多數人以為，網站上那種能用滑鼠拖動、360 度轉看的商品 3D 展示，背後一定是工程師從零手刻的複雜繪圖引擎。真相剛好相反，絕大多數電商網站看到的商品 3D 展示，工程團隊很少從最底層的繪圖管線寫起，多半是站在現成的函式庫之上，把場景、攝影機、燈光這些元件組裝起來，就能做出可互動的畫面。真正考驗工程能力的地方，反而不在會不會寫 3D，而在模型檔案要壓到多小才不拖累網站速度，以及搜尋引擎與螢幕閱讀器根本看不懂那塊畫布裡發生了什麼事。
WebGL 3D 產品展示（讓消費者在瀏覽器裡直接旋轉、縮放、多角度檢視商品的立體畫面）已經不是少數品牌的實驗性玩法。Shopify 官方就公開觀察到，有加入 3D 或 AR 內容的商品，互動轉換率平均比沒有的商品高出 94%，多個實際導入的品牌也各自證實了加購率與訂單金額的具體增幅。只是這筆投入不是免費的，模型愈精細，使用者要等的下載時間就愈長，畫在 canvas 裡的商品內容，對搜尋引擎與輔助工具來說也幾乎是一片空白。
撐起商品 3D 展示畫面的通常是 Three.js 而非純手寫 WebGL
把這套體驗拆開來看，其實分成兩層：最底層是瀏覽器原生的 WebGL，直接跟顯示卡溝通該怎麼畫東西；商品展示實際用的，則是蓋在 WebGL 之上的高階函式庫，最常見的是 Three.js，偶爾也會看到 Babylon.js。兩者分工清楚，弄懂了這條分界，才看得懂後面每一段技術決策在解決什麼問題。
瀏覽器原生的 WebGL 和它的繪圖管線
WebGL 全名 Web Graphics Library，是瀏覽器內建的 3D 繪圖標準 API。根據 Mozilla 官方技術文件 MDN 的說明，WebGL 讓開發者能運用顯示卡運算 3D 畫面，而且完全不需要另外安裝任何外掛。它建立在 HTML 的 canvas 元素之上，開發流程大致分成幾個階段：先準備好繪圖情境，把要畫的頂點資料上傳給顯示卡，再逐幀重新計算並繪製到畫面上。
這套流程聽起來單純，但每一步都要處理相當底層的細節：頂點座標怎麼轉換成螢幕上的像素、光線該怎麼跟表面互動、材質貼圖要怎麼對應到模型表面，這些過去屬於遊戲引擎工程師才會碰的工作，如今被搬進了瀏覽器。也正因為門檻不低，商業產品很少有人真的從這一層開始寫起，Three.js 這類函式庫因此成為多數商品 3D 展示實際仰賴的那一層。
Three.js 封裝的場景、攝影機與燈光物件
Three.js 官方網站把自己定位成一套「JavaScript 3D Library」，做的事情正好補上前一段提到的那道門檻。它把 WebGL 底層那些著色器、緩衝區、矩陣運算包裝成場景、攝影機、燈光、材質這些物件，開發者不必再手刻繪圖管線，用組裝積木的方式，把商品模型放進場景、擺好攝影機角度、打上燈光，就能做出使用者可以拖曳旋轉的商品展示。
Three.js 官方頁面上收錄了大量用這套函式庫實作的公開專案，其中不少就是互動式的商品或場景展示，可以佐證一件事，多數電商網站看到的 3D 展示，實作層面用的其實是 Three.js 這一層，而不是原始 WebGL。這也代表，一個團隊要導入商品 3D 展示，真正要學的不是圖形學底層原理，而是怎麼用 Three.js 或同類型函式庫，把模型、燈光、互動邏輯組起來。只是模型本身要放進場景之前，還有一關要先過，檔案格式該用哪一種，才不會讓瀏覽器遲遲載入不出來。
glTF 已是模型傳輸的產業標準，2022 年並入 ISO 國際規範
商品模型要能順利在瀏覽器裡打開，第一道關卡是檔案格式的選擇。這個問題現在已經有清楚答案，glTF 與它的二進位版本 GLB，是目前 3D 模型傳輸公認的預設格式，背後不是哪一家廠商自訂的規格，而是有國際標準組織背書。
glTF 與 GLB 取代 OBJ、FBX 成為模型傳輸的預設格式
glTF 由 Khronos Group 主導，這是同一個訂出 OpenGL、Vulkan 這些圖形業界基礎規格的跨產業標準組織。Khronos 官方把 glTF 定義為「一個免版稅的規範，用來高效傳輸與載入 3D 場景及模型」，並形容它是「3D 的 JPEG」，核心設計目標就是把 3D 資產的檔案體積與執行期的解析成本壓到最低。這正好對上網頁比原生應用程式更敏感的痛點，使用者要在瀏覽器裡等模型下載完成，沒有「安裝過程」可以攤提這段等待時間，因此早期為建模軟體之間交換資料而設計的 OBJ、FBX，逐漸讓位給專為傳輸效率設計的 glTF。
這套格式的地位不只是業界共識，2022 年 glTF 2.0 正式被發布為 ISO/IEC 12113:2022 國際標準，等於從 Khronos 自家規範，升級成跨國認可的技術規格。GLB 則是 glTF 的二進位封裝版本，把模型幾何、貼圖、動畫打包成單一檔案，方便網站直接載入。Shopify 官方部落格也證實，該平台目前接受的 3D 模型格式正是 GLB，另外搭配 Apple 用於 iOS 裝置擴增實境的 USDZ 格式，等於電商實務也印證了 GLB 已經是這個場域的標準做法。
Draco 幾何壓縮和 KTX2 材質壓縮，把檔案體積壓到能上線
格式選對了，檔案體積不一定就夠小，這時候要靠壓縮技術再往下砍。Draco 是 Google 開發、開源在 GitHub 上的幾何網格壓縮函式庫，官方說明它的目的是改善 3D 圖形的儲存與傳輸，具體效果是應用程式下載得更快、瀏覽器裡的 3D 圖形載入得更快，VR、AR 場景也能只用一小部分頻寬就傳完。開發者可以自行調整量化位元數，數值愈低壓縮率愈高，但模型的精細度也跟著損失愈多；Google 官方文件指出，多數專案把頂點位置的量化位元數設在 11 左右，這個範圍壓縮效果明顯，肉眼卻已經看不出品質上的落差。Draco 目前也能直接整合進 glTF 資產，透過對應的轉碼工具處理。
除了幾何網格，貼圖材質本身也需要壓縮，這時候輪到 KTX2 上場。KTX2 是 Khronos Group 制定的 GPU 材質容器格式，內建 Basis Universal 這套超壓縮技術。Khronos 官方頁面指出，KTX2 比傳統的 JPEG、PNG 貼圖能達到明顯更小的傳輸體積與 GPU 記憶體佔用，而且可以在執行期依裝置種類轉碼成該裝置原生支援的壓縮格式，不用為不同裝置各準備一套貼圖。Khronos 也發布了 KHR_texture_basisu 這項擴充規格，讓 glTF 資產能直接內嵌 KTX2 材質。把格式、幾何壓縮、材質壓縮這三件事都做對，模型才真正到了能上線的程度，只是即使檔案已經壓到最小，使用者還是得花時間下載，這仍是一筆無法迴避的代價。
3D 模型直接拖累首屏載入速度，這是多數團隊低估的代價
多數談商品 3D 展示的討論只講效果好不好看，很少談它對網站速度造成的實際負擔。這個負擔其實很單純，不管模型壓縮得多精簡，使用者都得先等它下載完成，才看得到畫面。
模型檔案大小與 Largest Contentful Paint 的取捨
Google 官方開發文件 web.dev 說明，Core Web Vitals 目前聚焦載入、互動、視覺穩定三個面向，其中 Largest Contentful Paint（LCP）專門用來量測感知載入速度，也就是使用者主觀感覺網頁需要多久才看起來準備好了。同一份 web.dev 針對 <model-viewer> 元件的說明文件則點出一個容易被忽略的事實，把 3D 模型加入網站是複雜的工作，因為所有 3D 模型都需要時間載入，模型的下載與解析時間會直接影響使用者感受到的載入表現。
這解釋了為什麼一顆 3D 模型比一張圖片更容易拖慢 LCP。一張商品照片就算沒壓縮好，體積頂多幾百 KB；一顆商品模型光是幾何網格加上貼圖，動輒是圖片的好幾倍，而且瀏覽器還要花額外的運算資源把它解析、繪製出來，不是下載完就結束。如果 3D 模型剛好是頁面上最大的可視元素，多半就是主打的商品展示區塊，它的載入速度幾乎直接決定了 LCP 這項指標的分數，也就直接影響 Google 怎麼評價這個頁面的使用者體驗。
用預覽圖與捲動載入，把代價壓在使用者能接受的範圍
這筆代價不是無解，業界以 Google 官方推出的 <model-viewer> 元件為例，已經有兩種常見手法在管理它。第一種是先用一張圖片頂住版位，<model-viewer> 提供 poster 屬性，讓開發者在模型真正準備好之前，先顯示一張預覽圖片，使用者不會看到空白的畫面，只會覺得模型正在展開細節，而不是網頁沒有反應。
第二種手法是延後啟動，<model-viewer> 內部使用 Intersection Observer，這是瀏覽器原生提供的 API，用來偵測某個元素是不是已經進入使用者的可視範圍。當商品 3D 展示還在畫面外，例如使用者還沒捲動到那個區塊，元件會暫停渲染，藉此節省電力與 GPU 運算資源，等使用者真的捲到那個位置才開始運算畫面。這兩個做法合起來，等於把 3D 模型需要花時間載入這個既定事實，管理在使用者感受得到、卻不至於不耐煩的範圍內，代價可以被工程手法壓低，但完全消除不了。
canvas 裡渲染出的商品畫面對搜尋引擎完全不可見
載入速度的問題處理好之後，還有一個更容易被忽略的技術限制，不管 Three.js 把畫面做得多精緻，這一切都發生在 HTML 的 canvas 元素裡，而 canvas 對搜尋引擎與輔助工具來說，幾乎是一片空白。
canvas 標籤只是一塊畫布，瀏覽器把 WebGL 運算出來的每一個像素畫在這塊畫布上，但這些像素本身不是 HTML 的一部分，也沒有任何語意。搜尋引擎的爬蟲在讀取網頁時，讀得到的是 canvas 標籤周圍的文字與結構，讀不到畫布裡畫出來的商品外觀、材質細節，更不會知道使用者正在看的是哪一款商品。螢幕閱讀器面對同一塊畫布，狀況一樣，它讀得懂 HTML 元素上的文字與屬性，對著一塊純粹由像素構成的畫布，完全沒有東西可以唸給使用者聽。
canvas 規格本身有提供一種補救機制，做法是在 canvas 標籤內部放進替代用的子元素，理論上輔助技術讀不懂畫布時，就會改讀這些子元素當作替代內容。但這個機制在實際產品上有明顯侷限：多數商品 3D 展示的介面，不會把完整的商品名稱、規格、賣點都寫進這幾行替代標記裡，結果還是等於什麼都沒有交代清楚。比較務實的做法，是把商品標題、規格、材質說明這些真正重要的文字，寫進 canvas 外層真正的 HTML，而不是寄望畫布裡的模型或貼圖能替代這些資訊。換句話說，3D 畫面應該被當成錦上添花的體驗，不能是唯一承載商品資訊的地方，這樣搜尋引擎抓得到、螢幕閱讀器唸得出來，少了 3D 也不會讓使用者看不懂這是什麼商品。
電商導入 3D 展示後，加購率與訂單轉換率的實際增幅
解決了載入速度與可讀性這兩個技術門檻之後，真正的問題才浮上檯面，這筆投入值不值得。Shopify 在 2020 年於自家社群媒體公布過一個平台層級的觀察，有加入 3D 或 AR 內容的商品，互動轉換率比沒有的商品平均高出 94%。這個數字要先說清楚它的性質，這是 Shopify 平台級的彙總觀察，不是控制變因的對照實驗，樣本規模、統計方法 Shopify 並未公開，只能當作方向性的參考，不是保證每個商品套上 3D 都會得到同樣的增幅。真正能拆解出技術細節與具體數字的，是幾個公開揭露的品牌案例。
Rebecca Minkoff 案例的加購率與訂單轉換率數字
Shopify 官方案例研究記錄了時尚配件品牌 Rebecca Minkoff 的做法，這個品牌為超過 50 款商品建置了 3D 模型與 AR 檢視功能，桌面端消費者可以用滑鼠點擊拖曳，查看包款完整角度的紋理與結構；行動裝置則提供 AR 虛擬試戴，讓顧客在自己身上先看一次上身效果。
該品牌全球電商和數位資深總監 Sarah Sheldon，與共同創辦人暨執行長 Uri Minkoff 共同證實了三個具體數字：跟 3D 模型互動過的消費者，把商品加入購物車的機率比沒互動過的消費者高 44%，下單機率也高出 27%；曾經用 AR 檢視商品的消費者，完成購買的機率更高出 65%。案例頁面沒有公開這幾個數字對應的樣本規模與統計時間區間，但差異幅度已經足以說明，多讓消費者用手轉一轉、試戴一次，確實能換算成實際下單的行為變化。
Oakywood 案例的客製訂單量與平均訂單金額成長
另一個案例換了完全不同的商業模式。Shopify 官方案例研究記錄，波蘭木作家具品牌 Oakywood 與 3D 掃描技術商合作，讓顧客能透過 Shopify 內建的 AR 功能，即時客製化桌板尺寸與木紋材質，還可以用手機掃描 QR code，把家具依真實尺寸投影到自己家裡預覽擺放效果。
創辦人 Mateusz Haberny 證實，導入這套功能之前，客製化訂單常常好幾個月都掛零；導入之後，訂單量穩定成長到每月 200 到 300 筆。更值得注意的是平均訂單金額的變化，在三個市場分別成長：英國 84%、瑞士 232%、德國 458%。這組數字跟 Rebecca Minkoff 案例形成有意思的對照，後者證明 3D 能提升要不要買的意願，Oakywood 則證明它能提升客製化之後願意花多少錢，兩者加起來，大致勾勒出 3D 展示在電商場景能發揮作用的兩個方向。
Google 官方案例顯示 3D 產品教育規模和成本效益同步改善
如果前兩個案例證明的是 3D 展示能拉高電商的加購與轉換，Google 自家的案例則從另一個角度切入，重點不是轉換率，而是規模與成本效益，也就是同一套技術棧，能不能用更少的資源做出更多的體驗。
web.dev 的案例研究記錄，Google 內部的 Devices and Services Marketing 團隊，也就是負責手機、手錶、耳機、平板、智慧家居這幾條產品線行銷的部門，建置了一整套互動式 3D、AR 產品教育體驗。這套體驗用的技術棧，跟前面幾節談過的完全對得上：網頁元件用 <model-viewer>，場景與互動邏輯用 Three.js 搭建互連的虛擬環境，資產格式是 glTF、GLB，幾何網格則用 Draco 壓縮。團隊也自訂了一條硬性規則，含貼圖的模型檔案最大不能超過 2MB，確保比較舊的裝置與訊號較弱的網路環境也能順利載入，這跟前面談過的載入代價與壓縮手法，是同一套邏輯的落地版本。
官方公布的具體成效相當直接：能推出的互動式產品教育體驗數量，成長為原本的 4 倍；受益的產品數量，成長為原本的 3 倍；單一體驗的製作與上線速度快 4 倍；而整體製作成本，降到傳統作法的一半以下。這個案例最早在 2021 年上線，之後持續擴充。它跟電商轉換率的案例合在一起看，補足了完整的一面，3D 展示不只是讓單一商品賣得更好，對一個要同時經營多條產品線、大量產出教育內容的團隊來說，它也是一種能規模化、還能同時省成本的做法。
產品特性與呈現方式同樣決定 3D 展示能不能拉高轉換率
不過前面這幾組亮眼的數字，不代表隨便一個商品套上 3D 展示，就能複製 Rebecca Minkoff 或 Oakywood 的成績。
把這幾個案例的商品類型放在一起比較，會看到一個共同特徵。Rebecca Minkoff 是單價較高的時尚配件，Oakywood 是能客製化尺寸與材質的木作家具，Google DSM 案例的手機、手錶、耳機這些 3C 硬體，本身就需要多角度細節與功能說明才能被理解。這幾類商品有一個共通點：消費者在下單前，本來就需要多看幾眼、多轉幾個角度確認細節，或者需要先客製化才能決定要不要買。這種考慮型購買，天生就比日常消耗品更容易從 3D 展示得到邊際效益，買一包衛生紙不需要 360 度檢視包裝，但買一張要客製尺寸的桌板，顧客會想先看清楚成品長什麼樣子。
反過來說，前面談過的兩項技術代價，也不是等生意做起來再回頭補的選配。模型會拖累首屏載入速度，canvas 裡的商品畫面對搜尋引擎與輔助工具不可見，這兩件事在導入 3D 展示的第一天就會存在，必須跟轉換率的效益一併規劃，不能只看數字亮眼的那一面。真正該問自己的問題，不是別人做了 3D 展示、要不要跟進，而是這個商品的購買決策，是不是真的需要靠多角度細節或客製化預覽，才能說服顧客下單。如果答案是肯定的，前面談過的每一項技術投入，大概率能換回看得到的成效；如果商品本身不需要這種說服過程，3D 展示比較像是加分項，而不是決定成敗的關鍵。
回到最開頭的那個反直覺，多數商品 3D 展示背後，真正的門檻不在會不會寫 WebGL，而在願不願意把 Three.js、glTF、Draco 這些現成工具搭好，並且誠實面對它帶來的載入速度與可讀性代價。這幾年 Shopify、Google 陸續公開的案例已經證明，只要產品類型對了，加購率、訂單金額、規模化的內容產出，都能換算成看得見的數字。但數字背後的前提，是先確認這個商品的購買決策，真的需要靠多看幾眼、多轉幾個角度才能被說服，想清楚這一點，再決定要不要把預算花在這上面，會比看到別人做了就跟著做，划算得多。