87% arkusza stylów szło na darmo. Usuwanie bije minifikację

👁 120 przeczytań

Arkusz szablonów na mierzonej instalacji ważył 75 094 bajty i ładował się na każdej podstronie, mimo że większość stron nie używała żadnego szablonu. Wersja podstawowa tego samego arkusza ma 9 708 bajtów - czyli 87% wagi szło na darmo. Żadna minifikacja nie da takiego wyniku, bo minifikator nie wie, że plik jest tu zbędny.

Skąd się bierze nieużywany CSS na WordPressie

Motywy i wtyczki rejestrują swoje style w jednym miejscu i wypisują je bezwarunkowo. Z punktu widzenia autora wtyczki to rozsądne: nie wie, na której podstronie jego komponent się pojawi, więc dokłada arkusz wszędzie. Problem robi się wtedy, gdy komponent jest używany na trzech podstronach z trzystu, a arkusz jedzie na wszystkich trzystu.

W mierzonym przypadku było dokładnie tak. Arkusz szablonów obsługiwał kilka wariantów układu treści - siatki, kolumny, warianty kart. Większość stron w serwisie korzystała z układu podstawowego, który potrzebuje tylko fragmentu reguł. Ten fragment to właśnie 9 708 bajtów. Pozostałe 65 386 bajtów to reguły dla szablonów, których na tych stronach nie było.

Opinia: wtyczki typu „remove unused CSS” próbują rozwiązać to automatycznie, skanując DOM i wycinając selektory. Wolałbym ręczne warunki w kodzie motywu, bo skanery często gubią klasy dodawane przez JavaScript po załadowaniu strony. Ale to ocena z mojego workflow, nie wynik pomiaru.

Co dokładnie zmierzyłem

Porównanie dotyczy jednego zasobu na jednym widoku - podstronie, która nie używała żadnego szablonu. Waga to rozmiar pliku przed transferem, bez kompresji na poziomie serwera.

Do tego doszedł drugi przypadek tej samej klasy: biblioteka jQuery ładowana mimo braku konsumenta. Żaden skrypt na tej podstronie nie odwoływał się do jQuery, a plik i tak był w kolejce, bo zarejestrowała go wtyczka aktywna globalnie.

Dlaczego minifikacja tu nie wystarczy

Minifikator robi trzy rzeczy: usuwa komentarze, usuwa białe znaki, skraca zapisy wartości. Wszystkie te operacje działają na treści pliku i żadna nie zadaje pytania „czy ten plik jest tu potrzebny”. Jeśli arkusz ma 75 094 bajty i zostawisz go w kolejce, po minifikacji nadal będzie się ładował na każdej podstronie - tylko lżejszy.

Warunkowe wypisanie działa na innym poziomie. Zamiast pytać „jak mniej waży ten plik”, pyta „czy w ogóle go wysyłać”. Na podstronie bez szablonu odpowiedź brzmi nie, więc oszczędność jest pełna: 75 094 bajty zamiast części z nich. To jest sedno tezy - przyspieszenie WordPressa zaczyna się od inwentaryzacji, nie od kompresji.

Drugi efekt, który warto policzyć osobno: mniej plików w kolejce to mniej zapytań HTTP i krótsza ścieżka krytyczna renderowania. W przypadku jQuery ładowanej bez konsumenta usunięta została nie tylko waga, ale cały blokujący zasób.

Jak to wpisać w kod motywu

Mechanika jest banalna i sprowadza się do jednego warunku w miejscu, gdzie rejestrujesz styl. Zamiast wypisywać arkusz szablonów zawsze, wypisz go tylko wtedy, gdy aktualny widok faktycznie używa szablonu. Warunek może opierać się na typie wpisu, na wartości pola w bazie, na obecności konkretnego bloku w treści - to zależy od tego, jak w danym serwisie wybiera się szablon.

Analogicznie z jQuery: jeśli żaden skrypt na widoku nie potrzebuje biblioteki, wyrejestruj ją dla tego widoku. Kluczowe jest słowo „dla tego widoku” - globalne wyłączenie jQuery na serwisie, który gdzieś jej używa, kończy się zepsutym koszykiem albo galerią.

Dzielenie arkusza na wersję podstawową i rozszerzoną to trzecia opcja, użyta w mierzonym przypadku. Wersja podstawowa (9 708 bajtów) jedzie wszędzie, bo zawiera reguły układu potrzebne na każdej stronie. Reszta dokłada się tylko tam, gdzie szablon występuje.

Czego ta metoda nie naprawi

Uczciwie: warunkowe wypisanie plików nie pomaga na stronach, które rzeczywiście używają wszystkiego. Jeśli twój landing korzysta z każdego wariantu szablonu, arkusz o wadze 75 094 bajty jest tam potrzebny w całości i wtedy wracamy do minifikacji oraz kompresji transferu.

Nie rozwiązuje też problemu duplikatów - sytuacji, w której dwie wtyczki dowożą własne kopie tej samej biblioteki. To osobna robota, polegająca na ujednolicaniu zależności, a nie na warunkach.

Opinia: mimo tych ograniczeń zaczynam każdy audyt od inwentaryzacji kolejki zasobów, bo w praktyce największe liczby wychodzą właśnie tam. 87% wagi jednego pliku to skala, której nie odzyskasz żadnym parserem CSS.

Jak to sprawdzić u siebie

1. Otwórz podstronę, którą uważasz za najprostszą w serwisie - zwykły artykuł bez galerii, formularzy i osadzeń.
2. W narzędziach deweloperskich przełącz się na zakładkę z listą zasobów i posortuj po rozmiarze. Zapisz wagę każdego arkusza CSS i każdego pliku JavaScript.
3. Dla trzech najcięższych arkuszy sprawdź w narzędziu pokrycia kodu, jaki procent reguł jest na tej stronie używany. Jeśli widzisz wartości rzędu kilkunastu procent, masz kandydata do usunięcia, nie do minifikacji.
4. Dla każdego skryptu sprawdź, czy istnieje na stronie jego konsument. jQuery bez żadnego wywołania to czysty balast - dokładnie ten przypadek miałem w pomiarze.
5. Ustal, od czego zależy użycie ciężkiego arkusza: typ wpisu, szablon strony, obecność konkretnego bloku. To będzie twój warunek.
6. Wypisz arkusz warunkowo i przeklikaj wszystkie typy widoków - strona główna, archiwum, wpis, strona kontaktu, wyniki wyszukiwania, 404. Szukasz rozjechanego układu, nie brakującego koloru.
7. Powtórz pomiar wagi z punktu drugiego i porównaj obie liczby w tabeli. Dopiero teraz włącz minifikację na tym, co zostało w kolejce.