CSSで表示を速くする — セレクタの最適化は、条件を揃えて測ったら0.1msだった

公開 2026-10-25 ／ 更新 2026-10-25 ／ 文：スブリ

先に結論

「子孫セレクタは遅いから避ける」「IDセレクタが最速」という助言が、いまも検索結果の上位に並んでいます。 条件を揃えて測ったら、差は0.1ミリ秒でした。

手を付ける順番は、こうなります。

セレクタの最適化を測ってみた

条件を揃えて比べる

セレクタの速度を比べるとき、うっかりすると「何要素にマッチするか」を比べてしまいます。 IDは1要素、クラスは数千要素、では比較になりません。

そこで、すべて同じ2,000要素にマッチするセレクタを用意しました。 DOM全体は12,008要素です。スタイルを差し替えて、再計算が終わるまでの時間を51回測り、中央値を取りました。

「IDが最速」の正体

条件を揃えない比較もやってみました。こちらだと、たしかにIDが速く見えます。

0.7msと1.8msの差は、セレクタの複雑さではありません。 1要素を塗り直すか、2,000要素を塗り直すかの差です。

「IDセレクタが最速」という助言は、この2つを混同しています。 同じ数の要素にスタイルを当てるなら、表3のとおり、 書き方を変えてもほとんど変わりません。

MDNは何と言っているか

公平に書いておくと、MDNもセレクタの簡略化は勧めています。 ただし、理由の並べ方を見てください。

そしてMDNは、CSSの主な課題として別のものを挙げています。

つまり「セレクタを簡潔に書く」は正しい助言です。 ただし、速度のためではなく保守のためと考えたほうが実態に合います。 速度で効くのは、MDNが先に挙げている2つです。

測る指標が変わった

いまの3つ

2010年代前半は「表示が速い／遅い」を体感で語っていました。 いまは測り方が決まっています。

判定は75パーセンタイルで行われます。 平均ではありません。遅いほうの4人に1人がどうかを見ます。 「自分の環境では速い」が通用しないのはこのためです。

FIDは廃止された

検索結果にはいまも FID を挙げている解説がありますが、これは置き換わっています。

FIDと書いてある解説は、2024年3月より前の情報です。 その記事の他の内容も、同じだけ古い可能性があります。

CSSで本当に効くのはレンダリングブロック

なぜ止まるのか

CSSは、読み終わるまで描画を止めます。 スタイルが分からないうちに描くと、あとから見た目が変わってしまうからです。

だから、CSSのサイズと本数がそのまま最初の描画の遅さになります。 セレクタの書き方は、そのあとの話です。

このサイトの記事ページで測った値を載せておきます。

FCPとLCPが同じ値になっています。 画像が無く、一番大きい要素が h1 のテキストなので、 最初の描画がそのまま最大要素の描画になるからです。

メディアクエリで非ブロッキングにする

MDNが挙げている手が、これです。

<!-- 常に要るものだけをブロッキングにする -->
<link rel="stylesheet" href="/base.css">

<!-- 印刷用・広い画面用は、条件が合うときだけブロックする -->
<link rel="stylesheet" href="/print.css" media="print">
<link rel="stylesheet" href="/wide.css" media="(min-width: 1200px)">

最後の行は、昔から変わらず有効です。 @import は、1本目を読み終わってから2本目を取りに行くので、待ち時間が足し算になります。 <link> を並べれば同時に取りに行けます。

もう一方の課題、再フロー

MDNが挙げるもう一方が再フローです。 こちらは、セレクタとは桁が違いました。

2,000個の要素に対して、①高さを読んで、すぐ高さを書くを交互に繰り返す場合と、 ②全部読み終えてから、全部書く場合を測りました。やっている仕事は同じです。

なぜこうなるか。offsetHeight のような値を読もうとすると、 ブラウザは「いま正しい値」を返すために、保留していたレイアウト計算を強制的に終わらせます。 書いた直後に読めば、また計算させることになります。2,000回繰り返せば、2,000回計算させます。

// 遅い：読む→書く を交互に（2,000要素で 378ms）
for (const el of els) {
  el.style.height = el.offsetHeight + 1 + 'px';   // 読んだ直後に書いている
}

// 速い：読み切ってから、書き切る（同じ処理で 0.4ms）
const hs = els.map(el => el.offsetHeight);        // まず全部読む
els.forEach((el, i) => { el.style.height = hs[i] + 1 + 'px'; });

レイアウトを強制的に計算させるプロパティを覚えておくと、見分けがつきます。

いまのCSSにある道具

2012年には無かったもので、速度に直接効くプロパティがあります。 MDNも挙げています。

/* 画面外の記事カードは、入ってくるまで描かない */
.card {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;   /* 想定の高さを伝える */
}

どこから手を付けるか

推測で直さないでください。 どこが遅いかは、ページによって違います。

最後の行が、この記事の主題です。 「なんとなく重い」からセレクタを書き直すのは、0.1msを取りに行く作業です（表3）。 先に測って、どこで時間を使っているかを見てください。

4行目が効きます。LCPの「要素」が取れるので、 何を速くすればいいかが一発で決まります。 画像ならその画像、見出しならCSSの読み込み、という具合です。

AIに任せるときの注意

判定の目安です。答えに「子孫セレクタを避ける」「IDセレクタを使う」が出てきたら、2010年代前半の情報です。 レンダリングブロックの話が出てくれば、現代的です。

よくある質問

子孫セレクタは避けるべきですか

速度のためなら、避ける必要はありません。 条件を揃えて測ったところ、4段の子孫セレクタと単純なクラスセレクタの差は0.1ミリ秒でした（表3）。 保守のために簡潔に書くのは、別の話として正しいです。

IDセレクタが一番速いのでは

比較の条件が揃っていません。 IDは1要素、クラスは数千要素にマッチします。 差の正体は「何要素を塗り直すか」です（表4）。

セレクタが右から左に解釈されるのは本当ですか

解釈の仕組みとしてはそのとおりです。 ただし「だから遅い」という結論は、実測では出ませんでした（表3）。

では何をすればいいですか

CSSの読み込みが描画を止めている時間を減らすことです（詳しく）。 MDNもCSSの主な課題として「レンダリングブロックと再フローの最小化」を挙げています。

FIDはどうなりましたか

2024年3月12日にINPへ置き換わり、廃止されました（web.dev）。 FIDを挙げている解説は、それより前の情報です。

content-visibility を付ければ速くなりますか

画面外の長いコンテンツには効きます。ただし contain-intrinsic-size で想定の高さを伝えてください（詳しく）。 伝えないとレイアウトのずれ（CLS）になります。

再フローとは何ですか

レイアウトの再計算です。寸法や位置を読むと、ブラウザは正しい値を返すために計算を終わらせます。 読んだ直後に書くのを繰り返すと、その回数だけ計算が走ります。 2,000要素で測ったら378ms、順番を直すと0.4msでした（表8）。

自分の環境では速いのですが

判定は75パーセンタイルで行われます（詳しく）。 平均でも最速でもなく、遅いほうの4人に1人がどうかで決まります。

@import はいまでも遅いですか

遅いです。1本目を読み終わってから2本目を取りに行くので、待ち時間が足し算になります（表7）。 <link> を並べれば同時に取得できます。

まとめ

• セレクタの最適化は、条件を揃えて測ると0.1msの差だった。12,008要素のDOMで2,000要素を塗り直しての値。
• 「IDが最速」は比較の条件が揃っていない。差の正体は、塗り直す要素の数。
• MDNもセレクタの簡略化は勧めているが、理由に「メンテナンス」を並べている。
• MDNが主な課題として挙げるのは「レンダリングブロックと再フローの最小化」。そちらが本命。
• CSSは読み終わるまで描画を止める。サイズと本数がそのまま最初の描画の遅さになる。
• media を付ければ、条件外ではブロックしない（MDNが挙げている手）。
• @import は待ち時間が足し算になる。これは昔から変わらず有効な指摘。
• 指標は LCP 2.5秒 / INP 200ms / CLS 0.1。判定は75パーセンタイル。
• FIDは2024年3月12日にINPへ置き換わって廃止された。FIDと書いてある記事は、それ以前の情報。
• content-visibility には contain-intrinsic-size を添える。さもないとCLSが悪化する。
• MDNが挙げるもう一方は再フロー。読み書きを交互にすると2,000要素で378ms、順番を直すと0.4ms。約945倍の差。
• offsetHeight や getBoundingClientRect() をループ内で読んでいたら、そこが原因。
• 推測で直さない。LCPの「要素」まで測れば、何を速くすべきか一発で決まる。