English
繁體中文
配置器上線，產品團隊慶祝，三週後業務那邊傳來一句：客人說頁面會「卡住」。嚴格說沒有東西壞掉，而這才是最麻煩的地方，因為網站 3D 配置器性能的問題極少報錯，它只是安靜地在中階手機上流失客人，而工作室那台桌機看起來一切正常。
市面上寫這件事的文章，大多假設你正要從零開始建。這篇寫的是另一種處境：東西已經在了，你需要知道重量壓在哪裡。六項檢查，按「最快找到大問題」的順序排。除了瀏覽器，不需要新工具。
體檢到底在量什麼
預設視圖的下載量是最直白的一個數字：購物者在能碰模型之前必須抓多少東西。跟它並排的是 LCP 歸屬問題，如果畫布拿走了 Largest Contentful Paint，那麼 3D 就變成你的 Core Web Vitals 分數負責人，不管你原本有沒有這個打算。再來是首次可互動時間，也就是拖一下真的轉得動的那一刻，這是客人實際感受為「快不快」的數字。
三項可以過一項、掛兩項，這也是為什麼供應商說「兩秒載入」時，如果沒講清楚什麼算載入完成，那句話幾乎沒有價值。
第一項：預設視圖的重量
量測需要一個無痕視窗、一個誠實的限速設定（例如 Fast 3G），以及在配置器抓第一批檔案時盯著網路面板。
幾個可以放在心裡的數字。CAD 原檔直轉 glTF，單一變體常常落在 40 到 120MB 之間，在手機上就是二十秒以上的白畫面；Draco 或 meshopt 之後，同一個資產通常進到個位數 MB。瞄準快速店面的工作室會公布約 2MB 的初始載荷目標，其餘細節後載。如果預設視圖在客人動手之前就拉 15MB，這張清單的其他項目都還輪不到討論。到了這個階段，3D 配置器載入速度是建模問題，不是前端問題。
同一項的另一半，是配置器該不該出現在那個頁面上。配置器腳本只該出現在會用到它的頁面，模型應該等一個觸發點（點「看 3D」，或者區塊進入視窗）再來，而不是跟著頁面一起載。Google 索引的是 HTML，塞滿幾何的畫布對這件事毫無貢獻，所以文字內容得先渲染、而且快。
畫布哪裡搶走了分數
螢幕上最先出現什麼，已經講了大部分故事。如果是一個空心框裡的轉圈動畫，這頁就吃了一次不必吃的虧。一張 poster 圖加上固定長寬比，本來可以佔住位置、拿到不錯的繪製時間。版面位移也在這裡算帳：3D 容器在模型到達後才改變尺寸，內容被推來推去，在實際使用者資料裡就是「不穩定」。
接下來要確認 LCP 算在誰頭上。順序建錯的專案裡，畫布會認領它，於是之後每一次 3D 優化，都是在優化一個本來用一張靜態圖就能過關的指標。這是架構問題，不是外觀問題，也是老練團隊堅持「標題、價格、購買按鈕必須是會先繪製的普通 HTML」的原因。
手機端的現實
你的受眾不是工作室那支手機。一位公開九個真實部署的開發者說，配置器流量大約七成來自手機，這跟我們看到的相符；客人是在沙發上滑，或在工地現場滑，不是在桌前。
兩個細節值得查。裝置像素比是其一：在 retina 手機上以 3 倍渲染，GPU 工作量翻倍，而差別幾乎沒有人看得出來，把它壓到 2 就能回收一大塊成本。重複幾何是其二：一組配置裡有四十片相同的葉片、每片都是獨立網格，畫面一定爬不動，而實例化渲染可以用一次呼叫畫完。如果某個選項把相同零件乘上去之後幀率就崩，問題在 draw call，不在檔案大小。
著色器編譯也值得提一句，因為它在快筆電上完全隱形。中階 Android 第一次渲染可能卡在編譯上，而先顯示低細節版本、再串流細節的漸進式載入，正好把那個卡頓藏在有用的畫面後面。
被忽略的乘數：每個變體一套紋理
紋理通常是下載量最大的那一塊，而且它會安靜地相乘。一套 PBR 材質往往就是三、四張貼圖，如果每種布料都自帶一整套、而且開場全部載入，那每加一個選項就是加幾 MB。要查的是：瀏覽器有沒有在下載客人根本沒選的布料貼圖。
兩個改動能解決大半。產品展示用 2K 上限，小件用 1K，而且要用 GPU 能直接使用的格式，而不是必須先完整解壓的格式，這正是 KTX2 加 Basis Universal 存在的理由。另一個改動是按需抓取：先載預設配置，客人選了布料再抓，並在背景預載下一個可能的選擇。體感速度的提升，這件事比任何壓縮率都大。
前端能救的也有上限。幾何本身一旦比產品需要的重，下游每一個修正都只是在壓縮浪費，實際的替代方案是重做資產。那套功夫屬於素材管線而不是頁面，先從為網站 3D 配置器準備 CAD 檔案開始，再往下才是縮小 web 端 GLB 檔案按「哪一步先做最划算」的順序寫過。
修的順序
這裡沒有什麼稀奇技術，但順序很重要，因為在一個根本不該上傳的模型上修紋理，等於白忙。
先砍預設載荷，砍要載什麼、也砍該不該現在載：延後到有互動意圖、給一張 poster、把空間先佔住。然後處理紋理，因為重量多半在這裡：限解析度、用 GPU 友善格式、停止運送每個變體的貼圖。幾何壓縮與實例化排在後面，而用哪個編碼器，其實不如「在真正的中階機上測解碼時間」重要，解碼器也要自己託管，別從第三方 CDN 拉，那會在畫面出現前先加上幾百毫秒。
客人實際看到多少，也取決於檢視器怎麼呈現、由哪種形態承載互動、以及做不到的裝置有沒有靜態替代方案，這些取捨在互動式 3D 商品展示裡整理過。
我們每個專案上線前都會跑其中一項，而且從來沒有空手而回：拿辦公室裡最便宜的那支手機打開頁面，用碼錶計時。如果第一次互動要超過一次呼吸，上面那些數字會告訴你為什麼。如果配置器已經上線、卻沒有人說得清重量壓在哪，說說你的現況，我們陪你的團隊跑一次體檢。網站 3D 配置器性能的問題，多半一個下午就能找到，兩週內就能修好，前提是有人知道該往哪裡看。
FAQ
問：網站 3D 配置器多快算合格？
量預設視圖，不要量整個體驗。載荷約 2MB、中階手機上首次互動在一到兩秒內，是合理的目標；互動前就超過 10MB，通常會直接反映在手機網路上的跳出率。
問：壓縮模型就能救回慢的配置器嗎？
只救一部分。壓縮減少下載量，但如果檢視器還是跟著頁面載入、還是運送每個變體的紋理、還是用 3 倍像素比渲染，頁面照樣慢。延後載入和紋理策略帶來的效果，通常大於換編碼器。
問：怎麼知道畫布有沒有拖累 Core Web Vitals？
在 PageSpeed Insights 或效能面板裡看 LCP 歸屬哪個元素。如果是 3D 畫布，代表檢視器在關鍵路徑上，要移到 poster 圖和觸發點後面；如果 LCP 是產品標題或主視覺圖，那 3D 不是你的瓶頸。
