Google Lighthouse：增強使用者體驗和搜尋引擎可見性的道德駭客手冊 (2024)

Google Lighthouse 是遊戲化和鼓勵開發人員增強網頁效能最有效的方法之一。利用 Lighthouse，我們能夠根據整體有效性、可訪問性、SEO 和 Google 的首選「最佳實踐」來評估網頁 - 只需按一下按鈕即可。

這些檢查可用於評估前端框架的預設效能或展示透過精心重組實現的效率改進。在社交媒體上展示您無可挑剔的燈塔評分無疑是令人欣慰的。這是一項值得尊敬的成就，值得舉辦一場充滿活力的慶祝活動。

Lighthouse 激發了像我們這樣的開發人員之間關於效能的對話，這一簡單事實就是一個勝利。然而，儘管不考慮問題的重要性，網路效能卻複雜得多。在這篇文章中，我們將探索 Google Lighthouse 效能評估背後的方法，並利用這些知識，努力操縱這些結果以對我們有利， 一切都本著享受與探索的精神 – 最終，Lighthouse 充當診斷效能問題的可靠但粗略的指南。讓我們來玩一玩，看看我們能在多大程度上比 Lighthouse 更聰明，從而提供超出我們合理接收範圍的改進分數。

但在此之前，讓我們先深入研究一下數據。

現場數據至關重要

本地效能評估可以為您網站的效能是否朝著正面的方向發展提供有價值的見解，但它們並不能提供完整的現實情況。互聯網是一個無限多樣性的領域，總的來說，我們可能已經忘記了訪問網站的個人使用的無數設備、互聯網速度、屏幕尺寸、瀏覽器和瀏覽器版本——所有這些都會影響頁面性能和用戶交互。

與使用高精度從單一樣本獲得的實驗室數據相比，Sentry 等應用程式效能監控工具從在其設備上存取您的網站的真實用戶收集大量的現場數據，可以更準確地評估您的網站效能。 Philip Walton 在 2021 年透露的 HTTP Archive 數據強調，“在 Lighthouse 上獲得 100 分的所有頁面中，近一半未達到建議的 Core Web Vitals 閾值。”

Web 效能超出了單獨的核心 Web 重要指標或 Lighthouse 效能評級。我們的討論超越了我們正在使用的基本資料類型。

Web 效能不僅僅包含統計數據

速度 通常成為網路效能討論的主要焦點—頁面載入的速度。雖然這是一個需要考慮的重要因素，但我們必須承認速度在很大程度上受到業務目標和銷售目標的影響。 Google 在 2018 年發布的一份報告表明，一旦頁面加載時間超過 3 秒，跳出率就會上升 32%，而當加載時間超過 10 秒時，跳出率就會飆升至 123%。因此，有必要加速頁面加載以提高銷售轉換率。降低跳出率的核心目的是加快頁面速度 載入中.

但「載入速度更快」到底意味著什麼？有一個閾值，超過該閾值我們實際上就無法加快網頁的載入速度。人類以及連接他們的伺服器分散在全球範圍內，當代互聯網基礎設施在任何給定時間只能傳輸有限數量的數據。

問題的關鍵在於頁面載入並不代表一個單一的時刻。在一篇題為「什麼是速度？」的文章中Google 闡明頁面載入事件是：

任何單一指標都無法完全概括這種遭遇。載入過程中的許多實例可能會影響使用者是否認為其“快速”，並且僅關注其中一個實例，您可能會忽略在剩餘時間跨度內發生的負面事件。

這裡的關鍵術語是 經驗。真正的網路效能超越 指標 和 速度，更多關注 我們如何感知 使用者的頁面載入和頁面可操作性。這毫不費力地引導我們討論 Google Lighthouse 如何計算效能評級。 （顯然，這並不像人們想像的那樣純粹是速度。）

Google Lighthouse 效能分數是如何決定的？

Google Lighthouse 效能分數的計算涉及從核心 Web 重要指標（例如，首次內容繪製 (FCP)、最大內容繪製 (LCP)、累積佈局偏移 (CLS)）和其他速度相關指標得出的分數的加權合併（例如，速度指數（SI）和總阻塞時間（TBT）） 整個頁面載入時間軸都很明顯.

以下是這些指標在總分中的權重細分：

每個指標的權重分配讓我們深入了解 Google 如何優先考慮有助於卓越使用者體驗的各種元素：

1. 網頁應該及時響應使用者輸入

主要加權指標是 總阻塞時間 (TBT)，一個檢查之後持續時間的儀表 首次內容繪製 (FCP) 識別主線程可能長時間受阻的情況，從而阻礙對使用者命令的快速回應。只要主執行緒上發生 JavaScript 任務超過 50 毫秒，主執行緒就會被視為「阻塞」。減少 TBT 可確保網站對有形的使用者操作（例如鍵盤輸入、滑鼠點擊等）做出回應。

2. 網頁應該顯示相關內容，且沒有意外的視覺波動

隨後的加權 Lighthouse 指標包括 最大內容塗料 (LCP) 和 累積佈局偏移 (CLS)。 LCP 表示載入過程中頁面主要內容已載入的時刻 想必 已加載，因此 有價值的.

在假定主要內容載入完成後，保持視覺一致性對於確保無縫用戶參與和防止意外視覺中斷至關重要。理想的 LCP 測量是低於 2.5 秒的任何持續時間（考慮到我們不斷努力優化我們的網站，這明顯大於我們的預期） 盡可能快).

3. 在網頁上載入內容

這 首次內容繪製 (FCP) 指標表示頁面載入過程中使用者可以辨別螢幕上內容的初始時刻，而 速度指數 (SI) 衡量載入過程中內容視覺呈現的速度，直到頁面達到「完成」狀態。

您的頁面評估是基於使用 HTTP Archive 中的效能統計資料對實際網站進行的速度測量。值得稱讚的 FCP 指標低於 1.8 秒，值得稱讚的 SI 指標低於 3.4 秒。這些基準高於人們在考慮速度時的預期。

優先考慮可用性而非純粹速度

Google Lighthouse對效能的評估無疑強調的是可用性而不是純粹的速度。您的SI 和FCP 可能會表現出卓越的速度，但如果您的LCP 遇到渲染延遲，由於複雜的圖像或外部內容導致視覺變化而導致CLS，那麼與頁面稍微滯後的情況相比，您的整體性能評估將較差顯示 FCP，但避免引起任何 CLS。從本質上講，如果 JavaScript 透過阻塞主執行緒超過 50 毫秒來阻礙頁面的回應能力，那麼效能評估將比頁面稍微延遲顯示 FCP 受到更不利的影響。

為了更好地理解每個指標的權重如何影響最終的效能評估，您可以在 Lighthouse 評分計算器上嘗試滑動控制。這是一個簡單的表格，說明了偏重於單一指標權重對整體效能評估的影響，證明了頁面可用性和回應能力比純粹的速度優先。

Google Lighthouse 整體效能分數是透過根據其在 Lighthouse 評分分佈中的位置將每個原始指標值轉換為 0 到 100 範圍內的分數來計算的，該分數源自 HTTP Archive 中真實網站效能資料的效能指標。從這些數學密集型數據中得出兩個重要結論：

1. 您的 Lighthouse 效能分數是根據真實的網站效能數據進行的，而不是孤立的。
2. 鑑於在評分中使用對數正態分佈，各個指標值與總分之間的相關性是非線性的，這表明雖然可以對錶現不佳的分數進行顯著增強，但提高已經很高的分數變得更具挑戰性。

進一步探索如何確定指標分數，並在developer.chrome.com 上以對數常態分佈曲線的圖形表示形式表示。

有可能智勝Google燈塔嗎？

我很欣賞 Google 在討論 Web 效能時對可用性的強調，而不是純粹的速度。它鼓勵開發人員優先考慮創造真實的體驗，而不是追求任意的指標。儘管如此，我一直在思考，在 2024 年的今天，是否可以欺騙 Google Lighthouse，讓其將設計糟糕且無用的頁面視為優秀頁面。

我穿上實驗室外套並戴上科學護目鏡開始調查。進行了所有測試：

• 使用 Chromium Lighthouse 插件，
• 在使用 Arc 瀏覽器的隱身視窗中，
• 選擇“導航”和“移動”配置（除非另有說明），
• 由我在實驗室環境中完成（即沒有真實世界數據）。

儘管我的實驗的受控環境與本文開頭的建議相矛盾，但該實驗被證明是一項有趣的嘗試。我希望您了解到 Lighthouse 分數只是複雜的網路效能難題中的一個要素（儘管是次要的）。此外，由於缺乏真實世界的數據，這些發現的相關性可能會受到質疑。

操縱 FCP 和 LCP 分數的策略

TL;DR：在加載時展示最低限度的 LCP 合格內容，以提高 FCP 和 LCP 分數，直到 Lighthouse 評估完成。

FCP 表示頁面載入過程中的初始階段，其中使用者可以感知螢幕上的任何內容，而 LCP 表示載入時間軸中主頁面內容（例如，最大的文字或圖像元素）可能已載入的時間點。快速的 LCP 有助於增強使用者對頁面的信心 好處。 「可能」和「有益」是這裡要記住的關鍵術語。

識別 LCP 元素

Lighthouse for LCP 考慮的網頁上的元素類別有：

• <img> 標籤
• <image> 內的標籤 <svg> 標籤
• 標籤
• 具有透過載入的背景圖像的元素 網址（） 函數（不包括 CSS 漸層）
• 包含文字節點或行內文字元素的區塊級元素

隨後的元素是 省略 由於假定它們缺乏有用內容，因此不考慮 LCP：

• 零透明度的元素（使用者不可見），
• 遮蓋整個視窗的元素（可能是背景元素），以及
• 佔位符影像或具有邊緣熵的低資訊內容影像（例如，純色影像）。

然而，在這種情況下，判斷圖像或文字元素是否有益的概念是非常主觀的，並且通常超出了機器演算法可以可靠確定的範圍。例如，我建立的頁面僅包含 <h1> 標籤，一旦過了 10 秒，JavaScript 就會將更多描述性內容插入 DOM 中，然後隱藏 <h1> 標籤。

根據實驗，Lighthouse 將標題標籤視為最大的內容繪製 (LCP) 組件。到達此階段後，頁面的載入時間軸完成，但主要內容尚未完全載入。儘管如此，Lighthouse 仍假設內容很有可能在 10 秒視窗內載入。令人驚訝的是，即使標題被換成了句點這樣的簡單標點符號，Lighthouse 仍然給出了 100 分的滿分，這更不值錢了。

該試驗表明，當透過客戶端 JavaScript 載入頁面內容時，最好不要顯示骨架載入器畫面。這是因為顯示這樣的畫面需要在頁面上載入其他元素。透過認識到此過程需要一些時間，並透過將網路請求從主執行緒傳輸到Web Worker 以避免影響總阻塞時間，我們可以使用包含最小可行LCP 元件的通用“啟動畫面”，以實現更好的第一效果內容豐富的繪畫（FCP）評分。這種方法給 Lighthouse 的印像是該頁面的使用者友善性比實際上要快得多。

所需要的只是包含代表 FCP 的合法 LCP 組件。雖然我不建議在 2024 年透過客戶端 JavaScript 載入主頁內容（傾向於從內容交付網路提供靜態 HTML 或在伺服器上建立盡可能多的內容），但也不建議對無論Lighthouse 效能得分如何，都可以獲得積極的用戶體驗。此外，此方法可能不利於搜尋引擎索引，因為當 DOM 中不存在主要內容時，搜尋機器人無法找到主要內容。

我用各種隨機圖像冒充 LCP 進行了類似的試驗，以進一步削弱該頁面的實用性。然而，考慮到使用較小的檔案大小- 透過第三方圖像API 進一步減小並轉換為“下一代”圖像格式以提高頁面加載速度- Lighthouse 將這些圖像視為“佔位符圖像”或“低”圖像熵」。因此，這些圖像沒有被識別為 LCP 組件，這是一個理想的結果，使 LCP 不易受到操縱。

在隱身模式下查看使用 Chromium DevTools 的示範頁面，親眼見證結果。

然而，這種策略在許多其他場景中可能不那麼有效。例如，Discord 在瀏覽器中對其應用程式進行硬刷新時採用了「閃屏」方法，導致效能分數令人失望，為 29 分。

與我的 DOM 注入演示相反，LCP 組件被識別為隱藏在啟動屏幕後面的一些內容，而不是啟動屏幕本身內的元素，這可能是由於我測試的聚焦文本通道中存在一個或多個大圖像。有人可能會說，Lighthouse 分數對於僅在身份驗證後才能訪問的應用程式來說意義不大，因為它們不需要由搜尋引擎編制索引。

在應用程式提供使用者生成內容的許多其他情況下，完全控制 LCP 元件可能具有挑戰性，尤其是在圖像方面。

例如，如果您確實可以控制網頁上所有圖像的大小，則可以利用有趣的駭客或「最佳化」（帶引號）來潛在地操縱系統。 RentPath 在 2021 年證明了這一點，其中開發人員能夠透過放大網頁上的影像縮圖將 Lighthouse 效能得分提高 17 分。他們設法影響 Lighthouse 將 LCP 元件視為較大的縮圖之一，而不是頁面上的 Google 地圖圖塊，後者透過 JavaScript 載入的時間要長得多。

關鍵要點是，如果您留意 LCP 元素並對其進行控制，無論是透過類似於 RentPath 的 hack 或您自己的設計之一，還是透過真正的增強，獲得更高的 Lighthouse 效能分數都是可行的。雖然我在本文中將閃屏方法描述為一種駭客攻擊，但這並不意味著這種類型的體驗不能提供有意義且令人愉悅的使用者體驗。效能和使用者體驗都圍繞著理解載入過程和意圖。

操縱 CLS 分數的策略

快速摘要：延遲載入導致佈局變更的內容，直到 Lighthouse 測試可能完成（假設它有足夠的資料）。使用變換的 CSS 動畫通常不會引發 CLS，除非與向 DOM 添加新元素結合使用。

CLS 以小數制來衡量，低於 0.1 的分數視為良好，高於 0.25 的分數視為較差。 Lighthouse 根據使用者會話期間發生的最重要的一系列意外佈局變化來計算 CLS，同時考慮視口大小和兩個渲染幀之間不穩定元素的移動。雖然佈局變化的個別實例可能無關緊要，但一系列接二連三的變化會對您的分數產生不利影響。

如果您意識到您的頁面在加載時觸發了煩人的佈局變化，您可以將它們推遲到頁面加載完成後，欺騙 Lighthouse 假設不存在 CLS 問題。在個人範例中，示範頁面傳回 0.143 的 CLS 分數，即使新新增的文字元素透過 JavaScript 立即導致原始內容向上移動。透過使用 a 暫停向 DOM 新增節點的腳本隨機五秒鐘 設定超時() 函數中，Lighthouse 無法偵測到 CLS 發生。

另一個演示頁面獲得了 100 分的完美性能分數，儘管其實用性和用戶友好性可能不如前一個頁面，因為附加元素是在沒有任何用戶互動的情況下任意出現的。

儘管推遲頁面載入測試的佈局轉換是可行的，但這種解決方法對於現場數據或長期用戶體驗並不有效，而這些是更關鍵的因素，如前面所討論的。在使用 Lighthouse 在延遲佈局轉換的頁面上進行「時間跨度」測試時，它準確地報告了 0.186 左右的不令人滿意的 CLS 分數。

如果您有意創建類似於演示的混亂用戶體驗，則可以利用 CSS 動畫和轉換來策略性地將內容帶入頁面視圖。在Google的CLS指南中，它提到“內容從一個位置平滑過渡到另一個位置可以增強用戶的理解並引導他們完成狀態變化”，再次強調了上下文用戶體驗的重要性。

在下一個演示頁面上，我使用 CSS 轉換 規模（） 為文字元素設定動畫 0 到 1 並將它們重新放置在頁面上。這些轉換不會觸發 CLS，因為當文件準備好時，文字節點已經存在於 DOM 中。我在實驗過程中註意到，如果在使用 JavaScript 載入頁面後將文字元素動態插入 DOM 中，然後進行動畫處理，Lighthouse 將偵測 CLS 並進行相應的評估。

您無法操縱速度指數分數

速度指數分數是根據頁面渲染時的視覺進度計算的。在頁面載入序列早期，內容載入得越快，結果就越好。

人們可以嘗試採用某些策略來欺騙速度指數，使其感知較慢的載入序列。相反，也沒有可行的方法來人為地加快內容的載入。提高速度指數分數的唯一方法是優化您的網頁，以盡快加載盡可能多的內容。雖然這種方法在當前的網路場景中可能並不完全實用（主要是因為它會危及設計師的角色），但您可以完全致力於透過以下方式降低速度指數：

• 直接從 CDN 提供靜態 HTML 網頁，
• 省略頁面中的圖像，
• 減少或刪除 CSS，以及
• 停止載入 JavaScript 或任何外部依賴項。

您也無法真正操縱 TBT 分數

TBT 測量 FCP 之後主線程被 JavaScript 活動充分阻礙以阻礙對使用者互動的回應的總持續時間。理想的 TBT 分數低於 200 毫秒。

大量使用 JavaScript 的 Web 應用程式（如單頁應用程式）在頁面載入期間（而不是在傳輸渲染的 HTML 之前在伺服器上）執行複雜的狀態計算和 DOM 調整，往往會獲得較差的 TBT 分數。在這種情況下，可以想像，人們可以透過推遲所有 JavaScript 直到 Lighthouse 評估結束來改變他們的 TBT 分數。儘管如此，仍需要提供佔位符內容或載入畫面以滿足 FCP 和 LCP 要求並通知用戶即將進行的活動。此外，還需要努力瀏覽正在使用的前端框架。 （避免載入佔位符頁面，該頁面最終會在頁面載入序列中的某個不確定時刻載入不同的 React 應用程式！）

一個有趣的方面是，雖然高級 JavaScript 功能在客戶端活動中仍然很普遍，但當前 Web 環境中的創新正在促進集體努力，以減少 TBT 分數低於標準的情況。許多前端框架與現代託管服務相結合，具有渲染頁面並按需執行複雜邏輯的能力，而無需任何客戶端 JavaScript。雖然從客戶端消除 JavaScript 並不是目標，但減少其部署的可能性有很多種，從而降低頁面載入期間主執行緒上過多運算任務的風險。

總結：燈塔仍然只是一個大致的指南

Google Lighthouse 無法找出特定網站中的每個缺陷。儘管 Lighthouse 的效能指標在對使用者操作的回應能力方面優先考慮頁面可用性，但它並沒有全面識別 2024 年的所有可用性或可訪問性問題。

2019 年，曼努埃爾·馬圖佐維奇 (Manuel Matuzović) 進行了一項實驗，故意製作了一個設計糟糕、但 Lighthouse 給予正面評價的網頁。我推測Lighthouse的效能在五年後會有所提升；然而，事實並非如此。

在最後的示範頁面中，CSS 和 JavaScript 會使輸入事件失效，使頁面無法回應使用者操作。五秒後，JavaScript 會更改行為，允許與按鈕互動。令人驚訝的是，該頁面在效能和可訪問性方面都保持了滿分。

僅依靠 Lighthouse 來取代可用性評估和邏輯推理是不可取的。

其他異想天開的利用

在生活的各個方面，都存在著操縱系統的策略。以下介紹了一些經過驗證且有保證的策略，可以人為地提高您的 Lighthouse 效能分數，超越所有其他策略：

• 僅在高速和頂級硬體上進行 Lighthouse 評估。
• 確保您的網路連線處於最佳狀態；如果需要的話搬遷。
• 僅使用實驗室數據，不合併使用上述高速硬體和出色的互聯網連接收集的實際使用數據。
• 利用本文中詳細介紹的所有巧妙技巧，在不同的實驗室條件下重複評估，直到達到給您的熟人、同事和網路陌生人留下深刻印象的預期結果。

重要的: 若要深入了解網路效能並提升網站優化技能，請考慮採用 Sentry 等應用程式監控工具。將 Lighthouse 視為初步指標，將 Sentry 視為最終的生產資料擷取、高效的網路生命體設備。

最後，這裡是用於教育目的的完整演示網站的連結。