パーソナライゼーションやA/Bテストでサイトは遅くなる？ ページ速度への実際の影響

パーソナライゼーションやA/Bテストの導入に対して最もよく聞く反対意見は速度です。「スクリプトがまた増えたら読み込みが遅くなり、Core Web Vitalsが台無しになるのでは？」というものです。もっともな懸念です——作りの悪いテスト用スクリプトは実際にページを遅くします。しかし最新の非同期スクリプトなら、実際のコストはわずかです。およそ~250ミリ秒の追加読み込みが、ページをブロックせずに発生するだけです——Google PageSpeed Insightsを導入前後で実行しても、通常スコアに意味のある変化は見られません。

その理由と——実際にページを遅くする要因を解説するので、それを避けましょう。

実際のコスト：非同期読み込みで約250ミリ秒

鍵となる言葉は非同期です。Personyzeのスクリプト（ダッシュボードでのデフォルトかつ推奨の設定）は、レンダリングを止めるのではなく、ページのほかの部分と並行して読み込まれます。ブラウザは通常どおりのタイミングでコンテンツを描画し、パーソナライゼーションのレイヤーはそれと並行して処理され、平均でおよそ4分の1秒を追加します——その大半は、ページがすでに使える状態のため訪問者には感じられません。

対照的に、同期型でレンダリングをブロックするスクリプトでは、ブラウザは何かを表示する前に処理を止めて待たなければなりません。「テストツールでサイトが遅くなる」という評判はここから生まれています——そして、まさにそれを回避するのが非同期のアプローチです。

PageSpeed Insightsのスコアがほとんど動かない理由

PageSpeed Insightsとその基盤であるLighthouseは、いくつかのレンダリング指標を評価します。Largest Contentful Paint（LCP）、Interaction to Next Paint（INP）、Cumulative Layout Shift（CLS）、Total Blocking Time（TBT）です。重要なタイミングでメインスレッドをブロックせず、レイアウトもずらさない非同期スクリプトは、これらの数値をほとんど動かしません——そのため導入前後のテストでも、差は通常ごくわずかです。

影響が出るとすれば、それはすべて実装の問題です。重いスクリプトや同期スクリプト、バリエーションが読み込まれるまでページを隠す不適切なちらつき防止スニペット、コンテンツが突然表示されることによるレイアウトのずれ、メインスレッドの長いタスクなどです。いずれも修正可能なミスであり——パーソナライゼーションに本来伴うコストではありません。

でも、追加のコンテンツを読み込んでいるのでは？それは問題にならないのですか？

はい——パーソナライゼーションや レコメンドはコンテンツを追加します。カスタマイズされたブロック、レコメンドウィジェット、画像などです。バイト数もリクエスト数も増えます。それでも悪影響を防げる理由は3つあります。

• コンテンツは非同期で、クリティカルレンダリングパスの後に読み込まれるため、最初の描画を遅らせません。
• その多くはスクロールしないと見えない位置に配置されるか段階的に表示されるため、ユーザーが実際に体感する指標に影響しません。
• 画像やウィジェットは遅延読み込みと最適化ができるため、追加コンテンツは最初にまとめてではなく、必要なタイミングで届きます。

追加のコンテンツがあることと、ページが遅いことは同じではありません。適切に配信すれば、高まる関連性の価値はわずかな重さをはるかに上回り——その重さはツール上でもほとんど目立ちません。

実際にページを遅くするもの（と回避方法）

• 同期的でレンダリングをブロックするスクリプト。非同期を使いましょう——Personyzeのデフォルトです。
• ページ全体を長時間隠すちらつき防止。全体を真っ暗にするのではなく、短く範囲を絞りましょう。
• レイアウトのずれ。パーソナライズされたブロックの表示領域を確保し、コンテンツが跳ねないようにします（CLS）。
• 重く最適化されていない画像をパーソナライズされたブロックに使っている。圧縮し、適切なサイズにし、遅延読み込みしましょう。
• 多すぎるサードパーティスクリプトが積み重なっている。本当に必要なものを見直し、削りましょう。
• すべてをクライアント側で処理する。重い処理は、可能な限りサーバー側やエッジに移しましょう。

正しく測定する方法

代表的なページでPageSpeed InsightsまたはLighthouseを導入前後に実行し、見出しの総合スコアだけでなく、LCP、INP、CLS、TBTを確認しましょう。さらに良いのは、フィールドデータ（Chrome UX Reportやアナリティクスなどの実ユーザーデータ）を確認することです。ラボのスコアは計測のたびに変動するからです。最も重要なページ——トラフィックの多いテンプレート——をテストし、パーソナライゼーションにもほかのスクリプトと同じ基準を求めましょう。

Personyzeが速さを保つ仕組み

Personyzeは、クリティカルパスに入り込まないように設計されています。スクリプトはデフォルトで非同期（ダッシュボードの推奨設定）で、パーソナライゼーションはリダイレクトではなく同じURL上でその場で適用され、レコメンドウィジェットは遅延読み込みでき、ちらつき防止は範囲を絞っているためページ全体を隠すことはありません。その結果が上記のプロファイルです。追加の読み込みは約250ミリ秒で、PageSpeedへの意味のある影響はありません——速度を犠牲にせず関連性を高められます。

ここでは速度と検索順位は表裏一体です。テストとパーソナライゼーションがクロール、インデックス、ランキングシグナルとしてのCore Web Vitalsにどう影響するかについては、 A/BテストやパーソナライゼーションはSEOに悪影響を与えるのか？をご覧ください

速いページとパーソナライズされた体験は両立できる

読み込みの速いサイトか、パーソナライズされたサイトか、どちらかを選ぶ必要はありません。非同期スクリプトといくつかの賢明な習慣があれば、パーソナライゼーションとA/Bテストは、訪問者が実感できる関連性をもたらし、体感できる遅さはもたらしません。デモを予約して実際の動作をご確認いただくか、 プランと料金をご覧ください.

パーソナライゼーション、A/Bテスト、ページ速度：よくある質問

パーソナライゼーションでWebサイトは遅くなりますか？

非同期スクリプトで実装すれば、ごくわずかです。Personyzeの非同期スクリプトは平均で約250ミリ秒を追加しますが、ページをブロックせずに読み込まれ、PageSpeed Insightsのスコアにも通常は意味のある変化は見られません。

A/Bテストはページ速度に悪影響を与えますか？

テスト用スクリプトが同期的だったり重かったりする場合や、ちらつき防止でページを長く隠す場合は、影響が出ることがあります。軽量な非同期スクリプトなら、読み込み時間やCore Web Vitalsへの影響は最小限です。

Personyzeのスクリプトは読み込み時間をどれくらい増やしますか？

平均でおよそ250ミリ秒です。非同期で読み込まれるため、ページのレンダリングをブロックしません。その時間の大半は、ページがすでに使える状態のためユーザーには見えません。

パーソナライゼーションでPageSpeedやLighthouseのスコアは下がりますか？

通常、意味のあるほどは下がりません。LighthouseはLCP、INP、CLS、TBTといった指標を測定しますが、メインスレッドをブロックせずレイアウトもずらさない非同期スクリプトは、これらをほとんど動かしません。目に見える低下があれば、ほぼ必ず同期スクリプト、ちらつき対策、レイアウトのずれといった、修正可能な原因があります。

パーソナライズされた追加コンテンツを読み込むとページは遅くなりますか？

適切に配信されていれば遅くなりません。パーソナライズされたブロックやレコメンドは非同期で読み込まれ、スクロールしないと見えない位置に配置されることも多く、画像やウィジェットは遅延読み込みと最適化ができます。そのため、追加コンテンツが最初の描画を遅らせることはありません。

パーソナライゼーションとA/Bテストを高速に保つには？

非同期スクリプトを使い、ちらつき防止は短く抑え、レイアウトのずれを防ぐために表示領域を確保し、画像は遅延読み込みと最適化を行い、サードパーティスクリプトの重なりを減らし、重い処理は可能な限りサーバー側に移し、PageSpeed Insightsと実ユーザーのフィールドデータで導入前後を測定しましょう。

関連記事

• A/BテストやパーソナライゼーションはSEOに悪影響を与えるのか？——クロール可能性、クローキング、検索順位。
• オーディエンス別A/Bテスト——セグメントごとに体験をテスト。
• ウェブサイトパーソナライゼーション——プラットフォームの概要。