瀏覽器是否可以最佳化第三方資源載入作業？

Addy Osmani

第三方資源 (例如嵌入內容和指令碼) 目前在網路上廣泛使用。這些解決方案可立即套用，用於嵌入社群媒體、影片、分析、即時通訊、廣告、A/B 版本測試、個人化等內容。第三方嵌入功能是現代網站的必要元素，可讓網站擁有者專注於核心業務，同時將標準但重要的功能外包給外部供應商。

如果網頁上的第一方和第三方都能和諧運作，網頁就能提供良好的使用者體驗。不過，這項工作需要工程和業務團隊共同投入大量心力，但往往被忽略，導致網頁效能不佳，並對以使用者為主的指標 (例如 Core Web Vitals) 造成負面影響。這對雙方都沒有好處，也會錯失商機。我們可以做得更好嗎？

我們對未來的網路有願景，第三方指令碼和資源可提供預期的商業價值，同時盡可能減少對瀏覽器中使用這些資源的網站效能或使用者體驗的回歸。這樣一來，使用者就能享有更快的網頁載入體驗。

過去一年，我們考慮、討論並嘗試了許多可能的做法，希望能保護使用者免受第三方指令碼的負面影響，同時不影響這些指令碼對網站擁有者的商業價值。

我們希望透過這篇文章，分享一些實驗的相關資訊。我們希望這只是一個開始，讓使用者代理程式、企業和第三方供應商之間的資訊公開透明，並為更快速的網路鋪路。

深入瞭解第三方

第三方是指由網站外部供應商提供的資源。這些廣告並非由網站擁有者直接控管，而是經過他們核准後才會顯示。第三方資源包括：

  • 代管在與主要網站來源不同的共用和公開來源。
  • 並非由個別網站擁有者撰寫或影響。
  • 廣泛用於各種網站。

第三方服務供應商可協助您達成各種業務目標，例如透過廣告賺取收益，或是提供更優質的行銷機會 (嵌入社群媒體)。常見的第三方類別包括：

來源：第三方 (依類別劃分)。

類別 定義
廣告 用於放送廣告或評估廣告成效的程式碼。
影片 可啟用影片播放器和串流功能的指令碼。
代管程式庫 混合式：公開代管的開放原始碼程式庫。
內容 內容供應商提供的指令碼，或發布商專屬的聯盟追蹤功能。
客戶成功 提供即時通訊和聯絡解決方案的客戶服務/行銷服務供應商提供的腳本。
託管 來自網站代管平台的指令碼。
行銷 用於新增彈出式視窗、電子報和其他內容的行銷工具指令碼。
社群媒體 啟用社群功能的腳本。
代碼管理工具 載入許多其他指令碼並啟動許多工作指令碼。
數據分析 用於評估或追蹤使用者及其動作的腳本。
Cookie 同意聲明平台 讓網站以明確透明的方式取得使用者同意聲明 (GDPR、ePR、CCPA) 的程式碼。
公用程式 開發人員公用程式 (API 用戶端、網站監控、詐欺偵測等)。
其他 透過共用來源提交的其他指令碼，且沒有明確的類別或歸因。

這些第三方指令碼和程式庫可讓網頁開發人員利用經過測試的解決方案來實作標準功能，而非重新發明輪子。因此，第三方供應商可縮短開發時間，協助企業更快推出或升級產品。因此，在電腦和行動裝置上，超過 94% 的網站都會使用第三方服務。

第三方對成效有何影響？

理想情況下，第三方開發人員應是提供特定功能的專家。大多數熱門的第三方服務都經過多次迭代，因此程式碼會根據各自的商業目標進行最佳化，但不一定會納入使用這些程式碼的網頁成效。不過，我們也知道，即使是經過最佳化調整的第三方程式也會影響成效。造成這項影響的主要原因如下：

  1. 大小和指令碼執行成本：第三方通常會在網頁中加入 <script> 或 <iframe> 元素，以提供重要的功能。這些元素接著會擷取大小較大且下載及執行時間較長的指令碼和資源。太多 JavaScript 會讓主執行緒持續忙碌，阻斷轉譯作業，並延遲使用者互動。在分析的網站中，超過 50% 的網站都發現，部分主要第三方會封鎖主執行緒，時間從 42 毫秒到 1.6 秒不等。封鎖的主執行緒會導致總封鎖時間 (TBT) 偏高，而這項指標會影響網站的效能分數。此外，這也會延遲對使用者互動的回應，並降低用於評估網站回應速度的 Interaction to Next Paint (INP) 指標。因此，指令碼執行成本會對效能造成重大影響。

  2. 數量：網站在行動版網站和網站上平均使用約 21 個不同的第三方。第三方代碼通常是透過代碼管理工具新增，而技術/開發團隊並未直接控管這些工具。其他團隊可能會在沒有審查程序的情況下新增非必要的標籤，而且永遠不會移除。這些因素可能會大幅影響使用者體驗、網頁重量或 CPU 使用率。建立治理程序可解決這類情況，並讓開發人員稽核每個供應商的影響。如果開發人員能針對提供特定功能的所有第三方提供現成資料，並比較其成效影響、優點和取捨，將有助於做出比較。團隊面臨的另一個挑戰是，許多網站的第三方代碼只會在實際工作環境中執行，不會在開發環境中執行，因此開發人員更難測試這些代碼。

  3. 網路：由於第三方託管在不同的來源上，瀏覽器必須建立更多連線，才能從這些來源下載內容。不同的連線無法根據優先順序協調下載作業，導致網路爭用。如果沒有考量適當的最佳化，這可能會進一步延遲網頁載入時間。

  4. 排序：第三方可以封鎖主執行緒，並與頻寬競爭更重要的資源。不過，在某些情況下，第三方資源是轉譯網頁時所需的重要資源。如果網站使用多個第三方資源，就必須為第一方和第三方資源建立最佳順序。網路開發人員應瞭解可用於最佳化排序的不同選項。

因此，第三方可能會影響 Core Web Vitals 的任何或所有元件。大多數第三方會對最大內容繪製 (LCP) 和首次輸入延遲時間 (FID) 造成負面影響。在行動版網站中，10% 的網站在嵌入 YouTube 時會阻斷主執行緒 4.5 秒，而 50% 的網站則會阻斷 1.6 秒以上。試想，如果使用者在連線速度較慢的情況下，遇到有 20 個這類指令碼的網頁，一定會感到很不耐煩。以下圖表取自 thirdpartyweb.today，顯示目前對成效影響最大的第三方。

第三方網站圖表

「在約 400 萬個熱門網站中，約 2, 700 個來源佔所有指令碼執行時間的約 57%，其中前 50 個實體就佔了約 47%。」- third-party-web

網頁必須在合理時間內快速轉譯，並且在合理時間內可供互動，才能提供良好的使用者體驗，這也是 Core Web Vitals 的評估標準。良好的使用者體驗通常能為網站帶來良好的業務，也能為使用第三方服務的客戶帶來良好的業務。透過攜手合作，減少第三方影響，可讓整個供應鏈中的所有人皆能受惠。

我們瞭解 Google 提供多種常用的第三方指令碼，包括 Google 代碼管理工具、YouTube 嵌入功能和 ReCaptcha 等。我們瞭解許多 Google 指令碼可能會對 Core Web Vitals 造成輕微的效能影響，並且致力於探索可行的改善方式。

Chrome 可以提供哪些協助？

第三方資源效能不佳，一直是開發人員面臨的挑戰，因此需要在基礎生態系統中進行逐步變更。Chrome 希望探索這個領域，以便達成以下目標：

  1. 找出更佳的做法，在網路上載入第三方資源，同時不影響使用者體驗或業務成效。

    我們瞭解，如果不與合作夥伴、商家、第三方和開發人員合作，就無法在這個領域取得長足進展。我們希望建立開放的討論空間，透過公開說明和規格討論可能性，交換想法。開發人員將有時間提供意見回饋，並測試這些提案的影響。

  2. 讓第三方指令碼使用者能更準確地歸因工具和實地成本，並在使用過程中提供清晰的使用路徑，以及更優質的誘因，確保預設最佳化。

    我們希望強化所有層級 (例如使用者代理程式、架構和第三方指令碼)，以減少第三方對效能造成的影響。我們也打算提供充足的洞察資料，協助網站擁有者採用各個嵌入指令碼的最佳做法，包括適用情況下的更快速替代方案。

建議做法

我們建議採用三管齊下的做法來達成這些成效...

  1. **透過 RUM 和 Chrome 開發人員工具，讓開發人員更深入歸因每項第三方影響因素。**

    RUM 是指透過網站效能監控 API 取得的實際使用者指標資料 (也稱為「現場資料」)。Chrome 的開發人員工具包括 Lighthouse、Chrome 開發人員工具和 Chrome 使用者體驗報告。我們建議強化現有的 API 和工具，讓網站開發人員瞭解每個第三方工具對每個網頁的影響。這些工具也會教導使用者如何採取行動來減輕影響 (例如延後或使用門面)，並探索其他潛在解決方案 (其他第三方或自行解決) 的取捨。針對網路效能監控 API，我們正在研究如何在不損害使用者隱私權和安全性的前提下，擴大跨來源資源的涵蓋範圍。

  2. **為商家提供明確的路徑，以便有效載入第三方資源。**

    我們希望提出新的標準，鼓勵瀏覽器在提供更優質的載入體驗時，更聰明地在第一方和第三方資源的載入方式之間取得平衡。稍後，我們會強調其中一些建議，例如預設以延遲載入方式嵌入第三方內容，或是針對對使用者來說不那麼重要的初始內容，為第三方資源設定不同的資源優先順序。這些只是我們在這個領域評估的想法中的一小部分，我們很樂意與網站效能專家和更廣泛的社群合作，共同完成這項工作。

    我們也想在 JavaScript 架構和內容管理系統 (CMS) 中解決這類問題 (在適當情況下)。Aurora 和 WordPress Performance Team 等專案都說明瞭內建預設值的重要性，可解決已知的載入問題。架構和 CMS 內建的預設值，可引導商家走上正確的道路。這些資訊也能為使用者代理程式 (例如 Chrome) 提供提示，讓使用者代理程式套用推論法，以便最佳化網頁載入和 CWV。這類提示可協助使用者代理程式決定在網頁生命週期中，應何時載入特定第三方，以及如何載入。(例如，Next.js 指令碼元件內建預設值，可在網頁可供互動後載入第三方指令碼)。

  3. **透過更透明的做法，鼓勵第三方降低成效影響。**

    第三方開發人員目前缺乏必要的資訊，無法瞭解自己的指令碼對網站整體的影響。我們打算解決這個問題，並為這些供應商提供工具，以便分析其影響力，並與市場上提供相同價值的其他產品進行比較。我們也希望協助他們運用資料診斷影響的原因，以便在問題發生前採取因應措施。我們必須呼叫所有第三方 (包括 Google 撰寫的第三方)，才能成功。

挑戰

這類規模的努力不免有難題。我們必須考量的幾項重要挑戰如下：

  • 第三方是廣告、數據分析、代碼管理、公用程式等多項跨領域問題的共同因素。每個領域都需要考量一組獨特的條件和取捨。例如：
    • 您應在收益和使用者體驗之間取得平衡，才能做出最佳化廣告載入的決定。如果太早，就會封鎖有價值的內容；如果太晚，使用者就會錯過這些內容。
    • Analytics 指令碼會增加網頁重量，但可為商家提供有關使用者動作的重要資料。

我們希望與各類第三方合作，掌握相關細節、解決取捨問題，並建立適用於所有人的獎勵機制。我們瞭解，為了讓策略有效，我們必須與各個領域的實體個別合作。包括 Google 代碼管理工具、Google Ads 和 YouTube 等內部合作夥伴。

  1. 我們希望為網站開發人員和第三方開發人員提供更深入的歸因資訊。這項工作需要謹慎進行，我們必須找出最能評估成效的資料，並精確地歸因，提供正確的後續行動。歸根究柢，第三方計算方式應公開透明，讓所有人都能瞭解其競爭力。

  2. 我們建議強化 Chrome，讓它能夠套用最佳化功能，以便在優先載入第一方資源和第三方資源之間取得平衡。這項有價值的變更會成為所有瀏覽器的標準，但需要一段時間。舉例來說，<img> 和 <iframe> 元素的 loading 屬性自 2019 年起已在 Chrome/Edge 中提供，但在 Safari 中則要到 2022 年才推出。在功能標準化之前，第三方資源的使用者必須確保已針對其他瀏覽器進行最佳化。我們會在相關指南中強調這一點。

  3. 為了執行這個專案，我們必須與合作夥伴和開發人員互動，不僅要瞭解特定需求，還要大規模測試實驗性解決方案、提供意見回饋，並視需要進行調整和改進。變更必須經過規劃，並留出合理的測試和評估時間。

初步標準提案

我們已進行一些初步實驗，以開發可啟用的功能，藉此改善第三方載入程序。我們對觀察到的結果感到滿意，目前可以討論其中兩項功能。

LazyEmbeds

過去，Chrome 會為Lite 模式使用者延遲載入螢幕外 <img> 和 <iframe> 元素。這項功能可擴展至所有使用者，讓系統在使用者捲動至 <iframe> 元素附近時，延遲載入這些元素 (系統判定為第三方嵌入項目)。這麼做可以加快網頁其他部分的載入速度、改善 Core Web Vitals、減少記憶體用量並節省資料。

以下是使用 LazyEmbeds 的示範，可在網頁上延後載入 YouTube 影片。單一 YouTube 影片嵌入功能通常會在網頁中加入 500 到 600 KB 的 JavaScript。我們嘗試使用 LazyEmbeds 對含有 14 個這類嵌入式影片的網誌文章進行最佳化。在頁面載入時間和資料節省方面，結果令人振奮。

變更前 變更後
資料 15.4 MB 6.1 MB
總封鎖時間 3.2 秒 1.6 秒

如要進一步瞭解這項工作，請參閱說明和 Blink 開發人員的 意圖至實驗串流和實驗擴充功能。

指定第三方節流

第三方指令碼經常是由不同團隊新增，且沒有整體的監督程序。The Telegraph 的工程團隊表示：「每個人都希望在網頁上放置『那個』標記，讓機構賺取收益。」這可能會持續增加管理效能影響的負擔。

針對性第三方指令碼節流功能會針對特定類型的第三方進行節流，以減輕其影響。這樣一來，瀏覽器就能提早載入主要內容和重要第三方內容，而可在稍後載入的內容則會受到限制。

改善 RUM API

我們也正在考慮強化 RUM API，納入評估第三方成效相關的資訊。強化功能包括：

  1. <iframe> 報表：我們正在開發可運用 Performance Timeline API 的跨框架報表解決方案。這樣一來，頂層網頁的作者就能檢查嵌入頁面中的合作第三方 iframe 的成效資料。

  2. 長時間工作歸因：RUM 中的 Long Tasks API 可協助網站擁有者找出長時間工作，導致主執行緒長時間綁定並延遲互動。

後續更新

我們仍在嘗試許多這類構想，希望能發布 GitHub 說明和規格草稿，以便在後續過程中進行變更。第三方和網站擁有者如想與我們合作或提供意見，可以透過這些管道參與討論。第三方也能開始著重於改善 Core Web Vitals 和 INP 指標，確保 Core Web Vitals/INP 資料不受其影響。目前，積極尋找最新資訊的使用者可以參考 blink-dev 群組中的貼文。

我們期待進一步探索這個問題領域，並與社群分享我們的學習成果。

特別感謝 Leena Sohoni-Kasture、Jeremy Wagner、Gilberto Cocchi、Kenji Baheux、Kouhei Ueno、Kentaro Hara、Alex N. 感謝 Jose、Melissa Mitchell、Yoav Weiss、Shunya Shishido 和 Minoru Chikamune 提供意見回饋和貢獻。