【ITニュース解説】A/B Testing UI Variations with Zero Performance Penalty & Zero Layout Shifts

ウェブサイトやアプリケーションをより良くしていくために、「A/Bテスト」という手法が広く使われている。これは、ウェブサイトの特定の要素、例えば見出しの文言やボタンの色、ページ全体のレイアウトなどについて、複数の異なるバージョン（例えばAパターンとBパターン）を用意し、どちらがより多くのユーザーの行動（商品購入や資料請求など）につながるかを実際に試して比較するテストだ。このテストは、「コンバージョン率最適化（CRO）」と呼ばれる、ウェブサイトの訪問者を顧客に変える効率を高めるための重要な取り組みの一つである。

しかし、これまでのA/Bテストの方法にはいくつかの課題があった。多くの場合、OptimizelyやVWO、Google Optimizeといった外部の専門ツールが利用されてきたが、これらのツールはウェブサイトのユーザー体験やパフォーマンスに悪影響を与える可能性があったのだ。

一つ目の課題は、「Flash of Original Content（FOOC）」、つまり「元のコンテンツがちらつく現象」だ。ユーザーがウェブサイトにアクセスすると、まず最初に、まだA/Bテストのスクリプトが適用されていないオリジナルのコンテンツが短時間（記事によると約150ミリ秒）表示される。その後、ウェブサイトの裏側でA/Bテスト用のJavaScriptコードがダウンロードされて実行され、表示されているコンテンツがテスト用のバージョンに切り替わる。この一瞬の切り替わりが、ユーザーにとっては視覚的なちらつきとして感じられ、不快感を与えてしまうことがあった。

二つ目の大きな課題は、「Cumulative Layout Shift（CLS）」、つまり「レイアウトが累積的にずれる現象」だ。これは、ウェブサイトの読み込みが完了した後に、JavaScriptがページの要素を動的に追加したり、既存の要素のサイズを変更したりすることで、既に表示されていたコンテンツの位置が突然ずれてしまうことだ。例えば、後から画像が読み込まれて、その下にあった文章が突然下に移動するような状況だ。このCLSは、ユーザーが意図しない場所をクリックしてしまったり、読んでいる箇所を見失ってしまったりと、ユーザー体験を著しく損なう。さらに、Googleはウェブサイトの品質評価においてCLSスコアを重視しており、CLSスコアが高い（例えば0.25を超えると）ウェブサイトは、検索エンジンのランキングで不利になる可能性がある。

三つ目の課題は、「Bloated Client Bundles」、つまり「クライアントサイドのJavaScriptの肥大化」だ。従来のA/Bテストツールは、その機能を実現するために、ユーザーのブラウザ（クライアントサイド）で動作するJavaScriptのコード（SDKと呼ばれるソフトウェア開発キット）をウェブサイトに挿入する。これらのSDKは、一般的に80KBから150KBものサイズがあり、ウェブサイトのHTMLコードの冒頭（<head>タグ内）に埋め込まれることが多い。このJavaScriptコードは、ページの表示を妨げる「レンダリングブロッキング」となることがあり、結果としてウェブサイト全体の読み込み速度を遅くしてしまう原因となっていた。

これらの問題を解決するために、「Zero-Layout-Shift Edge Experimentation（ゼロレイアウトシフト・エッジ実験）」という新しいアプローチが提唱されている。これは、従来のA/Bテストのようにクライアントサイド（ユーザーのブラウザ）でJavaScriptを使ってウェブサイトのHTML要素（DOM）を操作するのではなく、ウェブサイトのコンテンツがユーザーに届く前の段階、具体的には「CDN（Contents Delivery Network）のエッジ」という場所でA/Bテストの処理を完結させる方法だ。これにより、クライアントサイドのJavaScriptを一切使わずに、0.00 CLS（レイアウトのずれゼロ）と、0ms FOOC Flicker（ちらつきゼロ）を実現することを目指す。

この新しいアプローチの具体的な仕組みを見ていこう。Next.jsのようなウェブ開発フレームワークでは、「Edge Middleware（エッジミドルウェア）」という機能を利用できる。ミドルウェアとは、ユーザーからのウェブサイトへのリクエストがサーバーに到達する前や、サーバーからのレスポンスがユーザーに返される前に、追加の処理を行うことができるプログラムのことだ。エッジミドルウェアは、ユーザーに最も近い場所に配置されたCDNのエッジサーバー上で動作するため、非常に高速に処理が行われる特徴がある。

このエッジミドルウェアを使って、ユーザーをA/Bテストのいずれかのグループに割り振る「Cookie Bucketing（クッキーバケット分け）」を行う。ユーザーがウェブサイトにアクセスすると、ミドルウェアはまず、そのユーザーが以前にどのバリアント（例えば「コントロール」または「バリアントB」）に割り振られたかを示す「Cookie（クッキー）」という小さなデータを持っているかを確認する。もしクッキーがなければ、ミドルウェアはランダムな方法（例：50%の確率でどちらか一方）でユーザーをいずれかのバリアントに割り振り、その情報をクッキーに保存する。これにより、同じユーザーはウェブサイトを再訪しても、常に同じバリアントのコンテンツを見ることになる。

そして、ミドルウェアは割り振られたバリアントに基づいて、ウェブサイトのURLを内部的に「書き換え（URL Rewriting）」る。例えば、ユーザーがウェブサイトのトップページを表す/というパスにアクセスしたとしても、ミドルウェアは内部的に、テスト用のバリアントBのページを表す/variants/hero-bのようなパスにリクエストを書き換えるのだ。ここで重要なのは、このURLの書き換えはユーザーのブラウザのアドレスバーには表示されないということだ。ユーザーは元のURLにアクセスしていると思っているが、サーバーからは内部的に書き換えられたパスに対応するコンテンツが返されることになる。

なぜ、このエッジでのURL書き換えがFOOCやCLSといった問題を完全に排除できるのだろうか。その理由は、ユーザーのリクエストがウェブサイトに到達する前に、CDNのエッジミドルウェアがユーザーをどのテストグループに割り振るかを決定し、そのグループに対応するコンテンツのURLに内部的にリクエストを書き換えてしまうからだ。その後、ウェブサーバーは最初からその書き換えられたURLに対応する、完成されたHTMLをレンダリングしてユーザーのブラウザに送り返す。つまり、ユーザーのブラウザは、最初から最終的なテスト済みのコンテンツを受け取るため、後からJavaScriptによってコンテンツが書き換えられることが一切ない。これにより、オリジナルのコンテンツがちらつくこともなく（0ms FOOC Flicker）、レイアウトがずれることもない（0.00 Cumulative Layout Shift）。さらに、クライアントサイドで動作する重いA/Bテスト用のJavaScriptも不要になるため、ウェブサイトの読み込み速度も大幅に改善される。

A/Bテストで肝心なのは、どのバリアントがより良い結果（コンバージョン）をもたらしたかを正確に測定し、追跡することだ。この新しいアプローチでは、「Server Actions（サーバーアクション）」というNext.jsの機能を使ってコンバージョンを追跡する。Server Actionsは、クライアントサイド（ブラウザ）から直接サーバーサイドの特定の処理を呼び出すことができる機能だ。例えば、ユーザーがウェブサイト上の「購入」ボタンや「資料請求」ボタン（Call-To-Action）をクリックした際に、このサーバーアクションを呼び出して、どのテスト（例: hero_conversion_test）の、どのバリアント（controlまたはvariant_b）で、どのようなアクション（例: button_click）が、いつ発生したかというコンバージョンイベントの情報をデータベースに記録する。これにより、クライアントサイドに余分なトラッキングスクリプトを読み込ませることなく、安全かつ効率的にテスト結果を収集できるのだ。

このように、この新しいアプローチは、従来のA/Bテストが抱えていたパフォーマンスとユーザー体験上の課題を根本的に解決する。ウェブサイトの速度低下や視覚的なちらつき、レイアウトのずれといった問題を解消しながら、よりスムーズで高速なユーザー体験を提供しつつ、ウェブサイトの最適化を進めるための強力な手段となる。