GitHub passe à CSS Modules : quels gains pour React ?

Pourquoi CSS-in-JS est devenu coûteux pour GitHub

CSS-in-JS répondait à des besoins concrets dans Primer, le design system de GitHub. Les styles restaient proches des composants, les design tokens étaient intégrés à l’API et TypeScript facilitait l’autocomplétion. Avec sx, les développeurs pouvaient personnaliser un composant à partir d’un objet JavaScript.

Selon GitHub, les difficultés sont devenues importantes autour de 2023, avec l’augmentation du nombre de composants sur certaines pages. Dans une solution CSS-in-JS exécutée au runtime, le traitement des styles accompagne l’exécution de l’application. Répété sur des centaines ou des milliers de composants, ce travail peut devenir significatif.

Ces mécanismes varient selon les bibliothèques. Il faut donc distinguer le CSS-in-JS exécuté au runtime des solutions qui extraient les styles au build : elles ne présentent pas nécessairement les mêmes coûts.

CSS Modules : conserver les composants, déplacer le travail

CSS Modules permet d’associer une feuille de style à un composant tout en rendant les noms de classes locaux au module par défaut. Le composant importe une correspondance de noms de classes ; l’outillage transforme ces noms pour éviter les collisions.

GitHub conserve ainsi une organisation orientée composants, mais produit des feuilles de style sans dépendre du même traitement JavaScript des styles au moment du rendu.

Les styles dynamiques ne disparaissent pas

Passer à CSS Modules n’interdit ni les thèmes ni les changements d’apparence. Les variables CSS permettent notamment de faire varier des couleurs ou des espacements sans reconstruire toutes les règles en JavaScript. En revanche, les comportements auparavant fournis par la bibliothèque doivent être identifiés et repris explicitement.

Quels gains GitHub a-t-il mesurés ?

Les mesures portent sur plusieurs étapes et plusieurs périmètres. Elles ne doivent ni être additionnées ni être interprétées comme une accélération globale équivalente de github.com.

La dispersion des résultats est instructive. Le nombre de composants, les variations de styles et le poids des autres traitements changent d’une page à l’autre. Une réduction importante sur un cas chargé ne garantit pas le même résultat sur une interface plus simple.

Une migration progressive plutôt qu’une réécriture

GitHub a commencé par Primer. Pour chaque composant, une implémentation en CSS Modules était placée derrière un feature flag, comparée à l’ancienne par des tests de régression visuelle, puis déployée progressivement. Cette première phase s’est achevée en décembre 2024 pour les composants concernés.

Maintenir la compatibilité avec l’existant

Le code de github.com contenait encore environ 7 760 props sx en avril 2025. GitHub a utilisé une couche intermédiaire, @primer/styled-react, afin que ces usages continuent de fonctionner pendant la transition. Une équipe de huit ingénieurs a ensuite converti 6 419 props sx en six mois.

Cette coexistence temporaire évitait d’imposer une bascule unique à toute la base de code. Elle permettait de progresser package par package, avec un périmètre de validation plus maîtrisable.

Automatiser les transformations connues

GitHub a développé une extension Visual Studio Code et un codemod pour faciliter les conversions. Lors de la reprise de la dernière phase en avril 2026, il restait 895 occurrences de sx. GitHub rapporte leur suppression en trois semaines avec deux ingénieurs et plusieurs agents GitHub Copilot.

Ce résultat concerne une transformation déjà définie et outillée. L’automatisation accélère les modifications répétitives ; elle ne dispense pas de vérifier les styles dynamiques, le responsive, l’accessibilité et les régressions.

Découpler le système de thèmes

Le dernier obstacle ne se limitait pas aux props sx. Une partie du theming dépendait encore de styled-components. GitHub a dû découpler cette logique et s’appuyer davantage sur les variables CSS de Primer, notamment pour ses différents thèmes et variantes à contraste élevé.

C’est un point important pour les applications SaaS : déplacer les déclarations CSS ne suffit pas si la bibliothèque assure aussi les thèmes, les tokens ou des comportements hérités.

Faut-il abandonner styled-components sur une application React ?

Non, pas sur la seule base du retour de GitHub. Une architecture productive et suffisamment performante n’a pas besoin d’être remplacée parce qu’une autre entreprise rencontre des contraintes différentes.

Pour un nouveau projet, partir des contraintes

CSS Modules constitue une option pertinente pour utiliser du CSS standard avec un scope local et limiter le runtime consacré aux styles. Ce n’est pas l’unique voie : CSS structuré, classes utilitaires ou génération au build peuvent également répondre au besoin. Le design system, les compétences de l’équipe et les exigences de personnalisation restent déterminants.

Comment évaluer une migration sans se tromper de priorité

Avant de modifier l’architecture, établissez une référence sur des pages représentatives, dont une interface particulièrement chargée. Le protocole doit conserver les mêmes composants, contenus, comportements et conditions de test.

Mesurer le serveur et le navigateur

Pour une application SSR, suivez le temps de rendu, le CPU par requête et la mémoire. Complétez avec le TTFB, les volumes JavaScript et CSS transférés, l’hydratation et les mesures LCP et INP auprès des utilisateurs réels. Ces indicateurs décrivent des dimensions différentes : une amélioration sur l’un ne garantit pas celle des autres.

Intégrer le coût de maintenance

Une décision d’architecture ne se résume pas à un benchmark. Le temps de migration, la compatibilité du design system, la couverture des tests et la facilité de contribution doivent entrer dans l’évaluation.

Le principal enseignement : garder une architecture évolutive

Le retour de GitHub montre qu’une solution confortable au début d’un projet peut devenir moins adaptée à une autre échelle. Il montre aussi qu’un changement profond peut être mené progressivement, sans réécrire toute l’application.

Mesurer, tester sur un périmètre réduit, préserver la compatibilité et valider les résultats : cette démarche est plus utile à reproduire que le choix d’une bibliothèque. CSS Modules peut réduire un coût identifié ; il ne remplace pas le diagnostic.

Sources et périmètre documentaire Afficher les références

Références indiquées dans le brief éditorial. Les chiffres sont attribués au retour d’expérience de GitHub ; les documents n’ont pas fait l’objet d’une vérification indépendante pour cette rédaction.

• GitHub Engineering — Improving site performance by shipping more CSS, publication indiquée au 25 septembre 2026.
• Primer React — Styling with CSS Architecture Decision Record, pour les choix d’architecture et benchmarks internes.
• Documentation officielle CSS Modules, pour le fonctionnement des classes locales.
• Primer React v37 et v38 — documentation de la transition vers CSS Modules.
• styled-components — documentation du rendu serveur et des React Server Components.