Cookie に関する通知のベスト プラクティス

パフォーマンスとユーザビリティを重視して Cookie に関する通知を最適化する。

このドキュメントでは、Cookie に関する通知がパフォーマンス、パフォーマンス測定、ユーザー エクスペリエンスに与える影響について説明します。

Cookie に関する通知は、通常はページ読み込みプロセスの早い段階で読み込まれ、すべてのユーザーに表示されるため、広告やその他のページ コンテンツの読み込みに影響する可能性があるため、ページのパフォーマンスに大きな影響を与える可能性があります。

Cookie に関する通知が Web Vitals 指標に与える影響は次のとおりです。

  • Largest Contentful Paint(LCP): ほとんどの Cookie 同意通知は非常に小さいため、通常はページの LCP 要素が含まれていません。ただし、特にモバイル デバイスでは、この問題が発生することがあります。モバイル デバイスでは、通常、Cookie に関する通知が画面の大部分を占めます。これは通常、Cookie に関する通知に大きなテキスト ブロックが含まれている場合に発生します(テキスト ブロックも LCP 要素になります)。

  • Interaction to Next Paint(INP): 通常、Cookie に関する通知は承認されるとサードパーティ スクリプトを大量に追加するため、INP が高くなる原因となることがあります。多くの場合、主な問題は [承認] 操作を行うことです。これにより、サードパーティ スクリプトを一度に追加するために多くの処理が発生します。これを軽減する方法については、ベスト プラクティスのセクションをご覧ください。

  • Cumulative Layout Shift(CLS): Cookie 同意通知は、レイアウト移動の非常に一般的な原因です。

一般的に、サードパーティ プロバイダの Cookie に関する通知は、自社で作成した Cookie に関する通知よりもパフォーマンスに大きな影響を与えます。これは Cookie に関する通知に固有の問題ではなく、サードパーティ スクリプトの一般的な性質によるものです。

ベスト プラクティス

このセクションのベスト プラクティスでは、サードパーティ Cookie に関する通知に焦点を当てます。これらのベスト プラクティスの一部は、ファースト パーティ Cookie の通知にも適用されますが、すべてが適用されるわけではありません。

Cookie 通知による INP への影響について

前述のように、[同意] ボタンは、クリック時に大量の処理が行われるため、INP の問題の原因となることがよくあります。

Chrome チームは、同意管理プラットフォーム(CMP)と連携して、[同意] をクリックした後に処理を中断し、ブラウザが次のペイントでその同意を迅速に認識できるようにしました。例として、こちらの PubTech のケーススタディをご覧ください。

ご利用の CMP がこれに影響を受けている場合は、埋め込み先のサイトで INP の問題を回避できるかどうか、CMP の提供元にお問い合わせください。イージング戦術に関するガイダンスについては、長時間タスクを最適化するをご覧ください。

Cookie に関する通知スクリプトは非同期で読み込む必要があります。これを行うには、スクリプトタグに async 属性を追加します。

<script src="https://example.com/script.js" async>

非同期ではないスクリプトは、ブラウザ パーサーをブロックします。これにより、ページの読み込みと LCP が遅延します。詳細については、サードパーティの JavaScript を効率的に読み込むをご覧ください。

Cookie に関する通知のスクリプトは、タグ マネージャーやその他のスクリプトによって読み込まれるのではなく、メイン ドキュメントの HTML にスクリプトタグを配置して「直接」読み込む必要があります。タグ マネージャーまたはセカンダリ スクリプトを使用して Cookie 通知スクリプトを挿入すると、Cookie 通知スクリプトの読み込みが遅れます。ブラウザのルックアヘッド パーサーからスクリプトが見えなくなり、JavaScript の実行前にスクリプトが読み込まれなくなります。

サードパーティの場所から Cookie に関する通知スクリプトを読み込むすべてのサイトは、dns-prefetch または preconnect のリソースヒントを使用して、Cookie に関する通知リソースをホストするオリジンとの早期接続を確立する必要があります。詳細については、ネットワーク接続を早期に確立してページの表示速度を改善するをご覧ください。

<link rel="preconnect" href="https://cdn.example.com/">

一部のサイトでは、preload リソース ヒントを使用して Cookie に関する通知スクリプトを読み込むと便利です。preload リソース ヒントは、指定されたリソースの早期リクエストを開始するようブラウザに通知します。

<link rel="preload" href="https://www.example.com/cookie-script.js">

preload は、ページあたりの重要なリソースの取得に限定して使用すると最も効果的です。したがって、Cookie に関する通知スクリプトをプリロードするメリットは、状況によって異なります。

サードパーティ Cookie に関する通知の外観をカスタマイズすると、パフォーマンスのコストが増加する可能性があります。たとえば、サードパーティ Cookie に関する通知では、ページの他の場所で使用されているリソース(ウェブフォントなど)を再利用できない場合があります。また、サードパーティ Cookie に関する通知は、長いリクエスト チェーンの最後にスタイル設定が読み込まれる傾向があります。想定外の事態を回避するには、Cookie に関する通知が読み込まれ、スタイル設定と関連リソースが適用される仕組みを把握してください。

レイアウト シフトを回避する

クッキーに関する通知に関連する、最も一般的なレイアウト シフトの問題をいくつかご紹介します。

  • 画面上部の Cookie に関する通知: 画面上部の Cookie に関する通知は、レイアウト シフトの非常に一般的な原因です。周囲のページがすでにレンダリングされた後に Cookie に関する通知が DOM に挿入されると、その下のページ要素がページのさらに下に押しやられます。このタイプのレイアウト シフトは、同意を求める通知用に DOM にスペースを予約することで回避できます。これが現実的な解決策でない場合は(Cookie に関するお知らせのサイズが地域によって異なる場合など)、固定フッターまたはモーダルを使用して Cookie に関するお知らせを表示することを検討してください。どちらの方法でも、Cookie に関するお知らせはページの残りの部分の上に「オーバーレイ」として表示されるため、読み込み時にコンテンツがずれることはありません。
  • アニメーション: 多くの Cookie に関する通知ではアニメーションが使用されています。たとえば、Cookie に関する通知を「スライドイン」させるのは一般的な設計パターンです。これらのエフェクトの実装方法によっては、レイアウト シフトが発生する可能性があります。詳細については、レイアウト シフトのデバッグをご覧ください。
  • フォント: フォントが遅れて読み込まれると、レンダリングがブロックされたり、レイアウトがずれたりする可能性があります。この現象は、接続速度が遅い場合に顕著になります。

高度な読み込みの最適化

これらの手法は実装に手間がかかりますが、Cookie に関する通知スクリプトの読み込みをさらに最適化できます。

パフォーマンスの測定

Cookie に関する通知はパフォーマンス測定に影響する可能性があります。このセクションでは、これらの影響とその軽減方法について説明します。

リアルユーザー モニタリング(RUM)

一部の分析ツールと RUM ツールは、Cookie を使用してパフォーマンス データを収集します。ユーザーが Cookie の使用を拒否した場合、これらのツールはパフォーマンス データを取得できません。

サイトはこの現象を認識する必要があります。また、RUM ツールがデータの収集に使用するメカニズムを理解することも価値があります。ただし、一般的なサイトでは、データの偏りの方向と大きさを考えると、この差異は心配の種にはならないと考えられます。Cookie の使用は、パフォーマンス測定の技術的な要件ではありません。Cookie を使用しないライブラリの例として、web-vitals JavaScript ライブラリがあります。

サイトが Cookie を使用してパフォーマンス データを収集する方法(Cookie に個人情報が含まれているかどうか)や、該当する法律によっては、パフォーマンス測定のために Cookie を使用する場合、サイト上で他の目的(広告 Cookie など)に使用される Cookie と同じ法的要件が適用されないことがあります。一部のサイトでは、ユーザーの同意を求める際に、パフォーマンス Cookie を Cookie の別のカテゴリとして分類しています。

合成モニタリング

カスタム設定を行わないと、ほとんどのシミュレート ツール(Lighthouse や WebPageTest など)では、Cookie 同意通知に応答していない初回ユーザーのエクスペリエンスのみが測定されます。ただし、パフォーマンス データを収集する際には、キャッシュ状態の変化(初回アクセスと再アクセスなど)だけでなく、Cookie の許可状態の変化(許可、拒否、未応答)も考慮する必要があります。

以降のセクションでは、パフォーマンス測定ワークフローに Cookie に関する通知を組み込む際に役立つ WebPageTest と Lighthouse の設定について説明します。ただし、Cookie と Cookie に関する通知は、ラボ環境で完全にシミュレートするのが難しい多くの要因の 1 つにすぎません。そのため、合成ツールではなく RUM データをパフォーマンス ベンチマークの基盤にすることが重要です。

スクリプトを使用する

スクリプトを使用して、トレース収集中に WebPageTest が Cookie 同意バナーを「クリック」するように設定できます。

[スクリプト] タブに移動してスクリプトを追加します。次のスクリプトは、テスト対象の URL に移動し、id=cookieButton を含む DOM 要素をクリックします。

combineSteps
navigate    %URL%
clickAndWait    id=cookieButton

このスクリプトを使用する場合は、次の点に注意してください。

  • combineSteps は、続くスクリプト ステップの結果を 1 つのトレースおよび測定セットに「結合」するよう WebPageTest に指示します。combineSteps なしでこのスクリプトを実行することも便利です。個別のトレースを作成すると、Cookie の同意前後にリソースが読み込まれたかどうかを簡単に確認できます。
  • %URL% は、テスト対象の URL を指す WebPageTest の規則です。
  • clickAndWait は、attribute=value で指定された要素をクリックし、その後のブラウザ アクティビティが完了するまで待つように WebPageTest に指示します。形式は clickAndWait attribute=Value です。

このスクリプトが正しく設定されている場合、WebPageTest で撮影されたスクリーンショットに Cookie に関する通知は表示されません(Cookie に関する通知は承認されています)。

WebPageTest スクリプトについて詳しくは、WebPageTest のドキュメントをご覧ください。

Cookie を設定する

クッキーを設定して WebPageTest を実行するには、[詳細] タブに移動し、[カスタム ヘッダー] フィールドにクッキー ヘッダーを追加します。

WebPageTest の [カスタム ヘッダー] フィールド

テストの場所を変更する

WebPageTest で使用するテストロケーションを変更するには、[高度なテスト] タブにある [テストロケーション] プルダウンをクリックします。

WebPageTest の [Test Location] プルダウン

Lighthouse の実行時に Cookie を設定すると、Lighthouse によるテスト用にページを特定の状態にするためのメカニズムとして使用できます。Lighthouse の Cookie の動作は、コンテキスト(DevTools、CLI、PageSpeed Insights)によって若干異なります。

DevTools

Lighthouse を DevTools から実行しても、Cookie は削除されません。ただし、他の種類のストレージはデフォルトで消去されます。この動作は、[Lighthouse] 設定パネルの [Clear Storage] オプションを使用して変更できます。

Lighthouse の [ストレージを消去] オプションがハイライト表示されたスクリーンショット

CLI

CLI から Lighthouse を実行すると、新しい Chrome インスタンスが使用されるため、デフォルトでは Cookie は設定されません。特定の Cookie セットを使用して CLI から Lighthouse を実行するには、次のコマンドを使用します。

lighthouse <url> --extra-headers "{\"Cookie\":\"cookie1=abc; cookie2=def; \_id=foo\"}"

Lighthouse CLI でカスタム リクエスト ヘッダーを設定する方法については、認証済みページで Lighthouse を実行するをご覧ください。

PageSpeed Insights

PageSpeed Insights から Lighthouse を実行すると、新しい Chrome インスタンスが使用され、Cookie は設定されません。PageSeed Insights では、特定の Cookie を設定するように構成することはできません。

ユーザー エクスペリエンス

さまざまな Cookie 同意通知のユーザー エクスペリエンス(UX)は、主に 2 つの決定の結果です。ページ内の Cookie 通知の場所と、ユーザーがサイトの Cookie の使用をカスタマイズできる範囲です。このセクションでは、これらの 2 つの決定に適用できるアプローチについて説明します。

Cookie に関する通知のデザインを検討する際は、次の点を考慮してください。

  • UX: これは優れたユーザー エクスペリエンスですか?この特定のデザインは、既存のページ要素とユーザーフローにどのように影響しますか?
  • ビジネス: サイトの Cookie 戦略はどのようなものですか?Cookie に関する通知の目標は何ですか?
  • 法律: 法的要件を満たしていますか?
  • エンジニアリング: 実装とメンテナンスにどれくらいの作業量がかかりますか?変更はどの程度難しいですか?

プレースメント

Cookie に関する通知は、ヘッダー、インライン要素、フッターとして表示できます。また、モーダルを使用してページ コンテンツの上に表示したり、インタースティシャルとして配信したりすることもできます。

Cookie に関する通知のさまざまな配置オプションの例を示す図

通常、Cookie に関する通知はヘッダーまたはフッターに配置されます。これらの 2 つのオプションのうち、通常はフッター プレースメントが優先されます。フッター プレースメントは目立たず、バナー広告や通知と競合せず、通常は CLS を引き起こさないためです。また、プライバシー ポリシーや利用規約を掲載する場所としても一般的です。

インライン Cookie に関する通知も選択肢の一つですが、既存のユーザー インターフェースに統合するのが難しいため、あまり一般的ではありません。

モーダル

モーダルは、ページ コンテンツの上に表示される Cookie 同意通知です。モーダルの外観と動作は、サイズによって大きく異なります。

レイアウトのずれを引き起こさない方法で Cookie に関する通知を実装するのが難しい場合は、画面の一部を占有する小さなモーダルを使用することをおすすめします。

一方、ページのコンテンツの大部分を隠す大きなモーダルは慎重に使用する必要があります。特に小規模なサイトでは、コンテンツが不明瞭な見慣れないサイトの Cookie に関する通知をユーザーが承認せずに離脱する可能性があります。必ずしも同義の概念ではありませんが、全画面 Cookie 同意モーダルの使用を検討している場合は、Cookie ウォールに関する法律に注意する必要があります。

構成の柔軟性

Cookie に関する通知のインターフェースでは、ユーザーが許可する Cookie をさまざまなレベルで管理できます。

構成不可

これらの通知形式の Cookie バナーには、Cookie のオプトアウトを直接操作できる UX コントロールがユーザーに表示されません。通常、サイトの Cookie ポリシーへのリンクが含まれており、ウェブブラウザを使用して Cookie を管理する方法に関する情報がユーザーに提供されます。通常、これらの通知には [閉じる] ボタンと [承認] ボタンがあります。

Cookie を構成できない Cookie に関する通知の例を示す図

構成の柔軟性

これらの Cookie に関する通知では、ユーザーは Cookie を拒否できますが、より細かい制御はサポートされていません。Cookie に関する通知にこの方法を使用することはあまり一般的ではありません。

Cookie の設定が可能な Cookie に関する通知の例を示す図

完全な構成

これらの Cookie に関する通知により、ユーザーは許可する Cookie の使用をよりきめ細かく設定できるようになります。

Cookie を完全に設定できる Cookie に関する通知の例を示す図

  • UX: Cookie の使用を構成するためのコントロールは、通常、ユーザーが最初の Cookie 同意通知に応答したときに起動する別のモーダルを使用して表示されます。ただし、スペースに余裕がある場合は、一部のサイトでは、最初の Cookie 同意通知内にこれらのコントロールをインラインで表示します。

  • 粒度: Cookie の構成方法として最も一般的なのは、Cookie の「カテゴリ」ごとにユーザーが Cookie をオプトインできるようにすることです。一般的な Cookie カテゴリには、機能 Cookie、ターゲティング Cookie、ソーシャル メディア Cookie などがあります。

    ただし、一部のサイトでは、さらに一歩進んで、ユーザーが Cookie ごとにオプトインできるようにしています。ユーザーにより具体的なコントロールを提供するには、Cookie カテゴリ(「広告」など)を特定のユースケースに分割することもできます。たとえば、「基本広告」と「パーソナライズド広告」を個別にオプトインできるようにします。

Cookie を完全に設定できる Cookie に関する通知の例を示す図