Next.jsでサードパーティスクリプトを修正し、Core Web Vitalsを改善する
Next.jsでサードパーティスクリプトによって引き起こされるCore Web Vitalsの問題を修正する
Next.jsのサードパーティスクリプトを修正する
サードパーティスクリプトは、最適化されたNext.jsサイトにおいてCore Web Vitalsが不合格になる最も一般的な原因です。画像の最適化、静的生成の実装、クリティカルCSSのインライン化など、すべてを正しく行ったとします。しかし、Interaction to Next Paintは依然として不合格になります。その原因のほとんどはサードパーティのJavaScriptです。2025 Web Almanacによると、92%のページが少なくとも1つのサードパーティリソースを読み込んでいます。スクリプトはすべてのサードパーティリクエストの24.8%を占めており、他のどのリソースタイプよりも多くなっています。
2026年3月、Arjen Karelによる最終レビュー
これは、広告、分析、ソーシャルメディアボタン、ウィジェット、A/Bテストスクリプト、ビデオプレーヤーなどのサードパーティスクリプトが原因である可能性があります。
サードパーティスクリプトがCore Web Vitalsに与える影響
サードパーティスクリプトは、想像以上にさまざまな形でCore Web Vitalsを台無しにする可能性があります。これらは、私が実際のWebサイトで遭遇する問題の一部です。
- ネットワークの速度低下。サードパーティスクリプトは、複数のサーバーに複数のリクエストを送信し、画像やビデオなどの最適化されていない大きなファイルをダウンロードし、フレームワークやライブラリを何度もダウンロードする可能性があります。
- サードパーティのJavaScriptは、いつでも（またはページ訪問中に複数回）DOMをブロックする可能性があり、ページのレンダリング速度を遅らせ、CPU時間を使いすぎることでユーザーの操作を遅延させ、バッテリーの消耗を引き起こす可能性があります。
- レンダリングをブロックするサードパーティスクリプトは、単一障害点（SPOF）になる可能性があります。
- サードパーティスクリプトは、不適切に設定されたHTTPキャッシュ、不十分なサーバー圧縮、遅いまたは古すぎるHTTPプロトコルが原因でネットワークの問題を引き起こす可能性があります。
- コンテンツの非表示、ブラウザイベント（ウィンドウのロードイベントなど）のブロック、document.writeなどの古いAPIの使用など、他の多くの方法でユーザーエクスペリエンスを損なう可能性があります。
その数字は深刻なものです。Chrome Auroraチームの調査によると、18個のタグを持つGoogle Tag Managerコンテナは、Total Blocking Timeを約20倍に増加させます。2025 Web Almanacでは、モバイルのTBTの中央値が1,916ミリ秒であり、ベストプラクティスである200ミリ秒の約10倍であると報告されています。サードパーティスクリプトは、その数値の主な要因です。
Next.jsでサードパーティスクリプトとCore Web Vitalsを修正する
理想的には、サードパーティスクリプトがクリティカルレンダリングパスに影響を与えないようにする必要があります。最初の直感としては、deferまたはasync属性を使用することでしょう。残念ながら、タイミングの観点から見ると、これはほとんどのNext.jsサイトにとって良い選択肢ではありません。Next.jsサイトは、ページをハイドレーションするためにJavaScriptに大きく依存しています。
つまり、Next.jsのバンドルがダウンロードされるとすぐに、ブラウザはそのJavaScriptを実行します。これには時間とリソースがかかります。ブラウザがサードパーティのJavaScriptのコンパイルと実行に忙しすぎる場合、このプロセスは遅くなります。
Next.jsのScriptコンポーネント
Next.jsのScriptコンポーネント（next/script）を使用すると、アプリケーションコードと比較してサードパーティスクリプトを読み込むタイミングを制御できます。ブラウザのデフォルトの読み込み動作と戦うのではなく、スクリプトの重要度に一致する戦略を選択します。
任意のコンポーネントでインポートします：
import Script from 'next/script' 戦略
next/scriptを使用すると、strategyプロパティを使用してサードパーティスクリプトを読み込むタイミングを決定できます。4つの読み込み戦略があります：
- beforeInteractive: ページがインタラクティブになる前にスクリプトを読み込む
- afterInteractive: ページがインタラクティブになった直後にスクリプトを読み込む
- lazyOnload: アイドル時間中にスクリプトを読み込む
- worker: Webワーカーでスクリプトを読み込む（実験的、Pages Routerのみ）
beforeInteractive戦略
beforeInteractive戦略で読み込まれるスクリプトは、defer属性が有効な状態でサーバーから初期HTMLに挿入され、自己バンドルされたJavaScriptが実行される前に実行されます。
Core Web Vitalsの観点から見ると、これはまさに私たちが避けたい動作です！beforeInteractive戦略は、ページにとって絶対に不可欠なスクリプトにのみ使用する必要があります。サードパーティスクリプトが不可欠になることは決してありません！
<Script
id="bootstrap-cdn"
src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstrap.bundle.min.js"
strategy="beforeInteractive"
/> この場合、bootstrapのJavaScriptライブラリは、Next.jsバンドルの直前にdefer属性を使用して生成されたHTMLに追加されます。つまり、ブラウザはおそらくNext.jsバンドルよりも前にbootstrapライブラリをフェッチして実行します。これにより、Next.jsのハイドレーションが遅延し、ブラウザがNext.jsのチャンクをダウンロードして実行する必要があるときにメインスレッドがブロックされる可能性があります。Core Web Vitalsの場合、これはInteraction to Next Paintがおそらく影響を受けることを意味します。
afterInteractive戦略
afterInteractive戦略を使用するスクリプトはクライアント側で挿入され、Next.jsがページをハイドレーションした後にダウンロードされます。
Core Web Vitalsの観点から見ると、これはサードパーティスクリプトを挿入するためのはるかに優れた（しかし、まだ完璧ではない）場所です。この戦略は、できるだけ早く読み込む必要がなく、ページがインタラクティブになった直後にフェッチして実行できるスクリプトに使用する必要があります。
<Script
strategy="afterInteractive"
dangerouslySetInnerHTML={{
__html: `
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer', 'GTM-XXXXXX');
`,
}}
/> Google Tag ManagerとGoogle Analyticsについては、現在、より良い選択肢があります。以下の@next/third-partiesセクションを参照してください。
lazyOnload戦略
lazyOnload戦略で、ついに興味深い展開になります！私がサードパーティスクリプトについて考えていることはシンプルで、「それらはページにとって不可欠であるべきではない」ということです。特定のサードパーティスクリプトなしではやっていけない場合は、おそらくサードパーティに依存するべきではありません。
lazyOnload戦略を使用するスクリプトは、すべてのリソースがフェッチされた後のアイドル時間中に遅延読み込みされます。これは、サードパーティスクリプトがNext.jsのチャンクに干渉せず、このスクリプトがInteraction to Next Paint (INP)に与える影響を最小限に抑えることを意味します。
<Script
id="some-chat-script"
src="https://example.com/chatscript.js"
strategy="lazyOnload"
/> worker戦略
worker戦略は、メインスレッドの代わりにWebワーカーでスクリプトを実行するためにPartytownを使用する実験的な機能です。このコンセプトは興味深いものです。Chrome Auroraチームの測定によると、GTMをWebワーカーに移動した場合、TBTが92%削減されました。しかし、worker戦略はPages Routerでのみ機能します。App Routerはサポートしていません。私のアドバイスとしては、プロジェクトが成熟するか、WebワーカーでDOMが利用できるようになるまでは、これには近づかないことです。
@next/third-parties: モダンなアプローチ
Next.jsは現在、最も一般的なサードパーティサービス向けに最適化されたコンポーネントを含む@next/third-partiesパッケージを提供しています。これらのコンポーネントは内部で読み込み戦略を処理するため、自分で設定する必要はありません。
インストール：
npm install @next/third-parties Google Tag Managerの場合は、ルートレイアウトにコンポーネントを追加します：
import { GoogleTagManager } from '@next/third-parties/google'
export default function RootLayout({ children }) {
return (
<html>
<GoogleTagManager gtmId="GTM-XXXXXX" />
<body>{children}</body>
</html>
)
} Google Analyticsの場合：
import { GoogleAnalytics } from '@next/third-parties/google'
export default function RootLayout({ children }) {
return (
<html>
<body>
{children}
<GoogleAnalytics gaId="G-XXXXXX" />
</body>
</html>
)
} Chrome Auroraチームは、Next.jsサイトの66%がGoogle Tag Managerを使用し、52%がGoogle Analyticsを使用していると報告しています。これらのいずれかを読み込む場合は、dangerouslySetInnerHTMLを使用する汎用のScriptコンポーネントの代わりに、専用のコンポーネントを使用してください。GTMのdataLayerを使用する場合は、プッシュイベントがインタラクションをブロックするのを防ぐために、dataLayer INP yield patternも参照してください。
どのスクリプトにどの戦略を使用するか？
- GTMおよびGA： @next/third-partiesコンポーネントを使用します。これらは内部でタイミングを処理します。
- チャットウィジェット（Intercom、HubSpot、Drift）：
lazyOnloadを使用します。チャットウィジェットが最初のインタラクションに不可欠であることは決してありません。 - A/Bテスト（Optimizely、VWO）： テストがアバブザフォールドのコンテンツに影響を与える場合にのみ、
beforeInteractiveを使用します。それ以外の場合はafterInteractiveを使用します。 - ソーシャル埋め込みとビデオプレーヤー：
lazyOnloadを使用します。 - 広告スクリプト：
afterInteractiveを使用します。広告は収益のために適度に早く読み込まれる必要がありますが、ハイドレーションをブロックするべきではありません。
CoreDashによって監視されているNext.jsサイト全体で、分析スクリプトにlazyOnloadを使用しているサイトは、afterInteractiveと比較して中央値で27ミリ秒のINPの改善を示しています。これは、INPのしきい値の合格と不合格の差になります。
どの戦略を選択するにしても、Real User Monitoringを使用して結果を検証してください。ラボスコアは、何が起こる可能性があるかを示します。フィールドデータは、実際に何が起こったかを示します。そして場合によっては、最高の最適化は不要なスクリプトを削除することです。
影響の測定についての詳細は、Next.jsでのCore Web Vitalsの測定に関するガイドを参照してください。Next.jsのレンダリングをブロックするCSSにも対処している場合は、まずそちらを修正してください。ブラウザが何をいつフェッチするかを決定する方法についてのより幅広い視点については、リソースの優先順位付けガイドを参照してください。
