Case study: CSS lżejszy o 65% bez zmiany wyglądu

Drugi wpis z serii o tym, jak budowaliśmy nexowork.pl. Tym razem temat, o którym klienci rzadko słyszą, a który mocno wpływa na szybkość: plik stylów CSS, czyli kod odpowiadający za cały wygląd strony.

Wszystkie liczby w tym tekście to nasze własne pomiary z listopada 2026 roku. Podajemy je dokładnie, z bajtami, bo w odchudzaniu kodu diabeł tkwi w szczegółach.

Skąd się bierze „spuchnięty” CSS?

Strona główna nexowork.pl powstawała iteracyjnie. Sekcje przebudowywaliśmy wiele razy: nowy układ realizacji, nowa sekcja o dostępności, nowe karuzele na telefon, nowe tła z falami. Każda runda dokładała nowe reguły na koniec pliku, a stare zostawały, bo „może się jeszcze przydadzą”.

To typowy mechanizm w każdej żywej stronie. Kreatory stron typu Elementor robią to samo, tylko na dużo większą skalę i bez możliwości posprzątania.

Stan wyjściowy w liczbach

Co mierzyliśmy	Wartość
Rozmiar pliku stylów	539 247 bajtów (ok. 527 KB)
Po minifikacji	516 772 bajty
Po kompresji gzip (to pobiera przeglądarka)	ok. 68 KB
Liczba reguł CSS	2485
Selektory dotyczące tylko strony głównej (.home)	1016 wystąpień
Grafiki SVG wpisane w kod (data URI)	291 sztuk, 161 KB
W tym unikalnych grafik	218
Zdublowane grafiki	ok. 42,7 KB

Najważniejszy wniosek z tej tabeli: każda podstrona, np. kontakt albo wpis na blogu, pobierała pełne style strony głównej, czyli fale, karuzele, realizacje i animacje, których nigdy nie wyświetla.

Lekcja z wcześniejszego etapu: 69 punktów na komputerze

To nie był pierwszy raz, gdy CSS dał o sobie znać. Na wcześniejszym etapie budowy test Google PageSpeed na komputerze pokazał tylko 69 punktów. Strona pojawiała się szybko (pierwszy obraz po 0,3 s, główna treść po 0,6 s), ale potem przez ok. sekundę nie reagowała na kliknięcia: czas blokowania wynosił 990 ms.

Ciekawe było to, że winne nie były skrypty, bo ich wykonanie zajmowało tylko 83 ms. Przeglądarka traciła około 2 sekund na przeliczanie stylów i układu strony z ok. 1150 elementami. Plik stylów miał wtedy 320 KB i 1651 wymuszeń !important.

Wtedy pomogło to, że dolne sekcje rysują się dopiero przy przewijaniu: 13 z 18 sekcji przeglądarka liczy dopiero, gdy się do nich zbliżysz. Prawdziwe rozwiązanie, czyli posprzątanie pliku, zostało na później. Ten wpis opisuje właśnie to sprzątanie.

Krok 1: znaleźć reguły, których nic nie używa

Ręczne przeglądanie 2485 reguł nie wchodziło w grę. Napisaliśmy więc narzędzie, które:

1. Pobiera 33 strony: wszystkie adresy z mapy strony plus warianty, których w mapie nie ma (filtr kategorii na blogu, puste wyniki wyszukiwania, formularz po wysłaniu i z błędem, strona 404, jasna wersja hero).
2. Rozbiera plik CSS na reguły, z zachowaniem bloków @media i @supports.
3. Dla każdego selektora sprawdza, czy na którejkolwiek z 33 stron istnieje pasujący element.
4. Pomija stany, których nie widać w samym kodzie HTML: najechanie myszką, fokus, otwarte menu na telefonie, klasy dodawane przez skrypty (np. „animacja wystartowała”, „karuzela aktywna”, „animacje wstrzymane”). Te klasy trafiły na listę chronionych.

Wynik analizy

Wynik	Liczba
Wszystkich reguł	2485
Reguł do usunięcia (nic na 33 stronach ich nie używa)	409 (16,5%)
Reguł, z których usunięto tylko część selektorów	17 selektorów
Reguł mieszanych (wspólne i tylko dla strony głównej)	4

Krok 2: rozdzielić style na dwa pliki

Samo usunięcie 409 reguł dało 12% mniej kodu. Dużo większy zysk dało rozdzielenie stylów: każda reguła, która pasuje tylko do strony głównej, trafiła do osobnego pliku ładowanego wyłącznie tam.

Plik	Rozmiar	Po minifikacji	Po kompresji gzip	Gdzie się ładuje
Przed: jeden plik	539 247 B	516 772 B	ok. 68 KB	wszędzie
Po: style wspólne	199 969 B	196 893 B	ok. 24 KB	wszędzie
Po: style strony głównej	264 352 B	258 165 B	ok. 36 KB	tylko strona główna

Efekt dla użytkownika:

• podstrona (oferta, kontakt, blog, wpis) pobiera 24 KB zamiast 68 KB stylów, czyli o 65% mniej,
• strona główna pobiera 60 KB zamiast 68 KB, czyli o 12% mniej,
• przeglądarka na podstronie ma do przetworzenia ok. 2,7 raza mniej kodu stylów (199 969 zamiast 539 247 bajtów).

Ważna kolejność: plik strony głównej ładuje się po pliku wspólnym. Dzięki temu reguły, które nadpisywały się nawzajem, dalej działają w tej samej kolejności co wcześniej.

Krok 3: dowód, że nic się nie zmieniło

Odchudzanie CSS ma jedno ryzyko: coś „rozjedzie się” na stronie, której nikt nie sprawdził. Dlatego nie wystarczyło nam „wygląda dobrze”. Zrobiliśmy test porównawczy:

1. Na każdej stronie zapisujemy wyliczony wygląd każdego elementu: 47 właściwości, m.in. pozycję, rozmiar, marginesy, kolory, czcionki, cienie, przezroczystość, siatki, a także pseudo-elementy (fale, kółka i ozdobniki).
2. Podmieniamy w locie stary plik na dwa nowe.
3. Zapisujemy wygląd jeszcze raz i porównujemy element po elemencie.

Strona	Szerokość	Sprawdzonych elementów	Różnic
Strona główna (ciemne hero)	1024 px	1150	0
Strona główna (jasne hero)	1024 px	1150	0
Strona główna	375 px (telefon)	1199	0
Blog	1024 i 375 px	377	0
Wpis na blogu	375 px	460	0
Oferta	1024 px	261	0
Kontakt	1024 px	218	0
O nas	1024 px	211	0
Umów konsultację	1024 i 375 px	234	0
Nexo Core	375 px	368	0

Fałszywy alarm, który warto znać

W pierwszym przebiegu strona główna pokazała 3 różnice na komputerze i 11 przy otwartym menu na telefonie. Wszystkie dotyczyły ozdobników sekcji: pozycja „auto” zamiast konkretnej liczby pikseli.

Przyczyną nie był nowy CSS. Sekcje poza ekranem mają ustawione content-visibility: auto, więc przeglądarka celowo ich nie liczy, dopóki nie są potrzebne. Pierwszy odczyt łapał je w stanie „jeszcze nieobliczone”. Powtórzony test: 0 różnic. Gdybyśmy nie znali tego mechanizmu, moglibyśmy niepotrzebnie cofnąć dobrą zmianę.

Bezpieczeństwo zmiany

• Pełna kopia starego pliku i starej konfiguracji ładowania stylów została zapisana na serwerze.
• Minifikacja jest automatyczna: po każdej edycji pliku źródłowego serwer sam tworzy wersję skompresowaną i zmienia jej numer, więc przeglądarki nie trzymają starej wersji.
• Cache stron wyczyściliśmy od razu, żeby odwiedzający dostali nową wersję.

Co jeszcze można odchudzić

Nie zatrzymujemy się na 65%. Kolejne kroki, które już zmierzyliśmy:

Pomysł	Potencjalny zysk
Usunięcie zdublowanych grafik SVG z kodu	ok. 42,7 KB przed kompresją
Przeniesienie części grafik SVG do osobnych plików	do 161 KB przed kompresją
Scalenie reguł nadpisujących się nawzajem	trudne do oszacowania bez testu

Lekcje dla każdej strony

1. Kod rośnie sam z siebie. Każda przeróbka zostawia ślady. Raz na jakiś czas trzeba posprzątać.
2. Style strony głównej nie powinny ładować się wszędzie. To najprostszy i największy zysk.
3. Sprzątanie bez testu to loteria. Porównanie 1150 elementów daje pewność, której nie da oglądanie strony.
4. Znaj mechanizmy przeglądarki. content-visibility przyspiesza stronę, ale myli proste testy.

To podejście, czyli lekki kod pisany pod konkretną stronę, opisujemy na stronie Nexo Core. O tym, jak przyspieszyliśmy sam serwer, przeczytasz w case study o czasie odpowiedzi serwera. Porównanie z kreatorami stron znajdziesz we wpisie Elementor czy własny kod.

Najczęstsze pytania

Czy usuwanie nieużywanego CSS może zepsuć stronę?

Może, jeśli usuwa się reguły dla stanów, których nie widać w kodzie: otwartego menu, animacji czy elementów dodawanych przez skrypty. Dlatego chroniliśmy takie klasy i porównywaliśmy wygląd przed i po na wielu stronach.

Czy wtyczki do usuwania nieużywanego CSS robią to samo?

Częściowo. Działają automatycznie, ale nie znają Twoich skryptów i często psują menu lub karuzele, a do tego dokładają własny kod. Ręczna analiza z testem porównawczym jest pewniejsza.

Ile CSS powinna mieć strona firmowa?

Nie ma jednej liczby. Dla porównania nasze podstrony pobierają ok. 24 KB stylów po kompresji, a strona główna z wieloma sekcjami i animacjami ok. 60 KB.

Czy minifikacja CSS wystarczy?

Zwykle daje niewiele. U nas usunęła ok. 4% (z 539 247 do 516 772 bajtów). Największy zysk daje usunięcie nieużywanych reguł i rozdzielenie plików.