こんにちは。フロントエンドの迷宮で日々CSSの挙動とブラウザエンジンの機嫌取りに明け暮れているチーフアーキテクトだ。
今回は、CSSセレクタの中でも「分かっているつもりで最も事故を生み出す罠」の一つ、`:first-of-type` 疑似クラスについて深掘りしようと思う。
公式ドキュメントには「親要素内で特定のタグ型として最初に出現する要素を選択する」と、いかにもシンプルに書いてある。だが、この言葉を文字通りに信じ、コンポーネント指向の現代的なWebアプリケーションで無造作に使い倒すと、確実に痛い目を見る。コンポーネントの構造が変わった瞬間、あるいは動的なDOM再構築が走った瞬間に、意図しないスタイルが暴走し、我々を深夜のデバッグ地獄へと引きずり込むのだ。
今回は、BlinkやGeckoといったブラウザの内部描画エンジンがこのセレクタをどう解釈し、メモリやレンダリング負荷にどう影響を与えているのか。そして、実務で絶対に踏んではならない地雷と、その回避策について、ギークな視点から徹底的に紐解いていこう。
—
1. `:first-of-type` の残酷な真実：タグ名ベースという「呪縛」
まず大前提として、この疑似クラスの名前を今すぐ脳内で再定義してほしい。`:first-of-type` は、「DOMツリー上の兄弟要素の中で、指定された『タグ名（Type）』を持つ最初の要素」を指す。ここが最大の罠だ。クラス名や属性は一切関係ない。純粋にHTMLのタグ名（`div`, `p`, `span` など）を見ている。
次のコードを見てほしい。よくあるカードリストのつもりで組んだマークアップだ。
ここで「最初のカードだけに特別なボーダーをつけたい」と考え、以下のようなCSSを書いたとする。
/ やりがちなバグの温床 /
.card-list .card:first-of-type {
border-top: 2px solid #3b82f6;
}
結果はどうなるか？ 期待した「カード 1」には、スタイルは一切適用されない。
なぜか？ ブラウザエンジンは `.card` というクラス名を見る前に、まず `:first-of-type` の条件を評価する。親（`.card-list`）の子供たちを走査したとき、「最初に出現したタグ」は `.card` ではなく、先頭にいる `` タグだからだ。
つまり、このセレクタが指し示しているのは `` であり、それに `.card` というクラスは付いていないため、マッチする要素は「存在しない」と判定される。これが、現場で「CSSが効かない！」と叫ぶエンジニアの9割が最初に踏む地雷だ。
—
2. ブラウザエンジンの内部挙動：メモリ効率とレンダリング負荷
では、ブラウザのパース時およびスタイルの計算時（Style Calculation）において、`:first-of-type` はどのような負荷をもたらすのだろうか。
CSSセレクタの評価は、基本的に右から左（Key Selectorから親方向）へと行われる。
`:first-of-type` のような構造的疑似クラス（Structural Pseudo-classes）が絡むと、ブラウザは単に要素の属性やクラスを見るだけでなく、DOMのツリー構造を上下に辿り、兄弟要素の型（Tag Name）の出現順序を動的に逆算・検証する必要が生じる。
特にコンポーネントが動的に生成・破棄されるモダンなSPA（ReactやVueなど）において、この「型の順序検証」は、DOMが書き換わるたびにスタイルツリーの再計算（Style Recalculation）コストをわずかに押し上げる要因になる。
もちろん、数個の要素であれば体感できるほどの差はない。しかし、数千件の行を持つ巨大な仮想スクロールのテーブルや、複雑にネストされたWebコンポーネントの内部でこれを多用すると、メインスレッドをじわじわと圧迫し、INP（Interaction to Next Paint）のスコアを悪化させる隠れたボトルネックになり得る。
構造的疑似クラスを多用するよりも、明示的なユーティリティクラス（例: `.is-first`）をJavaScript側、あるいはテンプレートエンジン側で付与する方が、ブラウザのセレクタマッチングのコストを劇的に下げられるという事実を、パフォーマンスチューニングの現場では忘れてはならない。
—
3. 非同期の競合と、動的DOMにおけるバグ回避策
もしあなたがどうしても `:first-of-type` を使いたい、あるいはデザインシステムの規約上避けられないのであれば、「DOMの構造変化に対する脆弱性」を完全にコントロール下におかなければならない。
特に危険なのは、APIからのデータフェッチに伴う「ローディング状態からデータ表示への切り替え（非同期のDOM書き換え）」だ。
ローディング中は `.skeleton-loader`（`div`タグ）が `.user-profile` 内の最初の `div` になる。データがロードされ、Reactなどが一気にDOMを書き換えると、今度は `.avatar`（これも `div`タグ）が最初の `div` になる。
もし `.user-profile div:first-of-type` のような粗いセレクタを書いていると、スケルトン表示から実データに切り替わった瞬間、レイアウトやスタイルのジャンプ（意図しないスタイルの継承・適用）が発生し、UIがガタつく原因になる。
堅牢なアーキテクチャのための回避策
この問題をエレガントに解決するアプローチは2つある。
1. タグ名を混在させない（Strict Type Policy）
親要素直下の子供のタグを完全に統一する。これが最も手堅い。
/ 親要素の中身をすべて同じタグで統一し、クラスで制御する /
.user-profile > div {
/ 共通のベーススタイル /
}
/ 最初の要素の制御には、クラスを併用するか、
そもそもDOM構造側で制御する /
2. `:has()` 疑似クラスとの組み合わせによる次世代アプローチ
モダンブラウザの普及により、我々はよりセマンティックで安全なセレクタを手に入れている。`:first-of-type` の曖昧さに頼るのではなく、`:has()` を使って「特定の状態を持つ要素の最初」を精密に狙い撃つ。
/ 例：中に特定の要素を含んでいる場合のみ適用するなど、
タグの型に依存しないスタイリングの構築 /
.card-list .card:not(:has(~ .card)) {
/ 実質的に「最後のカード」や「単一のカード」を安全に選択するイディオム /
}
いや、もっと直感的に `:first-of-type` の暴走を防ぎたいのであれば、コンポーネントのルート直下にはラッパーを挟み、型が混ざらない設計を徹底するのがプロの仕事だ。
—
4. 実務で使える堅牢なサンプルコード
最後に、`:first-of-type` を安全に、かつ美しく運用するための実践的なCSSスニペットを提示しよう。余計なコメントは省かない。エディタに貼り付けてその挙動の意図を噛み締めてほしい。
/
- 堅牢なカードリストコンポーネントのスタイリング
- 【アーキテクチャ上の注意】
- リスト直下に異なるタグ（p, span, div等）が混入して
- :first-of-type の挙動が狂うのを防ぐため、
- リストアイテムのHTML構造は完全に同一のタグで統一していることが前提。
/
.app-secure-list {
display: flex;
flex-direction: column;
gap: 1rem;
}
.app-secure-list__item {
padding: 1.5rem;
background-color: #ffffff;
border: 1px solid #e2e8f0;
border-radius: 8px;
transition: transform 0.2s ease;
}
/
- 【安全な :first-of-type の使用法】
- 親要素（.app-secure-list）の直下にある、
- 完全に制御された同型タグ（.app-secure-list__itemのdiv）の最初を選択する。
- タグの混入がないため、予期せぬバグが発生しない。
/
.app-secure-list__item:first-of-type {
border-color: #3b82f6;
background-color: #eff6ff;
}
/
- 【応用：ネストされた構造での安全策】
- 万が一、将来的に見出しやバナーなどの異物（別タグ）が
- リストの先頭に挿入される仕様変更が入るリスクを考慮する場合、
- CSSの構造セレクタだけに頼らず、Modifierクラスを併用するのが
- 大規模アプリケーションにおける真の「堅牢性」である。
/
.app-secure-list__item–featured {
border-color: #10b981;
background-color: #ecfdf5;
}
—
まとめ
`:first-of-type` は諸刃の剣だ。HTMLの構造に強く依存するため、マークアップの変更や非同期のDOM構築の揺らぎによって、いとも簡単に牙を剥く。
優れたフロントエンド・アーキテクトとは、CSSの「便利そうな機能」に飛びつくのではなく、「その仕様がブラウザのレンダリングや将来の保守性にどういった負債を生むか」を逆算できる者のことだ。
タグの型に依存する仕様の本質を理解し、安全なHTML構造の設計とCSSセレクタの選択を両立させること。それこそが、破綻しない堅牢なWebアプリケーションを構築する唯一の道である。
コメント