2022/03/02

フィールドデータって知ってる？

Yusuke Wada

トラベルブックでは「スピード改善」という名の下「Core Web Vitals」のスコアを上げる努力をしています。Core Web VitalsというとLighthouseのスコアがいかに「100に近いか？」が焦点になりやすいのですが、本来はユーザーの環境でいかに「速いか？」が重要です。これはフィールドデータと呼ばれています。そこで今回は、フィールドデータとはなにか、ラボデータとの比較、確認方法、スコアを上げる方法などを我々の理解の範囲で綴っていきます。

Lighthouseのスコアが全てではない

Core Web Vitalsと聞くとあの「緑色の100」が浮かびます。 我々は「緑色の100」を目指して、TTFBを短くし、ヒーロー画像をpreloadし、width/heightを指定してレイアウトシフトをなくします。

これはGoogleのLighthouseというソフトウェアが算出したスコアで、ChromeのDevToolsやGoogle PageSpeed Insightsで使われています。我々は躍起になりがちですが、Lighthouseのスコアだけが全てではありません。「ページの速度」というのは閲覧するユーザーの環境によって異なるからです。例えば以下の要素があるでしょう。

  • 回線速度
  • デバイスのスペック
  • 画面幅
  • 国
  • 時間
  • …

Ligthouseにはスロットリングといった回線速度やスペックをエミュレートする機能がついていますが、それだけでは対応しきれません。

ラボデータとフィールドデータ

そこで、Googleはデータを2つの種類に分類しました。ひとつがラボデータ。これが例のLighthouseのスコアのことです。もう1つがフィールドデータと言います。これは実際のユーザーの行動に基づいてスコアリングされます。まさに「ラボ」と「フィールド」です。

さて、大事なこと。Googleでは検索結果の順位を決めるのにラボデータのものではなく、フィールドデータを参考にしています。確かに理にかなっています。大切なのは「ユーザーに近い」データです。

では、どうやってGoogleはフィールドデータを取得しているのか、というとChromeから取得しています。スコアを決めるために、自らが開発しているブラウザを使っているわけですね。これらは「Chrome User Experience Report=CrUX」と呼ばれています。Googleのページにはこのように書かれています。

The Chrome User Experience report is powered by real user measurement aggregated from Chrome users…

Chrome User Experience Report  |  Chrome UX Report  |  Google Developers

つまり、ラボデータはフィールドデータを向上させるための「あくまで」指標として存在しています。 CrUXは直近28日以内のデータをもとに算出されます。スコア向上のための施策をして結果を確認するのに、28日待つのは大変ですし、その間に他の施策をしたら、因果関係が把握できなくなります。ラボデータは「手っ取り早く」スコアを知るためのものです。

フィールドデータの確認方法

フィールドデータを確認する最も簡単な方法はGoogle Search Consoleを見ることです。Search Consoleでは「ウェブに関する主な指標」としてフィールドデータの遷移をグラフで表示しています。データのソースが「Chrome UXレポート」となっているので分かるでしょう。

CrUXは一般に公開されているので、自身のサイトだけではなく、他サイトも知ることができます。 CrUXはGoogleが提供する以下の方法でも確認できます。

  • Chrome UX Report APIを叩く。
  • Google BigQueryに蓄積されているデータを引っ張ってくる。

また、あえて言及してこなかったのですが、Google PageSpeed Insightsでも「実際のユーザーの環境で評価する」という項目がフィールドデータとなっています。ページ単位とオリジン単位で知ることができます。

このスコアをラボデータと比べると面白いです。Lighthouseでは100点だった項目が、Search Consoleで警告されている、なんてことはよくあります。というか、まさにトラベルブックもそこで悩んでるところです。

ラボデータとの乖離の例

この通り、ラボデータとフィールドデータには当然ながら乖離があります。 LCPは環境によって大きく変動しそうです。加えて、CLSについて。 Lighthouseのスコア上は「0」でありながら、フィールドデータではレイアウトシフトが発生していました。 これ、言われてみれば当然なのですが、ファーストビューではCLSが発生してなくとも、ページを下にスクロールするとCLSが起こることってありますよね。おそらくあれなんです。そして、スクロール中のどこで発生しているかを知る方法があります。

web-vitalsライブラリ

CrUXがChromeから収集されるとして、そもそもChromeは一体どのようにスコアリングしているのか。 web-vitalsライブラリが参考になります。

web-vitalsはJavaScriptのライブラリでnpmやCDN経由で使うことができ、ブラウザのAPIを使って、Core Web Vitalsの各指標を取得します。

import { getLCP, getFID, getCLS } from "web-vitals";

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

例えば、この値を直接Google Analyticsに送って集計できます。また、同じ測定方法を使ったChromeの拡張機能「Web Vitals」が便利です。

この拡張機能を使えば、上記「スクロール中にCLSが発生する」を確認できます。

実はこの「テックブログ」のページもファーストビューではCLS「0」で、スクロールするとレイアウトシフトが発生したります。 「Fastlyについて知らないかもしれない30のこと」 のページでは（この記事もそうでした）、最下部に embed.ly を使って、Wantedlyのページを埋め込んでるのですが、表示領域近くにこない限り高さが決まりません。「Web Vitals」エクステンションで確認すると、しっかり「赤」になりました。

これはラボデータには現れない、フィールドデータと言えるでしょう。

RUMツール

web-vitalsライブラリもしくはそれ相当のもので「CrUXの元となる」データが測れるのは分かりました。 これを集計して視覚化したら、ラボデータに加えて、便利な指標になることでしょう。

「RUM=Real User Monitoring」という概念があります。これを具現化するツール・プラットフォームがたくさんあるのですが、CWVに対応するものもあります。Datadogや、はたまた面白いところでは Vercel Analytics などです。

その中でも最近トラベルブックでは Cloudflare Web Analytics を使っています。

無料で、CDNから配信されたJavaScriptを一個読み込ませるだけで設置が完了する手軽さがよいです。

管理画面を見ると、先程のCLSの発生なんかがよく分かります。「p.article__text」とか「div.topic--cover__imageWrapper」といったDOMレベルで指摘してくれます。

LCPも同じくどこの要素で何秒かかったか分かります。

Cloudflare Web Analyticsを使えば、Lighthouseでは分からなかった問題点がすぐ把握できるので、重宝しています。

フィールドデータを上げる努力

Lighthouseのスコアに影響がなくとも、フィールドデータに反映される施策があるのならばやった方がいいでしょう。 例えば、トラベルブックではService Workerを入れてドキュメント、アセット、AMP用のスクリプトをキャッシュさせています。

また、トラベルブックのページは Fastlyを導入して HTTP/3に対応しました。HTTP/3は回線が貧弱なほど従来のプロトコルに比べて優れていると聞くので、フィールドデータの向上が見込まれます。

冒頭に書いたことですが、Ligthouseのスコアが全てではないのです。

まとめ

以上、駆け足でしたがフィールドデータについてまとめてみました。 トラベルブックではラボデータとフィールドデータの2つをみつつ、速度改善を日々行っています。 フィールドデータの向上は、Googleの順位を上げるだけではなく、ユーザー体験として大事だと改めて感じました。

エンジニア募集中

トラベルブックではエンジニアを募集中です。 一緒に速いWebを作りましょう！

フロントエンド