Speed Index が伸びない理由｜“画面が埋まらないサイト”の共通点とは？

Speed Index は「画面がどれだけ早く埋まるか」を示す指標です。
LCP と違い “最初に見える範囲がどれだけ早く形になるか” を評価するため、画像の置き方・読み込み順・レイアウト構造 がスコアに直結します。

今回は Speed Index が伸びないサイトに共通する原因と、改善のための具体的な考え方を解説します。

Speed Index が悪化する最も一般的なパターン

Speed Index が良くならないサイトには、次のような特徴があります。

ファーストビューに不要な画像が多い

カルーセル、装飾画像、SNS埋め込みなど、ユーザーがスクロールするまで見ない要素が初期読み込み対象になっているケースです。 視認できない画像を最初から読み込むと、“画面が埋まるスピード” がどうしても遅くなります。

背景画像がファーストビューを占めている

背景画像が悪いわけではありませんが、background-image は IMG より後回しで読み込まれるため、ファーストビューを背景画像で構成すると画面がなかなか描画されません。 背景画像は以下のような使い分けが必要です。

• ファーストビュー → IMG を使用（fetchpriority=”high” を推奨）
• それ以外 → 背景画像を検討（自然と遅延効果がある）

レイアウトが複雑すぎる

DOM が不要に入れ子になっていたり、カルーセルやタブ UI の初期化が遅れて画面描画を妨げるケースです。

• 位置計算
• サイズ計算
• レイアウトシフト抑制処理

これらが描画前に走り、結果として画面が埋まらない状態が続きます。

CSS が画面表示をブロックしている

Speed Index は FCP（最初の描画）にも影響するため、 CSS の読み込み順や外部ファイル数も重要です。

• 不要な CSS が多い
• 全ページ共通の巨大 CSS を読み込んでいる
• レンダリングブロックが多い

こうした構成は Speed Index の足を引っ張ります。

Speed Index を高めるための設計思想

Speed Index は “何を先に見せるか” の問題です。
改善するには次の3点だけ意識すれば大枠は整います。

1. ファーストビューは最短で「形」が見える構成にする

Speed Index は “きれいに見える” かではなく 形が出る速さ を評価します。

• 背景色
• 最低限のテキスト
• 1枚のメイン画像

この3つで “画面が完成したように見える” 状況を最優先に設計します。

2. ファーストビューに読み込む画像は厳選

“あると良い” 画像ではなく、 “ないと困る” 画像だけを初期読み込みに含めます。

• 推奨構成：
  main visual → IMG + fetchpriority=”high”
• サブ画像 → loading=”lazy”
  装飾画像 → CSS background（自然に後回し）

3. それ以外は後回しにしてよい

Speed Index はファーストビューが埋まる速さが評価対象です。

• スクロールしないと見えない画像
• 初期表示に必要ない JavaScript
• タブ・アコーディオンの UI
• SNS の埋め込み

これらは後回しにしても Speed Index に問題ありません。むしろ後回しにしたほうが快適です。

Speed Index を改善するための実装方針

Speed Index は “画面が見えるまでの速度” を評価するため、
改善のポイントは 「最初の描画をどれだけ軽くできるか」 に集約されます。

以下は特に効果が高い施策です。

ファーストビューを IMG 主体で構成する

初期描画の優先順位は IMG の方が高いため、メインビジュアルの画像は IMG + fetchpriority=”high” を採用します。 背景画像は fold 後（スクロール後）の利用が適しています。

初期描画に不要な画像を読み込まない

カルーセルの2枚目以降、サブビジュアル、装飾画像など、“なくても困らない画像” を初期読み込みに含めない設計が重要です。 loading=”lazy” や遅延スクリプトで後回しにできます。

CSS は「描画に必要な範囲」だけ先に読み込む

巨大なCSSを1つにまとめていると、最初の描画が遅くなり Speed Index を圧迫します。 critical CSS（初期表示に必要なスタイル）だけインライン化し、残りは遅延読み込みにすることで改善が期待できます。

JavaScript が描画をブロックしないようにする

初期描画前に動く JavaScript があると、画面が出るまでの時間が延びます。 不要なスクリプトは defer / async を利用し、UI 制御系は初回描画後に初期化します。

DOM（HTML構造）を必要最低限に保つ

入れ子の多い複雑なレイアウトはブラウザの計算量を増やし、描画開始が遅れます。 Speed Index 改善には HTML の簡素化が最も効きます。

Speed Index を改善するなら“初期描画”にすべてを寄せる

Speed Index は単に“速くする”のではなく、ユーザーが画面を認識できるタイミングを早める指標です。

ファーストビューの構成、画像の扱い、CSS/JavaScript の読み込み順を意識して設計するだけでも、数値は大きく改善します。