GLB 檔案大小實戰：從 4GB 的 CAD 到 2MB 的網頁

說個實際的例子。客戶寄來一個壓縮檔，解開是一條包裝產線的整組 STEP 組立圖，4 GB，光解壓就等了一陣子。郵件裡只有一句話，說放到網站上讓買家能繞著看就好，口氣輕鬆得像在訂飲料。我當時心裡想的是，這條線裝起來八米長，光算頂點就夠嗆，還要塞進瀏覽器，而且客戶在展場用的手機大概只有兩格訊號。

這個比例不算特殊，反而接近常態。CAD 儲存的是給製造用的精確幾何，網頁需要的是給看的近似幾何。這兩件事之間的距離，就是 GLB 檔案大小問題的所在，而這些問題幾乎都來自四個可測量的來源。

為什麼匯出的檔案一定很大

一個 STEP 或 SolidWorks 組立圖裡面，塞滿了渲染器根本用不到的資訊，因為那些東西是給機台看的，不是給眼睛看的。你把整包直接匯出成 GLB，多出來的重量會用一種很固定的順序出現，每次都是同樣那幾樣先冒出來。

有個數字值得記住：一張未壓縮的 4K PNG 貼圖，本身就可以是 30 MB。一套 PBR 材質——基礎色、法線、粗糙度、金屬度、環境遮蔽——就是五張。在任何人動幾何之前，貼圖這一邊就可能已經超過整個預算。

先把順序搞對

這是最花時間的錯誤，而且普遍到值得講白。順序是：幾何、貼圖、壓縮、拆包。倒過來做感覺很有進度，實際幾乎沒改變什麼。

一個還有兩百萬三角面的模型，壓縮完在手機上一樣掛，因為解碼器必須先重建那兩百萬面，才畫得出第一格。只縮貼圖、卻讓機器內部維持完整建模，你省了頻寬，卻讓 GPU 忙在沒有人會看到的表面上。

動手之前先量測，不要憑感覺。對匯出的檔案跑一次 gltf-transform inspect，它會把每個網格、每張貼圖、每個節點的數量佔比列出來。十秒鐘的事，然後你就知道上面那四個桶子裡哪一個才是真凶，不用瞎猜。

那 4 GB 到底去了哪裡

具體數字比一般性建議有用，所以同一條包裝產線，一階段一階段列出來。

這張表要當成比例來看，不是食譜。刪掉看不到的零件做掉了大約 93% 的工作，需要的技術最少——那只是判斷買家看得見什麼。貼圖轉檔又做掉一個數量級。而壓縮，大家第一個伸手去抓的那件事，只負責最後那一小段。這個順序很典型，也剛好和大多數「幫我把檔案壓小」的需求講法完全相反。

而且真正該處理的時間點比優化器更早。匯出設定決定了一半的問題到底能不能修，那部分在為網站 3D 配置器準備 CAD 檔案裡。

幾何：砍掉沒有人看的部分

製造用的模型是為了被做出來，不是為了被看。三道處理可以去掉大部分多餘，而不動到買家真正會檢查的地方。

刪掉內部與隱藏零件。那條包裝產線裡，機架、馬達、輸送帶內部、走線全部建了模。外板一裝上去，這些一個都看不到。光是把這些刪掉，檔案就從 4 GB 掉到 300 MB 以下，什麼減面都還沒做。

減面，但不是全面減。一塊四個孔的平板，面數減到原來的 40% 看不出差別。一個有倒角、圓角、鑽孔的加工面就不是這樣——掉到 85% 以下，那個孔會變成多邊形，而這正好是機械買家第一眼會放大的地方。要按材質和零件類型分開減，不要全域減。

合併同材質的物件。兩百個同樣鋼材的支架，合併成一個網格就變成一次繪製呼叫。行動裝置上，繪製次數比三角面總數更關鍵，而一個兩千節點的 CAD 階層就會產生兩千次呼叫。

三道處理做完，那條包裝產線的幾何大概落在 12 MB。還不能接受，但已經不再荒謬，而且剩下的重量轉移到了處理成本比較低的地方。

貼圖：真正的大頭

多數團隊把力氣花在多邊形上，而檔案大小是圖片決定的。四條規則，按影響力排序。

解析度減半，位元組剩四分之一。4K 降到 2K，像素少四倍，檔案大小差不多也少四倍。產品頁上模型最多佔 1080p 螢幕的三分之一，也就是說 2K 在預設視角下已經超過螢幕能分辨的密度。只有在你的介面真的提供近距離特寫時，才需要留 4K。

對大多數網頁產品，1K 就夠。我知道這句話對花了幾週調材質的人來說像在挑釁。但說真的，一條產線外殼掛 1K 的基礎色貼圖跟掛 4K，在人們實際滑手機的那個距離下，我自己也分不出來，而我盯這種東西盯了很多年。

換成 KTX2，不要換 JPEG。PNG 轉 JPEG 會減少位元組，但增加解碼時間和顯示記憶體用量，因為 GPU 還是需要完整未壓縮的貼圖進記憶體。KTX2 搭配 Basis 壓縮可以在 GPU 記憶體裡保持壓縮狀態，通常比 PNG 小五到八倍，而且是在 GPU 上解碼，不佔 CPU。

砍掉沒在用的貼圖。從 CAD 烘焙出來的環境遮蔽通常本來就是錯的。一個完全非金屬的產品帶著金屬度貼圖，就是浪費一張 2K。每砍一張，就是換回重量和解碼時間。

那條包裝產線上，把每個材質五張 4K PNG 換成 2K KTX2，貼圖載荷從 200 MB 以上降到 6 MB 以下。這一步的效果超過所有減面加起來。

Draco 還是 Meshopt

兩者都壓幾何，差別在壓縮率和解碼成本的取捨。

在產品頁上，第一格必須在一兩秒內出現，Meshopt 通常勝出，儘管壓縮率比較差。模型很大、靜態、而且是在工作站上看，那 Draco 勝。還有一個硬限制值得知道：需要 GPU 端逐頂點處理、或需要部分串流頂點資料的幾何，跟 Draco 配合得不好。

拆包，而不是硬壓

到了某個點，壓縮不夠用，要靠架構解決。配置器很適合拆包，因為零件本來就是邏輯單位。

先載入降細節的主體，再串流載入屬於目前配置的零件。一台有四種選配的機器，買家只會用到他選的那一個。一個傢俱配置器可以只送基礎框架加十二種門板的其中一種，而不是十二個完整模型。顏色變化屬於貼圖圖集或材質參數，永遠不該用每個顏色一個重複模型來解決。

代價是複雜度：更多請求、更多狀態要管，而且漸進式出現這件事必須被設計，不能靠它自己發生。行動端通常值得。桌機通常不值得。

我會照著做的預算

這些是我們交付時要求自己守住的數字，刻意寫得很直白。

最後那一列才真正要緊，也是多數 3D 專案會忽略的。一個漂亮但把最大內容繪製推到四秒以上的模型，是淨損失，因為頁面過不了 Core Web Vitals，搜尋表現也跟著掉。模型不在頁面預算之外，它通常是裡面最大的一筆。

什麼時候這個建議是錯的

上面那套建議有一種會走偏的版本。如果配置器本身就是產品——一只旗艦手錶、一件高級珠寶、展間裡的一台車——那麼逼真度就是賣點，1K 貼圖就是錯誤決定。沒有人因為一只戒指一秒鐘載得出來就買它。

那類專案屬於另一種架構。雲端串流在伺服器上渲染、送出影像，任何裝置都能拿到接近照片的品質，用戶端幾乎不做事；代價是按工作階段計費，而且隨流量放大。對少數幾件產品它是最佳解，對四十台機器的目錄它是錯的。要問的問題是：買家是在評估一筆採購，還是在欣賞一件物品。一次對話之內通常就分得出來。

這件事實際要花多少工時

把一個主力模型好好優化，是一位美術一到三個工作天。聽起來對「把檔案變小」這件事太多了，直到你拿它跟另一個選項比：一個產品頁整整一年過不了 Core Web Vitals，然後自然流量悄悄跟著掉。

再乘上主力模型的數量，它就是專案預算裡實實在在的一行。所以它該在任何人報價之前就被算進去，而不是事後被當成超支吸收掉。跳過這一步的團隊並沒有省下那些天。他們只是晚一點花掉，在救火的時候花，在最糟的時刻花。

做完之後長什麼樣子，看產品類型差別很大。我們的案例涵蓋了那個範圍：從必須禁得起近距離檢視的衛浴，到重點在組裝順序而不是表面質感的工業儀器。

上線前怎麼驗

四個檢查，都只要幾分鐘，能抓到幾乎所有問題。

對最終檔案跑 gltf-transform inspect，確認貼圖和幾何的佔比是你預期的。在 Chrome DevTools 裡用節流後的行動設定、關掉快取載入頁面，看第一格畫面實際出現的時間，而不是網路跑完的時間。在渲染器自己的統計面板看繪製次數和三角面數，因為行動效能主要由這兩件事決定，不是檔案大小。最後對上線網址跑一次 PageSpeed Insights，因為那是 Google 會拿來評分的數字。

模型輕到載得出來之後，互動層是另一門功課，行動裝置 3D 產品互動談的是當檢視器從滑鼠換成拇指，什麼東西會變。

那條 4 GB 的包裝產線，最後首格停在 1.9 MB，其餘部分在後面串流補上。在手機上看過它的人，沒有一個問過它有幾個多邊形。把檔案寄給我們，我們會告訴你你的模型現實上能降到多少，以及要犧牲多少細節。

常見問題

問：網站用的 GLB 檔案多大才算合理？

產品頁的首格，桌機 2 MB 以內、行動裝置 1 MB 以內。全部載完的場景總重，分別控制在 8 MB 和 3 MB 以內。超過這個量級的檔案通常還是載得出來，但它會吃掉最大內容繪製的時間，那既是使用者體驗問題，也是搜尋表現問題。

問：Draco 壓縮一定是最好的選擇嗎？

不一定。Draco 可以把幾何壓掉九成，但畫第一格之前需要先跑 WASM 解碼器，在中階手機上這可能是幾百毫秒。Meshopt 壓得少，解碼幾乎瞬間，這在行動優先的產品頁上通常是更好的交換。選哪一個看模型在哪裡被看，不是看報告上哪個壓縮率漂亮。

問：用 GLB 壓縮工具直接處理不行嗎？

會有幫助，但不會夠。自動工具通常一律套用 Draco 和縮圖。真正有效的部分，多半來自先刪掉內部幾何和沒用的貼圖，以及不去減那些買家會近看的加工面——這些決定需要知道這個產品是什麼。

問：為什麼我的 GLB 比 OBJ 或 FBX 大那麼多？

論幾何其實多半沒有。GLB 把貼圖嵌在單一檔案裡，而 OBJ 和 FBX 常常是外部引用，所以這個比較把大部分的重量藏起來了。要比就比整個匯出資料夾的大小，而且先看一份檢測報告裡的貼圖明細再下結論。

問：壓縮會傷畫質嗎？

幾何壓縮一般不會，實務上對觀看用途是無損的。貼圖壓縮會，這也是要刻意處理的部分。解析度減半在瀏覽距離下通常看不出來；砍掉法線貼圖、或壓得太兇，表面就會開始變平。