PageSpeed 100 分又怎樣？全綠也可能在 SEO 排名輸給慢網站

字型怎麼載入才不會拖慢、又不位移？

在之前的文章中文 Web Font 踩雷記事本有探討過 FOUT 和 FOIT 的問題，在 PageSpeed Insight 的評分裡，也會看到一些關於「字型顯示」的評分項目。

關鍵是讓字先顯示、縮小字型檔，再讓替代字型與正式字型的尺寸接近，而不是把整包中文字型塞進 preload 就算完成，這句話不是一件事，而是好幾件事。

首先讓字先顯示，可以在 CSS 加入 font-display: swap 可以避免字型下載期間整段文字空白。

再來縮小字型檔，只保留網站實際會用到的字元並輸出成額外的字體檔案。實作方式在之前的文章有探討過 用 FontForge 做 tree-shaking 減少網頁字型檔案大小

如果是雲端字體(webfont)，最好選擇中文字型有做 subset 動態子集的，像 Google Fonts 的思源黑體和 Cloudflare Fonts 都有這種把字體分片切成小檔案的設計。

在之前的文章 Google Fonts 遭指用免費字型追蹤使用者? 研究各家 web font 的實作方式和隱私條款有探討過各家 web font 的實作方式，會發現像 Bunny Fonts 之類的某些 webfont 服務，雖然產品主打隱私、GDPR 合規之類的是很好，但是在網頁前端效能的議題上是 0 分，會把所有字元都放在單一個字體檔案裡，讓使用者端的裝置多浪費頻寬下載檔案，這也會導致分數下降。

如果替代字型與正式字型的字寬、行高差很多，則可用 size-adjust、ascent-override 等描述值微調，降低換字型時的 CLS。

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont-subset.woff2") format("woff2");
  font-display: swap;
}

@font-face {
  font-family: "MyFont Fallback";
  src: local("Arial");
  size-adjust: 105%;
  ascent-override: 90%;
}

body {
  font-family: "MyFont", "MyFont Fallback", sans-serif;
}

現實專案狀況

剛剛講了一堆，還沒講到字重的情況，如果頁面上的文字需要多種不同的字體粗細，那載入的檔案數量就會成倍增加，對分數的影響也會更大。理想情況是設計端先確認需要哪些字重，前端只輸出用得到的檔案。

現實卻常遇到品牌規範一次指定五、六種字重，CMS 內文又可能出現任何中文字，沒辦法做預先壓縮或激進的subset。萬一少放一個粗細度，就會導致網頁文字的字重顯示異常，可能大標題字變得超細。

反向優化翻車

只加 font-display: swap，但替代字型和正式字型差太多，字型換上去時整段文字重新換行，CLS 反而增加。

另一種常見翻車是把完整思源黑體與多種字重全部 preload，網頁載入時，瀏覽器把下載字型當成最高優先任務，真正的 LCP 圖片或其他重要的檔案反而被延後載入，讓網頁開啟載入速度變得更慢，分數更難看。

讓這些第三方套件真的開始瀏覽時再觸發

一樣不要聽從官方的嵌入碼，自己把那些 Facebook, LINE 嵌入碼改寫掉，例如先改寫成 lazyload 之類的機制，網頁開始捲動後，才載入這些社群網站套件。

一個幾乎沒內容的空網頁測試頁4，也能回到比較正常的分數了。但因為目前 PageSpeed 主要是測網頁首次顯示的首屏，如果改天增加一種評量方式，會把網頁從頭捲動到尾，那這種奧步又失效了。

這些社群套件各有不同的雷，例如:

• FB Customer Chat 在 LINE 瀏覽器上，會有登入之後，還會再叫人登入，偶發無法成功紀錄登入狀態的問題
• 有時候在 Android 行動裝置上的瀏覽器，那些套件會讓網頁畫面卡住無法捲動
• Page Plugin 會遇到封面圖跑不出來(hide_cover參數是false)，但是換一張粉專封面圖就又可以…之類千奇百怪的問題。

為了安全起見，盡量能改用自己做圖片+超連結，不要顯示即時資料的就好了。否則喜歡三不五時沒事找事做、幫自己改不到的網站 debug 的，就歡迎多多使用這些社群外掛套件的「原廠」嵌入碼。

讓這些第三方套件真的開始操作時再觸發

例如 YouTube、地圖、聊天視窗與社群外掛可以先顯示靜態門面，等使用者點擊後再換成真正的 iframe 或 SDK。

這些第三方套件如果不是一打開網頁就要用，先別急著載入；等使用者真的看到或點擊時再載入，通常最有效。

<button class="video-facade" type="button" data-video-id="abc123">
  <img src="/img/video-cover.jpg" alt="播放影片" width="640" height="360">
  <span>播放影片</span>
</button>

<script>
document.querySelector(".video-facade").addEventListener("click", function () {
  const iframe = document.createElement("iframe");
  iframe.src = `https://www.youtube.com/embed/${this.dataset.videoId}?autoplay=1`;
  iframe.width = "640";
  iframe.height = "360";
  iframe.allow = "autoplay; encrypted-media";
  this.replaceWith(iframe);
});
</script>

使用 Web Worker 搬移第三方套件的程式碼

追蹤碼或廣告程式也有人用 Partytown 搬到 Web Worker。Web Worker 就像瀏覽器另外開一條背景工作線，讓部分 JavaScript 不必和畫面更新、按鈕操作擠在同一條主執行緒上，降低網頁卡頓。

實作方式是在專案內安裝 Partytown 的程式，然後把那些廣告追蹤程式碼改成<script type="text/partytown">..，但這只適合經過驗證、能在 Web Worker 環境運作的腳本。

但這玩意會用到很多瀏覽器機制，前端老韭菜都知道肯定有瀏覽器相容性問題，像是其中一個 JavaScript built-in: Atomics 需要 iOS Safari 15.2 才支援。

實務問題是行銷部門可能要求 GA、廣告轉換、客服與 A/B test 全部在第一時間啟動，這樣數字才會比較好看。甚至有些供應商條款不允許我們這樣擅自偷改嵌入碼。

反向優化翻車

這種點擊後換成 iframe 或真正其他內容的技巧，若內容毫無規律，萬一前後設定的高度不同，容易製造 CLS，影響使用者體驗。

另一種翻車是把所有 script 一律加 defer、搬進 Worker，結果相依順序被打亂，或 SDK 需要直接操作 document 而整個失效；分數可能變好，網頁上的 JS 程式、表單、廣告或轉換追蹤卻壞掉。

圖片除了壓縮，還能怎麼再加速？

最大的原則，首屏主圖要優先下載，畫面外的圖片才延遲載入，並用 AVIF、WebP 與 JPG 提供逐級相容的格式。

<picture>
  <source type="image/avif" srcset="/img/hero.avif">
  <source type="image/webp" srcset="/img/hero.webp">
  <img
    src="/img/hero.jpg"
    alt="主視覺"
    width="1200"
    height="600"
    fetchpriority="high">
</picture>

AVIF 通常比 WebP 更小，但不代表每張圖都一定更清楚或更省。
照片、透明圖、帶有大量文字的廣告圖，每種圖片適合的格式與壓縮參數都不同。專案若有十幾年舊圖、多人上稿與多個外部通路，不一定能一次把整套圖片流程換掉，可以先處理首頁主視覺、商品首圖與流量最高的文章。

反向優化翻車

不小心把首屏 LCP 圖也加上 loading="lazy"，會讓瀏覽器延後下載最重要的圖片，反而造成 LCP 被扣分。

沒有設定好 CSS min-height、aspect-ratio，與真實圖片比例不同，圖片載入後還會把內容擠開，讓 CLS 項目被扣分，得分更差。

反向優化翻車

一次對十幾個網域 preconnect，會提前建立大量可能根本用不到的連線，搶走頻寬、CPU 與連線額度。

原本想加速字型或主圖，結果先把資源分給不重要的追蹤程式碼、廣告代碼，LCP 反而更慢。

反向優化翻車

把輪播每一張、所有字型與數支 JavaScript 全部 preload，只是把原本排隊下載的資源改成一起搶頻寬。尤其預載了錯誤尺寸的圖片，瀏覽器之後仍可能再下載真正需要的版本，造成重複流量。

系統允許編輯人員直接上傳 300 dpi、數 MB 的原始照片，一旦把這種超級大圖設定 fetchpriority=high 之類的，載入網頁時直接卡在下載這些大圖。

反向優化翻車

aspect-ratio 不是隨便填個 16 / 9 就會自動正確，如果為了消除 CLS 而亂加 CSS，但卻沒有依照實際內容調整，把每個區塊都寫死成過大的高度，雖然指標可能改善，手機畫面卻充滿空白。

反過來，如果比例寫錯，圖片載入後仍會重排；或是讓內容被裁切。

反向優化翻車

全站搜尋取代，把每個 img 都加上 lazy loading，連 LCP 元素的圖片也一起延遲；或是圖片沒有尺寸，雖然晚點才載入，載入時照樣造成 CLS。延遲載入只能延後請求，不能取代尺寸設定與圖片壓縮。

反向優化翻車

沒有搭配 contain-intrinsic-size 提供合理預估高度，捲到該區塊時頁面總高度才突然改變，捲軸位置與內容一起跳。預估值若和實際高度差太遠，也只是把 CLS 從載入時延後到捲動時發生，也許只是改善分數，但實際使用者瀏覽網頁時非常不舒服。

另一種翻車，是直接把 content-visibility: auto 加在包住整頁內容的大容器，連裡面的 position: fixed 元素也一起受到影響。跑分可能只改善一點，原本固定在右下角的客服按鈕或回到頁首按鈕卻開始亂跑。

反向優化翻車

成熟專案可能已經在幾百個地方使用 icon font class，直接全面改成 SVG 的工時與風險都很高，一不小心就有 icon 沒換掉、SVG 字串被 AI coding agent 亂改，顏色不對等各種問題。

然後每個 inline SVG 都有一大段重複路徑，最後 HTML 體積可能比原本字型還大。

另一種問題是 SVG 沒有處理 aria-hidden、title 或可讀標籤，跑分變快了，無障礙反而退步。

Speculation Rules：讓下一頁預先載入

Speculation Rules 讓瀏覽器在背景先 prefetch 或 prerender 使用者可能會去的下一頁，點過去時 LCP 幾乎瞬間完成。

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/products/*" },
    "eagerness": "moderate"
  }]
}
</script>

對使用者感受有效，但跑分不動的原因是：PageSpeed 是「當場空手去跑」，不是「已經 prerender 完的狀態」，所以分數不受影響。另外無差別 prerender 整個網站會白耗使用者流量與伺服器資源，分析工具還可能收到根本沒人真正看過的 pageview。

WordPress 這邊有一段時期，官方跟不少協力主機商、擴充套件，都在主打「Speculative Loading」功能，把預取/預渲染包裝成一鍵開啟的設定。

但實際用起來問題不少：部分主題或外掛在 prerender 狀態下會出現 JS 錯誤、購物車狀態異常、或分析數據重複計算；Firefox 跟 Safari 的瀏覽器相容性沒有全面到位。裝了外掛把它開下去不代表沒問題。

我們可以看到 Kinsta 是如何介紹這個神奇技術跟裡面的坑: How Speculative Loading can boost your WordPress site’s page speed。

bfcache：上一頁/下一頁瞬間回復

Back/Forward Cache 不需要特別寫程式，只要頁面沒有主動阻止它，瀏覽器就能在使用者按上一頁/下一頁時從記憶體直接還原整個頁面，速度幾乎是瞬間的。

常見會破壞 bfcache 的寫法：

• 頁面掛了 unload 事件監聽器
• 對所有頁面設定 Cache-Control: no-store
• 開了 SharedArrayBuffer 卻沒設對 COOP/COEP header

bfcache 只對「按上一頁/下一頁」有幫助，PageSpeed 不量這個場景。

View Transitions：換頁不閃白

View Transitions API 讓頁面切換時可以加入平滑過渡動畫，避免傳統換頁的白屏閃爍感。

document.startViewTransition(() => {
  updateDOM(); // 更新內容或觸發導航
});

這不需要特別用什麼前端框架，純 CSS&JS 就能做，但目前以 Chrome/Edge 為主，Safari 部分支援，Firefox 尚未支援。這是純視覺體驗優化，對任何 CWV 指標都沒有直接影響。

現實上，兩個頁面的 DOM 結構差異越大，動畫效果越難控制——從文章列表頁跳到完全不同版型的內頁，畫面可能一片混亂，甚至比原本的白屏閃爍更難看。

頁面如果有大量固定定位元素、Sticky header 或複雜的 Grid 版型，也容易在過渡動畫期間位置亂跳。適合用在版型接近、內容平滑切換的場景（如商品列表換頁、編排相似的子頁面），不適合強行套在整個網站的所有換頁上，還有每次換頁的動畫如果過於華麗，看了兩三頁之後就開始視覺疲乏。

反向優化翻車

為了減少 request 數，把全站 JavaScript 合併成一支肥大的 bundle，下載後還要長時間解析與執行，TBT、INP 反而更差。

另一種翻車是把工作拆成大量 setTimeout，讓功能完成時間拉得很長，或造成狀態競爭與重複送出。

反向優化翻車

critical CSS 抽得不完整，頁面會先出現未套樣式內容，再突然變成正式版面，形成 FOUC 與位移。自動清除 unused CSS 若沒有掃到動態 class，還可能把選單展開、驗證錯誤或後台產生的樣式刪掉，直到使用者操作才發現功能跑版。

網站所有的圖片上傳程式都要做調整

例如上傳 JPG, PNG，自動轉檔成 WebP 的格式，前台的圖片顯示 html 碼也要做調整，為了瀏覽器相容性，建議改成 picture>source+img 的那種方式，CSS 裡的背景圖則要多掛一段偵測是否支援 webp 的 js code (可以用 modernizer)，又是一項非常大的工程，直到近代 IE11 結束了，大部分瀏覽器也都支援了，才能放心使用。

也有些 CDN 服務或圖床服務可以把圖片輸出成 webp 需求

上一點提到的那些舊網站功能修改，報價很貴? 那可以考慮使用一些 CDN 服務，使用者瀏覽網站時，會自動看到被轉成 WebP 的圖片，例如 CloudFlare Pro 的 Polish WebP conversion、EWWW Image Optimizer、阿里雲的圖片處理服務等等，

但都是要依圖片數量、網站訪客流量情形等條件持續繳費。

占用更多伺服器磁碟容量

早年 WebP 的圖片無法在 IE 上顯示，所以為了 IE11 能看到網頁上的圖片，視覺設計做好1張圖傳上去，系統還是要轉檔成 JPG 小縮圖、JPG大圖、webP小縮圖、webP大縮圖等等，占用更多伺服器磁碟空間。

有些虛擬主機的伺服器有檔案數/Inode 的限制

上傳1張圖，系統要自動產生4張圖片，檔案數/Inode 更容易滿了，又到了付錢升級主機的時候了。

伺服器設定

有些主機放 webp 圖片還要調整 MIME 設定 <mimeMap fileExtension=".webp" mimeType="image/webp" />，不然 webp 的圖片根本顯示不出來，如果自己沒有相關系統權限，又是很麻煩的一件事。

繪圖軟體不支援

有時候要修改圖，又沒有留原始編輯檔，就不得不直接抓網站上的圖，但 WebP 無法直接下載後拉到 Photoshop 內做編輯，又要再自己轉檔成 JPG。有些通訊軟體(例如LINE)直接傳 webp 人家也看不到圖片，還被人以為是傳病毒。

(2022/2更新:Photoshop 版本 23.2 起支援 WebP 圖片格式)。

或是有些電商類會有同一套圖要上架N個網站的作業情形，直接從網站下載 WebP 圖片，再上傳別的網站? 別的網站也不見得接受 WebP 的圖片，又要再轉檔一次。網頁改成放 WebP 的圖片，讓一些稀鬆平常的視覺設計作業流程變得困難重重。

Pagespeed 的圖片實驗

照慣例做個實驗，以一個放在台灣機房的購物網站的商品內頁為例，網頁最上方有兩大張滿版 banner，第一個畫面還有商品圖輪播圖效果，網頁上還有放 YouTube 跟 FB customchat 等上述提到會讓網頁載入變慢的一些社群天王。

為求公平，都把他轉成 html，就不需考慮 SQL 查詢太久之類的 server side 問題。原網頁裡大小圖共計 25 張，jpg 跟 png 都有，實驗組則是把網頁上所有圖都換成 webp。

換了 webp 之後，20幾張圖片的總大小從 3.5MB 縮小到只剩 1MB，圖片也出現了肉眼輕易可見的畫質損失(因為圖片上有壓字，邊緣不銳利很容易看出來)。

提供 next-gen 格式的圖片、圖片編碼有效率之類的建議改善項目，確實都完成了! PageSpeed 跑分也增加了幾分! 但是 Google Search Console 裡面會列的 LCP 那些還是一樣紅燈啊! 而且 LCP 時間還拉更長了!

做網站，其實有很多調校是表面上「看不出來」的，大費周章調整一堆東西，但可能還是一場空。

新技術的帶來新問題

當然這個黑箱背後的技術實作、dependencies 和各種未經過時間考驗的機制，常常也是各種資安漏洞、全球前端大 bug 的來源，還有一些不太好 debug 的問題，需要理解某個功能的歷史發展。

但如果不想花時間在優化細節上，直接改用現代前端框架，確實是個快速提升 PageSpeed 分數的捷徑。

但不是用了就分數一定會變漂亮，不是分數漂亮就一定 SEO 排第一名，有些框架是為了解決前端開發問題而生，不是為了解決 SEO 問題，要把 SEO 做好做滿比以前還麻煩。有幾個大坑要先搞清楚，不然改完反而更慘，可能網站直接從搜尋引擎消失，最常見的就是 CSR 問題跟路由問題。

不要覺得這些技術在 2026 年是基本常識，有一個 vibe coding 的人很愛用的快速架站工具廠商 Lovable，他們到了 2026 年中才宣布 Building apps using TanStack Start，更換新專案的技術架構，從之前的 CSR 換成 SSR。

就因為一些純 CSR(client-side rendering) 的 SPA(早期常見的 React / Vue 純前端)，首屏在 PageSpeed 上就是一片空白，HTML 幾乎是空的 <div id="app"></div>，要等一大包 JS 下載、執行、再打 API，才有網頁內容。SEO 爬蟲也不一定抓得到內容。

解法是改走 SSR / SSG：伺服器先吐出有內容的 HTML，首屏馬上看得到。可以選的框架很多：

• TanStack Start：建在 TanStack Router + Vite 上的全端 React 框架，支援 SSR、streaming、server functions，路由是 type-safe 的。
• Astro：內容型網站(部落格、官網、活動頁)很合，islands 架構預設幾乎不出 JS。
• Next.js / Nuxt / SvelteKit：各自生態成熟，SSR/SSG/ISR 都有。
• Qwik：主打 resumability，把 hydration 成本壓到極低。

Lovable 就舉了一些實證，像是架構更新後，爬蟲檢索速度變快、自然搜尋流量變多、從AEO(ChatGPT, Perplexity 等工具)來的流量增加了 98.5%，不再是那個網頁看似很漂亮，網站在搜尋引擎都找不到的 AI 玩具。

解決了 SEO 爬蟲問題，還有更多問題

但別以為換框架、有用 SSR 就一勞永逸，還有接連不斷的坑：

SSR 吐了 HTML 之後，前端還要 hydration，這包 JS 一樣要下載執行。如果整頁都要 hydrate，TBT / INP 反而可能比舊的多頁式網站還差。

hydration mismatch：伺服器跟瀏覽器渲染結果對不起來，畫面會閃一下甚至報錯。盡量縮小首屏要 hydrate 的範圍(islands / 部分 hydration / RSC)，能靜態就靜態。要是設定錯誤，退化成「SSR 殼 + 整頁 CSR」，等於兩邊的缺點都吃到。

當使用者使用網頁翻譯套件，或是一些瀏覽器小工具，這些套件通常是直接改 DOM 的，容易破壞 React/Vue/Svelte 等框架的虛擬 DOM 差異比對機制，導致 hydration error，畫面閃爍、畫面全白、甚至功能異常。

這種情況下，使用者根本不知道發生什麼事，難道要告訴使用者「請關掉翻譯套件」?

路由的坑

• 要用框架的 client-side 路由 + 預先 prefetch，換頁才會快；別不小心做成每次點都整頁重載(full reload)，那就白用框架了。
• 每一條路由要各自設好 <title>、meta、OG、canonical，不然 SSR 出來每頁的 head 都長一樣，SEO 直接扣分。
• deeplink、直接打某個內頁、404 都要 server 端能正確回應對應的 HTML(SSR)，不然分享連結進來是空白或 soft 404。

// TanStack Start：在 server 端先抓資料、設好每頁的 head
// （API 仍在演進，實際以官方文件為準）
import { createFileRoute } from '@tanstack/react-router'

export const Route = createFileRoute('/products/$id')({
  head: ({ params }) => ({ meta: [{ title: `商品 ${params.id}` }] }),
  loader: ({ params }) => fetchProduct(params.id), // 首屏就有內容，不靠前端再打一次 API
  component: ProductPage,
})

平心而論：把一個好好的多頁式網站整個改寫成現代框架，是一筆可觀的工，改完跑分可能也才多個幾分。到底划不划算，又是另一個要跟老闆解釋很久的故事了。

如果只是內容型網站，沒有什麼會員登入或購物車，與其上重量級框架，先評估 SSG 純靜態的方案，往往 CP 值更高。

Google Search Console 的 Page Experience 的廣告體驗報表

剛剛看到上面的圖，可以看到一個「廣告體驗」的東西，這主要會針對網站所使用的廣告方式是否擾人、造成干擾或讓使用者體驗變差，來進行評分。而不是評斷說網站曾經投放 Google Ads 或 FB 廣告，點廣告進來看網站的使用者的瀏覽情況，這個檢測項目跟投放廣告無關，簡單來說就是評量網站內是否有設計一些很擾人的彈跳廣告…之類的東西。

這個廣告體驗報表也不是新玩意，只是多年前舊的東西一起整合進來而已。當時 2019年 Google 號稱要終結網站裡的蓋版廣告…

Better Ads Standards

當時不少媒體也下了聳動的標題…

現在好幾年過去了，各大網站的廣告還是蓋版蓋爽爽，連 Google 自己的 AdSense 也有蓋版廣告跟 Large Sticky Ads，如果你在本部落格多逛幾篇文章就有機會看到。

對於這項評比，Google 的網頁體驗報表說明 有相關的說明:

如果 Google 將某個網站標記為具有不良的廣告體驗，則該網站的所有網頁都會被視為具有不良的廣告體驗。「廣告體驗」評估會影響整個域名，而非只影響單一網頁。

請注意，許多網站並未經過「廣告體驗」測試：如果你的網站並未受到測試，可視為網站已通過「廣告體驗」測試。

(從「廣告體驗」報告的清單上選擇你的資源以查看狀態。如果狀態為「未經審查」，該資源在「網頁體驗」報表中會顯示為具有良好的「廣告體驗」狀態。)

再講一次，Apple 重新定義 3C 產品，Google 重新定義網頁體驗。

Google Search Console 裡的網頁體驗報表

這報表也很謎，例如我們看到一個 CLS 不良的警示訊息，一層一層點進去看…WTF? PDF 檔案又不是網頁，是要怎麼優化 CLS?

而且要讓缺失項目消失，從網站使用體驗核心指標報告 – 驗證修正結果的說明來看，如果網站中任何網址在這 28 天內皆未發生問題，問題就會視為已成功修正。不過，只要任一網址出現問題，Google 就會將問題標為未修正。

網頁體驗報表裡另外還有不少神秘的整人地雷，例如:

• RWD網站因應客戶需求做了那種「返回電腦版網站內容」的功能，讓手機小螢幕可以看到電腦版畫面，而不是簡化過的手機板畫面，網站上做了一段切換 meta name=”viewport” content=”width=1170, initial-scale=0.2… 的，將會報表中顯示「未將可視區域設為「device-width」」，行動裝置可用性出現一堆紅字了。
• 上面的 PDF 造成 CLS 錯誤的問題，是真的有效連結的 PDF，不是那種檔案 URL 404 會 redirect 到其他網頁的問題，PDF 也沒有設定封鎖。
• 上稿人員在網頁裡放了一堆表格，然後被列一堆行動裝置可用性問題「文字太小，不易閱讀」，以後可能請上稿的人把表格都做成圖片吧，雖然文字更小，更不易閱讀，但這樣就不會被抓缺失了。
• 「網站使用體驗核心指標」有拿到綠勾勾，沒有偵測到任何問題，但是點進去卻有顯示一些CLS 問題：超過 0.25 (行動版)，LCP 問題：超過 2.5 秒 (行動版)的不良或需要改善的，但網址數又是0? 網站也沒做任何調整，是有問題的頁面刪掉了嗎? 問題是網站的頁面數一隻手就數得完，根本沒有刪呀
• 已經放在 Google Search Console 裡面 N 年，可以被正常搜尋到網站，報表裡卻各種「這個裝置類型的資料不足。」是網站太少人瀏覽? 可是那網站有下關鍵字廣告，瀏覽數明明就很多呀。
• 各種 LCP, CLS 需要改善、不良，然後點進去，半條網址都沒顯示的。
• 各種 LCP, CLS 需要改善、不良，但是每一條網址丟去 PageSpeed，LCP, CLS 都是「良好」的。
• 各種 LCP, CLS 需要改善、不良，顯示有好幾十頁，但是點進去只看得到類似網址 (最多 20 個)，然後測了都是「良好」的。
• 有的有「驗證修正後的項目」按鈕可以按，有的沒有。

跑分跟 SEO 排名的關係

所以現在我可以做一個跑分100分，但是毫無內容的垃圾網頁，在整形等熱門關鍵字衝到第一名，讓大家來跟我買推薦連結嗎?

Core Web Vitals 指標的官方 Q&A 問答集 裡面有提到:

即使頁面體驗的某些方面低於標準，我們也會優先考慮總體上具有最佳信息的頁面。 良好的頁面體驗並不能取代擁有豐富而相關的內容。(機器翻譯)

If you have pages that aren’t measuring “good” on at least one of the Core Web Vitals metrics or not passing the other page experience criteria, we recommend focusing on improvements in those dimensions over time. While all of the components of page experience are important, we will prioritize pages with the best information overall, even if some aspects of page experience are subpar. A good page experience doesn’t override having great, relevant content. However, in cases where there are multiple pages that have similar content, page experience becomes much more important for visibility in Search.

為什麼「瞭解實際使用者體驗」半點資料都沒有？

因為那塊吃的是 CrUX 實地資料，網站訪客太少，Google 根本湊不出足夠樣本。

PageSpeed 上半部那塊「瞭解實際使用者體驗(Discover what your real users are experiencing)」，用的是 CrUX(Chrome 使用者體驗報告)的實地資料，來源是真的用 Chrome 逛過你網站、而且同意回傳統計的使用者。

• 樣本數不夠(流量太少)就湊不出統計，這塊會直接顯示「沒有足夠的實際使用速度資料」。
• 有時候頁面級沒資料，會退而顯示整個來源(origin)級的；連 origin 都不夠，就整片空白。
• 所以這不是你網頁做壞了，是 Google 手上根本沒有你的訪客數據。冷門頁面、剛上線的站、擋國外 IP 的站，幾乎都看不到實地資料。
• 想確認自己的 CrUX 到底有沒有資料，可以查 CrUX API。

換句話說，這塊空白跟網站技術好壞無關，純粹是流量問題。要它有資料，先去衝流量，不是去改 CSS&JS 程式碼。

實地資料全綠，分數為什麼還是很難看？

因為那個分數是 Google 拿一台模擬的慢手機當場跑出來的，跟「實地」真實使用者量到的根本是兩回事。

PageSpeed 同一頁其實同時給你兩種完全不同的東西：

• 上面的 實地資料(CrUX)：真實使用者過去 28 天的第 75 百分位(p75)。
• 下面的 實驗室資料(Lighthouse)：用一台節流過的「模擬低階手機 + 慢網路」當場跑一次，算出那個 0–100 分數。

這兩者量的東西不一樣，本來就會打架。實地全綠代表你真實使用者的體驗其實是好的；但那個 0–100 分數是模擬一台很慢的手機當場跑的結果，常常很難看。

重點是：Google 排名看的是實地的 Core Web Vitals，不是那個 0–100 分數。 所以實地全綠、分數只有 60 幾分，對 SEO 來說其實沒事——但客戶/主管往往只看得懂那個大大的分數，於是工程師又要開始解釋人生了。

LCP 為什麼每次測都在亂跑？

實驗室那個 LCP 每次測都不一樣，原因大概有三個：

1. Lighthouse 的模擬節流本身就有變異。
2. 伺服器 TTFB 每次浮動。
3. 被判定為 LCP 的元素每次可能不同(前面實驗講過，有時候是 logo、有時候是分隔線的背景圖)。

而實地的 LCP 是 28 天滾動的 p75，會隨最近訪客的裝置/網路慢慢變動，今天改的東西，要過好幾天甚至幾週才反映出來。

所以想抓真正的 LCP 元素，看 PageSpeed 報告裡的「最大內容繪製元素」，或乾脆用 web-vitals.js 在真實環境量。別只測一次就下定論，多測幾次看分佈才準。

缺失整個修掉，分數為什麼一點都沒動？

照著 PageSpeed 建議，把某一項(例如「減少無用的 JavaScript」)整個清乾淨，重測，分數動都沒動、甚至還掉了。原因：

1. 那個 0–100 是好幾個指標加權算出來的，你修的那項剛好不是卡分數的瓶頸。
2. 報告寫的「預估可省下 XX 毫秒 / KiB」是理論上限，實際不一定省得到。
3. 每次測本來就有上下浮動，我們的改善被雜訊蓋過去了。

真正卡分數的通常是 LCP 跟 TBT(總阻塞時間)。一直去修一堆無關痛癢的小項目，分數當然不動。修之前先看清楚瓶頸在哪，不要看到紅字就無腦修。

報告列的那些缺失，到底哪些值得修？

報告裡那一串「預估可省下…」看起來很嚇人，實際上能無腦修又有效的沒幾項，逐項說明：

• 「會阻斷算繪的要求（預估可省下 XXX 毫秒）」：就是 render-blocking 的 CSS/JS。理論上 defer/async 或 inline critical CSS 就好，但那個「XXX 毫秒」是模擬慢網路下的理論值，真實使用者多半有快取、網路也沒那麼慢，根本省不到那麼多。而且很多 render-blocking 是廣告/追蹤碼/框架本身，我們不能動它。
• 「提升圖片傳送效能（預估可省下 87 KiB）」：就是叫你壓圖、上 next-gen 格式、給對的尺寸。87 KiB 在現在的網路根本零點幾秒，為了它把整套上稿流程改成奇特的圖片格是，划不划算自己算。
• 「LCP 要求探索」：抱怨你的 LCP 元素被發現得太晚載入完成——例如它是用 JS / CSS 背景圖載的、或沒 preload。解法在本文中有談到一些，但如果 LCP 元素每次測還會變，這項就很難穩定修掉。
• 「網路依附元件樹狀結構」：列出「A 載完才能載 B，B 載完才能載 C」這種一條龍的相依鏈。理論上要打平、preconnect、preload。但第三方 SDK 的相依鏈是人家寫死的，我們只能看著。
• 「使用有效的快取生命週期（預估可省下 142 KiB）」：嫌靜態檔的 Cache-Control 太短。諷刺的是被點名的常常是 GA、廣告、FB SDK 這些第三方檔案，它們的快取時間是人家設的，你改不了，這項幾乎永遠掛在那裡消不掉。
• 「舊版 JavaScript（預估可省下 12 KiB）」：網站建置打包時可能為了相容舊瀏覽器塞了一堆 polyfill / transpile 出來的舊語法，現代瀏覽器其實不需要。解法是 build 時把輸出 target 設成現代語法(esbuild / Vite 設定一下即可)。12 KiB 不多，但這項確實是該清的技術債。但問題有時候是重要的程式碼，但檢測工具根本無法偵測這段程式碼是不是實際有在使用的。
• 「減少無用的 JavaScript（預估可省下 197 KiB）」：載了卻沒用到的 JS，通常是整包 framework / UI library 只用到幾個元件、或第三方 SDK。解法是 code splitting、tree shaking。但同樣，第三方那一包 tree shake 不掉。
• 「避免長時間在主執行緒上執行的工作」：JS 跑太久卡住主執行緒，導致 INP&TBT 變差。本文有提到一些解法。但元凶常常還是一些改了之後會動搖國本的東西，繞一圈又回到原點。

結論：這份缺失清單，能無腦修又有效的其實沒幾項；剩下的不是第三方的鍋，就是理論值跟現實有落差，修了分數也未必會動。看懂哪些值得修、哪些是噪音，比盲目把紅字清光更重要。

簡單一行 CSS 就能讓 web.dev 的 accessibility 測不出分數

遇到一個網頁，在 web.dev 的 a11y 項目得分跑不出來，不知道是問號還是 0 分，Report 說明裡更是甚麼都沒寫，只有 Background and foreground colors have a sufficient contrast ratio – Error! 黑底白字能有什麼對比度問題？Google 又再整人了嗎？對，就是在整人。

做了個可以重現問題的頁面webdev-a11y-fail，用蒙地卡羅法測了老半天，看看刪除頁面上哪一段 CSS 或 HTML 就能讓分數正常？

最後終於查出來。當要做一種效果：讓一段長度不固定的的文字在任何螢幕寬度都不要斷行，溢位的文字自動變成…，會使用 white-space:wrap 配合 text-overflow: ellipsis，雖然版面用一般瀏覽器看起來正常，但 white-space:wrap 竟然會讓跑分異常，向 web.dev 提交 bug 之後不知道有沒有機會解決。

PageSpeed 真的能算準首屏 LCP 嗎？

LCP 的立意基本上是好的，計算網頁可視區域中，最大的內容元件載入所需要的時間，簡單來說就是使用者要花多久才能看到首屏主視覺。官方的介紹說 web.deb – LCP，會認以下這些元素當成頁面上最大內容。

• img elements
• image elements inside an svg element
• video elements (the poster image is used)
• An element with a background image loaded via the url() function (as opposed to a CSS gradient)
• Block-level elements containing text nodes or other inline-level text elements children.

但判定頁面上最大內容這回事，似乎也有很多莊孝維的地方。

做了一些實驗，發現 LCP 的評量標準似乎有一些可議之處…

上方的範例頁面，只是一個非常簡單的靜態頁面，2張圖片和 html 總共 56.5KB，GA 的檔案大約 52.6KB，在 LightHouse 的機器上面測 LCP 落在 1.9~4秒之間，一個內容跟寫法非常單純的網頁，LCP 評分項目已經差點進入不及格的邊緣了。

現實的網頁當然不可能這麼單純，頁面上有一堆視覺上硬要放上去的雜物，為了RWD多出的CSS樣式碼和行動裝置操作元件，FB專頁按讚等第三方外掛，嵌入 Youtube、放思源黑體雲端字型、還有行銷公司要求追蹤碼一定要放在 head 裡面，還有整大包的 CSS framework, JavaScript framework，主機環境能省則省…等各種因素。

別說 100 分，Google 搜尋排第一頁的大部分的網頁都不及格。軟體開發的現實，絕非按照一些規範準則 optimize lcp 就可以完事的。

規範與實際現場脫鉤，這是各行各業都有的問題，在網頁設計這個小小的行業也不例外。

#### 挑戰把官方沒列出的元素當成 LCP
但是有網頁設計知識的人都知道，HTML TAG 至少有 100 多個，就這幾行，真的能包含所有現實的設計情況?先試一下在網頁上用 YouTube 提供的嵌入語法，放一個 iframe 在網頁上。

網頁上放了一段影片，照理說畫面上最大的內容當然就是這個 YouTube 影片，但是卻測出載入時間 6.5 秒，LCP 算不出來，分數是問號。(下圖上半部)

在影片下面加了一段文字(上圖下半部)，載入時間跟 LCP 卻神奇的降到 0.8 秒，分數65分，在及格邊緣。

同樣的邏輯思維，Google 曾經出了一個 Framework 叫 Flutter，可以做 APP+WEB，Flutter 在 Web 上的具體呈現方式就是把主要網頁內容都包在一個 HTML5 Canvas 裡面，堪稱 Adobe Flash 概念的復辟，那網頁首屏上最大的元素無庸置疑就是 canvas，而 canvas 也跟 iframe 一樣，沒有直接列在上面的元素清單內，那在 Core Web Vitals 檢測時會發生什麼事呢?

抓了幾個 Flutter Samples 上面的頁面去測，神奇的事發生了，卻沒有像 iframe 一樣跑出問號或是數字異常的情況…

Flutter Web 後來也一直在改渲染策略，HTML renderer 已被移除、改以 CanvasKit / 新的 skwasm 為主，整頁包在 canvas 裡對 SEO 跟 CWV 一直都是個尷尬點，這也是為什麼內容型網站幾乎沒人用 Flutter Web。

#### 找出網頁裡的 LCP 元素(最大內容繪製元素)
有時候 LCP 秒數表現不佳，調整時猜測 LCP 是畫面上的某張圖，但怎麼調都沒差? 其實可以看一下 PageSpeed 有沒有出現這兩行「預先載入 LCP 元素所使用的圖片，以縮短 LCP 載入時間。」「最大內容繪製元素」，點擊之後可以看到它究竟把網頁上的哪一塊內容當成 LCP。

最有趣的是，有時候以為 LCP 元素是上面滿版大圖，還是 logo，結果這邊列出的卻是…分隔線的背景圖之類的，也許照數學算法來說面積的確是最大，但是對於人類的預期似乎有點距離。或是同一個網頁連測數次，列出來的 LCP 元素竟然還會變動，有時候是分隔線，有時候是一個表格內的文字，有時候是 logo…可能就跟物理學上的光一樣，一三五用粒子說，二四六用波動說，禮拜天聽神父說。

經過一連串實測與踩雷，LCP 真的能計算網頁可視區域中，最大的內容元件載入所需要的時間? 真想把 Web Vitals 官方網頁的相關敘述印出來，然後壓著 Google 的工程師請他們把字吃下去。

#### 一樣的網頁試圖偽造不同的首屏視覺
上圖為第二個實驗，LCP實驗範例網頁0 和LCP實驗範例網頁1，兩個範例網頁放置的圖文，引用的 webfont, js, css 檔案完全相同，但一個網頁開啟時會先顯示一個提示訊息，要按掉才能繼續看。

首屏主視覺和 UX 完全不一樣的兩個網頁，卻得到相同的得分？LCP真的是叫(Largest Contentful Paint, 最大內容繪製)時間嗎？還是 Lighthouse 的電腦程式假裝知道使用者看到的首屏畫面，但實際上錯誤百出，在不少情況卻會誤殺忠良？

所以如果想透過諸如網頁一打開時先顯示提示訊息、 loading 動畫之類的，來掩護其他真正的首屏視覺，避免因為 LCP 太長而被扣分？看起來沒這麼好作弊，勢必要花更多時間去嘗試。

像 LCP實驗範例網頁2，調整許多地方，讓 LCP 變成綠色的，但也才提升一丁點的 PageSpeed 總分(不到10分)，非常適合沒事找事做的企業，或是有人想要去刁難資訊部門的時候使用。

為什麼跑版網頁的 LCP 分數更高？

另一個北爛的實測，我們做了2個實驗對照頁面，裡面有一個使用 Swiper 套件的普通圖片輪播 slideshow 效果，使用 IE11 無法正常顯示的純 ES6 版本(網頁不用掛JQuery)，整個網頁含圖片載入 size 約 400 KB。

檢測項目幾乎都是綠燈，只有LCP項目的數值有相當大的落差，最終導致兩者差了快10分，但網頁程式碼就只差了幾個字。

• 分數較低的那個，我們讓輪播廣告內的大圖片在手機上會與螢幕同寬 100% 顯示，等比例縮小，就是正常網站的做法。
• 分數較高的那個，則是完全不限制圖片寬度，在手機上看，圖片是會超出畫面外的，甚至讓網頁產生水平左右卷軸，就是一般人認知的網頁跑版。

測試其他網頁元素，好像只有圖片有此情況，94要讓畫面跑版凸出去，減少畫面 render 時間，讓機器檢測 LCP 變成綠燈，才是高分的網頁體驗。但是測試表格、iframe，卻沒有此情況，讓畫面跑版凸出去，或是符合畫面寬，分數都沒有多大的差異。

這就有趣了，一個跑版的網頁，卻能在網頁體驗的評分項目拿到更高分，機器真的能評斷出網頁體驗，還是實際上常常在搞笑？

讓網站在 PageSpeed 測不出分數

有碰過幾個網站，前人有請主機商設定阻擋國外IP，只限台灣IP瀏覽，我不知道主機商是如何設定的，以及他們是用哪套國家 IP 資料表。總之這些設定阻擋國外訪客的網站，丟去測 PageSpeed 就只會出現以下訊息，跑不出分數。

Lighthouse returned error: FAILED_DOCUMENT_REQUEST. Lighthouse 無法穩定載入你要求的網頁。請確認你的測試網址是否正確，以及伺服器是否正確回應所有要求。(詳細資訊：net::ERR_TIMED_OUT) 結尾訊息有時候是 403 ERROR，有時候是 ERR_TIMED_OUT

限制國外 IP 除了會造成寄信問題、Google Ads 會變成廣告到達網址無效、FB企業平台認證、Google 跟 FB 一堆廣告商品目錄相關功能出現問題，也會造成 PageSpeed 無法檢測的問題(要再開放某些IP設為白名單)。這也開啟了整個跑分的新思維，例如查主機 Log 檔，可以發現 PageSpeed bot 的 UserAgent 字串至少有以下兩種：

• Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36 Chrome-Lighthouse
• Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Mobile Safari/537.36 Chrome-Lighthouse

然後 IP 通常是66.249. 開頭的，所以理論上可以針對 Chrome-Lighthouse 的 UserAgent 字串，或 IP 網段進行阻擋，甚至特別吐出不一樣的內容給 bot 看，來達成造假的目的…

用「最佳」這個詞容易讓人有錯誤的預期

講到「優化」，就牽涉到對於中國用語的問題，我的個人想法，除了一些會讓人聽起來不悅的，哪邊更接近現實、更能讓人理解，就用哪個，例如這邊台灣用語應該要用「最佳化」，但是論網頁開啟速度要達到最佳，應該是把網頁上對於視覺傳達毫無用途的雜物通通移除，所有會造成扣分的東西拿掉、非必要的東西通通不要放，才能叫最佳。

但論現實情況，客人可以接受本來好好的網站整個打掉重寫、內文可能還要一篇篇修改嗎? 客戶可以接受他的網站變得像瀏覽器的閱讀模式一樣簡約清爽嗎? 上稿的人有能力把每一張圖片都要壓縮到勉強不會太模糊的臨界點嗎? 系統使用者能完整掌控整個網站前後端的程式、整天做實驗看看把某個東西拿掉，看看分數會不會變高嗎? 都是只能稍做微調，離最佳還差遠的了。我覺得「最佳」這個詞容易讓人有錯誤的預期。

至於大費周章調整後，然後發現還是有網頁排在你前面，而 PageSpeed 分數卻很低，不禁開始懷疑人生…