Nie sklejaj plików CSS. Zmierzyłem, ile to kosztuje

👁 118 przeczytań

Skleiłem kilka arkuszy stylów w jeden plik o wadze 69 KB i TBT na stronie wpisu skoczył z 76 do 372 ms. Czas styleLayout wzrósł z 700 do 1018 ms. Zmianę wycofałem, bo poprawa liczby żądań nie zrekompensowała tego, co stało się z wątkiem głównym.

Co dokładnie zmierzyłem

Punktem wyjścia był typowy stan po kilku latach życia motywu i wtyczek: kilka osobnych arkuszy ładowanych w nagłówku, każdy niewielki. Klasyczna rekomendacja z narzędzi audytowych brzmi w takiej sytuacji „zmniejsz liczbę żądań”, więc zrobiłem to, co robi większość ludzi zajmujących się optymalizacją WordPress - połączyłem je w jeden plik. Wyszło 69 KB.

Mierzyłem stronę wpisu, bo to ona generuje u mnie większość ruchu i ona decyduje o wyniku core web vitals w raportach terenowych. Interesowały mnie dwie rzeczy: Total Blocking Time, czyli ile czasu wątek główny był zajęty zadaniami dłuższymi niż 50 ms, oraz czas styleLayout w profilu wydajności, czyli sumaryczny koszt pracy nad stylami i układem.

Prawie pięciokrotny wzrost TBT przy jednoczesnym zmniejszeniu liczby żądań to wynik, który burzy intuicję zbudowaną na poradnikach z poprzedniej dekady. Dlatego warto rozebrać mechanizm.

Dlaczego pięć krótkich zadań bije jedno długie

Przeglądarka wykonuje parsowanie CSS, budowę CSSOM i przeliczanie stylów na wątku głównym - tym samym, na którym wykonuje JavaScript, reaguje na kliknięcia i rysuje klatki. Kluczowa własność: zadanie raz rozpoczęte jest wykonywane do końca. Nie ma wywłaszczenia.

Gdy arkusze są osobne, każdy z nich generuje własne, krótkie zadanie. Między nimi przeglądarka ma okna, w których może obsłużyć coś innego: wykonać fragment skryptu, zareagować na input, oddać klatkę. Pięć krótkich zadań parsowania przeplata się z pozostałą pracą i żadne z nich nie przekracza progu 50 ms, od którego TBT zaczyna cokolwiek liczyć.

Po sklejeniu mam jedno zadanie, które musi przeżuć 69 KB reguł w jednym ciągu. Ono samo przekracza próg i całą swoją długość ponad 50 ms wnosi do TBT. Do tego dochodzi efekt kaskadowy: skoro jedno zadanie trzyma wątek dłużej, zadania stojące za nim w kolejce startują później i częściej wpadają w sytuację, w której konkurują ze sobą. Stąd wzrost styleLayout o 318 ms, mimo że reguł CSS jest dokładnie tyle samo, co przed zmianą. To ta sama praca, tylko upakowana tak, że przeglądarka nie może jej rozłożyć.

Skąd wzięła się porada o sklejaniu

Przy HTTP/1.1 przeglądarka utrzymywała maksymalnie kilka równoległych połączeń na domenę. Szósty plik czekał, aż zwolni się miejsce. Każde połączenie wymagało handshake’u, przy HTTPS dodatkowo negocjacji TLS. W tych warunkach dziesięć małych plików faktycznie było wolniejsze od jednego dużego, nawet jeśli suma bajtów była identyczna - płaciło się za narzut protokołu, nie za treść.

HTTP/2 wprowadził multipleksowanie: wiele strumieni w jednym połączeniu, bez kolejkowania na poziomie żądań. Koszt dodatkowego pliku spadł do wartości, która przy kilku arkuszach jest szumem. Argument za sklejaniem stracił podstawę, ale porada została w narzędziach audytowych i w tysiącach wpisów blogowych. Moja opinia: rekomendacja „zmniejsz liczbę żądań” jest dziś jedną z najbardziej szkodliwych pozostałości po starej epoce, bo brzmi konkretnie i łatwo ją wykonać, a efekt bywa odwrotny do zamierzonego.

Co to znaczy dla TBT i core web vitals

TBT nie jest metryką terenową w core web vitals - w raportach z realnych urządzeń jej rolę pełni INP. Ale TBT jest najlepszym laboratoryjnym przybliżeniem tego, jak zajęty jest wątek główny, i praktycznie zawsze idzie w tę samą stronę co responsywność na interakcje. Skok z 76 do 372 ms oznacza, że w oknie pomiaru dołożyłem prawie trzy dziesiąte sekundy, w których strona nie odpowiedziałaby na dotknięcie ekranu.

Jeśli ktoś szuka szybkiej ścieżki do tbt poprawa, to rozbicie jednego bundle’a na mniejsze pliki jest w tym pomiarze zabiegiem o efekcie -296 ms, wykonanym bez pisania ani jednej linijki nowego CSS. Nie twierdzę, że u każdego wyjdzie tyle samo. Twierdzę, że warto to zmierzyć przed przyjęciem założenia, że mniej plików znaczy szybciej.

Czego ten pomiar nie pokazuje

Uczciwie o ograniczeniach. Sprawdzałem jeden szablon - stronę wpisu - na jednej instalacji, przy jednym zestawie arkuszy sumujących się do 69 KB. Nie sprawdzałem, gdzie leży próg, przy którym sklejanie przestaje szkodzić: możliwe, że przy dwóch plikach po 3 KB różnicy nie będzie żadnej. Nie sprawdzałem też zachowania przy HTTP/1.1, bo mój serwer go nie używa, ani wpływu na serwerach, gdzie dodatkowe żądanie kosztuje więcej niż u mnie.

Druga rzecz: sklejenie nie zmieniło ilości reguł. Gdyby przy okazji łączenia usunąć martwy CSS, wynik byłby mieszanką dwóch efektów i nie dałoby się ich rozdzielić. Dlatego zmieniałem tylko jedną rzecz naraz - liczbę plików - i tylko o tej jednej rzeczy piszę.

Jak to sprawdzić u siebie

1. Zanotuj stan wyjściowy: otwórz DevTools, zakładkę wydajności, nagraj wczytanie strony wpisu z symulacją wolniejszego procesora i zapisz TBT oraz sumaryczny czas styleLayout. Zrób trzy przebiegi i weź medianę, bo pojedynczy pomiar potrafi się rozjechać o kilkadziesiąt milisekund.
2. Policz, ile arkuszy CSS realnie ładuje się na tym szablonie i jaka jest ich suma bajtów. To twój punkt odniesienia.
3. Sprawdź w kolumnie protokołu w zakładce sieciowej, czy serwer obsługuje HTTP/2. Jeśli tak, argument o oszczędzaniu żądań cię nie dotyczy w takiej formie, w jakiej opisują go stare poradniki.
4. Włącz w narzędziu optymalizacyjnym opcję łączenia CSS, wyczyść cache i powtórz pomiar z punktu pierwszego. Tą samą metodą, na tym samym szablonie, w tych samych warunkach dławienia procesora.
5. Porównaj dwie rzeczy: TBT oraz najdłuższe pojedyncze zadanie w profilu. Jeśli po sklejeniu pojawiło się jedno zadanie parsowania dłuższe niż wcześniej wszystkie razem, masz dokładnie ten mechanizm, który opisałem.
6. Jeśli liczby się pogorszyły, wycofaj zmianę i zostaw arkusze osobno. Ja tak zrobiłem - i do dziś nie mam powodu, by wracać.
7. Dopiero po tym zajmij się prawdziwym problemem, czyli objętością CSS. Usunięcie niepotrzebnych reguł zmniejsza pracę do wykonania, a nie tylko przepakowuje ją w inny kształt.