Speed Index（スピードインデックス）

TL;DR — Speed Indexは、読み込み中にページ上のものがどれだけ速く表示されるかを測るLighthouseのスコアです。低い（速い）ほど良く、秒で測定します。モバイルでは3,4秒未満がGoodです。Core Web Vitalではなく、Googleのランキングへ直接影響もしません。ただし、Speed Indexを改善する施策は、ランキングに関係する指標の改善にも役立つことが多いです。

Speed Indexとは

LighthouseやPageSpeed Insightsでページを実行すると、返される数値の1つがSpeed Indexです。単純な質問に答えます。ページの見える部分はどれくらい速く埋まるか？

多くの速度指標は、最初のコンテンツが表示された瞬間（First Contentful Paint）や最大の要素が表示された瞬間（Largest Contentful Paint）のように、1つの時点を測ります。Speed Indexは異なり、読み込み全体を見て、表示されるまでの速さを平均します。ほぼ瞬時にすべてを描画するページは低い（良い）スコアになり、空白のまま待ってから少しずつコンテンツを表示するページは高い（悪い）スコアになります。

スコアの読み方

LighthouseはモバイルのSpeed Indexを次のように評価します。

• Good: 0〜3,4秒（緑）
• Needs improvement: 3,4〜5,8秒（オレンジ）
• Poor: 5,8秒超（赤）

デスクトップは、Goodが約1,3秒未満とかなり厳しくなります。Lighthouseはモバイルを、低速化をシミュレートしたデバイスでテストするためです。デスクトップの数値とモバイルの数値を比較しないでください。異なる尺度です。

SEOに関係しますか？

ここが誤解される部分です。Speed IndexはCore Web Vitalではなく、Googleのランキング要因でもありません。 Googleのページエクスペリエンスシグナルは、実ユーザーで測定するCore Web Vitals（LCP、INP、CLS）から得られます。Speed Indexはその中に含まれず、実ユーザーでも測定されません。読み込みの動画が必要で、テストツールでしか取得できないためです。

だからといって役に立たないわけではありません。Speed Indexを改善する高速なサーバー、レンダリングをブロックするファイルの削減、フォント読み込み中も表示を保つテキストなどの施策は、FCPとLCPを改善する施策と同じです。そのため、Speed Indexが改善すると、重要なLCPも改善することが多くなります。

計算式、WebPageTestの歴史、Lighthouseスコア内での位置、注意すべき制約を知りたい場合は、Advancedタブに切り替えてください。

TL;DR — Speed Indexは、ページ読み込み中にコンテンツが視覚的に表示される速さ、つまり見えるコンテンツが表示される平均時間を秒で測定します（低いほど良い）。読み込み動画から視覚的な進捗曲線の上側の面積を合計して計算するため、ラボ専用の指標です（CrUX、PSIのフィールドデータ、Search Consoleには含まれません）。Pat MeenanのWebPageTestで生まれ、LighthouseはオープンソースのSpeedlineモジュールで計算します。Core Web Vitalでもランキング要因でもありません。 Lighthouseの5つの指標の1つで、Lighthouse 10では重みが**10%**です。モバイルはGoodが3,4秒以下、Needs improvementが5,8秒以下、Poorが5,8秒超、デスクトップのGoodは約1,3秒以下です。FCPより速くなることはなく、ビューポートに依存し、FCP/LCPと同じ施策で改善します。

Speed Indexが実際に測るもの

Googleの定義は1行です。「Speed Indexは、ページ読み込み中にコンテンツが視覚的に表示される速さを測定する」。重要な語は視覚的です。Speed IndexはFirst Contentful PaintやLargest Contentful Paintのような単一のタイムスタンプではありません。ページの見える部分が表示されるまでの平均時間を表す複合スコアです。低いほど良く、秒で報告されます。

最も分かりやすい考え方は、X軸を時間、Y軸を「ページが視覚的に完成した割合」とするグラフを描き、0%から100%まで上昇させることです。Speed Indexはその曲線の上側の面積です。曲線が100%まで速く上がるほど面積は小さくなり、スコアは良くなります。しばらく空白のページは線の上に大きな空白の長方形を残し、速く描画するページはほとんど残しません。

計算方法

Lighthouseはページ読み込みの動画を撮影し、フレーム間の視覚的な進行を計算します。各時間間隔は、その時点でページがどれだけ未完成かで重み付けされます。完全に空白のフレームは100%として数えられ、ほぼレンダリング済みのフレームはごくわずかにしか寄与しません。元のWebPageTestの式は次のとおりです。

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

具体的な計算例を見ると分かりやすくなります。DebugBearは1回の読み込みを次のように説明しています。

• 0% 完了（0〜253ミリ秒）→ 253,0ミリ秒の寄与
• 43% 完了（253〜403ミリ秒）→ 85,5ミリ秒の寄与
• 98% 完了（403〜536ミリ秒）→ 2,7ミリ秒の寄与
• 99% 完了（536〜653ミリ秒）→ 1,2ミリ秒の寄与
• 合計：342,3ミリ秒

最初の区間に注目してください。何も表示されていない間は、その時間のすべてが最大の重みで寄与します。だからSpeed IndexがFirst Contentful Paintより速くなることはありません。最初のコンテンツが描画される前の1ミリ秒ごとに、100%で数えられるためです。

Lighthouseはここで独自の実装を使っていません。オープンソースのSpeedlineモジュール（元はPaul Irish）を実行し、スクリーンショットを有効にしたChrome DevToolsのトレースから、WebPageTestと同じ視覚的進捗の動画手法を使います。Speedlineは、現在のフレームと最終フレームのヒストグラム差分による標準Speed Indexか、SSIMを使う知覚的な変種を計算できます。通常表示されるのは標準版です。

良いスコアとは

Lighthouse 10は、HTTP Archiveの実在サイトデータを基準にSpeed Indexを評価します。Lighthouseはデフォルトで中程度のモバイル端末にスロットリングをかけてシミュレートするため、端末によって閾値は大きく異なります。

「1 000ミリ秒未満ならGood」という古いベンチマークを見かけたなら、それは特定の時代と接続プロファイルに対する、古いWebPageTestのガイダンスです。現在のLighthouseモバイル基準ではありません。数値を生んだツールと端末/ネットワーク設定を必ず確認してください。同じページでもスコアは変わります。Lighthouse、WebPageTest、GTmetrixは同じ尺度ではありません。

Lighthouseスコア内での位置

Speed IndexはLighthouse 10のPerformanceスコアに含まれる5つの指標の1つで、重みは**10%**です。FCPと並び、最も重みが低い指標です。

実務上の結論は、Speed Indexだけを追うのは投資対効果が低いということです。Total Blocking Time（30%）とLCP、CLS（各25%）のほうが全体スコアを大きく動かします。Speed Index自体が問題になっていない限り、通常はLCPとTBTを修正したほうが得られ、Speed Indexも副次的に改善します。PageSpeed Insightsでは、Speed Indexは上部のフィールドデータではなく、ラボ（Lighthouse）セクションに表示されます。

Speed IndexはCore Web Vitalまたはランキング要因ですか？

どちらも違います。レポートを関係者に説明するとき、この区別が重要です。

• Core Web Vitalではありません。 Core Web VitalsはLCP、INP、CLSで、CrUXを通じて実ユーザーで測定します。Speed Indexはこの集合に含まれず、Search ConsoleのCore Web Vitalsレポートにも表示されません。
• 直接的なランキング要因ではありません。 GoogleのページエクスペリエンスシグナルはCore Web Vitalsのフィールドデータを使います。Speed IndexはGoogleが実ユーザーから収集しないラボ専用の診断指標なので、Speed Indexの数値からランキングへ直接つながる経路はありません。

ランキングとの関係は間接的です。悪いSpeed Indexを生む遅いTTFB、レンダリングをブロックするCSS/JS、フォント切り替え中の見えないテキストは、悪いFCPとLCPを生む問題と同じです。修正するとSpeed Indexも通常はLCPと一緒に改善し、Googleが実際に評価する部分が良くなります。

ラボ専用である理由

Speed Indexには、ページのレンダリングをフレームごとに記録する動画と、各フレームの視覚的な完成度を計算する画像処理が必要です。すべての実訪問者に実行するにはコストが高すぎるため、Lighthouse、WebPageTest、GTmetrixのような合成/ラボツールにしか存在しません。Real User MonitoringとCrUXデータセットにもありません。フィールドのパフォーマンスデータが必要ならCore Web Vitalsを使い、Speed Indexは管理されたテストでのレンダリング診断に使います。

どこから生まれたか

Speed IndexはWebPageTestで生まれました。Pat Meenanが2008年に作成してオープンソース化したツールで、指標自体は2012年頃に追加されました。当時の指標にあった実際の不足を解決するために設計されました。

• Render startは、1ピクセルや背景色だけで発火することがあり、意味のあるコンテンツを示しません。
• Document complete（onload）には、画面下部や関係のないリソースも含まれます。

Speed Indexは、画面上部の視覚的な完成度を時間に沿って測ることで、その中間を捉えました。ユーザーが実際に認識するものをよりよく表す指標です。Lighthouseは後にSpeedlineモジュールを通じてこの手法を採用したため、スロットリングは異なっていてもWebPageTestとLighthouseの数値には共通の系譜があります。

改善方法

Speed Index専用の裏技はありません。Google自身のガイダンスは、ページ読み込み速度を改善するために行うことは何でもSpeed Indexのスコアを改善するというものです。実際には次のとおりです。

• サーバー応答時間（TTFB）を短縮する。 最初のバイトまでの1ミリ秒は、最大の重みで数えられる空白ページの時間です。
• レンダリングをブロックするCSSとJavaScriptをなくす。 これらは最初の描画を遅らせ、曲線上で最もコストの高い部分に影響します。重要なCSSをインライン化し、残りを遅延させます。
• フォント読み込みを修正する。 フォント切り替え中にテキストが見えないと、その範囲は0%完了として数えられます。font-display: swap（またはoptional）でテキストを表示し続けます。これはLighthouseがSpeed Indexについて明示的に指摘する監査の1つです。
• メインスレッドの作業を最小化し、JavaScriptの実行時間を短縮する。 LighthouseがSpeed Indexに影響の大きいものとして挙げる、他の2つの診断です。
• 画面上部のコンテンツを優先する。 Speed Indexは表示中のビューポートだけを気にするため、最初の画面を速く描画することが全てです。

これらはFCPとLCPの最適化とほぼ完全に重なります。だから私はSpeed Indexを別のToDoリストではなく、裏付けとなるシグナルとして扱います。単一の数値に基づいて行動する前に、読み込みのフィルムストリップ（LighthouseとWebPageTestの両方が生成します）を見て、実際に早く描画されたものと遅れたものを確認してください。また、1回のテストではなく、条件をそろえた繰り返し実行をいくつか比較します。下記の実行ごとのばらつきに関する注記も参照してください。

知っておくべき制約

• ラボ専用 — 実ユーザーの体験ではなく、テスト環境だけを反映します。
• ビューポート依存 — 表示領域を測るため、モバイルとデスクトップでは結果が大きく異なります（そのため閾値も大きく異なります）。
• SPA/AJAXの盲点 — シングルページアプリは、シェルがすぐ描画され、ページ更新なしで本当のコンテンツが後から読み込まれるため、実際より速く見えることがあります。
• カルーセル、自動再生動画、同意オーバーレイ — 意味のあるコンテンツが読み込まれた後もピクセルを変え続けるものは、「未完了」として記録され続けるため不利になることがあります。自動回転カルーセルが不利になるのと同じ仕組みです。
• 「完全読み込み」指標ではない — すべてのスクリプト、画像、画面下部の要素が終わる時点ではなく、画面上部の視覚的な進行を測ります。WebPageTestの別指標Visually Complete（常にSpeed Index以上）が、遅れて遅延読み込みされるウィジェットを捉えます。
• 視覚的な進行は有用性の証明ではない。 Speed Indexは最終フレームに対するピクセル変化だけを測り、画面上のものが読めるか、正しい順序か、アクセシブルか、実際に操作できるかは分かりません。高速に描画されるスケルトンやシェルは良いスコアでも、本当のコンテンツや操作可能性が後から届くことがあります。これは、意味のない早期描画というアンチパターンを指標側から説明したものです。
• 実行ごとのばらつき — 1回の記録された読み込みから導出されるため、Speed Indexはテスト条件で変わります。Googleのスコアリングガイダンスも、デバイスの違い、ブラウザー拡張、ウイルス対策ソフト、広告やA/Bテストの変更など、コードとは関係のないスコア変動の原因を挙げています。単発の数値ではなく、条件をそろえた繰り返し実行の分布を比較してください。

関連する指標

Speed IndexはCore Web Vitalsハブとその関連項目と同じウェブパフォーマンスクラスターにあります。最も近いのはFirst Contentful Paint（Speed IndexがFCPを上回ることはない）とLargest Contentful Paint（同じ施策、同じ根本原因）です。LighthouseスコアではTotal Blocking Timeと並び、LighthouseとPageSpeed Insightsの中で確認できます。ランキングを実際に動かすフィールド指標については、Core Web Vitalsハブから始めてください。

AI要約

Advanced版の要約です。

• Speed Index = 読み込み中にコンテンツが視覚的に表示される速さ — 単一のタイムスタンプではなく、見えるコンテンツが表示される平均時間という複合スコアです。秒で報告され、低いほど良い指標です。
• 考え方： 視覚的な進捗曲線（時間と視覚的な完成度の割合）の上側の面積です。読み込み動画から計算し、各区間をその時点の未完成度で重み付けします。
• ラボ専用： フレームごとのスクリーンショットが必要なため、CrUX、PageSpeed Insightsのフィールドデータ、Search Consoleには含まれません。フィールドデータにはCore Web Vitalsを使います。
• 起源： WebPageTest（Pat Meenan、2008年、指標は約2012年）。LighthouseはオープンソースのSpeedlineモジュールで、WebPageTestと同じ手法を使って計算します。
• Core Web Vitalでもランキング要因でもない。 CWVはLCP、INP、CLSです。ランキングとの関係は間接的で、Speed Indexを改善すると通常はFCP/LCPも改善します。
• Lighthouse 10の重み：10% — FCPと並び最小です。TBT（30%）とLCP/CLS（各25%）のほうがはるかに重要なので、Speed Indexだけを追う投資対効果は低くなります。
• 閾値（モバイル）： Goodは3,4秒以下、Needs improvementは5,8秒以下、Poorは5,8秒超。デスクトップのGoodは約1,3秒以下です。FCPより速くなることはなく、ビューポートに依存します。
• 改善方法 = FCP/LCPの改善方法： TTFBの短縮、レンダリングをブロックするリソースの削減、font-display: swap、メインスレッド/JS作業の削減、画面上部の優先。
• 制約： SPAは実際より良く見えることがあり、カルーセル、自動再生動画、同意オーバーレイは不利になる可能性があります。「完全読み込み」の測定ではなく、視覚的な進行はコンテンツが読める、アクセシブル、利用可能である証明ではありません。また、単一実行のスコアはデバイス、拡張、広告/A-Bテストによって、コードと関係なく変動します。

公式ドキュメント

Speed Indexの一次資料です。

Google / Lighthouse

• Speed Index（Lighthouse監査） — 定義、Speedlineによる計算方法、スコアの閾値、最適化監査の公式リファレンス。
• Lighthouseのパフォーマンススコア — Speed Indexの10%の重みと全指標の内訳。
• メインスレッドの作業を最小化 — LighthouseがSpeed Indexに影響が大きいと指摘する3つの監査の1つ。
• JavaScriptの実行時間を短縮 — 指摘される2つ目の監査。
• ウェブフォントの読み込み中にテキストを表示したままにする（font-display） — 指摘される3つ目の監査。

起源 / 実装

• Speedline (paulirish/speedline) — LighthouseがDevToolsのトレースからSpeed Indexを計算するために使うオープンソースモジュール。
• Lighthouseのソース — speed-index.js — 監査の説明定数。
• WebPageTest — About — Pat MeenanがWebPageTestを作成してオープンソース化した場所で、Speed Indexの起源。

出典からの引用

記録上の発言です。各Google/Lighthouseリンクは、引用箇所へ移動するディープリンクです。

Google — Speed Indexが測定するもの

• “Speed Index measures how quickly content is visually displayed during page load.” — Lighthouse Speed Index audit。 引用箇所へ

Google — スコアの設定方法

• “Your Speed Index score is a comparison of your page’s speed index and the speed indexes of real websites, based on data from the HTTP Archive.” — Lighthouse Speed Index audit。 引用箇所へ

伝達された出典 (一次資料からの逐語引用ではなく、二次資料に基づく要約)

• Lighthouseはページ読み込みの動画を撮影し、フレーム間の視覚的な進行を計算して、Speedlineモジュールでスコアを生成します。元のWebPageTest Speed Indexと同じ原理に基づきます（Lighthouse Speed Index監査の計算セクション）。
• フレームが表示される時間が長く、その時点でページが未完成であるほど、そのフレームの寄与は大きくなります。FCP前の時間はすべて100%で数えられるため、Speed IndexがFirst Contentful Paintより速くなることはありません（DebugBear、Speed Indexドキュメント）。
• Speed Indexはフレームごとのスクリーンショット処理のコストが高いため、合成/ラボテストでしか利用できません（DebugBear、Speed Indexドキュメント）。
• 指標は2012年頃にWebPageTestへ追加され、Pat Meenanが2008年にオープンソース化したツールを土台にしています（KeyCDN、WebPageTest Aboutページ）。

Speed Indexチートシート

閾値（Lighthouse 10）

Lighthouse 10のPerformanceの重み

要点

• 単一のタイムスタンプではなく、時間に沿った視覚的な完成度（進捗曲線の上側の面積）を測ります。低いほど良い指標です。
• ラボ専用 — CrUX、PSIのフィールドデータ、Search Consoleには含まれません。
• **Core Web Vitalではなく、**直接的なランキング要因でもありません。
• FCPより速くなることはありません（FCP前の時間は100%で数えられます）。
• ビューポートに依存 — モバイルとデスクトップでスコアが大きく異なります。
• Speedlineが計算し、WebPageTest（Pat Meenan）で生まれました。

改善方法（FCP/LCPと同じ）

• TTFBを短縮する（サーバー応答を速くする）。
• レンダリングをブロックするCSS/JSを削除し、重要なCSSをインライン化する。
• テキストを表示したままにするため、font-display: swap / optionalを使う。
• メインスレッドの作業とJSの実行時間を最小化する。
• 画面上部の描画を優先する。

惑わされないために

• 「1 000ミリ秒未満」は古いWebPageTestのガイダンスで、Lighthouseのモバイル基準ではありません。
• SPAは実際より良く見えることがあり、カルーセルは不利になることがあります。

Speed Indexを報告するツール

• Lighthouse（Chrome DevTools、CLI、Nodeモジュール） — Speedlineで計算したSpeed Indexを、5つのPerformance指標の1つとして報告します。
• PageSpeed Insights — Lighthouseを実行し、ラボ（Diagnostics）セクションにSpeed Indexを表示します。上部のフィールドデータセクションはCore Web Vitalsを使うため、そこにSpeed Indexは表示されません。
• WebPageTest — 指標が生まれた場所です。設定可能な接続プロファイルで、Visually Completeやフィルムストリップ表示とともにSpeed Indexを報告します。
• GTmetrix — WebPageTestのデータを使ってUIにSpeed Indexを表示しますが、デバイスやネットワークのシミュレーションが異なるため、数値はLighthouseと一致しません。
• DebugBear — Speed Indexの計算方法をフレームごとに明確に分解する合成モニタリングです。

ツールを比較するときの注意点です。異なるスロットリングとデバイス前提のため、同じページでもSpeed Indexの値はLighthouse、WebPageTest、GTmetrixの間で異なります。条件をそろえて比較してください。

最適化の時間を無駄にするSpeed Indexの間違い

• Speed IndexをCore Web Vitalと呼ぶ。 ラボ専用の視覚的進捗指標であり、フィールドのランキングシグナルではありません。ページの埋まり方を診断するために使い、実際のCore Web Vitalsは別に確認してください。
• モバイルとデスクトップの閾値を比較する。 Lighthouseは異なるスコア曲線とテスト条件を使います。2つのスコアを互換可能と扱わず、1つのプロファイルを時間に沿って追跡してください。
• 意味のない早期描画で数値を改善する。 ヘッダーのシェルで視覚的な進行を早めても、主要コンテンツが空白のままになることがあります。指標とともに読み込みのフィルムストリップを確認してください。
• クリティカルパスを確認する前にすべての画像を最適化する。 遅いTTFB、レンダリングをブロックするCSS、フォント、同期JavaScriptは、視覚的な連続を全体的に遅らせます。ウォーターフォールで最初のボトルネックを見つけて追跡してください。
• 1回の実行で安定した値を期待する。 Speed Indexは合成動画から導出され、テスト環境で変動します。リグレッションや改善を宣言する前に、比較可能な実行を繰り返してください。

実力チェック：Speed Index

Speed Indexが測定するものについての5つの簡単な質問です。それぞれ回答を選んでから、確認してください。

時間を使う価値のあるリソース

公式

• Speed Index — Lighthouse audit — 公式の定義、閾値、最適化監査。
• Lighthouse performance scoring — Speed Indexの10%を含む指標の重み。
• WebPageTest — About — 指標の起源。

実装

• paulirish/speedline — LighthouseがSpeed Indexの計算に使うオープンソースモジュール。

その他

• DebugBear — Speed Index — 計算とFCPとの関係を段階的に説明する明快な例。
• KeyCDN — Speed Index — 歴史的背景とWebPageTestの式。
• Catchpoint — Speed Index — WebPageTestブログの後継で、視覚的進捗の式とSPA/カルーセルの制約。
• Google Search Central — Core Web Vitals — LCP、INP、CLSがランキングシグナルであり、Speed Indexが一覧にないことを確認できます。
• web.dev — Vitals overview — Core Web Vitals（LCP、INP、CLS）の公式定義。Speed Indexがないため、ランキングに影響しない理由の説明に役立ちます。
• WebPageTest — Speed Index documentation — Pat MeenanによるWebPageTestの作成（2008年にオープンソース化）とSpeed Indexの起源。

引用する価値のある数値

• Lighthouseの重み：10% — Lighthouse 10のPerformanceスコアにおける割合で、FCPと並んで最小です。TBT（30%）とLCP/CLS（各25%）を大きく下回ります。 出典
• モバイルのGoodは3,4秒以下、デスクトップのGoodは1,3秒以下 — HTTP Archiveの実在サイトデータを基準に調整されたLighthouse 10の閾値です。 出典
• Speed Indexは常にFCP以上 — 最初のコンテンツが描画される前の時間は100%で寄与するため、Speed IndexがFirst Contentful Paintより速くなることはありません。 出典
• 起源：WebPageTest、約2012年 — Pat Meenanが2008年にオープンソース化したツールに追加されました。出典

変更履歴