提高核心網絡生命力，一個 Smashing Magazine 案例研究
已發表: 2022-03-10“為什麼我的 Core Web Vitals 失敗了？” 許多開發人員最近一直在問自己這個問題。 有時很容易找到該問題的答案，而網站只需要在性能上進行投資。 但有時，它有點棘手，儘管出於某種原因認為您的網站在性能方面非常出色，但它仍然失敗。 這就是我們自己的 smasingmagazine.com 所發生的事情，要弄清楚並解決這個問題，需要進行一些挖掘。
呼救聲
這一切都始於去年三月的一系列推文，呼救聲：
嗯，這引起了我的興趣！ 我是 Smashing Magazine 的忠實粉絲，並且對 Web 性能和 Core Web Vitals 非常感興趣。 我之前在這裡寫過一些關於 Core Web Vitals 的文章，並且總是很想看看他們的年度 Web 性能檢查表中有什麼。 因此，Smashing Magazine 了解 Web 性能，如果他們在苦苦掙扎，那麼這可能是一個有趣的測試案例！
我們中的一些人在使用我們最喜歡的一些 Web 性能分析工具（如 WebPageTest 或 PageSpeed Insights）後就該線程可能出現的問題提出了一些建議。
調查 LCP 問題
問題是 LCP 在移動設備上太慢了。 LCP 或最大內容繪製是您必須“通過”的三個核心 Web 生命值之一，作為其頁面體驗更新的一部分，您必須從谷歌獲得完整的搜索排名提升。 顧名思義，LCP 旨在測量頁面的最大內容何時被繪製（或“繪製”）到屏幕上。 通常這是主圖或標題文本。 它旨在衡量網站訪問者可能來到這裡看到的內容。
以前的指標衡量的是第一次繪製到屏幕上的變化（通常是標題或背景顏色）； 附帶的內容並不是用戶真正想要離開頁面的內容。 最大的內容通常是一個很好的指標或最重要的指標。 並且名稱的“內容”部分錶明該指標旨在忽略（例如背景顏色）； 它們可能是最大的內容，但它們不是“內容”，所以不要計算 LCP，而是算法試圖找到更好的東西。
LCP 只查看初始視口。 只要您向下滾動或以其他方式與頁面交互，LCP 元素就固定了，我們可以計算從頁面第一次開始加載時繪製該元素需要多長時間 - 這就是您的 LCP！
有很多方法可以衡量你的核心網絡生命值，但最終的方法——即使它不是最好的方法，我們很快就會看到——是在谷歌搜索控制台 (GSC) 中。 從 SEO 的角度來看，其他工具告訴您什麼並不重要，GSC 就是 Google 搜索所看到的。 當然，重要的是您的用戶體驗而不是某些搜索引擎爬蟲看到的內容，但 Core Web Vitals 計劃的一大優點是它確實衡量了真實的用戶體驗，而不是 Google Bot 看到的內容！ 因此，如果 GSC 說您有不好的體驗，那麼根據您的用戶，您確實有不好的體驗。
Search Console 告訴 Smashing Magazine，他們的大部分網頁在移動設備上的 LCP 都需要改進。 足夠標準的 GSC 部分輸出並且很容易解決：只需讓您的 LCP 元素繪製得更快！ 這不應該花費太長時間。 當然不是六個月（或者我們認為）。 因此，首先要找出 LCP 元素是什麼。
通過 WebPageTest 運行失敗的文章頁面突出顯示了 LCP 元素：
改善 LCP 形象
OK，所以文章作者照片就是LCP元素。 第一個直覺是問我們可以做些什麼來加快速度？ 這涉及深入研究瀑布，查看何時請求圖像，下載需要多長時間，然後決定如何優化它。 在這裡，圖像在大小和格式方面得到了很好的優化（通常是提高圖像性能的第一個也是最簡單的選項！）。 該圖像是從一個單獨的資產域提供的（通常對性能不利），但短期內不可能改變它，Smashing Magazine 已經添加了一個preconnect資源提示以盡可能加快速度可以。
正如我之前提到的，Smashing Magazine 了解 Web 性能，直到最近才致力於提高性能，並且在這裡做了所有事情，但仍然失敗了。 有趣的…
其他建議包括減少負載、延遲服務工作者（以避免爭用）或調查 HTTP/2 優先級，但它們對 LCP 時間沒有必要的影響。 因此，我們必須訪問我們的 Web 性能工具包以獲取所有提示和技巧，看看我們還能在這裡做些什麼。
如果資源對頁面加載至關重要，您可以內聯它，因此它包含在 HTML 本身中。 這樣，頁面就包含了進行初始繪製所需的所有內容，而不會延遲。 例如，Smashing Magazine 已經內聯了關鍵的 CSS 以允許快速首次繪製，但沒有內聯作者的圖像。 內聯是一把雙刃劍，必須謹慎使用。 它增強了頁面，並意味著後續的頁面瀏覽量不會從數據已經下載的事實中受益。 因此，我不喜歡過度內聯，並認為必須謹慎使用它。
因此，通常不建議內聯圖像。 然而，這裡的圖像給我們帶來了真正的問題，相當小，並且直接鏈接到頁面。 是的，如果您閱讀了該作者的大量文章，那麼多次重新下載同一圖像而不是下載該作者的圖像並重複使用它是一種浪費，但您很可能在這裡閱讀不同作者的不同文章.
最近在圖像格式方面取得了一些進步，但 AVIF 已經引起了轟動（至少在 Chrome 和 Firefox 中），並且與傳統上用於照片的舊 JPEG 格式相比，它具有令人印象深刻的壓縮效果。 Vitaly 不想內聯作者圖像的 JPEG 版本，但調查了內聯 AVIF 版本是否可行。 使用 AVIF 壓縮作者圖像，然後將圖像 base64 轉換為 HTML 會導致 HTML 頁面重量增加 3 KB — 這是很小的，因此是可以接受的。
由於當時僅在 Chrome 中支持 AVIF（畢竟它來到了 Firefox），並且由於 Core Web Vitals 是 Google 的一項舉措，因此由於 Google 的法令，它確實對 Google 瀏覽器的優化感到有些“噁心”。 Chrome 通常處於新功能支持的最前沿，這是值得稱讚的，但當其業務的這兩個方面相互影響時，它總是感覺有點不對勁。 儘管如此，這是一種新的標準圖像格式，而不是一些專有的僅限 Chrome 的格式（即使它最初只在 Chrome 中受支持），並且是性能的漸進增強（Safari 用戶仍然可以獲得相同的內容，只是速度沒有那麼快)，因此添加了 AVIF 扭曲 Smashing 接受了建議並內聯了圖像，並且確實在實驗室工具中看到了令人印象深刻的結果。 問題解決了！
另一種 LCP
所以，我們讓那張床進來，像往常一樣等了 28 天左右，讓 Core Web Vitals 的數字全部變綠……但他們沒有。 它們在綠色和琥珀色之間徘徊，所以我們當然改進了一些東西，但還沒有完全解決問題。 在琥珀“需要改進”部分停留了很長時間後，維塔利伸出手來看看是否還有其他想法。
圖像畫得很快。 不是立即（畢竟處理圖像仍然需要時間），但盡可能接近。 老實說，我的想法已經不多了，但我又用新的眼光看了一眼。 然後我想到了一個替代想法——我們是否優化了正確的 LCP 元素？ 作者當然很重要，但這真的是讀者來這裡看到的嗎？ 儘管我們的自尊心想說是的，而且我們美麗的閃亮杯子比我們寫的內容重要得多，但讀者可能不這麼認為（讀者，呵呵——你能做什麼！）。
讀者是為了這篇文章，而不是作者。 所以 LCP 元素應該反映這一點，這也可能解決 LCP 圖像繪製問題。 為此，我們只需將標題放在作者圖片上方，並稍微增加移動設備上的字體大小。 這聽起來像是以犧牲用戶為代價來欺騙 Core Web Vital SEO Gods 的偷偷摸摸的把戲，但在這種情況下，它對兩者都有幫助！ 儘管許多網站確實試圖針對真實用戶進行快速簡便的破解或針對 GoogleBot 進行優化，但事實並非如此，我們對這裡的決定感到非常滿意。 事實上，進一步的調整完全刪除了移動視圖上的作者圖像，空間有限，該文章目前在移動設備上看起來像這樣，並突出顯示了 LCP 元素：
在這裡，我們展示了標題、文章的關鍵信息和摘要的開頭——對用戶來說比用一張大照片佔據所有寶貴的手機屏幕空間更有用！
這就是我喜歡 Core Web Vitals 的主要優點之一：它們正在衡量用戶體驗。
要改善指標，您必須改善體驗。
“
現在我們終於完成了。 文本的繪製速度比圖像快得多，因此應該可以解決 LCP 問題。 非常感謝大家，晚安！
我討厭谷歌搜索控制台中的 CWV 圖表……
我們又一次失望了。 這並沒有解決問題，不久之後 Google Search Console 圖表就恢復為琥珀色：
在這一點上，我們應該多談談頁面分組和 Core Web Vitals。 您可能已經從上圖中註意到，幾乎整個圖表同時波動。 但也有一個大約 1,000 頁的核心組大部分時間都保持綠色。 這是為什麼？
好吧，Google Search Console 將頁面分類為頁面分組，並測量這些頁面分組的 Core Web Vitals 指標。 這是為那些沒有獲得足夠流量以獲取有意義的用戶體驗數據的頁面填充缺失數據的嘗試。 他們可以通過多種方式解決這個問題：他們可能只是沒有對此類頁面進行任何排名提升，或者可能假設最好並在沒有任何數據的情況下對頁面進行全面提升。 或者他們可能已經退回到原始級別的核心網絡生命體徵數據。 相反，他們試圖做一些更聰明的事情，這是一種有益的嘗試，但在許多方面也更令人困惑：頁面分組。
基本上，每個頁面都分配有一個頁面分組。 他們如何做到這一點尚不清楚，但之前已經提到過頁面上使用的 URL 和技術。 您也看不到 Google 為您的每個頁面選擇了哪些分組，以及他們的算法是否正確，這對網站所有者來說是另一個令人沮喪的事情，儘管他們確實在圖表下方為每個不同的 Core Web Vitals 分數提供了示例 URL在 Google Search Console 中，有時可以從中隱含分組。
頁面分組可以很好地適用於 Smashing Magazine 等網站。 對於其他站點，頁面分組可能不太清楚，許多站點可能只有一個分組。 然而，Smashing 網站有幾種不同類型的頁面：文章、作者頁面、指南等。 如果文章頁面很慢，因為作者圖像是 LCP 圖像，加載速度很慢，那麼所有文章頁面都可能出現這種情況。 並且所有文章頁面的修復可能都是相同的。 所以把它們組合在一起是有意義的（假設谷歌可以準確地找出頁面分組）。
然而，當一個頁面確實獲得了足夠多的訪問者以獲得它自己的核心 Web 生命值分數並且它通過了，但它被歸為一個失敗的組時，它可能會讓人感到困惑。 您可以為站點中的所有頁面調用 CrUX API，看到它們中的大多數都通過了，然後當這些相同的頁面在 Search Console 中顯示為失敗時會感到困惑，因為它們已被歸為一個包含失敗 URL 的組，並且大多數該組的流量用於失敗。 我仍然想知道 Search Console 是否應該使用頁面級 Core Web Vital 數據，而不是始終使用分組數據。
無論如何，這說明了大幅波動。 基本上，所有文章（其中大約有 3,000 篇）似乎都在同一個頁面分組中（並非不合理！）並且該頁面分組要么通過，要么失敗。 當它切換時，圖形會急劇移動。
您還可以通過 CrUX API 獲得有關 Core Web Vitals 的更詳細數據。 這在原始級別（即整個站點）或單個 URL（存在足夠數據的情況下）可用，但在頁面分組級別不可用。 我一直在使用 CrUX API 跟踪原始級別 LCP 以獲得更精確的 LCP 測量結果，它也顯示了一個令人沮喪的故事：
我們可以看到我們從來沒有真正“解決”過這個問題，“好”頁面的數量（上面的綠線）仍然徘徊在 75% 的通過率附近。 此外，p75 LCP 分數（使用右手軸的虛線）從未真正遠離 2500 毫秒閾值。 難怪通過和失敗的頁面來回翻轉。 糟糕的一天，加上一些更慢的頁面加載，足以將整個頁面分組翻轉到“需要改進”類別。 我們需要更多的東西來給我們一些空間來吸收這些“糟糕的日子”。
在這一點上，很想進一步優化。 我們知道文章標題是 LCP 元素，那麼我們可以做些什麼來進一步改進它？ 嗯，它使用了一種字體，而字體一直是網絡性能的禍根，所以我們可以研究一下。
但請稍等。 Smashing Magazine 是一個快速的網站。 通過 Lighthouse 和 WebPageTest 等網絡性能工具運行它表明——即使在較慢的網絡速度下。 它做的一切都是正確的！ 它是作為靜態站點生成器構建的，因此不需要任何服務器端生成，它內聯了初始繪製的所有內容，因此除了 HTML 本身之外沒有資源加載限制，它由 Netlify 在 CDN 上託管，所以應該靠近它的用戶。
當然，我們可以考慮刪除字體，但如果 Smashing Magazine 無法提供快速體驗，那麼其他人又能如何呢？ 通過 Core Web Vitals 應該不是不可能的，也不要求您只在沒有字體或圖像的普通網站上。 這裡還有其他事情，是時候了解更多關於正在發生的事情，而不是盲目地嘗試另一輪優化。
深入挖掘指標
Smashing Magazine 沒有 RUM 解決方案，因此我們深入研究了谷歌為前 800 萬個左右的網站收集的 Chrome 用戶體驗報告 (CrUX) 數據，然後使這些數據可用於以各種形式查詢。 正是這些 CrUX 數據推動了 Google Search Console 數據以及最終的排名影響。 我們已經在使用上面的 CrUX API，但決定深入研究其他 CrUX 資源。
我們使用站點地圖和 Google Sheets 腳本來查看可用的整個站點的所有 CrUX 數據（Fabian Krumbholz 已經創建了一個更全面的工具來使這更容易！）並且它顯示了頁面的混合結果。 一些頁面通過了，而另一些頁面，尤其是較舊的頁面，則失敗了。
在這種情況下，CrUX 儀表板並沒有真正告訴我們太多我們不知道的事情：LCP 處於臨界狀態，不幸的是沒有下降趨勢：
深入研究其他統計數據（TTFB、First Paint、Online、DOMContentLoaded）並沒有給我們任何提示。 但是，移動使用量顯著增加：
這是移動應用總體趨勢的一部分嗎？ 儘管我們進行了改進，但這是否會影響移動 LCP？ 我們有問題，但沒有答案或解決方案。
我想看看的一件事是流量的全球分佈。 我們在 Google Analytics（分析）中註意到從印度到舊文章的大量流量——這可能是個問題嗎？
印度連接
國家級 CrUX 數據在 CrUX 儀表板中不可用，但在 BigQuery CrUX 數據集中可用，並且在 www.smashingmagazine.com 原始級別運行查詢顯示 LCP 值存在很大差異（SQL 包含在順便說一句，該鏈接的第二個選項卡，以防您想在自己的域上嘗試相同的操作）。 根據 Google Analytics 排名前 10 的國家/地區，我們有以下數據：
| 國家 | 移動 p75 LCP 值 | 流量百分比 |
|---|---|---|
| 美國 | 88.34% | 23% |
| 印度 | 74.48% | 16% |
| 英國 | 92.07% | 6% |
| 加拿大 | 93.75% | 4% |
| 德國 | 93.01% | 3% |
| 菲律賓 | 57.21% | 3% |
| 澳大利亞 | 85.88% | 3% |
| 法國 | 88.53% | 2% |
| 巴基斯坦 | 56.32% | 2% |
| 俄羅斯 | 77.27% | 2% |
印度的流量在 Smashing Magazine 中佔很大比例（16%），它沒有達到 LCP 在始發地級別的目標。 這可能是問題所在，當然值得進一步調查。 還有菲律賓和巴基斯坦的數據得分很差，但流量相對較小。
在這一點上，我對這裡可能發生的事情有所了解，並且有一個潛在的解決方案，因此讓 Smashing Magazine 安裝web-vitals庫來收集 RUM 數據並將其發布回 Google Analytics 進行分析。 經過幾天的收集，我們使用 Web Vitals Report 以我們以前無法看到的方式為我們提供了很多數據，特別是國家級細分：
它就在那裡。 分析中所有排名靠前的國家/地區的 LCP 得分都非常好，除了一個：印度。 Smashing Magazine 使用 Netlify，它是一個全球 CDN，它在孟買也有業務，所以它的性能應該和其他國家一樣，但有些國家只是比其他國家慢（稍後會詳細介紹）。
然而，印度的移動流量剛剛超出 2500 的限制，而且它只是訪問量第二大的國家。 當然，良好的美國分數應該足以抵消這一點嗎？ 好吧，上面兩張圖顯示了國家按流量排序。 但是 CrUX 分別計算移動和桌面流量（順便說一下平板電腦，但似乎沒有人關心這一點！）。 如果我們將流量過濾為僅移動流量會發生什麼？ 更進一步——只是移動 Chrome 流量（因為只有 Chrome 提供 CrUX，所以只有 Chrome 計入 CWV）？ 那麼我們得到一張更有趣的圖片：
| 國家 | 移動 p75 LCP 值 | 移動流量百分比 |
|---|---|---|
| 印度 | 74.48% | 31% |
| 美國 | 88.34% | 13% |
| 菲律賓 | 57.21% | 8% |
| 英國 | 92.07% | 4% |
| 加拿大 | 93.75% | 3% |
| 德國 | 93.01% | 3% |
| 尼日利亞 | 37.45% | 2% |
| 巴基斯坦 | 56.32% | 2% |
| 澳大利亞 | 85.88% | 2% |
| 印度尼西亞 | 75.34% | 2% |
在某種程度上，印度實際上是移動 Chrome 訪問量最高的訪問者——幾乎是第二高訪問者（美國）的三倍！ 成績不佳的菲律賓也躍升至第三位，而成績不佳的尼日利亞和巴基斯坦也進入了前 10 名。現在，LCP 在移動端的整體成績不佳開始變得有意義。
雖然在所謂的西方世界，手機已經取代台式機成為最流行的訪問互聯網的方式，但這裡仍然存在手機和台式機的合理混合——通常與我們許多人所在的工作時間有關桌面的前面。 下一個十億用戶可能不一樣，移動在這些國家扮演著更大的角色。 上述統計數據表明，對於像 Smashing Magazine 這樣的網站，您可能會認為在設計和開發時會從坐在桌面前的設計師和開發人員那裡獲得更多流量！
此外，由於CrUX 僅衡量 Chrome 用戶，這意味著擁有更多 iPhone 的國家（如美國）在 CrUX 和 Core Web Vitals 中代表的移動用戶比例要小得多，因此也放大了這些國家的影響。
核心網絡生命力是全球性的
Core Web Vitals 每個國家/地區沒有不同的閾值，您的網站是否被不同的國家/地區訪問也沒關係 - 它只是將所有 Chrome 用戶註冊為相同。 谷歌之前已經證實了這一點，所以 Smashing Magazine 不會因為美國的好分數而獲得排名提升，也不會為印度用戶獲得排名提升。 相反，所有用戶都進入了熔爐，如果這些頁面分組的分數沒有達到閾值，那麼所有用戶的排名信號都會受到影響。
不幸的是，這個世界並不是一個均勻的地方。 不同國家/地區的網絡性能確實存在很大差異，並且顯示出富國和窮國之間的明顯差異。 技術需要花錢，許多國家更專注於讓民眾上網，而不是不斷將基礎設施升級到最新最好的技術。
眾所周知，CrUX 中缺少其他瀏覽器（如 Firefox 或 iPhone），但我們一直認為它更多是衡量 Firefox 或 iPhone 性能的盲點。 這個例子表明影響要大得多，對於擁有全球流量的網站，它使結果顯著偏向 Chrome 用戶，這通常意味著貧窮的國家，這通常意味著更差的連接性。
核心 Web Vitals 是否應該按國家/地區劃分？
一方面，如果基礎設施變化如此之大，讓網站保持相同的標準似乎是不公平的。 為什麼 Smashing Magazine 應該受到懲罰或要求比只由西方世界的設計師和開發人員閱讀的類似網站更高的標準？ Smashing Magazine 是否應該阻止印度用戶讓 Core Web Vitals 開心（我想在這裡非常清楚，這從未在討論中出現過，所以請務必將此作為作者提出的觀點，而不是 Smashing 的花招！）。
另一方面，“放棄”一些國家，接受他們的緩慢風險，將他們中的許多人永久降級到較低的層次。Smashing Magazine 的普通印度讀者幾乎不是他們的錯，他們的基礎設施速度較慢，而且在很多方面，這些人應該得到更多的關注和努力，而不是更少！
這不僅僅是富國與窮國的辯論。 讓我們以一個針對法國讀者的法國網站為例，該網站由法國的廣告或銷售資助，並在該國擁有一個快速網站。 但是，如果該網站被許多法裔加拿大人閱讀，但由於該公司不使用全球 CDN 而遭受損失，那麼該公司是否應該在法國 Google 搜索中遭受損失，因為它對那些加拿大用戶來說沒有那麼快？ 該公司是否應該被 Core Web Vitals 的威脅“勒索贖金”並不得不投資於全球 CDN 以保持這些加拿大讀者，從而讓谷歌感到高興？
好吧，如果你的觀眾中有足夠多的人正在遭受痛苦，那麼這正是 Core Web Vital 的倡議應該浮出水面的。 儘管如此，這是一個有趣的道德困境，這是與SEO 排名提升相關的 Core Web Vitals 倡議的副作用：金錢總是會改變事情！
一種想法可能是保持限制不變，但按國家/地區衡量。 法語谷歌搜索網站可以提高法語用戶的排名（因為這些用戶通過了該網站的 CWV），而谷歌搜索加拿大可能不會（因為他們失敗了）。 即使目標相同，這也將為每個國家提供公平的競爭環境和衡量地點。
同樣，Smashing Magazine 在美國和他們通過的其他國家/地區可能排名很好，但與其他印度網站相比（他們處於“需要改進”部分的事實實際上可能仍然比那裡的許多網站更好，假設它們都受到相同的性能限制）。
可悲的是，我認為這會產生負面影響，一些國家再次被忽略，而網站只能證明對更有利可圖的國家進行網絡性能投資是合理的。 另外，正如這個例子已經說明的那樣，Core Web Vitals 已經足夠複雜了，而沒有為世界上每個國家/地區提供近 200 個額外的維度！
那麼如何解決呢？
所以我們現在終於知道為什麼 Smashing Magazine 很難通過 Core Web Vitals 了，但是如果有的話，可以做些什麼呢？ 託管服務提供商 (Netlify) 已經擁有 Mumbai CDN，因此應該為印度用戶提供快速訪問，那麼這是 Netlify 需要改進的問題嗎？ 我們已經盡可能地優化了網站，所以這只是他們必須忍受的東西嗎？ 好吧，不，我們現在回到之前的想法：進一步優化網絡字體。
我們可以採取根本不提供字體的極端選擇。 或者可能不向某些位置提供字體（儘管這會更複雜，因為 Smashing Magazine 網站的 SSG 特性）。 或者，我們可以根據某些標准在前端等待並加載字體，但這可能會在我們評估該標準時降低其他人的字體速度。 如果有一些易於使用的瀏覽器信號來指示我們何時應該採取這種激烈的行動。 類似於 SaveData 標頭的東西，正是為此而設計的！
SaveData And prefers-reduced-data
SaveData是用戶可以在他們真正想要的時候在瀏覽器中打開的設置……很好地保存數據。 這對於使用受限數據計劃的人、漫遊費用高昂的人或在基礎設施不如我們希望的那麼快的國家/地區的人很有用。
用戶可以在支持它的瀏覽器中打開此設置，然後網站可以使用此信息比平時更優化他們的網站。 可能會返回質量較低的圖像（或完全關閉圖像！），或者不使用字體。 此設置的最佳之處在於您是根據用戶的請求採取行動，而不是隨意為他們做出決定（許多印度用戶可能訪問速度很快，並且不想要網站的受限版本！）。
保存數據信息有兩種（即將成為三種！）方式：
- 每個 HTTP 請求都會發送一個
SaveData標頭。 這允許動態後端更改返回的 HTML。 -
NetworkInformation.saveDataJavaScript API。 這允許前端腳本對此進行檢查並採取相應措施。 - 即將推出的
prefers-reduced-data媒體查詢，允許 CSS 根據此設置設置不同的選項。 這在 Chrome 中的標誌後面可用，但在完成標準化時默認情況下尚未啟用。
所以問題是，許多 Smashing Magazine 讀者（尤其是那些在 Core Web Vitals 苦苦掙扎的國家的讀者）是否使用此選項，因此我們可以使用此選項為他們提供更快的網站嗎？ 好吧，當我們添加上面提到的web-vitals腳本時，我們還決定測量它以及有效連接類型。 你可以在這裡看到完整的腳本。 在允許它收集一段時間後，我們可以在一個簡單的 /Google Analytics 儀表板中顯示結果，以及 Chrome 瀏覽器版本：
因此，好消息是很大一部分印度移動用戶（約三分之二）確實設置了此設置。 ECT 的用處不大，大多數顯示為 4g。 我之前曾說過，這個 API 變得越來越沒用，因為大多數用戶都屬於這個 4g 設置。 此外，有效地將此值用於初始負載會帶來很多問題。
更多好消息，因為大多數用戶似乎都在使用最新的 Chrome，因此當它完全可用時，將受益於新功能，例如prefers-reduced-data媒體查詢。
Smashing 團隊的 Ilya 將 JavaScript API 版本應用到他們的字體加載器腳本中，因此不會為這些用戶加載額外的字體。 The Smashing folks also applied the prefers-reduce-data media query to their CSS so fallback fonts are used rather than custom web fonts for the initial render, but this will not be taking effect for most users until that setting moves out of the experimental stage.
I Love That Graph In Google Search Console
And did it work? Well, we'll let Google Search Console tell that store as it showed us the good news a couple of weeks later:
Additionally, since this was introduced in mid-November, the original level LCP score has steadily ticked downwards:
There's still not nearly enough headroom to make me comfortable, but I'm hopeful that this will be enough for now, and will only improve when the prefers-reduced-data media query comes into play — hopefully soon.
Of course, a surge in traffic from mobile users with bad connectivity could easily be enough to flip the site back into the amber category, which is why you want that headroom, so I'm sure the Smashing team will be keeping a close eye on their Google Search Console graph for a bit longer, but I feel we've made the best efforts basis to improve the experience of users so I am hopeful it will be enough.
Impact Of The User Experience Ranking Factor
The User Experience ranking factor is supposed to be a small differentiator at the moment, and maybe we worried too much about a small issue that is, in many ways outside of our control? If Smashing Magazine is borderline, and the impact is small, then maybe the team should worry about other issues instead of obsessing over this one? But I can understand that and, as I said, Smashing Magazine are knowledgeable in performance and so understand why they wanted to solve — or at the very least understand! — this issue.
So, was there any impact? Interestingly we did see a large uptick in search impression in the last week at the same time as it flipped to green:
It's since reverted back to normal, so this may have been an unrelated blip but interesting nonetheless!
結論
So, an interesting case study with a few important points to take away:
- When RUM (including CrUX or Google Search Console) tells you there's a problem, there probably is! It's all too easy to try to compare your experiences and then blame the metric.
- Implementing your own RUM solution gives you access to much more valuable data than the high-level data CrUX is intended to provide, which can help you drill down into issues, plus also give you potentially more information about the devices your site visitors are using to visit your site.
- Core Web Vitals are global, and that causes some interesting challenges for global sites like Smashing Magazine. This can make it difficult to understand CrUX numbers unless you have a RUM solution and perhaps Google Search Console or CrUX could help surface this information more?
- Chrome usage also varies throughout the world, and on mobile is biased towards poorer countries where more expensive iPhones are less prevalent.
- Core Web Vitals are getting much better at measuring User Experience. But that doesn't mean every user has to get the same user experience — especially if they are telling you (through things like the Save Data option) that they would actually prefer a different experience.
I hope that this case study helps others in a similar situation, who are struggling to understand their Core Web Vitals. And I hope you can use the information here to make the experience better for your website visitors.
Happy optimizing!
Note: It should be noted that Vitaly, Ilya and others at the Smashing team did all the work here, and a lot more performance improvements were not covered in the above article. I just answered a few queries for them on this specific problem over the last 6 months and then suggested this article might make an interesting case study for other readers to learn from.