網路上目前大量使用第三方資源，例如嵌入內容和指令碼。這類解決方案提供立即可用的解決方案，用於嵌入社群媒體、影片、數據分析、聊天室、廣告、A/B 測試和個人化功能等。現代網站需要使用第三方嵌入內容，才能讓網站擁有者專注於核心能力，同時卸載標準卻重要的功能，減輕外部供應商的負擔。
如果第一方和第三方在同一個網頁上運作時順暢運作，網頁就可能提供良好的使用者體驗。不過，工程和業務團隊必須投入大量心力，且經常受到忽視，導致網頁成效不佳，並會對以使用者為中心的指標 (例如網站體驗核心指標) 產生負面影響。這對雙方都會不堪負荷，也會讓商家錯失商機。這裡還有需要改進的地方嗎？
我們未來將透過第三方指令碼和資源，以最低限度的干擾性，在採用第三方指令碼和資源的網站瀏覽網站時，提供適當的商業價值。這樣一來，使用者就能享有更快的頁面載入速度。
過去一年來，我們思考、討論及嘗試各種可能性，避免第三方指令碼對使用者體驗造成負面影響，而且不會影響網站擁有者的業務價值。
我們希望透過這篇文章分享部分實驗相關資訊。我們希望這只是一個程序的起點，這麼做能提升使用者代理程式、商家和第三方供應商之間的透明度和透明度，進而為網頁載入速度更快做好準備。
深入探究第三方
第三方是指由網站外部供應商提供的資源，他們無法直接控制網站擁有者的控制方式，而是已取得他們的核准。第三方資源如下：
- 由與主要網站來源不同的共用和公開來源代管。
- 不是由個別網站擁有者編寫或影響。
- 廣泛用於各種網站。
第三方能協助企業達成各種業務目標，包括透過廣告產生收益，以及提供更優質的行銷機會 (社群媒體嵌入)。常見的第三方類別如下：
資料來源：第三方 (按類別劃分)。
| 類別 | 定義 |
|---|---|
| 廣告 | 用於放送廣告或評估廣告成效的指令碼。 |
| 影片 | 啟用影片播放器和串流功能的指令碼。 |
| 代管的程式庫 | 公開代管的開放原始碼程式庫組合。 |
| 內容 | 來自內容供應者的指令碼，或發布專屬的聯盟追蹤功能。 |
| 客戶成功 | 客戶支援/行銷供應商的腳本，可提供即時通訊和聯絡解決方案。 |
| 託管 | 來自網站代管平台的指令碼。 |
| 行銷 | 由行銷工具新增彈出式視窗、電子報等內容的指令碼。 |
| 社群媒體 | 啟用社交功能的指令碼。 |
| 代碼管理工具 | 載入其他指令碼及啟動多項工作的指令碼。 |
| 數據分析 | 評估或追蹤使用者及其動作的指令碼。 |
| Cookie 同意聲明平台 | 透過指令碼，讓網站按照清楚且公開透明的方式取得使用者同意聲明 (GDPR、ePR、CCPA)。 |
| 實用功能 | 屬於開發人員公用程式的指令碼 (API 用戶端、網站監控、詐欺偵測等)。 |
| 其他 | 透過共用來源傳送的其他指令碼，但沒有精確的類別或出處。 |
這些第三方指令碼和程式庫可讓網頁程式開發人員運用經實證有效的解決方案，導入標準功能，不必重複開發工具。因此，第三方可以縮短開發時間，並加快商家推出或升級產品的速度。令人驚嘆的是，電腦和行動裝置上有超過 94% 的網站會使用第三方。
第三方對成效有何影響？
理想情況下，第三方開發人員應針對自己提供的特定功能指派主題專家。大多數熱門的第三方都經過多次疊代，也希望根據自己的業務目標調整程式碼，這不一定包含使用網頁的成效。不過，我們也知道，即使是最佳化程度最高的第三方，也會影響成效。以下是造成影響的主要原因：
大小和指令碼執行費用：第三方通常「只」在網頁中置入
<script>或<iframe>元素，主要是為了提供顯著的功能。接著，這些元素會提取耗用大量資源的指令碼和資源，需要較長的時間才能下載和執行。太多 JavaScript 有助於讓主執行緒長時間忙碌、阻礙轉譯，並延遲使用者互動。部分頂尖第三方在分析的網站中，有超過 42 毫秒到 1.6 秒會封鎖主執行緒，時間超過 42 毫秒。遭到封鎖的主要執行緒會導致總封鎖時間 (TBT) 偏高，這個指標會影響網站的效能分數。此外，該 API 也會延遲回應使用者互動，並降低用於評估網站回應速度的「與下一個繪製互動」(INP) 指標。因此，指令碼執行成本會對效能產生重大影響。數字：平均而言，網站在行動版和網站上使用大約 21 個不同的第三方。第三方代碼通常是透過代碼管理工具加入，但該工具不會直接由技術/開發團隊控管。不需要的標記可能由其他團隊加入，即使沒有審查程序，也絕對不會移除。可能會對使用者體驗、網頁權重或 CPU 使用率產生重大影響。建立管理程序可以解決這類情況，讓開發人員稽核每個供應商的影響。如果開發人員已經準備好資料，供所有第三方使用，也能提供特定功能，包括效能影響、優勢和優缺點，以便進行比較。團隊面臨的另一個挑戰是，許多網站的第三方代碼只能在實際工作環境中執行，而無法在開發環境中執行，因此讓開發人員更難以測試。
網路：由於第三方是由不同來源代管，因此瀏覽器必須建立大量連線，才能從來源下載內容。不同的連線無法根據優先順序協調下載作業，導致網路爭用。如果不考量適當的最佳化設定，這可能會進一步延遲網頁載入。
序列：第三方可以封鎖主執行緒，並與頻寬競爭，以取得更重要的資源。儘管如此，在某些情況下，第三方是轉譯網頁所需的重要資源。如果網站使用多個第三方，則有必要為第一方和第三方資源設定最佳序列。網頁開發人員應瞭解有哪些選項可用來最佳化序列。
因上述情況，第三方可能會影響網站體驗核心指標的任何或所有元件。大部分的第三方會對最大內容繪製 (LCP) 和首次輸入延遲時間 (FID) 造成負面影響。YouTube 內嵌封鎖主要執行緒，有 4.5 秒的網站會在行動裝置上載入，50% 的網站研究網站則至少為 1.6 秒。假設使用者在連線速度緩慢時，瀏覽到含有 20 種這類指令碼的網頁時感到不悅，以下由 thirdpartyweb.today 提供的圖表，顯示目前成效影響最大的第三方。
「在前 4 百萬個網站當中，約 2, 700 個來源佔了約 57% 的指令碼執行時間，前 50 名實體佔了約 47%。」- 第三方網站
網頁必須能在合理時間範圍內快速轉譯且具備互動性，才能根據網站體驗核心指標的評估結果，提供良好的使用者體驗。良好的使用者體驗往往能為網站帶來良好業務成效，而使用第三方也能獲得良好業務成效。攜手減少第三方的影響，或許能為鏈結中的所有人創造雙贏。
我們知道 Google 推出了許多常用第三方指令碼，包括 Google 代碼管理工具、YouTube 嵌入項目和 reCAPTCHA 等等。我們明白，我們的部分指令碼可能會對網站體驗核心指標的效能產生較輕微的影響，因此也致力於探索如何盡可能提高這類影響。
Chrome 能提供哪些協助？
對第三方而言，第三方資源的效能不佳，經常是一大挑戰，因為基礎生態系統的動態變化需要逐步改變。Chrome 想要探索這個空間，並實現下列成果：
找出以更好的方式在網路上載入第三方資源，並且不影響使用者體驗或業務成果。
我們知道如果不與合作夥伴、商家、第三方和開發人員合作，我們就無法繼續努力。我們想打造一個開放式領域，讓大家討論各種可能性，並透過公開解說內容與規格交流想法。開發人員將有時間提供意見回饋，並測試許多提案的影響。
讓第三方指令碼的使用者能更妥善地歸因工具及實際使用的費用，並且在編寫期間提供清楚明確的使用路徑，並在編寫期間提供更周全的獎勵，確保指令碼在預設情況下能發揮最佳效能。
我們想強化所有層，例如使用者代理程式、架構和第三方指令碼，藉此降低第三方的效能影響。我們也希望能提供充分的深入分析，協助網站擁有者針對各種內嵌指令碼採用最佳做法，包括加快替代速度。
建議做法
為了達到這些成果，我們建議採用三管齊下的做法...
**透過 RUM 和 Chrome 開發人員工具，讓開發人員更深入地瞭解每個第三方的影響**。
RUM 是指透過網頁效能監控 API 取得的實際使用者指標資料 (又稱為「現場資料」)。Chrome 的開發人員工具包含 Lighthouse、Chrome 開發人員工具和 Chrome 使用者體驗報告。我們提議改進可用的 API 和工具，讓網站開發人員能夠瞭解在各個網頁上使用的每個第三方會帶來的影響。這些工具也會向他們說明可以採取哪些行動來減輕影響 (例如延遲交付或使用門面)，並探索其他可能的權衡解決方案 (其他第三方或 DIY)。針對網路效能監控 API，我們正在探索如何在不影響使用者隱私權和安全性的情況下，擴大跨來源資源的涵蓋範圍。
**為企業提供照明妥善的路徑，以便有效率地載入第三方資源。**
我們想提出新標準，鼓勵瀏覽器更明智地權衡第一方和第三方資源的載入方式，為使用者提供更優異的載入體驗。稍後，我們會重點介紹其中幾種提案，例如預設會延遲載入第三方嵌入，或者針對使用者可能較關注最初內容，不太重要的第三方資源套用不同的資源優先順序。這些只是我們要在這個領域中評估的一小部分構想，也希望與網路成效專家和廣大社群合作，共同形塑這項工作的發展方向。
另外，我們也希望視情況解決 JavaScript 架構和內容管理系統 (CMS) 中發生的問題。Aurora 和 WordPress 效能團隊等專案告訴我們，烘焙預設功能對解決已知載入問題的重要性。預設運作方式可融入各種架構，讓企業循序漸進地引導企業行事。對 Chrome 等使用者代理程式來說，這些參數也相當實用，因為可以提示運用經驗法則來最佳化網頁載入和 CWV。這些提示可協助使用者代理程式決定特定第三方在網頁生命週期中載入的時機和方式。(舉例來說，Next.js 指令碼元件預設會在網頁互動後載入第三方指令碼)。
**提供獎勵給第三方，透過更公開透明的方式降低成效影響**。
第三方開發人員目前無法取得所需瀏覽權限，因此無法瞭解指令碼對大型網站的影響。我們打算解決這項問題，並為供應商提供工具，方便他們分析其影響，並與市場上價值相同的產品比較。我們也希望協助他們運用這些資料診斷影響範圍，進而減少上游問題。我們必須徹底指出所有第三方 (包括 Google 編寫的第三方)，才能成功執行要求。
挑戰
這項工作的成果可帶來許多挑戰。我們必須考量的一些主要挑戰是。
- 第三方會交叉比對廣告、分析、代碼管理和公用程式等問題。每個領域都需要考慮自己獨特的要求與優缺點。例如：
- 改善廣告載入量的決策，取決於收益和使用者體驗之間的取捨。太早封鎖有價值的內容；結果太晚，他們可能會錯過這些內容。
- Analytics (分析) 指令碼雖然加進網頁權重，但提供與商家使用者動作相關的重要資料。
我們希望與各種類別的第三方合作、掌握所涉及的細節、解決取捨問題，並制定適合所有人的獎勵措施。我們瞭解，我們必須與各領域的實體個別合作，策略才能有效運作。包括 Google 代碼管理工具、Google Ads 和 YouTube 等內部合作夥伴。
我們希望進一步歸因於網站開發人員和第三方開發人員。這需要投入深思熟慮，才能在評估影響時找出哪些資料最相關、準確歸因，並提供正確的路徑。最後，計算方式應公開說明特定第三方與競爭對手的競爭成效。
我們提議強化 Chrome，讓 Chrome 在優先載入第一方和第三方資源時套用最佳化功能，以在各方面取得理想平衡。一項重要的異動已在所有瀏覽器中推出這套標準系統，但需要一些時間才能完成。舉例來說，Chrome/Edge 開始提供
<img>和<iframe>元素的loading屬性，但自 2022 年起在 Safari 中開放使用。在功能標準化之前，第三方資源的使用者也必須確保他們適用於其他瀏覽器。我們會在適當情況下強調這一點。為了執行這項專案，我們必須與合作夥伴和開發人員合作，不僅要協助我們瞭解特定需求，還能大規模測試實驗性解決方案，並在需要時提供意見回饋、反覆測試和即興發揮。變更必須經過規劃，預留合理的測試和評估時間。
初始標準提案
我們已經進行一些初步實驗，致力開發可最佳化第三方載入程序的功能。我們對於觀察的結果非常滿意，現在能夠進一步討論這兩項功能。
LazyEmbeds
Chrome 先前會為精簡模式使用者延遲載入畫面 <img> 和 <iframe> 元素。您可以針對所有使用者執行這項功能，延後載入經第三方嵌入的 <iframe> 元素，直到使用者捲動附近為止。這可以加快頁面其他部分的載入速度、改善網站體驗核心指標、降低記憶體用量並節省資料。
以下示範使用 LazyEmbeds 延遲載入網頁上的 YouTube 影片。嵌入一個 YouTube 影片內嵌後，通常就會在網頁上增加 500-600KB 的 JavaScript。我們嘗試使用 LazyEmbeds 針對 14 個這類內嵌影片進行網誌文章最佳化。不論是網頁載入時間還是節省資料，成效都很出色。
| 變更前 | 變更後 | |
|---|---|---|
| 資料 | 15.4 MB | 6.1 MB |
| 總封鎖時間 | 3.2 秒 | 1.6 秒 |
如要進一步瞭解這項作業，請參閱說明和 blink-dev 的 intent-to-experiment 執行緒和實驗擴充功能。
指定第三方節流
第三方指令碼通常是由多個團隊加入，但無法全面監督。The Telegraph 的工程團隊向來說明「所有人希望在網頁上使用代碼，藉此提高機構收益」。這會持續增加管理效能影響的負擔。
針對目標的第三方指令碼調節功能提出了限制措施，以限制特定類型的第三方來降低影響。這可讓瀏覽器盡早載入重要內容及重要的第三方，但稍後可載入的安全內容則會受到限制。
強化 RUM API
我們也考慮強化 RUM API，納入評估第三方成效時所需的資訊。強化功能包括：
<iframe>報表：我們正在研究解決方案，運用 Performance Timeline API 製作跨影格報表。這樣一來，頂層頁面的作者就能查看網頁上內嵌的第三方 iframe 成效資料。長時間工作歸因：RUM 中的 Long Tasks API 可協助網站擁有者找出連結主執行緒很長一段時間且延遲互動的長時間工作。
其他最新消息
我們仍在對許多這類構想進行實驗，並希望發布 GitHub 說明和規格草稿，以便日後變更流程。想要與我們合作或提供意見的第三方和網站擁有者，都可以透過這些方式進行討論。第三方也可能會開始專注於針對網站體驗核心指標和 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 提供意見和貢獻。