给一个庞大系统做重构，最反直觉的做法莫过于用看似原始的技术去替换现代化方案。
2026年9月，GitHub 官方披露了一项历时三年的底层技术改造：github.com 核心全站以及 Primer 设计系统，已经完全剔除以 styled-components 为代表的运行时 CSS-in-JS 方案，全面转入 CSS Modules 与原生 CSS 变量体系。官方给这篇技术复盘起了一个近乎挑衅的标题：靠多发 CSS 来提升网站性能。
这并非噱头。在前端领域沉迷于开发者体验（DX）多年后，GitHub 用真金白银的性能账单完成了一次清算：把样式逻辑从 JavaScript 引擎里剥离后，代码提交路由 github/code_view / commit 的服务端渲染（SSR）耗时直接缩短了约 21.97%。
繁荣背后的账单：内联对象拖垮主线程
过去数年，React 生态几乎被以内联对象和组件化封装为卖点的样式库统治。在 GitHub 内部，Primer 的 sx 属性曾是最主流的排版手段。开发者在 JSX 里顺手塞入一个 JS 对象，就能享受到 TypeScript 的类型推断和设计令牌映射。样式和业务代码就近放置，体验顺滑无缝。
代价在后台暗中累加。到 2023 年，GitHub 页面复杂度骤增，运行时样式引擎的物理局限彻底浮出水面。
抽象层越舒服，浏览器主线程承担的无效折损就越沉重。
根据 GitHub 内部对 Issues 页面的基准测试，CSS-in-JS 在服务端渲染期间必须额外执行样式收集流程，甚至需要进行二次预渲染，这直接在原先 1900 毫秒的基础上额外增加了约 450 毫秒的耗时，等于凭空吃掉两成服务器算力。
而在客户端，根据 Primer ADR-016 的基准数据，在 1000 个组件的渲染场景中：
- 静态 CSS 仅耗时 96 毫秒；
- 运行时注入 CSS 需要 242 毫秒，耗时超出近 1.5 倍；
- 若包含动态样式，重渲染耗时更是直接飙升至 441 毫秒。
在重度依赖样式的 PR 代码差异对比场景下，动态 sx 需要耗费 400 毫秒，而静态 CSS 只需要 165 毫秒。即使在基础的仓库目录页面，仅因使用 Primer 原生 Box 组件就需耗时 3800 毫秒，改用定制静态 CSS 后耗时立即降至 3076 毫秒，直接提速 20%。
每次组件状态更新，运行时都要重新哈希计算、比对规则、动态向 DOM 插入 <style> 标签。这不仅打乱了浏览器的样式计算流水线，更让原本专司并发与交互的 JS 引擎变成了繁重的样式分发调度器。
置换定律：为什么多发 CSS 反而更快
所谓的多发 CSS，本质是一次精准的算力置换。
长期以来，前端界流行一种体积执念，误以为把 CSS 压缩进 JS 就能减小网络传输压力。然而在现代浏览器架构中，文本体积不是瓶颈，主线程执行开销才是。
CSS 是声明式的，现代浏览器可以使用独立线程并行拉取、流式解析并进行高效率的全局缓存。而一旦样式被封装进 JS 运行时，网络传输后还必须经历反序列化、内存构造和样式注入。GitHub 宁可发送体积略大的独立 CSS 文件，也要将样式解析彻底赶出 JavaScript 主线程。
为了平稳完成这次跨越三年的大规模迁徙，GitHub 采取了极其克制的工程防御策略：
- 分层分步走Primer 基础设计系统率先在 2024 年 12 月完成 CSS Modules 改版，不仅让组件库 SSR 耗时缩减 55%，组件初始化耗时也减少了 25%。
- 中间垫片隔离风险为避免业务层直接崩塌，官方打包了
@primer/styled-react兼容层，允许业务在不中断开发的前提下逐步剥离代码。 - 消除数千个内联属性从 2025 年 4 月立项时全站峰值约 7,760 处
sx属性起步，8 位工程师轮换作战 6 个月消除了 6,419 处；到了 2026 年 4 月剩余 895 处时，团队配合 Copilot coding agent 在三周内完成最终收尾，于 2026 年 6 月达成全站零sx的终点线。 - 低特异性与原生变量从 Primer React v37 起，组件库要求消费端直接从 JS 引入 CSS，样式全面改由原生 CSS 变量驱动以承载全站 7 种主题方案，并严格采用低特异性（low-specificity）选择器确保样式可覆盖。
- 结论.多发 CSS 绝不是工程倒退，而是用确定性的静态网络缓存，去置换昂贵且不可控的客户端算力。
实用主义的抉择与前端秩序回归
这场历时三年的剥离，标志着一个周期的收尾。
耐人寻味的是，GitHub 并没有选择 StyleX 或 vanilla-extract 这类兼具强类型约束与编译期静态抽取的零运行时 CSS-in-JS 框架，而是径直回退到了几乎没有类型花活的 CSS Modules。
这是一种极具现实意味的取舍。采用编译期框架确实能延续 TypeScript 的舒适感，但不可避免地要将整个构建链条与专有编译插件死锁在一起。对于 github.com 这样体量的长期基建而言，与其继续在高度定制的抽象语法树里闪转腾挪，不如退回至最靠近原生 Web 规范的标准路线。
天下皆知美之为美，斯恶已。当行业盲目追逐 DX 并试图用 JavaScript 吞噬 HTML 和 CSS 时，往往忽视了平台原生的演进速度。随着 HTTP/2+ 多路复用、原生 CSS 变量以及 React 18+ 架构的成熟，强行在客户端维持一套庞杂的动态样式引擎，早从当年的最佳实践蜕变成了系统的负资产。
- 提醒.如果你的系统尚未拥有精细的代码分割能力，盲目堆砌全局静态 CSS 依然会诱发静态体积膨胀的次生问题。
从极尽复杂的内联抽象，到重新老老实实写 CSS 文件，这一轮兜兜转转并没有虚掷。它用最直观的渲染速度提醒所有工程师：任何违背底层硬件与浏览器运行机理的体验红利，最终都会以性能债务的形式如数索还。