本案例研究說明 GoDaddy 如何改善數百萬個網站的網站效能，協助這些網站獲得良好的 PageSpeed Insights 和 Core Web Vitals 分數。
GoDaddy 是全球最大的創業服務平台，我們的使命是為全球 2,000 多萬名客戶和創業者提供協助，提供他們在線上成長所需的所有工具。
GoDaddy 於 2019 年推出 Websites + Marketing，致力於提供簡單易用的工具和服務，協助商家達成目標。Websites + Marketing 整合了網站建置工具、行銷工具和電子商務工具，並提供頂尖的操作說明，協助客戶在新的事業中取得成功。
自「網站 + 行銷」推出以來，效能一直是產品的重要一環，我們也積極監控及改善效能。本文將回顧 GoDaddy 從使用實驗室效能測試，到採用 Core Web Vitals 的實際資料，以及產品為了讓客戶網站達到極高的通過率而進行的一系列改善。
使用 Lighthouse 追蹤成效
我們一直仰賴 Lighthouse 資料追蹤成效。每當平台上發布網站時，我們會使用名為「Lighthouse4u」的內部工具評估其效能，該工具提供 Google Lighthouse 服務 https://github.com/godaddy/lighthouse4u。這有助於我們瞭解網站在實驗室環境中的整體表現。
由於我們平台上託管的數百萬個網站具有多種功能和內容，因此我們必須將成效資料與每個測試網站的中繼資料 (例如使用的範本、顯示的小工具類型等) 結合。這讓我們得以得出結論，瞭解哪些網站功能成效較低，同時提供洞察資料，協助我們找出可改善的部分。
舉例來說，這項功能有助於我們發現「彈出式模式」對網頁速度造成負面影響，啟用這項功能的網站效能比未啟用時低了 12 分。更新程式碼以延後 JavaScript 載入作業後，我們的 Lighthouse 分數提高了 2 分。我們可以將這項學習結果套用至其他功能，例如在網頁載入後立即顯示的「Cookie 資訊欄」。
除了根據功能查看有問題的網站，我們也分析了 JavaScript 組合，發現大部分的大小都來自外部依附元件 (immutable.js 和 draft.js)。我們重新建構消費者，讓其按需延後載入依附元件，藉此縮減套件大小。這使得常見的 JavaScript 套件大小從 200 KB 以上降至 90 KB 左右 (經過精簡)，減少幅度超過 50%。較小的套件大小可讓瀏覽器在初始網站載入生命週期較早的階段載入外部素材資源，並執行重要指令碼，進而提升最大內容繪製時間 (LCP) 和首次輸入延遲時間 (FID)。
在我們的持續努力下，客戶網站的 Lighthouse 平均分數從 2020 年 11 月的 40 分左右，提升至 2021 年 5 月的 70 分以上。不過，並非所有嘗試都成功，而且有時我們會發現，在本機測試環境中測試的結果，與實際測試結果不一定一致。實驗室測試結果非常實用，但現在是時候著重於實際觀察到的使用者體驗。
運用 Core Web Vitals 追蹤實際使用者資料
在客戶的網站中加入 web-vitals 程式庫後，我們就能測量實際訪客在實際裝置上的資料，因為這些裝置的硬體、網路速度和使用者互動 (例如捲動或點擊) 並非使用 Lighthouse 進行實驗室設定時的一致基準。這項做法是朝正確方向邁進的重要一步，因為我們現在擁有代表網站訪客體驗的資料。
著重於最弱的環節：累計版面配置位移 (CLS)
分析新資料後，我們有了新的想法，知道如何改善網站速度。由於我們致力改善 Lighthouse 分數，因此 75 百分位數的 LCP 為 860 毫秒，而 FID 在相同門檻下低於 10 毫秒，因此客戶網站的這些指標通過率相當高，分別為 78% 和 98%。不過，累計版面配置位移 (CLS) 的數字與 Lighthouse 的數字有相當大的差異。我們的 CLS 在第 75 百分位數為 0.17，超過「通過」的 0.1 門檻，因此所有網站的通過率只有 47%。
這項指標將整體通過率拉低至 40%，因此我們決定設定遠大目標，在 2021 年 8 月底前將這項指標提高至 60% 以上。為此，我們必須著重於 CLS。
在實際情況下，使用者會與網頁互動，並捲動「上方」內容，這正是網站體驗核心指標能更準確捕捉的情況。由於使用者在網站初次載入時與網站互動的方式各有不同，因此 CLS 與實驗室和實地資料有所差異。
如何通過所有 Core Web Vitals
改善成效需要反覆嘗試，而且每次嘗試不一定都能發揮預期的效果。不過，我們也做了一些改善，以便達成目標。
預留圖片載入空間可大幅改善 CLS 分數，因為這樣可避免圖片下方的內容轉移。我們使用 CSS aspect-ratio 屬性解決這個問題，適用於支援 CSS 的瀏覽器。對於未提供圖片的網站，我們會載入快取的透明預留位置圖片，大小只有幾個位元組，因此幾乎可即時載入。
這項通用圖片行為可讓我們在伺服器端算繪期間，根據可視區寬度和圖片顯示比例預先計算最終圖片高度。這會產生 HTML 標記，並為最終圖片保留適當的垂直空間。在行動裝置上，這項改善特別明顯，因為圖片會算繪至行動裝置視區的完整範圍。
客戶網站上的某些元件含有動態內容 (例如外部顧客評論清單)，無法轉換為純 CSS，因此無法充分發揮伺服器端算繪的效能優勢。這些區域的內容 (以及高度) 會有所不同，因此很難改善版面配置移位。在這些情況下，我們會將元件包裝在容器中，並套用 min-height，此預設值是根據每個特定元件的平均高度觀察結果決定。內部動態元件完成轉譯後，系統就會移除 min-height。雖然這個解決方案並非完美無缺，但確實能大幅減少版面配置偏移情形。
除了專注於改善 CLS，我們也持續改善 LCP。在許多網站上，圖片是導致 LCP 的最大原因，這也是我們明顯需要改善的部分。我們已使用 IntersectionObserver 改善延遲載入圖片的功能，但我們發現圖片大小並未以最理想的方式設定為每個中斷點 (行動裝置、平板電腦、電腦、大型電腦)，因此我們更新了圖片產生程式碼，以便限制及調整每個中斷點的圖片，然後根據像素密度再次調整解析度。舉例來說，這項功能可將特定大型圖片的大小從 192 KB 縮減至 102 KB。
為了在網路連線速度較慢的裝置上快速轉譯網站，我們新增了程式碼，可根據連線速度動態縮小圖片品質。您可以使用 navigator.connection 傳回的 downlink 屬性完成這項操作。我們會根據這些網路條件，透過資產 API 套用以網址為基礎的查詢參數，降低圖片品質。
客戶網站的部分內容會以動態方式載入。由於我們知道在特定網站發布時，哪些部分會算繪，因此使用 rel=preconnect 資源提示，提前初始化連線和必要的握手動作。我們也會使用資源提示快速載入字型和其他重要資源。
建構網站時，客戶會新增各種區段，其中可能包含內嵌指令碼，以便提供不同的功能。在整個 HTML 網頁中內嵌這些指令碼，不一定能達到最佳效能。我們決定將這些指令碼外部化，讓瀏覽器可非同步載入及剖析指令碼內容。新外部化指令碼也可以在不同網頁間共用。這可透過瀏覽器和 CDN 快取，進一步提升效能。我們將重要的指令碼保留在內文中，讓瀏覽器能更快速地剖析及執行這些指令碼。
結果
專注於改善 CLS 的努力終於獲得回報，我們的 Core Web Vitals 通過率從約 40% 提升至近 70%，改善幅度高達 75%！
使用者回來平台更新及重新發布網站後，就能獲得最新的效能改善功能，因此「通過 Core Web Vitals」的網站數量持續增加，如下圖所示：
結論
要找出可改善成效的領域，並成功追蹤進度，取決於您使用哪些評估工具。雖然 Lighthouse 可用於在「實驗室設定」中評估可見區域以上的效能，但無法準確擷取僅因使用者互動 (例如捲動網頁) 而發生的效能問題。
我們使用中繼資料追蹤實際的 Core Web Vitals，進而將改善成效視覺化、鎖定目標並加以評估。在改善 Core Web Vitals 分數的過程中，團隊成員找出了程式碼庫中不良的效能模式，並予以取代。有時看似有希望的變更，成效卻不如預期，有時則相反。這不是完美的世界，所以你必須持續嘗試。