ホームページの表示速度測定で知るべき重要ポイント

はじめに

本記事はホームページの表示速度（ページ読み込みの速さ）を測定し、改善するための実践的な情報をまとめた入門ガイドです。特にGoogleが提供する無料ツールを中心に、代表的な計測方法、評価指標、スコアの見方、そして測定から改善までの一連の流れを分かりやすく解説します。

目的

• サイトの表示速度がなぜ重要かを理解すること
• 適切な計測ツールを選び、正しく使えるようになること
• 測定結果をもとに改善策を考え、実行できるようになること

想定する読者

ウェブ担当者、サイト運営者、マーケター、エンジニア初心者など、表示速度を改善したい方を想定しています。専門用語は必要最小限にし、具体例で補足します。

表示速度が重要な理由

表示が遅いと訪問者が離れ、機会損失につながります。検索結果での評価にも影響するため、ユーザー体験と集客の両面で重要です。例えば、画像が大きすぎたり外部スクリプトが多いと、読み込みが遅くなります。

測定の際の注意点

実際のユーザー環境（モバイル回線やキャッシュの有無）とラボ環境（テストツールでの計測）は結果が異なります。複数回の測定や異なる条件での比較を行ってください。

次章では、Googleが提供する主要な計測ツールとそれぞれの特徴を詳しく見ていきます。

Googleが提供する主要な計測ツール

概要

Googleは無料で使える表示速度やユーザー体験の計測ツールを複数提供しています。どれも目的が少しずつ異なるため、状況に応じて使い分けると効果的です。ここでは主要なツールをやさしく説明します。

PageSpeed Insights（おすすめの入口）

• 何をするか：URLを入れるだけでモバイルとデスクトップ両方のパフォーマンスを点数化します。
• 特長：0〜100のスコアで分かりやすく、改善案を具体的に示します。
• 使い方の例：サイトURLを入力→分析ボタン→改善提案と実行優先度を確認。

Lighthouse

• 何をするか：PageSpeedの裏で動く詳細診断ツールです。
• 特長：パフォーマンスだけでなく、アクセシビリティやベストプラクティスも評価します。
• 利用法：Chromeの開発者ツールやコマンドラインで実行できます。初心者はブラウザからの実行が簡単です。

Search Console（Core Web Vitalsレポート）

• 何をするか：実際の訪問者データに基づいてCore Web Vitals（主要指標）を監視します。
• 特長：実運用での問題を把握でき、改善の優先度を決めやすくなります。

Chrome UX Report（CrUX）とモバイル向けテスト

• CrUX：大規模な実ユーザーデータを集めたレポートで、競合比較に役立ちます。
• モバイルフレンドリーテスト：スマホでの表示や操作性を簡単にチェックします。

使い分けの目安

• 初めてならPageSpeed Insightsで現状把握。
• 詳細診断や改善の証拠が欲しいときはLighthouse。
• 実際のユーザー体験を追いたいときはSearch ConsoleとCrUXを使います。

各ツールを組み合わせることで、測定と改善の精度が高まります。

PageSpeed Insightsの評価指標とスコア基準

概要

PageSpeed Insightsは実際のユーザー環境と、ツールによる診断結果を組み合わせて評価します。主に6つの指標でパフォーマンスを判断します。

主要な指標（わかりやすく）

• LCP（Largest Contentful Paint）: ページの主要な見た目要素が表示されるまでの時間。例：トップ画像や大見出しが出るまで。目安は短いほど良いです。
• FID（First Input Delay）: 初回の操作に対する反応の遅れ。例：最初にボタンを押したときの反応遅延。古い指標ですが重要です。
• INP（Interaction to Next Paint）: ページ全体の操作感を示す新しい指標。複数の操作を通して平均的な応答性を測ります。
• CLS（Cumulative Layout Shift）: ページ表示中のレイアウトずれの合計。例：読み込み途中にボタンが動くとスコアが悪くなります。目安は小さいほど良いです。
• FCP（First Contentful Paint）: 最初のコンテンツが描画されるまでの時間。ユーザーに“表示された”と感じさせる指標です。
• TTFB（Time To First Byte）: サーバーが最初の応答を返すまでの時間。サーバー改善で短縮できます。

スコア基準

PageSpeedのスコアは0〜100で評価します。一般的な目安は次の通りです：50点未満は「遅い」、70点以上が改善の目安、90点以上で「速い」と判断されます。目標は高く設定するほどユーザー体験が良くなりますが、段階的な改善が現実的です。

測定の注意点と対策

スコアは条件やタイミングで変動します。したがって複数回測定し、異なる端末や回線で確認してください。優先度はまずLCPやINP（操作性）とCLS（視覚の安定性）を改善することです。測定結果を見て小さな改善を繰り返すと、確実に体感品質が向上します。

その他の主要な計測ツール

概要

PageSpeed Insights以外にも多様な無料・有料ツールがあります。目的に応じて使い分けると、より深い原因特定や現実のユーザー状況の把握ができます。

主なツールと特徴

• Lighthouse（Google）: ページの品質を自動で監査します。表示速度だけでなくアクセシビリティやSEOの改善点も示します。
• ChromeのPerformanceパネル: ブラウザ上で詳細な読み込み記録やCPU・メモリの消費を確認できます。開発時の挙動確認に便利です。
• WebPageTest: 詳細なウォーターフォール（読み込み順がわかる図）や複数地域・回線条件での測定が可能です。細かな再現試験に向きます。
• GTmetrix: 計測履歴や改善提案を分かりやすく表示します。定期的なチェックに便利です。
• Pingdom: シンプルで使いやすい速度テストと稼働監視が特徴です。チームでの報告に適します。
• Semrush: 主にSEOツールですが、サイト監査でパフォーマンス指摘や競合比較ができます。
• Site Relic（監視ツール類）: 継続的な監視や実ユーザーの計測（RUM）、アラート設定が可能です。

使い分けのコツ

• 初期診断はLighthouseやPageSpeedで広くチェックします。
• 読み込み順や個別リソースの原因追及はWebPageTestやChromeのPerformanceで深掘りします。
• 定期監視や実ユーザーデータが必要な場合はRUMや監視サービスを導入します。

実践例

開発中はChromeのPerformanceで問題再現→修正後にWebPageTestで複数条件で確認→本番は監視ツールで実ユーザーを継続観察、の流れが効率的です。

Googleアナリティクスを使用した測定方法

導入と前提

Googleアナリティクス（ユニバーサルアナリティクス）のトラッキングをサイトに導入していることが前提です。サイト速度のデータは自動的に収集されますが、標準ではサンプリングされるため、精度を上げたい場合はサンプリング率の調整が必要です。

サイト速度レポートを見る手順

1. 管理画面にログインします。
2. メニューから「行動」→「サイトの速度」を選びます。サマリー、ページ速度、ユーザータイミングなどのレポートが表示されます。
3. ページ一覧では、遅いページは赤、速いページは緑などで視覚的に確認できます。

指標の見方と具体例

• 平均ページ読み込み時間：ページ全体がブラウザで読み込まれるまでの平均時間です。目安として3秒未満が望ましいとされます。
• ドメイン検索時間やサーバー応答時間：どの工程で時間がかかっているかを把握できます。たとえばサーバー応答時間が長ければホスティングを見直します。

セグメント別の比較と分析方法

モバイル／デスクトップや国別、流入経路ごとにセグメントを作成し、速度差を比較します。例：モバイルで遅い場合は画像最適化や遅延読み込みを優先します。

カスタム測定（User Timings）とサンプリング

独自の処理時間を測りたいときはUser Timingsを実装します。重要なスクリプトの実行時間やファーストインタラクションの時間を送信し、詳細に分析できます。サンプリング率は管理画面やトラッキングコードで上げられますが、データ量に注意してください。

実務での使い方例

• 遅い上位ページを抽出し、影響の大きいページから改善する。
• セグメントでモバイルの問題を特定し、画像圧縮やCSSの最適化を施す。
• 定期的にCSVで書き出してチームで共有し、改善の効果を比較する。

以上の手順で、Googleアナリティクスを使って現状把握と改善優先順位の決定ができます。

測定と改善のプロセス

概要

表示速度改善は「測定→分析→改善→検証」を繰り返すサイクルが重要です。無料ツールを使って継続的にチェックし、優先度の高い問題から手を加えると効果が出やすいです。

測定の準備

• 対象ページを決める（トップ、主要導線、流入が多いページ）。
• 比較用の基準値を記録しておく（現在のスコアや代表的な指標）。
• ツールを選ぶ（PageSpeed Insights、Chrome DevTools、Lighthouse、Googleアナリティクスなど）。

定期的な測定手順

1. 同じ条件で計測する（モバイル/デスクトップ、回線速度条件）。
2. 複数回計測してばらつきを確認する。
3. スコアだけでなく、主要指標の数値（例：LCP、CLS、INP/応答時間）を記録する。

結果の分析ポイント

• どのリソース（画像、スクリプト、外部API）が遅いかを特定します。
• モバイルで悪化しているかデスクトップとの違いを確認します。
• 改善の効果を測るために、変更前後で数値比較を行います。

改善策の実施と検証

• まず影響が大きくて実装が簡単な改善（画像圧縮、キャッシュ設定、遅延読み込み）から着手します。
• 次にコード最適化（レンダーブロッキングの解消、不要な外部スクリプト削除）を行います。
• デプロイ後は同条件で再測定し、期待した改善が出ているか確認します。

運用のコツ

• 目標スコアや許容値を決めて運用する。
• 変更履歴を記録し、問題が出たらすぐロールバックできる体制を整える。
• 定期チェック（週次・月次）と、主要リリース時の測定をルール化して継続的に改善してください。