CLS A/B testing

CLS(Cumulative Layout Shift)は、Googleが定義する3つのCore Web Vitalsの1つであり、ウェブページの視覚的な安定性、つまり読み込み中に要素が予期せず移動する度合いを測定します。
A/B testingにおいて、CLSはよくある落とし穴であり、たとえテストしているバリエーションの内容自体が優れていても、テスト結果を歪めたり、ユーザー体験を損なったりする可能性があります。

🎯 なぜA/B testingにおいて重要なのか

A/B testingは、ユーザー行動(クリック、コンバージョンなど)に対する特定の変更の影響を切り分けることを目的としています。しかし、バリエーションが視覚的なズレ(例:ボタンが突然動く、画像がコンテンツを下に押し出すなど)を引き起こすと、次のような問題が生じます。

ユーザーの操作が妨げられる:クリックミス、悪い印象、注意の逸脱などが発生します。
テスト結果が歪められる:パフォーマンスの低下はテスト対象のコンテンツ自体が原因ではなく、技術的な実装の質に起因します。

💡 CLSが高すぎると、一般的なKPIには表れないものの、原因不明のままCVRに悪影響を及ぼします。

🧪 A/B testingがCLSを引き起こす仕組み

バリエーションが意図せずCLSを引き起こすよくあるシナリオは以下の通りです。

スペースを確保せずに画像やHTMLブロックを追加する:読み込み後、コンテンツがページの他の部分を「押し出して」しまいます。
処理の遅いタグマネージャー経由でA/B testingスクリプトを読み込む(<head>への直接実装ではなく)。
スペースを確保せずにメッセージやプロモーションバナーをコンテンツの上に動的に挿入する。
プリロードなしでフォントやフォントの太さを変更することで、テキストの「ズレ」が発生します。
制御されていないCSSアニメーションを使用する(例:スライドやフェードインの効果がページを再描画してしまう)。

📌 A/B testingにおける直接的なリスク:

モバイルでのコンバージョン損失(視覚的なズレが増幅されるため)。
統計的に有意だが誤った結果。
明確な理由のないCVRの低下。
誤った理由でバリエーションを棄却してしまう。

✅ CLSへの影響を避けるためのCRoのベストプラクティス：

バリエーションに追加する各ブロックに対してスペースを事前に確保する（例：CSSのaspect-ratioやプレースホルダー用クラスで画像の高さを確保する）、
JavaScriptによるコンテンツの遅延挿入を避ける（サーバー側での挿入、またはクライアント側でもできるだけ早いタイミングでの挿入を優先する）、
公開前にLighthouseやPageSpeed Insightsですべてのバリエーションをテストし、CLSスコアを確認する、
フリッカリングを防ぐため、A/B testのスクリプトをコード内（head）に直接組み込む、
Web Vitals Extension、SpeedCurve、Datadog RUM、BigQuery + GA4などのツールを使って、各バリエーションのCore Web Vitalsをリアルタイムで計測する。