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