GitHubは2026年6月、styled-components、styled-system、sxプロパティを含め、CSS-in-JSへの依存を終え、サイト全体をCSS Modulesで運用するようになったと発表した。同社によると、この移行によりサーバーサイドレンダリング時間が55%短縮され、ページ上のコンポーネントの初期化に必要な時間も25%削減された。
この取り組みは、2023年以降、GitHubの一部のページでコンポーネント数が膨れ上がったことへの対応として始まった。従来の仕組みではクライアント側でスタイルを初期化する必要があり、サーバーサイドレンダリング中のスタイル収集コストが増大していた。また、ページ内のコンポーネント数が増えるほど、スタイルの更新も難しくなっていた。
GitHubがCSS Modulesを選んだ理由
CSS Modulesでは、コンポーネントのソースに隣接するCSSファイルにスタイルを記述でき、クラス名はデフォルトでローカルスコープになるため、衝突を減らせる。このケースでより重要だったのは、クライアントやサーバー上でのランタイム処理が不要になることだった。スタイルはCSSファイルにまとめられ、ページのHTMLとともに送信される。
移行はPrimerデザインシステムから始まった。チームは各コンポーネントにCSS Modulesのファイルを追加し、機能フラグによって旧方式と新方式を切り替えられるようコンポーネントを接続し、その後、ビジュアルリグレッションテストを使って結果が一致することを検証した。続いて、PrimerチームからGitHubの従業員、そして全ユーザーへと段階的に展開した。
2024年12月までに、PrimerのすべてのコンポーネントがCSS Modulesへ移行した。しかし、それだけでは不十分だった。GitHubのコードベースの大部分では、埋め込みオブジェクトを通じてコンポーネントをカスタマイズするために、依然としてsxプロパティが使われていたからだ。この方式はTypeScriptやデザイン トークンとの統合性に優れていた一方、動的な性質によってランタイムコストが増加し、コンポーネント数の増加に伴うスケーリングを難しくしていた。
大規模な移行の管理
既存の利用箇所を壊さないため、GitHubは@primer/styled-reactという中間ライブラリを作成した。このライブラリにより、CSS Modulesへ移行したコンポーネントでもsxを使い続けられるようになった。一方、sxを必要としないパスでは@primer/reactから直接インポートできた。
sxの削除作業は2025年4月に始まり、その時点でこのプロパティの使用箇所は約7,760件あった。社内向けのVS Code拡張機能とcodemodツールの支援を受け、8人のエンジニアからなるグループが6か月で6,419件を移行し、一部のページではサーバーサイドレンダリング時間が1%から22%改善した。2026年4月には、2人のエンジニアが参加し、GitHub Copilotのコーディングエージェントを使って、残りの件数を895件から3週間でゼロにした。
GitHubは7つのテーマをサポートしており、それぞれにハイコントラストモードがあるため、ビジュアルテーマも追加の課題となった。このシステムの一部はstyled-componentsと結び付いていた。そのためチームは、JavaScriptの利用箇所とテーマ用ツールも移行し、色の変数はCSSで定義されたままにした。
この取り組みが開発者に意味すること
GitHubの数字は、UIが大規模化した場合、ランタイムのスタイル処理をなくすことで具体的な効果が得られる可能性を示している。しかし、この取り組みで最も重要なのはCSS Modules自体の選択ではなく、その実施方法だ。段階的な互換性、機能フラグ、ビジュアルテスト、段階的なデプロイ、レビュー可能な自動化が用いられた。
一方で、このプロセスはCSS-in-JSからの移行が、単にスタイルの記述形式を置き換えるだけではないことも示している。sxプロパティの削除、テーマとstyled-componentsの結び付きの解消、そして長期間にわたるコンポーネントの互換性維持が必要だった。そのため、この結果はすべてのプロジェクトが同じ効果を得られることを証明するものではない。結果はGitHubの規模、コンポーネントの構造、動的なスタイリングの利用方法に関連している。