- 首頁
- 知識庫
- SEO 搜尋引擎最佳化
- PageSpeed Insights 怎麼看？核心網頁指標與無障礙分數改善
SEO 搜尋引擎最佳化
PageSpeed Insights 怎麼看？核心網頁指標與無障礙分數改善
作者：JamXu更新日期：2026-10-10
PageSpeed Insights 一次給你兩份報告：上半部是真實訪客過去 28 天的核心網頁指標（LCP、INP、CLS），代表使用者實際感受；下半部是 Lighthouse 在模擬環境跑出的效能、無障礙、最佳做法與 SEO 分數，用來找問題。判斷好壞以實際使用者資料為準，分數只是診斷工具，不必為了 SEO 追求 100 分；無障礙方面，一般文字對比度 4.5:1 是 WCAG AA 標準，7:1 則是更嚴格的 AAA。
PageSpeed Insights 是什麼？一個網址、兩種資料
一句話定義：PageSpeed Insights（簡稱 PSI）是 Google 提供的免費網頁檢測工具，輸入一個網址，就能同時看到真實訪客的使用體驗，以及模擬測試找出的改善項目。很多人只看那個大大的圓形分數，但它只是報告的一半，而且不是最重要的那一半。
根據 Google 對 PageSpeed Insights 的官方說明，PSI 會同時提供「實際使用者資料」與「實驗室資料」。前者來自 Chrome 使用者體驗報告（CrUX），是真實 Chrome 使用者在過去 28 天造訪時的匿名統計；後者是 Lighthouse 在受控環境中載入一次網頁所量到的結果。兩者回答的問題不同：實際資料告訴你「訪客實際感受如何」，實驗室資料告訴你「可能是哪裡拖慢了」。
| 比較項目 | 實際使用者資料（現場資料） | 實驗室資料（Lighthouse） |
|---|---|---|
| 資料從哪裡來 | Chrome 使用者體驗報告（CrUX），真實訪客的匿名統計 | Lighthouse 在模擬裝置與網路下載入一次網頁 |
| 時間範圍 | 過去 28 天的累積結果，每天更新 | 按下分析當下的一次測試 |
| 主要指標 | LCP、INP、CLS 三項核心網頁指標，另有 FCP 與 TTFB | 效能分數與 FCP、LCP、TBT、CLS、Speed Index 等指標 |
| 適合用來 | 判斷網頁對訪客來說是不是真的慢 | 找出原因、測試修改有沒有效果 |
| 和搜尋排名的關係 | Google 排名系統使用的核心網頁指標以實際使用者體驗為基礎 | 分數本身不是排名信號，是診斷用的工具 |
除了效能，Lighthouse 還會同時檢查另外三個類別：無障礙、最佳做法與 SEO。所以一份 PSI 報告最多會出現四個分數，加上一組核心網頁指標的評估結果。報告頂端可以切換「行動裝置」與「電腦」，兩者的資料與分數分開計算，而 Google 是以行動版內容建立索引，手機版的結果通常要優先處理。
這篇是 SEO 搜尋引擎最佳化主題頁中技術檢查部分的深入版，專門處理「報告怎麼讀、數字代表什麼、先改哪裡」。網頁體驗和排名之間的關係，在 Google 排名看哪些因素有完整說明；手機版版面本身的檢查重點，則整理在 RWD 響應式網站為什麼重要，這裡不再重複。
打開報告先看哪裡？由上而下的閱讀順序
看 PSI 報告不要從最大的數字開始，先確認「資料在講誰」，再看「結果好不好」，最後才看「要改什麼」：
- 確認右上角的裝置是「行動裝置」，並記下測試的完整網址；同一個網站的首頁、文章頁與商品頁結果可能完全不同
- 看上半部的實際使用者體驗：核心網頁指標評估是「通過」還是「未通過」，以及這份資料是「這個網址」還是「整個來源」
- 逐一看 LCP、INP、CLS 三個數值落在良好、需要改善還是不佳，並看下方的分布長條，了解有多少比例的造訪體驗不好
- 往下看實驗室的四個分數，把效能分數當成「模擬環境下的健康檢查」，而不是最終成績
- 展開效能下方的診斷項目，用指標篩選器只看和有問題的指標相關的建議（例如只看 LCP 相關）
- 最後看無障礙、最佳做法與 SEO 的未通過項目，把能自己修正的記下來，需要工程協助的另外整理
「這個網址」和「來源」差在哪裡
實際使用者資料有兩個層級。如果這個網址本身有足夠的造訪樣本，PSI 會顯示這個網址的資料；如果樣本不夠，例如剛發布的文章或流量很少的頁面，PSI 會改成顯示整個來源，也就是整個網域所有網頁合併的結果。這時看到的數字並不專屬於你測的那一頁，首頁、文章與商品頁全部混在一起。判讀時一定要先看清楚是哪一種，避免把整站的問題誤以為是某一頁的問題，或反過來。
如果連來源層級都沒有足夠資料，上半部就會顯示沒有實際使用者資料。官方說明列出的條件是：網址必須公開、可以被檢索與建立索引，而且要有足夠數量的不重複樣本。新網站或小型企業網站常常停在這個狀態，這不是錯誤，只是還沒有累積到能代表真實體驗的資料量；這段期間就以實驗室資料作為參考。
核心網頁指標怎麼看？LCP、INP、CLS 的門檻與意義
核心網頁指標（Core Web Vitals）是 Google 用來衡量真實使用體驗的三項指標，分別對應三個問題：主要內容多快出現、點下去之後多快有反應、畫面會不會亂跳。每項指標都有「良好」「需要改善」「不佳」三段門檻，PSI 與 Search Console 使用的門檻一致。
| 指標 | 在量什麼 | 良好 | 需要改善 | 不佳 |
|---|---|---|---|---|
| LCP 最大內容繪製 | 畫面中最大的圖片或文字區塊顯示完成所需的時間，代表主要內容多快出現 | 2.5 秒以下 | 超過 2.5 秒、4 秒以下 | 超過 4 秒 |
| INP 與下一個顯示的互動 | 點擊、輕觸、鍵盤操作後，到畫面出現回應的時間，取整次造訪中最慢的互動（排除極端值） | 200 毫秒以下 | 超過 200 毫秒、500 毫秒以下 | 超過 500 毫秒 |
| CLS 累計版面配置位移 | 瀏覽期間非預期的版面移動加總分數，0 代表完全不動 | 0.1 以下 | 超過 0.1、0.25 以下 | 超過 0.25 |
| FCP 首次顯示內容（輔助） | 第一個文字或圖片出現的時間，用來判斷 LCP 慢在哪一段 | 1.8 秒以下 | 超過 1.8 秒、3 秒以下 | 超過 3 秒 |
| TTFB 首位元組時間（輔助） | 從開始載入到收到伺服器第一個位元組的時間 | 0.8 秒以下 | 超過 0.8 秒、1.8 秒以下 | 超過 1.8 秒 |
表格最後兩列不屬於核心網頁指標，但 PSI 會一起顯示，因為它們能幫你拆解 LCP。TTFB 偏高，代表問題出在伺服器或轉址；TTFB 正常但 FCP 很慢，通常是網頁一開始就要下載很多會阻擋顯示的檔案；FCP 正常但 LCP 很慢，則常是主視覺圖片太大或太晚才開始下載。
為什麼看的是第 75 百分位數
PSI 在每項指標上方顯示的數值，不是平均值，而是第 75 百分位數。意思是：把過去 28 天所有造訪依體驗由好到壞排列，取第 75% 那一筆。如果 LCP 顯示 2.4 秒，代表大約四分之三的造訪在 2.4 秒內看到主要內容，其餘四分之一比這更慢。Google 選這個位置，是希望網頁在大多數使用者、包括裝置與網路比較差的人身上，都能有良好體驗。
「通過」核心網頁指標評估的條件
PSI 上方的評估結果只有通過與未通過兩種。官方規則是：三項指標的第 75 百分位數都落在「良好」才算通過。若 INP 資料不足，只要 LCP 與 CLS 都良好仍可通過；若 LCP 或 CLS 資料不足，就無法評估。換句話說，只要有一項是「需要改善」，整體就是未通過，不會因為另外兩項很好而抵銷。
為什麼實際資料和效能分數對不起來？
效能分數一片紅、核心網頁指標卻通過，或分數 90 分以上、實際資料卻顯示 LCP 不佳，都是常見而正常的情況，因為兩份資料的測量方式完全不同。
- 裝置與網路不同：實驗室測試用的是固定的中階手機與較慢的行動網路設定；真實訪客的裝置與網路有好有壞，整體可能比模擬條件快，也可能更慢
- 快取不同：實驗室每次都像第一次造訪；真實訪客常是第二次以上造訪，很多檔案已經存在瀏覽器裡
- 互動不同：INP 需要真的有人點擊、輸入，實驗室不會模擬這些操作，所以效能分數裡沒有 INP，改看 TBT（總封鎖時間）作為參考
- 時間範圍不同：實際資料是 28 天的累積，剛修好的問題要過一段時間才會反映；實驗室結果則是當下立即呈現
遇到兩者不一致時，以實際使用者資料為準。實驗室資料的價值在於「可以重複測試」：你修改一張圖片後，不必等 28 天，馬上就能用實驗室結果確認方向對不對。
| 你看到的情況 | 代表什麼 | 建議做法 |
|---|---|---|
| 實際資料通過、效能分數偏低 | 真實訪客體驗已經不錯，模擬條件比多數訪客嚴苛 | 不必為分數大改；有空再處理診斷中的明顯問題 |
| 實際資料未通過、效能分數很高 | 真實環境有實驗室沒測到的狀況，例如互動卡頓、載入後才出現的廣告或彈出視窗 | 先看是哪一項指標未通過，INP 問題要從互動與第三方程式找原因 |
| 沒有實際資料、只有分數 | 流量還不足以統計 | 以實驗室結果為參考，優先處理 LCP 與 CLS 相關的建議 |
| 同一網址每次測的分數都不一樣 | 網路路由、伺服器負載、廣告內容等變動造成的正常浮動 | 連續測三到五次看大致範圍，不要以單次結果下結論 |
效能分數怎麼算？為什麼不必為了 SEO 追 100 分
效能分數是幾項實驗室指標的加權平均。Lighthouse 官方計分說明列出的 Lighthouse 10 權重如下表；每項指標先依真實網站資料換算成 0 到 100 分，再乘上權重加總。改善建議與診斷項目本身不直接計分，它們只是透過改善指標間接影響分數。
| 指標 | 權重 | 白話意思 |
|---|---|---|
| TBT 總封鎖時間 | 30% | 載入期間主執行緒被長時間工作卡住、無法回應操作的總時間 |
| LCP 最大內容繪製 | 25% | 主要內容多快出現 |
| CLS 累計版面配置位移 | 25% | 載入過程版面跳動的程度 |
| FCP 首次顯示內容 | 10% | 第一個內容多快出現 |
| Speed Index 速度指數 | 10% | 畫面內容整體填滿的速度 |
TBT、LCP、CLS 三項就占了八成，時間有限時先處理這三項的相關建議。分數的顏色區間是 0 到 49 分紅色（不佳）、50 到 89 分橘色（需要改善）、90 到 100 分綠色（良好）。
越接近 100 分越難提升
Lighthouse 官方說明提到，滿分 100 分非常難達成，也不是預期目標；分數越高，每多 1 分需要的改善幅度越大，例如從 99 分到 100 分所需的改善，大約和從 90 分到 94 分一樣多。對多數企業網站來說，把分數從紅色拉到橘色、再穩定在綠色附近，已經是合理的目標。
更重要的是 Google 在網頁體驗說明中的態度：在 Search Console 報表或第三方工具取得好成績，不代表網頁就會排在前面；如果只是為了 SEO 想拿滿分，Google 並不建議把時間花在這件事上。排名系統使用的是核心網頁指標，而且是以內容的相關性與實用性為優先。所以正確的順序是：先確保真實訪客的核心網頁指標達到良好，再把剩下的時間投入內容。
LCP 太慢怎麼改：先找出最大的那個元素
多數企業網站的 LCP 元素，是首屏的主視覺圖片或輪播看板第一張圖；文章頁則可能是封面圖或標題文字。改善 LCP 的第一步，是在 PSI 診斷中找到「最大內容繪製元素」，確認它到底是哪一張圖或哪一段文字。
web.dev 的 LCP 最佳化指南把 LCP 拆成四段時間：首位元組時間（伺服器回應）、資源載入延遲（瀏覽器多晚才開始下載這張圖）、資源載入時間（圖片本身下載多久）、元素算繪延遲（下載完到真正顯示的時間）。每一段都有不同的處理方式：
| 時間段 | 常見原因 | 改善方向 |
|---|---|---|
| 首位元組時間 | 多次轉址、伺服器離訪客太遠、網址帶參數導致無法使用快取 | 連結直接指向最終網址，避免 http → https → www 多次跳轉 |
| 資源載入延遲 | 主視覺圖片由程式動態載入，或被設成延遲載入，瀏覽器太晚發現它 | 首屏圖片不要設延遲載入；讓圖片直接寫在網頁中，而不是等程式插入 |
| 資源載入時間 | 圖片檔案太大，例如直接上傳相機原圖 | 先縮小尺寸再上傳，寬度以實際顯示需要為準，並使用 WebP 等較新的格式 |
| 元素算繪延遲 | 字型或樣式表尚未載入、大量程式佔用主執行緒 | 減少首屏用不到的程式與外掛，避免首屏使用過多特殊字型 |
最常見、也最容易自己處理的是「圖片太大」與「首屏圖片被延遲載入」。web.dev 提醒，載入時就會出現在可視區域的圖片，尤其是 LCP 圖片，不應設定延遲載入。
圖片轉成 WebP 不等於已經壓縮
Sharing AI 架站平台會把上傳的圖片自動轉成 WebP 格式，這對檔案大小有幫助，但轉換格式不等於縮小尺寸。一張寬度好幾千像素的相機原圖，轉成 WebP 之後仍可能是好幾百 KB 甚至更大。上傳前先把圖片縮到實際顯示需要的寬度，例如滿版主視覺約 1,920 像素寬、文章內圖約 1,200 到 1,600 像素寬，通常就能大幅降低 LCP 的下載時間。
Search Console 說明中也給了一般網站擁有者兩個方向：把網頁及所有資源的大小盡量控制在 500 KB 以下，並把網頁的資源數量限制在 50 個以下，以利在行動裝置上展現最佳效能。這不是硬性規定，但很適合當作檢查首頁時的參考線：如果首頁載入了十幾張大圖、好幾個外掛與追蹤程式，LCP 很難好看。
CLS 版面跳動怎麼改：先幫內容預留位置
你一定遇過這種情況：正要點一個按鈕，上方突然多出一張圖片或一條橫幅，整個畫面往下推，結果點到別的地方。這就是 CLS 在衡量的問題。根據 web.dev 的整理，造成 CLS 最常見的原因有四種：沒有設定尺寸的圖片；沒有設定尺寸的廣告、嵌入內容與 iframe；動態插入的內容；以及網頁字型載入造成的文字重排。
- 圖片要有寬高：在圖片元素上寫入 width 與 height 屬性，或用 CSS 設定長寬比，瀏覽器在圖片下載前就能先預留空間
- 嵌入內容要預留高度：地圖、影片、社群貼文嵌入，外框先設定固定高度或比例，內容載入後就不會把下方段落推開
- 不要在已顯示的內容上方插入東西：公告橫幅、優惠條、Cookie 同意列，盡量固定在畫面邊緣或一開始就預留位置
- 字型替換要溫和：特殊字型載入前後的字寬差異太大，會讓整段文字重新換行；首屏標題避免使用過多不同字型
CLS 計算的是整次瀏覽期間的位移，不只載入當下。web.dev 提到，往下捲動時延遲載入的內容若沒有預留空間，也會造成位移；所以實際資料的 CLS 不佳、實驗室 CLS 卻很低時，要往捲動後或互動後才出現的內容去找。
INP 互動卡頓怎麼改：減少同時在跑的程式
INP 衡量的是訪客點擊、輕觸或按鍵之後，畫面多快給出回應。按下選單沒反應、勾選表單選項要等一下才打勾，都是 INP 不佳的典型感受。造成 INP 偏高的主因，是瀏覽器的主執行緒正在忙其他工作，例如解析與執行大量的 JavaScript，沒有空處理訪客的操作。
使用架站平台的企業網站，自己寫的程式通常不多，INP 問題更常來自後來加上的第三方程式：追蹤代碼、聊天外掛、社群嵌入與廣告程式。每一個單獨看都不大，同時載入就可能塞滿主執行緒。
- 列出網站上所有第三方程式與外掛：分析、廣告、像素、聊天、嵌入、彈出視窗工具
- 逐一確認是否還在使用、有沒有人在看它的資料；不再使用的直接移除
- 需要的追蹤程式改由一個代碼管理工具統一載入，方便控管與停用
- 嵌入內容只放在真正需要的頁面，不要每一頁都放社群動態牆
追蹤代碼的整理方式，在 網站行銷代碼怎麼裝中有完整的做法；社群貼文嵌入對速度的影響與取捨，則可以對照 網站和社群怎麼串的說明。兩篇都是使用 Sharing AI 架站平台時最常遇到的情境。
無障礙分數怎麼算？100 分不等於網站無障礙
PSI 報告中的「無障礙」分數，來自 Lighthouse 的一組自動化檢查。根據 Lighthouse 的計分說明，這個分數是所有無障礙檢查項目的加權平均，權重依照每個問題對使用者影響的程度設定；而且每個項目只有通過與不通過兩種結果，沒有部分得分。例如頁面上十個按鈕有九個有名稱、一個沒有，「按鈕要有可辨識的名稱」這一項就是零分。
| 檢查項目 | 權重 | 常見原因 | 修正方式 |
|---|---|---|---|
| 圖片要有替代文字（alt） | 10 | 上傳圖片時沒有填寫替代文字 | 為有意義的圖片寫出描述內容的 alt；純裝飾圖可以留空 alt |
| 按鈕要有可辨識的名稱 | 10 | 只有圖示、沒有文字的按鈕，例如搜尋放大鏡、漢堡選單 | 加上文字或替按鈕設定說明用的名稱 |
| 表單欄位要有對應的標籤 | 10 | 只用欄位內的提示文字，沒有真正的標籤 | 每個欄位都設定可見的標籤文字 |
| 不可禁止使用者縮放畫面 | 10 | viewport 設定禁止縮放或最大縮放倍率低於 5 | 移除禁止縮放的設定 |
| 前景與背景顏色要有足夠對比 | 7 | 淺灰字、白字配亮色按鈕 | 調整文字或背景顏色，達到 WCAG 對比度標準 |
| 連結不能只靠顏色區分 | 7 | 文中連結只換顏色、沒有底線 | 文中連結加上底線，或讓連結與周圍文字對比達 3:1 以上 |
| 網頁要設定語言（html lang） | 7 | 模板沒有宣告語言 | 繁體中文網站設定為 zh-Hant-TW 或 zh-TW |
| 標題層級要依序遞減 | 3 | H2 之後直接跳到 H4，或用標題標籤只為了放大字體 | 依內容結構使用 H2、H3，不要跳級 |
自動檢查只是起點
同一份計分說明也提到，需要人工確認的項目，以及影響較低或屬於建議性質的項目，並不計入分數。換句話說，自動化工具只能判斷「有沒有」，無法判斷「好不好」：它能發現圖片沒有替代文字，卻看不出你寫的替代文字是不是在亂填關鍵字；它能確認按鈕有名稱，卻不知道名稱是否讓人看得懂。無障礙分數 100 分，代表通過了所有自動檢查，不代表視障者、色覺辨識困難者或只用鍵盤的使用者都能順利使用網站。
實用的做法是把分數當成第一層篩選，再加上幾項人工檢查：只用鍵盤的 Tab 鍵能否走完主要流程、焦點位置看不看得到、放大到 200% 時文字是否仍可閱讀、替代文字是否真的描述了圖片內容。
對比度怎麼判斷？WCAG AA 與 AAA 的正確數值
對比度是無障礙檢查中最常被扣分的項目之一，也是網路上最常被說錯的數字。很多教學寫「文字與背景的對比度要達到 7:1」，這其實是把 WCAG 最嚴格的 AAA 等級，誤當成一般要求。正確的標準如下：
| 標準 | 等級 | 一般文字 | 大型文字 | 說明 |
|---|---|---|---|---|
| 1.4.3 對比（最低） | AA | 至少 4.5:1 | 至少 3:1 | 多數網站與規範採用的基本要求 |
| 1.4.6 對比（加強） | AAA | 至少 7:1 | 至少 4.5:1 | 更嚴格的等級，適合以閱讀為主或特殊需求的網站 |
| 1.4.11 非文字對比 | AA | — | — | 按鈕外框、表單欄位邊框、圖示等介面元件與相鄰顏色至少 3:1 |
根據 W3C 對 WCAG 2.1「對比（最低）」準則的說明，一般文字與背景的對比至少 4.5:1，大型文字至少 3:1，這是 AA 等級；7:1 屬於「對比（加強）」準則，是 AAA 等級。所謂大型文字，是指至少 18 點，或至少 14 點的粗體字，W3C 的換算是 1 點約等於 1.333 像素，也就是約 24px 的一般字重，或約 18.5px 以上的粗體。W3C 也提醒，筆畫特別細或造型特殊的字型，實際看起來會比較淡，使用這類字型時，建議仍以一般文字的標準檢查。
另外有幾種情況不受對比度要求限制：商標或品牌標誌中的文字、純裝飾用途的文字、照片中剛好出現的文字，以及停用狀態的介面元件。這也是為什麼品牌標誌即使顏色較淺，也不一定會被判定違規。
對比度要怎麼量
最簡單的方法是展開 PSI 無障礙區塊中的對比度項目，它會列出有問題的元素。自己挑顏色時，可以在 Chrome 開發人員工具中選取文字，顏色選擇器會顯示對比度數值與是否達到 AA、AAA。
文中連結只換顏色會被扣分：3:1 規則與底線
Lighthouse 的「連結不能只靠顏色區分」對應 WCAG 1.4.1「顏色的使用」準則（A 等級），檢查夾在文字中的連結：如果只差在顏色，色覺辨識困難或低視力的訪客可能看不出哪裡可以點。
依照 axe 規則說明，文中連結要符合以下其中一種狀況才算通過：連結有不依賴顏色的區分方式，例如底線、粗體或外框；或連結顏色和周圍文字的對比至少 3:1。若對比達到 3:1 但平常沒有其他樣式，還需要人工確認滑鼠移過或鍵盤聚焦時，連結會出現明顯變化。
這裡有一個實務上的難題：連結本身要和背景有足夠對比（白底上至少 4.5:1），又要和深色內文有 3:1 的差異，兩個條件同時成立的顏色其實很少。以常見的配色計算，深藍色連結 #1856b8 放在白底上的對比約 6.86:1，閱讀沒問題；但它和深灰色內文 #333333 之間的對比只有約 1.84:1，遠低於 3:1。也就是說，大多數「深色內文＋藍色連結」的網站，單靠顏色是不夠的。
最省事也最可靠的做法，是讓內文中的連結保留底線。底線不需要很粗，與文字稍微保持距離就不會影響閱讀美感。選單、按鈕、卡片這類一看就知道可以點的元件，不在這項檢查的範圍內，不必強加底線。
Search Console 的核心網頁指標報表：看全站，不看單頁
PSI 一次只能測一個網址，想知道整個網站有哪些頁面需要處理，要改看 Search Console 的核心網頁指標報表。兩者用的是同一份資料，都是 CrUX 的實際使用者資料，但呈現方式不同。
依照 Search Console 說明中心對核心網頁指標報表的說明，報表會把使用體驗相似的網頁歸成「網址群組」，並分成行動裝置與電腦兩部分；每個群組的狀態取決於表現最差的那一項指標，例如 CLS 不佳、LCP 需要改善，整個群組就顯示「不良」。報表只會顯示已建立索引的網址，而且是範例而非完整清單；資料量不足的網站會顯示目前沒有資料。
| 比較項目 | PageSpeed Insights | Search Console 核心網頁指標報表 |
|---|---|---|
| 看的範圍 | 單一網址（資料不足時改看整個來源） | 全站，依相似網頁分成網址群組 |
| 實驗室資料 | 有，附改善建議 | 沒有，需另外用 PSI 測試 |
| 適合用來 | 診斷單一頁面、驗證修改效果 | 找出哪一類頁面有問題、追蹤修正進度 |
| 驗證修正 | 重新測試即可看到實驗室結果 | 按「開始追蹤」後進行 28 天的監控期 |
修正的優先順序
Search Console 說明建議先處理「不良」，再處理「需要改善」，並優先處理影響最多或最重要網址的問題。修正後，在問題詳細資料頁按「開始追蹤」，系統會進行 28 天的監控，期間沒有網址再出現同樣問題，驗證才會通過。要注意的是，「開始追蹤」只是啟動監控，不會讓 Google 重新建立索引，也不會加快任何處理。
報表其他區塊的用法，例如成效報表與網址審查，整理在 Google Search Console 怎麼用，這裡只說明和速度、體驗相關的部分。
用 Sharing AI 架站平台時，哪些項目可以自己處理
使用架站平台時，主機與程式架構由平台負責；但影響 PSI 結果的另一半，是你放進網站的圖片、外掛、追蹤程式與配色。下表整理可以自己動手的部分：
| PSI 中的問題 | 可以自己做的事 | 主要影響 |
|---|---|---|
| 首屏圖片太大、LCP 慢 | 上傳前先縮小圖片尺寸，輪播看板只放必要的張數，第一張圖用最重要的畫面 | LCP、效能分數 |
| 版面跳動 | 同一組輪播圖片使用相同比例，嵌入地圖、影片時放在固定高度的區塊中 | CLS |
| 互動卡頓、TBT 高 | 在「設定 → 行銷代碼」檢查已啟用的代碼，停用不再使用的項目；嵌入內容只放在需要的頁面 | INP、TBT |
| 圖片缺少替代文字 | 每張有意義的圖片都填寫替代文字（ALT）；選單圖片同樣建議填寫 | 無障礙、SEO |
| 對比度不足 | 調整區塊文字顏色、按鈕底色；全站配色可在設計規範中統一 | 無障礙 |
| 連結只靠顏色區分 | 內文連結保留底線；自訂樣式時不要移除文中連結的底線 | 無障礙 |
| 表單欄位沒有標籤 | 表單欄位都設定清楚的欄位名稱，不要只用欄位內的提示文字 | 無障礙 |
表單欄位的命名與設計方式，在 網站表單怎麼設計有逐欄說明。至於伺服器回應、程式碼結構這類平台層級的項目，若 PSI 的建議指向這些部分，就不是網站擁有者能直接修改的範圍，可以把報告整理後交給平台或技術夥伴評估。
一份可以照做的檢查流程
- 每月一次打開 Search Console 核心網頁指標報表，記下行動裝置「不良」「需要改善」「良好」的網址數量
- 如果出現「不良」或「需要改善」，點進問題看是哪一項指標、哪一類網頁
- 從該類網頁挑一個代表網址，用 PSI 的行動裝置模式測試三次，記下實際資料與實驗室分數範圍
- 依指標對照本文的改善方向：LCP 看圖片與首屏，CLS 看預留空間，INP 看第三方程式
- 同時檢查無障礙未通過的項目，優先處理權重 10 的項目，例如替代文字、按鈕名稱與表單標籤
- 修改完成後再用 PSI 測試確認實驗室結果改善，並在 Search Console 按「開始追蹤」
- 網站改版、換模板、加裝新外掛或追蹤程式之後，額外做一次完整檢查
速度與無障礙都屬於「做好不一定加分、做不好一定扣分」的基礎工程。先讓真實訪客的核心網頁指標達到良好，把無障礙的明顯問題修正，再把主要心力放回內容本身。網站整體的技術檢查順序可以從 網站 SEO 健檢要先看什麼開始；如果想請人協助檢查網站的技術狀況並排出改善順序，也可以了解分享家的 AI SEO 顧問服務。