Core Web VitalsがGoogle検索ランキングの指標に
WEBサイトの表示スピードが検索に影響する…というのはなんとなくわかっていたことですが、
2021年5月末、ついにそれが明確に検索ランキングの指標になると発表されたようです。
Web Vitalsという言葉があります。
これは何かというと、「ウェブ上で優れたユーザーエクスペリエンスを提供するために不可欠な高品質の信号に関する統一されたガイダンスを提供するためのGoogleによるイニシアチブです」…
………と公式に説明がありますが（直訳よくわからない）、
要するに、ユーザーによりよいサービスを提供するためのガイダンスをまとめて提供する、googleの取り組みです。
Googleはこれまでもパフォーマンスを測定するためのツールを提供してきましたが、一部の開発者にしか浸透しておらず、全てのサイトの所有者が活用しているわけではありません。
でも実際には、Googleのツールを使えば誰でも全てのWEBページを測定可能であり、改善することで優れたユーザー体験を提供することができるようになります。
その指標となるのがCore Web Vitalsです。
Core Web Vitalsの3つの側面
Core Web Vitalsは3つの側面があります。
- LCP (Largest Contentful Paint)
- FID (First Input Delay)
- CLS (Cumulative Layout Shift)
それぞれ上から、読み込み、インタラクティブ性、視覚的安定性です。
Core Web Vitalsは、ユーザーエクスペリエンスを向上させるための考え方であり、時代とともに進化していくとのことです。
今はこの3つですが、また年月とともに新たに指標が加わることもあるかもしれません。
LCP (Largest Contentful Paint)
ページのメインコンテンツが読み込まれるまでの速度です。
メインコンテンツというのは、ビューポートに表示されている「最大コンテンツ」の要素のことですが、これが2.5秒以内に表示されると、良いスコアとされます。4秒を越えると遅いと判断されます。
現在最大コンテンツとして考慮されている要素は
- img要素
- image要素内のsvg要素
- video要素（poster属性で画像を使用している）
- url()（背景画像を持つ要素）
- テキストノードまたは他のインラインレベルのテキスト要素を含むブロックレベルの要素
CSSによるmarginやpaddingによる境界線は考慮されませんとのことですが、経験上、画像のレンダリングがされた時点でこれらが終わってないことはあまりないです。
大きい画像、テキストを含むブロック要素が最大コンテンツとして認識され、さらにビューポート内での計測になるので、ほとんどのWEBサイト場合はメインビジュアルがこれに当たるのではないでしょうか。
Googleの検索結果ページでは、画像やロゴよりもテキストの段落の方がサイズが大きいため、画像が表示されていなくてもLCP発生となるようです。
通常、ビューポート内でユーザーに表示されるサイズが対象となります。
要素がビューポートの外側に伸びている場合、またはクリップ（マスク）されている場合は、要素のサイズにカウントされません。
つまり、カルーセルの２枚目がビューポートの外にあり、overflow:hiddenで隠れている部分は、まだ描画されていなくてもLCPが悪くなることはない…ということになるんだと思います（多分）。
opacity:0で消してるだけの場合はどうなるんだろう…という疑問が湧きましたが…どうなんでしょう…そこまではわかりませんでした。
FID (First Input Delay)
双方向性…つまり、ユーザーが何かしらのアクションを起こしてページが反応するまでの時間です。
ページを読み込んですぐは、クリックしても何も起こらないことがありますが、これは、まだサイトの解析が終わっていないからです。
FIDは100ミリ以下で良いスコアとされます。0.1秒以内に何かしら応答できるサイトが良いということです。300ミリ秒以上で、遅いと判断されます。
応答が遅れる理由の一つは、JavaScriptファイルの解析と実行に時間がかかっているからです。JSがロード中だということは、まだロードできていない部分で何か他の指示が書かれているかもしれないので、読み込まれたイベントリスナーもまだ実行することができません。
ちなみに私が最初に勘違いしていたところですが、FIDとTTIは別ものです。
TTIはTime to Interactiveの略で、「ページの読み込みが開始されてから」「メインのサブリソースが読み込まれるまで」の時間のことで、
一方FIDは「ユーザーがアクションを起こした（ブラウザがユーザーのアクションを受け付けた）時から」「メインスレッドが応答するまで」の時間です。
さらに、JSの解析でメインスレッドがビジー状態になっている時間をTBT（Total Blocking Time）といい、
通常、入力遅延はTBTの間に起こるので、TBTを改善すればFIDも改善→TTIも短くなる ということになります。
この、頭文字をとったアルファベットがSEO周りにはすごく多いです。図で見るとこんな感じです。
イベントリスナーがない場合はFIDを測定できないのかというと、そうではないようです。
入力イベントが受信されてから、メインスレッドが次にアイドル状態（処理可能）になるまでの時間を測定するということです。
また、最初の入力としてカウントされるアクションは、クリック、タップ、キー押下などの個別のアクションからの入力です。
スクロールやズームなどはこれらとは別に評価する必要があり、FIDの範囲ではありません。
ちなみに、クリックなどに対する応答はレスポンス、スクロールやズームはアニメーションというように、パフォーマンスモデルを定義したものをRAILモデルというようです。
FIDの測定は、実際のユーザーがページを操作する必要があるため、PageSpeed Insightsでポチっとしただけでは計測できません。JSを仕込んでconsoleに記録する方法があります。
が、TTIやTBTと関係が深いため、これらが合格ラインであれば大丈夫と言えると思います。
CLS (Cumulative Layout Shift)
パッと画面を開いた時に、最初に見えていたテキストが、その上に画像が入ったことによって下にずれて見えなくなった…という経験はよくあると思います。
CLSは、視覚的安全性のことで、このようにテキストが大幅に移動してユーザーが一瞬ストレスを抱えることがないようにと考えられた指標です。
テキストが移動してちらつくくらいならあまり問題にはならないですが、クリックしようとしたものが一瞬で移動して、違うものをクリックしてしまった！という経験が私にもあります。
最近改善されていましたが、グーグルの検索画面で、広告が後から出てきてクリックしてしまったということがよくありました。
CLSは0.1以下で良いスコアとされ、0.25以上で悪いとされます。
ページのレイアウトシフトについて、どうやって数値をだしているのかというと、
要素が移動したことによる影響の割合（ビューポート基準の％）と要素が移動した距離（ビューポート基準の％）をかけて出しているようです…。
「影響の割合」は、移動した要素の面積とビューポートから、グーグルのアルゴリズムで決められています。
CLSを改善するには、高さを指定しておくことが手っ取り早い改善方法だと思いますが、CSSのtransformプロパティを使用すると、このレイアウトシフトにひっかからずに要素をアニメーションできます。
アニメーションとトランジションは、うまくいけばユーザーを驚かせることなくページのコンテンツを更新できるので、グーグル的に「優れた方法」だと書かれています。（デザインにもよると思いますが）
Core Web Vitalsを測定するツール
PageSpeed Insights
計測する方法で私がよく使用するのは、PageSpeed Insightsです。
URLを入れてボタンをおしてしばらく待つだけで計測してくれるので、手軽で便利です。
ローカルデータやベーシック認証がかかっているサイトは対応していませんが、実際に公開するサーバーで測定するので、一番信用できるデータがとれるのではと個人的に思っています。
JavaScriptライブラリ
web-vitalsというJavaScriptライブラリも用意されています。
npmインストールのほか、CDNもあります。コンソールに出力して確認できます。
import {getCLS, getFID, getLCP} from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify(metric);
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);Chrome DevTools
制作中にこれらのデータを収集するために便利なのがChrome DevToolsです。
FIDは測定できないので、代わりにTBTを使用します。
Performanceタブでは、データ読み込み時のかなり詳細なデータを見ることができます。
何ミリ秒でどの画像が読み込まれたのか、LCPのタイミングはいつなのか、またどの要素がそれに当たるか、
レイアウトシフトがどこで起こっているか、ボトムアップになっているデータはどれなのかなど…
たくさんの情報がありますが、読み方をある程度覚えるとローカルでも使えるので、パフォーマンスアップの強い味方となります。
Networkタブでは、個々のファイルのダウンロードにどれだけの時間がかかったかを見ることができます。設定でパソコンの性能を落とした状態での計測も可能なので、開発者のすごく速いパソコンではいい結果だけど、一般の人の環境ではそうはいかない…といった懸念があっても、あらかじめ試すことができます。
Lighthouseは、ボタンを押すだけで、パフォーマンス、アクセシビリティ、SEOなどが点数化されます。
ローカルで使えるPageSpeed Insightsのようなものです。
昔はローカル環境では計測できなかった記憶がありますが、今は対応しています。
WebPageTest
こちらのサービスは今回初めて知りましたが、これもローカルで測定できます。
URLを入れるだけで測定できます。
「Web Vitals」という項目があり、LCP、CLS、TBTの結果が表示され、合格か不合格が色分けされます。
Web Vitalsを明確に測定してくれるという点で、焦点を絞った測定結果が得られやすいと思いました。
一度に３回ロードし、ファーストビューにかかる時間を測定しています。
Search Console、CrUXダッシュボード
SearchConsoleを使う方法もあります。
こちらは、所有者が所有権を確認したサイトでのみ使用可能です。PageSpeedInsightsとは異なり、検索コンソールのレポートには過去のパフォーマンスデータが含まれます。
他にも、CrUXダッシュボードというものがあるようで、セットアップ１分ほどで多くのデータを得ることができます。
初めて知りましたが、ある期間内にそのサイトのUXがどう変化したか確認できるようです。
cumakのサイト（このサイト）を計測した結果
PageSpeed Insightsと、WebPageTestを使ってこのサイトを計測しました。
作ったときにすでにPageSpeed Insightsで計測しながらやっていたので、知っていたことですが、やっぱりこれだけ画像があると、LCPの対策がツライです。
画像を軽量化するためには、
１、最適化する
２、１からさらに様子を見ながら解像度を落とす
３、CSSでできるところは画像をつかわずCSSでやる
４、次世代フォーマット（Webpなど）を使う
などが挙げられます。
このサイトではすでに下記対策済みです。
１、最適化済み
２、水彩素材なのもあり、ボケてもいいものは選別して解像度を落としている
３、CSSでできるところはCSSでやっている
４、サイズの大きい画像はWebpを使っている
それでも合格に達しないので、単純にデザインに無理があると思っています。
私はデザイナーではないですが（デザインの知見はあるつもりですが）、仕事ではこういう感じのデザインは勧めません。自分のサイトだからできたことです。
また、WebPagetestではLCPは5秒という結果が出ました。PageSpeed Insightsと比べると厳しい結果です。危険信号出てますね…。
それ以外の部分ではまぁ…まぁ…な結果でした。
Security scoreはF判定ですが、クリックすると、「このWebサイトでは、脆弱なJavaScriptライブラリの既知のバージョンは検出されませんでした。」とかいてあったものの、
jQuery、lodashなどその他のライブラリには、新しい脆弱性が絶えず発見されていますという文言がありました。
ここの評価をあげるには、これらのライブラリを使わない限りは難しそうです。脆弱性が発見されるたびに20ポイントくらい下がるようで、結構厳しい判定だと思いました。
ちなみに、開発者ツールのPerformanceタブで、レイアウトシフトが発生していたところがあり、クリックすると左下のGithubのアイコンでした。こんな、position:fixedの要素がなぜ…と思って、heightを指定すると、レイアウトシフトが発生しなくなりました。
bottomからの位置を設定しているので、高さが決定した時に上に移動するからだろうか…と思いましたが、あくまで予想です。
まとめ
表示スピードはもともとSEOに影響する部分でしたが、指標が明確になったことでより重要課題になったと言えます。
特に、開発者だけでなくサイトの所有者が意識すべき課題としてこのようなツールが提供されているので、しっかりSEO対策していくことが必要だと感じました。
参考URL
https://web.dev/vitals/
https://web.dev/lcp/
https://web.dev/vitals-measurement-getting-started/
