【テクニカル・上級編】 first-child疑似クラスの挙動と注意点 – CSS実践ガイド

こんにちは。日々、CSSOMの構築速度やセレクタのヒット率に脳髄を焼かれているフロントエンド・アーキテクトの皆さん。

今回は、CSSの基礎中の基礎であるはずなのに、大規模なデザインシステムや複雑なコンポーネントツリーの組み替えにおいて、しばしばエンジニアの意表を突き、深夜のデバッグ大会を引き起こす魔物——`:first-child`疑似クラスについて、そのブラウザの内部挙動レベルから解き明かしていく。

「親要素の最初の子要素を選択する」というあまりにも有名なこの仕様。だが、「兄弟要素の型が動的に変わる現代のコンポーネント駆動開発」において、このセレクタを安易に使うことがどれほど危険な爆弾を抱えることになるか、実務の現場で痛い目を見ながら学んできたはずだ。

今回は、単なる使い方の解説ではない。ブラウザのレンダリングエンジン（BlinkやGecko）がこのセレクタをどう評価し、どのようなメモリ効率・パフォーマンスの最適化を行い、そしてどういった「落とし穴」が待ち受けているのか。そのすべてを語り尽くそう。

—

1. そもそも `:first-child` はブラウザ内部でどう評価されているのか

CSSセレクタのパフォーマンスを語る上で避けて通れないのが、「右から左へ（Right-to-Left）」の評価アルゴリズムだ。

ブラウザはDOMツリーを構築し、スタイルを適用する際、パフォーマンスを最大化するためにセレクタを右端（ターゲット要素側）から左に向かって評価していく。`.parent > :first-child` というセレクタがあった場合、ブラウザはまず「ある要素が誰かの最初の子であるか」を判定し、その後に親が `.parent` であるかを検証する。

ここで重要なのは、`:first-child` は単なるクラスセレクタ等とは異なり、「DOMの構造的関係性（兄弟関係）」に依存しているという点だ。

レンダリング負荷とメモリ効率の罠

現代のブラウザは賢い。CSSOMツリーとDOMツリーの差分を効率的に計算するため、各要素のポインタ（`previousElementSibling` や `parentNode`）をキャッシュしている。しかし、動的にDOMが書き換わるシングルページアプリケーション（SPA）や、複雑な仮想DOMの差分パッチが当たる環境では話が別だ。

`:first-child` が含まれるセレクタは、DOMの挿入・削除が発生した際、その親要素の直下の子要素すべてのインデックス再計算や構造的キャッシュの無効化（Invalidation）を引き起こすトリガーになりやすい。
特に、数千個の要素を持つ巨大なリストやテーブルにおいて、ルートに近い階層で `:first-child` を多用すると、スタイル再計算（Recalculate Style）のフェーズでメインスレッドをブロックし、フレームドロップ（jank）の原因となる。

—

2. 要素型が異なる場合の挙動：最大のバグ温床

多くのジュニア、あるいは中堅エンジニアすら誤解している仕様の核心に迫ろう。
`:first-child` は「要素の型（タグ名）」を見ない。純粋に「親から見て、DOMツリー上で一番最初に生成されたノード」を指す。

これが何を意味するか？ 実際のコード例を見てみよう。

/ 「最初の子要素には上パディングを消す」というよくある要件 /
.card-container :first-child {
padding-top: 0;
}

この状態では、`

` が最初の子要素であるため、` ` の `padding-top` が `0` になる。ここまでは意図通りだ。 しかし、ある日、仕様変更によって「新着バッジ（`.badge`）」が条件付きでタイトルの上に動的に挿入されるようになったとする。コメントアウトを外した状態を想像してほしい。 DOMの先頭に `.badge` が現れた瞬間、`:first-child` がヒットするターゲットは ` ` から `.badge` にすり替わる。 結果として、` ` に当たっていたはずの `padding-top: 0;` が消滅し、代わりに `.badge` に適用され、レイアウトが盛大に崩壊する。さらに最悪なことに、このバグは静的なコードレビューでは見抜けず、APIのレスポンスやユーザーの状態によって動的に発生するため、テスト漏れを引き起こしやすい。 型を意識したいなら `:first-of-type` との使い分け

もし「要素の種類に関わらずとにかく先頭のノード」を狙いたいのでなければ、この挙動はバグの温床でしかない。特定のタグ（例えば最初の `p` タグなど）を狙いたいのであれば、`:first-of-type` を使うべきだ。

しかし、`:first-of-type` にも「親要素の中にある指定された型の中で最初」という別の罠があるため、コンポーネント設計においては、そもそも構造依存の疑似クラスに頼らないアーキテクチャへシフトするのが、シニアエンジニアの選択肢となる。

—

3. 堅牢なWebアプリケーションを目指すためのアーキテクチャ戦略

では、実務の現場でこのような脆弱性を排除し、保守性が高くパフォーマンスに優れたCSS設計を行うにはどうすればよいのか。具体的なプラクティスを提示しよう。

戦略 A: ユーティリティクラス（Modifier）の明示的付与

最も泥臭く、しかし最も確実でバグらない方法は、CSSセレクタの構造依存性を完全に断ち切ることだ。動的に要素が増減する可能性のあるコンポーネントでは、`:first-child` に頼らず、状態をクラス名として明示的にバインドする。

/ 構造に依存せず、クラスの有無で制御する /
.card-title.is-first {
padding-top: 0;
}

このアプローチは、CSSの記述量はわずかに増えるものの、「DOMの構造が変わったらスタイルが壊れる」という悪夢のような結合度（Coupling）を完全に排除できる。大規模なデザインシステムにおいては、この疎結合性こそが正義である。

戦略 B: `:has()` 疑似クラスを活用した現代的なアプローチ

モダンブラウザのシェアがほぼ100%に達した現在、私たちは強力な武器を手に入れている。そう、関係性セレクタの決定版、`:has()` だ。

例えば、「もしバッジが存在するなら、その直後の見出しのスタイルを変えたい」という要件があった場合、`:first-child` の位置関係の揺らぎに怯える必要はなくなる。

/ バッジを持つカードコンテナ内の、バッジ直後にある見出しを制御 /
.card-container:has(.badge) .card-title {
margin-top: 0.5rem;
}

`:has()` を使うことで、子要素の「先頭かどうか」という曖昧な位置に依存するのではなく、「兄弟要素の存在有無（State）」に基づいたスタイリングが可能になる。これにより、DOMの順序変更に対する耐性が飛躍的に向上する。

—

4. チーフアーキテクトからの提言

CSSの疑似クラスは、魔法の杖ではない。`:first-child` はコードを簡潔に見せるための便利なショートハンドである一方、DOM構造とスタイルを強く結合させ、動的なアプリケーションの変更耐性を著しく下げる両刃の剣だ。

• 静的なレイアウトのグリッドや、構造が絶対に変わらない定型文のリストであれば、`:first-child` はそのパフォーマンスと記述の簡潔さにおいて大いに活躍する。
• しかし、状態によって子要素の増減や順序入れ替えが発生する動的なUIコンポーネントにおいては、この疑似クラスの使用を厳禁とし、明示的なModifierクラスや `:has()` などの文脈依存セレクタへの置き換えをチームのコーディング規約として強制すべきだ。

コードの美しさは、行数の少なさではなく、「仕様変更の嵐が吹いても微動だにしない堅牢性」宿るところにある。今一度、プロジェクト内のセレクタを見直し、無用な構造依存を断ち切ってほしい。