PageSpeed Insights 的 Performance 分數不是 Google 直接拿來排序的 SEO 分數。 但 PSI 所檢測的網站速度、Core Web Vitals 與使用者體驗，和 Google 搜尋所重視的整體頁面體驗有關。
一、PageSpeed Insights 和 SEO 到底有沒有關係？
Google 搜尋系統會考量整體頁面體驗，Core Web Vitals 是評估真實使用者體驗的核心指標之一， 但沒有單一的「Page Experience 分數」決定網站排名。
- PageSpeed Insights 是網站效能檢測工具。
- Performance 0～100 分主要來自 Lighthouse 的實驗室測試。
- Core Web Vitals 反映真實使用者的載入、互動與版面穩定體驗。
- Google 排名還會同時考量內容相關性、品質、網站架構、連結與其他因素。
Google 官方資料可參考： Understanding Core Web Vitals and Google Search results
二、什麼是 Google PageSpeed Insights？
Google PageSpeed Insights 是 Google 提供的免費網站效能分析工具，可以檢測網頁在行動裝置與桌上型電腦上的效能表現。
PSI 主要會提供兩類資料：
| 資料類型 | 來源 | 用途 |
|---|---|---|
| Field Data 真實使用者資料 | Chrome User Experience Report（CrUX） | 了解真實 Chrome 使用者過去一段時間的網站體驗。 |
| Lab Data 實驗室資料 | Lighthouse | 在模擬環境執行測試，找出效能問題與改善方向。 |
做 SEO 判斷時，不要只看當下跑一次的 Lighthouse 分數。 若 PSI 有提供真實使用者資料，應優先觀察 Core Web Vitals 的 Field Data，再利用 Lab Data 找出改善原因。
因為測試環境、網路速度、裝置效能與伺服器當下狀況不同， 同一個網站即使完全沒有修改，PageSpeed Insights 每次測試的分數仍可能不同。
三、如何使用 PageSpeed Insights？
直接進入：
https://pagespeed.web.dev/?hl=zh-TW
- 輸入要檢測的網頁網址。
- 點擊「分析」。
- 分別查看「行動裝置」與「電腦」結果。
- 優先確認 Core Web Vitals，再查看 Lighthouse 診斷項目。
Google 採用 Mobile-first Indexing，也就是主要使用網站的手機版內容進行索引與排名， 所以 SEO 檢查時，手機版網站的內容與使用體驗尤其不能忽略。
四、PageSpeed Insights 多少分才算好？
Lighthouse 的 Performance 分數介於 0～100，常見區分如下：
| Performance 分數 | 狀態 | 怎麼看 |
|---|---|---|
| 90～100 | 良好 | 實驗室測試的效能表現良好。 |
| 50～89 | 需要改善 | 建議檢查 LCP、JavaScript、圖片與其他效能瓶頸。 |
| 0～49 | 較差 | 通常存在比較明顯的載入或執行效能問題。 |
重要
不要把 90 分當成 SEO 及格線。
例如某網站 PSI 只有 82 分，但真實使用者的 Core Web Vitals 都達標， 內容又比競爭網站完整，它完全可能排得比 PSI 100 分、內容卻很薄弱的網站更前面。
五、PageSpeed Insights 100 分，SEO 就一定比較好嗎？
不一定。
Google 搜尋排名不是 PageSpeed 比賽。 使用者搜尋某個問題時，Google 還是必須找到真正符合搜尋意圖、內容可靠，而且容易使用的頁面。
所以一個網站即使 PSI 100 分，如果：
- 內容與使用者搜尋問題無關；
- 文章內容過薄；
- 標題與內文主題不一致；
- 網站架構混亂；
- 重要頁面難以被 Google 爬取；
仍然不會因為速度快就自動取得好的搜尋排名。
實務上比較合理的目標：
先把嚴重影響使用者的速度問題解決， 再將時間投入內容、搜尋意圖、網站架構、內部連結與轉換設計， 通常比花大量時間追求 PSI 100 分更有價值。
六、什麼是 Core Web Vitals 網站體驗核心指標？
Core Web Vitals 是 Google 用來衡量真實使用者網頁體驗的一組核心指標。 目前主要包含 LCP、INP 與 CLS。
| 指標 | 良好標準 | 主要測量內容 |
|---|---|---|
| LCP | ≤ 2.5 秒 | 頁面主要內容顯示速度。 |
| INP | ≤ 200 ms | 使用者點擊、輸入、操作後的反應速度。 |
| CLS | ≤ 0.1 | 頁面載入過程中是否出現意外版面位移。 |
1. LCP 最大內容繪製（Largest Contentful Paint）
LCP 測量頁面主要內容出現在畫面上的速度。 常見的 LCP 元素包含 Hero 圖片、大型 Banner、主要標題或大面積內容區塊。
2. INP 互動到下一次繪製（Interaction to Next Paint）
INP 測量網頁對使用者互動的回應速度，例如點擊按鈕、展開選單或輸入內容之後， 網頁多久能產生視覺回應。
INP 已在 2024 年 3 月取代 FID，成為 Core Web Vitals 的互動性核心指標。
3. CLS 累計版面配置位移（Cumulative Layout Shift）
CLS 用來判斷網頁內容是否會在載入過程中突然移動。 例如你正準備點「購買」，結果 Banner 突然載入，整個按鈕往下跳，就是典型的 CLS 問題。
其他常見網站效能指標
FCP 首次內容繪製（First Contentful Paint）
測量瀏覽器第一次顯示文字、圖片或其他內容的時間。
FID 首次輸入延遲（First Input Delay）
FID 過去是 Core Web Vitals 的其中一項指標， 2024 年 3 月開始由 INP 取代，目前可視為歷史指標。
TTFB 第一個位元組時間（Time to First Byte）
TTFB 測量瀏覽器提出請求後，到收到伺服器第一個位元組資料所需要的時間。 如果主機、資料庫或後端程式回應太慢，TTFB 通常也會跟著變差。
七、如何解讀 PageSpeed Insights 報告？
PageSpeed Insights 的 Lighthouse 報告通常包含以下類別：
1. Performance 網站效能
綜合 FCP、LCP、Speed Index、TBT、CLS 等 Lighthouse 指標計算效能分數， 用來協助開發人員發現頁面載入與執行問題。
2. Accessibility 無障礙功能
檢查圖片替代文字、色彩對比、表單標籤、鍵盤導覽等無障礙使用問題。
3. Best Practices 最佳作法
檢查網站安全性、瀏覽器相容性與常見前端開發問題。
4. SEO 搜尋引擎最佳化
Lighthouse 也會進行部分基礎 SEO 技術檢查。 但這不是完整 SEO 健檢，更不能把這裡的 100 分解讀成「Google SEO 100 分」。
八、PageSpeed Insights 常見問題與網站速度改善方法
PSI 會列出目前頁面可能存在的效能問題，以及可能節省的傳輸量或時間。 不過不用看到紅色項目就全部修改，應先找出真正影響 LCP、INP 與使用者體驗的問題。 遇到不同指標偏低，優先檢查的方向也不同：
| PSI 問題 | 優先檢查 |
|---|---|
| LCP 過慢 | Hero 圖、TTFB、CSS、字型 |
| INP 過高 | JavaScript、第三方程式、主執行緒 |
| CLS 過高 | 圖片尺寸、Banner、動態內容 |
| TTFB 過慢 | 主機、快取、資料庫、後端程式 |
| 圖片傳輸量過大 | WebP／AVIF、尺寸、壓縮 |
| 未使用 CSS / JS | 外掛、頁面建構器、第三方套件 |
1. 使用 Google Search Console 檢查 Core Web Vitals
登入 Google Search Console ，查看 Core Web Vitals 報告，確認哪些網址群組存在「良好」、「需要改善」或「不良」問題。
2. 減少阻礙轉譯的 CSS、JavaScript 與第三方程式
CSS、JavaScript、字型或第三方工具如果在頁面初期大量載入， 可能延後主要內容顯示時間。
- 查看 PSI 報告中的相關診斷項目。
- 確認是哪一個 CSS、JavaScript 或第三方服務造成阻塞。
- 判斷資源是否真的需要在第一時間載入。
- 視情況採用移除、延遲載入、程式碼分割或其他最佳化方法。
如果你對程式或網站開發不熟悉， 歡迎與益盛科技聯絡，我們可以先檢查問題，再評估需要處理的範圍與報價。
3. 改善伺服器回應與 TTFB
如果網站後端產生頁面本身就需要很久， 即使前端圖片全部壓縮，使用者還是必須先等伺服器回應。
常見改善方式包括：
- 改善主機與伺服器效能：確認 CPU、RAM、儲存設備與網路環境是否足夠。
- 使用快取：避免每次請求都重新產生完整頁面。
- 改善程式邏輯：移除不必要的後端處理。
- 改善資料庫查詢：建立適當索引並減少低效率查詢。
- 使用 CDN：縮短部分靜態資源到使用者之間的傳輸距離。
益盛科技網站升級案例：
4. 優化網站圖片
大型圖片通常是網站載入速度問題中最常見、也最好處理的一類。 特別是首頁 Banner、產品圖片、案例照片，如果直接上傳數 MB 原圖，很容易拖慢 LCP。
- 上傳前先壓縮圖片。
- 依用途選擇 JPEG、PNG、WebP 或 AVIF 等格式。
- 不要用 3000px 圖片顯示在只有 500px 的區塊。
- 使用適當的 responsive images，例如 srcset。
- 畫面外圖片可以使用 Lazy Loading。
- 首屏 LCP 圖片不要一律設定 Lazy Loading，否則可能反而延後主要內容顯示。
原本使用 WordPress 的網站，也可以使用 TinyPNG、ShortPixel 或其他圖片壓縮工具協助處理圖片。
5. 減少關鍵請求鏈
網頁載入時，如果 A 資源必須等 B、B 又必須等 C， 就可能形成很長的關鍵請求鏈。 請求彼此依賴越多，主要內容出現在畫面上的時間就可能越晚。
改善方式要先判斷哪些資源需要優先載入、哪些可以延後， 不是單純把所有 JavaScript 都加上 async 或 defer。
async 與 defer 都可以避免傳統 script 阻塞 HTML 解析， 但執行方式不同，修改前仍需要測試網站功能。
6. 正確預載重要資源
Preload 可以告訴瀏覽器某些資源需要提早取得。 常見使用情境包括重要字型、LCP 圖片或頁面初期必要資源。
但不是所有圖片、CSS、JavaScript 都應該 preload。 預載太多反而會搶占頻寬，所以應根據實際效能報告決定。
WordPress 網站可以透過效能最佳化外掛處理部分預載設定； 其他網站則建議由開發人員判斷哪些資源真的需要提前載入。
7. 減少不必要的 CSS 與 JavaScript
網站使用大量套件、動畫、追蹤工具或頁面建構器時， 很容易累積沒有實際使用到的 CSS 與 JavaScript。
可以採用程式碼壓縮、移除未使用資源、延後非必要 JavaScript、 程式碼分割、快取以及 Gzip 或 Brotli 等方式降低傳輸與執行成本。
WordPress 常見效能工具包括 Hummingbird、LiteSpeed Cache、W3 Total Cache 等， 但外掛不是裝越多越快，實際上多套快取工具互相衝突反而可能造成網站異常。
Joomla 本身也提供 Gzip 頁面壓縮設定。 不同 Joomla 版本的管理介面可能有所差異， 可從全站設定或伺服器相關設定中確認是否啟用。
8. 延後載入畫面外圖片
對於首屏看不到的圖片，可以透過 Lazy Loading 延後載入， 避免使用者一進入頁面就下載所有圖片。
重要
首頁第一個大型 Banner 或 LCP 圖片通常不適合盲目設定 lazy loading， 否則可能讓最重要的圖片反而更晚出現。
9. 避免 DOM 過大
DOM 可以簡單理解成瀏覽器看到的 HTML 頁面結構。 如果頁面堆了大量巢狀區塊、隱藏元素與頁面建構器產生的多餘標籤， 瀏覽器處理與重新計算版面的成本也會增加。
改善方式包括：
- 移除沒有必要的 HTML 元素。
- 避免過度巢狀的 DIV。
- 清除從 Word、網頁或編輯器貼入的多餘 inline style。
- 減少沒有實際使用的模組與外掛。
- 透過 Chrome DevTools 檢查大型 DOM 與效能瓶頸。
10. 修正多重 Redirect 重新導向
網址從 A 轉 B，再從 B 轉 C，最後才到 D， 使用者與搜尋引擎都需要經過額外請求。 最理想的做法通常是讓舊網址直接轉到最終網址。
可以使用 Semrush Site Audit 或其他網站爬蟲工具檢查 redirect chains。
WordPress 有 Redirection、Easy Redirect Manager 等工具可以管理重新導向。
Joomla 也有內建「重新導向」功能， 可以將已不存在的網址導向新的有效頁面。
11. 避免過度使用第三方程式碼
Google Analytics、Google Tag Manager、Facebook Pixel、客服工具、 熱圖、影音播放器、廣告與第三方 Widget 都可能增加 JavaScript 執行成本。
這些工具可以繼續使用，但應該定期盤點： 現在真的還需要嗎？
如果需要更完整的網站技術檢測，也可以使用 Semrush Site Audit 檢查網站錯誤、警告與技術 SEO 問題。
建立 Site Audit 專案：
查看 Site Health 整體健康分數：
依 Errors／Warnings 分級檢視問題：
查看每個問題的修復方式：
追蹤網站改善趨勢：
設定定期自動掃描：
九、PageSpeed Insights 與 SEO 常見問題
不應把 PSI Performance 0～100 分直接理解成 Google 排名分數。 Google 搜尋使用多種訊號與系統判斷頁面， 網站速度與 Core Web Vitals 屬於整體頁面體驗的一部分。
不一定。90～100 代表 Lighthouse 實驗室效能測試屬於良好區間， 但 SEO 不存在「90 分才及格」的規則。 建議同時確認真實使用者 Core Web Vitals 與網站實際使用情況。
行動裝置測試會模擬較低效能的裝置與受限網路環境， 大型圖片、JavaScript、第三方程式與慢速伺服器在這種環境下更容易被放大。 手機版分數比桌機低並不罕見。
不一定。搜尋結果還取決於內容是否符合搜尋意圖、網站品質、 內容相關性、網站架構與其他搜尋訊號。 不應為了追求 100 分而忽略網站真正的內容與轉換目的。
不要先猜。 建議先用 PSI、Search Console 或 Chrome DevTools 找出瓶頸。 如果 LCP 差，就先檢查首屏圖片、TTFB 與主要 CSS； 如果 INP 差，則優先檢查 JavaScript 與第三方程式。
不是。Core Web Vitals 並不是唯一排名條件。 但如果兩個頁面的內容品質與相關性相近，更好的使用者體驗仍然是值得改善的優勢。
代表 Chrome User Experience Report 目前沒有足夠的真實使用者資料可供顯示，不代表網站有問題。 這時可以先利用 Lighthouse Lab Data 找出效能瓶頸，再搭配 Search Console 持續觀察。
PageSpeed 分數低，不一定只是主機慢
圖片、JavaScript、第三方追蹤工具、CMS 外掛、資料庫、 伺服器設定與網站架構都可能造成效能問題。 如果不知道問題出在哪裡，建議先檢測，再決定要不要改程式或升級主機， 也可以直接參考益盛科技的 SEO 服務內容。
十、相關文章
PageSpeed／SEO 延伸閱讀
更多網站 SEO 文章
- 關鍵字 SEO 優化步驟：提升網站可見度
- 利用 ChatGPT 提升 SEO！19招指令應用指南！
- 9款 SEO 工具大解析：讓網站 SEO 優化事半功倍
- 提升網站轉化率的20個實用工具推薦
- SEO：電子商務內容行銷帶來曝光率增加6倍，點擊率增加19倍
- SEO 從零開始：打造月營業額100萬的電商網站策略大揭秘
網頁設計問與答
SEO 及廣告投放問與答： https://des13.com/faq/seo.html
網站建置報價相關： https://des13.com/faq/quote.html
網站建置技術相關： https://des13.com/faq/webtech.html
購物網站／網路開店： https://des13.com/faq/e-commerce.html
B2B 形象官網建置： https://des13.com/faq/b2b.html
如果您喜歡我們的文章，歡迎分享！ 也歡迎查看其他網站設計、SEO 與網站經營相關文章。 如果有任何疑問，也歡迎加 LINE 與我們聯絡。
全後台模組化形象官網，符合各式商業模式與需求，請參考： https://des13.com/service/rwd.html
