この記事は Ateam Hikkoshi samurai Inc.× Ateam Connect Inc. Advent Calendar 2021 18日目の記事です。
はじめに
ページパフォーマンスがSEO指標として明示化されて以後、改善に取り組んでいるエンジニアも多いと思います。
自分も半年ほど前に本格的に改善を行い、自社サービスサイトのCore Web Vitalsを改善しました。
Core Web Vitals は「LCP / FID / CLS」の３指標が、「良好・要改善・不良」の３段階で評価されます。
改善前は多くのページが「要改善」、もしくは「不良」になっていましたが、全ページ「良好」にまで持っていくことができました。
ただ当初はこの分野に詳しくなく、道中なかなかに苦労をしました。
今回は自分がその中で「最初に知っておきたかった...」と思ったことを、３つに厳選してお伝えしたいと思います。
具体的には以下の３つ。
- そもそもなんでやるのか理解しておく
- 指標の見方と選び方
- 手段にとらわれない
それでは早速1から。
1. そもそもなんでやるのか理解しておく
ページパフォーマンスの改善に取り組み始める動機は様々だと思います。
自分にとってのきっかけは、SEO観点での Core Web Vitals 改善でした。
多くの場合の理由になるものだと思います。
ただ他にも改善をするメリットがあります。
大きく大別すると、以下の２つに集約されると思っています。
- ユーザー満足度(UX)の向上
- 事業指標の向上
2の事業指標とは、以下の様なものを指します。
- 直帰率
- CVR
- SEO順位 ほか
事業などによって、どこに比重を置くかがそれぞれ違うと思いますが、
取り組む当人が多面的にメリットを理解しておくことは重要だと考えます。
その理由としては、「組織活動において推し進めるための合意を得やすくなるから」です。
例えばエンジニア発信でパフォーマンス改善を始めようとする場合、経営層や事業部に説明をする必要があります。
他には改善のさなかで、事業メリットを含む機能やを取り下げたいケースがあります。
（例：あまり活用されていない3rdパーティスクリプトの削除など）
こういった場合、パフォーマンスとベネフィットのトレードオフになります。
実施価値を当事者が把握していないものにOKが下るわけはないので、必然的に理解が必要です。
これらは事業上の裁量などは関係なく、そもそも説明責任として知識を備えておくことがエンジニアの義務になると思います。
目的の詳細についてはこの資料がよくまとまっています。
2. 指標の見方と選び方
序文で触れたCore Web Vitalsだけでなく、ページパフォーマンスには様々な指標があります。
自分が改善に取り組みはじめて最初に思ったのは、「指標多すぎ・・結局どれ見たらいいんだろう？」ということでした。
指標というのはそれぞれに目的と見方があり、切り口も計測方法などで異なります。
どういう場面でどの指標をどう活用するか、説明していきます。
今回は各指標の意味については説明しません
そこから知りたい方は web.dev などを参照してください。（最後にリンク）
計測の手法
まずはじめに知っておきたいのは、計測手法が大きく２種類に分かれるということです。
それは以下の２つです。
- リアルユーザーモニタリング
- 合成モニタリング
指標をどう活用するであれ、これらは大前提となってきます。
具体的に見ていきます。
リアルユーザーモニタリングとは
英語では Real User Monitoring (RUM) と書きます。
ユーザーの実働環境で計測された指標です。
以下で計測された指標はRUMになります。
- Chrome UX Report（CrUX）
- サーチコンソール (上記のCrUXを参照している)
- PageSpeed Insights (以下PSI) の「フィールドデータ1」（これもCrUX）
- NewRelic Browserによる計測データ など
合成モニタリング
英語では Synthetic Monitoring 言います。
可能な限り同一の環境（ネットワーク、マシンスペックなど）で計測する方法です。
- Webpagetest
- Lighthouse (CLI / ブラウザ)
- PageSpeed Insights の「ラボデータ」（内部的には Lighthouse）
このうちLighthouseは少し注意が必要です。
Lighthouse ではデフォルトで MotoG4 というミドルレンジ端末相当のCPUとSlow LTEネットーワークがシミュレートされます。（バージョンによりますが）
このシミュレートは端末スペックにいくらか影響されます。（参考）
僕がM1で計測した場合と、IntelMacで計測した場合では M1 のがかなり高く出ました。
また、Devtool の Lighthouseタブ で計測する場合は、ブラウザの拡張機能にも影響されるのであわせてご注意を。
指標の活用
指標の活用方法は様々ですが、以下２つについて説明します。
- KPI
- 調査
1. KPIにする指標
KPIにするべき指標はリアルユーザーモニタリング(以下 RUM)で計測された指標がおすすめです。
RUMをKPIとしたい理由は、「1.そもそもなんでやるのか理解しておく」で触れたそれぞれがこの値を参照しているからです。
目的をざっくり振り返ると ①UX ②事業指標(SEO, CVR, 離脱率など)という話でした。
まず①は実ユーザーの体験が指標になりますのでそのままです。
次に②、例えばSEOについてはCore Web Vitalsが参照されます。
自分のWebサイトにおけるCore Web VitalsがGoogleにどう判定されているかは Google の サーチコンソールで見ることができます。
このサーチコンソールに表示されているデータの参照元は CrUX というデータであり、RUM になります。
であればこそ、SEOのために改善するのであれば RUM を見るべき、という結論になります。
誤解のないように言っておくと、合成モニタリング指標を見るなということではありません。
最終的には RUM を見るべきだよね、というぐらいのスタンスです。
2. 調査で活用するべき指標
調査においては合成モニタリングを参照するべきだと思います。
そもそもRUMは改善後からデータが反映されるまで蓄積を待つ必要があります。
言わずもがな、調査でPDCAを回すためには不向きです。
調査時には検証用環境などでPSIやLighthouseで条件を変えながら計測することがおすすめです。
というか自然とその選択肢になってくると思います。
このときに気をつけるべきは以下２点です。
- 実行ごとの環境が変化していないか
- 値のブレが大きくないか
まず1ですが、実行ごとにCPUやネットワーク環境などが変わっていないかしっかり保証してやる必要があります。
条件変数の変化多いと比較ができません。
そして2, PSI や Lighthouse の値はアーキテクチャにもよりますがかなり変動します。
特に3rdパーティスクリプトが多いと顕著に感じます。
対策は難しいのですが、自分は PSI の API で複数回取得させて平均値を取り、平準化させていました。
Lighthouse CLI でも同様のことができると思います。
合成モニタリングにおけるDevtoolのTIPS
実際の検証にはChrome Devtool がかなり重宝しました。
タブとしてはSource, Network, Performance, Lighthouse です。
自分のユースケースの場合、
Code Splitting をしたあとに NetworkタブからRequest Blocking をして原因切り分けをするのが、かなり効率が良いと感じました。
一見難解なPerformanceタブの使い方については、超速本とメルカリさんの記事がわかりやすかったです。（最後にリンク貼っておきます）
3. 手段にとらわれない
ページパフォーマンス改善後に共有を求められたとき、横展開のために「どんな手段で改善したか」を聞かれることがいくらかありました。
自分としてはこれにはあまり意味がないと考えています。
なぜなら多くの場合、必要な改善要素はドメインによって異なってくるからです。
なのでまずやるべきは、「どの手段が効果的か調べる」ではなく、「どの指標をどれくらい改善するために、何が課題かを追求する」ことです。
そしてそのために基礎知識を押さえることは、案外近道です。
仮説立ての制度など、効率が変わってきます。
また手段、という点で盲信してはならない代表的なものがあります。
それは Lighthouse(PSI) の「指摘項目」です。
着手当初に知識も乏しかったことから当てずっぽうで改善項目に手を付けましたが、費用対効果は芳しくありませんでした。
自分も「１に計測、２に改善」という基本はわかっていたつもりでしたが、見当がつけられなかったときにうっかりやってしまいました。
実施前に自分の頭で考える、検証するということは必ずやるべきです。
おわりに
もっと体系的に学びたい、という方には web.dev と 超速本 をおすすめします。
（自分はそれらから大半を学びました。下にリンク貼っておきます）
web.devはパフォーマンス改善における最高の教材になっています。
Google運営ということもあり、英語がきれいなので日本語翻訳しても大体そのまま読めます。
指標、改善手段など幅広く学ぶことができるので、いまから改善に本格的に取り組むという方はぜひ読んでみることをおすすめします。
参考外部リンク
Web.dev: Web Vitals と Metrics をまず読むのがおすすめです
明日は我らがボス、@hironey さんの担当日です！ドキドキ、ワクワク・・・！
-
ページからは消えてましたが、ドキュメントには残っていたのでこの呼称としています ↩