先看重點：網頁測試工具應該如何選擇
若要快速掌握網站問題，建議先用 Google PageSpeed Insights 進行 Google 網站速度測試，分別檢查行動版與電腦版，再以 WebPageTest、GTmetrix 或 Pingdom 執行不同地區的網站延遲測試。開發人員可進一步使用 Lighthouse、Chrome DevTools、Puppeteer 與 Chrome Headless；需要跨瀏覽器及實際裝置測試的團隊，則可使用 BrowserStack。
網站管理者不應只追求單一 Google 網站評分，而要同時觀察真實使用者資料、實驗室測試結果、伺服器回應、網頁載入速度、互動延遲及版面穩定性。速度分數本身不是唯一的搜尋排名訊號，真正重要的是使用者能否穩定、快速地瀏覽及操作網站。
網頁測試工具可以檢查哪些問題
網頁測試工具不只是測量「頁面幾秒開啟」，還可分析瀏覽器如何下載 HTML、CSS、JavaScript、字型、圖片及第三方資源。完整的網頁效能測試工具通常會提供載入瀑布圖、請求數量、檔案大小、快取設定、主執行緒工作及 Core Web Vitals 等資訊。
網頁載入速度與內容顯示
使用者開啟網址後，瀏覽器必須完成 DNS 查詢、建立連線、接收伺服器回應及下載資源。測試結果中的首次位元組時間、首次內容繪製及最大內容繪製，可以協助判斷延遲發生在主機、網路還是前端程式。
網頁載入速度也不能只看完整載入時間。即使背景程式尚未全部完成，只要主要內容很快出現且可以操作，使用者仍可能感覺網站流暢。
Core Web Vitals 核心指標
依照 Google 公開文件，Core Web Vitals 目前包括：
- 最大內容繪製 LCP：衡量主要內容顯示速度，良好標準為 2.5 秒以內。
- 下一次顯示內容所需時間 INP：衡量頁面的整體互動回應能力，良好標準為 200 毫秒以內。
- 累計版面配置位移 CLS：衡量畫面是否意外跳動，良好標準為 0.1 以下。
Google 通常以第 75 百分位數評估使用者體驗，並區分行動裝置與電腦裝置。因此，少數快速測試不代表所有訪客都能獲得相同體驗。
網站連線與延遲
測試網站連線時，應分開檢查 DNS、TCP、TLS、伺服器處理時間與內容傳輸時間。如果台灣主機在本地測試很快，但海外使用者等待時間很長，通常需要檢查主機地點、路由品質或 CDN 配置。
網站延遲測試也應涵蓋行動網路、較慢裝置及不同地區，而不是只在公司高速網路上測試。否則測得的結果容易過度樂觀。
常見網頁效能測試工具比較
不同工具採用的裝置、網路、瀏覽器版本及測試節點不同，分數不能直接互相比較。正確做法是選定相同工具與條件，持續追蹤網站更新前後的變化。
網頁測試工具功能比較表
| 工具 | 主要用途 | 資料或測試方式 | 適合對象 | 主要特色 |
|---|---|---|---|---|
| Google PageSpeed Insights | 速度與 Core Web Vitals 分析 | CrUX 真實資料及 Lighthouse 實驗室資料 | 站長、行銷與開發人員 | 操作直覺，可分別檢查行動版與電腦版 |
| Lighthouse | 效能、無障礙、SEO 與最佳實務檢測 | 模擬環境自動稽核 | 前端開發人員 | 可從 Chrome DevTools 或命令列執行 |
| Chrome DevTools | 即時除錯及效能分析 | 本機瀏覽器記錄 | 開發人員 | 可查看 Network、Performance 與 Coverage |
| WebPageTest | 深入載入流程與影片分析 | 多地區、多瀏覽器及多次測試 | 技術團隊 | 提供瀑布圖、視覺進度及重複瀏覽測試 |
| GTmetrix | 網頁效能報告與持續監控 | Lighthouse 及測試節點 | 站長、代理商 | 報告易讀，可追蹤歷史趨勢 |
| Pingdom Website Speed Test | 載入時間及資源分析 | 指定地區測試 | 非技術使用者 | 介面簡單，適合初步檢查 |
| BrowserStack | 跨瀏覽器與實際裝置測試 | 雲端瀏覽器及裝置 | QA 與企業團隊 | 涵蓋桌上型電腦、行動裝置及自動化測試 |
| Puppeteer | Chrome 自動化與效能流程 | Node.js 控制瀏覽器 | 開發與測試工程師 | 可擷取追蹤資料、截圖及自動執行流程 |
| Chrome for Testing | 固定版本 Chrome 自動測試 | 可重現的瀏覽器版本 | CI/CD 團隊 | 避免自動更新造成測試結果不一致 |
| Rich Results Test | 結構化資料與複合式搜尋結果資格 | Google 解析頁面或程式碼 | SEO 與網站管理者 | 檢查支援的結構化資料及錯誤 |
| Ranorex | 桌面、Web 與行動應用自動化 | 圖形介面及程式化測試 | QA 團隊 | 適合功能與回歸測試，不以測速為核心 |
| OWASP ZAP | Web 安全測試 | 被動及主動掃描 | 資安與開發團隊 | 用於找出常見安全弱點，不是速度評分工具 |
Google PageSpeed Insights 怎麼看
Google PageSpeed Insights，常縮寫為 PSI 或 pagespeed，是最常見的免費 Google 網站速度測試工具。使用者只要輸入公開網址，即可查看行動裝置與電腦裝置的分析結果。介面相對直覺，非技術人員也能理解主要指標與改善建議。
真實使用者資料
報告上方若有足夠資料，會顯示 Chrome 使用者體驗報告，也就是 CrUX 資料。這些資料來自符合條件的 Chrome 真實使用者，反映過去約 28 天的使用情況。
真實資料會受到訪客裝置、所在地、網路速度及快取狀態影響，較接近網站實際體驗。不過，流量較少的網址可能沒有足夠的網址層級資料，此時可能只顯示來源層級資料，或完全無法提供欄位資料。
Lighthouse 實驗室資料
PSI 下方的效能分析來自 Lighthouse 模擬測試。它在受控條件下執行，因此適合找出阻塞轉譯資源、過大的圖片、未使用的 JavaScript 及主執行緒負擔。
實驗室資料可能因伺服器狀態、第三方服務及測試環境而浮動。建議至少執行三次，觀察中位數，而不是以單次結果判定網站品質。
正確理解 Google 網站評分
Google 網站評分中的 Performance 分數是多項實驗室指標經加權後形成的綜合分數。分數達到 90 分以上通常會顯示為良好，但 100 分不代表網站在所有裝置、地區與使用情境下都沒有問題。
Google 也沒有表示 Lighthouse 的單一分數會直接成為搜尋排名分數。網站速度與頁面體驗有助於搜尋及轉換，但內容相關性、可檢索性、原創價值與整體網站品質仍然重要。
Lighthouse 與 Chrome 開發者工具
Lighthouse 是 Google 開發的開源自動化工具，可檢查效能、無障礙、最佳實務及 SEO。除了透過 PageSpeed Insights 使用，也能在 Chrome DevTools、命令列或自動化流程中執行。
Performance 效能記錄
Chrome DevTools 的 Performance 面板可記錄頁面載入及操作過程，呈現長任務、JavaScript 執行、樣式計算、版面配置及繪製活動。這類瀏覽器效能測試比單一分數更適合診斷互動卡頓。
例如 INP 不佳時，可檢查使用者點擊後是否執行大量 JavaScript、是否出現超過 50 毫秒的長任務，以及主執行緒是否被第三方程式占用。
Network 網路瀑布圖
Network 面板會顯示每項資源的開始時間、等待時間、傳輸大小與優先順序。開發人員可利用網路節流模擬較慢連線，也能停用快取，測試首次造訪者的體驗。
如果主要圖片很晚才開始下載，可能是圖片由 JavaScript 延後建立，或瀏覽器未能及早辨識。此時可檢查 HTML 結構、資源優先順序及預載設定。
Puppeteer、Chrome Headless 與 Chrome for Testing
這三項資源經常搭配使用，但功能並不相同。它們主要服務自動化測試、持續整合及可重現的瀏覽器環境。
Puppeteer
Puppeteer 是 Chrome 團隊維護的 JavaScript 函式庫，可透過高階 API 控制 Chrome 或 Firefox。測試人員可以自動開啟頁面、點擊按鈕、填寫表單、產生 PDF、擷取畫面及記錄效能資料。
它適合重複執行登入、購物車或表單流程，也能整合 CI/CD，在每次部署後檢查關鍵功能。若要評估實際使用者經驗，仍應搭配真實資料與實際裝置測試。
Chrome Headless
Chrome Headless 是沒有傳統視窗介面的 Chrome 執行模式。它保留瀏覽器的渲染與 JavaScript 能力，可在伺服器、容器及自動化環境中執行。
Headless 不是獨立效能評分工具，而是一種瀏覽器執行方式。開發者可透過 Puppeteer、Chrome DevTools Protocol 或自動化框架控制它。
Chrome for Testing
Chrome for Testing 提供專為自動化測試準備的 Chrome 版本，並有明確版本對應及下載方式。一般 Chrome 會自動更新，可能導致相同測試在不同日期使用不同版本；Chrome for Testing 則有助於固定環境，提升測試的可重現性。
Chrome 工具團隊也提供 ChromeDriver、DevTools Protocol、Lighthouse、CrUX 與 Web Vitals 相關資源。選擇工具時，應先區分「功能自動化」、「實驗室效能測試」與「真實使用者監控」三種需求。
BrowserStack 跨裝置測試
BrowserStack 提供雲端 Web 與行動應用程式測試環境，涵蓋多種桌上型瀏覽器、作業系統、行動裝置及螢幕尺寸。團隊不必自行購買及維護大量設備，也能檢查網站在不同環境中的相容性。
適合檢查的項目
BrowserStack 可用於手動互動測試、視覺差異檢查及 Selenium、Playwright 等自動化流程。測試報告、日誌、截圖與錄影有助於保存執行紀錄，方便團隊重現問題。
不過，跨裝置功能正常不代表速度一定良好。若主要目的是分析網站延遲測試、Core Web Vitals 及資源瀑布圖，仍應搭配 PageSpeed Insights、WebPageTest 或真實使用者監控系統。
複合式搜尋結果測試
複合式搜尋結果是 Google 產品中可能出現的特殊搜尋體驗。除了標準藍色連結，也可能包含圖片、評分、輪轉介面及其他非純文字元素。網站通常需要使用 Google 支援的結構化資料，才可能具備特定搜尋呈現形式的資格。
Rich Results Test 的用途
Google Rich Results Test 可檢查網頁中的結構化資料，並顯示偵測到的項目、錯誤與警告。使用者可以輸入網址，也可以直接貼上程式碼進行測試。
通過測試只代表頁面在技術上可能具備資格，不保證 Google 一定會顯示複合式搜尋結果。內容還必須符合 Google 搜尋政策、結構化資料規範及品質要求。部署後可透過 Google Search Console 查看相關報表與索引狀態。
如何建立正確的網站測試流程
只測首頁容易忽略真正影響使用者的頁面。電商網站應涵蓋商品分類、商品頁、購物車及結帳流程；內容網站則應測試文章、分類與站內搜尋頁面。
建議測試步驟
- 選出流量、轉換或商業價值較高的代表頁面。
- 使用 PageSpeed Insights 查看真實資料與實驗室結果。
- 分別測試行動版與電腦版，不混合解讀。
- 使用 WebPageTest 或 GTmetrix 查看瀑布圖及視覺載入過程。
- 透過 Chrome DevTools 定位 JavaScript、圖片與主執行緒問題。
- 使用 BrowserStack 檢查不同裝置與瀏覽器的功能。
- 部署網站速度優化項目後，在相同條件下重新測試。
- 持續追蹤 Google Search Console 的 Core Web Vitals 及真實使用者資料。
每次測試都應記錄日期、網址、工具版本、測試地區、裝置、網路條件與測試結果。只有維持相同條件，才能判斷變化來自網站修改，還是來自測試環境。
網站速度優化的執行順序
速度問題需要依據測試資料處理，不宜安裝大量外掛或盲目刪除程式。優先處理影響主要內容、互動及版面穩定性的項目，通常能取得較明顯的改善。
優先改善伺服器與快取
若首次位元組時間偏高，應檢查主機資源、資料庫查詢、後端程式、頁面快取及 CDN。前端檔案再小，也無法完全補償伺服器長時間沒有回應的問題。
靜態資源可設定適當的瀏覽器快取，並採用內容雜湊版本控制。全球或跨區域網站可評估 CDN，但仍需確認 HTML 與動態內容的快取策略是否正確。
最佳化圖片與字型
圖片通常占據大量傳輸體積。網站可使用 WebP 或 AVIF 等現代格式，依顯示尺寸提供適當圖片，並對非首屏圖片設定延遲載入。LCP 圖片則不應因錯誤的延遲載入設定而延後下載。
網頁字型應減少不必要的字重與字元範圍，並設定合理的 font-display 策略。若預載過多字型，反而可能搶占主要圖片與 CSS 的下載頻寬。
控制 JavaScript 與第三方程式
大量 JavaScript 會增加下載、解析、編譯及執行成本，尤其容易影響低階手機。可透過程式碼分割、延後載入、移除未使用套件及縮短長任務，改善互動延遲。
廣告、聊天工具、追蹤碼與社群元件也可能影響效能。網站應評估每個第三方程式的商業價值，並確認是否能在取得同意或使用者互動後再載入。
避免版面位移
圖片、影片與廣告區塊應預留寬高或使用 CSS 長寬比。不要在既有內容上方突然插入橫幅，也應避免字型替換導致文字尺寸大幅改變。這些措施有助於降低 CLS 並減少誤點。
常見測試錯誤
測試結果可能受到登入狀態、快取、外掛、地區、網路及第三方服務影響。若沒有控制條件，容易得出錯誤結論。
把網路測速當成網站測速
一般網路速度測試衡量使用者端連線的下載、上傳與延遲；網站效能測試則分析特定頁面的伺服器、資源及瀏覽器執行狀況。兩者目的不同，不能互相取代。
只測一次就下結論
單次測試可能遇到冷快取、主機瞬間負載或第三方服務波動。建議執行多次並觀察中位數，同時比較首次瀏覽與重複瀏覽。
只追求 100 分
為了提高分數而移除必要功能，可能傷害內容、轉換及無障礙體驗。網站速度優化的目標應是讓實際使用者更快完成任務，而不是只讓測試畫面變成綠色。
使用 HTML 代碼測試器取代效能工具
HTML、CSS 與 JavaScript 線上代碼測試工具適合驗證語法或快速執行片段，但通常無法模擬完整網站的網路、伺服器與第三方資源。若要判斷實際效能，仍需使用瀏覽器效能測試與完整頁面測速工具。
結論
有效的網站測試需要結合多種資料。PageSpeed Insights 適合快速了解 Google 網站評分、Core Web Vitals 及常見改善方向；Lighthouse 與 Chrome DevTools 適合技術診斷；WebPageTest、GTmetrix 及 Pingdom 可補充不同節點與載入瀑布圖；BrowserStack 則負責跨瀏覽器、桌上型電腦與行動裝置的相容性驗證。
執行 Google 網站速度測試時，應同時檢查真實使用者資料與實驗室資料，並用一致條件反覆測量。最終目標不是獲得單一高分，而是縮短網頁載入速度、降低互動延遲、保持畫面穩定，讓搜尋訪客與實際客戶都能順利使用網站。
常見問題
1. 哪一款網頁測試工具最適合新手？
Google PageSpeed Insights 最適合入門。只要輸入網址，就能取得行動版與電腦版結果、Core Web Vitals、效能分數及改善建議，不必安裝軟體。
2. PageSpeed Insights 分數多少才算好？
Lighthouse 效能分數 90 至 100 通常屬於良好，50 至 89 表示需要改善，低於 50 則較差。但分數只是實驗室評估，仍應優先查看真實使用者的 LCP、INP 與 CLS。
3. 為什麼同一個網站每次測試分數不同？
伺服器負載、網路狀態、快取、廣告、分析工具及第三方 API 都可能造成波動。建議測試至少三次，採用中位數並維持相同地區、裝置與網路條件。
4. Google 網站評分會直接影響 SEO 排名嗎？
Google 沒有將 Lighthouse 單一分數直接當成搜尋排名分數。Core Web Vitals 與頁面體驗可能影響搜尋表現，但內容品質、相關性、可檢索性及其他搜尋訊號仍然重要。
5. 行動版和電腦版應該以哪一個為準？
兩者都要檢查，但若網站多數流量來自行動裝置，應優先處理行動版。行動裝置的硬體與網路條件通常較受限制，也更容易暴露 JavaScript 及圖片問題。
6. 如何測試網站在海外的連線速度？
可以使用 WebPageTest、GTmetrix 或 Pingdom 選擇不同地區的測試節點，再比較 DNS、TLS、首次位元組時間及完整載入流程。若海外延遲明顯，可進一步評估 CDN 與主機地點。
7. Lighthouse 和 PageSpeed Insights 有什麼不同？
PageSpeed Insights 是 Google 提供的線上服務，可同時顯示 CrUX 真實資料與 Lighthouse 實驗室結果。Lighthouse 則是開源稽核工具，可在 Chrome DevTools、命令列及自動化環境中執行。
8. BrowserStack 可以取代 PageSpeed Insights 嗎？
不能完全取代。BrowserStack 強項是跨瀏覽器、作業系統及實際裝置測試；PageSpeed Insights 則著重網頁效能與 Core Web Vitals。兩者適合搭配使用。
9. 網站速度優化應先處理哪一項？
應先從測試結果中找出影響最大的瓶頸。常見優先項目包括降低伺服器回應時間、最佳化 LCP 圖片、移除阻塞資源、減少 JavaScript 長任務及修正版面位移。
10. Rich Results Test 通過後一定會顯示複合式搜尋結果嗎？
不一定。通過測試只表示結構化資料在技術上可能符合資格，Google 仍會依內容品質、搜尋需求、政策及其他系統決定是否顯示特殊搜尋結果。