Jak zmniejszyć rozmiar CSS przy użyciu purgeCSS

Zmniejszanie rozmiaru plików CSS to prosty sposób na przyspieszenie ładowania stron i poprawę wydajność użytkownika. Jednym z najskuteczniejszych narzędzi do tego celu jest purgeCSS, który usuwa nieużywane reguły z finalnego arkusza stylów. W poniższym tekście omówię, jak działa to narzędzie, jak je poprawnie skonfigurować oraz jakie pułapki i dobre praktyki warto znać, aby nie stracić funkcjonalności ani stylów dynamicznych.

Dlaczego warto usuwać nieużywany CSS

Wiele projektów webowych zawiera setki, a nawet tysiące linii CSS, z których znaczna część nigdy nie jest używana w rzeczywistych widokach. To prowadzi do większych plików do pobrania, dłuższego czasu parsowania przez przeglądarkę i gorszych wyników w narzędziach takich jak PageSpeed. Usuwanie nieużywanych reguł skraca transfer danych i zmniejsza czas renderowania. Dodatkowo mniejszy kod jest łatwiejszy w utrzymaniu i debuggowaniu.

Jak działa purgeCSS

purgeCSS analizuje Twoje pliki źródłowe (HTML, JS, szablony) i porównuje je z selektorami występującymi w CSS. Jeżeli dany selektor nie pojawia się w żadnym pliku treści, zostaje usunięty z finalnego CSS. Kluczowymi elementami działania są: lista plików do analizy, sposób ekstrakcji klas i selektorów oraz mechanizm safelist (whitelist), który pozwala zachować wybrane reguły.

Główne kroki działania

• Skanowanie plików treści (HTML/JS/templating).
• Wyodrębnianie potencjalnych klas i selektorów (domyślny extractor lub niestandardowy).
• Porównanie z regułami CSS.
• Usunięcie reguł, które nie zostały dopasowane.

Konfiguracja i przykłady użycia

Poniżej znajdziesz praktyczne przykłady integracji purgeCSS w typowym build pipeline. Najczęściej używanymi integracjami są: jako plugin PostCSS, w Webpacku, albo w procesie generowania statycznych stron.

Instalacja

Najprostszy sposób to instalacja pakietu PostCSS plugin:

npm install -D @fullhuman/postcss-purgecss

Przykład konfiguracji PostCSS

W pliku postcss.config.js możesz dodać plugin tylko dla produkcji. Ważne jest podanie wszystkich plików, które zawierają klasy (HTML, JS, Vue/React, szablony):

const purgecss = require(’@fullhuman/postcss-purgecss’)({

content: [’./src/**/*.html’, ’./src/**/*.js’, ’./src/**/*.jsx’, ’./src/**/*.vue’],

defaultExtractor: content => content.match(/[A-Za-z0-9-_:/]+/g) || []

})

module.exports = {

plugins: [require(’autoprefixer’), …(process.env.NODE_ENV === 'production’ ? [purgecss] : [])]

}

Warto w powyższym przykładzie poświęcić uwagę defaultExtractor, który definiuje, jak wyciągane są tokeny z plików treści. Dla frameworków generujących złożone klasy (np. Tailwind) używa się bardziej restrykcyjnych wyrażeń regularnych.

Safelist i dynamiczne klasy

Częstym problemem jest usuwanie klas tworzonych dynamicznie (np. klas opartych o propsy Reacta lub zmienne w szablonach). Aby ich nie stracić, użyj opcji safelist (wcześniej whitelist):

purgecss({

content: […],

safelist: [’active’, 'open’, /^btn-/, /^text-/]

})

Możesz przekazywać konkretne nazwy lub wzorce regularne. Używaj ich oszczędnie i celowo — za duża safelist przywróci otyłość CSS.

Integracja z frameworkami i narzędziami

Każdy ekosystem ma swoje niuanse. Poniżej omówienie kilku popularnych przypadków.

Tailwind CSS

Tailwind generuje setki klas naraz, dlatego integracja z purgeCSS jest wręcz niezbędna w produkcji. W konfiguracji Tailwind wystarczy podać pola content/purge, które wskazują pliki do skanowania. W nowych wersjach Tailwind ma wbudowaną obsługę purge (np. pole purge w tailwind.config.js), ale zasada pozostaje ta sama: upewnij się, że wszystkie pliki szablonów są uwzględnione.

React / JSX

W React często używamy klas tworzonych dynamicznie (classnames, template literals). Domyślny extractor może nie wyciągnąć niektórych kombinacji, więc:

• Upewnij się, że pliki .jsx i .tsx są w content globs.
• Użyj wyrażeń regularnych w safelist, by złapać wzorce (np. /^bg-/).
• Rozważ generowanie listy klas w pliku, by były widoczne dla PurgeCSS (np. komentarz lub stała).

Vue / Angular

W przypadku Vue zawarte klasowe wiązania (v-bind:class) wymagają uwagi. PurgeCSS może nie wykryć klas ustawianych jako tablice lub obiekty. W Angularze analogicznie — szablony HTML i pliki TS muszą być podane jako źródło. Dla obu frameworków rozważ stosowanie następujących praktyk:

• Dodaj wszystkie pliki komponentów do content.
• Użyj safelist dla klas generowanych z danych.
• Przetestuj zachowanie po deploymencie.

Najczęstsze problemy i jak ich unikać

Poniżej lista typowych pułapek i praktyczne porady jak ich unikać.

Usunięcie klas dynamicznych

Problem: Po włączeniu purgeCSS znikają style używane tylko dynamicznie (np. „is-active” nadawane w JS). Rozwiązania:

• Dodaj nazwy klas do safelist.
• W kodzie pozostaw komentarz z nazwą klasy (może to być wykryte przez niektóre extractory).
• Generuj listę klas w pliku, który jest skanowany (np. stała w pliku JS).

Selektory zagnieżdżone i pseudoklasy

Jeśli używasz złożonych selektorów (np. .foo > .bar:hover), PurgeCSS porównuje nazwy klas/ID, ale nie zawsze rozpoznaje kontekst. Zadbaj, by najważniejsze kombinacje pozostały w safelist, a reguły nie opierały się jedynie na kontekście usuwanych klas.

CSS Modules i unikalne nazwy

W przypadku CSS Modules klasy są zamieniane na unikalne nazwy w czasie kompilacji. PurgeCSS może nie rozpoznać tych transformacji, dlatego warto przeprowadzić czyszczenie po kompilacji i upewnić się, że analiza plików treści odbywa się z uwzględnieniem zmapowanych nazw, lub stosować integracje specyficzne dla CSS Modules.

Konflikty z innymi narzędziami

Upewnij się, że kolejność pluginów w PostCSS/webpack jest poprawna: najpierw procesory Sass/LESS, potem autoprefixer, a na końcu PurgeCSS (przy produkcji). W przeciwnym razie PurgeCSS może nie widzieć ostatecznych selektorów lub usunąć reguły, które później są modyfikowane.

Dobre praktyki i porady

Oto lista sprawdzonych praktyk, które pomogą bezpiecznie korzystać z purgeCSS:

• Uruchamiaj PurgeCSS tylko w środowisku produkcyjnym, aby nie utrudniać pracy deweloperskiej.
• Podawaj komplet plików do analizy: wszystkie szablony, komponenty i pliki JS, które generują klasy.
• Używaj safelist dla klas dodawanych dynamicznie.
• Testuj aplikację po wdrożeniu: przejrzyj krytyczne widoki i testy wizualne.
• Jeżeli używasz bibliotek UI, rozważ osobne pliki CSS i selektywne purgowanie (np. nie oczyszczaj zewnętrznych bibliotek bez potrzeby).
• Monitoruj rozmiar CSS przed i po — zmierz korzyści i weryfikuj, czy nic nie zostało przypadkowo usunięte.

Jeżeli masz w projekcie wiele warunków generujących klasy, warto stworzyć mały skrypt, który wygeneruje listę wszystkich możliwych klas i zapisze ją do pliku, który zostanie przeczytany przez PurgeCSS jako dodatkowe źródło treści. To pozwala zachować elastyczność bez ryzyka utraty stylów.

Monitorowanie i walidacja

Po włączeniu purgeCSS monitoruj zmiany wielkości plików oraz testy wizualne. Narzędzia takie jak Lighthouse, Webpagetest czy narzędzia do testów wizualnych (Percy, Chromatic) pomogą wykryć regresje. Przydatne jest też trzymanie kopii oryginalnego CSS, by łatwo porównać i odzyskać usunięte reguły, jeśli pojawi się problem.