網站速度就是轉換率：Core Web Vitals、圖片、快取到 CDN 的提速路線圖

先講結論：網站速度不是加分題，而是轉換率的地板。你的商品力、素材、促銷方案，全都建立在「頁面打得開、按鈕按得動」這個前提上。頁面慢，前面所有努力一律打折；頁面快，同樣的流量就能多接住一批原本會默默流失的訂單。這篇文章我會把速度優化拆成一條可以照做的路線圖：先用 Core Web Vitals 建立量測基準，再依「圖片、快取、CDN、第三方腳本」的順序動手，最後把整件事收斂成每個月固定執行的營運例行公事，而不是出事才救火的工程專案。

我每天在 ECPRO 掃描台灣大量網站的技術組成與流量訊號，有個現象反覆出現：同一個產業、用同一套開店系統的兩個站，流量級距差不多，體質卻可以差一大截，而拉開差距的變數裡，載入速度幾乎每次都榜上有名。更麻煩的是，速度差的站自己通常不知道——老闆和員工天天用辦公室網路開自家官網，永遠感受不到消費者在捷運上、用四年前的手機開你商品頁的真實體感。速度問題就這樣藏在「我自己看都很快啊」的錯覺底下，一天一天吃掉營收。

漏斗的第一層不是商品頁，是「頁面成功載入」

大多數品牌畫轉換漏斗，第一層都從商品頁瀏覽開始畫。但真正的第一層其實更前面：頁面有沒有在消費者失去耐心之前載入完成。這一層漏掉的人，幾乎不會留下任何行為紀錄——沒有加入購物車、沒有瀏覽事件、有時連工具都來不及記到這次造訪。你在報表上看到的，只是一個莫名偏高的跳出率，以及一個怎麼調受眾、換素材都拉不動的廣告成效。

速度的殺傷力還會層層放大。搜尋引擎把頁面體驗納入排名考量，慢站的自然流量會被慢慢磨掉；廣告平台評估落地頁品質時，載入體驗差的站要用更高的出價才能買到同樣的曝光；而好不容易進站的人，又有一部分在互動卡頓中放棄結帳。等於同一個病灶，同時對自然流量、付費流量、站內轉換三個引擎放血。反過來說，速度也是少數「改一次、三條線同時受惠」的槓桿，這是我把它排在多數優化項目前面的原因。

Core Web Vitals：三個數字，對應三種離開的理由

要管理速度，得先有共同的量尺，業界目前的標準答案就是 Core Web Vitals。它的價值在於三個指標各自對應一種消費者「離開的理由」，你可以直接把它讀成行為語言：

用行為語言翻譯一次：LCP 差，消費者的感受是「還沒看到商品就不想等了」；INP 差，是「按了加入購物車沒反應，再按一次還是沒反應，算了」；CLS 差，是「正要點規格，版面突然跳動害我點到別的地方」。三種都指向同一個結局——離開，但成因與解法完全不同，所以不能只籠統喊「網站要變快」，要分開量、分開治。

量測上我建議兩套並行：測試工具（例如 PageSpeed Insights 這類）跑出來的是模擬環境分數，適合用來定位問題與驗證修改；Search Console 裡的實際使用者體驗資料，才是真實消費者在各種網路與裝置條件下的成績。前者是聽診器，後者是健檢報告，只看其中一種都會誤判。我看過不少站測試分數漂亮，但真實數據長期不及格，原因是它的客群手機舊、網速慢，模擬環境根本模擬不出來。

圖片與影音：多數慢站的第一病灶

依我在 ECPRO 看技術快照的經驗，行動版速度不及格的電商站，絕大多數第一個病灶都在圖片。電商靠視覺賣貨，圖多是宿命，但「圖多」和「圖肥」是兩回事。攝影師交付的原始檔動輒數 MB，直接上傳到商品頁，一個首屏就要消費者下載十幾 MB，再好的網路也撐不住尖峰時段的行動連線。處理順序我建議這樣排：

• 先換格式：全站改用 WebP 或 AVIF 這類現代格式。同樣視覺品質下，檔案通常能省下三成以上，是所有速度優化裡投入最少、回收最快的一步。
• 再給對尺寸：列表縮圖只顯示幾百像素寬，就不該讓瀏覽器下載兩千像素的原圖再硬縮。用響應式圖片依裝置出圖，手機拿小張、桌機拿大張，別讓使用者付費下載看不到的像素。
• 然後延遲載入：捲動到才載入，首屏以外的圖全部延後。但有一個關鍵例外——首屏主圖（通常就是 LCP 元素）絕對不能延遲，反而要標成最高優先，不然 LCP 會不降反升。
• 最後預留空間：每張圖標好寬高或比例，讓瀏覽器先把版位框住，圖片載入時版面就不會跳，CLS 直接受惠。

影音同理：自動播放的商品影片、背景動態，都要問一次「它帶來的轉換價值，付得起它吃掉的載入時間嗎」。答案常常是否定的。

快取要分層設計，失效機制比命中率更重要

圖片解的是「東西太重」，快取解的是「同樣的東西被重複搬運」。快取要分層想：最外層是瀏覽器快取，讓回訪客不必重新下載沒變過的靜態資源——樣式、字型、程式、商標圖，這些檔案配上長效期加檔名版本號，回訪的載入體驗會跟第一次完全不同水準，而電商偏偏是回訪率越高越賺錢的生意，這層價值常被低估。

往內一層是頁面快取：商品頁、分類頁這種人人看到內容相同的頁面，預先產生好存起來，不必每個訪客都讓伺服器與資料庫重算一輪。但電商有一個不能踩的地雷——購物車、會員、結帳這類人人不同的頁面，絕不能整頁快取，否則會發生把別人的購物車顯示給另一個人的事故。正確的架構是動靜分離：商品資訊走快取，個人化區塊獨立即時載入。

而快取設計裡最容易被忽略、卻最常釀禍的是失效機制。改了價格、上了新檔期、商品完售，前台若還供應舊快取，輕則客訴，重則變成消費爭議。所以快取策略必須跟營運節奏綁定：什麼動作要清哪些頁的快取，要有明確的規則與自動化，而不是靠人記得去按清除。我的判斷標準是——一個快取方案的好壞，先看它失效做得乾不乾淨，再看它命中率高不高。

CDN：把距離變短，把尖峰接住

CDN 的原理一句話講完：把靜態資源複製到離消費者更近的節點，就近供應，距離短、延遲低。但它對台灣電商的意義不只有日常速度。第一是主機位置的解耦——不少品牌的主機或開店平台機房在海外，沒有 CDN 的話，台灣消費者每個請求都得跨海往返。第二是檔期承載：雙 11、週年慶、開賣瞬間的流量尖峰，讓 CDN 吃掉靜態資源的請求，主機才有餘裕專心處理下單、金流、庫存這些真正需要即時運算的事，開賣即當機的風險會低很多。第三是基本防護，主流 CDN 服務通常附帶擋掉部分惡意流量的能力。

導入時的核心功課只有一件：分清楚哪些請求該走 CDN、哪些必須即時回源。靜態資源盡量全上，動態請求老實回源，別為了追求快取命中率把不該快取的東西也快取了，那是拿正確性換速度，電商賠不起。如果你的客群橫跨台灣與海外，CDN 更是從「建議」升級成「必備」，因為你不可能在每個市場都放一台主機。

第三方腳本堆疊症候群：每一支外掛都在向速度收租

我在 ECPRO 看站的技術組成時，常看到一種我私下叫「堆疊症候群」的狀態：分析工具兩三套、廣告像素好幾支、聊天外掛、彈窗工具、熱點錄影、再行銷代碼……每一支裝的當下都有理由，但沒有人負責退場。這些腳本共同競爭瀏覽器的主執行緒，INP 就是這樣被拖垮的——消費者按下加入購物車，瀏覽器卻正忙著執行某支根本沒人在看報表的追蹤碼。

治理方法不難，難在有人願意做：每季盤點一次全站腳本，每支回答三個問題——誰在用它產出的資料、拿掉會少什麼、能不能延後或用更輕的方式載入。答不出第一題的直接移除。另外兩個常被漏掉的前端項目：自訂字型要設好載入策略，避免文字先隱形後突然跳字體，那會同時傷 LCP 與 CLS；渲染順序上，把消費者最先要看、要按的內容排最前面送出，行銷彈窗、推薦模組、客服視窗晚一兩秒出現，沒有任何消費者會抱怨。

匿名案例：三十天把一個行動版慢站救回來

說一個去識別化的實例。一個經營服飾配件的品牌來問我為什麼廣告成本一直墊高，我先不看廣告帳戶，先看速度數據：行動版 LCP 落在五秒多，INP 也在不及格區。換句話說，他們付費買進來的行動流量，有相當比例的人在頁面可用之前就離開了，廣告帳戶怎麼調都調不回來，因為問題根本不在廣告。

我們排了三十天的處理節奏。第一週處理圖片：全站轉現代格式、補響應式尺寸、首屏主圖改最高優先、其餘延遲載入。第二週整快取：商品頁與分類頁上頁面快取，配好改價與上架的自動失效規則，個人化區塊拆出來即時載。第三週把靜態資源全部上 CDN。第四週盤點腳本，移除了幾支早已沒人看的追蹤工具，聊天外掛改成延遲初始化。全程沒動任何一檔廣告、沒改任何商品。

一個多月後回看真實使用者數據，行動版 LCP 進入良好區間，加入購物車率與結帳完成率都往上走了一個明顯的級距——不是因為流量變多，而是原本漏掉的流量被接住了。同樣的廣告預算，接得住的訂單變多，投報率自然回升。這個案例我常拿來講一個順序觀念：在加碼流量之前，先確認你的站接得住流量，不然預算加得越多，漏得越多。

把速度變成每月例行指標，而不是年度專案

速度優化最大的敵人不是技術難度，是「做完一次就以為結束」。網站會持續上新功能、裝新工具、換新版型，每一次改動都可能讓速度悄悄退步，所以它必須是節奏，不是專案：

1. 每月固定看一次真實使用者的核心指標趨勢，只看趨勢方向，不糾結單次分數。
2. 任何較大改版或新增第三方工具，上線前後各測一次，變慢就要有人說明代價是否值得。
3. 旺季前一個月做完整健檢，重點驗證快取與 CDN 能不能扛住預期尖峰。
4. 每季盤點一次第三方腳本，強制退場沒有使用者的工具。

負責人也不該只有工程端。速度直接連動營收，營運端要一起盯，因為很多讓網站變慢的決定——多掛一支像素、首頁再加一排輪播——都是營運端做的。讓做決定的人看得到決定的速度代價，這套節奏才轉得動。

最後收束一句：速度是你花錢買來的每一個點擊能不能變成訂單的前提。Core Web Vitals 給你量尺，圖片、快取、CDN、腳本治理給你施力點，每月節奏讓成果不回退。在下一次提高廣告預算之前，先把這個桶子的洞補上——這通常是你手上投報率最高的一筆投資。