こんにちは。フロントエンドの現場で日々、CSSの不可解な挙動やパフォーマンス低下と格闘しているエンジニアの皆さん。
今回は、CSSの基本中の基本である擬似クラス、`:first-child` と `:last-child` について、あえて「上級アーキテクチャの視点」から徹底的に解剖していこうと思う。
「最初と最後の要素を選ぶだけの単純なセレクタに、何言ってるんだ？」と思ったかもしれない。しかし、ブラウザのレンダリングエンジン（Blink, Gecko, WebKit）の内部挙動や、モダンなコンポーネント指向のアーキテクチャ、そして動的なDOM操作が絡み合う現代のWebアプリケーションにおいて、この2つの擬似クラスを適当に扱うことは、パフォーマンスの深刻なボトルネックや、予期せぬレイアウトシフト（CLS）を引き起こす引き金になり得るのだ。
今回は、机上の空論ではなく、戦場の最前線で培った知見を共有しよう。
—
1. 脳死で使っていませんか？ `:first-child` の背後にあるDOMツリー走査の現実
まず大前提として、ブラウザがCSSセレクタを評価する方向を思い出してほしい。CSSセレクタは右から左（Key Selectorから祖先方向）へマッチングが行われる。
例えば、以下のようなセレクタを書いたとする。
.card-list .card-item:first-child {
/ スタイル定義 /
}
ブラウザはまずDOMツリーから `.card-item` をすべて探し出し、その親要素が `.card-list` であるかを右方向に検証し、さらにその要素が「親から見て本当に最初の兄弟要素（First Child）なのか」を判定する。
ここで問題になるのが、HTML構造の変動や、JavaScriptによる動的なDOMの差し込みだ。
「予期せぬHTMLの挿入」によるスタイルの崩壊
SPA（Single Page Application）やモダンなフレームワーク（React, Vue, Svelteなど）を使っていると、コンポーネントのライフサイクルの中で予期せぬラッパー要素や、フレームワーク特有のコメントノード、あるいはテキストノードが兄弟の間に挟まることがある。
ここで、`:first-child` の仕様における最大の罠を確認しておこう。
`:first-child` は「親要素における最初の子要素」を指す。したがって、以下のようなHTML構造があった場合、
もし `.container` の直下にコメントやテキストノードが入り込んだ場合、DOMノードの種類によっては `:first-child` の挙動が変わることはない（要素ノードのみがカウント対象のため）。しかし、フレームワークが生成する不隠な `` や `
現場で「なぜか一番上のマージンが消えたんだけど！」というバグに遭遇したなら、大抵はこのDOM構造の意図しない変化が原因だ。
—
2. レンダリング負荷とメモリ効率：巨大リストにおける最適化
何千件ものレコードを持つ仮想スクロールや、無限スクロールのリストを実装しているとしよう。
各行（アイテム）の境界線やパディングを制御するために、次のようなCSSを書くのは悪手だ。
/ 毎回全アイテムに対してセレクタの評価と再計算が発生するアンチパターン /
.virtual-list-item {
border-bottom: 1px solid #ccc;
}
.virtual-list-item:last-child {
border-bottom: none;
}
一見、何の問題もない美しいコードに見える。しかし、DOMノードが数千、数万規模に膨れ上がったとき、ブラウザのレイアウトエンジンは、DOMが変更されるたびにすべての `:last-child` の再評価（Style Recalculation）コストを支払うことになる。
堅牢なアーキテクチャのための「オフセットパターン」
モダンな高パフォーマンス・アプリケーションでは、`:last-child` に頼るのではなく、「隣接兄弟セレクタ（`+`）」や「コンテナ側での制御（BEMやUtility Firstの思想）」に逃げるのが定石だ。
例えば、以下のようなアプローチをとることで、ブラウザの計算コストを劇的に削減できる。
/ すべてのアイテムにデフォルトの境界線を持たせるが、
コンテナ側でボーダーの相殺や打ち消しをコントロールする /
.list-container {
–item-border-color: #e2e8f0;
}
/ 隣接するアイテムの間だけに線を引く（最初と最後には影響を与えない） /
.list-item + .list-item {
border-top: 1px solid var(–item-border-color);
}
この手法の何が優れているかというと、`:last-child` のように「最後の要素を特定してスタイルを上書きする」というレイアウトの再計算プロセスをバイパスできる点だ。DOMの追加や削除が行われた際も、変更のあったノード周辺の隣接関係しか再評価されないため、メモリ効率とレンダリング速度（特にFPSの維持）において圧倒的なアドバンテージを誇る。
—
3. 実務で直面する非同期の競合とCLS（Cumulative Layout Shift）の回避
データを非同期（Fetch APIなど）で取得し、リストを動的にレンダリングするアプリケーションにおいて、`:first-child` と `:last-child` はCLS（累積レイアウトシフト）の隠れた主犯になり得る。
次のようなシチュエーションを想像してほしい。
1. スケルトンスクリーン（ローディング表示）として、3つのプレースホルダー用アイテムが表示されている。
2. プレースホルダーの最後の要素には、`:last-child` によって特別な下部マージンやボーダーが適用されている。
3. 非同期通信が完了し、実際のデータ（1件のみ）がレンダリングされる。
この瞬間、DOMの総数が 3件 から 1件 へと一気に縮小する。
プレースホルダーの状態では「3番目（最後）」だった要素に適用されていた `:last-child` のスタイルが、データ描画後に「1番目（最初にして最後）」の要素へと瞬時に付け替わる。このスタイル変化に伴い、要素の高さやマージンがガクッと変動し、ユーザーの画面が意図せずカクつく――これが最悪のUXを生む原因だ。
防衛的CSSアプローチ：構造のプレ・ノーマライゼーション
この非同期競合によるレイアウトシフトを防ぐためには、擬似クラスの魔法に頼り切るのではなく、状態に依存しない確定的なレイアウト設計を行う必要がある。
/ バグを防ぐための実用的なコンポーネントCSSの例 /
.async-data-container {
display: flex;
flex-direction: column;
/ 隙間は gap で一元管理し、子要素のマージン相殺や擬似クラスによるハックを排除する /
gap: 1rem;
}
.async-data-item {
padding: 1.25rem;
background: #ffffff;
border-radius: 8px;
/ ボーダーの有無を :last-child で切り替えるのではなく、
一律でシャドウまたはボーダーを持たせ、状態によるレイアウトの差異を無くす /
box-shadow: 0 1px 3px rgba(0, 0, 0, 0.1);
}
このように、マージンを個別の要素の `:first-child` / `:last-child` で調整するのではなく、コンテナ側の `gap` プロパティや、一律のボックスシャドウでデザインを完結させることで、DOM構造や非同期データの増減に完全に耐えうる「堅牢なUI」を構築できる。
—
4. まとめ：擬似クラスを使いこなす真のアーキテクチャ思考
`:first-child` と `:last-child` は、CSSの中でも非常に直感的で便利な擬似クラスだ。しかし、それを「便利だから」という理由だけで深く考えずに多用すると、以下のような技術的負債を生む。
1. DOM構造への過度な依存: HTMLの些細な変更（ラッパーの追加やコメントの混入）でスタイルが崩壊する脆弱性。
2. パフォーマンスの劣化: 巨大なリストにおける、動的なスタイルの再計算コストの増大。
3. UXの低下: 非同期データ読み込み時のレイアウトシフト（CLS）の誘発。
真に優れたフロントエンド・アーキテクトは、CSSの機能を単体で覚えるのではなく、「ブラウザのレンダリングパイプラインにどう影響するか」「JavaScriptやフレームワークの状態変化とどう競合するか」を常に俯瞰してコードを書く。
`:first-child` や `:last-child` を使うときは、「本当にこのセレクタでなければならないのか？ `gap` や `+` セレクタ、あるいはコンポーネント自体の設計で解決できないか？」と一歩立ち止まって自問してみてほしい。その泥臭いこだわりこそが、あなたの作るWebアプリケーションを世界最高峰の品質へと引き上げるのだから。
コメント