ExplainThis 全端開發雙週報 #61 衡量網站表現不能不知道的 Web Vitals
衡量網站表現不能不知道的 Web Vitals
嗨～歡迎閱讀全端開發雙週報 #61 期
在這期最開始前，想先感謝讀者們的支持，截至上週 ExplainThis 推出的 E+ 成長計畫(連結) 的累積訂閱人數，突破 750 位，我們由衷地感謝讀者們的支持！
由於陸續有讀者詢問「是否能用公司教育補助訂閱 E+ 成長計畫?」。針對這個問題，確實過去有不少讀者是透過所任職的公司的教育補助來訂閱，我們有做了一個相關頁面說明 (連結)。
如需簡易的 E+ 成長計畫說明文件，我們也製作了 PDF 格式的申請說明 可以讓部門主管或人資參考使用（如果你是在台灣訂閱 E+，可以於結帳時勾選需要統編，我們會協助開立有統編的發票）。
以上，接著讓我們進到這期的主題文吧！
衡量網站表現不能不知道的 Web Vitals
環法自由車賽 (Tour de France) 是世界最有名的公路車大賽之一，最近在社群中看到，有一個開發者兼車迷去分析環法自由車賽中，每個參賽隊伍的官方網站，來看各個網站在綜合表現的排名 (連結)。
不過這時問題就來了，在衡量網站的表現，用的是什麼指標? 舉例來說，要用速度嗎? 如果是的話又要衡量哪個時間點? 畢竟瀏覽器加載網站的過程中，有非常多的時間點，從收到第一個位元，到 HTML 完成載入，再到所有靜態元素都到位，在衡量時該用哪一個? 為什麼?
針對這個問題，目前業界最多人使用的，是由 Google 提出的 Web Vitals 指標。
Web Vitals 系列指標主要看三件東西：
LCP (Largest Contentful Paint)
INP (Interaction to Next Paint)
CLS (Cumulative Layout Shift)
LCP (Largest Contentful Paint)
Largest Contentful Paint 是指最大內容繪製，這個指標看的是加載的效能，具體衡量的是指網頁中最大的內容被繪製在畫面上的時間點。
畫面上有東西出現，是 FCP (First Contentful Paint)，但是有東西出現，不代表那個東西是對使用者有用的。舉例來說，如果是出現在轉圈圈的加載動畫，雖然有東西在畫面上，但並不是真正的內容。
過去有些指標會衡量 FMP (First Meaningful Paint)，意即去衡量，是需要開發者自行去定義，比較難抓通用的衡量，因此 LCP 抓最大的那個元素被渲染的時間點。不過這邊有個前提假設，是最大的那個是最重要的。
一般來說，LCP 2.5 秒內才是好，換句話說，從使用者進到網站，到網頁中最大元素出現，需要在 2.5 秒內完成。而 LCP 如果在 2.5 到 4 秒是可接受，超過 4 秒會嚴重影響使用者體驗。
INP (Interaction to Next Paint)
Interaction to Next Paint 是指從使用者開始互動到畫面完成繪製這段時間，這個指標最核心的概念是衡量「使用者要等多久才能跟前端應用互動」，也就是互動時的延遲，假如這段時間常，表示使用者互動後，要等很久才有反應，這樣使用者體驗就不會好。
試想，如果使用者看到畫面上有按鈕，結果點下去什麼都沒發生，大概會覺得很困惑，甚至會因此以為是壞掉了所以關掉網站。
在使用者與網站互動 (例如點某個按鈕後)，會有幾件事發生：
首先瀏覽器要先處理完手邊正在做的事
然後處理點擊按鈕觸發的事件
這時瀏覽器也可能會塞其他事情來做
最後才根據該事件處理器中的邏輯，重新渲染 DOM 並去繪製新的畫面
可以看到，在使用者開始互動 (interaction) 到瀏覽器繪製新的畫面 (paint) 這中間，瀏覽器可能會去做其他事，這是因為瀏覽器要最大化利用運算資源。而因為 JavaScript 是單線程，所以如果當瀏覽器去做其他事的時間拉長，就可能導致 INP 變久。
CLS (Cumulative Layout Shift)
相信可能很多人過去都遇過以下的狀況，當在網站上想要點某個東西，結果點下去之前突然跳出廣告，導致原本要點的東西沒點到，反而點到了廣告，覺得非常不愉快。這種不愉快意味著從使用者的角度來看，網站的視覺存在不穩定性。
而 CLS (Cumulative Layout Shift) 正是在量測網站的視覺穩定性，當越穩定，意味著越少的跳動，也意味著更好的使用者體驗。特別注意，CLS 的 C 是 Cumulative 意思是累加的，所以在優化 CLS 時，需要從整體的角度看，確保網頁盡可能沒有突發的移動。
閱讀更多
在了解完 Web Vitals 是什麼後，下一步就是要了解該如何優化。這些指標的具體優化指南，我們在 E+ 成長計畫的主題文都有談到。如果你對 Web Vitals 或是其他前端效能優化的方法感興趣，歡迎加入 E+ 成長計畫 (連結)。
本期推薦
在社群中有人製作了一個叫 Torvalds Mode 的提示詞，很多人分享用這個提示詞請 AI 協助 code review 非常有效。假如你也想要有一個嚴格的角色督促自己寫程式，或許可以試試 (連結)
前陣子 Notion 推出離線版本 ，背後用到 CRDT 這個技術。Notion 團隊的人有跟著名的 DDIA 作者，合寫了《Peritext: A CRDT for Collaborative Rich Text Editing》一文 (連結) 。關於離線 (本地優先) 的軟體設計，我們先前也有寫相關內容，推薦不熟的讀者可以溫習 (連結)
富文本編輯器 (rich-text editor) 的實作是前端的一大難題，最近看到社群越來越多人使用開源專案 Plate.js (連結)；這個開源專案除了把各類編輯器細節都考量了，甚至可以用很輕鬆的方式，整合 AI 功能到編輯器中。不論是想在產品中加入富文本編輯器，或是想理解這種進階前端如何實作，都推薦可以去讀原始碼
Vercel 最近發了《Preparing for the worst: Our core database failover test》談他們如何做災害復原測試，來確保即使有意外發生，仍能夠確保服務持續可用，是很難得的實務分享 (連結)
最近 Bun 分享了一篇《500x faster postMessage(string)》 談了，他們如何有效加速
postMessage這個方法達 500 倍，同時減少 22 倍記憶體消耗，文章不長但非常有洞見，推薦一讀 (連結)在 JavaScript 社群中，越來越多團隊使用 es-toolkit 這個套件（連結)，來取代傳統的
lodash-es，手寫題可以看我們先前整理的。關於這類套件提供的效用函式，經常會在前端面試中出現，推薦可以一讀原始碼。先前我們也有彙整一系列前端手寫題，感興趣的讀者也推薦回顧 (連結)37signals 的創辦人 Jason Fried 多年前寫過一篇《Give it five minutes》 的反思文 (連結)，談到「在批評一件事情前，先花五分鐘多想」 是改變他職涯的重要習慣，這點也是我們特別感同身受的。
文末彩蛋
最近有人在社群中討論 Replit 的創辦人兼執行長 Amjad Masad 的經歷，當年他離開 Facebook (現在的 Meta) 創業後，其實經歷很長一段時間，公司比起其他新創相對不亮眼。
以 ARR (年經常性營收) 來說，在創辦前六年都還只停在一百萬美元左右 (對許多發展迅速的新創，這是在一到兩年可以達成的)。然而在 2022 到 2025 年中這段期間，Replit 的 ARR 從一百萬美元，成長了足足 150 倍，達到一億五千萬美元，火箭式的成長是過去幾年無法比擬的。
針對這個討論，Amjad Masad 引用了比爾蓋茲說過的一句話「多數人高估了自己一年內能完成的事，卻低估了自己十年內能達到的成就」來回覆。
Most people overestimate what they can do in one year and underestimate what they can do in ten years — Bill Gates
在現代軟體科技業，透過募資在短期內快速擴張是主流方法；相比短期迅速累積的成就，長期把腳步踏穩、用扎實的方式累積，反而是常會被忽略的方式。比起那些快速崛起又快速隕落的公司 (近期比較有名的包含 WeWork、FTX 等等)，我們認為 Replit 的成長軌跡，是更健康一點的。
這個觀點不僅適用公司經營，在個人職涯成長上也是，用長遠的眼光，踏實地累積，以十年的角度來看，能夠達到的蛻變與成就，是很多人會忽略的。
對此，假如你正在為自己所處的職涯狀態感到煩惱，覺得自己比不上身邊那些已經取得某些世俗定義的成就的同齡人，推薦可以換個角度想，放眼十年後的未來，然後在接下來職涯中，不求快但求不懈怠，穩步累積後，相信未來會能夠站到某個意想不到的高度。
追蹤 ExplainThis
感謝看到這期雙週報最後的你，除了雙週報，我們在其他的平台也會分享不同的內容，歡迎在你有使用的平台追蹤 ExplainThis