ページ速度
ページ速度とは、Webページのコンテンツがどれだけ速く読み込まれ、ユーザーが実際に閲覧したり操作したりできるようになるかを指します。これはユーザー体験とコンバージョンに直接影響し、GoogleのPage Experienceシグナルの一つであるCore Web Vitalsによって測定されます。
ページスピードとは、ページのコンテンツがどれだけ速く読み込まれ、使用可能になるかを示すもので、ユーザー体験、コンバージョン、SEOを左右する中核指標です。
Googleは速度と使いやすさをCore Web Vitals（LCP、INP、CLS）で測定し、検索順位の判断材料となるPage Experienceシグナルに反映します。
推奨される基準値は、LCPが2.5秒未満、INPが200ms以下、CLSが0.1以下で、実ユーザー（フィールド）データの75パーセンタイルで評価されます。
PageSpeed Insights、Search Console、Lighthouse、CrUXなどのツールで測定し、サーバー応答、レンダーブロック要素、画像最適化によって改善します。
概要
ページスピードとは、ユーザーがページを要求した瞬間から、そのコンテンツが画面に表示され、実際に使えるようになるまでの時間を指します。この概念は、単に「どれだけ速く表示されるか」だけでなく、読み込み、応答性、視覚的な安定性を総合的に含むようになっています。ページが遅いと、コンテンツが描画される前にユーザーが離脱しがちで、それはコンバージョンの低下に直結します。
Googleは、ページスピードを含むユーザー体験を、Core Web Vitalsと呼ばれる一連の指標で数値化しています。Core Web VitalsはPage Experienceシグナルの一部であり、Googleのドキュメントでは、同社のコアランキングシステムが評価対象としている内容と一致していると説明されています。つまり、速度だけで順位が決まるわけではありませんが、同程度の品質のコンテンツ同士を比べる際の重要な差別化要因として機能します。
3つのCore Web Vitals
ページスピードと使いやすさは、3つの主要指標で測定されます。
LCP (Largest Contentful Paint)— 読み込みパフォーマンス。ビューポート内で最も大きなコンテンツ要素が描画されるタイミングを測定し、良好な基準値は2.5秒以下です。
INP (Interaction to Next Paint)— 応答性。ユーザーの操作に対して画面が反応するまでの遅延を測定し、良好な基準値は200ミリ秒以下です。
CLS (Cumulative Layout Shift)— 視覚的な安定性。読み込み中に予期しないレイアウトの移動がどれだけ累積したかを測定し、良好な基準値は0.1以下です。
指標 | 測定対象 | 良好な基準値 |
|---|---|---|
LCP | 読み込みパフォーマンス | 2.5秒以内 |
INP | 応答性 | 200ms以内 |
CLS | 視覚的安定性 | 0.1以下 |
評価は、モバイルとデスクトップを別々に評価した実ユーザーデータの75パーセンタイルに基づいて行われます。実際には、指標が合格と見なされるには、ユーザーの75%が良好な体験を得る必要があります。
測定ツール
ページ速度の測定は、フィールドデータ実際のユーザーから収集したデータと、ラボデータ制御された環境で測定したデータに分かれます。Googleは、ラボ測定がフィールド測定の代替にはならないと明言しています。ラボデータは開発中のリグレッションを検出するのに有用ですが、実際のデバイス、ネットワーク、操作を反映することはできません。
PageSpeed Insights— フィールドデータ（CrUX）とラボデータ（Lighthouse）の両方をまとめて提供する、代表的な診断ツールです。
Search ConsoleCore Web Vitalsレポート— 実ユーザーデータに基づき、サイト全体のページのパフォーマンス状況をステータス別に表示します。
CrUX (Chrome User Experience Report)— 実際のChromeユーザーから収集されたフィールドデータのソースです。
Lighthouse / Chrome DevTools— パフォーマンスのチェックや開発中のリグレッション検出に使用される、ラボ環境の診断ツールです。ラボ実行ではインタラクションがないため、INPの代わりにTBT（Total Blocking Time）を代用指標として使用します。
主要な最適化領域
web.dev の LCP 最適化ガイドから導かれる主な改善点は次のとおりです。
サーバー応答時間（TTFB）の短縮— 不要なリダイレクトを削減し、初回 HTML をできるだけ速く配信します。
レンダリングをブロックするリソースの削除— 未使用の CSS を削除し、重要でないスタイルは遅延読み込みし、
<head>内の同期スクリプトを避けます。画像の最適化— レスポンシブ画像とあわせて WebP や AVIF などの最新形式を使用し、圧縮します。LCP 画像には
fetchpriority="high"を適用し、loading="lazy"は使用しません。リソースの事前読み込み— 重要なリソースに
<link rel="preload">を適用し、LCP 要素が初回 HTML で検出可能であることを確認します。CDN とキャッシュ— ユーザーに近い場所からリソースを配信し、
cache-controlポリシーによって再訪時のネットワークリクエストを削減します。
<!-- LCP 画像の優先順位を高める -->
<img src="hero.avif" fetchpriority="high" alt="Hero image">
<!-- 重要なリソースを事前読み込みする -->
<link rel="preload" href="hero.avif" as="image" fetchpriority="high">理由
Google Search Centralのドキュメントでは、検索での成功のために良好なCore Web Vitalsを達成することが推奨されています。これは、コアランキングシステムが評価対象としている内容と一致するためです。また、LCP 2.5秒、INP 200ms、CLS 0.1という良好な基準と、75パーセンタイルで評価する方法も明記されています（出典: Google Search Central, web.dev）。LCP最適化の具体的な手法は、web.devのLCP最適化ガイドに基づいています。
アクションチェックリスト
PageSpeed InsightsとSearch Consoleのレポートを使用して、LCP、INP、CLSの現在のフィールドデータを確認します。
モバイルとデスクトップをそれぞれ個別に評価し、各項目が75パーセンタイルで基準を満たしているか確認します。
サーバー応答時間（TTFB）を短縮し、不要なリダイレクトを削除します。
未使用のCSSとJSを削除し、重要でないスクリプトは遅延読み込みにします。
最新の形式、圧縮を適用し、
fetchpriority="high"をLCP画像に設定し、画像の遅延読み込みを無効にします。重要なリソースを事前読み込みし、CDNとブラウザキャッシュを設定します。
CLSを低減するため、画像、広告、埋め込みコンテンツのサイズを明示します。
デプロイ後はLighthouseで回帰がないか確認し、フィールドデータで実際の改善を再確認します。