- 登入
- 註冊
PageSpeed Insights 怎麼看？Core Web Vitals 分數與網站速度改善順序
內容目錄
顯示
PageSpeed Insights 報告要先看真實使用者資料，再用實驗室資料找原因。上方 Core Web Vitals 評估反映 Chrome 使用者在過去 28 天的實際體驗；下方 Lighthouse 效能分數則是在模擬環境中針對這次載入產生的診斷結果。
兩者用途不同。真實使用者資料可以回答「多數使用者最近的體驗如何」，實驗室資料適合回答「在這組測試條件下，可能是哪個資源或程式工作造成問題」。手機版出現紅色分數，不代表 Google 已經替網站算出一個固定的 SEO 排名分數，也不能只靠把 Lighthouse 衝到 100 分保證排名上升。
來源：Google About PageSpeed Insights、Google web.dev Web Vitals與Chrome Lighthouse performance scoring（查證 2026-07-24）。官方文件用來確認 PSI 的 field data 與 lab data 來源、Core Web Vitals 判定方式，以及 Lighthouse 分數的加權與波動。本文不把單次效能分數寫成 SEO 排名分數。
PageSpeed Insights 是什麼？
PageSpeed Insights，常縮寫為 PSI，是 Google 提供的網頁效能分析工具。輸入公開網址後，PSI 會分別呈現行動裝置與電腦環境的資料，並把真實使用者體驗與模擬載入診斷放在同一份報告。
PSI 是報告入口，不是資料全部由 PSI 自己產生
PSI 把兩套主要資料來源放進同一頁：
- <strong>Chrome User Experience Report</strong>：常縮寫為 CrUX，提供符合資料條件的 Chrome 真實使用者體驗。
- <strong>Lighthouse</strong>：在模擬環境中載入指定網址，產生效能指標、分數與診斷建議。
CrUX 提供真實使用者資料
PSI 的真實使用者資料來自 CrUX。Google 官方目前說明，PSI 會呈現前 28 天收集期間的 FCP、LCP、CLS 與 INP，並可能顯示實驗性 TTFB 指標。
Lighthouse 提供可重跑的實驗室診斷
PSI 的 lab data 由 Lighthouse 產生。它會在模擬裝置與網路條件下載入這個網址，計算效能指標，再產生 Performance、Accessibility、Best Practices 及 SEO 等類別分數與診斷。
PageSpeed Insights 不會自動替網站排好修復順序
報告中的 Opportunities 與 Diagnostics 會列出可能改善項目，也可能估算節省時間或傳輸量。這些結果是技術候選清單，不等於商業優先級。
- 問題影響哪些頁面範本。
- 是否阻擋主要內容或互動。
- 行動版與電腦版是否都受影響。
- 真實使用者資料是否也呈現相同訊號。
- 修正成本與回歸風險。
- 是否由第三方腳本或外部服務造成。
來源：Google About PageSpeed Insights與Chrome Lighthouse performance scoring（查證 2026-07-24）。Google 文件說明 PSI 的真實資料來自 CrUX，涵蓋前 28 天，資料不足時可能回退到 origin 或完全無法顯示；lab data 則由 Lighthouse 在模擬環境產生。本文的商業優先級欄位是診斷方法，不是 PSI 內建排序。
Field data、lab data、Core Web Vitals 與 Performance score 差在哪裡？
這四個名詞最容易被混成同一個「速度分數」。Field data 與 lab data 是資料取得方式；Core Web Vitals 是一組真實體驗核心指標；Performance score 則是 Lighthouse 實驗室指標經加權後的總分。
| 項目 | 資料來源 | 代表對象 | 時間範圍 | 主要用途 | 主要限制 |
|---|---|---|---|---|---|
| URL field data | CrUX 真實 Chrome 使用者 | 指定網址的合格樣本 | 過去 28 天移動期間 | 判斷該頁真實體驗 | 需要足夠樣本，無法逐筆重現 |
| Origin field data | CrUX 真實 Chrome 使用者 | 同一來源網站的合格頁面 | 過去 28 天移動期間 | URL 資料不足時提供較廣訊號 | 不能直接代表指定頁面 |
| Lab data | Lighthouse 模擬載入 | 這次測試條件下的單次執行 | 當次測試 | 重現問題與找候選原因 | 不是多數真實使用者分布 |
| Performance score | Lighthouse 多項 lab 指標 | 當次模擬執行 | 當次測試 | 快速摘要與同條件比較 | 權重會更新，總分會波動 |
Field data 回答「真實使用者最近遇到什麼」
Field data 是現場資料的常見翻譯。PSI 不是追蹤某一位使用者，而是呈現符合 CrUX 條件的匿名彙整資料。
- LCP 不超過 2.5 秒。
- INP 不超過 200 毫秒。
- CLS 不超過 0.1。
Lab data 回答「這次模擬為什麼可能變慢」
Lab data 來自單次模擬測試，能提供效能時間軸、網路請求、主執行緒工作與改善建議。它的優勢是可重跑：團隊可以在修改前後用相似條件測同一網址，觀察候選原因是否改變。
- 第一次：58 分。
- 第二次：72 分。
- 第三次：64 分。
- 最低值：58 分。
- 最高值：72 分。
- 範圍：72 － 58 ＝ 14 分。
- 簡單平均：（58 ＋ 72 ＋ 64）÷ 3 ＝ 64.7 分。
Core Web Vitals 不是 Performance score 的三個子分數
Core Web Vitals 目前由 LCP、INP 與 CLS 組成，分別關注載入、互動回應與視覺穩定。PSI 的真實體驗區塊會用 CrUX 資料評估這三項。
- Field data 的 Core Web Vitals 通過，但這次 lab score 偏低。
- Field data 未通過，但新版本單次 lab score 已改善。
- 指定 URL 沒有 field data，只能看到 origin 資料與 lab 診斷。
- 手機 lab score 低於電腦版，但真實使用者差距要另外看 field data。
Performance score 是診斷摘要，不是 SEO 分數
Lighthouse Performance score 是多項指標分數的加權平均。不同指標權重不一樣，而且 Lighthouse 團隊可能隨研究與版本更新調整權重。
- 網站會排在 Google 第幾名。
- 真實使用者是否都覺得快。
- 全站每一種頁型是否相同。
- 轉換率一定會增加多少。
- 哪個技術問題必須第一個修。
LCP、INP、CLS 怎麼讀？
Core Web Vitals 不是三個可以互相抵銷的分數。LCP 看主要內容多久出現，INP 看使用者操作後多久看到下一次畫面更新，CLS 看頁面是否發生非預期位移。三項都要在各自門檻內，才能通過這項評估。
| 指標 | 英文全名 | 衡量內容 | 良好 | 需要改善 | 不良 | 常見頁面例子 |
|---|---|---|---|---|---|---|
| LCP | Largest Contentful Paint | 可視區域最大內容元素的呈現時間 | 不超過 2.5 秒 | 超過 2.5 秒至 4 秒 | 超過 4 秒 | 主視覺圖片、大型文字區塊或影片預覽圖出現太慢 |
| INP | Interaction to Next Paint | 點擊、輕觸或鍵盤操作到下一次畫面更新的延遲 | 不超過 200 毫秒 | 超過 200 毫秒至 500 毫秒 | 超過 500 毫秒 | 選單點了才開，加入購物車後很久才顯示結果 |
| CLS | Cumulative Layout Shift | 頁面生命週期內非預期版面位移的累積分數 | 不超過 0.1 | 超過 0.1 至 0.25 | 超過 0.25 | 圖片載入後把文字推開，橫幅突然插入內容上方 |
LCP 看主要內容何時真正出現
LCP 的完整名稱是 Largest Contentful Paint。它測量使用者開始前往頁面後，可視區域內最大圖片、文字區塊或影片元素完成呈現所需的時間。
- 初始文件與伺服器回應是否太慢。
- LCP 資源是否太晚才被瀏覽器發現。
- 圖片或字型等資源下載是否太久。
- 資源下載完成後，元素是否仍被 CSS 或 JavaScript 延後呈現。
INP 看操作後多久出現下一個畫面
INP 的完整名稱是 Interaction to Next Paint。它觀察使用者造訪期間的點擊、輕觸與鍵盤操作，再以最慢或接近最慢的互動延遲代表頁面整體回應能力。
- 點選導覽選單後，選單很久才出現。
- 按下加入購物車後，數量或提示遲遲沒有更新。
- 輸入表單內容時，介面明顯卡住。
- 切換頁籤或篩選器後，結果很晚才顯示。
CLS 看內容是否在沒有預期時突然移動
CLS 的完整名稱是 Cumulative Layout Shift。它衡量可見元素在頁面生命週期中發生非預期位移的程度，分數由位移影響範圍與移動距離計算。
- 圖片沒有預留寬高比例，載入後才撐開空間。
- 廣告、嵌入內容或 iframe 沒有預留位置。
- 網頁載入後才把橫幅或提示插入既有內容上方。
- 網頁字型切換時改變文字尺寸與換行。
三項都要達標，不能取平均
假設同一組行動版 field data 顯示：
- LCP：2.3 秒，良好。
- INP：240 毫秒，需要改善。
- CLS：0.08，良好。
來源：Google web.dev Web Vitals、Largest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shift與Optimize Cumulative Layout Shift（查證 2026-07-24）。官方文件用來確認三項指標定義、良好與不良門檻、第 75 百分位判定及常見 CLS 原因。頁面例子與改善優先順序為本文依官方定義整理的診斷框架。
哪些 PageSpeed Insights 報告狀態要先處理？
先處理哪一項，不能只看哪個顏色最紅。正確順序要同時考慮資料層級、影響頁數、主要任務與證據可信度。
| 報告狀態 | 代表意思 | 第一個檢查 | 常見誤讀 | 建議優先級 |
|---|---|---|---|---|
| URL field data 未通過 | 指定網址的真實使用者資料至少一項核心指標未達良好門檻 | 哪項指標失敗，是否影響主要任務 | 把 Lighthouse 每個建議都當成已確認原因 | 關鍵頁或共用範本通常優先 |
| 只有 origin field data | 指定網址樣本不足，報告改顯示整個來源網站資料 | 報告標籤是否為 Origin | 把全站訊號直接當成這一頁的實測 | 先找受影響頁型與 URL 證據 |
| 沒有 field data | URL 與 origin 都沒有足夠 CrUX 樣本 | 網址是否正確及是否可公開存取，再看 lab 診斷 | 當成通過、失敗或流量為零 | 診斷但不宣稱 field data 結論 |
| 行動與電腦落差大 | 裝置、網路、資源或使用者組成可能不同 | 是否比較相同資料層級與時間範圍 | 用手機 lab score 對照電腦 field data | 依主要流量與轉換裝置排序 |
| 單一頁面異常 | 特定 URL 或頁型可能有獨有資源與元件 | 與健康對照頁比較唯一差異 | 直接把單頁問題擴大成全站問題 | 依該頁商業重要性排序 |
真實使用者未通過，而且影響關鍵流程
如果 field data 未通過，且問題出現在首頁、主要服務頁、商品頁或結帳流程，通常應先列入改善。這代表最近 28 天的真實體驗已出現訊號，不只是一次模擬測試偏慢。
沒有 field data 不是自動通過
新網站、低樣本頁面或不符合 CrUX 資料條件的網址，可能完全沒有 field data。PSI 會先嘗試由指定 URL 回退到 origin；如果 origin 也沒有足夠資料，就只剩實驗室診斷。
行動版落後時，先確認比較基準
行動版常比電腦版更容易出現低分，但差異可能來自模擬條件，也可能是真實體驗。第一步不是宣告「手機網站壞了」，而是核對：
- 兩邊都是 URL field data，還是其中一邊為 origin data。
- 兩邊都是 field data，還是拿 field data 與 lab data 混比。
- 行動版的圖片等資源是否不同，或是否另外載入選單與第三方元件。
- 主要訪客與轉換是否集中在行動裝置。
單頁異常要先找健康對照頁
同一網站中，首頁不良但文章頁良好，或只有某一個商品頁 CLS 過高，適合用對照組找差異。選一個功能與版型相近的健康頁面，逐項比較：
- 是否多了一支第三方腳本。
- 是否使用不同的主視覺圖片。
- 是否插入廣告、影片或外部表單。
- 是否套用不同頁面範本。
- 是否在載入後注入公告或促銷區塊。
PageSpeed Insights 測試前要準備什麼？
沒有先固定頁面與測試條件，PSI 很容易變成反覆截分數，卻無法比較。測試前要先回答三件事：這次代表哪一種頁面，要驗證哪一個使用者任務，以及修改前後要用什麼證據判定改善。
先選頁型，不要只測首頁
首頁通常流量高，卻不一定代表文章、商品與結帳頁。不同頁型可能使用不同範本、圖片及第三方元件，只測首頁無法推論全站。
- 首頁：觀察主視覺、導覽與全站共用資源。
- 主要服務頁：觀察詢價入口及長版內容。
- 一篇典型文章：觀察首圖、目錄及嵌入內容。
- 一個典型商品頁：觀察商品圖、規格與加入購物車互動。
- 轉換頁面：觀察表單、購物車或結帳流程。
URL、裝置與資料層級要先記錄
PSI 會分開呈現行動與電腦結果，field data 又可能顯示 URL 或 origin 層級。測試紀錄若只寫「首頁 62 分」，日後很難確認這個數字來自哪個環境。
| 欄位 | 紀錄內容 | 原因 |
|---|---|---|
| 測試網址 | 完整 canonical URL | 避免測到重新導向或不同參數版本 |
| 頁型 | 首頁、文章、商品或轉換頁 | 判斷能否推廣到同範本 |
| 裝置 | 行動或電腦 | 兩種模擬及真實分布不同 |
| Field data 層級 | URL、Origin 或無資料 | 避免把全站訊號當成單頁結果 |
| 測試日期與時間 | 年月日與時段 | 對照版本、活動與服務狀態 |
| Lighthouse 版本 | 報告 Environment 顯示內容 | 工具版本與條件可能更新 |
| 頁面版本 | 修改前、修改後或部署識別 | 避免比較到不同程式狀態 |
公開頁面與登入狀態要分開處理
PSI 適合分析可由 Google 測試環境存取的公開網址。會員後台、登入後購物車或需要特定 Cookie 才出現的畫面，不能直接把公開 PSI 結果當成完整使用流程證據。
- 公開入口頁仍用 PSI 查看 field data 與 Lighthouse 診斷。
- 登入後流程搭配 Chrome DevTools 和測試帳號，以真機操作記錄效能。
每個 URL 至少重測三次並保留分布
Lighthouse 分數可能受到網路路由、廣告內容、A/B 測試及測試環境變化影響。單次 90 分或單次 40 分都不足以代表穩定狀態。
- 輸入值：61 分、68 分、64 分。
- 最低值：61 分。
- 最高值：68 分。
- 範圍：68 － 61 ＝ 7 分。
- 簡單平均：（61 ＋ 68 ＋ 64）÷ 3 ＝ 64.3 分。
怎麼把 PageSpeed Insights 報告變成改善待辦？
一份可執行的效能待辦，不是把 PSI 的 Opportunities 全部複製給工程師。它要把「哪一群使用者遇到什麼問題」連到「哪個假設值得驗證」，並定義修改範圍與驗收方式。
先確認結論來自 field data 還是 lab data
同一個數值若來源不同，能支持的結論也不同：
- Field data 可以支持「最近 28 天的真實使用者體驗出現這個訊號」。
- Lab data 可以支持「在這次模擬條件下重現這個現象」。
- Opportunities 與 Diagnostics 可以支持「這是值得檢查的候選原因」。
把指標翻成具體使用者問題
技術指標只有連到任務，才容易判斷優先級：
| 指標訊號 | 使用者可能感受到的問題 | 第一批證據 | 待辦方向 |
|---|---|---|---|
| LCP 不良 | 進入頁面後，主要內容很久才出現 | LCP 元素、資源瀑布與 TTFB | 縮短主要內容的發現時間與下載時間，並減少呈現延遲 |
| INP 不良 | 點擊後介面沒有立即回應 | 受影響互動、長工作與第三方程式 | 縮短主執行緒阻塞及事件處理 |
| CLS 不良 | 閱讀或點擊時內容突然移動 | 位移元素與觸發來源 | 預留尺寸並避免非預期內容插入 |
| Lab score 波動大 | 同一頁有時快，有時慢 | 三次分布與環境備註 | 找出快取、網路或第三方變數 |
用健康頁與異常頁建立對照
找出一個合理原因前，至少列出兩到三個競爭假設，再用證據淘汰。假設某商品頁 LCP 不良，可以先提出：
- 主圖檔案過大，下載時間偏長。
- 主圖被延遲載入，瀏覽器太晚才發現。
- 初始文件回應過慢，所有主要資源都延後。
排序要同時納入影響範圍與任務重要性，並評估修正成本
PSI 不知道哪個頁面帶來詢價，也不知道哪支腳本是法規同意管理所必需。專案排序可以使用五個欄位：
| 評估欄位 | 低 | 中 | 高 |
|---|---|---|---|
| 影響頁數 | 單一低流量頁 | 一個重要頁型 | 全站共用範本 |
| 任務影響 | 裝飾性效果 | 閱讀與導覽 | 購買、預約或送出表單 |
| Field 證據 | 無資料 | 需要改善 | 不良且樣本充足 |
| 重現程度 | 單次出現 | 多次但波動 | 相同條件穩定重現 |
| 修正風險 | 局部且可回復 | 需跨元件測試 | 影響核心功能或第三方合規 |
看 PageSpeed Insights 最常犯哪些錯？
PSI 最容易被誤用的地方，不是指標太多，而是把不同層級的證據壓成一個分數。以下錯誤會讓團隊忙著「優化」，卻無法證明使用者體驗是否改善。
把 Lighthouse 100 分當成專案目標
Lighthouse 的 Performance score 是加權後的 lab 摘要，不是真實使用者體驗保證，也不是 SEO 排名分數。Chrome 官方指出，從 99 分提升到 100 分所需的指標改善，可能和從 90 分提升到 94 分相近；追逐最後一分的成本未必符合網站任務。
- 關鍵頁的 field data 是否達到良好門檻。
- 主要內容與互動是否不再阻擋使用者。
- 修改後底層指標是否穩定改善。
- 功能、版面及追蹤是否沒有回歸。
只測首頁或只保留一次最好成績
首頁良好不能代表文章頁、商品頁與結帳頁都良好。只測首頁是第一個取樣錯誤；測了三次卻只截最高分，則是第二個取樣錯誤。
- 輸入值：45 分、79 分、52 分。
- 最低值：45 分。
- 最高值：79 分。
- 範圍：79 － 45 ＝ 34 分。
混用 field、lab、URL 與 origin 資料
常見的第三個錯誤，是拿手機 lab score 與電腦 field data 比較；第四個錯誤，是把 origin 資料當成指定 URL 的實測；第五個錯誤，則是把沒有 field data 寫成 0 分或自動通過。
- 裝置是否相同。
- 資料是 field 還是 lab。
- Field data 是 URL 還是 Origin。
- 報告是否真的有足夠資料完成評估。
- 比較期間與頁面版本是否一致。
同時修改太多項目或忽略第三方腳本
第六個錯誤，是一次更換主機，壓縮圖片，合併程式又改快取；第七個錯誤，是把客服、廣告與分析程式視為不可檢查的外部因素。
來源：Chrome Lighthouse performance scoring、Google About PageSpeed Insights與Why lab and field data can be different（查證 2026-07-24）。官方文件用來確認 Lighthouse 分數加權與波動、field data 層級及 lab 與 field 的環境差異。七項常見錯誤與 45／79／52 分算式為本文的診斷示例。
首頁與內容頁各測三次，要怎麼判讀？
以下數字是教學用的假設資料，不是 site-now.app 或客戶網站實測。目的在示範如何保存中間值，區分穩定問題與單次波動，再轉成可驗收待辦。
首頁三次測試顯示穩定的 LCP 問題
假設首頁結果如下：
| 次數 | Performance score | LCP | TBT | CLS | 當次 LCP 元素 |
|---|---|---|---|---|---|
| 1 | 48 | 4.3 秒 | 320 毫秒 | 0.04 | 首頁主視覺 |
| 2 | 54 | 3.9 秒 | 280 毫秒 | 0.03 | 首頁主視覺 |
| 3 | 51 | 4.1 秒 | 300 毫秒 | 0.05 | 首頁主視覺 |
- 輸入值：48 分、54 分、51 分。
- 最低值：48 分。
- 最高值：54 分。
- 範圍：54 － 48 ＝ 6 分。
- 簡單平均：（48 ＋ 54 ＋ 51）÷ 3 ＝ 51 分。
- 輸入值：4.3 秒、3.9 秒、4.1 秒。
- 最低值：3.9 秒。
- 最高值：4.3 秒。
- 範圍：4.3 － 3.9 ＝ 0.4 秒。
- 簡單平均：（4.3 ＋ 3.9 ＋ 4.1）÷ 3 ＝ 4.1 秒。
- 輸入值：320 毫秒、280 毫秒、300 毫秒。
- 最低值：280 毫秒。
- 最高值：320 毫秒。
- 範圍：320 － 280 ＝ 40 毫秒。
- 簡單平均：（320 ＋ 280 ＋ 300）÷ 3 ＝ 300 毫秒。
- 輸入值：0.04、0.03、0.05。
- 最低值：0.03。
- 最高值：0.05。
- 範圍：0.05 － 0.03 ＝ 0.02。
- 簡單平均：（0.04 ＋ 0.03 ＋ 0.05）÷ 3 ＝ 0.04。
內容頁三次測試顯示一次明顯波動
假設內容頁結果如下：
| 次數 | Performance score | LCP | TBT | CLS | 環境備註 |
|---|---|---|---|---|---|
| 1 | 72 | 2.7 秒 | 110 毫秒 | 0.07 | 無特殊狀況 |
| 2 | 60 | 3.4 秒 | 420 毫秒 | 0.08 | 一支第三方請求延遲 |
| 3 | 70 | 2.8 秒 | 130 毫秒 | 0.06 | 無特殊狀況 |
- 輸入值：72 分、60 分、70 分。
- 最低值：60 分。
- 最高值：72 分。
- 範圍：72 － 60 ＝ 12 分。
- 簡單平均：（72 ＋ 60 ＋ 70）÷ 3 ＝ 67.3 分。
- 輸入值：2.7 秒、3.4 秒、2.8 秒。
- 最低值：2.7 秒。
- 最高值：3.4 秒。
- 範圍：3.4 － 2.7 ＝ 0.7 秒。
- 簡單平均：（2.7 ＋ 3.4 ＋ 2.8）÷ 3 ＝ 2.97 秒。
- 輸入值：110 毫秒、420 毫秒、130 毫秒。
- 最低值：110 毫秒。
- 最高值：420 毫秒。
- 範圍：420 － 110 ＝ 310 毫秒。
- 簡單平均：（110 ＋ 420 ＋ 130）÷ 3 ＝ 220 毫秒。
- 輸入值：0.07、0.08、0.06。
- 最低值：0.06。
- 最高值：0.08。
- 範圍：0.08 － 0.06 ＝ 0.02。
- 簡單平均：（0.07 ＋ 0.08 ＋ 0.06）÷ 3 ＝ 0.07。
兩個頁面應先處理哪一個？
若首頁承接主要導覽，而且 field LCP 同樣不良，首頁三次都穩定辨識同一個 LCP 元素，應優先建立主視覺 LCP 待辦。理由是證據方向一致，影響範圍較大，也連到主要入口體驗。
- 內容頁 LCP 在三次 lab 測試皆超過良好門檻，檢查共用文章範本與首圖。
- 第二次 TBT 明顯升高，驗證第三方請求是否能穩定重現。
來源：Chrome Lighthouse performance scoring、Google About PageSpeed Insights與Google web.dev Web Vitals（查證 2026-07-24）。官方文件用來確認 Lighthouse 分數波動、LCP 良好門檻、lab 與 field data 的用途及限制。兩張表中的 URL、分數、指標與第三方請求均為教學假設，不代表秒站或任何客戶網站實測。
內文精華總結
- PageSpeed Insights 是什麼：PageSpeed Insights，常縮寫為 PSI，是 Google 提供的網頁效能分析工具。
- PSI 是報告入口，不是資料全部由 PSI 自己產生：白話來說，CrUX 比較像最近一段時間的實際體驗紀錄，Lighthouse 比較像在固定測試條件下重現一次頁面載入。
- CrUX 提供真實使用者資料：Google 官方目前說明，PSI 會呈現前 28 天收集期間的 FCP、LCP、CLS 與 INP，並可能顯示實驗性 TTFB 指標。
- Lighthouse 提供可重跑的實驗室診斷：PSI 的 lab data 由 Lighthouse 產生。
想把PageSpeed Insights規劃成能長期營運的網站？
先用秒站建立可操作的網站，再依實際內容、功能與營運需求調整。你可以先試用，查看方案，或從真實案例確認適合自己的方向。
- 1 小時免費試用：不必信用卡，先確認後台與編輯流程是否適合。
- 查看秒站方案：標準方案 NT$24,000、專業方案 NT$36,000、輕電商方案 NT$48,000 年費。
- 瀏覽 80+ 真實案例：從不同產業的內容、版型與功能安排找參考。
延伸閱讀
網站營運健檢系列文章
秒站現在不只是一套版型。你可以從現成架構快速開始，用頁面編輯器拖曳、複製與調整版面；需要更高自由度時，也能和 AI 協作，把自製頁面放進 Vibe 畫布。上線速度與設計自由不必二選一。
重點整理
PageSpeed Insights 是什麼？
PageSpeed Insights，常縮寫為 PSI，是 Google 提供的網頁效能分析工具。輸入公開網址後，PSI 會分別呈現行動裝置與電腦環境的資料，並把真實使用者體驗與模擬載入診斷放在同一份報告。它不是單純的「網站速度秒數測試」，也不是只看一個總分。完整報告至少要分成四層：真實使用者資料是否存在，Core Web Vitals 是否通過，這次 Lighthouse 執行呈現哪些效能指標，以及診斷項目指出哪些可能原因。
行動版與電腦版為什麼不同？
真實使用者採用的裝置與網路可能不同，處理器及視窗大小也會有差異，頁面還可能載入不同圖片或介面。Lighthouse 的行動與電腦測試同樣使用不同模擬條件。判讀時不要拿手機 lab score 直接減去電腦 field data，也不要用一邊的 URL 資料和另一邊的 origin 資料硬做比較。先確認報告標籤、資料層級與時間範圍相同，再談差異。
實際使用者資料與實驗室資料差在哪裡？
PSI 的真實使用者資料來自 CrUX。Google 官方目前說明，PSI 會呈現前 28 天收集期間的 FCP、LCP、CLS 與 INP，並可能顯示實驗性 TTFB 指標。這些資料不是今天早上改完圖片，下午就只剩新版本結果。28 天視窗會同時包含修改前後的真實體驗，而且資料每日更新時仍保留這段移動期間。因此，正式修改後要看趨勢，不能期待 field data 立刻跟單次 Lighthouse 一起翻轉。
為什麼沒有 Core Web Vitals 實際資料？
通常是該 URL 與整個 origin 都沒有足夠的 CrUX 真實使用者樣本，或頁面不符合資料呈現條件。沒有 field data 不代表網站一定快或慢，仍可先看 Lighthouse 診斷，再持續累積實際流量資料。
LCP、INP、CLS 是什麼？
Core Web Vitals 不是三個可以互相抵銷的分數。LCP 看主要內容多久出現，INP 看使用者操作後多久看到下一次畫面更新，CLS 看頁面是否發生非預期位移。三項都要在各自門檻內，才能通過這項評估。這些門檻要看第 75 百分位，並分開評估行動裝置與電腦。表中的「秒」只適用 LCP，「毫秒」只適用 INP；CLS 是沒有單位的分數，0.1 不是 0.1 秒。
效能分數多少才算好？
Lighthouse 90–100 為綠色區間，但不應把單次分數當成上線或 SEO 保證。實務上先看 field Core Web Vitals 是否通過，再用 lab 分數及診斷項目找改善線索，並以多次測試和商業任務結果驗證。
為什麼每次測試分數不同？
測試裝置、網路、伺服器回應、快取、第三方資源及動態內容都可能造成波動。應在相近條件下測試多次，記錄中位數及主要差異，再判斷是穩定瓶頸或單次雜訊，不要只挑最高或最低的一次。
分數低會不會影響 SEO？
可能間接影響，但不能用單次 Lighthouse 分數推算排名。Google 使用 Core Web Vitals 等頁面體驗訊號，內容相關性與其他訊號仍同時作用；改善順序應兼顧真實使用者體驗、頁面可抓取性及商業任務。
