網站速度會影響 SEO，原因有兩層。第一層是直接的：Google 已將頁面體驗納入排名訊號，其中最具體的就是 Core Web Vitals。當兩個頁面的內容相關性相近時，速度與體驗較好的那一個會更有優勢。第二層則是間接但同樣重要：速度差的網站會讓使用者失去耐心。研究普遍顯示，頁面載入每多一秒，跳出率就明顯上升。當使用者點進來又快速退出，這種行為訊號長期下來也不利於排名。
值得釐清的是，速度並非「越快排名就越高」的線性關係。它比較像一道門檻——把體驗做到「夠好」很重要，但把已經很快的網站再壓榨那零點幾秒，邊際效益就很低了。所以優化的目標是先讓指標進入「良好」區間，而不是無止盡追求極限數字。
Core Web Vitals（核心網頁指標）是 Google 用來量化真實使用者體驗的一組指標。它目前由三個指標組成，分別衡量載入、互動、視覺穩定三個面向。請特別注意：早期的互動指標 FID（First Input Delay）已經在 2024 年正式被 INP 取代，現在的三大指標是 LCP、INP、CLS。
LCP（Largest Contentful Paint）衡量頁面主要內容載入完成的速度，也就是視窗內「最大的那個元素」（通常是主圖或大段標題）出現在畫面上所需的時間。它反映使用者感受到的「這頁載好了沒」。
LCP 偏慢通常和伺服器回應慢、主圖太大、阻擋渲染的 CSS／JavaScript，或字型載入太晚有關。
INP（Interaction to Next Paint）衡量頁面對使用者操作的整體回應速度。當使用者點擊按鈕、輸入文字或點開選單時，畫面要多久才會給出視覺回饋，INP 會綜觀整個瀏覽歷程中的互動延遲，取一個有代表性的數值。它取代了舊的 FID，因為 FID 只看「第一次」互動的輸入延遲，而 INP 更完整地反映整段使用過程的流暢度。
INP 偏高的主因幾乎都是 JavaScript：過重的腳本長時間佔用主執行緒，使得瀏覽器來不及即時回應使用者的操作。
CLS（Cumulative Layout Shift）衡量頁面在載入過程中版面「跳動」的程度。你一定遇過：正要點某個按鈕，圖片或廣告突然載入把內容往下擠，結果點錯位置。CLS 就是在量化這種惱人的非預期位移。它是一個無單位的分數，越低越好。
CLS 通常來自沒有預留尺寸的圖片或廣告、動態插入的內容，以及晚載入的網頁字型造成文字重排。
圖片往往是頁面中最大的資源。未壓縮的高解析度圖片、用過大的尺寸再由瀏覽器縮小、使用過時的格式，都會嚴重拖慢 LCP。圖片也是 CLS 的常見元兇——沒有指定寬高的圖片載入時會把版面撐開。
過多或過重的 JavaScript 是 INP 最大的敵人，也會延後 LCP。第三方腳本（分析工具、聊天外掛、廣告碼）尤其容易在不知不覺中累積成沉重負擔，長時間佔用主執行緒。
若伺服器回應第一個位元組的時間（TTFB）就很慢，後面所有環節都會被連帶拖累。常見原因包括主機效能不足、沒有使用快取、資料庫查詢太慢，或使用者距離伺服器過遠。
放在 <head> 中、沒有非同步處理的 CSS 與 JavaScript，會在它們載入完成前阻止頁面顯示，直接拉長 LCP。
以下手法依「投報率」由高到低大致排序，多數不需要重寫整個網站就能見效：
width 與 height 或用 CSS 預留空間，可直接改善 CLS。loading="lazy"，讓瀏覽器先處理重要內容。defer 或 async，減輕主執行緒負擔以改善 INP。font-display: swap 避免字型載入時的空白，並只載入需要的字重。優化前後都要量測，才知道有沒有真的改善。常用的工具與資料來源：
要特別分清「實驗室數據」與「真實使用者數據」：前者是在受控環境模擬出來的，方便除錯；後者來自實際造訪者，才是 Google 排名真正參考的。優化時用實驗室數據快速迭代，但最終要回頭看真實數據是否進入良好區間。
速度優化是 SEO 裡少數「使用者體驗與排名完全一致」的領域——你為訪客做的每一分加速，搜尋引擎都會看在眼裡。先用工具找出目前卡關的指標，再從投報率最高的圖片與 JavaScript 著手，通常就能看到明顯進步。
立即檢測你的網站 SEO