站長之間談主機速度，最常掛在嘴邊的是 LCP（Largest Contentful Paint）。它確實是 Google 核心 Web 指標（Core Web Vitals, CWV）裡最直觀的一項，但只盯著這個數字看，等於把整套效能診斷壓縮成一支體溫計。網站慢可以慢在很多層，伺服器回應、資源下載、瀏覽器渲染、互動處理，每一段都有自己的計時器，混在一起看反而抓不到真正的瓶頸。
2026 年的 WordPress 主機效能指標，已經從 LCP 一支獨秀，演進成一組分工明確的儀表板。Google 在 2024 年 3 月把互動到下次繪製（Interaction to Next Paint, INP）正式納入 CWV，退役了首次輸入延遲（First Input Delay, FID）。現在的官方門檻在 75 百分位的真實使用者資料下，LCP 要低於 2.5 秒、INP 要低於 200 毫秒、累積版面位移（Cumulative Layout Shift, CLS）要低於 0.1，這組數字在 2026 年仍是穩定基準。
把指標分清楚還有一個現實理由，那就是責任歸屬。有的數字壞了，是主機商該處理；有的數字壞了，再怎麼換主機都救不回來，得回頭看主題與外掛。下面六個指標，剛好能把這條責任線畫清楚。
首位元組時間決定起跑線
首位元組時間（Time To First Byte, TTFB）是瀏覽器送出請求到收到伺服器第一個位元組的時間，量的是「網站動工前的等待」。如果 TTFB 就先吃掉 1 秒，後面所有指標都會被推遲，再怎麼壓縮圖片、再怎麼延後 JavaScript，也補不回這段預支的時間。
Google 對 TTFB 沒有單獨打分，但建議低於 800 毫秒才算合格，多數效能顧問會把目標壓在 200 至 400 毫秒之間。Kinsta、Rocket.net 這類 2026 年表現領先的託管型主機，全球平均落在 180 毫秒上下；台灣本地共享主機若沒有快取，常見值會跑到 600 至 1,200 毫秒。
這個指標幾乎全由伺服器端決定，PHP 版本、資料庫效能、固態硬碟（NVMe）、網頁伺服器選型（LiteSpeed 或 Nginx）、邊緣快取覆蓋率，每一項都直接影響它。TTFB 持續高於 800 毫秒，先找主機商，不是先找前端工程師。
最大內容繪製反映前端搬運
LCP 量的是瀏覽器把可視範圍內最大的元素（通常是首屏的大圖或主標）畫到螢幕上需要多久。它接著 TTFB 的棒子跑，但跑道是前端的，包含 HTML 解析、CSS 阻塞、字型載入、圖片下載與渲染。
CWV 把 2.5 秒以下視為良好，2.5 至 4 秒需要改善，超過 4 秒判定不佳。要注意的是它取 75 百分位，意思是要有四分之三的真實訪客都低於門檻才算過關，少數測試環境跑出漂亮數字並不代表現場合格。
LCP 是責任邊界最模糊的一個指標。前半段被 TTFB 決定，後半段卻在前端，例如首屏圖片有沒有用新一代格式（WebP、AVIF）、有沒有設明確尺寸、字型有沒有阻塞渲染、佈景主題的關鍵 CSS 是不是內聯。看到 LCP 偏高，先拆出 TTFB 那段，剩下的差距才是前端要處理的部分。
互動到下次繪製衡量回應感
INP 是 2024 年 3 月正式上線的互動指標，取代了 FID。它觀察整個頁面瀏覽期間的所有互動事件，回報最慢的一次從點擊到畫面更新的延遲，遠比只看第一次點擊的 FID 更貼近真實使用感受。
2026 年的判定門檻維持 200 毫秒以下為良好、200 至 500 毫秒需要改善、超過 500 毫秒判定不佳。電商結帳按鈕、搜尋下拉、表單送出這類關鍵互動最容易吃虧，特別是當頁面同時掛著好幾個追蹤腳本或大型 JavaScript 框架。
INP 主要由主題與外掛決定，跟主機關係相對小。佈景主題的 JavaScript 體積、外掛在前台注入的腳本數、第三方追蹤碼的執行成本，都是主因。換更快的主機對 INP 通常只能拉回幾十毫秒，真正大幅改善要靠減少主執行緒阻塞、延後非必要腳本、用程式碼分割（Code Splitting）拆掉肥大套件。
累積版面位移反映設計嚴謹度
CLS 量的是頁面在載入過程中元素跳動的累積幅度，門檻是 0.1 以下良好、0.25 以下需要改善，超過判定不佳。這個指標跟主機速度幾乎無關，純粹是排版與資源宣告的問題。
最常見的禍首有三類元素，分別是沒寫寬高屬性的圖片與影片、預留空間不夠的廣告或嵌入區塊、字型載入完成後文字尺寸跳動的版面。這些問題在共享主機與企業級主機上會用一模一樣的方式發生，因為它們發生在瀏覽器端而非伺服器端。
CLS 偏高時不要去找主機商投訴，回頭檢查佈景主題、廣告外掛、字型載入策略。給每個媒體元素設明確尺寸、廣告位用 min-height 預留空間、字型用 font-display: optional 或先載入回退字型，多半就能把分數壓回安全區。
總阻塞時間量主執行緒擁塞
總阻塞時間（Total Blocking Time, TBT）是首次內容繪製（FCP）與可互動時間（TTI）之間，主執行緒被超過 50 毫秒的長任務（Long Task）擋住的累計時間。它不在 CWV 三大指標裡，但 PageSpeed Insights 的實驗室分數就是它撐起一大塊。
TBT 在實驗室環境裡的角色，相當於 INP 在現場資料裡的角色，一個量機器測得的潛在阻塞，一個量真實使用者感受的延遲。實務上 TBT 低於 200 毫秒算良好、200 至 600 毫秒需要改善，超過 600 毫秒幾乎一定會連帶把 INP 也拖差。
要降 TBT，著手點跟 INP 重疊。把肥大 JavaScript 切片載入、延後非首屏需要的腳本、減少第三方追蹤、避免在主執行緒上跑長迴圈或同步資料解析。主機升級對 TBT 的幫助有限，因為主執行緒擁塞發生在使用者的瀏覽器，不在你的伺服器。
伺服器回應時間是底層心跳
伺服器回應時間（Server Response Time, SRT）跟 TTFB 概念相近但更聚焦，指伺服器從接到請求到開始送出回應主體的純後端處理時間，不含網路往返。Google 在 PageSpeed Insights 報告會把它單獨拉出來，建議壓在 600 毫秒以下，多數效能顧問抓在 200 毫秒以內。
SRT 反映的是後端在做什麼，包括 PHP 解譯速度、資料庫查詢效率、物件快取（Object Cache）有沒有打開、頁面快取命中率、是否有外掛在每個請求都跑昂貴的同步呼叫。WooCommerce 站台若把這個數字撐到 1 秒以上，購物車與結帳的所有指標都會跟著塌。
它跟 TTFB 的關係，可以想成同一條供應鏈的兩個觀測點。TTFB 是訪客端看到的「等了多久」，SRT 是伺服器端看到的「我花了多久處理」，兩者中間的差距是網路與 CDN 那層的成本。SRT 過高一定是主機與後端的問題，包含主機規格、PHP 版本、資料庫優化、快取策略，沒有一項能甩鍋給前端。
把這六項 WordPress 主機效能指標放在一起看，責任就分得很清楚。TTFB 與 SRT 是主機與後端的責任，CLS 與 INP 是主題與外掛的責任，LCP 與 TBT 則跨在兩端中間，需要拆段歸因。下次再聽到「主機太慢」這四個字，先打開 PageSpeed Insights 把這六個數字一一對齊，問題出在哪一段就會一目瞭然，不必再陪著前端與主機商互相推諉。