3D 產品模型檔案大小一旦超過 5 MB，就已經不適合放在讓買家用手機打開的商品頁。能撐得住中階 Android 手機、一般行動網路的重量大約是 2 MB——理由不是美感，是算術：5 Mbps 之下，每 1 MB 要先等 1.6 秒，瀏覽器才可能畫出第一帧。
想通這件事，討論的性質就變了。多數供應商把 3D 模型當成行銷素材，把檔案大小當成 3D 工作室的問題；買家只看到它是打開頁面後第一件要下載的東西。以下是重量預算表、位元組真正花掉的地方，以及把 3D 連結貼進報價信之前要跑的六項檢查。
3D 產品模型檔案大小對照表：手機先下載什麼
下載時間 = 檔案大小 × 8 ÷ 頻寬，公式裡沒有算繪、沒有旋轉，也沒有第一帧。下表假設連線穩定，且不計 TLS 握手與往返延遲，所以真實手機只會更慢。
| 模型大小 |
10 Mbps |
5 Mbps |
1.6 Mbps |
買家等待時會做什麼 |
| 2 MB |
1.6 秒 |
3.2 秒 |
10 秒 |
轉一下模型，順手讀一行規格 |
| 5 MB |
4 秒 |
8 秒 |
25 秒 |
滑走，或改點靜態圖 |
| 10 MB |
8 秒 |
16 秒 |
50 秒 |
判斷頁面壞了 |
| 20 MB |
16 秒 |
32 秒 |
100 秒 |
關掉分頁 |
| 50 MB |
40 秒 |
80 秒 |
250 秒 |
根本看不到模型 |
50 MB 那一列請再讀一次：在辦公室好網路下也要 13 秒，在倉庫、展場或飯店那種較弱的行動網路下要四分多鐘。這種大小的模型不是展示素材，而是一次買家沒有同意的檔案傳輸。
3D 產品模型是唯一一種買家必須先下載完整個產品、才看得到產品任何一部分的商品素材。 照片可以逐列載入，影片可以緩衝幾秒就播，GLB 不行。
為什麼整個模型必須先到齊
glTF 2.0 規範明確寫著它不是串流格式：二進位資料本身可以串流傳送，但 glTF 沒有定義任何串流結構。因此檢視器只能先載入資產、解析，再算繪，中間沒有「看起來像產品」的半成品畫面。
容器選擇也影響這一點。GLB 把 JSON 場景描述與二進位緩衝打包成一個檔案，沒有 base64 膨脹，單次請求效率最高，代價是買家要等整個包。拆開的 .gltf 加 .bin 加獨立貼圖可以讓檢視器分塊抓取、更早開始，但請求更多、更容易出錯。單一 SKU 的產品卡通常一個 GLB 就夠；六十個 SKU 的系列，共用拆分的檔案總重往往更小。
這些不會出現在效能報表的圖片欄位，所以容易被忽略。商品頁的最大內容繪製（LCP）元素通常是主圖或文字區塊，不是 WebGL 畫布。Google 的標準是第 75 百分位的 LCP 不超過 2.5 秒。如果檢視器腳本和模型下載跟主圖搶頻寬，頁面就會錯過這個門檻，而 3D 團隊那邊只會回報「模型算繪正常」。
頁面其他部分已經佔掉多少
Web Almanac 引用的 2024 年 HTTP Archive 資料：桌機頁面中位數 2,312 KB，行動頁面中位數 2,037 KB；行動端光是圖片就佔其中約 900 KB。
把模型放進來比一比：
| 資源 |
典型重量 |
相對行動頁面中位數（2,037 KB） |
| 行動頁面整體 |
約 2 MB |
1 倍 |
| 2 MB 的 GLB |
2 MB |
頁面翻倍 |
| 5 MB 的 GLB |
5 MB |
整個頁面的 2.5 倍 |
| 20 MB 的 GLB |
20 MB |
整個頁面的 10 倍 |
預算就是這樣定的：3D 展示只是頁面上的一個元素，同一頁還有圖庫、規格表、評價、追蹤腳本和版型。模型單獨就比頁面中位數還大，那模型就變成頁面，而買家是在用自己的時間付費。
天候、展場 WiFi 和裝置都會放大這件事。三年前的中階手機解碼 4096 像素貼圖，比當初審圖的筆電慢得多。用測試機測，不要用工作室的螢幕測。
位元組花在哪裡，哪種壓縮修哪一塊
3D 產品模型檔案大小的開銷集中在三塊，按常見占比排序：貼圖、幾何、其他（動畫、相機、多餘節點）。很多人意外的是幾何往往不是大宗——一個由照片生成的模型，只要掛一張 4096 × 4096 的 PNG 貼圖，就可能比它包住的網格還重。
| 部分 |
什麼把它撐大 |
真正能減下來的做法 |
| 貼圖 |
4096 像素 PNG、用不到的法線／粗糙度貼圖、內嵌色彩設定 |
依檢視器實際顯示尺寸做小圖、改 JPEG 或 KTX2、刪掉材質不用的貼圖 |
| 幾何 |
掃描或細分出的百萬面網格、重複零件 |
減面到看得見的細節、重複件做實例化、Draco 幾何壓縮 |
| 其他 |
沒人播放的動畫、隱藏節點、相機、燈光 |
刪掉檢視器用不到的東西；產品轉台只需要一個相機 |
兩個已由 Khronos 批准的擴充承擔主要壓縮工作，且解決不同問題：KHR_draco_mesh_compression 以壓縮幾何資料取代原始頂點資料流；KHR_texture_basisu 以 KTX2 加 Basis Universal 超壓縮儲存貼圖，同時降低傳輸體積與顯示記憶體佔用。
兩者都是擴充，不是 glTF 基礎能力。檢視器必須支援，且沒有未壓縮備援檔時，必須在 extensionsRequired 宣告。送出之前，請用買家真正會用的那個檢視器開啟匯出檔——你的產品卡、你的官網，或平台的 3D 欄位。能在 Blender 開啟，不代表手機瀏覽器沒問題。
送出 3D 產品展示連結前的六項檢查
依序做。前兩項能擋掉大部分損失，後四項能擋掉最後變成客服信的失敗。
檢查 1：它是網頁匯出檔，不是工程檔
.blend 或 .step 是創作文件，帶著歷史紀錄、相機、材質，有時還引用某人筆電上某個資料夾裡的貼圖。網頁容器是 GLB，場景裡應該只有一個產品、一個相機、檢視器讀得懂的材質。匯出對話框問「是否套用修改器」「是否包含隱藏物件」時，前者選是，後者選否。
模型背後的原始照片同樣重要。混用不同角度和光線的素材建出來的模型，買家一轉就會看見接縫——這和照片組不匹配會毀掉商品頁是同一個道理。如果照片組還在拍，先看3D 產品展示需要哪些照片，再碰匯出器。
檢查 2：重量對應的是買家的網路，不是工作室的
開啟匯出檔，讀出以 MB 計的 3D 產品模型檔案大小，和上面的表對照。一定要看匯出檔，不看原始專案——40 MB 的工作檔可能匯出成 3 MB，3 MB 的工作檔也可能因為打包貼圖匯出成 30 MB。
超標時先修最大的那一塊。把四張 4096 像素 PNG 換成一兩張 1024 像素 JPEG，通常比改幾何省得多。Draco 和 KTX2 放在後面用：它們的價值是把合理的資產做小，而不是把不合理的資產變得可以接受。
檢查 3：第一帧是海報圖，不是空白畫布
延遲載入檢視器，先顯示靜態圖——最好和模型開啟時的角度一致——直到買家操作再啟動。這讓 3D 畫布不進關鍵路徑，也給頁面一個真正的 LCP 候選。
下一個最常出問題的是互動反應。Google 的 Interaction to Next Paint 標準是第 75 百分位不超過 200 毫秒，超過 500 毫秒算差。一個重模型加上物理引擎和陰影通道，在中階手機上很容易讓「點擊旋轉」超過這條線，即使頁面本身載入很快。
檢查 4：一根拇指就能轉
單手握手機，用拇指轉模型。如果手勢需要兩根手指、放開後模型自己漂移、縮放時旋轉中心跑掉，買家就會跟檢視器較勁，而不是讀產品。
邊緣也要測：頂面、底部、背面。把旋轉限制在 ±45 度的檢視器，剛好藏住買家最想看的那幾面——也就是攝影棚從來不拍的那幾面。
檢查 5：形狀仍然和產品一致
拿模型對著實物和尺寸圖轉一圈，看輪廓、五金件、拼縫，以及板材邊緣的厚度；再重點看買家會檢查的地方：鉸鏈、腳墊、把手、線條的斷面。
把照片轉成 3D 是展示步驟，不是測量步驟。模型可以把一條弧線做順，但不能憑空長出一個把手、抹掉一條拼縫，或改掉尺寸圖寫明的比例。模型和圖面衝突時，以圖面為準，重建模型。
這也是兩類輸出必須彼此誠實的地方。可旋轉模型表達形狀和零件如何相接，標註過的尺寸圖表達數字。把量出來的尺寸釘在照片上、再用同一份素材生成可旋轉模型的軟體，能讓這兩種視圖不跑偏——尺寸留在標註上，買家讀得到，而不是埋進算繪裡，誰都量不了。
檢查 6：看不到的人也有退路
企業筆電會禁 WebGL，有些瀏覽器預設關閉，舊手機在大貼圖上會記憶體不足。以上任何一種情況，買家都應該還能拿到靜態圖、規格表和聯絡按鈕。
把備援做法寫進頁面，不要只寫在計畫裡。WebGL 不可用時只顯示一個轉圈的灰框，比沒有檢視器更糟，因為買家會認定你的產品頁壞了。
3D 展示能證明什麼，不能證明什麼
3D 產品展示是展示資產：它傳達形狀、比例和零件之間的關係，不是測量紀錄。模型在螢幕上的視覺大小取決於相機、視角與買家螢幕，所以買家無法從上面讀出一個尺寸，供應商也不該暗示可以。
這句話值得直接寫在頁面上。一行字——「尺寸以實物測量為準，3D 展示只表達形狀」——能擋住這個流程裡最貴的誤會：買家以為模型就是帶尺寸的圖面，然後照著它下單。
| 買家的疑問 |
什麼能回答 |
什麼不能 |
| 「寬度正好是 1200 mm 嗎？」 |
尺寸標註在照片上的規格圖 |
再精細的 3D 算繪 |
| 「背面長什麼樣？」 |
3D 展示，或背面照片組 |
只有正面的圖庫 |
| 「進得了我家門嗎？」 |
門寬加上最小的包裝尺寸 |
能在螢幕上隨便縮放的模型 |
| 「底座怎麼固定？」 |
拆解圖，或把底座拆開的 3D 展示 |
一張漂亮的示意圖 |
什麼時候 3D 不值得這份重量
3D 不是所有買家問題的預設答案，把所有格式都堆在一頁上，比只放對的那一種更慢。用下面的判斷規則。
| 買家真正的問題 |
更輕、也夠用的素材 |
什麼情況才用 3D |
| 「側面長什麼樣？」 |
360 度照片序列或四角度圖組 |
買家需要自由旋轉，而不是逐帧翻看 |
| 「多大？」 |
尺寸標註在照片上的規格圖 |
從不——3D 回答不了這個問題 |
| 「怎麼拆開？」 |
帶引出編號的拆解圖 |
組裝順序本身就是賣點 |
| 「飾面對不對？」 |
同一光線下拍的微距照片 |
從不——貼圖不是顏色證明 |
如果問題只是「發哪種格式」，真正的選擇通常在 3D 展示和照片序列之間，而不是 3D 和什麼都不發之間。取捨點是檔案重量、互動程度，以及買家需要多少控制權；3D 產品檢視器與 360 度照片的比較把這個區分講得更細。
3D 值得佔位時，把它放在看得見的地方：一個和測量尺寸並排開啟的3D 產品展示，放在買家會轉寄給同事的那張產品卡裡，比藏在目錄頁三次點擊之後的檢視器有用得多。
常見問題
網站上的 3D 產品模型應該多大？
5 MB 以下；如果買家很可能用手機打開，2 MB 以下。上限來自算術而非偏好：5 Mbps 下，5 MB 的模型要先等 8 秒才出第一帧，而且還沒算檢視器腳本的執行時間。看匯出的 GLB，不看原始專案。
3D 模型會讓商品頁變慢嗎？
會，通常在兩處。下載會和主圖搶頻寬，把最大內容繪製推過 Google 的 2.5 秒良好線；檢視器腳本再搶主執行緒，把互動延遲推向 200 毫秒的 INP 門檻。要在模型真實上線的情況下跑 PageSpeed Insights，不要用佔位圖測。
GLB 和 glTF 有什麼不同？
GLB 是二進位容器，glTF 是格式。.gltf 是 JSON，指向另外的 .bin 和圖片檔；.glb 把 JSON 和二進位緩衝裝進一個檔案，不用 base64，所以是一次請求、比等價的 JSON 內嵌略小。兩者都是 glTF 2.0，都能在合規的檢視器裡載入。
不破壞形狀的前提下能減小 3D 模型檔案大小嗎？
能，三步：刪掉材質用不到的貼圖、把幾何減到檢視器真能顯示的細節、再對幾何用 Draco、對貼圖用 KTX2／Basis。每做完一步都重新核對輪廓和零件數量。最便宜的收益幾乎總在貼圖；最貴的錯誤是把曲面減到輪廓已經不像圖面。
買家能從 3D 展示裡量出產品尺寸嗎？
不能。3D 展示表達形狀和比例，無法確認尺寸，因為視覺大小取決於相機、視角與螢幕。需要數字的買家應該看標註過的規格圖或尺寸圖——尺寸要掛在產品上，而不是從算繪裡推斷。
參考資料
