2026年10月19日更新
13ミリ秒。これは人間の脳が画像を識別するのに必要な時間です。 MITの神経科学者による2014年の研究. しかし、クライアントサイドのA/Bテストツールのスクリプトは、ページの変更に数百ミリ秒かかることがよくあります。この間、訪問者は元のバージョンと変更後のバージョンの両方を見ています。つまり、両方を見たことになります。しかし、テストでは、訪問者が片方しか見ていないと想定しています。
このちらつき効果は、測定結果に体系的な偏りをもたらし、ほとんどの場合、対象となるバリエーションに悪影響を与え、優れたアイデアを却下したり、不適切なアイデアを検証したりする原因となる可能性があります。このガイドでは、ちらつき効果の原因、実際のコスト、自社サイトでの測定方法、そして除去方法について説明します。
A/Bテストにおけるフリッカー効果とは何ですか?
フリッカー効果(またはFOOC、「オリジナルコンテンツのフラッシュ」)とは、テストスクリプトがブラウザによるページ表示開始後にページを変更するため、テスト対象のバリアントが適用される前に元のページが短時間表示される現象のことです。 訪問者は、タイトルが変わったり、ボタンの色が変わったり、ブロックが移動したりするなど、何らかの変化を知覚する。
この現象はクライアントサイドテストに特有のものです。このモデルでは、サーバーは常に同じ HTML ページを送信します。ブラウザによって読み込まれる JavaScript ファイルで、訪問者がどのグループに属するかを判断し、それに応じて DOM を書き換えます。このスクリプトがダウンロード、解釈、実行されるまで、コントロールが表示されます。この用語 (DOM、variant、control、allocation) に馴染みがない場合は、 A/Bテスト用語集 各項を繰り返します。
Flickerが結果を歪める理由
ちらつきは2つのグループのうち一方にのみ影響します。コントロール群はアーティファクトなしで表示されますが、バリアント群はちらつきが発生します。したがって、もはや「デザインAとデザインBの比較」ではなく、「デザインAと表示不良のあるデザインBの比較」となります。 これはノイズではなくバイアスであり、サンプルサイズを増やしても打ち消されるものではありません。
この変異株に対しては、2つのメカニズムが作用する。
- 自信喪失。 ページが「飛び跳ねる」ような表示は、ウェブサイトのデザインが劣悪であることを示唆しています。決済プロセスや見積もり依頼フォームにおいて、このような表示は、それだけで警戒すべき兆候と言えるでしょう。
- 比較効果。 訪問者は以前の価格、タイトル、または画像を見たことがある。もしバリエーションで取り消し線付きの価格やより強い約束が提示された場合、訪問者は両方のバージョンを見ることになり、オファーに対する認識が変わる。
逆に、時には「現れる」要素が目を引き、バリエーションを増幅させることもあります。どちらの場合も、あなたの 分析ダッシュボード これは、スクリプトなしでハードコーディングしてデプロイした場合のバリアントの外観とは一致しません。これは、過小評価されている原因の 1 つです。 A/Bテストにおける偽陽性(および偽陰性). 。
画面のちらつきを引き起こす5つの技術的原因
最初のページレンダリング後、バリアントが適用されるとすぐにちらつきが発生します。この遅延を長引かせる要因は5つあり、これらが組み合わさることがあります。
1. スクリプトの場所
最後に配置されたスクリプト <body> HTML の残りの部分が解析された後、つまりブラウザが既にすべてを表示した後にのみ実行されます。できるだけ高い位置に配置する必要があります。 <head>, スタイルシートやその他のサードパーティースクリプトよりも前に。
2. タグマネージャーの使用
Googleタグマネージャーはタグを非同期で読み込みます。そのため、テストスクリプトはGTMコンテナ自体が読み込まれるのを待ってから実行されます。アナリストのSimo Ahava氏は、同じサイトでトラフィックを2つに分割してこの差異を測定したところ、ページは非表示のままでした。 タグをGTM経由で送信した場合の平均処理時間は964ミリ秒だったのに対し、スニペットをページに直接挿入した場合は581ミリ秒だった。. 積分方法のみが原因で、約400ミリ秒の時間が失われました。
3. 非同期読み込み
非同期スクリプトは画面表示をブロックしません。これが処理速度の速さという利点であり、同時に画面のちらつきが発生する原因でもあります。これについては次のセクションで詳しく説明します。
4. スクリプトサイズとレイテンシ
一時停止中のテストも含め、すべてのアカウントテストの設定を含むファイルは、実行に時間がかかります。訪問者から遠く離れたサーバーから配信される場合、往復ごとに数十ミリ秒が追加されます。
5. バリアントのコード化方法
DOM に要素が存在するまで待ってから書き換える変更 (例: ボタンのテキストが読み込まれたら置き換える) は、表示後に必ず適用されます。WYSIWYG エディタは、デフォルトでこの種のコードを生成することがあります。Optimizely それを認識します。視覚的な変更は要素が利用可能になるまで待機するため、変更が多数キューに入っている場合は点滅が発生します。
同期スニペットか非同期スニペットか:本当の決断
同期スニペットは、実行が完了するまで画面表示をブロックします。ちらつきは発生しませんが、スクリプトの実行が遅い場合は画面が真っ白になります。非同期スニペットは、ページの読み込みを許可します。画面が真っ白になることはありませんが、ちらつきが発生します。他に有効な方法はありません。
| 基準 | 同期スニペット | 非同期スニペット |
|---|---|---|
| ちらつき | スクリプトが応答しない場合は何も起こりません | 可能性は高く、遅延に比例する。 |
| ホワイトスクリーン | はい、スクリプトの読み込み中に | いいえ |
| スクリプトサーバーが失敗した場合 | ネットワークタイムアウトが発生するまで、ページはブロックされたままになります。 | このページは元のバージョンで表示されています。 |
| LCPへの影響 | 直接表示(レンダリング待ち) | 間接的(マスキングが追加された場合) |
| 実験の信頼性 | 高い | フリッカー防止対策による |
Optimizely スニペットを同期的に読み込むことを推奨します VWO Wingify 2026年に)ライブラリを待機している間、ページの本文を非表示にします。 Kameleoon 「ブロッキング非同期」統合を強化します。
最適な選択は、たった一つの質問にかかっています。それは、スクリプトのレイテンシが制御可能かどうかです。ファイルが小さく、訪問者の近くにあるCDNから配信されている場合、同期モードにすると数十ミリ秒の遅延が発生しますが、問題は解消されます。そうでなければ、ネットワークの遅延が発生するたびに画面が真っ白になってしまいます。これが問題の本質です。 バリエーションの超高速配信 : ブロッキングモードを、知覚できないほど短くする。
ちらつき防止のためのコード:便利だが、代償が伴う。
アンチフリッカーのコードスニペットは、テストスクリプトの実行中にCSSルールを使用してページ(またはその一部)を非表示にし、実行後に表示します。これにより、目に見えるFlashコンテンツは削除されますが、その代償として、ページがすべてのユーザーに対して後から表示されることになります。
原理は単純です。 <head> 適用済み opacity: 0 または visibility: hidden で <body>. 。 ツールがバリアントを適用すると、そのルールが削除されます。ツールが応答しない場合、最大タイムアウトでページが開きます。一応値は寛大です。古いスニペットは Google Optimize 最大 4 秒待って、 SmartCode VWO / Wingify 設定の許容値を2000ms、ライブラリの許容値を2500msに設定しています。. 。
これらの数値は重要です。この間、ピクセルは1つも描画されません。AdRollのホームページでDebugBearが公開した監査結果によると、マスキングが有効になっている場合、最大コンテンツペイント(LCP)は6.0秒でしたが、マスキングを無効にすると2.7秒になりました。Googleは、LCPが2.5秒を超えると「改善が必要」、4秒を超えると「悪い」と判断します。設定が不適切なアンチフリッカーは、正常なページをマイナスの結果に変えてしまう可能性があります。
破損させないための3つのルール:
- テスト対象領域のみを非表示にする (ヒーローブロック、フォーム)ではなく
<body>全体。ページの残りの部分は通常どおり表示され、LCP は非表示の要素自体が LCP 要素である場合にのみ影響を受けます。 - タイムアウト時間を短縮する 2000~4000ミリ秒ではなく、1000~1500ミリ秒で表示されるようにする。それ以上の時間では、空白ページが表示される訪問者は、画面が一瞬点滅する訪問者よりも大きなペナルティを受けることになる。
- テストをホストするページでのみマスキングを有効にする. サイト全体に導入されたフリッカー防止システムは、何もテストしていない何千ものページにペナルティを課します。
サイトのフリッカーを測定する:A/A'法
フリッカーがテスト結果に偏りをもたらすかどうかを判断するには、A/Aテストを実行します。2つのグループには全く同じページが表示されますが、一方のグループにはテストスクリプトによって目に見えない変更が加えられます。2つのグループ間に有意な差があれば、マーケティング上の考慮事項とは無関係に、インジェクションメカニズム自体のコストを測定できます。
どのグループも変更を受けないため、どのグループもちらつきを経験しません。これが私たちが推奨する方法です。 BlastOptimize 新しいサイトや新しいページテンプレートで連続のテストを開始する前に。
4段階のプロトコル
- バリアントA'を作成する これは、テスト対象の要素に対して、視覚的な効果を伴わない変更を適用します(例えば、タイトルテキストを同じテキストで書き換えたり、属性を追加したりします)。
data-(ボタンのところ)。技術的な経路は真の変異株の経路と同一です。 - 遅延を計測する 最初の表示(最初のコンテンツペイント)から変更の適用までの時間を記録してください。以下の抜粋で十分です。
- 完全なサイクルを実行させてください (平日/週末の影響を平準化するために少なくとも2週間)通常のコンバージョン目標で、 目的と追跡設定. 。
- 2つの数字を読む : 中央値時間と 90 パーセンタイル (遅い訪問者)、次に A と A' の間のコンバージョンギャップ。
<script>
// À appeler dans le code de la variante A', juste après la modification
(function () {
var fcp = performance.getEntriesByName('first-contentful-paint')[0];
var applique = performance.now();
var delai = fcp ? Math.round(applique - fcp.startTime) : null;
// delai > 0 : la variante s'applique APRÈS le premier affichage = flicker visible
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ event: 'flicker_delay', flicker_ms: delai });
})();
</script>解釈方法
- 負またはゼロの遅延 このバリアントは最初のレンダリング前に適用されます。ちらつきは発生しません。
- 中央値遅延100ms未満 :ちらつきは意識的に知覚できるほどではないが、視認できる程度である(13ミリ秒であることを覚えておいてください)。90パーセンタイルを監視してください。
- 中央値遅延が300ミリ秒を超える ほとんどの訪問者にちらつきが見られます。統合が修正されるまで、このページでテストを実行しないでください。
- AとA'の間には有意な変換差がある 注入メカニズムだけでも測定可能な影響があります。このテンプレートを使ったすべてのテストは、このバイアスの影響を受けています。
この図は、このページで解釈できる最小効果量を示しています。A/A'がA'に対して-2%を示している場合、+1.5%増加する変異体は実際には+3.5%増加する可能性があり、-1%の変異体は中立である可能性があります。
最も収益性の高いものから最も費用のかかるものまで、9つの具体的な改善策
ほとんどのちらつきは、ツールを変更せずに修正できます。スクリプトの位置を変更したり、明るさを調整したり、JavaScriptではなくCSSでバリエーションをコーディングしたりすることで解決できます。 以下に、労力対効果の比率に基づいてランク付けした各手段を示します。
- スニペットを上部に配置します
<head>, CSSやその他のサードパーティースクリプトの前に配置します。すぐに効果が得られ、作業時間はわずか5分です。 - Googleタグマネージャーからテストスクリプトを終了します。 これをテンプレートに恒久的に組み込んでください。Simo Ahava氏が測定した400msの差は、この処理によるものです。
- 追加する
preconnectスクリプトを提供するドメインへ(<link rel="preconnect" href="…">ブラウザがタグを検出する前に接続を開くため。 - CSSを使用して視覚的な変更をコーディングします。 CSSルールが挿入され、
<head>要素が描画されるとすぐに適用され、DOM に存在するのを待つ必要はありません。色を変更したり、ブロックを非表示にしたり、2 つの要素の順序を変更したりするには、orderflexbox を使用するのに JavaScript は不要です。これはドキュメントでも Optimizely ティントするバリアントについて。 - 生成されたコードをクリーンアップしますビジュアルエディター : 重複するセレクタを削除し、同じ要素に対する変更をグループ化し、テキストの変更だけで済む場合は HTML ブロックの完全な書き換えを避ける。
- 完了したテストをアーカイブする。 設定に残っている一時停止中のテストごとに、すべての訪問者のファイルサイズが増加します。
- テスト対象領域のみを非表示にする。, ページ全体を4秒間表示するのではなく、短いタイムアウト(1000~1500ミリ秒)を設定します。
- 流入トラフィックが多いページでのリダイレクトテストは避けてください。 URL Aを読み込んだ後にURL Bにリダイレクトすると、ページ読み込みが2回発生します。これは最もコストのかかるフリッカーの形態です。
- 訪問者の近くにあるCDNからスクリプトを配信する, 構成は、訪問したページでアクティブなテストのみに限定されます。これはツールに依存するため、制御できる範囲が最も狭い項目です。プロバイダーに問い合わせるか、当社の スクリプト配布に関するページ BlastOptimize 訪問者に最も近い. 。
サーバーサイドに切り替えるタイミング
サーバーサイドテストでは、設計上、ちらつきが解消されます。サーバーがバリアントを選択し、正しいHTMLを直接送信するため、ブラウザでページを書き換えるスクリプトは存在しません。 デメリットはよく知られています。各テストは開発者の手を経て行われるため、ビジュアルエディタは使い物にならなくなり、イテレーションサイクルが長くなります。サーバーサイドテストは、構造要素(価格設定アルゴリズム、チェックアウトプロセス、ナビゲーション)のテスト、LCPのわずかなずれでもコストがかかるページ、またはA/A分析で上記9つの修正では解決できないバイアスが明らかになった場合に正当化されます。タイトル、ビジュアル、ボタンのテストについては、十分に統合されたクライアントサイドのアプローチの方が実装が速いままです。このアーキテクチャの選択については、サーバーサイドテスト専用のガイドを作成する価値があります。
起動前のアンチフリッカーチェックリスト
テストを本番環境に導入する前に、以下の10項目を確認してください。最初の4項目で1つでも「いいえ」と判断された場合、ローンチを延期するのに十分な理由となります。
- ☐ このスニペットはハードコードされています
<head>, タグマネージャーを除くスクリプトの中で、第1位。 - ☐ このページでは、読み込みモード(同期/非同期)が既知であり、文書化されています。
- ☐ このバリアントは、開発ツールでネットワークを「低速4G」に制限した状態で、実際のスマートフォンで検証されました。
- ☐ 変異が最初に表示されてから適用されるまでの遅延が測定されます(中央値と90パーセンタイル)。
- ☐ 可能な限り、視覚的な変更はCSSで行います。
- ☐ マスキングを使用する場合、テスト対象領域が対象となり、タイムアウトは1500ms以下です。
- ☐ テストありとテストなしのページのLCPを比較しました(目標差:100ms未満)。
- ☐ 完了したテストはアカウントからアーカイブされました。
- ☐ 正当な理由がない限り、主要なエントリーページでリダイレクトテストは実施されません。
- ☐ このページテンプレートに対して、過去 6 か月以内に A/A' テストが実施されました。
Flickrがリストに追加されました A/Bテストでよくある間違い 統計分析を行う前にテストを無効にするものもある。 多変量検定, 複数の領域が同時に変更され、それぞれの組み合わせが異なる閃光を生成できる場所で、 電子商取引サイト, 商品ページには多くの画像やサードパーティのスクリプトが読み込まれる。
よくある質問
画面のちらつき効果はSEOに影響しますか?
間接的には、そうです。フリッカー自体はペナルティではありませんが、不適切な修正方法がペナルティとなります。ページを覆い隠すアンチフリッカーはLCP(ページコンテンツ低下)を悪化させ、ブロックを挿入するタイプの修正はCLS(累積レイアウトシフト)を増加させます。これらの指標はどちらも、Googleが考慮するコアWebバイタルの一部です。テスト済みページと未テストページのSearch Consoleのフィールドデータを比較して、これを検証してください。
私の使っているツールは「100%ちらつきなし」だと謳っていますが、本当にそうでしょうか?
方法を尋ねてください。「フリッカーフリー」は多くの場合「マスキングあり」を意味します。つまり、フラッシュは消えますが、ページの読み込みが遅れます。次の3つの点を確認してください。スニペットの読み込み方法、マスキングのタイムアウト値、スクリプトの有無で測定したLCPの差。A/Aテストを実施すれば、自社サイトで問題を解決できます。アプローチの違いについては、当社の 比較 BlastOptimize / Kameleoon そして私たちの 比較 AB Tasty. 。
同期スニペットは本当にサイトの速度を低下させるのでしょうか?
スクリプトのダウンロードと実行にかかる初期表示時間を遅延させます。CDNから配信される小さなファイルの場合、その差は数十ミリ秒程度です。しかし、大きなファイルや低速なサーバーの場合は、数百ミリ秒にも達し、プロバイダの障害が発生すると、ネットワークタイムアウトまでページが表示されなくなる可能性があります。決定を下す前に、スニペットの有無でLCPを測定してください。
Googleタグマネージャー経由でA/Bテストツールをアップロードできますか?
技術的には可能ですが、この構成ではGTMがタグを非同期で読み込むため、最もちらつきが発生します。公開されている測定結果によると、直接統合した場合と比較して約400msのマスキングが追加されています。GTMはトラッキングイベントのトリガーにのみ使用し、ページを変更するスクリプトには使用しないでください。
同意バナーは画面のちらつきを悪化させるのか?
可能です。テストツールがCookieの承認後にのみ読み込まれる場合、または同意管理プラットフォームが訪問者の選択を読み取る間スクリプトをブロックする場合、バリアントの適用はそれに応じて遅延します。Cookieを使用しないクリーンなセッションで、バナーとテストスニペットの実行順序を確認してください。
主なポイント
- フリッカー効果とは、バリアントが表示される前に元のページが短時間表示される現象のことです。これはクライアントサイドのテストに特有のものです。
- これは単なる視覚的な欠陥ではなく、2つのグループのうち1つだけがこの欠陥を抱えているため、比較を体系的に歪めてしまう。
- 主な原因としては、スクリプトの配置ミス、GTMを経由した処理、非同期読み込み、ファイルサイズが大きすぎること、CSSではなくJavaScriptでコーディングされたバリエーションなどが挙げられます。
- アンチフリッカー機能は症状を隠蔽しますが、表示を遅延させます。テスト対象領域をターゲットにし、タイムアウトを1500ms以下に設定してください。
- 修正する前に測定しましょう。A/A'テストは、現場における注入機構の真のコストを示します。
- サーバーサイド処理は設計上、ちらつきを排除するが、その代償として開発者への依存度が高まる。
どうすれば BlastOptimize バリエーションも提供していますか? オファーと価格 サイトで最初のA/Aテストを実施する。















コメントは締め切りました。