2026年の3つのCore Web Vitals

Googleはページエクスペリエンスに関して3つの主要なフィールド指標を測定しています。それぞれに「良好」なパフォーマンスの閾値があります：

• Largest Contentful Paint（LCP） — 最大の可視要素をレンダリングするまでの時間。良好：2.5秒未満。
• Interaction to Next Paint（INP） — すべてのユーザーインタラクションへの応答性（2024年3月にFIDを置き換え）。良好：200ms未満。
• Cumulative Layout Shift（CLS） — 読み込み中の視覚的安定性。良好：0.1未満。

レンダリングをブロックし、読み込み時に重いJavaScriptを実行し、または遅延レイアウト変更を注入する同意バナーは、これらのいずれかを「改善が必要」または「不良」バンドに押し込む可能性があります — GoogleはリアルなChromeユーザーからの28日間のフィールドデータを使用しているため、一時的な問題が持続的なランキングシグナルになります。

同意バナーがLCPを損なう方法

Largest Contentful Paintは通常、ヒーロー画像や見出しで発生します。いくつかの同意パターンが不必要に遅延させます：

レンダリングをブロックするCMPスクリプト

ドキュメントのheadからCMPを同期的に読み込むと、スクリプトがダウンロードされて実行されるまでHTMLの解析が停止します。CMPが遅いCDNでホストされていたりコールドキャッシュがあったりする場合、LCPにグローバルで200〜800msを追加する可能性があります。

ヒーローを覆うバナー

同意バナーがLCP要素を覆うモーダルオーバーレイとして配置されている場合、ブラウザは引き続き覆われた要素からLCPを測定します。しかし、バナーが最も大きく描画された要素であれば、LCP候補になります — そしてページ読み込み後にJavaScriptで描画された場合、LCPは人工的に高くなります。

修正：小さなインラインBootstrapによる非同期読み込み

完全なCMPを非同期で読み込み（`async`または`defer`）、初期バナー表示のための小さなインラインスクリプトのみを使用します。圧縮後5KB未満のbootstrapを目標にしてください。完全な動作ロジック、ベンダーリスト、UIクロームは初回描画後に遅延読み込みできます。

同意バナーがINPを損なう方法

Interaction to Next Paintは、セッション中のすべてのクリック、タップ、キー押下における最悪の応答時間を測定します。Cookie同意のインタラクションは、ユーザーが行う最初のインタラクションであることが多いため、遅い「同意する」ボタンはスコアを台無しにします。

同意時の重い処理

多くのCMPは同意時に同期的な処理を実行します：40以上のベンダースクリプトの読み込み、localStorageへの書き込み、dataLayerイベントの発火、Google Consent Modeの更新のトリガー。これが200msを超えると、INPが悪化します。

修正：描画後に処理をキューに入れる

同意ボタンのクリック時に、すぐにバナーを非表示にし、`requestIdleCallback`または`setTimeout(0)`で重い処理をスケジュールします。ユーザーにはバナーが即座に消えるように見えます。ベンダースクリプトはインタラクションをブロックせずにバックグラウンドで読み込まれます。

同意バナーがCLSを損なう方法

Cumulative Layout Shiftは予期しない視覚的な動きを追跡します。バナーはコンテンツが描画された後にDOMに注入されると、CLSの典型的な原因となります。

遅延バナー注入

LCPから800ms後にバナーが表示されると、コンテンツが下に押し下げられてレイアウトシフトが発生します。ビューポートの大きな部分に影響する場合、小さなバナーでも0.1以上のCLSスコアを引き起こす可能性があります。

Cookie設定ウィジェットの再レンダリング

ベンダーロゴを非同期に読み込むフッターの設定ウィジェットは、フッター全体を複数回リフローさせ、CLSを悪化させる可能性があります。

修正：前もってスペースを確保する

CSSを使用して、最初の描画からバナーのスペースを確保します — 固定高さのプレースホルダー、フッターの`min-height`、またはコンテンツを押し下げない下部固定バナー。現代のCMPはデフォルトでCLSゼロの設定を提供すべきです。

Google Consent Mode V2とパフォーマンス

Consent Mode V2を使用すると、Googleタグが同意前にクッキーなしの状態で動作し、`gtag('consent', 'default', {...})`を通じてシグナルを送信できます。これは測定の継続性に優れていますが、gtag.jsライブラリ自体は50〜90KBあります。非同期で読み込み、競合状態を避けるためにできるだけ早くデフォルトを設定してください。

• gtag読み込み前にデフォルトを設定する — gtag.jsスクリプトの前に、headに同意デフォルト呼び出しを配置します。
• デフォルトとして`analytics_storage: 'denied'`を使用する — 同意前に収集されるデータを最小化します。
• requestIdleCallbackを介して同意時に更新する — メインスレッドのブロックを避けます。

Core Web VitalsへのCMPの影響を測定する

推測しないで — 測定してください。バナーの影響を定量化するためにこれらのツールを使用します：

• PageSpeed Insights — Chrome UXレポートからのフィールドデータと実験室Lighthouseの監査。CMPスクリプトありとなしでスコアを比較してください。
• Web Vitals Chrome拡張機能 — ローカルテスト中のリアルタイムLCP、INP、CLSオーバーレイ。
• WebPageTest.org — バナーがいつレンダリングされ、何をブロックするかを正確に示すフィルムストリップとウォーターフォールビュー。
• Search ConsoleのCore Web Vitalsレポート — URLパターンでグループ化された28日間のフィールドデータ。バナーがあるランディングページとないページでスコアが異なるかどうかを確認してください。

FlexyConsentが高速を維持する方法