Co oznacza CSS blokujący renderowanie?
Przeglądarka potrzebuje reguł CSS, aby ustalić wygląd elementów strony. Gdy w kodzie znajduje arkusz stylów dotyczący aktualnego widoku, zwykle pobiera go i przetwarza przed wyświetleniem zawartości. Dzięki temu użytkownik nie widzi najpierw nieostylowanego tekstu i układu, które po chwili gwałtownie się zmieniają. Kosztem jest oczekiwanie na arkusz, zwłaszcza jeśli plik jest duży lub jego pobieranie zaczyna się późno.
Samo określenie „blokujący renderowanie” nie oznacza błędu. Główne style strony są potrzebne od początku. Problem pojawia się wtedy, gdy przeglądarka musi czekać na kod, który nie ma znaczenia dla pierwszego widocznego fragmentu. Przykładem jest wspólny plik zawierający zarówno style nagłówka sklepu, jak i obszerne reguły panelu konta, mimo że użytkownik otwiera stronę kategorii.
Jak potwierdzić, że CSS rzeczywiście opóźnia stronę?
Zacznij od konkretnej podstrony i warunków testu. Strona główna, artykuł i karta produktu mogą ładować różne style. W narzędziach deweloperskich przeglądarki otwórz zakładkę sieciową, przeładuj stronę i sprawdź, które pliki CSS są pobierane, jak długo to trwa oraz czy ich pobieranie rozpoczyna się dopiero po innych zasobach. W widoku wydajności zwróć uwagę na moment pojawienia się pierwszej treści i największego widocznego elementu. Pojedynczy pomiar może się wahać, dlatego porównuj próby wykonane w podobnych warunkach.
Raporty wydajności mogą wskazywać zasoby blokujące renderowanie, ale traktuj tę informację jako punkt wyjścia. Sprawdź również, czy plik jest wykorzystywany w początkowym widoku. Funkcja pokrycia kodu w narzędziach przeglądarki pomaga znaleźć reguły nieużyte podczas danego testu. Nie dowodzi jednak, że można je bezpiecznie usunąć: style rozwijanego menu, komunikatu o błędzie czy widoku mobilnego mogą być potrzebne później. Powtórz kontrolę na różnych szerokościach ekranu i po wykonaniu typowych działań użytkownika.
Najpierw ogranicz zbędny CSS
Najbezpieczniejsza poprawka często polega na zmniejszeniu ilości stylów wymaganych na danej podstronie. Sprawdź, czy szablon nie dołącza plików przeznaczonych wyłącznie dla formularza, galerii lub panelu administracyjnego. Usuń nieużywane reguły dopiero po sprawdzeniu wszystkich szablonów i stanów interfejsu, których dotyczą. Jeśli korzystasz z gotowego motywu lub wielu wtyczek, ustal, który składnik dodaje dany arkusz, zanim zmienisz sposób jego ładowania.
Warto też zadbać o podstawy dostarczania plików: kompresję odpowiedzi, odpowiednie buforowanie powtarzalnych zasobów i unikanie niepotrzebnych łańcuchów importów. Dyrektywa @import wewnątrz arkusza może sprawić, że kolejny plik zostanie odkryty dopiero po pobraniu wcześniejszego. Dzielenie jednego pliku na wiele mniejszych ma sens, gdy pozwala nie pobierać stylów niepotrzebnych na danej stronie; samo zwiększenie liczby plików nie gwarantuje poprawy.
Jak ładować style potrzebne dopiero później?
Jeśli pierwsza część strony korzysta z niewielkiego zestawu reguł, można rozważyć umieszczenie krytycznych stylów bezpośrednio w dokumencie, a resztę pobrać osobno. Krytyczny CSS powinien obejmować tylko elementy potrzebne do poprawnego wyświetlenia początkowego widoku, na przykład nagłówek, podstawowy układ i główną treść. Zbyt duży blok stylów w dokumencie powiększa HTML, a jego zmiana może utrudniać korzystanie z pamięci podręcznej wspólnego pliku CSS.
Arkusze przeznaczone dla określonych warunków można oznaczyć odpowiednim atrybutem media, aby przeglądarka wiedziała, kiedy są potrzebne. Inne techniki opóźniania stylów wymagają większej ostrożności: jeżeli skrypt włącza arkusz dopiero po załadowaniu strony, sprawdź działanie przy wolnym połączeniu, przy wyłączonym JavaScripcie i podczas nawigacji. Nie odkładaj stylów odpowiedzialnych za widoczną treść tylko po to, by usunąć ostrzeżenie z raportu. Może to zastąpić oczekiwanie na CSS nieprzyjemnym „przeskakiwaniem” układu.
Lista kontrolna przed i po zmianie
Przed wdrożeniem zapisz, które arkusze ładuje badana podstrona i jak wygląda jej pierwszy widok na telefonie oraz komputerze. Wskaż style niezbędne od początku, osobno oznacz style używane po interakcji i sprawdź, czy pliki nie są dołączane na stronach, które ich nie potrzebują. Wprowadzaj jedną grupę zmian naraz, aby łatwiej ustalić przyczynę ewentualnego problemu.
Po zmianie porównaj podobne pomiary wydajności, ale przede wszystkim obejrzyj stronę podczas ładowania. Przetestuj menu, formularze, komunikaty, wersję mobilną i typowe podstrony korzystające ze wspólnych stylów. Jeśli treść pojawia się bez formatowania, elementy zmieniają położenie lub część interfejsu przestaje działać, poprawka wymaga korekty. Celem nie jest wyeliminowanie każdego arkusza blokującego renderowanie, lecz szybsze i stabilne wyświetlenie użytecznej strony.
