​

フリッカーとは

ブラウザーが変更の読み込みと処理に時間がかかりすぎると、Webページがフリッカー(ちらつき)することがあります。このような場合、ブラウザーはテスト要件を満たして変更を適用する前に、Webページを元の状態(コントロール状態)で数秒間表示します。これにより、変更が反映される間にWebページが目に見えてちらつきます。 たとえば、アプリケーションで新しいMoEngageコンテンツを表示する前に、フリッカーによってユーザーインターフェース要素が一時的に乱れるのを目にしたことがあるかもしれません。

​

フリッカーの影響

フリッカーは、次のような形でユーザーの信頼に悪影響を及ぼす可能性があります。

• マイナスの印象: コンテンツの読み込み中にちらついたり点滅したりするWebページは、不安定に見えたり、設計が不十分に見えたりすることがあります。ユーザーはサイトの信頼性やプロフェッショナリズムに疑問を抱き始める可能性があります。
• パフォーマンスが遅いという認識: フリッカーにより、Webサイトの動作が遅い、またはコンテンツの読み込みが遅いという印象を与える可能性があります。ユーザーは、Webサイトのコンテンツや全体的なパフォーマンスに問題があると考えるかもしれません。Webサイトの動作が遅いことでユーザーが信頼を失い、それ以上操作することをためらうようになる可能性があります。
• 不完全または信頼できない情報: ユーザーがアプリケーション上のコンテンツを読んだり操作したりしようとするとき、フリッカーによって情報や機能が信頼できない、または不完全であるという印象を与える可能性があります。ユーザーはコンテンツの正確性や妥当性に対する信頼を失う可能性があります。
• ユーザーエクスペリエンスの妨げ: フリッカーは煩わしく気が散るものであり、怒りや不満を引き起こす可能性があります。ブラウジング中に頻繁にフリッカーを感じると、ユーザーはWebサイトがスムーズで快適なユーザーエクスペリエンスを提供できるかどうかについて信頼を失う可能性があります。

一般に、フリッカーはプロフェッショナリズム、サイトの信頼性、読み込み速度、コンテンツの正確性に対する認識を損なうことで、信頼を損なう可能性があります。シームレスでフリッカーのないエクスペリエンスを提供することは、信頼を築き、ユーザーがWebサイトとその提供内容に確信を持てるようにするために不可欠です。

​

フリッカーの原因となる要因

フリッカーは、Webサイトでのスクリプトのインストール方法やタグ管理、A/Bテストツールの読み込み方法(同期と非同期)、SDKのサイズ、実施されている実験の数などの要因によって発生する可能性があります。

​

直接インストールとタグマネージャー

タグマネージャーはJavaScriptコードの実装とデプロイを簡素化しますが、通常はWebサイトにJavaScript実行のレイヤーが追加されるため、パフォーマンスのオーバーヘッドが生じる可能性があります。特に複数のタグやスクリプトが関係する場合、ページの読み込み時間やユーザーエクスペリエンスに影響を与える可能性があります。この制限を克服するには、次のことを行います。

• 実行の優先順位付け

サードパーティのコードを <head> の先頭に配置すると、ページ上の他のスクリプトやコンテンツよりも先に読み込みと実行を行うことができます。これにより、コードができるだけ早く実行され、初期化の遅延を減らすことができます。

• 実行の高速化と可視性の向上

ページ読み込みプロセスの早い段階でPersonalization SDKを読み込むと、関連するすべての機能のトラッキングをすぐに開始できます。

​

A/Bテストツールの読み込み

A/Bテストは、Webページまたはアプリの2つのバージョンを比較し、パフォーマンスの高い方を判断して表示するものです。バリエーションをアプリケーションに適用するには、A/Bテストスクリプトを次のいずれかの方法で読み込んで実行する必要があります。

• 同期読み込み

JavaScriptの同期読み込みでは、スクリプトが1行ずつ読み込まれて実行されます。次のスクリプトに進んだり、ページのレンダリングを続けたりするために、ブラウザーはレンダリングを一時停止し、各スクリプトが読み込まれて実行されるのを待ちます。

• 非同期読み込み

JavaScriptの非同期読み込みでは、ページの読み込み中にスクリプトが並行して読み込まれ、実行されます。ブラウザーはモジュールを読み込むタイミングに依存せず、古いスクリプトがバックグラウンドで読み込まれている間も、レンダリングや他のリソースの読み込みを続けます。 非同期のスクリプト読み込みはページ全体の読み込みを高速化する可能性がありますが、A/Bテストスクリプトが後から読み込まれるとフリッカーが発生する可能性もあります。フリッカーは、元のページが最初にレンダリングされ、A/Bテストスクリプトが読み込まれて実行された時点でバリエーションが適用されるために発生します。これによりユーザーにとって目立つ視覚的な変化が生じる可能性があり、A/Bテストのシナリオでは通常望ましくありません。

​

SDKの仕様

​

SDKのサイズ

ページの読み込み時間に大きく影響するもう1つの要因はSDKのサイズであり、これによってブラウザーがSDKをダウンロードするのにかかる時間が決まります。SDKのサイズが大きいと、コードのダウンロードと実行にかかる時間が長くなり、その結果、Webページがコンテンツを読み込む時間も長くなります。

​

実験の数

訪問者にパーソナライズされたコンテンツをレンダリングするのにかかる時間は、SDKによって取得されるエクスペリエンスの数にも依存します。 MoEngageは、選択したターゲット条件に基づいて、アクティブで関連性のある訪問者エクスペリエンスのみを配信します。さらに、MoEngageは訪問者がアクセスしたWebページに固有のエクスペリエンスを優先し、Webサイトの他の部分に設定された残りのエクスペリエンスは並行して取得するため、Webページのパーソナライゼーションプロセスが大幅に高速化されます。 これに加えて、訪問者に配信されるエクスペリエンスには、元のコンテンツと比較して特定のWebページ要素に対して更新または追加される変更のみが含まれます。これによりペイロードのサイズが削減され、配信時間が短縮されるとともに、変更のレンダリングが高速化されます。

​

フリッカーを最小限に抑える

​

アンチフリッカースニペット

​

仕組み

Webページ上のコンテンツは、コード内の特定の設定を使用して非表示にできます。これは、変更を加えた後にコンテンツをすばやく非表示にしてから表示するために行われます。 留意点:

• コードの読み込みや実装に問題がある場合、ユーザーには数秒間、あるいはそれ以上の間、空白のページや画面が表示される可能性があります。変更が行われるのに十分な時間を確保しつつ、コンテンツが数ミリ秒以内に表示されるようにすることが重要です。
• 一定の時間枠(通常は数秒)内に変更が表示されない場合は、非表示のコンテンツを表示し、後で変更を適用することが重要です。これにより、ユーザーがWebサイトの動作が遅い、または正常に動作していないと考えることを防ぎます。

MoEngage Anti-flicker snippetは、パーソナライズされた変更が訪問者に表示されるまで、デフォルトで1.5秒間ページコンテンツを非表示にします。ほぼすべてのケースで、変更は0.5秒以内に適用され、ページコンテンツがユーザーに表示されます。デフォルトの1.5秒は、MAX_RENDER_TIME 変数の値を更新することで変更することもできます。

​

サーバーサイドパーソナライゼーションへの切り替え

サーバーサイドパーソナライゼーションに切り替えることは、A/Bテストのシナリオでフリッカーを最小限に抑えるための有効なアプローチとなり得ます。サーバーサイドパーソナライゼーションでは、Webページのさまざまなバリエーションをユーザーに配信する前にサーバー上でレンダリングします。これにより、ユーザーには最初から目的のバリエーションが表示され、クライアントサイドの変更によって発生するフリッカーがなくなります。 フリッカーを最小限に抑えるためのサーバーサイドパーソナライゼーションの利点は次のとおりです。

• バリエーションの即時表示: サーバーサイドパーソナライゼーションでは、サーバーが完全に変更されたページをユーザーに配信するため、最初の読み込み時から目的のバリエーションが確実に表示されます。これにより、他のアプローチで発生する可能性のあるクライアントサイドの変更によるフリッカーがなくなります。
• クライアントサイドのリソースへの依存がない: サーバーサイドパーソナライゼーションでは、JavaScriptを読み込んだり実行したりするための追加のクライアントサイドリソースを必要とせずに、サーバー上でバリエーションが生成されます。これにより、読み込みの遅いスクリプトや依存関係による遅延のリスクが軽減され、フリッカーの可能性がさらに最小限に抑えられます。
• ユーザーエクスペリエンスの向上: フリッカーを回避することで、サーバーサイドパーソナライゼーションは、より一貫性のあるシームレスなユーザーエクスペリエンスを提供します。ユーザーには最初から目的のバリエーションが表示されるため、エンゲージメントと満足度が向上します。