Interpretar los estilos
Los objetos y sus variaciones deben procesarse para determinar las reglas aplicables al componente.
Procesando…
React y rendimiento web
GitHub informa de mejoras en el renderizado del servidor y la inicialización tras sustituir su arquitectura CSS-in-JS. Esta experiencia arroja luz sobre las limitaciones del estilizado en runtime, sin convertir CSS Modules en una recomendación universal.
En su experiencia publicada el 25 de septiembre de 2026, GitHub indica que ha completado una migración llevada a cabo durante varios años: desde junio de 2026, su arquitectura de estilos en github.com se basa íntegramente en CSS Modules, sin styled-components, styled-system ni la prop sx.
GitHub informa de una reducción del 55 % del tiempo de renderizado del servidor en una medición tras la migración de Primer, y después de mejoras de aproximadamente entre el 1 % y el 22 % en distintas páginas. Estos resultados describen su entorno: no predicen los beneficios de una migración en otra aplicación React.
CSS-in-JS respondía a necesidades concretas en Primer, el sistema de diseño de GitHub. Los estilos permanecían cerca de los componentes, los design tokens estaban integrados en la API y TypeScript facilitaba el autocompletado. Con sx, los desarrolladores podían personalizar un componente a partir de un objeto JavaScript.
Según GitHub, las dificultades adquirieron importancia alrededor de 2023, con el aumento del número de componentes en algunas páginas. En una solución CSS-in-JS ejecutada en runtime, el procesamiento de los estilos acompaña la ejecución de la aplicación. Repetido en cientos o miles de componentes, este trabajo puede volverse significativo.
Los objetos y sus variaciones deben procesarse para determinar las reglas aplicables al componente.
La biblioteca genera o recupera las clases correspondientes a los estilos, según su funcionamiento y sus mecanismos de caché.
La recopilación de estilos puede añadir trabajo al renderizado de los componentes antes del envío de la página.
El procesamiento y la inyección de estilos pueden contribuir al coste de inicialización de la interfaz.
Estos mecanismos varían según las bibliotecas. Por tanto, hay que distinguir el CSS-in-JS ejecutado en runtime de las soluciones que extraen los estilos durante el build: no presentan necesariamente los mismos costes.
CSS Modules permite asociar una hoja de estilos a un componente y, al mismo tiempo, hacer que los nombres de las clases sean locales al módulo de forma predeterminada. El componente importa una correspondencia de nombres de clases; las herramientas transforman esos nombres para evitar colisiones.
GitHub conserva así una organización orientada a componentes, pero produce hojas de estilos sin depender del mismo procesamiento JavaScript de los estilos durante el renderizado.
La lógica de estilos puede utilizar directamente las propiedades del componente. Esta comodidad debe sopesarse frente al coste de procesamiento medido en la aplicación.
Los archivos CSS siguen vinculados explícitamente a los componentes. Las variantes pueden apoyarse en clases, atributos y variables CSS.
Pasarse a CSS Modules no impide utilizar temas ni cambiar la apariencia. Las variables CSS permiten, en particular, variar colores o espaciados sin reconstruir todas las reglas en JavaScript. En cambio, los comportamientos que antes proporcionaba la biblioteca deben identificarse y retomarse explícitamente.
Las mediciones abarcan varias etapas y varios ámbitos. No deben sumarse ni interpretarse como una aceleración global equivalente de github.com.
| Ámbito comunicado | Indicador | Resultado |
|---|---|---|
| Tras la migración de los componentes de Primer afectados | Tiempo de renderizado del servidor de una página | −55 % |
| Tras la migración de Primer | Tiempo de inicialización de los componentes | −25 % |
| Migración ampliada a distintas páginas de github.com | Tiempo de renderizado del servidor según la página | Aproximadamente entre −1 % y −22 % |
| Benchmark interno de Primer con 1 000 componentes | Inyección de CSS en runtime frente a archivos CSS estáticos | 242 ms frente a 96 ms |
La dispersión de los resultados es reveladora. El número de componentes, las variaciones de estilos y el peso de los demás procesos cambian de una página a otra. Una reducción importante en un caso exigente no garantiza el mismo resultado en una interfaz más sencilla.
Reducir el trabajo del servidor o de JavaScript puede mejorar la experiencia del usuario. Sin embargo, no garantiza ninguna mejora automática en el LCP, el INP o el posicionamiento: las imágenes, las llamadas a la API, los scripts de terceros, la caché y la lógica de negocio pueden seguir siendo los principales obstáculos.
GitHub comenzó por Primer. Para cada componente, una implementación en CSS Modules se colocaba detrás de un feature flag, se comparaba con la anterior mediante pruebas de regresión visual y después se desplegaba progresivamente. Esta primera fase terminó en diciembre de 2024 para los componentes afectados.
El código de github.com todavía contenía aproximadamente 7 760 props sx en abril de 2025. GitHub utilizó una capa intermedia, @primer/styled-react, para que estos usos siguieran funcionando durante la transición. Después, un equipo de ocho ingenieros convirtió 6 419 props sx en seis meses.
Esta coexistencia temporal evitó imponer un cambio único a toda la base de código. Permitió avanzar paquete por paquete, con un ámbito de validación más manejable.
GitHub desarrolló una extensión de Visual Studio Code y un codemod para facilitar las conversiones. Al retomar la última fase en abril de 2026, quedaban 895 apariciones de sx. GitHub informa de que las eliminó en tres semanas con dos ingenieros y varios agentes de GitHub Copilot.
Este resultado corresponde a una transformación ya definida y equipada con herramientas. La automatización acelera las modificaciones repetitivas; no exime de verificar los estilos dinámicos, el responsive, la accesibilidad y las regresiones.
El último obstáculo no se limitaba a las props sx. Parte del sistema de temas todavía dependía de styled-components. GitHub tuvo que desacoplar esta lógica y apoyarse más en las variables CSS de Primer, especialmente para sus distintos temas y variantes de alto contraste.
Es un punto importante para las aplicaciones SaaS: trasladar las declaraciones CSS no basta si la biblioteca también gestiona los temas, los tokens o comportamientos heredados.
No, no basándose únicamente en la experiencia de GitHub. Una arquitectura productiva y suficientemente eficaz no necesita sustituirse porque otra empresa se enfrente a limitaciones diferentes.
Si el rendimiento responde a las necesidades, si la dinámica de los estilos resulta útil y si la migración aporta pocos beneficios, conservar CSS-in-JS puede ser la opción más razonable.
Las páginas muy cargadas, un SSR costoso o una mayoría de estilos estáticos pueden justificar un prototipo en CSS Modules para comparar implementaciones equivalentes.
CSS Modules es una opción pertinente para utilizar CSS estándar con un ámbito local y limitar el runtime dedicado a los estilos. No es la única vía: el CSS estructurado, las clases utilitarias o la generación durante el build también pueden responder a la necesidad. El sistema de diseño, las competencias del equipo y las exigencias de personalización siguen siendo determinantes.
Antes de modificar la arquitectura, establezca una referencia en páginas representativas, incluida una interfaz especialmente cargada. El protocolo debe mantener los mismos componentes, contenidos, comportamientos y condiciones de prueba.
Para una aplicación SSR, siga el tiempo de renderizado, la CPU por solicitud y la memoria. Complételo con el TTFB, los volúmenes de JavaScript y CSS transferidos, la hidratación y las mediciones de LCP e INP entre usuarios reales. Estos indicadores describen dimensiones diferentes: una mejora en uno no garantiza una mejora en los demás.
Una decisión de arquitectura no se reduce a un benchmark. El tiempo de migración, la compatibilidad del sistema de diseño, la cobertura de pruebas y la facilidad de contribución deben formar parte de la evaluación.
La experiencia de GitHub muestra que una solución cómoda al principio de un proyecto puede resultar menos adecuada a otra escala. También muestra que un cambio profundo puede llevarse a cabo progresivamente, sin reescribir toda la aplicación.
Medir, probar en un ámbito reducido, preservar la compatibilidad y validar los resultados: este enfoque es más útil de reproducir que la elección de una biblioteca. CSS Modules puede reducir un coste identificado; no sustituye al diagnóstico.
Referencias indicadas en el brief editorial. Las cifras se atribuyen a la experiencia de GitHub; los documentos no han sido objeto de una verificación independiente para esta redacción.
Desarrollo web
Migración de PHP, actualización de un CMS o cambio de framework: identifique los problemas de compatibilidad y pruebe los recorridos esenciales antes de publicar.
Introduce al menos 2 caracteres para iniciar la búsqueda.