Tailwind CSS: Design System Enterprise Senza CSS Custom
Styled-components, CSS modules, SASS con BEM: li abbiamo provati tutti prima di approdare a Tailwind CSS. Quando il nostro team è cresciuto da 2 a 6 sviluppatori, mantenere CSS custom coerente è diventato impossibile. Tailwind ha risolto il problema alla radice — e il bundle CSS è passato da 340KB a 12KB.
Addio CSS Custom: Perché Abbiamo Abbandonato Styled-Components
La prima versione del sito i3k.eu usava styled-components. Funzionava bene con 2 sviluppatori: ognuno conosceva ogni riga di CSS, i nomi delle variabili, le convenzioni. Poi il team è cresciuto. E sono iniziati i problemi. Ogni sviluppatore creava le proprie varianti di colore, i propri spacing, i propri breakpoint. Avevamo 14 diverse sfumature di grigio nel codebase, 8 diverse definizioni di padding "standard", e 3 sistemi di naming diversi per i componenti styled. Il CSS totale pesava 340KB — di cui almeno la metà era codice morto che nessuno osava rimuovere per paura di rompere qualcosa. Il punto di rottura è stato un refactoring della landing page: cambiare il colore primario del brand ha richiesto modifiche in 47 file diversi. Con Tailwind, lo stesso cambio sarebbe stato una modifica in tailwind.config.js e stop. Abbiamo preso la decisione: migrazione a Tailwind per tutti i progetti frontend. La migrazione di i3k.eu ha richiesto 2 settimane. Il sito LetsAI dashboard, più complesso, ha richiesto 4 settimane. Ma il risultato è stato immediato: il bundle CSS finale di i3k.eu è passato da 340KB a 12KB grazie al purging automatico di Tailwind. Solo le classi effettivamente usate finiscono nel bundle.
Il Nostro Design System con Utility Classes
Tailwind non è solo "classi inline" — è la base su cui abbiamo costruito un design system coerente per tutti i prodotti i3k. Il segreto sta nella configurazione. Nel nostro tailwind.config.js definiamo: la palette colori del brand (primary, secondary, accent, con tutte le sfumature da 50 a 950), le unità di spacing personalizzate che mappano al nostro grid system a 8px, i breakpoint responsive coerenti con le dashboard dei nostri prodotti, e le font families con i pesi esatti che usiamo. Ogni sviluppatore del team usa le stesse classi perché sono le uniche disponibili. Non puoi inventarti un grigio custom — usi gray-600 o gray-700. Non puoi mettere un padding di 13px — usi p-3 (12px) o p-4 (16px). Questo vincolo, che sembra limitante, è in realtà liberatorio: elimina le micro-decisioni di design che rallentavano ogni pull request. Per i componenti ricorrenti (bottoni, card, badge, input), abbiamo creato componenti React che wrappano le classi Tailwind. Un Button accetta una prop variant ('primary' | 'secondary' | 'ghost') e applica le classi corrispondenti. I tech stack badges che vedete nella pagina RAG Enterprise su i3k.eu sono tutti componenti con classi Tailwind standardizzate. Questo approccio ci dà la flessibilità di Tailwind con la consistenza di un design system strutturato. Per il responsive design, Tailwind è imbattibile. Scriviamo le classi mobile-first e aggiungiamo varianti con md: e lg: dove serve. La dashboard di LetsAI è completamente responsive con zero media query custom — tutto gestito con le classi responsive di Tailwind.
Performance e Bundle Size: I Numeri Che Contano
Il passaggio a Tailwind ha avuto un impatto misurabile sulle performance di tutti i nostri siti. Ecco i numeri reali, misurati con Lighthouse e WebPageTest. i3k.eu: CSS bundle da 340KB a 12KB (-96%). First Contentful Paint migliorato di 0.4 secondi. Lighthouse Performance score da 82 a 97. La riduzione del CSS ha un impatto diretto sul Critical Rendering Path: meno CSS da parsare significa rendering più veloce. LetsAI dashboard: CSS bundle da 280KB a 18KB. Il miglioramento è meno drastico in percentuale perché la dashboard ha più componenti unici, ma 18KB di CSS per un'intera applicazione enterprise è eccellente. Un vantaggio sottovalutato: il CSS di Tailwind è altamente comprimibile con gzip/brotli perché le classi utility si ripetono e creano pattern prevedibili. I nostri 12KB di CSS diventano 3KB dopo la compressione brotli. Con styled-components, i nomi delle classi hash randomici rendevano la compressione meno efficiente. C'è un costo: l'HTML è leggermente più pesante perché le classi sono scritte direttamente nei componenti. Ma è un costo trascurabile: l'aumento medio è di circa 5KB sull'HTML, ampiamente compensato dai 300KB+ risparmiati sul CSS. Il bilancio netto è enormemente positivo.
Servizi Correlati
Scopri come applichiamo queste tecnologie nei nostri progetti enterprise.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu