ページ速度：指標・テスト・最適化のヒント

ページ速度とは？

ページ速度はウェブページのリソースがどれだけ速く読み込まれ、訪問者にとって利用可能になるかを示します。計測はデバイスとネットワークをシミュレートするラボ（合成）テストと、実際のブラウザから収集されるフィールド（実ユーザー）計測の2つの文脈で行われます。ページ速度は読み込み、ファーストペイント、対話性、視覚的安定性など、異なるユーザー中心の段階をとらえる指標で表されます。

なぜページ速度がSEOで重要か

高速なページはユーザー体験を改善します：待ち時間を短縮し、離脱を減らし、訪問者が早くコンテンツとやり取りできるようにします。検索エンジンはページ速度シグナルをランキング判断の一部として利用します。Core Web Vitalsはページエクスペリエンスに寄与するシグナルの一つですが、ランキングは多要素で速度だけで決まるわけではありません。なお2024年7月以降、GoogleはデフォルトでGooglebot Smartphoneを使ってサイトをクロールするため、モバイルのレンダリングやリソースはクロールとインデックス。

ページ速度の仕組み

ページ速度はサーバー／ネットワーク、リソースのペイロード、クライアント側のレンダリングの相互作用から生じます。主要な段階はDNSルックアップとTCP/TLSハンドシェイク、初回HTMLレスポンス、CSS/JS/画像のダウンロードとパース、最初の有意なコンテンツのレンダリング、そしてインタラクティビティを可能にするスクリプトの実行です。デバイスとネットワークを制御するラボツールと、実ユーザーのメトリクスであるフィールドデータの両方が、幅広い条件とオーディエンスにおけるパフォーマンス理解に必要です。

ページ速度の種類

一般的なカテゴリは次の通りです：

- Lab testing — LighthouseやWebPageTestのようなツールで行う制御された再現可能な監査。利点: 再現性があり回帰を特定できる。欠点: 実ユーザーのすべての条件を反映しない可能性がある。
- Field (real-user) data — 実際の訪問者から収集されるRUM（Chrome UX Report / PageSpeed Insightsのフィールドデータ、およびCore Web VitalsレポートがGoogle Search Consoleにあります）。利点: 実際の体験を示します。欠点: ノイズが多く、オーディエンスのデバイス/ネットワーク構成に影響されます。
- 知覚速度と技術的速度 — 知覚速度はユーザーがページを有用だと感じる時点（First Contentful Paint、Largest Contentful Paint）に焦点を当て、技術的速度は総ダウンロード時間やリクエスト数のような指標を含みます。

ページ速度の始め方

まずラボとフィールドの計測を組み合わせて始めてください。自サイトについては、Core Web VitalsレポートをGoogle Search Consoleで確認し、代表的なページについてPageSpeed InsightsやLighthouseの結果と比較してください。優先事項：レンダーブロッキングが大きいリソースを削減、画像とフォントを最適化、効率的なキャッシュとサーバー応答ヘッダーを利用、サードパーティスクリプトを監査。変更ごとに前後の計測を行い、影響を確認してください。

ページ速度の検証とトラブルシューティング方法

フィールドデータ: PageSpeed Insights と Core Web Vitals

PageSpeed Insights（利用可能な場合はCrUXのフィールドデータを表示）を使って実ユーザーのLCP、FCP、INPの分布を確認します。自分のプロパティについては、Google Search ConsoleのCore Web VitalsとPage ExperienceレポートでサイトレベルとURLレベルの傾向を把握してください。フィールドデータは実際のオーディエンス構成を反映するため、優先順位付けの指針になります。

ラボテスト: Lighthouse、Chrome DevTools、WebPageTest

Lighthouse（Chrome DevTools内またはコマンドラインで）やWebPageTestを実行して条件を再現し、ウォーターフォールチャートを確認します。DevToolsではPerformanceとNetworkパネルを使用してレンダーブロッキングなスクリプトや長時間タスクを特定してください。ラボテストはデバイスとスロットリングを制御して変更を一貫して比較できます。

サーバーおよびネットワークのチェック（curlとヘッダー）

簡易チェックにはcurlを使用します。レスポンスヘッダーのみを確認する場合: curl -I https://example.com/page（ヘッダーのみ返し、ボディは返しません）。指定したUser-Agentが受け取るHTMLを取得するには: curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page。Cache-Control、Content-Encoding、および Server-Timing ヘッダーを確認してキャッシュと圧縮を検証してください。

実用チェックリスト: ページ速度チェック

**Field Core Web Vitals** — 確認場所: PageSpeed Insights / Search Console Core Web Vitals — フィールドのLCP、INP、CLSの分布が対象オーディエンスで許容範囲内であること。

**Lab Lighthouse audit** — 確認場所: Chrome DevToolsのLighthouseまたはWebPageTest — Lighthouseで重大なレンダーブロッキングリソースがなく、Total Blocking Timeが低下していること。

**Server response time & caching** — 確認場所: curl -Iおよびサーバーログ — レスポンスに適切なCache-Controlが含まれ、通常負荷下で一貫して高速であること。

**Compression & payload size** — 確認場所: DevToolsのNetworkパネルまたはcurlの--compressed — リソースが圧縮され、転送バイト数が最小化されていること。

**Third-party scripts** — 確認場所: DevToolsのPerformance + Coverage — 非必須のサードパーティコードが遅延または削除され、長時間タスクが排除されていること。

**Mobile rendering parity** — 確認場所: Chrome DevToolsのデバイスエミュレーション + モバイルUAでのcurl — モバイル用のHTML/CSS/JSが意図したモバイルユーザー向けのコンテンツとパフォーマンス特性を提供していること。

よくあるページ速度の間違い

- ラボスコアのみに頼る：単一のLighthouse実行を決定的なものと見なし、フィールドデータを参照しない。
- レンダリングを阻害する大きな未最適化画像やフォント。
- 過度の同期的JavaScriptまたはインタラクティビティを遅らせる長時間タスク。
- キャッシュや圧縮ヘッダーの欠如や誤設定。
- メインスレッドに作業を注入する重いサードパーティスクリプト。
- サイトが主にGooglebot Smartphoneによってクロール・インデックスされるにも関わらずデスクトップのパフォーマンスだけを測定する。モバイル指標を優先する必要があります。
- クローラーとユーザーに異なるコンテンツを提供する（クローキング）ことは避け、デバイスクラスごとにモバイル/デスクトップ体験を最適化してください。

Technical SEOガイドを読む

よくある質問

Q: ページ速度は直接ランキングに影響しますか？
A: ページ速度はユーザー体験シグナルやCore Web Vitalsに寄与し、検索システムへの入力の一部となります。ランキング判断は多要素であり、速度改善は摩擦を減らしてエンゲージメント指標を間接的に改善し、検索エンジンが観察する指標を支援する可能性があります。

Q: どの指標を優先すべきですか？
A: ユーザー中心の指標を優先してください：読み込みではLargest Contentful Paint (LCP)、対話性ではInteraction to Next Paint (INP)、視覚的安定性ではCumulative Layout Shift (CLS)。ラボテストで修正を検証し、フィールドデータで実ユーザーへの影響を確認してください。

Q: モバイルだけ最適化すべきですか？
A: Googleはデフォルトでモバイル版をクロール・インデックスに使う（Googlebot Smartphoneが使用される）ため、モバイルのパフォーマンスは不可欠です。ただし、オーディエンスが異なる場合はモバイルとデスクトップの両方を最適化してください。

Q: サードパーティスクリプトの影響はどうテストしますか？
A: Chrome DevToolsのPerformanceを使ってページロードを記録し、長時間タスクやサードパーティスクリプトのトリガーを特定します。deferやasync読み込み、またはサードパーティコードに対するパフォーマンスバジェットの導入を検討してください。