"Tailwind è leggero" è una frase ricorrente, ma rara da quantificare. Su tre nostri progetti recenti — un'admin dashboard, un sito istituzionale, un e-commerce — abbiamo misurato il delta rispetto a styled-components ed Emotion.
I numeri
- Admin dashboard (era styled-components): bundle JS −34 KB, CSS +18 KB. Net −16 KB. Render time −12% sui list complessi.
- Sito istituzionale (era Emotion): bundle JS −41 KB, CSS +9 KB. Net −32 KB. LCP −180 ms.
- E-commerce (era Tailwind v2 → v3): solo refactor, ma JIT mode ha ridotto il CSS purged da 89 KB a 12 KB. Net −77 KB sul CSS.
Perché succede
CSS-in-JS calcola classi a runtime: ogni componente porta con sé un piccolo costo di parsing/serialization. Su una pagina con 200 componenti, sommato non è invisibile. Tailwind sposta tutto a build time: il CSS arriva già pronto, il JS non deve generare nulla.
Quando CSS-in-JS resta utile
Per stili dinamici realmente dipendenti da runtime state (theme switching avanzato, configuratori utente, A/B test pesanti), Tailwind richiede ginnastica con CSS variables o classi condizionali. Per quei casi, una libreria CSS-in-JS — meglio se zero-runtime come Vanilla Extract o Linaria — è ancora la strada giusta.