WebGL 是什麼？網頁 3D 物件能做到什麼程度？2026 技術現況與企業導入決策完整指南

最近我們在排一個客戶的官網改版時，業主丟過來一句話——「能不能像 Apple 那種網頁，產品自己會轉、零件會散開來，最好還能拖著看」。這幾年類似的問題從只出現在電商，到現在連工程設備、建築事務所、製造業 B2B 的客戶都會問。

所以這篇我們乾脆把「網頁 3D 物件可以做到什麼程度」一次講清楚——除了交代 WebGL 是什麼，更重要的是把 2026 年的瀏覽器到底已經能跑到什麼地步、Three.js 跟 WebGPU 各自走到哪裡、企業官網要不要花這個錢做、要做怎麼挑廠商不踩雷，整套講透。

先給結論：WebGPU 在 2026 年 1 月正式 Baseline 之後，「網頁 3D 物件」這件事已經跨過「能不能做」這道門檻，真正的關鍵變成「值不值得做、怎麼做不會拖垮行動裝置」。下面我們一段一段拆。

WebGL 是什麼？跟 WebGPU 差在哪——一頁理解網頁 3D 技術棧

WebGL（Web Graphics Library）是瀏覽器內建的 3D 圖形 API，2011 年由 Khronos Group 推出，本質上是把桌上型電腦繪圖標準 OpenGL ES 2.0 搬進瀏覽器，讓 JavaScript 可以直接呼叫 GPU 畫三維物件，不需要安裝任何外掛。十多年下來它已經是瀏覽器 3D 內容的事實標準——你在 Google Maps 看地球轉、在電商網站拖動沙發、在線上會議用虛擬背景、甚至在 Figma 拖原稿，背後幾乎都是它。

但 WebGL 跟 GPU 之間隔著一層 OpenGL ES 翻譯，CPU 用的是 JavaScript 主執行緒、不能用 compute shader、批次繪製能力也有上限。當你要畫的 3D 場景複雜到一定程度——例如汽車設定器一次顯示三萬個面、或一個完整的工廠 3D twin——WebGL 就會撞到天花板。為了解決這件事，W3C 跟瀏覽器廠商從 2017 年開始合作開發新一代標準，這就是 WebGPU：底層直接對應 Vulkan / Metal / Direct3D 12，提供 compute shader、bind group、async pipeline，整個 GPU 程式模型重來。

依 web.dev 官方公告，WebGPU 在 2026 年 1 月正式 Baseline，Chrome、Edge、Firefox（macOS 145 / Windows 141 起）、Safari 26 全數預設啟用；同期 caniuse 統計全球瀏覽器支援率約 82%。換句話說，2026 開始談「網頁 3D」已經是兩條軌道：WebGL 是兜底相容，WebGPU 是上限。

WebGL 與 WebGPU 一頁對照

網頁 3D 物件能做到什麼程度？六種已上線在跑的真實場景

回到業主最想知道的那個問題。我們挑六個「已經有公司商用上線、不是 demo」的代表場景，從最常見的電商產品旋轉一路講到瀏覽器端 AI 推論。所有數字都附了外部來源，你看完就有判斷依據。

場景一：3D 產品旋轉與配置器（電商、家具、汽車）

最普及的應用。讓使用者在商品頁直接拖動產品、換顏色、換材質、看內部結構。Three.js 加 React Three Fiber 加上 GLB 檔，三個工程師兩週就可以做出第一版。重點在配套——Draco 壓縮 + KTX2 紋理才不會把首屏拖死。

數據怎麼說？ 根據 Envive 蒐集的 52 個電商轉換實驗，購物網站導入 3D 互動之後成交率最高可提升 40%、停留時間平均 +30%；Rebecca Minkoff 自家數據顯示「看過 3D 產品的人下單機率 +27%」。挪威家具品牌一個「旋轉 + 配色」小元件就把加入購物車率拉了 27%、停留 +2:14。

場景二：可拖拉的 3D 投影簡報式 Hero（品牌官網）

Apple、Tesla、Stripe 那種「滾動頁面、3D 模型跟著鏡頭轉」的視覺效果，背後通常是 Three.js + GSAP ScrollTrigger 或 React Three Fiber + Framer Motion。真正的關鍵在於「滾到哪、看到哪」這個節奏感——配合 lazy load 與骨架屏，可以做到首屏 LCP 2 秒內、又同時保有「掀蓋」式互動。我們最近接到的中型製造業官網改版，幾乎都會問這種版型，這是 2026 B2B 官網的主流型態之一。

場景三：可配置的 BIM / 工程模型（建築、製造、設備出租）

把整套 Revit / SketchUp 模型轉成 GLB 丟上瀏覽器，讓客戶不用裝 CAD 就能在線上看戶型、轉換樓層、量距離、勾選裝潢選配。住宅銷售中心、輕鋼結構廠商、辦公家具、實驗室設備這幾個產業是主要客群。實作上會把 Three.js 跟自家報價或 CRM 串起來，做到「客戶在 3D 上勾完選項自動產生報價單」。我們的 客製化網站與系統開發服務 就有不少這類案子——3D 在前面，後台是配色 / 配料規格庫與報價邏輯。

場景四：科學與醫療資料視覺化（體積渲染、地形、流場）

醫學影像 DICOM 直接在瀏覽器跑體積渲染（volume rendering）、地球科學的地形流場、半導體的晶圓視覺化——這些以前必須用桌面工具的場景，2025 之後因為 WebGPU compute shader 開始大量搬上瀏覽器。Babylon.js 6.0 已內建 WebGPU compute path、Three.js r171 起也支援同步雙軌。優點是雲端零安裝，缺點是對 GPU 等級非常敏感，必須做能力偵測與降級。

場景五：WebXR — 瀏覽器端 AR 試戴 / 試擺

WebXR 是把 AR / VR 帶進瀏覽器的標準。眼鏡品牌讓人用手機鏡頭預覽自己戴上去的樣子、家具品牌讓人把沙發放到客廳量尺寸，這些全部都是純網頁，沒有 App。Apple Vision Pro 自 visionOS 26 起原生支援 WebXR + WebGPU，等於把 spatial computing 直接接到網頁。對 B2B 來說，最常見的是「設備 / 機械投影到客戶廠房」——業務不用扛 demo 機，網頁打開就可以對著現場放。

場景六：瀏覽器端 AI 推論 / 即時影像處理

這條是最讓人意外的——WebGPU compute shader 讓瀏覽器可以原生跑 ONNX Runtime Web、TensorFlow.js、Transformers.js，本機就能跑 Llama 3.2 1B、Whisper Tiny、Stable Diffusion Turbo。對企業來說意義很大：醫療影像、保險現勘照片、合約 OCR 這類「資料不能離開公司」的場景，本來要自架 GPU server，現在客戶瀏覽器就能跑完。延伸閱讀我們之前整理過 瀏覽器端本地 OCR 完整教學 那篇，可以對照看。

三大主流框架怎麼挑：Three.js、Babylon.js、React Three Fiber 對照

選錯框架後面什麼都別談。三個主流選項各有自己擅長的場景，我們把實作這幾年的經驗整理成這張對照表——選的時候不是看誰最熱門，是看「你的團隊原生熟什麼、要做的場景複雜度落在哪一段」。

如果你公司技術棧已經是 React / Next.js（恆遠這幾年新案幾乎都這組），React Three Fiber 加上 @react-three/drei 是壓倒性最有效率的選擇：UI state 直接驅動 3D 場景，省掉 90% 的 imperative code。

WebGPU 才是 2026 的真正分水嶺——效能、AI 推論、機器學習都往瀏覽器搬

我們認為 WebGPU 才是這幾年網頁 3D 領域最重要的事件，比任何 framework 更新都重要。原因有三個。

Compute shader 把瀏覽器變成本機 GPU 平台

這是 WebGL 拿不到的能力。Compute shader 讓你可以把任意計算丟給 GPU 平行跑——粒子系統、布料模擬、流體、影像濾鏡、ONNX 推論、Transformer 模型 inference 全部都靠它。依 byteiota 的 2026 報告，同一段 ML 推論在 WebGPU 路徑上比 WebGL 快約 15 倍，部分 batch 場景甚至接近原生 Metal / Vulkan 的 70%。這意味著很多原本必須在後端 GPU server 上跑的工作可以直接搬到使用者瀏覽器——對「資料不出公司」的合規場景影響特別大。

Render Bundle 與 async pipeline 把首屏時間壓下來

WebGL 一次只能下一個 draw call、shader 編譯阻塞主執行緒，是高頻互動場景卡頓的最大兇手。WebGPU 把這兩件事拆掉：Render Bundle 一口氣下幾百個 draw、shader 編譯走 async pipeline，首屏 LCP 可以從原本的 3–5 秒壓到 1.2 秒以內。我們在 Core Web Vitals 治理指南 這篇詳細談過 LCP / INP / CLS 對 SEO 與轉換的真實影響——如果官網本來就跑不過 Core Web Vitals，3D 別硬上，先把基本盤治理好。

WGSL 把 GLSL 的「黑屏 bug」根因解決

做過 WebGL 的工程師都遇過 GLSL 編譯 error 出在 production、開發環境跑得好好的場景。WebGPU 改用 WGSL，型別在編譯期嚴格檢查，三家瀏覽器照同一份 spec 跑——這對「客戶帳號裡看不到、開發機正常」的玄學問題是直接的根因解。生產維運成本下降有感。

行動裝置才是真正的隱形殺手——效能、耗電、記憶體三條痛線

業主只要看到「能轉 360 度」就會想「我們公司網頁也來一個」。我們把這幾年踩過的行動裝置坑整理成這節——這裡的目的是先把預期值對齊，沒有要勸退誰：3D 在桌機跑得順，搬到手機可能整支發燙、電池五分鐘掉 10%，這是真的會發生的事。

痛點一：模型檔太大，首屏直接陣亡

原始 GLB 檔常常是 30–100 MB，4G 行動網路下載 30 秒起跳。解法是「上 production 前一定要壓」：

• Draco 壓縮：Google 開源的幾何壓縮，檔案縮小 90–95%、解壓在 Web Worker 不阻塞主執行緒
• KTX2 + Basis Universal 紋理：把貼圖從 PNG/JPG 壓成 GPU 原生格式，VRAM 用量降 80%、首屏加速 40%
• Meshopt：vertex stream 重排序，跟 Draco 互補，再省 10–20%
• gltf-transform pipeline：把上面三個串成一條 CLI，部署前自動跑

依 Krapton 整理的 2026 mobile 部署實務，加上 Draco + LOD 後，行動端 avatar 場景初始化時間下降 40%，FPS 從 20–30 拉到 45–55；再開 OffscreenCanvas 之後維持 60 FPS 不掉。

痛點二：行動 GPU thermal throttle 一定會發生

手機 GPU 其實夠強，問題出在「不能一直全力跑」。iPhone 15 Pro 的 A17 Pro 跑全特效 Three.js 場景大概 90 秒就會熱降頻，FPS 從 60 掉到 30；Android 中階機更短。對策是設計階段就要考慮：

• 用 quality preset：debug / battery saver / normal / high 四段，依裝置自動切
• 限制 max pixel ratio 為 2（很多手機是 3），單一這條 GPU 負載砍 1.5 倍
• 主動偵測 FPS < 45 就降畫質，不要等到使用者罵
• 互動結束後立刻 pause render loop（requestAnimationFrame 停掉），背景不耗電

痛點三：iOS Safari 的「靜音 autoplay 政策」會打中 WebXR

iOS Safari 對 motion sensor、camera、autoplay 的限制比桌面嚴格，部分 WebXR 操作必須是「使用者點擊事件之後」才能初始化。實作上要寫一個明顯的「開始 AR」按鈕、不能直接進場景——這是 2026 蘋果為了隱私加碼的政策，工程師必須要懂的眉角。

企業官網該不該做 3D？六個訊號告訴你值不值

我們不認同「網頁 3D 是未來、所有公司都該做」這種說法——對某些行業 3D 是真的拉轉換、對某些行業就是貴貴的裝飾。下面六個訊號是我們判斷的依據，命中三條以上就值得認真評估，沒中半條就先省下這筆預算改去做別的。

反過來，這幾種情況不建議做 3D

• 服務型業務（顧問、會計、律師、行銷代理）——產品是「人」與「方法論」，3D 沒有著力點
• 純內容型網站（部落格、媒體、線上學習）——3D 拖慢 LCP 反而會傷 SEO 跟轉換
• 預算非常緊張的初創——3D 一個產品配置器報價落在 NT$25 萬到 80 萬，預算 < 50 萬建議全押在內容、廣告、SEO
• 技術團隊很小、沒有 maintenance 能量——3D 不是上線就結束，模型更新、新瀏覽器 bug 修正都需要持續顧

怎麼挑廠商：5 條合約紅線 + 3 個驗收里程碑

如果你已經確定要做、要找外包，下面這節是我們在客戶案件裡踩過的雷整理出來的。網頁 3D 的廠商良莠不齊，傳統網頁設計公司跟特效 / motion graphics 工作室都在接這類案子，但兩者的技術深度差很多——光看 portfolio 上的影片其實看不太出來，要看程式碼。延伸閱讀 企業官網設計外包採購完整指南 裡有更完整的官網外包視角，這節我們聚焦 3D 特化的部分。

5 條合約紅線

3 個驗收里程碑（M1/M2/M3）

• M1 — 技術原型驗證（簽約後 2–3 週）：用「真實的」一個 SKU 的 3D 模型上瀏覽器，跑得動、抓 FPS 數據。M1 過不了，現在止損還來得及。
• M2 — 全量資產 + 效能調校（M1 後 4–6 週）：所有 SKU 上線、Draco / KTX2 壓過、Lighthouse 性能分數 ≥ 80。這時候才可以付第二期款。
• M3 — 上線後 30 天觀察（M2 後 4 週）：用 Real User Monitoring 看真實流量的 FPS / LCP / 互動完成率，達標再付尾款。沒這條，廠商上線就跑路、出問題找不到人。

常見迷思破解與選擇建議

迷思一：3D 一定會拖慢 SEO

不一定。WebGL / WebGPU 元件只要做 lazy load + 預設 fallback 為靜態圖（Next.js 的 dynamic + ssr:false 是標配），對 Core Web Vitals 影響可以控制在 100ms 以內。真正會拖慢的是「全頁面強制等 3D 載完才顯示內容」——這是設計選擇，不是 3D 本身的鍋。

迷思二：iPhone 跑不動就放棄行動端

錯。iPhone 12 之後對 WebGL / WebGPU 支援都不錯，問題在於設定預設值——很多開發者用桌機等級的解析度跟特效，當然會跑不動。把 max pixel ratio 限制到 2、shadow map 從 2048 改成 1024、後製 bloom 關掉，中階 iPhone 跑 60 FPS 沒問題。

迷思三：要用最新的 WebGPU，舊用戶看不到沒關係

B2B 場景特別要小心這條。製造業、營造業、學校單位、政府機關常常還在用 IE 後遺症留下來的 Chrome 90、Edge legacy——這些用戶看不到 WebGPU。Three.js / Babylon.js 的 fallback 機制是 production 的保險，不是可選項。

迷思四：找做特效的工作室一定做得最炫

會做特效不等於會做 production web 3D。特效工作室強在「視覺概念 + 短期 demo」，但對 LCP、accessibility、SEO、跨瀏覽器 fallback、長期維運的訓練通常比較少。前者拿來做品牌活動或廣告 microsite 沒問題，要做要長期跑五年的官網主軸建議找有 production web engineering 訓練的團隊，或兩者協作分工。

如果你正在評估官網改版要不要把 3D 排進去、或想知道你公司的產品適合走哪一條技術路線，可以把現況丟過來——範圍多大、預算多少、目前官網跑得怎樣，我們會直接告訴你「值不值得做、怎麼做最划算」。先聊聊現況再談範圍跟費用，這個階段我們陪你想。也歡迎看我們的 客製化網站與系統開發服務頁、或 AI 顧問服務，了解我們做過的範圍。

最後再強調一次：3D 真正的價值不在炫，而在「用在對的節點才會改變成交」。如果你還在想自己公司適不適合，我們很樂意聽你聊聊現況；如果已經有明確需求要落地，可以從 官網改版採購完整指南 看起，再對著上面 5 條合約紅線跟 3 個里程碑去談價就好。