在 2021 年，Chrome Aurora 團隊引進了這個指令碼 元件，改善 在 Next.js 中載入第三方指令碼的效能。自這項功能推出以來 擴充其功能，讓第三方資源載入變得更輕鬆， 能讓開發人員更快完成
這篇網誌文章概略介紹了新推出的功能 值得注意的是 @next/third-parties 程式庫，並概述未來計畫的藍圖。
第三方指令碼對效能的影響
Next.js 網站中約有 41% 的第三方要求是指令碼。與其他內容不同 因此，下載及執行指令碼時 可能會耗費大量時間 導致轉譯過程無法顯示，並延遲使用者互動Chrome 中的資料 使用者體驗報告 (CrUX) 顯示，相較於載入更多第三方的 Next.js 網站 指令碼的與下一個顯示畫面的互動情形較少 (INP) 和 Largest Contentful Paint (LCP) 通過率。
此圖表中觀察到的相關性，並不代表發生原因。不過，本機 實驗提供了額外證據，證明第三方指令碼明顯 影響網頁效能舉例來說，下方圖表比較了不同研究室的 Google 代碼管理工具容器 (最多隨機選取 18 個) 標記) 已新增至 Taxonomy，這是常用的 Next.js 範例 應用程式。
WebPageTest 說明文件 詳細說明如何衡量這些時間。簡單來說 確定所有這些研究室指標都受到 GTM 容器影響。適用對象 例如 Total Blocking Time (TBT)：這是實用的研究室 約為 INP 的公司，增幅將近 20 倍。
指令碼元件
我們在 Next.js 中傳送 <Script> 元件時，確實會導入
，且功能與傳統 <script> 類似，容易使用
元素。有了這項功能，開發人員就能在所有
所有元件，而 Next.js 會處理
指令碼。
<!-- By default, script will load after page becomes interactive -->
<Script src="https://example.com/sample.js" />
<!-- Script is injected server-side and fetched before any page hydration occurs -->
<Script strategy=”beforeInteractive” src="https://example.com/sample.js" />
<!-- Script is fetched later during browser idle time -->
<Script strategy=”lazyOnload” src="https://example.com/sample.js" />
數以千計的 Next.js 應用程式，包括
Patreon、Target 和
注意：使用 <Script> 元件。但
部分開發人員聲稱以下方面擔憂
事物：
<Script>元件應放在 Next.js 應用程式中的哪個位置，同時一併遵循 參閱各家第三方供應商的不同安裝操作說明 (開發人員體驗)。- 不同的載入策略 第三方指令碼 (使用者體驗)。
為解決這兩個問題，我們推出了 @next/third-parties，
這個專業程式庫提供一組最佳化元件和公用程式
專為熱門第三方設計而成
開發人員體驗：讓第三方程式庫更容易管理
絕大部分的 Next.js 網站都使用許多第三方指令碼，
Google 代碼管理工具是最熱門的
66% 的網站。
「@next/third-parties」以 <Script> 為基礎建構而成
藉由導入較高層級的包裝函式來簡化
這些常見用途
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
<GoogleTagManager gtmId="GTM-XYZ" />
</html>
);
}
Google Analytics：另一種廣為使用的第三方指令碼 (佔 Next.js 網站的 52%) 本身也有一個專屬元件。
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
<GoogleAnalytics gaId="G-XYZ" />
</html>
);
}
@next/third-parties 簡化了常用指令碼的載入程序，
而且也強化了我們為其他第三方機構開發公用程式的能力
例如嵌入舉例來說，Google 地圖和 YouTube 的嵌入嵌入
用於
8%
和
4%
同時我們也提供了元件
載入。
import { GoogleMapsEmbed } from "@next/third-parties/google";
import { YouTubeEmbed } from "@next/third-parties/google";
export default function Page() {
return (
<>
<GoogleMapsEmbed
apiKey="XYZ"
height={200}
width="100%"
mode="place"
q="Brooklyn+Bridge,New+York,NY"
/>
<YouTubeEmbed videoid="ogfYd705cRs" height={400} params="controls=0" />
</>
);
}
使用者體驗：加快第三方程式庫的載入速度
理想情況下，獲得廣泛採用的第三方程式庫會是完全的 ，因此不需使用任何抽象化功能來改善效能。 但在那之前，我們可以嘗試改進使用者 也能感受到公司提供的產品價值我們可以 嘗試不同的載入技術，確保指令碼按順序顯示 並將意見回饋轉達給第三方 以鼓勵上游變更
以 YouTube 嵌入項目為例，部分替代導入方式
比起原生嵌入影片的成效更佳目前《<YouTubeEmbed>》
@next/third-parties 用途匯出的元件
lite-youtube-embed，
在「Hello, World」Next.js 比較，可大幅載入
同樣地，Google 地圖也會加入 loading="lazy" 做為
嵌入可確保地圖只會在
檢視區域這看起來似乎很明顯，可包含 - 尤其是
自 Google 地圖
說明文件
會將這個程式碼包含在樣本程式碼片段中，但
在嵌入 Google 地圖的 Next.js 網站中，有 45% 使用 loading="lazy"。
在網路工作站中執行第三方指令碼
我們在 @next/third-parties 中探索的一項進階技巧，是採用
可讓網路工作站輕鬆卸載第三方指令碼。熱門
因此，像 Partytown 這樣的資料庫，因此能減少
第三方指令碼對網頁效能的影響
已完全將其重新移至主執行緒外。
以下 GIF 動畫顯示長工作和主要執行緒中的變化
將不同的「<Script>」策略套用至 GTM 容器時，會帶來許多封鎖時間
。請注意，只有切換策略選項時
會延遲執行這些指令碼的時間，將這些指令碼重新移至網路工作站
就會完全減少在主執行緒上花費的時間
在這個具體範例中， 與網路工作人員相關聯的標記指令碼減少了 92%。
值得注意的是，如果未謹慎管理，這項技術可能會
破壞許多第三方指令碼，導致偵錯變得困難。近期內
若第三方元件是由您手動提供，我們會進行
在網路工作站中執行時，@next/third-parties 函式可正常運作。如果有，我們會
致力為開發人員提供簡單且選用的方式
這是標準文字處理技術
後續步驟
在開發這個套件的過程中，我們發現
將第三方載入建議集中在一處，讓其他架構
也能享有相同的基礎技術因此
建立第三方
Capital：圖書館
來描述第三方載入技術
做為 @next/third-parties 的基礎
在接下來的步驟，我們會持續改善系統提供的元件 ，並擴展我們在其他 熱門架構和 CMS 平台我們目前正與 Nuxt 合作 並計劃推出適用於維護人員的類似第三方公用程式 有利於他們生態系統
如果您用於 Next.js 應用程式的其中一個第三方受到支援
@next/third-parties,
安裝套件
試試看吧！我們很想瞭解您對下列主題的意見：
GitHub。