Webサイト高速化「改善策◯◯選」を試す前に。

はじめに

こんにちは、クラウドエース第四開発部の安田です。
業務でウェブサイトのパフォーマンス改善に取り組んだ際、何から始めれば良いか迷った経験があります。その経験から、このように進めると良さそうだと感じた点を記事にまとめました。

なぜパフォーマンス改善が必要？

ウェブサイトの読み込み時間が 3 秒を超えると多くの訪問者はサイトを離脱してしまうという有名な話があるように、サイトの表示速度やパフォーマンスがユーザーに与える影響はかなり大きいので頑張って取り組んで行きましょう！

図：モバイルサイトの速度の重要性 - Think with Google より引用

まず何から始めるべき？

Web サイトの高速化やパフォーマンス改善を任せられた人がまずやることってなんでしょう。

私がはじめにやったことは、
とりあえず Google 検索で「サイト高速化」「フロントエンド　パフォーマンス改善」などで検索
です。

「改善策〇〇選」のような記事を片っ端から開き、効果のありそうなものからとりあえず進めるか。といった感じ。

よく挙げられている改善策としては、以下のようなものがありました。

• 画像の圧縮、遅延読み込み
• CSS/JavaScript の最小化、バンドル
• CDN の利用
• キャッシュの利用
• ウェブフォントの最適化

画像はウェブサイトの中でもファイルサイズが大きく、容量の多くを占めるため読み込みにかなりの時間を要するため、最適化して読み込み速度を向上させましょう。
転送するデータ量を減らすためにコードを軽量化しましょう。
リソースの読み込み時のリクエスト回数を減らすためにファイルをバンドルしましょう。

などなど、それぞれが改善に繋がるのは理解できますが、どの対応がどこに影響しその結果どのようにパフォーマンス改善につながるのかがイマイチわかりませんでした。

改善を進めるためには、まず現状を正確に把握することが重要です。

手当たり次第に対応していくのではなく、まずは計測し、視覚的に現在の Web サイトの問題点を知ることから始めるのが良いでしょう。

パフォーマンスの測定

測定ツールはいろいろありますが、今回は PageSpeed Insights を使用します。
Google が提供する Web サイト分析ツールです。

PageSpeed Insights はフィールドデータ（実際のユーザーのデータ）とラボデータ（シミュレーションデータ）の 2 種類のデータを提供します。

フィールドデータ

ここにはページにアクセスした実際のユーザーから収集されたデータが表示されます。
本番環境での実際のユーザー体験を知るために有用です。

図：ウェブに関する主な指標の評価

ウェブに関する主な指標として、ここには 5 つ表示されています。

指標	内容	良好な値
LCP	ページのメインコンテンツが表示されるまでの時間	2.5 秒以下
INP	ユーザー操作への応答性	200 ミリ秒以下
CLS	ページの表示中に発生する、ユーザーが意図しないレイアウトのずれ（ガタつき）を測定	0.1 以下
FCP	ページの読み込みが開始されてから、最初のコンテンツ表示までの時間	1.8 秒以下
TTFB	サーバー応答までの時間	0.8 秒以下

図の LCP を例にとると、実際サイトに訪れたユーザーの 92 %が 2.5 秒以下の良好な LCP を体験しているということになります。

このようなフィールドデータは通常、CrUX レポートから取得されます。

CrUX レポートは、実際の Chrome ユーザーがウェブを閲覧した際のパフォーマンスデータをまとめたもので、PageSpeed Insights フィールドデータの箇所の下にある「過去 28 日間（履歴）」のリンクから確認することができます。

図：CrUX レポート画面

ここに示される Core Web Vitals というものがサイトにおいて最も重要視すべき指標です。
Google が検索ランキングの要素として重視しているだけでなく、実際のユーザー体験に直結する重要な指標だからです。

2025 年現在の Core Web Vitals は、以下の 3 つの指標で構成されています。

1. LCP (Largest Contentful Paint)：ページのメインコンテンツが表示されるまでの時間
2. INP (Interaction to Next Paint)：ユーザー操作への応答性
3. CLS (Cumulative Layout Shift)：ページの表示中に発生する、ユーザーが意図しないレイアウトのずれ（ガタつき）を測定

これらを最適化することでサイトのユーザビリティと検索エンジン評価が向上し、より多くのユーザーに届きやすくなります。

ラボデータ

ラボデータは Lighthouse というシミュレーションツールによって、ウェブページを読み込んだ際に生成されるデータです。

各指標毎にスコア化されているので直感的でわかりやすく、よくサイト改善の指標として用いられています。

図：パフォーマンス診断結果

実際のユーザー環境が反映されるフィールドデータとは違って、こちらは制御された環境で一貫した結果が得られるため、開発者がパフォーマンス改善を行う際に役立ちます。

ここに示される指標は以下となってます。

指標	内容	良好な値(PC)
FCP	最初のコンテンツ（テキストや画像など）が画面に表示されるまでの時間	0.9 秒以下
LCP	ページのメインコンテンツが表示されるまでの時間	1.2 秒以下
TBT	メインスレッドがブロックされ、ユーザー入力に反応できない合計時間	150 ミリ秒以下
CLS	ページの表示中に発生する、ユーザーが意図しないレイアウトのずれ（ガタつき）を測定	0.1 以下
SI	ページの読み込み中にコンテンツがどれだけ早く視覚的に表示されるかを示す指標	1.3 秒以下

良好な値のしきい値がフィールドデータの方と違いますが、Lighthouse のテストは PC（デスクトップ）の場合、モバイルよりも厳しいしきい値が設定されています。

少し下にスクロールすると改善が必要な項目が以下のようにリスト化されています。
各指標ごとに項目を絞り込むこともできるので、改善したものがどの指標に影響するのかが一目でわかります。

図：パフォーマンスを向上のための具体的な内容などが示されている

書いてある内容は「改善策〇〇選」の内容と一致するものも多く納得感がありますが、
やみくもに改善に取り組むよりも、このようなデータを参考に必要な改善策を適用していくのが良いでしょう。

改善計画をたてる

Lighthouse で示された改善項目を参考に、改善計画を立てていきます。

課題表の作成

課題表を作成します。
ボトルネックとなる課題、それに対する改善方法に加え、関連する指標も記載していきます。

課題	改善方法	関連する指標	優先度
効率的なキャッシュ保存期間を使用する	静的アセットのキャッシュポリシーを 1 年(Cache-Control: max-age=31536000)に設定	LCP,FCP	中
画像配信を改善する	対象画像を適切な表示サイズ(400*300)に変更する	LCP,FCP	中

優先度をつける

各項目の優先度は「効果が大きく、かつ実施する労力が小さいもの」を最も高く設定します。
逆に作業範囲の割にスコア改善がそこまで見込めないものなどは優先度を低くしてもよいでしょう。
「実装コスト」「効果の大きさ」の 2 つの観点で優先度を決めると良さそうです。

実装コスト

修正作業に必要な開発リソースや技術的な難易度を評価します。
まずは手軽に実装を進められそうなところから進めるでも良いでしょう。

例えば、HTML の修正や簡単な設定変更で対応できるものなどは低コストで実装ができますが、
未使用の JavaScript や CSS の削除やサードパーティ製スクリプトの最適化、サーバーの応答時間の短縮などはコード構造の根本的な見直しや、インフラの変更が必要になる場合があります。
比較的大きな改修となり、十分な計画と工数が必要です。

WordPress を利用している場合、画像の圧縮配信や WebP 変換、キャッシュなどプラグインを導入することで手軽に対応できる場合もあります。
ですが、それにより JavaScript や CSS が新たに読み込まれることでメインスレッドの処理を阻害するなど「良かれと思って入れたのに別の問題を引き起こして逆に遅くなった」という事態は起こり得ます。
導入前と導入後で計測を行い、スコアの悪化や新たな警告が発生していないかを確認しながら進めた方がよいでしょう。

効果の大きさ

例えば Lighthouse だとそれぞれの指標ごとに Weight が設定されています。

図：Lighthouse Scoring Calculator

指標	Weight
FCP (First Contentful Paint)	10 %
SI (Speed Index)	10 %
LCP (Largest Contentful Paint)	25 %
TBT (Total Blocking Time)	30 %
CLS (Cumulative Layout Shift)	25 %

現在のバージョン（v10）では LCP、TBT、CLS の Weight が高く、全体のパフォーマンススコアに与える影響が大きいので、ここに影響する課題の優先度をあげて対応すると良いと思います。

ここまでできれば、改善作業 → 効果測定 → 改善作業を繰り返していきます。

パフォーマンス改善は継続が大事！

Web サイトのパフォーマンスは、コンテンツの追加や機能改修、外部サービスの利用など、様々な要因で変動します。一度改善したからといって終わりではありません。

定期的に計測を行い Core Web Vitals や Lighthouse のスコアを監視することで、パフォーマンスの低下を早期に検知して継続的な改善に繋げることができます。

また、近年は LLM の登場によって「LLMO（Large Language Model Optimization）」や「GEO（Generative Engine Optimization）」といった新しい最適化の概念も出てきていますが、Core Web Vitals やパフォーマンス改善の重要性を損なうものではないはずです。

ウェブサイトの提供者がやるべきことは変わらず、これまで通りパフォーマンス改善に取り組むことでサイトの信頼性や安定性を担保することが大事だと思います。

この記事があなたの Web サイトパフォーマンス改善の一助となれば幸いです。