GitHub、CSS-in-JSを捨ててCSSを増やし、サーバーサイドレンダリング時間を55%削減
Improving site performance by shipping more CSS
GitHubは、Primerデザインシステムの全コンポーネントをCSS-in-JSからCSS Modulesへ段階的に移行した。2024年12月までにPrimerの移行を完了し、サーバーサイドレンダリング時間が55%短縮。その後、sxプロップの削減とstyled-componentsの除去を進め、2026年6月に100% CSS Modulesで稼働。パフォーマンスを犠牲にせず、大規模なアーキテクチャ変更を安全に実現した。
最初はCSSの移行に見えたものが、GitHubが大規模にUIをスタイリング、テーマ設定、配信する方法の段階的な再プラットフォーム化であることが判明した。
HNでの議論
72- meerita
彼らがパフォーマンスをどう捉えているのか分からない。私には41件のネットワークリクエストが見える。それは2.1 MBのCSSがネットワークを流れ、レンダリングをブロックし、描画と読み込み速度を損なっている。400 KBのTailwind、87 KBの一般的なCSS、さらに別の200 KBの一般的なCSSがある。彼らはファンクショナルCSSをきちんと取り入れる必要がある。すべてをレンダリングする80 KB未満の単一CSSファイルにできたはずだと確信している。
- jenadine
GitHubを毎日使っているが、パフォーマンスが改善したとはあまり感じない。むしろページは遅くなっていると言える。コメントが多い問題や大きなPRを閲覧するのは、すべてが読み込まれるわけではないのでひどい体験だ。
- efortis
まだ改善の余地がある。現在、プロダクションビルドでは長いdevクラス名が使われている。例えば `DirectoryContent-module__Box_3__gl6dE` は `gl6DE3a2` のような短いハッシュにコンパイルできる。
Viteを使っているなら:
css: {
modules: {
generateScopedName: mode === 'production'
? '[hash:base64:8]'
: '[name]__[local]___[hash:base64:5]',
}
}
- eviks
残念ながら、削除される素晴らしいCSS-in-JSシステムを紹介した元のブログ記事が「関連記事」セクションにない。二つの考え方を比較できると良かったのに。
- Gualdrapo
以前（1年ほど前）、ある人のウェブサイトのセクションを「修正」するのを手伝ってほしいという投稿に偶然出くわした。それは!importantの上に!importantの上に!importantの上に!importantというものだった。その人は、どうやらAIが（少なくとも当時は）吐き出したのがそれだったらしく、必要なのはさらに!importantを追加することだけだと本当に確信していた。