店家網站很慢怎麼辦：Core Web Vitals 三項指標與檢查方法

顧客在 Google 地圖上看到你的店，點進官網，結果白畫面轉了好幾秒；或是正要按「預約」，版面突然往下跳，按到了別的地方。這些體驗，Google 用一組叫做 Core Web Vitals 的指標來衡量。這篇用 web.dev 與 Google 搜尋中心的官方說明，解釋三項指標各自代表什麼、「良好」的門檻是多少、要用哪些工具檢查，最後整理小型店家網站最常見的拖慢原因與修法。先說結論：速度很重要，但它是眾多信號之一，不會取代內容本身。

三項指標與官方門檻

Core Web Vitals 目前包含三項指標，分別衡量載入、互動回應與版面穩定。Search Console 說明中心列出的分級如下：

指標	衡量什麼	良好	需要改善	不佳
LCP（最大內容繪製）	主要內容多快顯示	≤ 2.5 秒	≤ 4 秒	> 4 秒
INP（與下一個繪製的互動）	點擊、觸碰、按鍵後多快有反應	≤ 200 毫秒	≤ 500 毫秒	> 500 毫秒
CLS（累計版面配置位移）	畫面是否突然跳動	≤ 0.1	≤ 0.25	> 0.25

web.dev 說明，評估時看的是網頁載入的第 75 個百分位數，並把手機與電腦分開計算。意思是：不是看你自己用公司網路打開有多快，而是看大多數真實訪客（包括網路較慢、手機較舊的人）的體驗。三項都達到良好，才算通過。

LCP：最大的那塊內容多久出現

依 web.dev 定義，LCP 回報的是可視區域內最大的圖片、文字區塊或影片完成繪製的時間，從使用者開始前往這個網頁起算。可能被當成 LCP 的元素包括 img 圖片、svg 裡的 image、影片（看封面圖或第一個畫面）、用 url() 載入背景圖的元素，以及含文字的區塊元素。店家網站的 LCP 元素，通常就是首頁最上方那張大圖或輪播圖。

INP：按下去之後多久有反應

INP 只觀察三種互動：滑鼠點擊、觸控螢幕點按與按鍵；滑過、捲動、縮放不算。web.dev 說明最終數值是觀察到的最長互動時間，並排除極端值。INP 是 FID（首次輸入延遲）的後繼指標，web.dev 公告它在 2024 年 3 月 12 日正式取代 FID 成為 Core Web Vitals。差別在於 FID 只看第一次互動的延遲，INP 涵蓋整個瀏覽過程中的所有互動。

CLS：版面有沒有突然跳

CLS 衡量的是「非預期」的版面位移：可見元素在兩個畫面之間改變位置，就算一次位移。web.dev 說明，CLS 取的是位移分數最大的一段「工作階段視窗」，視窗內每次位移間隔不到 1 秒、整段最長 5 秒；使用者點擊或按鍵後 500 毫秒內發生的位移會被標記排除，因為那是使用者預期中的變化。常見原因包括沒有設定尺寸的圖片或影片、比備用字型大或小的網頁字型，以及會自己改變大小的第三方廣告或小工具。

Core Web Vitals 跟排名的關係

Google 搜尋中心寫明，強烈建議網站擁有者在 Google 搜尋中獲得良好的 Core Web Vitals，它和網頁體驗的其他層面一樣，是核心排名系統的考量要素。但同一組文件也說得很清楚：

• Google 搜尋會盡可能顯示最相關的內容，即使網頁體驗差強人意。
• Google 不會只考量單項信號，核心排名系統會參考多種信號。
• Core Web Vitals 報表表現良好，不代表網頁就會取得優先排名。
• 在很多網頁都有實用內容的情況下，良好的網頁體驗有助於取得理想排名。

對店家來說，正確的心態是：先確定網站有回答顧客的問題（服務、價格、地點、預約方式），再把速度修到「良好」，讓好不容易點進來的顧客不會因為等太久而離開。網站內容該有哪些頁面，可以對照店家官網必備頁面檢查表。

檢查方法一：PageSpeed Insights

PageSpeed Insights 是 Google 提供的免費網頁工具，輸入網址就能測試。報告分成兩部分，看懂差別很重要：

區塊	資料來源	用途
Core Web Vitals 評估（上方）	Chrome 使用者體驗報告（CrUX）的真實使用者資料，涵蓋過去 28 天	判斷實際訪客的體驗是否達標
效能分數與診斷（下方）	Lighthouse 在受控環境的模擬載入；手機版模擬中階手機與行動網路	找出拖慢的原因、改完立即重測

官方說明的幾個細節：

• 網址本身的樣本不夠時，會改顯示整個來源網域的資料；網域也不夠時，就不會顯示真實使用者資料。
• 三項指標資料都足夠時，INP、LCP、CLS 的第 75 個百分位數都是良好才算通過；INP 資料不足時，看 LCP 與 CLS。
• Lighthouse 效能分數 90 到 100 為良好、50 到 89 為需要改善、50 以下為不佳。實驗室數值與真實資料本來就可能不同，不需要期待兩邊一致。

檢查方法二：Search Console 的 Core Web Vitals 報表

如果網站已經驗證 Search Console，可以在左側選單找到 Core Web Vitals 報表。依 Search Console 說明中心：

• 資料同樣來自 CrUX 的實際使用資料，手機與電腦分開呈現。
• 體驗相似的網頁會被分成同一個網址群組，群組狀態套用到裡面所有網址。
• 群組狀態取決於表現最差的那項指標：例如 CLS 不佳、LCP 需要改善，整組就顯示不佳。
• 修正後可以在問題詳細資料頁點「開始追蹤」，系統會啟動 28 天的監控期，期間內仍有網址出現問題就會標示為未修正。
• 資源太新或資料量不足時，報表會顯示「目前沒有資料」。

來客量不大的店家網站，常常在 Search Console 看不到資料，這不代表網站有問題，只是樣本不夠。這時就以 PageSpeed Insights 的實驗室測試為主。

小型店家網站最常見的拖慢原因與修法

店家網站通常頁面不多、功能單純，速度問題大多集中在下面幾類，不需要整站改版就能處理。

圖片：最常見的 LCP 元兇

Google 圖片搜尋最佳做法提到，圖片通常占網頁大小的大部分。手機直接拍的照片動輒數 MB，放上網站前一定要處理：

• 縮小尺寸：依實際顯示寬度輸出，不要把相機原圖直接上傳。
• 壓縮與換格式：web.dev 建議改用 WebP 或 AVIF 等較有效率的格式來縮小檔案；Google 搜尋也支援這兩種格式。
• 提供不同尺寸：用 srcset 或 picture 讓手機下載較小的版本，並保留一般的 src 作為備援。
• 寫上寬高：web.dev 建議每張 img 都設定 width 與 height，讓瀏覽器預留空間，避免 CLS。

延遲載入：只延遲畫面外的圖片

在 img 加上 loading="lazy"，瀏覽器會等圖片快進入畫面才下載，適合用在作品集、菜單照片這類往下捲才看到的圖。但 web.dev 特別提醒，絕對不要延遲載入 LCP 圖片，那只會讓主圖更晚出現。首屏主圖維持正常載入，可以加上 fetchpriority="high" 提高優先順序，但不要每張圖都加，否則就失去作用。

字型：中文網頁字型特別大

web.dev 的字型最佳做法指出，中日韓字型可能包含超過 10,000 個字元，最佳化特別困難。店家網站可以這樣處理：

• 內文直接用系統字型，只有店名或標題才用特殊字型。
• 網頁字型使用 WOFF2 格式，並做字集子集化，只保留用得到的字。
• 設定 font-display：swap 讓文字最快顯示，optional 則可避免字型替換造成的位移；用 size-adjust 讓備用字型尺寸接近網頁字型，減少 CLS。
• 盡量少用字型種類與字重，每多一個檔案就多一次下載。

第三方嵌入：影片、聊天、社群小工具

首頁嵌入 YouTube 影片、線上客服聊天視窗、社群貼文牆，都會在載入時下載大量外部程式。Chrome for Developers 的說明建議使用「門面」（facade）做法：先放一個外觀相似的靜態圖片，使用者點擊後才載入真正的嵌入內容，影片、社群按鈕與聊天小工具都適用；代價是有些功能（例如影片自動播放）可能無法正常運作。同理，嵌入地圖也是外部內容，聯絡頁可以考慮改用靜態地圖圖片加上「在 Google 地圖開啟」的連結。另外，web.dev 也提醒 head 裡幾乎沒有必要放同步載入的 script，追蹤碼與外掛能刪就刪、能延後就延後。

主機與轉址：前端改不了的部分

web.dev 把 LCP 拆成四段，第一段是伺服器回應第一個位元組的時間（TTFB），後端還沒回應，前端什麼都做不了。主機太慢、多層轉址（例如 http 轉 https 再轉 www）都會拖慢每一項指標。使用 CDN 讓內容從離訪客較近的位置傳送、減少不必要的轉址，是官方建議的方向。

症狀對照表：先修哪一項

你看到的症狀	可能原因	先做什麼	影響指標
首頁主圖要好幾秒才出現	圖片太大、被設成 lazy、輪播圖太多張	壓縮主圖、改成正常載入、輪播減到一張	LCP
文字先是空白，過一下才出現	中文網頁字型太大	內文改系統字型、設定 font-display	LCP、CLS
捲動時按鈕位置一直跑	圖片沒寫寬高、廣告或嵌入內容晚出現	補 width／height、替嵌入區塊預留高度	CLS
按「預約」要等一下才有反應	外掛與追蹤碼太多、主執行緒忙碌	移除不用的外掛與第三方程式	INP
每一頁都慢，連空白頁也慢	主機回應慢、多層轉址	檢查主機方案與轉址設定	全部

常見誤解

「PageSpeed 100 分才會排前面」

效能分數是實驗室模擬，用來找問題；排名看的是眾多信號，Google 也說明會優先顯示最相關的內容。把三項指標修到良好之後，時間更值得花在內容上，例如照店家 SEO 文章的 7 個步驟寫出顧客真正想看的頁面。

「網站慢就要整個重做」

多數店家網站的問題是幾張大圖、一兩個外掛，修掉就有明顯改善。真的需要換架構時，才考慮重做，選擇方式可以看一頁式網站與形象網站比較。

「電腦上很快就沒問題」

手機與電腦是分開評估的，而官方門檻看的是第 75 個百分位數的訪客。用自己的新手機加上店裡的 Wi-Fi 測，看不到大多數顧客的真實狀況。

需要協助的時候

如果你的網站是很多年前做的，圖片、字型、外掛層層疊加，自己找原因很花時間。捷萊的店家網站方案包括店家一頁式網站（NT$35,000 一次性）與形象網站（SEO 架構，NT$65,000 一次性），適合想重新整理網站內容與架構的店家；只想先修速度的話，也可以先照上面的症狀對照表逐項處理。網站速度只是在地曝光的一環，商家檔案與地圖排名的部分，可以參考在地 SEO 與地圖排名服務。