Después de varios días escribiendo sobre agentes que se escapan de sus sandboxes, me apetecía volver a algo más terrenal. Y el equipo de GitHub ha publicado justo el tipo de artículo que me gusta leer un domingo: cómo mejoraron el rendimiento de la web enviando más CSS.
El título suena a contradicción, pero no lo es. Lo que han hecho es sacar los estilos de JavaScript y devolverlos a donde siempre estuvieron: a ficheros CSS. Una migración de casi tres años que terminó en junio de 2026 con GitHub funcionando al 100% con CSS Modules.
El problema: CSS-in-JS a escala
GitHub construye su interfaz con Primer, su sistema de diseño. Durante años, los componentes de Primer React usaban styled-components, una de las librerías de CSS-in-JS más populares: los estilos se escriben en JavaScript, junto al componente, y se generan en tiempo de ejecución.
Es una idea muy cómoda. Todo está en un sitio, tienes tipos de TypeScript, puedes usar tokens de diseño directamente… Pero tiene un coste, y ese coste crece con el número de componentes. Hacia 2023, en algunas páginas de GitHub el número de componentes se disparó y aparecieron tres problemas:
- La carga inicial tardaba más porque los estilos se inicializaban en el cliente.
- El renderizado en servidor (SSR) empeoró al tener que recolectar estilos.
- Las actualizaciones de estilos se volvían inmanejables a medida que crecía la página.
Dicho de otra forma: cada componente en pantalla era un poco de JavaScript extra que el navegador tenía que ejecutar solo para saber de qué color pintar un botón.
La solución: CSS Modules
La alternativa que eligieron fue CSS Modules. Los estilos se escriben en un fichero .css al lado del componente, las clases son locales por defecto (así que no chocan entre sí) y, lo más importante, no hay nada que ejecutar en el cliente ni en el servidor. Todo se compila a hojas de estilo normales que viajan con el HTML.
La diferencia, simplificada, es esta:
// Antes: CSS-in-JS con la prop sx, resuelto en tiempo de ejecución
<Box sx={{ display: 'flex', gap: 2, color: 'fg.muted' }}>
...
</Box>
/* Después: Toolbar.module.css, compilado a CSS estático */
.toolbar {
display: flex;
gap: var(--base-size-8);
color: var(--fgColor-muted);
}
import styles from './Toolbar.module.css'
<div className={styles.toolbar}>...</div>
Pierdes algo de la magia de tener todo en un objeto de JavaScript, pero ganas algo mucho más valioso: el navegador hace lo que mejor sabe hacer, que es aplicar CSS.
Cómo migras una web como GitHub sin romperla
Esta es la parte que me parece más interesante del artículo, porque es aplicable a cualquier proyecto grande. La receta fue siempre la misma, componente a componente:
flowchart LR
A["Nuevo fichero CSS Module · junto al estilo antiguo"] --> B["Feature flag · alterna entre los dos"]
B --> C["Tests de regresión visual · capturas idénticas"]
C --> D["Despliegue gradual · equipo, plantilla, todos"]Nada de un gran cambio de golpe. Los dos sistemas conviviendo, un interruptor para pasar de uno a otro y tests visuales para comprobar que el resultado era idéntico píxel a píxel. Si algo fallaba, se apagaba el flag.
Primer terminó de migrar todos sus componentes en diciembre de 2024, y los números compensaron el esfuerzo:
| Métrica | Mejora |
|---|---|
| Tiempo de renderizado en servidor | 55% menos |
| Tiempo de inicialización de componentes | 25% menos |
La parte difícil: miles de sx
Migrar el sistema de diseño era solo la mitad. El resto de GitHub seguía usando la prop sx, que permitía a cualquier equipo personalizar un componente con un objeto de estilos en línea. Era lo mejor y lo peor de CSS-in-JS a la vez: comodísima de usar, y cara de ejecutar.
Para no bloquear a nadie crearon un paquete puente, @primer/styled-react, que envolvía los componentes nuevos y seguía aceptando sx. Así, el código que no la usaba se beneficiaba ya de las mejoras, y el que sí la usaba podía migrarse poco a poco.
Y aquí viene el dato que más me ha llamado la atención:
| Fase | Props sx migradas | Equipo | Tiempo |
|---|---|---|---|
| Abril 2025 – octubre 2025 | 6.419 (de un pico de ~7.760) | Rotación de 8 ingenieros, con un plugin de VS Code y codemods | 6 meses |
| Abril 2026 | Las últimas 895 | 2 ingenieros y agentes de Copilot | 3 semanas |
El trabajo no cambió. Lo que cambió fue la herramienta. Un año después, dos personas con agentes de código hicieron en tres semanas lo que antes había llevado medio año a un equipo más grande. Y lo hicieron con la misma red de seguridad de siempre: feature flags, tests visuales y despliegue gradual. Los agentes aceleraron el trabajo, pero no sustituyeron el proceso que evitaba romper cosas.
Después quedaba desacoplar los temas (GitHub tiene siete, cada uno con su variante de alto contraste) de styled-components. Otros dos meses. En junio de 2026 retiraron por fin sx, styled-components y styled-system de github.com.
Como curiosidad, mientras preparaban todo esto, styled-components anunció que pasaba a modo mantenimiento. No hay mejor confirmación de que iban en la dirección correcta.
Lo que me llevo
La primera lección es que el mejor JavaScript es el que no se ejecuta. Durante unos años nos convencimos de que meter los estilos en JavaScript era la forma moderna de hacer las cosas, y para muchos proyectos lo fue. Pero CSS ha avanzado muchísimo —variables nativas, @layer, anidamiento, :has()— y hoy casi todo lo que nos llevó a CSS-in-JS se puede hacer con CSS normal compilado en el build. Este mismo blog funciona así con Tailwind v4: todo el CSS se genera al compilar el sitio y el navegador no ejecuta nada para aplicarlo.
La segunda es sobre el cómo. Lo que hace este artículo valioso no es la elección de CSS Modules, sino la disciplina de la migración. Convivencia de los dos sistemas, un interruptor para cada cambio, tests que comparan capturas y despliegues por fases. Es aburrido, es lento y es exactamente lo que permite cambiar la arquitectura de una web que usan millones de personas sin que nadie lo note.
Y la tercera es que las migraciones largas y tediosas son un terreno perfecto para los agentes de código, siempre que el proceso de seguridad ya esté montado. Pasar de 895 a 0 en tres semanas no fue magia: fue un trabajo repetitivo y bien acotado, con una forma clara de comprobar si cada cambio estaba bien. En esas condiciones, un agente es una ayuda enorme.
