Home 技術記事 eコマースWebサイトのコアWebバイタルを最適化する方法
Applications

eコマースWebサイトのコアWebバイタルを最適化する方法

About The Author

Outline

Googleの今後のPage Experienceアップデートでは、Core Web Vitals (CWV)から得られたシグナルが公式ランキングアルゴリズムに導入されます。 Core Web Vitalsは、ページの読み込み速度、インタラクティブ化、視覚的安定性を測定する指標です。 Core Web Vitalsテストに合格しなかったウェブサイトは、現在2021年初頭にリリースされたものよりもランクが低くなります。

CWVは、ユーザーの知覚体験に大きな影響を与えることが判明した3つの速度のメトリックで構成されています。 ロード時間を測定する最大のContentful Paint(LCP)、インタラクティブ性と応答性を測定するFirst Input Delay(FID)、視覚的安定性を測定するCumulative Layout Shift(CLS)などがあります。 多くのeコマース企業にとってウェブサイトの速度は最前線にありますが、オンライン環境で最も重要な要素の1つになりそうです。 ここでは、焦点を当てる必要がある指標と、それぞれの速度を向上させる方法について説明します。

コアウェブバイタルとは

オンラインで良い第一印象を与えることは重要です。 買い物客は、商品をすぐに見たり、すばやく閲覧したり、簡単にチェックアウトしたりしたいと考えています。 期待が満たされなければ、彼らは跳ね返って二度と戻ってこないでしょう。 Core Web Vitalsは、モバイル買い物客がサイトをリアルタイムで閲覧する際に提供するエクスペリエンスページを測定することで、この問題に対処します。

ほとんどのGoogleツールはシミュレーション環境(ラボデータ)での合成テストに依存していますが、Core Web Vitalsは、実際のChromeユーザーデータデータベースであるGoogle Chrome User Experience(CRUX)から収集されたフィールドデータを使用して測定されます。 フィールドデータは、デバイス、ネットワーク条件、設定など、実際のユーザー変数の劇的な影響をキャプチャします。 ユーザーの状況に応じて、サイトのパフォーマンスは劇的に変化し、Core Webの重要なスコアに影響を与える可能性があります。

CWVメトリックごとに、Good、Moderate、またはPoorと見なされるしきい値が異なります。 しかし、これらすべてに共通することが1つあります。Googleは、ページをこれらのグループに分類するときに75パーセンタイルを使用します。ページの読み込みの75%以上が高速と見なされるしきい値に達するページは、優れたエクスペリエンスです。

わからないものは最適化できないので、Core Web Vitalsを構成する3つの指標をそれぞれ確認してみましょう。

出典: https://web.dev/vitals/

最大コンテンツ表示時間(LCP)

ユーザーは通常、最大のコンテンツ要素が画面上に完全に表示されているとき、つまり最大のコンテンツフルペイント(LCP)の速度によって、ページが読み込まれたと感じます。 コンテンツ要素には、ブロックレベルの要素、画像(SVGファイル内の画像を含む)、およびビデオを含めることができます。 eコマースの場合、LCPは通常、製品画像/ヒーロー画像がロードされる速度を測定します。 これが遅い場合、ユーザーは全体的なエクスペリエンスが似ていると想定し、競合他社のサイトに移動します。

LCPが2.5秒以下の場合は高速、LCPが2.6 ~ 4.0秒の場合は改善が必要、LCPが4.0秒を超える場合は低速と見なされます。

TheTieBar.comは、Layer0(Edgio)で800ミリ秒でLCPをロードします。

上の例では、メインイメージが完全にペイントされたときに、Tie BarのLCPが900msにマークされています。 Tie Barは、モバイル買い物客に一貫して1秒未満のページ読み込みを提供すると同時に、Edgioの何千ものページでカスタマイズ、リアルタイムの在庫検索、動的な価格設定を提供します。

通常、LCPは次のいずれかの影響を受けます。

  • サーバーのレスポンス時間の遅さ
  • JavaScriptおよびCSSのレンダリングブロック
  • リソースのロード時間が長い
  • クライアント側のレンダリングの問題

LCPを最適化するには、次の点を考慮してください。

  1. 利用可能な最も近いCDN PoPにトラフィックをルーティングし、アセットをキャッシュし、サービスワーカーを使用し、「rel=」preconnect」でサードパーティ接続を早期に確立することで、サーバーの応答時間を最適化します。
  2. JavaScriptのブロック時間を短縮するには、コードを最小化し(空白を削除するなど)、Brotiやgzipなどのツールでデータを圧縮し 、バンドルを分割して最初に必要なものだけを送信し、Babelなどのツールで新しい構文でコードを提供し ます。 未使用のCSSや、スペース、インデント、コメントなどの不要な文字を削除し、重要なCSSをページの先頭に直接含めることでインライン化することで、CSSを削減します。
  3. リソースのロード時間を短縮するには、イメージファイルとテキストファイルを最適化および圧縮し、重要なリソースをプリロードし、サービスワーカーを使用してネットワーク接続とキャッシュアセットに基づいてさまざまなアセットを配信します。
  4. サーバーサイドレンダリング(SSR)とプリレンダリングを使用して、JavaScriptのブロック時間を短縮し(このために最適化するには#2を参照)、クライアント側レンダリングを最適化します。

初回入力までの遅延時間(FID)

ユーザーの第一印象は、最大の画像がレンダリングされる速度の影響を受けますが、ユーザーがそれを操作しようとしたときにサイトが応答することも同様に重要です。 最初の入力遅延(FID)は、ユーザーが最初にページを操作したとき(クリック、タップ、またはキーを押したとき)から、ブラウザーがその操作に応答できるようになるまでの時間を測定します。

通常、入力遅延が発生するのは、JavaScriptがメインスレッドで実行され、すべてのJavaScriptがデフォルトでレンダリングブロックされているためです。 これは、ブラウザがJavaScriptファイルを見つけたときに、そのJavaScriptをダウンロード、解析、コンパイル、実行するために何をしているかを一時停止する必要があることを意味します。 これにかかる時間が長くなるほど、ユーザー体験の遅延が大きくなり、Googleがページを使用可能として表示することは少なくなります。

Googleでは、FIDの100はミリ秒以下、1.1 ~ 3.0秒の間は改善が必要であり、3.0秒以上は低速であると考えています。 すべてのCore Web Vitalsで75パーセンタイルを目指すことは重要ですが、モバイルとデスクトップでのFIDの95パーセンタイルから99パーセンタイルを見ることをお勧めします。これは、最悪のユーザー体験を表し、最も改善が必要な領域を確認するためです。 (ページ読み込みの95%以上のFIDに焦点を当てます)。

また、LCPやCLSとは異なり、FIDは実際のユーザー操作が必要なため、現場でのみ測定できます(ラボデータには検出されません)。

FIDが遅い一般的な理由は次のとおりです。

  1. メインスレッドを50ミリ秒以上ブロックする長いタスク
  2. ファーストパーティスクリプトの実行によるインタラクションの準備の遅れ
  3. 重いJavaScriptの実行時間

FIDの動作時間:

  1. 長時間実行されているコードをより小さな非同期タスクに分解し、コード分割を利用します。
  2. 重要ではないコンポーネントのスクリプトロード(および実行)をクリティカルパスから移動し、カスケードデータフェッチとクライアント側で後処理する必要のあるデータ量を最小限に抑えます。
  3. Comlink、Workway、WorkerizeなどのWebワーカーを使用します 。これにより、バックグラウンドスレッドでJavaScriptを実行したり、JavaScriptバンドルを複数のチャンクにコード分割したり(遅延読み込みとも呼ばれます)、すべてのサードパーティスクリプトをdeferまたはasyncでロードしたりできます。

累積レイアウトシフト数(CLS)

ページの視覚的安定性は、ユーザーエクスペリエンスに影響を与え、買い物客が購入への道を続けるのを妨げるもう1つの要因です。 Core Web Vitalsの3番目で最後の指標は、累積レイアウトシフト(CLS)です。これは、ユーザーが予期しないレイアウトシフトを経験する頻度を測定します。

リンクや商品画像をタップしようとしているときに、画面をタッチする直前にページが移動し、BAMを実行すると、意図せず他の何かをクリックしたことがあります。 最良のシナリオでは、これらの状況はわずかな迷惑ですが、最悪のケースでは、買い物客にWeb上でよりスムーズで不快感の少ない体験を検索させます。

Googleでは、影響率、ビューポートでシフトされた表示コンテンツの量、距離の割合、フレーム内で不安定な要素が移動した距離を画面の最大寸法(高さまたは幅)で割った値を掛けて、ページの動きを計算し ます。 買い物客が閲覧している間に発生した予想外のレイアウトシフトごとの個々のスコア(影響率x距離率)の合計が ページのCLSになります。

Googleは、0.1より低いCLSを良好、0.1から0.25の間を中程度、0.25より大きいCLSを不良と見なしている。

CLSが不十分な場合は、次のいずれかが原因である可能性があります。

  1. 画像または動画のサイズ変更
  2. 広告のサイズ変更
  3. 読み込みが遅く、意図したサイズよりも大きく表示されたり小さく表示されたりするフォント

このメトリックを改善するには、次の点を考慮してください。

  1. 画像とビデオ要素の正確な寸法を含めます。
  2. ポップアップ広告やバナーは避けてください。 代わりに、静的に広告スロットのための大きなスペースを予約してください。
  3. フォント表示やフォント読み込みAPIなどのツールを使用して、スタイルが設定されていないテキストや見えないテキスト(FOIT/FOUT)のフラッシュを回避します

Layer0が各Core Web Vitalsメトリックの速度を最適化する方法

数百万ページ、数千のSKU、A/Bテストとパーソナライゼーション、動的な価格設定、リアルタイムの在庫検索を備えた大規模で複雑なeコマースWebサイトは、Layer0を使用して秒未満の速度を達成できます。 実際、Layer0は、500ミリ秒以下の中央値のLCPを保証する市場で唯一のプラットフォームです。

Layer0では、コンテンツは即座にページにレンダリングまたはペイントされ、アプリケーションに対応したJavaScript設定可能なCDNであるCDN-as-JavaScriptにより、すぐにタップ可能になります 。 高度な予測プリフェッチとエッジコンピューティングを利用して、要求される前に、エッジからユーザーのブラウザーに動的コンテンツ(JSON/SSR/HTML)をストリーミングします。 これにより、サイトの5は常に買い物客のタップ数よりも数秒早く維持されます。

Layer0のWebサイトは、エッジでのHTMLおよびJSONデータのキャッシュヒット率が95%以上であり、従来のCDNのサイトは平均6%です。 これは、通常Webサイトを遅くするコンテンツの配信における大きな違いです。

結論

ページの読み込みが速いことで、買い物客を喜ばせることと、競合他社のサイトを怖がらせることを区別できます。 Core Web Vitals最大のコンテンツフルペイント、最初の入力遅延、累積レイアウトシフトを測定することで、速度、インタラクティブ性、視覚的安定性に関するユーザーの第一印象を考慮します。 LCPの速度が2.5秒、FIDの速度が100ミリ秒、CLSの速度が.1秒を超える場合、ユーザーとGoogleの両方がサイトの速度を遅く認識していると想定できます。 Googleはあなたのランクを下げ、消費者は跳ね返って戻ってくることはありません。

わずか数ヶ月で、ページのエクスペリエンスが悪いと、ブランドの評判が損なわれ、SEOランキングに影響を与えます。 上記の最適化戦術を使用して苦労して獲得したSEOを保護するか、Layer0(現在はEdgio)を使用して即座に実行します。

Layer0は、開発、導入、プレビュー、実験、監視、 そしてフロントエンドを実行します。 Shoe Carnival、Revolve、および1-800-Flowersは、秒未満の速度を提供し、そのメリットを享受しているeコマースWebサイトのほんの一例です。 ページエクスペリエンスの更新やサイトのスピードアップ方法についてご質問がある場合は、サイトスピードの専門家にご連絡させていただきます。

Googleの今後のPage Experienceアップデートでは、Core Web Vitals (CWV)から得られたシグナルが公式ランキングアルゴリズムに導入されます。 Core Web Vitalsは、ページの読み込み速度、インタラクティブ化、視覚的安定性を測定する指標です。 Core Web Vitalsテストに合格しなかったウェブサイトは、現在2021年初頭にリリースされたものよりもランクが低くなります。