2020年5月28日、Googleが正式にCore Web Vitals(コア・ウェブ・バイタル)を検索エンジンの検索結果に反映させると発表した。

本記事では、コアウェブバイタルの詳細と具体的な対応方法について解説する。

コアウェブバイタルとは

要は、「使いやすいサイト」の評価指標。

これは検索アルゴリズムの改善というよりも、ユーザーの体験価値(UX)を向上するためのガイドラインの制定といった意味合いが強い。

LCP(Largest Contentful Paint)

「最大コンテンツの描画」の意味で、ユーザーの認識としてのページ表示速度を測る指標。

ブラウザの表示範囲内で、最も大きなコンテンツ(画像・動画の初期表示画像・背景画像のある要素・テキストを含むブロックレベル要素など、そのページでメインとなるコンテンツ)が表示されるまでの時間を表す。

FID(First Input Delay)

「初回入力遅延」の意味で、ユーザーが第一印象として感じるサイトのインタラクティブ性や反応速度を測る指標。

ユーザーが最初にページ内でアクションを行った際に(クリック・タップ・テキスト入力など)、ブラウザがその操作に反応するのにかかった時間を表す。

CLS(Cumulative Layout Shift)

「累積レイアウト変更」の意味で、視覚要素の安定性を示す指標。

ユーザーが意図せぬレイアウトのずれがどれぐらい発生したかを、独自の「レイアウトシフトスコア」で表す。

具体的な評価基準と計測方法

  良好 改善が必要 不良
LCP 2.5秒未満 4秒以下 4秒を超える
FID 100ミリ秒未満 300ミリ秒以下 300ミリ秒を超える
CLS 0.1未満 0.25以下 0.25を超える

Search Console

ある程度のトラフィックがあるWebサイトの場合はSearch Consoleからページ全体の評価を確認できる。

ウェブに関する主な指標 @ Web担当者Forum

PageSpeed Insights

Search Consoleで確認するにはトラフィックのデータが足りていない場合や、個別のページの評価を確認したい場合はPageSpeed Insightsを使用できる。

PageSpeed Insights

フィールドデータ(実際のユーザー行動に基づくデータ)が十分に集まっていなくても、ラボデータ(シミュレーション)を閲覧出来るのが利点である。

なお、参照項目は以下の通りだ。

  • LCP:最大コンテンツの描画
  • FID:合計ブロック時間
  • CLS:累積レイアウト変更

なお、FIDにおいては実際のユーザー行動によって計測が可能な項目であることから、厳密には合計ブロック時間=FIDではないため、参考までに確認する。

Chrome拡張

Search ConsoleやPageSpeed Insightsを使用せずに簡易的に調査するのであれば Web Vitals を使用する。

Web Vitals

何をしなければいけないのか

コアウェブバイタルは2021年から実装予定で、かつ実装前(6ヶ月前まで)にアナウンスされることから、すぐに対応しなければならないわけではない。

一方で、コアウェブバイタルへの対応=UXの向上であり、施策が早すぎるということはないため、現時点で可能な施策を提示する。

LCPへの対応

LCP(Largest Contentful Paint)
LCP @ web.dev

LCPの改善項目は以下の4つだ。

  • サーバー応答の改善
  • リソース読み込み時間の削減
  • JavaScriptやCSSによるブロックの削減
  • クライアントサイドレンダリングの改善

サーバー応答の改善

サーバー応答速度を測る指標としてはTTFB (Time to First Bite)がある。

Chrome Dev Toolなどを用いてTTFBを確認する。

Chrome Dev Tool(TTFB)

Googleはサーバー応答時間を200ミリ秒以下にすることを推奨しており、推奨値を上回っている場合は以下の施策を検討する。

  • サーバーの最適化
  • ユーザーから地理的に近いCDNを活用する
  • キャッシュの活用

リソース読み込み時間の削減

Webサイトにおける一般的な「最大コンテンツ(LCP)」は画像や動画などのメディアであり、基本的にはこれらのメディアのサイズやフォーマットを最適化するなどして表示速度を向上させることが重要である。

具体的に、LCPは以下のHTML要素が表示されるまでの時間を対象としている。

  • img要素
  • image要素
  • video要素
  • 背景画像

具体的なファイル容量・フォーマットは以下を参考されたし。

画像の最適化

Googleが推奨するWebページ全体のファイル容量は1,600 KiB(1.6MB)であることから、1ページあたり5枚程度の画像を使用すると仮定すると、1画像あたりのファイルサイズは200KB程度に抑えたい。

ただし、この1.6MBというのは3G回線を前提としており、4Gが一般的な現在の情勢においては若干のサイズオーバーは許容範囲と考えられる。

ファイルサイズを意識して、あまりに圧縮しすぎると画質が下がりすぎてしまいUXに影響しかねないため、画質とファイルサイズのバランスを考慮したい。

元サイズ2.8MBの画像を圧縮した例。

低圧縮:550KB
高圧縮:150KB
高圧縮:300KB

150KBの場合、背景がまだら模様になってしまい、圧縮による劣化が目立ってしまう。
300KBの画像ではそういった劣化もあまり目立たず、550KBの画像と比較しても遜色はない。

ファイル形式

  • PNG:高画質の画像を生成するが、ファイルサイズも大きい。透過画像はPNGを使用する。
  • JPG(JPEG):多くのケースでPNGよりも軽量。画質とファイルサイズのバランス調整が容易。
  • GIF:アニメーション画像に最適なフォーマット。場合によっては動画のほうが軽量。

動画の最適化

動画のファイルサイズは画像と比較すると大容量になりがちで、1280px × 720pxの30秒程度の動画でも40MBを超えてしまい、そのままの状態でWebページに埋め込むと読み込み時間の大幅な遅延の原因となる。

背景にループ動画を流しているWebサイトをよく見かけるが、少なくとも5MB以下に圧縮しつつ、画質の低下をドット状のフィルターで目立たなくしたり、動画が読み込まれるまでの間に仮の背景を表示させるなどの工夫が必要。

また、比較的長い動画を高画質に見せたい場合はYoutube経由で動画を埋め込み、ストリーミング再生にすることでページ自体の読み込み時間を短縮することが可能。

さらに、10秒以内のループ動画を掲載したい場合にはGIF画像の使用も検討したい。

画像・動画の最適化と圧縮以外にも以下のような施策が検討できる。

  • 重要なリソースをプリロードする
  • テキストファイルを圧縮する
  • Adaptive servingの活用(ユーザーのデバイスや回線等の環境に応じて配信するファイルを変更する)
  • Service Workerを使ってキャッシュを利用する

クライアントサイドレンダリングの改善

Reactなどを用いてSPA (Single Page App)を作成している場合は特に、クライアントサイドでのレンダリングが負荷をかけていないかどうかに注意する必要がある。

改善方法には以下のようなものがある。

  • JavaScriptの最小化
  • JavaScriptの非同期化
  • サーバーサイドレンダリングを使用する

FIDへの対応

FID(First Input Delay)
FID @ web.dev

FIDでは、ユーザーがそのページ内で最初に行うアクション(クリック・タップ・スクロール・文字入力など)に対して反応を返すのに要した時間のことであり、Webページの技術要件(htmlの構造やjsによる遅延の影響など)によって対応は異なる。

例えば、ユーザーが「読み込みが完了した」と判断してスクロールしようとしたが、Webページ側ではまだ読み込みが完了しておらずスクロール操作を受け付けない・遅延が発生するケースだ。

この場合は、

  • 常にその操作を受け付けるようにページ内での読み込み優先度をあげる
  • 読み込みが完了していない間はその要素を表示しない・見えないようにする

といった対応が考えられる。

具体的な改善方法としては以下が考えられる。

  • サードパーティコードを考慮する
  • JavaScript実行にかかる時間を軽減する
  • メインスレッドの作業を分割/最小化する
  • リクエスト数や転送量を削減する

サードパーティコードを考慮する

広告や分析用などのサードパーティタグがインタラクションの待ち時間に影響を与える可能性がある。

たとえば、ファーストビューの外にある広告は、その近くまでスクロールしたときにはじめて読み込まれるようにするなど、必要な時に読み込めるようにできないかを検討する。

CLSへの対応

CLS(Cumulative Layout Shift)
CLS @ web.dev

CLSの評価が低い場合、ユーザーが見ているコンテンツが後から読み込まれたコンテンツによって押し出される(位置がズレる)現象が発生している。

Impact fraction
Impact fraction @ web.dev

具体的には以下のような原因で発生する。

  • 画像、広告など埋め込まれる要素にサイズが指定されていない
  • コンテンツが動的に埋め込まれる
  • Webフォントの読み込み

7月6日 追記
img要素に、width属性とheight属性を設定することで、モダンブラウザは画像をダウンロードする前に本来のサイズを認識できる。

画像のサイズと配置場所がわかっていれば、ブラウザは画像の表示予定サイズを算出でき、表示予定サイズがわかっていれば、ブラウザは画像のダウンロード前でも画像を表示すべき場所に適切な大きさの領域を事前に確保できる。

そうすることで、画像があとからダウンロードされたとしても、レイアウト崩れの発生(CLS)を抑制できる。

こちらも、Webページの技術要件(htmlの構造やjsによる遅延の影響など)によって対応は異なる。

ありがちなのが、テキストが先に読み込まれユーザーがそれを読んでいる間に、テキスト間に設置された画像が後から割り込む形で表示されるようなケースだ。

往々にして、

  • ページが重い(画像や動画が多すぎる)
  • デザインが凝りすぎている

といった、「コンテンツの本質的な価値に直接的に寄与しない」要素がCLSの悪化を招くため、ページ内の要素はできるだけシンプルに、軽量にすることが望ましい。


参考文献・URL