Core Web Vitals：用 LCP、FID、CLS 量網頁效能，並用工具找出該修的地方

1. 為什麼要在意初次載入效能 0:00–0:46

作者用「五秒抓不住你就跳走」當開場，指出現代人注意力極短，網站慢就等於少賺錢。於是把問題收束成三個要懂的指標：largest contentful paint、first input delay、cumulative layout shift。並預告不只講 Lighthousei，還會用 Web Vitals 擴充套件與 Unlighthouse 去實測 Amazon、Google 等真實網站。

推理作者一開場就把自己當實驗品：「如果我不能在接下來五秒抓住你，你就不會看完」。因為他要讓你先接受「注意力是稀缺資源」這個前提，所以才能推出下一步——網站慢＝使用者跳走＝少賺錢。有了這個商業動機，他才有立場說「achieving Optimal Performance is complex」，並把複雜度收束成三個具體名詞：largest contentful paint、first input delay、cumulative layout shift。最後他預告工具（Web Vitals 擴充套件、Unlighthouse）與實測對象（Amazon、Google），但立刻煞車：「要把這些工具用好，得先搞懂 core web vitalsi」——先建立量測的語言，再拿工具。

• CCore Web Vitals 把使用者感受拆成三格：看得到（LCP）、按得動（FID）、不亂跳（CLS）→ 畫地圖
• EGoogle 挑三個指標的標準：與跳出率相關性最高、而且開發者改得動→ 存＋演練
• Rbounce：使用者進站沒任何互動就離開，效能變差時最先惡化的商業數字→ 存＋回想

AI 補充作者說「網站慢就會少賺錢」時跳過了中間那一步：慢到什麼程度、掉多少？補上這一步會讓後面的門檻數字有意義——Google 與各家零售商的公開研究長期給出的量級大致是「載入時間每多一秒，轉換率掉個位數百分比」，而 Core Web Vitals 之所以被訂成三個而不是十個，正是因為 Google 挑的是「與跳出i率相關性最高、且開發者改得動」的三件事。另外要先建立一個貫穿全片的分工：這三個指標不是隨機湊的，而是把「使用者感受」拆成三個互不重疊的面向——看得到（載入）、按得動（互動）、不亂跳（穩定）。作者接下來每講一個指標，其實都是在填這三格的其中一格；先知道有這張表，後面三段就不會覺得是三個零散的知識點。

2. LCP：載入效能怎麼量 0:46–1:28

largest contentful paint 量的是載入效能：網頁先出現 first contentful paint，接著逐步載完圖片影片，最大那塊內容畫出來的時間就是 LCP。Google 的門檻是 2.5 秒內算好、超過 4 秒算差且會影響 SEO。最基本的分析方式是打開瀏覽器 network 分頁看瀑布圖，特別寬的那一條就是瓶頸。

推理因為上一段已經確立「使用者在意的是多快看得到東西」，所以作者接著要找一個能代表這件事的時間點。他的推導是：網頁載入其實是一連串資源抓取（CSS、HTML、JavaScript、圖片、影片），中間會先出現 first contentful paint，然後畫面才逐步長齊——所以最能代表「我看到這一頁了」的時刻，是最大那塊內容畫完的瞬間，這就是 LCP。有了定義才能談門檻：2.5 秒內算好、超過 4 秒算差，而且會影響 SEO（這一句把技術指標接回第 1 段的商業動機）。有了門檻才需要診斷方法，所以他最後落到最基本的一招：打開 network 分頁看瀑布圖，找特別寬的那一條。

• CLCP：從開始載入到視窗內最大那塊內容畫出來的時間，代表「我看到這一頁了」→ 畫地圖
• RLCP 門檻：2.5 秒內算好、超過 4 秒算差→ 存＋回想
• P最基本的 LCP 診斷：開 DevTools Network 看瀑布圖，找特別寬的那一條→ 練習
• EAmazon 商品頁：333 個請求、28.7 MB，大多是 479 B 的 gif／ping beacon 靠數量吃光連線→ 存＋演練
• R瀑布圖顏色：淺色段是排隊與等待，深色段才是實際傳輸→ 存＋回想

AI 補充作者說「瓶頸在圖上會是特別寬的那一條」，但沒說怎麼讀寬度。截圖裡是 Amazon 商品頁在行動裝置模擬（375×667）下的 network 面板：333 個請求、28.7 MB 資源、DOMContentLoaded 2.83 秒、整頁 Finish 12.86 秒。值得注意的是，畫面上大多數條目是 479 B 的 gif 與 ping（廣告與追蹤的 beacon），它們每個都很快，卻靠數量把連線數吃光——這說明「寬」有兩種：一種是單一資源真的很大（一條長綠條），一種是它前面排了太多東西，等待時間被拉長。DevTools 的瀑布圖裡淺色段是排隊與等待、深色段才是實際傳輸，這個區分決定你該壓縮檔案還是該減少請求數。另外一個作者省略的關鍵：LCP 元素通常就是首屏那張最大的圖或那段標題文字，找到它比看整張瀑布圖更快——而這正是作者稍後要介紹的診斷工具要解決的事。

術語:Largest Contentful Paint (LCP)iFirst Contentful Paint (FCP)inetwork waterfalliSearch Engine Optimization (SEO)i

3. 優化 LCP 的三層做法 1:28–2:40

找到瓶頸後，作者給出三層優化：先減少資源載入時間（壓縮圖片、改用 webpi、字型只留最低限度），上線後用 CDN 送資源（Firebase、Vercel 會自動處理），再來是避免 render blocking JavaScripti——這正是 Next.js 這類伺服器端框架勝過純 React 單頁應用i的理由。最後是現代瀏覽器的資源優先權：用 preloadi 讓重要資源先被發現，用 fetch priorityi 把頁尾的次要圖片降級。

推理因為上一段的診斷方法會指向「某個資源花太久」，所以作者接著的第一招最直觀：資源本身變小——壓縮圖片、改用 webp、字型只留最低限度。但檔案再小也得跨越距離，所以第二招是把資源放到離使用者近的地方，也就是 CDN（他順手指出部署到 Firebase 或 Vercel 會自動處理，降低心理門檻）。前兩招處理的是「東西多久到得了」，第三招處理的是「東西到了為什麼還畫不出來」——render blocking JavaScript：如果得先跑一段 JS 才顯示圖片，LCP 就被綁架。這一步他順勢把架構選擇也拉進來：Next.js 這類伺服器端框架比純 React 單頁應用受青睞，正是因為 SPA 初次載入得先跑一堆 JavaScript 才畫得出主要內容。最後一招是最細的：既然資源會互相排隊（第 2 段瀑布圖已經看過），那就用 preload 讓重要資源提早被發現，用 fetch priority 把頁尾的次要圖片降級。整段的推導軸線是同一個問題被問了三次：小一點、近一點、早一點。

• P優化 LCP 三層：資源小一點、放近一點（CDN）、重要的早一點（preload / fetchpriority）→ 練習
• A「小一點、近一點、早一點」就像物流：壓小包裹、就近倉儲、重要件優先出貨→ 批判類比
• Crender blocking：必須先下載並執行完瀏覽器才肯繼續畫，預設 CSS 比 JS 更典型→ 畫地圖
• Rpreload 的 as 屬性不能省：少了瀏覽器不知道優先權，還可能重複下載→ 存＋回想
• Rfetchpriority 寫在 img / script / link 上，值是 high | low | auto→ 存＋回想
• ENext.js 這類 SSR 框架比純 React SPA 受青睞：SPA 初載入得先跑一堆 JS 才畫得出主要內容→ 存＋演練

AI 補充作者念出了 preload 和 fetch priority，但屬性怎麼寫只出現在畫面上。截圖裡的寫法是 `<link rel="preload" href="style.css" as="style" />`、`as="script"`、`as="video" type="video/mp4"`——這裡的 `as` 不是可省略的裝飾，少了它瀏覽器不知道該用什麼優先權去抓，還可能重複下載一次，等於白做。這是作者跳過的一步。另外兩個容易踩的坑：preload 是「提早發現」不是「提早畫出」，濫用會讓所有東西都變高優先權，等於沒有優先權；而 LCP 那張主圖其實不用 preload，用 `fetchpriority="high"` 寫在 `<img>` 上更直接。至於 render blocking，作者只講了 JavaScript，但預設情況下 CSS 才是最典型的 render blocking 資源——瀏覽器沒解析完 CSSOM 就不會畫任何東西，所以「把關鍵 CSS 內嵌、其餘非同步載入」通常比動 JavaScript 更快見效。

術語:Content Delivery Network (CDN)i

4. FID：畫得出來還要按得動 2:40–3:31

光是畫面出現不夠，first input delay 量的是互動性：從使用者點下按鈕，到瀏覽器處理完該次互動的事件處理器要多久，100 毫秒以內算好、300 毫秒算差。優化它基本上只有一條路——減少 JavaScript 執行時間，但又不可能不寫 JavaScript，所以改用 web workeri、Partytowni 搬走一部分，或用 React lazy 這類延遲載入i，甚至用專為即時互動設計的 Qwiki。

推理因為前兩段解決的都是「多快看得到」，而看得到不等於用得動，所以作者接著換一個面向：互動性。他用同一套模板往下推——先給門檻（100 毫秒內算好、300 毫秒算差），再給定義（從使用者點下按鈕，到瀏覽器處理該次互動的事件處理器所花的時間），再給一句白話收束：「你不希望網站畫出來了，但上面的東西按了沒反應」。接著他做了一個關鍵推論：既然阻擋互動的是主執行緒被佔住，而佔住主執行緒的只有 JavaScript，那優化就只有一條路——減少 JavaScript 執行時間。但他馬上承認這條路走不通到底（「你也不可能把 JavaScript 全部丟掉」），於是給出三種折衷：搬走（web worker、Partytown）、延後（React lazy 之類的延遲載入）、換掉（Qwik 這種為即時互動設計的框架）。他也預告量測方式要留到擴充套件那段，因為 FID 沒有真實使用者就量不到。

• CFID：使用者第一次互動後，瀏覽器隔多久才開始跑對應的事件處理器；元兇是主執行緒被 JS 佔住→ 畫地圖
• RFID 門檻：100 毫秒內算好、300 毫秒算差→ 存＋回想
• EFID 已於 2024 年被 INP 取代，且 Google 判定用真實使用者的第 75 百分位→ 存＋演練
• P減少主執行緒佔用：找出長任務，切小、讓出、搬走或延後→ 練習
• Rlong task：單次佔用主執行緒超過 50 ms 的工作，才是互動延遲的真正兇手→ 存＋回想
• RPartytown 把第三方腳本搬進 web worker；Qwik 靠 resumability 連 hydration 都省→ 存＋回想

AI 補充這一段有兩件事需要更正，見本段的勘誤：一是作者對 FID 的定義說反了範圍，二是 FID 本身已經被換掉了。除此之外還有一個他沒說的關鍵：截圖裡那條 100ms／300ms 的刻度是 Google 的官方判定條，綠／橘／紅三段對應 good／needs improvement／poor，而判定用的是真實使用者的第 75 百分位——意思是你自己點一次很快，不代表指標是綠的。另外「減少 JavaScript 執行時間」這句話在實務上要再拆一層：真正的兇手是「長任務」（long task，單次佔用主執行緒超過 50ms 的工作）。所以有效的做法不只是「少寫一點 JS」，而是把大工作切小、在中間主動讓出主執行緒（例如 `await scheduler.yield()` 或退而求其次的 `setTimeout` 切片），讓瀏覽器有空檔回應點擊。作者提到的三種手段其實對應三個不同的時機：web worker 是把工作搬離主執行緒、lazy loading 是延後不需要的程式碼、Qwik 的可續性（resumability）則是連 hydration 都省掉。

術語:First Input Delay (FID)iInteraction to Next Paint (INP)i

5. CLS：畫面不能亂跳 3:31–4:19

最後一個指標 cumulative layout shift 量的是視覺穩定性：元素不該用意料之外的方式跳動。可用 Lighthouse 報告或 Web Vitals 擴充套件量。最常見的元凶是沒寫尺寸的圖片，補上 width/height 或改用 CSS aspect-ratioi 通常就能修好；響應式圖片要換長寬比時則用 srcseti。此外，被注入的廣告與動作過多的動畫也會讓 CLS 變差。作者在此收束：三個指標講完了，接著進實測。

推理因為載入（第 2 段）與互動（第 4 段）都已經有指標了，所以作者接著補上唯一還沒被量到的面向：視覺穩定性——「頁面上的元素不該用你意料之外的方式亂跳」。他這次不先給門檻數字，而是直接跳到成因，因為 CLS 的成因高度集中：最容易讓 CLS 變差的就是沒指定尺寸的圖片。原因很直接——瀏覽器在圖片載完之前不知道它多高，只好先當成 0，等圖片到了再把下面的內容整片推開。所以修法也直接：給 width 和 height，或用 CSS 的 aspect-ratio；只有響應式圖片要隨視窗換長寬比時，才需要 srcset 這種比較麻煩的做法。最後他補上兩個他控制不了的來源：被注入的廣告、動作太多的動畫。講完他就收線——「效能可以講一整天，但我認為這三個指標最重要」——把整段理論收束，準備轉進實測。

• CCLS：把頁面上所有非預期的位移量累加的分數；最大成因是沒指定尺寸的圖片→ 畫地圖
• Aaspect-ratio 修 CLS 修的不是圖片是版面預留——像餐廳先留座位，人到了不用擠別人→ 批判類比
• P修 CLS：每張 img 給 width / height 或 aspect-ratio；晚到的區塊先佔位→ 練習
• RCLS 門檻 0.1 以內好、超過 0.25 差；使用者互動後 500 ms 內的位移不計分→ 存＋回想
• R動畫安全屬性：transform 與 opacity 在合成階段處理，不觸發重排→ 存＋回想

AI 補充截圖裡的寫法是 `.img { aspect-ratio: 69/420; }`，這正好示範了一件作者沒點破的事：aspect-ratio 之所以能修好 CLS，是因為它讓瀏覽器在圖片還沒到之前，就能從寬度推算出高度並預留空間——修的不是圖片，是版面預留。也因此，同樣的技巧適用於任何「內容晚到」的區塊：廣告位、嵌入的影片、非同步載入的橫幅，都應該先用固定高度或 aspect-ratio 佔位。另外兩個作者略過的重點：第一，`width`／`height` 屬性在現代瀏覽器裡不會鎖死尺寸，它只是拿來算長寬比的，所以搭配 `width: 100%; height: auto` 的響應式 CSS 完全沒有衝突——很多人以為寫了就不能響應式，這是誤解。第二，並非所有位移都算 CLS：使用者互動後 500 毫秒內發生的位移會被豁免（因為那是使用者預期的），所以點按鈕展開選單不會扣分，但廣告自己插進來會。至於動畫，安全的做法是只動 `transform` 與 `opacity`，它們在合成階段處理、不觸發版面重排，也就不會產生位移分數。

術語:Cumulative Layout Shift (CLS)i

6. Web Vitals 擴充套件：單頁診斷 4:19–5:21

Chrome 團隊新出的 Web Vitals 擴充套件，安裝後到設定打開 console logging，開任一網頁的 console 就會看到 CLS 與 LCP 的記錄。LCP 會直接指出是哪個元素造成的，並拆解出 time to first byte 與 element render delayi；layout shift 會列出造成位移的 DOM 元素；點擊頁面則會記錄 first input delay 與之後每次互動。作者說它的價值在於「直接指出該修哪一個東西」，但缺點是一次只能看一頁。

推理因為前三段建立的都是定義，而定義沒辦法告訴你「這一頁該改哪裡」，所以作者接著要一個能落到具體元素的工具。他刻意選最低摩擦的路徑：安裝擴充套件、到設定打開 console logging、開一頁看 console，三步就有數字。接著他依序展示這個工具能回答什麼——LCP 不只給秒數，還直接指出是哪一個元素造成的，並拆成 time to first byte 與 element render delay 等子項；layout shift 會列出實際造成位移的 DOM 元素；點一下頁面就會記到 first input delay 與之後每一次互動。這三件事正好一一對應前面三個指標，等於把理論逐條驗收。最後他給出這個工具的價值判斷（「它最強的是精準指出該修哪一個東西」）與它的邊界（一次只能看一頁），而這個邊界就是他推進下一段的槓桿。

• PWeb Vitals 擴充套件三步：安裝、設定開 console logging、開一頁看 console→ 練習
• CTTFB：從發請求到收到第一個位元組，是 LCP 四段拆解的第一段，佔大宗代表問題在伺服器或網路→ 畫地圖
• Efireship.io LCP 136 ms 拆成 TTFB 24、load delay 7、load time 0、render delay 105→ 存＋演練
• R擴充套件量到的是你這一台、這一次的單次觀測；Google 判定用真實使用者 p75→ 存＋回想

AI 補充三張截圖比作者的口述多給了不少東西。第一張是 fireship.io 的 console，可以看到記錄的格式就是 `[Web Vitals Extension] LCP 136 ms (good)`、`CLS 0.00 (good)`——指標、數值、評級一行到位，這是它比 Lighthouse 輕的地方：不用跑一輪稽核，正常瀏覽就在收數據。第二張展開 LCP，資訊量最大：LCP element 直接印出那個 `<img src="/courses/supabase/img/featured.webp">`，下面的表格把 136ms 拆成 Time to First Byte 24、Resource load delay 7、Resource load time 0、Element render delay 105。作者口述只提了頭尾兩項，但這張表其實是四項，而且四項的分佈就是診斷書——這一頁的 105ms 全壓在 element render delay，代表圖片早就下載完了、卡的是渲染，那麼壓縮圖片或換 CDN 都不會有用，該查的是 render blocking 的 CSS 或 JS。反過來如果 TTFB 佔大宗，問題在伺服器或網路，跟前端怎麼改都無關。第三張展開的其實是 CLS 而不是 FID：它列出 Layout shift score 0.0088 與造成位移的 `<ul class="flex justify-center items-center">`、`<main class="prose ...">`，滑鼠移過去還會在頁面上把那個元素框起來——這就是作者說的「精準指出該修哪一個」。一個實務提醒：擴充套件量到的是你這一台機器、這一次瀏覽的數字，屬於單次觀測；Google 判定用的是真實使用者第 75 百分位，兩者不會一致，這個工具的用途是定位問題而不是驗收成績。

術語:Web Vitals Chrome extensioniTime to First Byte (TTFB)i

7. Unlighthouse：整站掃描與實測 5:21–6:43

單頁工具在幾百上千頁的網站上不管用，所以作者介紹開源的 Unlighthousei：對全站每一頁平行跑 Lighthouse，幾分鐘掃完數百頁，用法是 npx unlighthouse 加網址。他用它掃自己的站，找出原本不會發現的爛頁面；再拿熱門網站實測——Amazon 意外地不錯但有明顯 CLS 問題，Google 表現極好，Reddit 與 GitHub 平均約 90 分，astroi.build 幾乎全部滿分。最後提到它有 SDK，可以接進 CI。

推理因為手動一頁一頁量在大型網站上不可行，所以作者接著找的是規模化的工具：Unlighthouse 會對網站每一頁都跑一次 Lighthouse，而且全部平行處理，幾分鐘就能掃完上百頁。他先降低嘗試成本（開個新資料夾、`npx unlighthouse` 加網址就跑），再給自身經驗當佐證——他掃自己的站，找到幾個「不掃根本不會發現」的爛頁面，這正是整站掃描相對單頁工具的真正價值：發現你不知道自己有問題的地方。有了工具，他才敢做最後一步——拿真實網站當對照組：Amazon 出乎意料地不錯（但用擴充套件看有明顯 CLS 問題，回頭呼應第 5 段），Google 表現極好（合理，規則是他們訂的），Reddit 與 GitHub 平均約 90，astro.build 幾乎滿分。這串排名的作用不是八卦，而是證明前面講的原則在真實世界會產生可見的分差。最後他補上 SDK 可接進 CI，把一次性的檢查升級成持續的防線——這是整支影片從「知道」走到「守得住」的最後一步。

• PUnlighthouse：npx unlighthouse --site <網址>，自動爬路由平行跑 Lighthouse 掃整站→ 練習
• E實測：Google 極好、Amazon 不錯但 CLS 明顯、Reddit／GitHub 約 90、astro.build 99 分→ 存＋演練
• RAstro：預設不送 JavaScript，建置時渲染成 HTML，只有需互動的元件才單獨載入→ 存＋回想
• R把效能變成流程：Unlighthouse SDK 接進 CI，設分數門檻擋 PR→ 存＋回想

AI 補充截圖補了幾個口述沒有的細節。第一張是命令的正式寫法：`npx unlighthouse --site <your-site>`——網址要跟在 `--site` 後面，光打網址是不會動的，這是作者口述略過的一步。第二張是掃 amazon.com 的即時畫面：ROUTES 147、worker 進度 44%（154/354）、DEVICE 是 Emulated Mobile，左側分成 Performance／Accessibility／Best Practices／SEO 四欄，每個路由的狀態在 In progress 與 Waiting 之間流動——這張圖真正說明的是「平行掃描」長什麼樣，以及它會自動爬站找出路由並依樣板分組（Coupons-slug、Smart-Home-slug…），你不用自己列 URL 清單。要注意此時 SITE SCORE 還在轉圈，所以作者口中「Amazon 表現不錯」的結論並不在這張畫面上。第三張是 astro.build 的成績單：SITE SCORE 99、36 個路由，Performance 100、Accessibility 99、Best Practices 98、SEO 100，逐列幾乎都是四個 100。這裡有個容易誤讀的地方：Amazon 有 147 個路由、astro.build 只有 36 個，掃描範圍差了四倍，而且預設在模擬行動裝置與節流條件下跑，所以這些數字適合當同一支工具的相對參考，不適合當精確排名。最後，「接進 CI」的實務做法是設一條分數門檻，PR 掉到門檻以下就擋——這比「上線後才發現變慢」有用得多，也是整支影片唯一一個把效能變成流程而非一次性活動的建議。

術語:Continuous Integration (CI)i