「CSSは軽いほど速い」は、フロントエンド最適化における長年の共通認識だった。だがその前提を揺さぶる事例が、GitHubのエンジニアリングブログから出ている。
Improving site performance by shipping more CSS – The GitHub Blog は、Design Systemsチームがスタイリングの持たせ方を見直し、これまでJavaScript側が担っていた処理をCSSへ寄せたことで、サイト全体のパフォーマンスが改善したという取り組みを紹介している。CSSの転送量そのものは増えても、体感速度は落ちなかったという逆説がここにはある。
この逆説を支えているのは、CSSとJSでは「増える」ことの意味が違うという構造だ。JSは実行のたびにパース・コンパイル・実行というコストを毎回払うのに対し、CSSはブラウザが並行して処理でき、共通化すればキャッシュも効く。Before/Afterで見ると、従来はスタイル計算やクラス切り替えをJSの実行時ロジックに任せていたのに対し、今回はその判断をあらかじめCSSの構造に織り込んでおく形に変わっている。実行時の分岐を減らし、静的に解決できる部分を増やすという発想だ。
これはAIがコードを書く現場にとって、むしろ相性がいい変化に見える。AIが生成するコンポーネントは、スタイリング方針が人間ほど一貫しないことが多く、JS側のロジックにスタイル制御を混ぜ込むほど破綻しやすい。逆に、スタイルの責務をCSS側にあらかじめ寄せておく設計であれば、AIが多少揺れたコードを書いても、パフォーマンスへの影響を構造で吸収できる余地が生まれる。「CSSを減らす」を最適化の唯一解にせず、責務の置き場所として捉え直す動きが、これから広がっていく可能性がある。
関連記事
- Marketing ops as code: Automating events from planning to follow-up on GitHub
- Gemini Omni 1.1 Flash lets you build with more control
- Looking back on Microsoft’s FY26: From AI experimentation to Frontier Transformation
参考文献
コメント