- パフォーマンス改善はどこから手をつけていいの？
- パフォーマンスが低い原因をどのように調べればいいの？
- 思うようにパフォーマンスのスコアが上がってくれない
以前、私が担当したサイトもPageSpeed Insightsのパフォーマンススコアは30点台と、お世辞にも良いとは言えない状態でした。しかし、試行錯誤を繰り返した結果、最終的には80点台まで改善することができました。
本記事では、その経験から得た「誰でも実践できるサイトパフォーマンス改善の進め方」を5つのステップに分けて解説します。具体的な手順と、私が特に重要だと考えているポイントをまとめましたので、ぜひ最後まで読み進めて、参考にしてください。
まずは現状を正しく把握しよう
パフォーマンス改善を始める前に、まずは「現状がどうなっているか」を客観的に把握することが重要です。
これには、以下のツールを使います。
| PageSpeed Insights | Googleが提供する無料ツール。実際のユーザー環境とラボ環境での計測が可能です。 |
|---|---|
| Lighthouse | Chromeのデベロッパーツール機能の一つ。ローカル環境でも計測できることが特徴です。 |
これらのツールを使って、あなたのサイトが現在どのくらいのスコアで、具体的にどんな問題点を抱えているかを確認しましょう。
上記ツールのそれぞれの使い分けとしては、
PageSpeed Insightsは、Web上にアップしているサイトでないと計測できないのと実際のユーザー環境で計測できるという特徴があるので、本番環境のスコア計測に使用していました。PageSpeed InsightsとLighthouseでスコアが微妙に変わってくるので、本番環境の計測はどちらか片方に固定するのがおすすめです。
Lighthouseは、施策を検討する段階で、一度ローカル環境で効果があるかを確認したい際に使用していました。ローカル環境と本番環境ではスコアに差分が出ますが、何%くらい改善したかの確認はできるので、施策の検討や優先順位決めなどの材料として使っていました。
PageSpeed InsightsやLighthouseの各指標の見方などについては、既に多くの記事で紹介されているかと思いますので、本記事では割愛します。
改善の目標値を設定しよう
現状を把握したら、次に「何の指標をどこまで改善するか」の目標値を決めます。
Googleが推奨する指標は、Core Web Vitalsです。
Core Web Vitals の指標
Google Developers
・Largest Contentful Paint（LCP）: 読み込みパフォーマンスの尺度。優れたユーザー エクスペリエンスを提供するには、ページの読み込み開始から 2.5 秒以内に LCP を実現するようにします。
・Interaction To Next Paint (INP): 応答性の尺度。優れたユーザー エクスペリエンスを提供するには、INP を 200 ミリ秒未満に収めるようにします。
・Cumulative Layout Shift（CLS）: 視覚的安定性の尺度。優れたユーザー エクスペリエンスを提供するには、CLS スコアを 0.1 未満に収めるようにします。
他にもFCPやTBTなど重要な指標はありますが、指標によってパフォーマンスへの影響度が異なります。影響度が大きい指標は優先的に修正する必要があるので、目標値を定めると良いでしょう。
各指標が与える影響度については以下の記事でまとめています。
以下はGoogleが定めている各指標を評価するための閾値なので、目標値を定める際の参考になると思います。
Desktop
| 良い | 改善が必要 | 悪い | |
|---|---|---|---|
| FCP | 0〜940ms | 941ms〜1600ms | 1601ms〜 |
| SI | 0〜1320ms | 1321ms〜2310ms | 2311ms〜 |
| LCP | 0〜1210ms | 1211ms〜2410ms | 2411ms〜 |
| TBT | 0〜150ms | 151ms〜350ms | 351ms〜 |
| CLS | 0〜0.10 | 0.11〜0.25 | 0.26〜 |
Mobile
| 良い | 改善が必要 | 悪い | |
|---|---|---|---|
| FCP | 0〜1820ms | 1821ms〜3010ms | 3011ms〜 |
| SI | 0〜3420ms | 3421ms〜5830ms | 5831ms〜 |
| LCP | 0〜2520ms | 2521ms〜4010ms | 4011ms〜 |
| TBT | 0〜200ms | 201ms〜600ms | 601ms〜 |
| CLS | 0〜0.10 | 0.11〜0.25 | 0.26〜 |
最初はすべての項目を「良い」にすることは難しいかもしれませんが、まずはパフォーマンススコアを60点以上にする、またはCore Web Vitalsの主要な指標を「改善が必要」まで改善するといった目標を設定してみましょう。
ボトルネックを正確に調査しよう
現状把握と目標設定が終わったら、いよいよ改善の鍵となる「ボトルネック調査」に入ります。
多くの開発者がこの段階で「おそらくここが原因だろう」と推測して進めてしまいがちですが、それでは効果が出にくいのは目に見えています。「推測するな、計測せよ」という言葉を常に心に留めておいてください。
ボトルネック調査は、以下の手順で行います。
目標で定めた指標やスコアが低い指標の指摘項目を確認します。特にスコアに悪影響を与えている項目には赤色で色付けされているので、その項目を重点的に確認しましょう。
指摘された項目について、具体的に何が原因でパフォーマンスを悪化させているかを調査します。
このとき、ほとんどの場合はChromeのデベロッパーツールにあるPerformanceタブとNetworkタブだけで十分です。
例外として、PageSpeed Insightsの指摘が明確な場合は、これ以降の工程が不要なケースもあります。
TTFB（Time to First Byte）のようにサーバーサイドの処理が原因である可能性もあるため、その場合はソースコードの確認やプロファイリングも視野に入れます。
デベロッパーツールでの計測方法については、以下の記事が参考になると思います。
施策の検討と優先順位付けをしよう
ボトルネックが特定できたら、実装レベルの具体的な改善策を検討しましょう。
改善策を検討する際は、以下2つの観点で施策に優先順位を付けましょう。
- パフォーマンススコアへの影響度：スコアへの影響度が大きい施策を優先しましょう。
- 工数が少ないこと：なるべく短時間で実装できる施策を優先しましょう。
- 影響範囲が少ないこと：既存機能や動作に影響を与えにくい施策を優先しましょう。
例えば、Nuxt.jsを使っている場合、Google Fontsの最適化は、既存のモジュールを使えば1〜2時間で実装でき、影響範囲も少ない施策です。何でもかんでもモジュールをインストールするとメンテナンスコストが増えていくので、バランスは考えながらですが、なるべく車輪の再開発を行わないよう効率的に施策を検討するのが良いと思います。
独自で実装しても工数があまりかからないし、影響度も少ないといった場合は独自で実装して、Google Fontsをセルフホスティングさせるとかサードパーティーをworkerスレッドで実行するといった独自で実装しようとすると工数がかかる項目に関してはモジュールを使うと良いかなと思います。
具体的な施策については、以下の記事を参考にしてください。
必ず効果を計測しよう
施策を実装して終わりではありません。改善策をリリースしたら、必ず効果を計測し、目標値と照らし合わせることが非常に大切です。
「ある問題を解決したと思ったら、その改善策のせいでまた別の項目の指摘点が増えた」というケースは珍しくありません。新しい施策によってパフォーマンスが悪化してしまった場合は、その施策を元に戻すことも視野に入れる必要があります。
このステップを繰り返すことで、パフォーマンス改善は着実に進んでいきます。
まとめ
最後まで読んでいただき、ありがとうございました！
サイトパフォーマンス改善は、一見難しそうに見えますが、「現状把握→目標設定→原因調査→施策の実施→効果測定」というPDCAサイクルを回すことで、着実に進められます。
ぜひ本記事で紹介したステップを参考に、サイトのパフォーマンス改善に取り組んでみてください。パフォーマンスが上がれば、ユーザー体験の向上だけでなく、SEOにも良い影響をもたらすはずです。
最後にパフォーマンス改善を行うにあたって、非常に役立った本を紹介します。
Web上にコンテンツが表示されるまでのフローをわかりやすくまとめられた本なので、どこにボトルネックがありそうか仮説立てできるようになると思います。
