GoogleのUX指標「Core Web Vitals」

Uncategorized

Googleが提唱するUX指標「Core Web Vitals」について、ざっくりと調べてみたことをまとめたい。
SEOという観点だけでなく、よりよいUXの実現というのがGoogleの意図だと思うので、
UX向上に向けたお勉強のつもりで、「LCP」「FID」「CLS」にも触れていきます。

Core Web Vitalsとは。

Core Web Vitalsというのがあるのだから、Web Vitalsというのがあるだろうと思ったら、
案の定ありました。

ウェブで優れたユーザー エクスペリエンスを実現するために重要と思われる品質シグナルの統合ガイドを提供する取り組み

via.Google Developers

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.

via.web.dev

サイト(システム)を利用するユーザ自身の体験をよくするために、
Googleがガイドを提供しています。
中でも特に重要な共通指標として出しているのが、「Core Web Vitals」と呼ばれる3要素で、
それぞれ、以下の通りです。

  • LCP(Largest Contentful Paint):読み込み時間
  • FID(First Input Delay):インタラクティブ性
  • CLS(Cumulative Layout Shift):ページコンテンツの視覚的な安定性

すべてユーザ中心の指標になっていて、数値でどのように評価されるかがGoogleでまとめられています。

LCP (Largest Contentful Paint)

ユーザーがページで最も有意義なコンテンツをどのくらい早く見ることができるかを表します。感覚的な読み込みスピードを測定し、ページ読み込みタイムラインにおいてページの主要コンテンツが読み込まれたと思われるタイミングを指します。

Google Developer

The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.

web.dev

ページの表示スピードを評価しています。
最も有意義なコンテンツ=最も大きいコンテンツ、とあらかじめ定義したうえで
その表示が2.5秒以内にレンダリングできればLCPのスコアは高くなるとされています。
評価対象となる要素も記載されていて、高いスコアを獲得するには、
ページ内の各要素について改善していく必要があります。

FID(First Input Delay)

最初の入力までの遅延を表します。応答性を測定して、ユーザーが最初にページを操作しようとする場合に感じるエクスペリエンスを定量化します。

Google Developer

FID measures the time from when a user first interacts with a page (i.e. when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.

web.dev

ページの中において、ユーザが何らかのアクションを起こしてから、応答までの時間を評価します。
その時間が100ミリ秒未満が高いスコアになるとのこと。
ページの表示速度だけでなく、操作への反応速度が速い(待ち時間が短い)ほど良いってことですね。

CLS(Cumulative Layout Shift)

ページがどのくらい安定しているように感じられるかを表します。視覚的な安定性を測定し、表示されるページ コンテンツにおける予期しないレイアウトのずれの量を定量化します。

Google Developer

CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page.
layout shift occurs any time a visible element changes its position from one rendered frame to the next. (See below for details on how individual layout shift scores are calculated.)

web.dev

layout shift(レイアウトシフト)とは、ページ読み込み時に配置がずれたりするアレです。
わりとよくあるアレですね。操作中にレイアウトがずれて誤操作につながるアレです。
これの累積して出した値(シフトの距離やら、影響範囲などを考慮して算出)でスコアが決まります。
スコア0.1未満が高評価対象です。

スコアを改善する。

LCP

大きく分けると以下の2パターンだと思われます。
ここから、もっと細かく見ていくイメージ。
(効率的にCPU・コアは使えているか、、無駄な処理はしてないか、、etc.)

  • サーバサイドの応答速度改善:サーバスペックの向上、内部アプリケーションのロジック改善
  • クライアントサイドのレンダリング速度改善:CSSやらJavaScriptの改善

FID

LCPに近いところもあると思います。

  • 時間のかかる、おおきなタスクを無くす(タスクの細分化)
  • JavaScriptの実行時間を削減する

CLS

対策が適用できるのかはともかく、以下があげられます。

  • 画像に対してサイズ設定する(枠を決めてあげる)
  • 動的なコンテンツを入れない

ただ、レスポンシブデザインを取っていることが多いと思うので、
あらかじめサイズを定義しておくことがどれほど現実的か、
動的なコンテンツをどうしても入れたい場合はどうするか、みたいな悩みが出そうです。

まとめ

各スコアの計測はブラウザの拡張ツールやらを導入すれば、比較的容易に計測できるようです。
理解を深めるためには、まずは計測してみるというのも手だと思います。

とはいえ、この「Core Web Vitals」が高ければ完璧!ってわけではなく。。
もちろん平均的に高くなることはあるかもしれませんが、
サイト(システムごと)にユーザ特性があって、それに適した指標(評価方法)や考え方を定義する必要があります。
まずは、とっかかりとして今後もユーザのニーズ、特性を踏まえて
ユーザ中心の組み立てをしていきたいですね。

コメント

タイトルとURLをコピーしました