このページは Cloud Translation API によって翻訳されました。

サードパーティライブラリを管理するための Next.js パッケージ

Houssein Djirdeh

2021 年に Chrome Aurora チームは Script コンポーネントを使用して、 Next.js でのサードパーティスクリプトの読み込みパフォーマンス。リリース以来サードパーティリソースの読み込みが容易になり、迅速に実現できるようになります

このブログ投稿では、Google がリリースした新機能の概要をご紹介します。特に @next/third-parties ライブラリと今後の取り組みの概要も記載しています。

サードパーティスクリプトのパフォーマンスへの影響

Next.js サイトのサードパーティリクエストの 41% がスクリプトです。他のコンテンツとの高評価スクリプトのダウンロードと実行にはかなりの時間がかかります。レンダリングがブロックされたり、ユーザーの操作が遅れたりすることがあります。Chrome のデータユーザーエクスペリエンスレポート（CrUX）によると、サードパーティを読み込む Next.js サイトはスクリプトでは、Next Paint とのインタラクションが少なくなります。（INP）と Largest Contentful Paint （LCP）の合格率を決定します。

読み込まれたサードパーティの数に比例して、Next.js の INP スコアと LCP スコアが良好である割合が低下していることを示す棒グラフ — </ph> 2023 年 12 月の CrUX レポート（110,823 サイト）

このグラフで観察された相関関係は、因果関係を示唆するものではありません。ただし、ローカルサードパーティスクリプトがページのパフォーマンスに影響しますたとえば、以下の表は、さまざまなラボを比較したものです。（ランダムに選択された 18 個が対象）の Google タグマネージャーコンテナがタグ（Next.js の一般的なサンプルである Taxonomy）に追加されます。

Google タグマネージャーを使用した場合と使用しない場合で、サイトを読み込んだときのラボのさまざまな指標の違いを示す棒グラフ — </ph> WebPageTest（Mobile 4G - Virginia USA）

WebPageTest のドキュメントでは、これらの時間の測定方法の詳細を確認できます。一見すると、これらすべてのラボの指標が GTM コンテナの影響を受けることが明白であること。対象たとえば、Total Blocking Time (TBT) などの便利なラボです。 20 倍近く増加しました。

スクリプトコンポーネント

Next.js で <Script> コンポーネントをリリースしたとき、従来の <script> によく似たユーザーフレンドリーな API で呼び出すことができます。要素です。これを使用することで、デベロッパーはサードパーティスクリプトをコンポーネントを作成し、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> コンポーネントを使用します。とは言え、一部のデベロッパーは次のことに懸念を抱いています。 :

Next.js アプリでの <Script> コンポーネントの配置場所サードパーティプロバイダの各種インストール手順に合わせ、 （デベロッパーエクスペリエンス）。
状況によって最適な読み込み方法を選択することは、サードパーティのスクリプト（ユーザーエクスペリエンス）。

この両方の懸念に対処するために、Google は @next/third-parties をリリースしました。最適化されたコンポーネントとユーティリティのセットを提供する専用ライブラリ一般的なサードパーティ向けにカスタマイズされています

デベロッパーエクスペリエンス: サードパーティライブラリの管理を容易に

サードパーティスクリプトの多くは、Next.js サイトのかなりの部分で使用されています。最も人気がありそれぞれ 66%。 @next/third-parties は <Script> 上に構築されていますより高レベルのラッパーが導入されています。これらのラッパーは、Terraform での使用を一般的なユースケースを紹介します

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 アナリティクス - 広く使用されているもう一つのサードパーティスクリプト（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% Next.js ウェブサイトの構成要素も用意されており簡単になります。

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" />
    </>
  );
}

ユーザーエクスペリエンス: サードパーティライブラリの読み込みを高速化

理想の世界では、広く採用されているサードパーティライブラリはすべて、パフォーマンスを向上させる抽象化は不要です。しかし、それが現実のものになるまでは、ユーザーの改善を試みることはできます。一般的なフレームワークと統合した場合のエクスペリエンスが向上します。Google では、さまざまな読み込み方法を試し、スクリプトの順序を確認する最終的には Google のフィードバックをサードパーティと共有し、アップストリームの変更を促すことができます。

YouTube の埋め込みの例を見てみましょう。一部の代替実装では、ネイティブの埋め込みよりはるかに高い成果を得られます現在の <YouTubeEmbed> @next/third-parties によってエクスポートされたコンポーネントは、 lite-youtube-embed が表示されています。これは、「Hello, World」でデモンストレーションすると、Next.js との比較で、かなりの負荷がかかる迅速に進めることができます。

YouTube Embed コンポーネントと通常の YouTube iframe でのページ読み込みの比較を示す GIF — </ph> WebPageTest（Mobile 4G - Virginia USA）

同様に Google マップの場合、デフォルト属性として loading="lazy" が含まれます。特定の距離にいるときにのみ地図が読み込まれるようにします。作成します。これは、特に、 Google マップはドキュメントサンプルコードスニペットに含まれていますが、 Google マップを埋め込んでいる Next.js サイトの 45% が loading="lazy" を使用しています。

ウェブワーカーでのサードパーティスクリプトの実行

@next/third-parties で検討している高度な手法の 1 つは、ウェブワーカーにサードパーティスクリプトを簡単にオフロードできます。宣伝者ライブラリ（Partytown など）を使用すると、サードパーティスクリプトがページパフォーマンスに及ぼす影響をメインスレッドから完全に移動します

次のアニメーション GIF は、長いタスクとメインスレッドのバリエーションを示しています。 GTM コンテナにさまざまな<Script>戦略を適用した場合のブロック時間追加します。なお、入札戦略オプションの切り替えはスクリプトが実行されるタイミングを遅らせてウェブワーカーに移動するメインスレッドの時間を完全に省くことができます。

スクリプト戦略ごとのメインスレッドのブロック時間の違いを示す GIF — </ph> WebPageTest（Mobile 4G - Virginia USA）

この例では、GTM コンテナとそのコンテナの実行をタグスクリプトをウェブワーカーに割り当てました。TBT を 92%削減しました。

注意が必要なのは、この手法は注意深く管理しなければ、密かに実行されてしまうことです。多くのサードパーティスクリプトが壊れてしまい、デバッグが困難になります。今後 Google は、Google Cloud で提供されるサードパーティコンポーネントが @next/third-parties は、ウェブワーカーで実行すると正しく機能します。その場合は、デベロッパーがこれを簡単にオプションとして使えるようにすることを目指しています手法です。

次のステップ

このパッケージの開発の過程で明らかになったのは、サードパーティの読み込みに関する推奨事項を一元化して、他のフレームワークが使用されているのと同じ基本的な手法からメリットを得られる可能性があります。これによって、構築サードパーティ Capital（図書館）これは、JSON を使用してサードパーティの読み込み手法を記述します。現在、 @next/third-parties の基盤として機能します。

次のステップとして、今後も提供されるコンポーネントの改善に他のモジュールにも同様のユーティリティを一般的なフレームワークと CMS プラットフォームをサポートしています現在 Nuxt と提携していますメンテナンス担当者向けに開発された、同様のサードパーティユーティリティのリリースを計画しています。今後導入する予定です

Next.js アプリで使用するサードパーティのいずれかが @next/third-parties, パッケージをインストールするやってみよう！フィードバックをお寄せください GitHub。

サードパーティ ライブラリを管理するための Next.js パッケージ

サードパーティ スクリプトのパフォーマンスへの影響

スクリプト コンポーネント

デベロッパー エクスペリエンス: サードパーティ ライブラリの管理を容易に

ユーザー エクスペリエンス: サードパーティ ライブラリの読み込みを高速化

ウェブ ワーカーでのサードパーティ スクリプトの実行