Speed Indexとは？“画面の埋まり方”が評価される理由と本当の改善方針

PageSpeed Insights（PSI）で診断すると、「Speed Index」の数値が悪い──という状況に出会うことがあります。

ただ一般的には、LCP・INPほど語られることは多くありません。理由は単純で、次のような背景があるからです。

1. 改善要因がコードに直結しにくい
2. Googleの公式説明が抽象的
3. 現場の“体感”と必ずしも一致しない

本記事では、Speed Index（SI）の意味・悪化要因・改善の方向性を実務者目線で分解して整理します。

Speed Indexとは「どれだけ早く画面が“埋まった”か」を示す指標

Speed Indexは “画面の表示進行がどれぐらい速いか” を数値化したものです。

LCPが「最大要素が表示されるタイミング」なのに対し、Speed Indexは「画面全体がどれだけ早く視覚的に構成されたか」を評価します。

• スケルトンスクリーン
• プレースホルダー
• プログレッシブ画像
• 初期テキストの先出し

といった “視覚的フィードバックの設計” に大きく影響される指標です。

GoogleがSpeed Indexを重視する理由はシンプルです。
ユーザーがページのすべてを読み込むのを待っているわけではありません。

“何か見え始めた瞬間から安心し、離脱が減る”

という行動特性が実際にあるからです。

Speed Indexが悪化しやすい典型的な要因

Speed Indexは「画面の埋まり方」を見るため、LCPとは違う“誤解されやすい悪化ポイント”があります。

代表的には以下です。

画像の読み込み順序が悪い

最初に出したい画像より、別の画像が先にダウンロードされているケースです。 特に複数のスライダーや背景画像は優先順位が分散しがちです。

CSSが肥大化して初期描画をブロック

CSSはJavaScript以上に描画を止めます。 未使用CSSが多いほど Speed Index は低下します。

JavaScriptが初期表示に割り込む

スライダーやフェードインなど「最初の一瞬に不要」な処理が画面構築の邪魔をすることがあります。

ページ内の画像をすべて初期読み込みする

ファーストビューで表示しない画像を読み込むことはSpeed Indexに響きます。

大きなコンポーネントが後から描画される

ニュース一覧・カード型UIなどが「まとめて後から」レンダリングされる場合、画面が“なかなか埋まらない”状態になります。

Speed Index は「ズレた読み込み順序」がよく原因になります。
LCPとは別の改善アプローチが必要です。

PageSpeed InsightsでSpeed Indexを見るときの“ポイント”

PSIの「診断」では多くの場合、次の項目が出てきます。

• レンダリングを妨げるリソース
• 使用していないCSS
• JavaScriptの初期実行
• 次世代フォーマットの未使用
• オフスクリーン画像の遅延読み込み

Speed Indexの改善で最も重要なのは 初期描画リソースの整理 です。

• ファーストビューのHTML構造（軽さ）
• 最初に読み込むCSSの精度
• 優先度の高い画像の選定
• 不要なJavaScriptの初期実行禁止

具体的にはこれらがSpeed Indexをまっすぐ改善するポイントです。

Speed Indexを改善するための“方向性”だけ押さえれば十分

Speed Indexは、LCPやINPのように「ここを直せば絶対改善する」という単純な構造ではありません。

実務で見るべき方向性は、次の3つだけです。

初期描画リソースを最小にする

CSSのインライン化・ネスト活用・整理、JavaScriptの遅延化、背景画像の乱用を避ける。

読み込み順序を制御する

優先画像の明示（fetchpriority=”high”）、スライダーなどのJavaScriptはLCP後に動かす。

見た目が早く見える構造にする

画面が埋まる順序を整える。 枠・テキストなど“即時表示可能なもの”を先に見せる。

Speed Indexは技術指標というより、“第一印象の設計” に近いものです。