Più CSS, meno runtime: perché GitHub ha abbandonato CSS-in-JS

Per anni abbiamo trattato il peso del frontend quasi come una contabilità: meno byte, meno JavaScript, meno CSS, quindi più velocità. È una scorciatoia comoda. E, come molte scorciatoie, smette di funzionare quando il sistema diventa abbastanza grande.

Il caso raccontato da GitHub nel suo engineering blog è interessante proprio perché sembra un paradosso: per migliorare le performance di github.com hanno iniziato a spedire più CSS. Non perché il CSS sia magicamente gratis, ma perché hanno tolto lavoro dal runtime.

Il problema non era CSS-in-JS. Era quando quel lavoro veniva fatto

Nel 2023 alcune pagine GitHub avevano accumulato abbastanza componenti da rendere visibile il costo dell’architettura CSS-in-JS usata da Primer. Gli stili dovevano essere inizializzati sul client, la raccolta degli stili pesava sul rendering server-side e il costo degli aggiornamenti cresceva con il numero di componenti presenti nella pagina.

Qui vale una distinzione importante. Dire “CSS-in-JS è lento” sarebbe una conclusione pigra. GitHub non sta pubblicando una legge universale sul frontend: sta descrivendo un sistema arrivato a una scala in cui il costo runtime di quella scelta era diventato misurabile e non più conveniente.

La performance non dipende soltanto da quanto codice spedisci. Dipende da quanto lavoro costringi il sistema a fare, dove lo fai e quante volte lo ripeti.

CSS Modules sposta il costo fuori dal runtime

La soluzione scelta dal team Primer è stata CSS Modules. Gli stili restano vicini al componente e i nomi delle classi sono locali per default, ma il risultato finisce in stylesheet statici inviati con l’HTML. In pratica, una parte del lavoro che prima avveniva durante l’esecuzione viene anticipata alla fase di build.

Questo è il punto architetturale che mi interessa più della tecnologia specifica. Non hanno semplicemente sostituito una libreria con un’altra. Hanno cambiato il momento in cui il sistema paga il costo della gestione degli stili.

Quando tutti i componenti Primer erano stati migrati, nel dicembre 2024, GitHub riporta due numeri notevoli: 55% di tempo in meno per il server-side rendering di una pagina e 25% di tempo in meno per inizializzare i componenti. Sono misure del loro ambiente, non promesse trasferibili a qualsiasi applicazione React. Ma mostrano bene quanto un costo apparentemente secondario possa diventare strutturale.

La parte difficile non era scegliere CSS Modules

La parte più utile del racconto GitHub, però, non è il benchmark. È la migrazione.

Ogni componente veniva convertito, messo dietro feature flag, confrontato con visual regression test e distribuito progressivamente: prima al team, poi allo staff GitHub, infine agli utenti. In parallelo è stato creato @primer/styled-react, uno strato di compatibilità che permetteva al vecchio sx di continuare a funzionare mentre il design system sottostante passava alla nuova architettura.

È una lezione molto più generale del CSS: quando devi cambiare una piattaforma usata ovunque, il problema non è trovare la soluzione tecnicamente più elegante. È costruire un percorso in cui vecchio e nuovo possano convivere abbastanza a lungo da rendere il cambiamento verificabile, reversibile e progressivo.

7.760 eccezioni non si eliminano con una slide di architettura

Dopo Primer restava il prodotto. Nell’aprile 2025 GitHub contava circa 7.760 utilizzi della prop sx. Una rotazione di otto ingegneri ne ha migrati 6.419 in sei mesi, usando un plugin VS Code e un codemod interno, ma mantenendo supervisione e validazione manuale. Su alcune pagine GitHub dichiara miglioramenti SSR compresi fra l’1% e il 22%.

Ad aprile 2026 ne restavano 895. Due ingegneri, affiancati da Copilot coding agents, li hanno portati a zero in tre settimane. Anche qui il dato interessante non è “l’AI ha fatto il lavoro”. È che l’automazione è arrivata dentro un processo già delimitato: obiettivo chiaro, trasformazione ripetibile, verifiche e un’architettura di destinazione già decisa.

Gli agenti hanno accelerato la coda della migrazione. Non hanno sostituito la decisione architetturale né i meccanismi di sicurezza che rendevano possibile quella migrazione.

Poi scopri che il vero coupling era nel tema

Una volta eliminato sx, il lavoro non era ancora finito. GitHub supporta sette temi, con varianti ad alto contrasto, e una parte del theming dipendeva ancora dalle utility JavaScript di styled-components. Le variabili erano già in CSS tramite @primer/css, ma è servito un altro intervento per separare il tema dalla vecchia infrastruttura runtime.

È il classico finale di una migrazione reale: il componente che pensavi fosse il problema era soltanto il punto più visibile di una rete di dipendenze. Quando togli il primo strato emergono compatibilità, temi, utility, convenzioni e assunzioni sedimentate negli anni.

Una migrazione architetturale non finisce quando il nuovo sistema funziona. Finisce quando il vecchio sistema non è più necessario.

Da giugno 2026 github.com è al 100% CSS Modules

GitHub dichiara che da giugno 2026 github.com gira al 100% su CSS Modules e che dal dotcom sono stati rimossi sx, styled-components e styled-system. Il progetto, iniziato come ottimizzazione del modo in cui Primer gestiva gli stili, è diventato una re-platforming del modo in cui GitHub costruisce, tematizza e distribuisce la propria interfaccia.

Ed è qui che il titolo originale del post — “Improving site performance by shipping more CSS” — diventa meno provocatorio di quanto sembri. Spedire più CSS statico può essere una scelta migliore se permette di eliminare elaborazione ripetuta sul client e sul server. Ottimizzare il peso senza guardare il costo di esecuzione significa misurare soltanto una parte del sistema.

La metrica sbagliata produce l’ottimizzazione sbagliata

Questa storia mi interessa perché è un antidoto a una certa idea meccanica di performance. Un bundle più piccolo può essere peggiore se sposta lavoro costoso nel runtime. Una soluzione più dinamica può essere elegante finché la scala non trasforma quella dinamica in una tassa pagata a ogni render. Una tecnologia meno sofisticata può vincere perché fa meno cose nel momento più costoso.

Vale per il frontend, ma vale anche per sistemi molto diversi: database, pipeline dati, automazioni e agenti. Prima di ottimizzare un numero bisogna capire quale lavoro rappresenta, quando viene eseguito e quante volte viene ripetuto.

GitHub non ha dimostrato che CSS Modules sia “migliore” in assoluto. Ha dimostrato qualcosa di più utile: a una certa scala, spostare lavoro dal runtime alla build ha prodotto un guadagno misurabile, e la vera difficoltà è stata costruire una migrazione che permettesse di arrivarci senza rompere il prodotto.

Quindi la domanda non è “quanto CSS sto spedendo?”. La domanda è: quale lavoro sto facendo pagare all’utente e al server per ogni pagina che renderizzo? È lì che spesso si nasconde il costo vero.