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

Cookie の通知を最適化して、パフォーマンスとユーザビリティを向上させます。

Katie Hempenius
Katie Hempenius
X
Barry Pollard

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

パフォーマンス

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

次に、Cookie の通知が Web Vitals の指標にどのように影響するかを示します。

  • Largest Contentful Paint（LCP）: Cookie 使用の同意確認はごく小規模であるため、通常はページの LCP 要素は含まれません。しかし、これは特にモバイル デバイスでは発生する可能性があります。モバイル デバイスでは、Cookie の通知が画面の大部分を占めるのが一般的です。これは通常、Cookie の通知に大きいテキスト ブロックが含まれている場合に発生します（テキスト ブロックが LCP 要素である場合もあります）。

  • Next Paint（INP）とのやり取り: Cookie の通知は、受け入れられるときに多くのサードパーティ スクリプトを追加するのが一般的であるため、INP が高くなることがよくあります。多くの場合、主な問題は Accept 操作を行うことです。このような第三者スクリプトを一度に追加するには、多くの処理が必要となります。この問題を軽減する方法については、以下の「おすすめの方法」セクションをご覧ください。

  • Cumulative Layout Shift（CLS）: Cookie 使用の同意確認は、レイアウト シフトが発生する一般的な原因となります。

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

ベスト プラクティス

このセクションのベスト プラクティスは、サードパーティ Cookie に関する通知に重点を置いています。ベスト プラクティスの一部は（すべてではありません）、ファーストパーティの Cookie の通知にも適用できます。

Cookie の通知が INP に及ぼす影響を理解する

前述のように、[Accept] ボタンをクリックした際に大量の処理が発生するため、INP の問題の主な原因となることがよくあります。

Chrome チームは、さまざまな同意管理プラットフォーム（CMP）と協力して、[Accept] をクリックした後に、ブラウザが次のペインですぐに同意を確認できるようにしました。例として、PubTech の事例紹介をご覧ください。

ご利用の CMP がこの影響を受ける場合は、CMP に連絡して、埋め込むサイトに関して同様に INP の問題を回避できるかどうかを確認してください。収益を生み出す戦術のガイダンスについては、長時間タスクの最適化に関する記事をご覧ください。

Cookie 通知スクリプトは非同期で読み込む必要があります。そのためには、スクリプトタグに async 属性を追加します。

<script src="https://cookie-notice.com/script.js" async>

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

Cookie 通知スクリプトは、タグ マネージャーなどのスクリプトで読み込むのではなく、メイン ドキュメントの HTML にスクリプトタグを配置して、「直接」読み込む必要があります。タグ マネージャーまたは予備のスクリプトを使用して Cookie 通知スクリプトを挿入すると、Cookie 通知スクリプトの読み込みが遅れます。ブラウザの先読みパーサーからスクリプトが不明瞭化され、JavaScript の実行前にスクリプトが読み込まれなくなります。

サードパーティのロケーションから Cookie 通知スクリプトを読み込むすべてのサイトでは、dns-prefetch または preconnect リソースヒントを使用して、Cookie 通知リソースをホストするオリジンとの早期接続を確立する必要があります。詳しくは、認識されるページ速度を上げるために、早期にネットワーク接続を確立するをご覧ください。

<link rel="preconnect" href="https://cdn.cookie-notice.com/">

サイトによっては、preload リソースヒントを使用して Cookie 通知スクリプトを読み込むとメリットが得られる場合があります。preload リソースヒントは、指定されたリソースに対する早期リクエストを開始するようにブラウザに通知します。

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

preload は、ページごとに取得する主なリソースが 2 ～ 3 個に限られる場合に最も効果的です。そのため、Cookie 通知スクリプトをプリロードする有用性は、状況に応じて異なります。

サードパーティ Cookie の通知のデザインをカスタマイズすると、追加のパフォーマンス コストが発生することがあります。たとえば、サードパーティ Cookie の通知では、同じページの他の場所で使用されているリソース（ウェブフォントなど）を再利用できない場合もあります。また、サードパーティ Cookie の通知では、長いリクエスト チェーンの最後にスタイルが読み込まれる傾向があります。予期せぬ事態を避けるため、Cookie の通知がどのようにスタイルと関連リソースの読み込みと適用を行っているかに注意してください。

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

Cookie の通知に関連するレイアウト シフトの問題として、最も一般的なものを以下に示します。

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

高度な読み込み最適化

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

パフォーマンスの測定

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

実際のユーザー モニタリング（RUM）

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

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

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

合成モニタリング

カスタム設定を行わないと、ほとんどの合成ツール（Lighthouse や WebPageTest など）で測定されるのは、Cookie 使用の同意が得られなかったユーザーのうち、初めて訪れたユーザーに関するエクスペリエンスのみとなります。ただし、パフォーマンス データを収集する際は、キャッシュの状態のばらつき（初回訪問と再訪問など）だけでなく、Cookie 受け入れ状態（承諾、拒否、未応答）のばらつきも考慮する必要があります。

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

スクリプトを使用する

スクリプトを使用して、トレースの収集中に WebPageTest で Cookie 使用の同意モードのバナーを「クリック」させることができます。

[Script] タブに移動してスクリプトを追加します。次のスクリプトは、テストする 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 を設定する

Cookie セットを使用して WebPageTest を実行するには、[詳細] タブに移動し、[カスタム ヘッダー] フィールドに Cookie ヘッダーを追加します。

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

テストの場所を変更する

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

WebPageTest の [Test Location] プルダウン

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

DevTools

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

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

CLI

CLI から Lighthouse を実行すると、新しい Chrome インスタンスが使用されるため、デフォルトでは Cookie は設定されません。CLI から特定の Cookie を設定して 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）は主に、ページ内での Cookie 通知の配置場所と、ユーザーがサイトで Cookie の使用をカスタマイズできる範囲の 2 つの決定によって変わります。このセクションでは、この 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 設定が可能な chookie 通知の例を示す図

  • UX: Cookie の使用方法を設定するコントロールは通常、ユーザーが最初の Cookie 同意通知に応答したときに起動される個別のモーダルを使用して表示されます。ただし、スペースが許せば、一部のサイトでは Cookie 使用の同意確認の最初の通知内にこれらのコントロールがインライン表示されます。

  • 粒度: Cookie を柔軟に設定する方法として最も一般的な方法は、ユーザーが Cookie の「カテゴリ」に基づいて Cookie を有効にできるようにすることです。Cookie の一般的なカテゴリの例としては、機能 Cookie、ターゲティング Cookie、ソーシャル メディア Cookie などがあります。

    ただし、一部のサイトでは、さらに一歩進んで、ユーザーが Cookie 単位でオプトインできるようにする場合もあります。また、「広告」などの Cookie カテゴリを特定のユースケースに分けて、ユーザーが「基本的な広告」と「パーソナライズド広告」に個別にオプトインできるようにするなど、より具体的な制御をユーザーに提供する方法もあります。

完全な Cookie 設定が可能な Cookie 通知の例を示す図