Kiedy Tailwind CSS niszczy twoją aplikację? 3 błędy średnich firm

Wstęp

Pamiętam ten moment. Na spotkaniu z CTO jednego z klientów usłyszałem: „Przerzuciliśmy się na Tailwinda w zeszłym roku. Było super, ale teraz projekt zwalnia, a developerzy spędzają więcej czasu na debugowaniu niż na nowych feature’ach.” Brzmi znajomo? Tailwind CSS podbił frontendową społeczność swoim utility-first podejściem. Ale jak każda technologia – ma ciemną stronę, która ujawnia się przy większych projektach i średnich firmach.

W tym artykule pokażę Ci trzy realne błędy, które widziałem w produkcyjnych aplikacjach. Błędy, które zamiast przyspieszać, spowalniają rozwój, generują dług techniczny i psują UX.

Błąd 1: Nadmiar klas inline i efekt „spaghetti HTML”

Tailwind zachęca do dodawania klas bezpośrednio w HTML. To świetne prototypowo, ale w długoterminowym projekcie skutkuje czymś, co nazywam „spaghetti HTML”.

Przykład z życia:

Widziałem komponent <ProductCard> z 40 klasami Tailwinda w jednym divie. Każda zmiana wymagała skanowania całego pliku w poszukiwaniu odpowiedniej klasy. Zespół spędzał 30% czasu na czystym utrzymaniu kodu.

Rozwiązanie:

Wyciągnij powtarzające się wzorce do komponentów lub użyj @apply w CSS (ale ostrożnie – to traci elastyczność). Dla klienta z branży e-commerce zdefiniowaliśmy zestaw komponentów z limitowaną liczbą wariantów. Dev time spadł o 25%.

Błąd 2: Ignorowanie bundle size – czy Tailwind naprawdę jest lekki?

Tailwind generuje mnóstwo CSS. W domyślnej konfiguracji plik wyjściowy może ważyć nawet 3-4 MB. Większość frameworków przycina nieużywane klasy na produkcji (purge), ale często widzę projekty, gdzie:

• nie skonfigurowano purge’a poprawnie (brak wskazania ścieżek do plików zawierających klasy)
• użyto dynamicznych nazw klas, przez co purge wycina potrzebne style
• wstrzyknięto cały Tailwind do main.css bez podziału na komponenty

Efekt?

Użytkownicy pobierają 2 MB CSS, z czego 30% jest nieużywane. To zabija Core Web Vitals – szczególnie First Contentful Paint i Time to Interactive.

Case z projektu SaaS:

Podczas audytu jednej platformy B2B wykryliśmy, że główny plik CSS ma 1.8 MB, a po optymalizacji (cięcie komponentami + lazy loading) spadł do 180 KB. Wzrost organicznych konwersji o 8% w ciągu miesiąca.

Błąd 3: Brak spójności design systemu – pułapka „każdy robi po swojemu”

Tailwind daje ogromną swobodę. I to jest jego największe przekleństwo. W zespołach bez silnego leada każdy developer używa własnych wartości spacingu, kolorów czy fontów.

Obserwacja z rynku:

W firmach zatrudniających 5+ frontendowców widzę projekty z 20 różnymi odcieniami niebieskiego i przypadkowymi wartościami mx-3, px-4, mt-6 bez żadnego systemu. To generuje bałagan, który później odbija się na czasie testów i spójności UI.

Jak to naprawić?

Zdefiniuj własną konfigurację Tailwinda (tailwind.config.js) precyzyjnie mapującą design system. Wprowadź enforcowanie przez ESLint (np. plugin eslint-plugin-tailwindcss). W jednym z naszych projektów zrobiliśmy customową konfigurację z ograniczoną paletą i zestawem spacingu – developerzy mieli mniej decyzji do podjęcia, a jakość interfejsu wzrosła.

Więc Tailwind – zło czy dobrodziejstwo?

Sam używam Tailwinda i lubię go. Ale jako praktyk muszę przyznać: to narzędzie dla świadomych. Jeśli nie kontrolujesz powyższych trzech obszarów, zamiast przyspieszenia dostajesz chaos.

Podsumowanie:

• Używaj komponentów zamiast inline klas tam, gdzie wzorce się powtarzają.
• Konfiguruj purge i mierz rozmiar CSS na każdym CI/CD.
• Zbuduj spójny design system w konfiguracji i pilnuj go.

Traktuj Tailwinda jak skalpel – narzędzie, które wymaga precyzji. Bez niej operacja zamienia się w jatkę.

Jeśli potrzebujesz pomocy przy audycie frontendu lub optymalizacji wydajności – w JurskiTech mamy doświadczenie w prostowaniu takich projektów. Napisz, pogadamy.