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

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

About The Author

Outline

Googleの次期ページエクスペリエンスアップデートでは、Core Web Vitals (CWV)から派生したシグナルが公式ランキングアルゴリズムに導入される。 Core Web Vitalsは、ページがロードされ、インタラクティブになり、実際にページを操作するユーザーの視覚的な安定性を測定する一連の指標である。 Core Web Vitalsテストに合格しなかったウェブサイトは、2021年初頭に現在実施されているものよりもランクが低くなる。

CWVは、ユーザーの知覚体験に重大な影響を与えることが判明した3つの速度の指標で構成されている。 これには、ロード時間を測定する最大のコンテンツフルペイント(LCP)、インタラクティブ性と応答性を測定する最初の入力遅延(FID)、視覚的安定性を測定する累積レイアウトシフト(CLS)が含まれる。 ウェブサイトの速度は多くのeコマース企業にとって最前線に立ってきたが、それはオンライン環境の中で最も重要な要素の1つになりようとしている。 ここに焦点を当てなければならない指標と、それぞれの速度を向上させる方法がある。

コアウェブバイタルとは

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

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

各CWVメトリックには、良好、中、または不良と見なされるしきい値が異なる。 Googleはページをこれらのグループに分類するときに75パーセンタイルを使用している—ページロードの75%以上が高速であると見なされるしきい値に達したページは良い経験である。

知らないことを最適化することはできないので、コアウェブバイタルを構成する3つの指標のそれぞれを知ってみよう。

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

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

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

2.5秒以下のLCPは高速であると見なされ、2.6秒から4.0秒の間のLCPを持つページは改善が必要であり、4.0秒より長いLCPは低速である。

TheTieBar.comはLayer0(Edgio)に800ミリ秒でLCPをロードする

上の例では、メインイメージが完全にペイントされているときに、タイバーのLCPが900msでマークされる。 Tie Barは、Edgio上の数千ページにカスタマイズ、リアルタイム在庫検索、動的価格設定を提供しながら、モバイルショッパーに一貫してサブセカンドページロードを提供する。

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

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

LCPを最適化するには、次の点を考慮する。

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

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

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

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

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

LCPやCLSとは対照的に、FIDは現場でのみ測定可能であり(ラボデータでは検出されない)、実際のユーザーの操作を必要とすることに注意することも重要である。

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

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

FIDのoptimeの方法:

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

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

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

リンクや商品画像をタップしようとしているが、画面に触れる直前にページが移動し、BAMが意図せずに他のものをクリックした。 最良のシナリオでは、これらの状況はわずかな迷惑であるが、最悪の場合は、ウェブ上でよりスムーズで、より少ないぎこちない経験を探している買い物客を送る。

Googleは、インパクトの割合、つまりビューポートでシフトされた可視コンテンツの量、距離の割合、フレーム内で不安定な要素が移動した距離を画面の最大の寸法(高さまたは幅)で割って、これらのページの動きを計算する。 買い物客が閲覧している間に発生した予期しないレイアウトシフトごとの個々のスコア(インパクトフラクションx距離フラクション)の合計。その結果、ページのCLSが発生する。

Googleは、0.1より小さいCLSを良し、0.1から0.25までのCLSを中等度、0.25より大きいCLSを不良と見なしている。

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

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

このメトリックを改善するには、次の点を考慮する。

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

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

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

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

Layer0上のウェブサイトは、エッジでHTMLとJSONデータのキャッシュヒット率が95%以上であるのに対し、従来のCDN上のサイトは平均6%である。 これは通常ウェブサイトを遅くする内容の提供の巨大な違いである。

要点

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

わずか数ヶ月で、悪いページ体験はあなたのブランドの評判を傷つけ、あなたのSEOランキングに影響を与える。 上で提供される最適化戦術を使用して苦労して稼いだSEOを保護するか、Layer0(現在のEdgio)で即座に行く。

Layer0は、フロントエンドの開発、デプロイ、プレビュー、実験、監視、実行を行うオールインワンソリューション。 靴のカーニバル、Revolve、および1-800-Flowersは1秒以下の速度を提供し、それの利点を得ているeコマースウェブサイトのほんの少数の例である。 ページエクスペリエンスの更新やサイトのスピードアップ方法について質問がある場合は、サイトスピードの専門家に今日連絡して喜んで。

Googleの次期ページエクスペリエンスアップデートでは、Core Web Vitals (CWV)から派生したシグナルが公式ランキングアルゴリズムに導入される。 Core Web Vitalsは、ページがロードされ、インタラクティブになり、実際にページを操作するユーザーの視覚的な安定性を測定する一連の指標である。 Core Web Vitalsテストに合格しなかったウェブサイトは、2021年初頭に現在実施されているものよりもランクが低くなる。