網站明明有流量，卻留不住人？問題很可能出在 Core Web Vitals。這不只是速度指標，而是直接影響排名與轉換的關鍵。本篇帶你用最實務的方法，快速找出問題並優化，讓網站不只被看見，更能留下用戶、提升成效。
Core Web Vitals 是什麼？搞懂這3個指標績效最佳化
Core Web Vitals（網站體驗核心指標） 是 Google 用來評估網站「使用者體驗」的三大指標，直接影響 搜尋引擎優化（SEO）排名與使用者留存。重點不是技術分數，而是網站對使用者「快不快、順不順、穩不穩」。
Core Web Vitals 三大指標在看什麼？
- LCP（載入速度）
衡量「主要內容多久出現」，建議在 2.5 秒內完成，太慢使用者會直接離開。 - INP（互動反應）
衡量「點擊後多久有反應」，建議低於 200 毫秒，避免卡頓感。 - CLS（畫面穩定）
衡量「畫面會不會亂跳」，建議低於 0.1，避免誤點或體驗差。
為什麼Core Web Vitals會影響SEO排名
Google從2021年起正式將Core Web Vitals嵌入搜尋排名算法，使用者體驗已成為SEO不可忽視的一環。簡單來說，Google 希望排名靠前的網站，不只是內容好，用起來也舒服。
如果兩個網站內容旗鼓相當，體驗分數上面的往往更有優勢。
另外，Core Web Vitals也直接影響跳出率與停留時間。載入慢、操作卡、畫面亂跳的網站，用戶會直接離開，這些行為訊號同樣對排名不利。
多少分才算好？ Core Web Vitals 評分標準解析
Google將指標各分為三個等級，讓你快速判斷當前狀況是否達標。
LCP：
- 良好 ≤ 2.5 秒
- 需改善 2.5～4 秒
- 不良 ＞ 4 秒
INP：
- 良好 ≤ 200 ms
- 需改善 200～500 ms
- 不良 ＞ 500 ms
CLS：
- 良好 ≤ 0.1
- 需改善 0.1～0.25
- 不良 ＞ 0.25
達到「良好」區間，才算透過 Google 的體驗權益。建議優先處理標示為「不良」的指標，再逐步精進其他部分。
＊SEO最關鍵的一個觀念，Google 是用「真實使用者數據的 75%」來判定：
- 至少 75% 使用者體驗達標，才算通過 Core Web Vitals
如何快速偵測Core Web Vitals？先找問題再優化
使用Google PageSpeed Insights一鍵看網站速度
PageSpeed Insights是最快入手的免費工具，只需貼上網址即可取得分析報告。
報告會同時顯示使用者實際數據（現場數據）與模擬測試結果（實驗室數據），讓您掌握真實狀況與技術細節。建議行動版與桌面版要分開偵測，因為兩者的問題點往往不同。
使用Google Search Console查找真實用戶數據
PageSpeed Insights 測算的是單頁，Search Console 則可以看到整個網站的實際體驗資料。
進入 Search Console 後，點選左側選單的「體驗 → 網站使用體驗核心指標」，可以看到哪些頁面被標記為待改善或差。這些數據來自真實用戶的 Chrome 瀏覽記錄（CrUX），比模擬測試更有參考價值。
利用Lighthouse深入分析技術問題
Lighthouse 是 Chrome 內建的開發者工具，能提供大量詳細的技術診斷報告。
開啟方式：按F12→選擇Lighthouse分頁→點選分析頁面載入。報告會列出具體的最佳化建議，例如「刪除未使用的JavaScript」或「延遲載入離螢幕圖片」，非常適合開發者或有技術背景的人深入使用。
LCP優化怎麼做？讓網站載入速度明顯變快
LCP（Largest Contentful Paint）代表「畫面主要內容出現的速度」，也是 Core Web Vitals 中最影響體感速度的指標。Google 建議 2.5 秒內完成，否則使用者很容易直接離開。
降低伺服器回應時間（TTFB）
TTFB（Time to First Byte）是伺服器接收請求後、回傳第一位元組所需的時間，是 LCP 的起點。 TTFB 越慢，LCP 幾乎不可能達標。
以下幾個方向能有效降低TTFB：
- 升級主機方案，選擇足夠穩定的主機商
- 啟用伺服器端快取（如Redis、Varnish）
- 使用CDN（內容分發網路）分散流量，降低地理位置帶來的延遲
- 優化資料庫查詢，減少前台處理時間
圖片壓縮與格式優化（WebP、AVIF）
圖片是拖慢LCP最常見的元兇，尤其是首屏的主大圖。現代格式WebP比JPEG平均小25–35%，AVIF更可壓縮至原始大小的一半，同時保持相近畫質。建議優先將首屏圖片轉換為這些格式，其他圖片也可以逐步跟進。
使用WordPress可穿透Imagify、ShortPixel等外掛自動換檔壓縮，無需手動處理每張圖。
關鍵資源預載（Preload）設定技巧
預先載入讓瀏覽器提早下載 LCP 必需的資源，不用等到解析 HTML 才發現它。
在<head>中加入以下語法，告知瀏覽器優先抓取首屏大圖：
html
<link rel=”preload” as=”image” href=”/hero-image.webp”>
字型也很適合使用預先載入，避免因字型載入延遲而影響畫面傳輸時間。但要注意不要過度使用，預載過多資源反而會競爭頻率。
減少 CSS 和 JavaScript 的渲染阻塞
瀏覽器解析 HTML 時，如果遇到未加上async或defer的<script>標籤，會暫停渲染等待腳本執行，直接拖慢 LCP。
優化方式如下：
- JavaScript 新增defer或async屬性，避免阻塞渲染
- 將非關鍵CSS延遲載入（Critical CSS內嵌，其餘非同步）
- 刪除頁面上未使用的 CSS 和 JS 程式碼
- 縮小（Minify）CSS、JS文件，減少傳輸大小
INP優化重點是什麼？讓網站操作更順不卡
INP（Interaction to Next Paint）其實就是在看「使用者點擊之後，畫面多久有反應」。而且它不是只看第一次操作，而是觀察整個使用過程中最慢的一次互動，來判斷網站到底順不順。
減少 JavaScript 執行時間
INP高通常代表主執行緒（Main Thread）被大量JavaScript佔用，導致使用者的操作無法及時回應。
首先用Chrome DevTools的效能分頁記錄互動過程，找出執行時間過長的函數。補充可以：
- 刪除不再使用的 JS 套件
- 以簡單的 JavaScript 取代重的 jQuery 功能
- 延遲載入非必要的腳本
拆分長任務避免互動延遲
當 JavaScript 執行過多超過 50ms 的「長任務（Long Task）」時，瀏覽器主執行緒會被長時間占用，導致無法即時回應使用者操作，進而讓 INP 明顯升高。
實務上，INP 過高的主要原因通常來自 JavaScript 執行時間過長、阻塞主線程，讓使用者出現「點了但沒反應」的延遲體驗。
善用緩存提升操作度
快取允許重複存取的使用者直接從本地或 CDN 取得資源，大幅減少需要重新破壞的工作量。
- 設定合理的Cache-Control標頭，讓靜態資源長時間緩存
- 使用 Service Worker 實施離線緩存，提升回訪時的操作流暢度
- WordPress使用者可使用WP Rocket或W3 Total Cache實現快速緩存功能
這些常見問題正在拖慢您的核心網路生命週期
第三方追蹤碼影響太大了
很多網站為了行銷分析需求，同時安裝了多個追蹤工具，如GA4、GTM、Hotjar、Meta Pixel、LINE Tag等。
每個工具都會引入額外的 JavaScript，下來累積對主執行緒的影響相當可觀。建議定期檢視安裝的追蹤碼，淘汰不再使用的工具，並透過GTM統一管理，減少直接寫入HTML的腳本數量。
圖片未壓縮導致載入變慢
這是最常見、也是最容易修復的問題。許多網站上傳圖片時直接使用原始大小，動不了3-5 MB，嚴重拖累LCP。
建立一套標準的圖片上傳流程是最有效的解方：
- 上傳前先壓縮至合理大小（一般內文圖約150KB以內）
- 使用 WebP 或 AVIF 格式取代 JPEG/PNG
- 取消loading=”lazy”延遲載入非主畫面圖片
伺服器故障影響整體速度
選擇了完全不足的主機方案，即使前端優化再努力，TTFB也難以壓低。共享主機在流量高峰時資源爭奪嚴重，建議評估是否升級至VPS（虛擬私人伺服器）或雲端主機（如AWS、Google Cloud）。同時搭配Cloudflare等CDN服務，能有效分散全球流量並加速回應。
前端架構設計不良造成卡頓
有時問題程式不在伺服器中，而是前端碼本身寫法有問題。
常見的問題包括：渲染時觸發過按鈕排（回流）、事件監聽器未適當移除造成記憶體流失、單頁應用（SPA）首次載入捆綁過大等。此類問題需要有經驗的前端工程師透過DevTools效能分析，從架構層面著手改善。
行動版 Core Web Vitals 更重要？優化關鍵如下
現在做 Core Web Vitals，行動版真的更重要，而且更難做好。原因很簡單：手機的網路不穩、效能較弱、使用情境更急，任何卡頓都會被放大。像 INP 這種互動指標，行動版表現甚至可能比桌機差上好幾倍。
行動裝置載入速度優化
Google搜尋採用行動優先指數（Mobile-First Indexing），代表行動版的體驗分數對SEO的影響更為關鍵。
行動裝置的網路環境與硬體完成通常不如桌機，優化標準要更嚴格。建議優先確保行動版LCP在2.5秒以內，並針對行動連線特性最佳化資源大小。
RWD響應式設計調整重點
響應式設計不只是「版本面能縮小」，還要確保行動版本身的元素配置不會引發 CLS。
需要特別注意的細節：
- 確定所有圖片在行動版都有設定寬高比
- 避免在行動版使用不同尺寸的廣告，造成裝備空間不符合
- 選單、按鈕的互動區域要達到大，降低誤觸後重新操作的延遲
減少行動端資源負擔
操作用戶通常在 4G 甚至 3G 環境下瀏覽，傳輸資源更大，等待越久。
幾個針對行動版的具體建議：
- 針對性行動版提供更小尺寸的圖片（使用<picture>標籤搭配srcset）
- 評估是否在行動版無效部分動畫或重型視覺效果
- 使用 AMP（加速行動頁面）或輕量級框架作為行動版解決方案（視情況評估）
Core Web Vitals 常見問題FAQ
1. 為什麼 Core Web Vitals 分數會突然變差？
因為這些數據來自真實使用者環境，網站只要有內容更新、圖片變多、外掛增加或廣告載入，都可能影響速度與穩定度，因此分數會持續波動，而不是固定不變。
2. 多久需要檢查一次 Core Web Vitals？
建議至少每月固定檢查一次 Google Search Console 與 PageSpeed Insights，因為Google是以長期數據（75%使用者體驗）來判斷表現，持續監測才能提早發現問題並修正。
3. Core Web Vitals 只影響技術SEO嗎？
不是，它影響的是整體使用者體驗，因此包含內容設計、圖片大小、頁面結構與行銷活動頁都會影響分數，應該由內容、設計與技術團隊共同優化，而不是只交給工程處理。
