Cookie の通知を最適化して、パフォーマンスとユーザビリティを高める。
この記事では、Cookie に関する通知がパフォーマンス、パフォーマンス測定、ユーザー エクスペリエンスにどのように影響するかについて説明します。
パフォーマンス
Cookie の通知は、通常はページの読み込みプロセスの早い段階で読み込まれ、すべてのユーザーに表示され、広告や他のページ コンテンツの読み込みに影響する可能性があるため、ページのパフォーマンスに大きな影響を与える可能性があります。
Cookie の通知がウェブに関する指標の指標に与える影響は次のとおりです。
Largest Contentful Paint(LCP): ほとんどの Cookie 使用の同意通知は非常に小さいため、通常はページの LCP 要素は含まれません。ただし、特にモバイル デバイスではこの状況が発生することがあります。モバイル デバイスでは、Cookie の通知が画面の大部分を占めるのが一般的です。これは通常、Cookie の通知に大きなテキスト ブロックが含まれている場合に発生します(テキスト ブロックを LCP 要素にすることもできます)。
First Input Delay(FID): 一般に、Cookie 使用の同意ソリューション自体が FID に及ぼす影響は最小限に抑えられます。Cookie 使用の同意は JavaScript の実行をほとんど必要としません。ただし、こうした Cookie によって実現される技術、すなわち広告スクリプトやトラッキング スクリプトは、ページのインタラクティビティに大きな影響を与える可能性があります。これらのスクリプトを Cookie が受け入れられるまで遅らせることは、初回入力遅延(FID)を短縮する手法として役立ちます。
Cumulative Layout Shift(CLS): Cookie 使用の同意通知は、レイアウト シフトの非常に一般的な原因です。
一般的に、サードパーティ プロバイダからの Cookie 通知は、独自に作成する Cookie 通知よりもパフォーマンスに大きな影響を与えることが予想されます。これは、Cookie に関する通知に固有の問題ではなく、サードパーティ スクリプトの一般的な性質によるものです。
ベスト プラクティス
このセクションでは、サードパーティ Cookie の通知に焦点を当てて説明します。ここで紹介するおすすめの方法の一部は、ファーストパーティ Cookie の通知にも適用できます。
Cookie 通知スクリプトを非同期で読み込む
Cookie 通知スクリプトは非同期的に読み込む必要があります。そのためには、スクリプトタグに async
属性を追加します。
<script src="https://cookie-notice.com/script.js" async>
非同期でないスクリプトは、ブラウザ パーサーをブロックします。これにより、ページの読み込みと LCP が遅延します。詳しくは、サードパーティの JavaScript を効率的に読み込むをご覧ください。
Cookie に関する通知のスクリプトを直接読み込む
Cookie 通知スクリプトは、タグ マネージャーや他のスクリプトで読み込むのではなく、メイン ドキュメントの HTML にスクリプトタグを配置して「直接」読み込む必要があります。タグ マネージャーまたは第 2 のスクリプトを使用して Cookie 通知スクリプトを挿入すると、Cookie 通知スクリプトの読み込みが遅れます。スクリプトはブラウザの先読みパーサーで隠され、JavaScript の実行前にスクリプトが読み込まれなくなります。
Cookie 通知元と早期に接続を確立する
サードパーティの場所から Cookie 通知スクリプトを読み込むすべてのサイトでは、dns-prefetch
または preconnect
リソースヒントを使用して、Cookie 通知リソースをホストするオリジンと早期接続を確立する必要があります。詳細については、ネットワーク接続を確立して認識されるページ速度を改善するをご覧ください。
<link rel="preconnect" href="https://cdn.cookie-notice.com/">
必要に応じて Cookie の通知をプリロードする
一部のサイトでは、Cookie 通知スクリプトの読み込みに preload
リソースヒントを使用すると便利です。preload
リソースヒントは、指定されたリソースの早期リクエストを開始するようにブラウザに通知します。
<link rel="preload" href="https://www.cookie-notice.com/cookie-script.js">
preload
は、ページごとにいくつかのキーリソースを取得するように使用が制限されている場合、非常に効果的です。したがって、Cookie 通知スクリプトをプリロードする利点は状況によって異なります。
Cookie 通知のスタイルを設定する際のパフォーマンスのトレードオフに注意する
サードパーティ Cookie の通知のデザインをカスタマイズすると、追加のパフォーマンス コストが発生する可能性があります。たとえば、サードパーティ Cookie の通知は、ページの別の場所で使用されている同じリソース(ウェブフォントなど)を常に再利用できるとは限りません。また、サードパーティ Cookie の通知は、長いリクエスト チェーンの最後でスタイルを読み込む傾向があります。予想外の事態を避けるため、Cookie 通知がスタイル設定と関連リソースをどのように読み込んで適用するのかに注意しましょう。
レイアウト シフトを避ける
Cookie の通知に関連する最も一般的なレイアウト シフトの問題は次のとおりです。
- 画面上部での Cookie の通知: 画面上部での Cookie の通知は、レイアウト シフトを引き起こす一般的な原因です。周囲のページがすでにレンダリングされた後で Cookie 通知が DOM に挿入されると、その下にあるページ要素がページの下方にプッシュされます。このタイプのレイアウト シフトは、同意通知用の DOM のスペースを予約することで排除できます。この方法で解決できない場合は、たとえば Cookie 通知のサイズが地域によって異なる場合は、固定フッターやモーダルを使用して Cookie 通知を表示することを検討してください。どちらの方法でも、Cookie 通知はページの他の部分の上に「オーバーレイ」として表示されるため、Cookie 通知によって読み込み時にコンテンツが移動することはありません。
- アニメーション: Cookie の通知の多くはアニメーションを使用しています。たとえば、Cookie の通知は一般的な設計パターンです。これらの効果の実装方法によっては、レイアウトが移動することがあります。詳細については、レイアウト シフトのデバッグをご覧ください。
- フォント: フォントの読み込みが遅れると、レンダリングがブロックされたり、レイアウト シフトが発生したりすることがあります。この現象は、接続速度が遅い場合に顕著です。
高度な読み込み最適化
以下の手法は実装には手間がかかりますが、Cookie 通知スクリプトの読み込みをさらに最適化できます。
- サードパーティの Cookie 通知スクリプトをキャッシュに保存して独自のサーバーから配信することで、こうしたリソースの配信速度を向上させることができます。
- サービス ワーカーを使用すると、Cookie 通知スクリプトなどのサードパーティ スクリプトの取得とキャッシュをより詳細に制御できます。
パフォーマンスの測定
Cookie の通知は、パフォーマンスの測定に影響を与える可能性があります。このセクションでは、これらの影響と、それらを軽減するための手法について説明します。
Real User Monitoring(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 通知をテストする
スクリプト作成
スクリプトを使用すると、トレースの収集中に WebPageTest に Cookie 使用同意バナーを「クリック」させることができます。
[スクリプト] タブに移動してスクリプトを追加します。以下のスクリプトは、テストする URL に移動し、ID が cookieButton
の DOM 要素をクリックします。
combineSteps
navigate %URL%
clickAndWait id=cookieButton
このスクリプトを使用する場合は、次の点に注意してください。
combineSteps
は、WebPageTest に対して、後続のスクリプト ステップの結果を「結合」して、トレースと測定値の 1 つのセットを作成するように指示します。このスクリプトをcombineSteps
を使用せずに実行することもできます。トレースを分けることで、Cookie の受け入れ前と受け入れ後のどちらでリソースが読み込まれたかを簡単に確認できます。%URL%
は、テスト対象の URL を参照する WebPageTest の規則です。clickAndWait
は、attribute=value
で指定された要素をクリックして、後続のブラウザ アクティビティが完了するまで待機するよう WebPageTest に指示します。clickAndWait attribute=Value
の形式に従います。
このスクリプトを正しく設定すると、WebPageTest が撮影したスクリーンショットには Cookie の通知は表示されません(Cookie の通知は受け入れられます)。
WebPageTest のスクリプトについて詳しくは、WebPageTest のドキュメントをご覧ください。
Cookie を設定する
Cookie を設定して WebPageTest を実行するには、[詳細設定] タブに移動し、[カスタム ヘッダー] フィールドに Cookie ヘッダーを追加します。
テストの場所を変更する
WebPageTest で使用するテストの場所を変更するには、[高度なテスト] タブにある [テストの場所] プルダウンをクリックします。
Lighthouse を使用して Cookie の通知をテストする
Lighthouse の実行で Cookie を設定すると、Lighthouse によるテストのために、ページを特定の状態にするメカニズムとして活用できます。Lighthouse の Cookie の動作は、コンテキスト(DevTools、CLI、PageSpeed Insights)によって若干異なります。
DevTools
DevTools から Lighthouse を実行しても、Cookie は消去されません。ただし、他のタイプのストレージはデフォルトでクリアされます。この動作を変更するには、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)は、主に 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 の使用をより詳細に構成できます。
UX: Cookie の使用を設定するコントロールは通常、Cookie 使用への同意に関する最初の通知にユーザーが応答したときに別のモーダルを使用して表示されます。ただし、スペースに余裕がある場合は、Cookie 使用への同意に関する最初の通知内に、これらのコントロールがインラインで表示される場合もあります。
粒度: Cookie を構成する最も一般的な方法は、ユーザーが Cookie の「カテゴリ」ごとに Cookie を有効にできるようにすることです。一般的な Cookie のカテゴリには、機能 Cookie、ターゲティング Cookie、ソーシャル メディア Cookie などがあります。
ただし、一部のサイトでは、さらに一歩進め、Cookie ごとにオプトインできるようにしています。または、「広告」などの Cookie カテゴリを具体的なユースケースに分ける方法もあります。たとえば、「基本広告」と「パーソナライズド広告」を別々にオプトインできるように、ユーザーを細かく制御します。