ハローWeb高速化シリーズはご無沙汰となりました。今回は"何を以って高速化したといえばいいのか？"という話をします。
率直に、Page Speed Insightsに対してこんな思いがありました。
- 80点以上合格点とされているが、無理では？
- 速くなっているはずなのにスコアに現れなくてつらい
- Core Web Vitalsの登場で「とにかくはやく"表示する"」よりも「はやくストレスなく"触れられる"」ことの重要性が増してきた
Page Speed Insights、もしかしたらあまり見なくてもいいのでは？説を抱き、AutoReserveでのパフォーマンス改善を通してこの説は正しいかもしれないと実感した筆者が、"Web高速化 パフォーマンス改善においてはPage Speed Insightsを見ない方が幸せになれる"という主張を以って話を進めていきます。
Next.jsにリニューアルしました
ハローが開発しているAutoReserveは、今年の夏からNext.js AppRouterで動作しています。それまではReact Router製react-native-webのSPAアプリケーションでした。パフォーマンス改善やSEO改善といった重要な要件を達成するためにNext.jsへのリニューアルに踏み切り、約4ヶ月の開発を経てリリースに至りました。リニューアルに関する詳しい話は、Next.jsからSPAに移行し、Next.jsに戻した話 - Hello Techにて紹介しています。
なぜ"Page Speed Insightsは見ない"？
Page Speed Insights（以下PSI）はもはや説明不要でしょう。ページが遅かったらまずはPSIをみてみよう、というような動きはかなり定着しているのではないでしょうか。
ハローではPSIのスコアではなく別のスコアをKPIに置くことで幸せになり、改善を実感しやすくなりました。私が思うPSIの難しさをいくつか紹介します。
1. PSI計測環境と一般的なデバイススペックとの乖離
このキャプチャはAutoReserveにおけるNext.jsリプレイス前後でのPSIのスコアを示したものです。
速さ・インタラクションなどあらゆる要素においてリプレイス後の方が優れている自負があるわけですが、PSIの点数は10点しか変わっていません。35点と点数は低いが、遅い！とは微塵も感じないほどのサクサク具合です。
思ったより点数が低く出てしまうのはPSIの計測環境が関連しています。以下のキャプチャはPSI実行環境のスペックで、この計測でのメモリ容量は434となっています。「CPU throttling: 4x slowdown」と書いてあるように、通常の1/4のマシンパワーで行われているようです。この数値はPSI登場以降ほとんど変わっていません。
一方で、実際のデバイスで実行するLighthouseで試してみるとメモリ容量は2,592（モバイルはもっと低くなるはず）と、PSIの環境とかなり乖離があります。
PSI登場時はユーザ離脱・SEOの影響を避けるため80点以上を目指すことが重視されていましたが、ウェブサイトに期待される機能が増えたことにより、PSIで高得点を獲得するのは難しくなっていると感じています。
2. 「Page Speed Insightsがよくなる = SEOが改善する」ではない
PSIには2種類の結果が表示されます。「実際のユーザーの環境で評価する (Discover what your real users are experiencing)」と「パフォーマンスの問題を診断する (Diagnose performance issues)」の2つです。 上記のNext.jsリプレイス前後でのPSIのスコアのキャプチャは「パフォーマンスの問題を診断する」の結果です。両者の違いはなんでしょうか？
実際のユーザーの環境で評価する
端的に「実際のユーザーがそのページにアクセスした時のスコアの集計」を示したもので、以前は「フィールドデータ」と表現されていました。過去28日間そのサイトにアクセスしたユーザー環境におけるスコアの移動平均値が表示されます。実際のデバイスで計測されたスコアということがとても重要です。
パフォーマンスの問題を診断する
「Googleが指定したマシンスペックでのスコア」を示したもので、以前は「ラボデータ」と表現されていました。フィールドデータと異なり、一般的には低スペックとされる環境下でのスコアです。
ここで大切なのは、SEO改善に直結するのは「実際のユーザーの環境で評価する」で表示された結果のみであるということです。これがCore Web Vitals、WebサイトのUXの良し悪しを表現する指標です。
PSIの登場時は「ページの表示速度」に重きが置かれていましたが、Core Web VitalsではUXというもっと広義な要素を取り扱っており、「ページを早く表示する」ことはあくまでUXを構成する要素の一つとし、重要なコンテンツが表示されるまでの時間を示すLCPのほかに、INP インタラクティブ性、CLS 視覚的安定性という要素を持っています。これが冒頭述べた「はやくストレスなく"触れられる"」ということです。
検索結果でのランキングを上げ、全般的に優れたユーザー エクスペリエンスを提供できるよう、サイト所有者の皆様には、Core Web Vitals を改善することを強くおすすめします。
と書かれています。PSIの結果については言及されておらず、あくま実際のユーザー環境で集計されたCore Web VitalsがSEOに影響を与えるということです。
PSIのスコア改善はCore Web Vitalsの改善に直結するが、PSIのスコアが改善しなくてもCore Web Vitalsが改善する可能性はおおいにあります。
こちらはAutoReserveにおけるSSR化以降のACore Web Vitalsの変化です。PSIのスコアは10点しか上がりませんでしたが、Core Web Vitalsの各指標は確実に変化していることがわかります。
特にLCPの改善は凄まじく、10月上旬まで良化し続け最終的には2,000ms以上の改善を見せました。あと少しでCore Web Vitals上Goodとなる数値です。PSIとCore Web Vitalsの結果は必ずしも一致せず、たとえPSIの結果が良くなくてもユーザーには高いパフォーマンスのアプリケーションを提供できているということが言えます。
3. Page Speed Insightsのスコア改善は簡単ではない
Web高速化1「メンバーを巻き込み、分析基盤を整える」 - Hello Tech こちらの記事でも触れたように、PSIのスコアが30点以下だった場合は点数を上げるのは容易なことではありません。高速化プロジェクト当初のAutoReserveのLCPは20,000msでした。この時点でLCPの点数は0点なのですが、1点獲得するためには少なくとも12,000ms減らす必要がありました。これは現実的な数値ではありません。20,000msから15,0000msに減らすだけでも非常に大きな改善で、スコアは変わらないが大きな変化を実感できるに足る改善です。
PSIにおいてはスコアに着目するのではなく、「各指標の秒数/数値」と"使用していない JavaScript の削減 xxx KiB 削減可能"などが書いてある「診断」の欄にフォーカスしてみるのが勘所かなあと考えています。
筆者がパフォーマンス面で大尊敬している日経新聞電子版は34点、そして最近本当に速くなり非常に使いやすくなった文春オンラインも33点です。 一方でCore Web Vitalsの方は両メディアともに全項目合格しており、「PSIのスコアが改善しなくてもCore Web Vitalsが改善する可能性が大いにある」「PSIとCore Web Vitalsの結果は必ずしも一致しない」というのはこの結果からもいうことができるでしょう。
Core Web Vitalsを確認する方法
ここまでで、PSIではなくCore Web Vitalsの数値を追った方がよさそうだということがお分かりいただけたと思います。ここからはCore Web Vitalsスコアをどのように追うべきかについてお話しします。
1. CrUX ダッシュボード
少し前までChrome UX Reportという名前だったと記憶してます。一般公開されていてある程度の訪問者数がいるWebサイトのドメインを入力すれば閲覧可能です。
Core Web Vitalsの各数値を月別・デバイス別に見ることができます。 以下のキャプチャはSSR化前後である7月と10月のCore Web Vitalsスコアです。Page Speed Insights上は10点しか変わりませんでしたが、Core Web Vitals目線では劇的に変化しています。
CrUXダッシュボードは最も手軽に閲覧できるデータですが、ページ別・日ごとに見ることができないため継続的に数値を追跡するのには向いておらず、簡単なサマリーとして使っています。
2. PSIの「実際のユーザーの環境で評価する」
こちらはCrUXダッシュボードと異なり、最新のCore Web Vitalsの数値を得られるという点が有用です。
「このURL」「オリジン」というタブがあり、それぞれURL単体 or サイト全体の数値を見ることができます。「このURL」タブはかなりのトラフィックを集めているページでないと有効にはならず閲覧するのが難しいと認識しています（AutoReserveで最もアクセス数があるレストランページでも非活性でした）。
最新の数値が見られますが、都度PSIでURLを入力して結果を待つ必要があるのが難点です。
3. サーチコンソール ウェブに関する主な指標
サーチコンソールではCore Web Vitalsのスコアが良くないURLと総数を確認できます。URLごとに各指標のスコアが見られるので問題の特定がしやすいです。 サイト全体でどれくらい不良URL（Core Web Vitalsが不合格なページ）があるのかわかるので、この3つなら一番使いやすいかなと思っています。
上記3つがCore Web Vitalsの数値を確認する主な方法ですが、それぞれ問題を抱えていると思っています。日時（day）・ページのディメンションとフィルタを持っていない点です。
1つ目の解決策として、こちらの記事で紹介した方法を改めて紹介させていただきます。 Google Apps Script, Spread Sheet, Looker Studioを使って簡単に日ごとのCore Web Vitalsのスコアを集計・可視化することができます。 tech.hello.ai
その場で現在のスコアが得られるPSIと違い、Core Web Vitalsのスコアは過去28日間のユーザーデータを集計したものなので、施策投入後は緩やかでありながら確実な変化があります。以下のキャプチャはNext.jsリニューアル前後のCore Web Vitalsスコア経過です。リリースした次の日から変化が見られ、だんだんとスコアが改善していったことがわかります。
ページごとのCore Web Vitalsの数値が見たいところですが、この仕組みでは見ることができないのが歯痒いです。どのページで問題が起きているのかは前述のとおりサーチコンソールで確認することができますが、私たちはSentryとVercel Toolbarを使って問題ページを特定するようにしています。
Sentry Web Vitals
Issue Trackerとして広く認識されているSentryですが、Core Web Vitalsの問題ページ特定に非常に有用です。
Sentry Web Vitalsの有用な点は主に4点あります。
- ページごと・デイリーでCore Web Vitalsを見ることができる
- ネットワークトレースも可能で、Core Web VitalsのボトルネックとなっているAPIリクエストを特定できる
- 「どのURLがそのサイトのCore Web Vitalsにおいて重要なのか」を示すOpportunityが見られる
- ↑のキャプチャをみると/ja/restaurants/*のOpportunityが一番大きく、レストランページの改善が一番インパクトがあるということが一目でわかる
Vercel Toolbar
AutoReserveはVercel上で動いており、Vercelのさまざまな機能を利用することができます。Toolbarは比較的昔からあった機能だと認識しているのですが（Preview環境においてUI上にコメントを打ったりするのがメイン機能だと思っていた...）、Core Web VitalsのなかでもCLSとINPの改善に非常に役立ちます。
ローカルやステージング環境で、要素がクリックされた時や表示された時にリアルタイムでINPとCLSの数値を確認できるようになっています。↓はINPの例です。
Vercel Toolbarを使うことで、INPとCLSの問題を開発の段階で潰すことができるのでCore Web Vitalsの数値悪化を最小限に抑えることができます。
これら2つのほかにも、Chrome Dev ToolsのPerformanceタブもすごく良いと感じています。Performance Insightsという機能は昔からありましたが、2024年はChorme Dev ToolsのメインタブPerformanceに統合され、一層進化しました。
以前までのPerfomanceは、最初のリクエストからページの表示まであらゆる情報を表示しており、Page SpeedやCore Web Vitalsに関連する情報は埋もれがちでした。今年のアップデートにより、Core Web Vitalsの改善に重きを置いたUIやレポーティングに生まれ変わっており、外部ツールに頼ることなくCore Web Vitalsの改善に取り組むことができるようになりました。
まとめ
PSIのスコアはSEOに直結しない
- SEOに影響があるのはCore Web Vitals
- PSIのスコアが良いに越したことはないが、PSIスコアが良くならなくてもCore Web Vitalsが良くなる可能性は大いにある
PSIの改善は難しい
- SSRしても10点しか上がらなかった
- PSIの計測環境は一般的なユーザーのデバイスよりも低スペックである可能性が高い
- PSIで見るべきはスコアではなく、秒数・診断結果の方（開発者の方向け）
「高速化」から「パフォーマンス改善」へのシフト
- Core Web Vitalsの定着によって、「はやく"表示する"」よりも「はやくストレスなく"触れられる"」が重要に
- コンテンツ表示速度のLCPのほかに、インタラクション性のINPと視覚安定性のCLSにも着目すべき
- PSIの100点満点のスコアではなく、Core Web Vitals各指標に目を向けたい
ユーザーのデバイスで計測されたスコアが重要
- Core Web Vitalsは実際のユーザーのデバイスで計測されたスコアが集計される
- PSIでは悪いスコアだが、Core Web Vitalsではいいスコアという状況が発生しやすい
- PSIのスコアだと「実際のところUXにどれだけ影響があったか」が分かりづらい
- できるだけ生きたデータを見ることが大切
Page Speed InsightsではなくCore Web Vitalsを見るべき
- PSIのスコアが変わらないことに一喜一憂する必要はない
- Core Web Vitalsのスコアは緩やかながら確実に変化をしていく。効果を実感しやすい
- PSIを使うなら着目すべきは各指標の秒数だが、これは開発者が着目すべき指標
- チーム全体として追うべきはCore Web Vitals
- Core Web Vitalsのスコア = SEOにおけるパフォーマンス目線の評価
- 実際のユーザーの体験がここに集まる
以上のような所感を持っています。
また、Core Web Vitals観点でのハローでの開発フローは以下のように定着してきているかと思っています。
- Vercel Toolbarを使ってINP・CLSに影響がないことを確認しながら実装を進める
- LCP要素となりうる画像はpreloadによる先読みができないかを検討する
- RSCでのAPIリクエストが並列で行われていることを確認する
- Looker StudioでCore Web Vitalsの変動を継続的に監視する
- スコアが悪化した場合はSentryのWeb Vitals or Search Consoleで問題ページの特定をする
どのようにCore Web Vitalsを改善したか、Next.js App Routerにおけるパフォーマンスを意識したコーディングについてもまた別の記事でお話しさせていただきたいと思います。
最後までご覧いただきありがとうございました！ パフォーマンス改善においては、Page Speed InsightsよりもCore Web Vitalsに着目した方がよいということが少しでも広まれば幸いです。
ハローではAutoReserveのCore Web Vitalsのスコアを完璧に近づけるために力を貸してくれるエンジニアを募集しています。
