Krytyczny CSS i nieużywane style: jak odchudzić arkusze i przyspieszyć pierwsze wyświetlenie

Dlaczego arkusze stylów wstrzymują rysowanie strony

Arkusze stylów wstrzymują rysowanie, ponieważ przeglądarka z założenia nie pokazuje treści, zanim nie pozna jej wyglądu. Jak wyjaśnia opracowanie web.dev o stylach blokujących renderowanie, do narysowania strony potrzebne są dwie struktury: drzewo dokumentu zbudowane z kodu HTML oraz model stylów zbudowany z CSS. Dopóki druga z nich nie jest gotowa, ekran pozostaje pusty, nawet jeśli tekst strony dawno dotarł do urządzenia.

Takie zachowanie ma uzasadnienie. Kurs web.dev poświęcony ładowaniu zasobów tłumaczy, że przeglądarka blokuje rysowanie, aby odwiedzający nie zobaczył na moment surowej, nieostylowanej treści, która po chwili gwałtownie zmienia wygląd. Samo blokowanie nie jest więc wadą. Kłopot zaczyna się wtedy, gdy trwa zbyt długo, czyli gdy arkuszy jest dużo, są ciężkie albo pobierają się przez wolne połączenie.

Co dzieje się przed pierwszym wyświetleniem

Każdy zewnętrzny arkusz to osobne żądanie do serwera. Dokumentacja Lighthouse, czyli narzędzia Google do badania jakości stron, w opisie zalecenia o usuwaniu nieużywanego CSS wskazuje trzy koszty zbędnych stylów. Po pierwsze, plik trzeba pobrać. Po drugie, trzeba go przeanalizować. Po trzecie, przy budowaniu drzewa renderowania przeglądarka dla każdego elementu strony ustala, które reguły go dotyczą, więc im więcej reguł, tym dłużej trwa samo obliczanie wyglądu.

Ciężki CSS opóźnia nie tylko rysowanie. Według kursu web.dev skrypt, który blokuje analizę dokumentu, musi poczekać na pobranie i przetworzenie stylów będących w drodze, ponieważ może odczytywać wygląd elementów. O samych skryptach piszemy we wpisie o skryptach zewnętrznych i szybkości strony.

Reguła @import wydłuża kolejkę

Osobnym źródłem opóźnień jest dołączanie jednego arkusza do drugiego regułą @import. Kurs web.dev opisuje, że powstaje wtedy łańcuch żądań: najpierw musi dotrzeć plik główny, dopiero potem przeglądarka dowiaduje się o kolejnym. Takie pliki są odkrywane późno, a mimo to blokują rysowanie. Zalecane jest podłączanie arkuszy znacznikiem link, bo wtedy pobierają się równolegle.

Który wskaźnik na tym cierpi

Najbardziej bezpośrednio cierpi FCP (First Contentful Paint), czyli czas do pierwszego wyrenderowania treści. Opis tego wskaźnika na web.dev podaje, że dobry wynik to najwyżej 1,8 sekundy, a wynik powyżej 3 sekund jest oceniany jako słaby. Wśród sposobów poprawy wymieniono tam eliminację zasobów blokujących renderowanie oraz zmniejszenie i usunięcie nieużywanego CSS. Opóźnione pierwsze wyświetlenie przesuwa też moment pokazania największego elementu, o czym piszemy we wpisie o wskaźniku LCP.

Czym jest krytyczny CSS

Krytyczny CSS to zestaw stylów potrzebnych do narysowania tej części strony, którą odwiedzający widzi od razu, bez przewijania. Technika opisana w opracowaniu web.dev o wydzielaniu krytycznego CSS polega na tym, że te style trafiają bezpośrednio do nagłówka dokumentu HTML, w znaczniku style, a pozostała część arkusza ładuje się w sposób, który nie wstrzymuje rysowania. Przeglądarka dostaje wszystko, czego potrzebuje do pierwszego obrazu, w jednej odpowiedzi serwera i nie musi czekać na dodatkowy plik.

Warto od razu zaznaczyć, że górna część ekranu nie ma jednej wysokości. To samo źródło podkreśla, że urządzenia i rozmiary ekranów są zbyt różne, aby wskazać uniwersalną liczbę pikseli. Krytyczne style wyznacza się więc dla kilku typowych rozmiarów, przynajmniej dla telefonu i komputera, i łączy w jeden zestaw.

Skąd granica czternastu kilobajtów

W opracowaniu web.dev pojawia się konkretna wskazówka: treść potrzebna do pierwszego wyświetlenia powinna po kompresji mieścić się w 14 KB. Wynika to ze sposobu działania połączeń sieciowych. Nowe połączenie nie korzysta od razu z pełnej przepustowości, a serwer w pierwszej turze wysyła zwykle około dziesięciu pakietów, czyli mniej więcej 14 KB. W kolejnych turach ilość danych rośnie. Jeśli początek dokumentu razem z krytycznymi stylami zmieści się w pierwszej turze, przeglądarka może zacząć rysować bez kolejnej wymiany z serwerem. O samej kompresji piszemy we wpisie o gzip i Brotli.

Wady, o których trzeba wiedzieć

Technika ma swoją cenę. Style wpisane w dokument powiększają każdą odpowiedź HTML i nie zapisują się w pamięci podręcznej przeglądarki tak jak zewnętrzny plik, więc przy kolejnych odsłonach są przesyłane ponownie. Zbyt obszerny blok stylów w nagłówku opóźnia dotarcie reszty dokumentu i odbiera całą korzyść. Dochodzi trudność utrzymania: po każdej zmianie wyglądu zestaw trzeba wyznaczyć od nowa.

Kiedy więc próbować? Źródło podaje dwa sygnały: słaby wynik FCP oraz zalecenie dotyczące zasobów blokujących renderowanie w raporcie Lighthouse. Dodaje też, że efekt zależy od witryny, a ogólna prawidłowość jest taka, że im więcej CSS ma serwis, tym większa możliwa korzyść.

Gdzie sprawdzić, czy style spowalniają stronę

Najszybciej widać to w raporcie Lighthouse, dostępnym w przeglądarce Chrome oraz w PageSpeed Insights. Wśród zaleceń dotyczących wydajności znajdują się dwa, które odnoszą się wprost do arkuszy: o zasobach blokujących renderowanie i o nieużywanym CSS. Przy każdym z nich raport wymienia konkretne pliki, co pozwala od razu ustalić, czy winny jest motyw, wtyczka, czy biblioteka pobierana z zewnątrz.

Zalecenie o zasobach blokujących renderowanie

Dokumentacja tego zalecenia precyzuje, które arkusze trafiają na listę. Lighthouse zgłasza znacznik link z arkuszem stylów, o ile nie ma on atrybutu disabled, który powstrzymuje pobieranie, oraz o ile jego atrybut media pasuje do urządzenia odwiedzającego. Zapis media="all" jest traktowany jako blokujący. Skrypty z nagłówka są zgłaszane wtedy, gdy nie mają atrybutu defer ani async. Dokumentacja informuje też, że od wersji Lighthouse 13 to zalecenie zostało przeniesione do nowej sekcji statystyk poświęconej żądaniom blokującym renderowanie, dlatego w nowszych raportach może nosić nieco inną nazwę.

Zalecenie o nieużywanym CSS

Drugie zalecenie wymienia arkusze, w których możliwa oszczędność wynosi co najmniej 2 KiB. Lista jest krótka i czytelna, ale ma ograniczenie: dotyczy jednej badanej podstrony i jednego załadowania. Arkusz, który na stronie głównej wygląda na niemal zbędny, może być w pełni potrzebny w koszyku albo na stronie kontaktu. Dlatego wynik z raportu to wskazówka, gdzie szukać, a nie lista plików do skasowania.

Narzędzie Pokrycie w Chrome: jak wykryć nieużywane reguły

Pokrycie (w angielskiej wersji przeglądarki Coverage) to panel narzędzi deweloperskich Chrome, który pokazuje, jaka część każdego pliku CSS i JavaScript została faktycznie wykorzystana podczas ładowania strony i korzystania z niej. Jest dostępny bez opłat w każdej instalacji Chrome i nie wymaga logowania. Polska dokumentacja panelu opisuje dwa sposoby otwarcia.

1. Otwarcie narzędzi deweloperskich

   Na badanej podstronie należy otworzyć narzędzia deweloperskie Chrome, na przykład klawiszem F12 albo z menu przeglądarki.

2. Otwarcie panelu Pokrycie

   Pierwsza droga prowadzi przez menu poleceń: po jego otwarciu wystarczy wpisać słowo coverage i wskazać polecenie Pokaż pokrycie. Druga droga to przycisk Więcej opcji w prawym górnym rogu narzędzi, a następnie Więcej narzędzi i Pokrycie. Panel otwiera się w dolnej szufladzie.

3. Rozpoczęcie nagrywania

   Na środku panelu znajduje się przycisk Przeładuj. Po jego kliknięciu strona ładuje się ponownie, a narzędzie zaczyna zapisywać, które fragmenty kodu zostały użyte.

4. Korzystanie ze strony

   Nagrywanie trwa także podczas korzystania ze strony. Warto w tym czasie przewinąć ją do końca, rozwinąć menu, otworzyć okno z formularzem i wykonać inne typowe czynności.

5. Zatrzymanie i odczyt

   Przycisk Zatrzymaj instrumentację i pokaż wyniki kończy nagrywanie. Listę można zawęzić do samych arkuszy, wskazując pozycję CSS na liście typów zasobów.

Jak czytać tabelę wyników

Raport ma postać tabeli, w której każdy wiersz to jeden plik. Znaczenie kolumn przedstawia zestawienie poniżej.

Kliknięcie wiersza otwiera plik w panelu Źródła, gdzie nieużyte wiersze kodu są oznaczone pionowymi szarymi liniami obok numerów wierszy. Na pasku stanu widać łączny odsetek wykorzystanego kodu, a przycisk Eksportuj pokrycie pozwala zapisać wynik do pliku i przekazać go osobie, która będzie wprowadzać zmiany.

Czego Pokrycie nie powie

Wynik opisuje wyłącznie to, co wydarzyło się podczas nagrywania: na jednej podstronie, przy jednej szerokości okna i przy czynnościach, które zostały wykonane. Reguły dla telefonu nie zostaną uznane za użyte, jeśli pomiar odbył się w szerokim oknie komputera. Style komunikatu o błędzie w formularzu pozostaną szare, jeśli formularz nie został wysłany z błędem. To samo dotyczy stanów po najechaniu kursorem, okien dialogowych, banera zgody na pliki cookie czy wersji do druku.

Dokumentacja panelu uczciwie stawia sprawę: znalezienie nieużywanego kodu jest łatwą częścią pracy, a trudną jest takie przebudowanie serwisu, aby każda podstrona ładowała tylko to, czego potrzebuje. Sposób tej przebudowy zależy od technologii, na której działa witryna.

Jak wydzielić krytyczny CSS i odroczyć pozostałe style

Wydzielenie polega na trzech czynnościach: ustaleniu, które reguły są potrzebne do narysowania górnej części ekranu, wpisaniu ich do nagłówka dokumentu oraz zmianie sposobu podłączenia pełnego arkusza tak, aby nie blokował rysowania. Kolejność ma znaczenie, ponieważ odroczenie arkusza bez wcześniejszego wpisania stylów krytycznych kończy się tym, że odwiedzający przez chwilę widzi stronę bez wyglądu.

Ustalanie stylów krytycznych

Opracowanie web.dev o odraczaniu niekrytycznego CSS pokazuje sposób ręczny z użyciem panelu Pokrycie. Po przeładowaniu strony, bez przewijania i klikania, reguły oznaczone jako użyte to te, których wymaga widoczna treść, a oznaczone jako nieużyte dotyczą elementów niewidocznych od razu. Pierwszą grupę przenosi się do bloku style w nagłówku.

Przy większym serwisie praca ręczna szybko staje się uciążliwa, dlatego web.dev zaleca narzędzia automatyczne i wymienia trzy otwarte rozwiązania: Critical, criticalCSS oraz Penthouse. Pierwsze z nich wyodrębnia style, zmniejsza je i wpisuje do dokumentu, a przy tym potrafi uwzględnić kilka rozdzielczości ekranu. Takie narzędzia włącza się do procesu budowania strony, żeby zestaw odświeżał się po każdej zmianie wyglądu. Dla WordPressa dokumentacja Lighthouse wspomina o wtyczkach, które wpisują zasoby krytyczne do dokumentu i odraczają mniej ważne.

Odroczone ładowanie pełnego arkusza

Samo przeniesienie znacznika link na koniec dokumentu nie rozwiązuje sprawy. Według web.dev przeglądarka nadal nadaje takiemu arkuszowi wysoki priorytet i może wstrzymać rysowanie. Opisany tam wzorzec wykorzystuje wstępne pobieranie: plik jest ściągany w tle, a dopiero po pobraniu zostaje zastosowany jako arkusz.

<style>
  /* style krytyczne dla górnej części ekranu */
</style>

<link rel="preload" href="styles.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

Zapis rel="preload" z atrybutem as="style" powoduje pobranie pliku bez blokowania. Atrybut onload po zakończeniu pobierania zamienia znacznik w zwykły arkusz, a znacznik noscript zapewnia style osobom, których przeglądarka nie wykonuje skryptów. Źródło zastrzega, że w środowisku produkcyjnym lepiej użyć gotowej funkcji ładującej, ponieważ polityka bezpieczeństwa treści ustawiona na serwerze może blokować skrypt wpisany w atrybut onload.

Podział arkuszy atrybutem media

Prostszym, a często pomijanym sposobem jest rozdzielenie stylów według zastosowania. Jeżeli znacznik link ma atrybut media, przeglądarka sprawdza warunek przy ładowaniu strony i wstrzymuje rysowanie tylko dla arkuszy, które do urządzenia pasują. Arkusz z zapisem media="print" obowiązuje wyłącznie przy drukowaniu, więc nie opóźnia pierwszego wyświetlenia na ekranie. Arkusz z warunkiem minimalnej szerokości blokuje tylko wtedy, gdy okno ten warunek spełnia.

<link href="style.css" rel="stylesheet">
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 40em)">

Trzeba przy tym znać jedno zastrzeżenie: przeglądarka pobiera wszystkie arkusze, także te, których warunek nie jest spełniony, tyle że z niższym priorytetem i bez wstrzymywania rysowania. Podział nie zmniejsza więc ilości przesyłanych danych, lecz skraca oczekiwanie na pierwszy obraz.

Zmniejszenie plików

Niezależnie od powyższych technik warto zadbać o minifikację, czyli usunięcie z arkusza spacji i innych niewidocznych znaków. Kurs web.dev wskazuje, że zmniejsza to rozmiar pliku i czas pobierania, ale ostrzega, że bardziej agresywne optymalizacje, takie jak łączenie powtarzających się reguł, bywają ryzykowne. Zysk utrwalają dobrze ustawione nagłówki Cache-Control, dzięki którym powracający odwiedzający nie pobiera arkusza ponownie.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Ryzyko automatycznego usuwania stylów

Automatyczne usuwanie stylów jest ryzykowne, ponieważ żadne narzędzie nie wie, co odwiedzający zrobi na stronie. Mechanizm ocenia reguły na podstawie tego, co zobaczył w kodzie podczas jednego załadowania, a wszystko, co pojawia się później, uznaje za zbędne. To konsekwencja ograniczeń opisanych przy panelu Pokrycie: szary kolor oznacza kod niewykorzystany w czasie pomiaru, a nie kod niepotrzebny.

Z naszej praktyki wynika, że najczęściej ofiarą padają elementy sterowane skryptami, czyli takie, którym klasa jest nadawana dopiero po czynności odwiedzającego: rozwijane menu na telefonie, okna dialogowe, karuzele, komunikaty walidacji formularza czy baner zgody. Druga grupa to style zależne od stanu, na przykład wygląd dla osoby zalogowanej albo pustego koszyka. Trzecia to treści dodawane przez redaktorów po wdrożeniu: tabela we wpisie, której w dniu pomiaru jeszcze nie było.

Dla zobrazowania: przyjmijmy hipotetyczny sklep z Poznania, w którym wtyczka optymalizująca usunęła style uznane za zbędne na karcie produktu. Strona ładuje się szybciej i w teście wygląda poprawnie, ale okno z tabelą rozmiarów, otwierane po kliknięciu, pojawia się bez tła i przycisku zamknięcia. Takiego błędu nie pokaże żaden raport szybkości.

Jak ograniczyć ryzyko

Bezpieczniej jest działać od ogółu do szczegółu. Najpierw warto usunąć całe arkusze, które na danym typie podstrony nie są potrzebne, bo to zmiana łatwa do sprawdzenia i odwrócenia. Dopiero potem można rozważyć odchudzanie pojedynczych plików regułą po regule. Kurs web.dev radzi podobnie: skupić się na dużych oszczędnościach i tam, gdzie to wykonalne, dzielić CSS według podstron. Dobrą praktyką jest też zapisanie wyglądu kluczowych podstron przed zmianą i porównanie go po zmianie na kilku szerokościach ekranu.

Ciężkie biblioteki i style ładowane na każdej podstronie

Największym źródłem zbędnego CSS są zwykle nie pojedyncze reguły, lecz całe pliki dołączane wszędzie, choć potrzebne są w jednym miejscu. Kurs web.dev zwraca uwagę, że łączenie wszystkich stylów w jeden plik sprawia, iż odwiedzający pobiera więcej CSS, niż wymaga bieżąca podstrona. W serwisach opartych na gotowych systemach dochodzi drugi mechanizm: każdy dodatek przynosi własny arkusz i domyślnie podłącza go do całej witryny.

Typowe przykłady łatwo rozpoznać w panelu Pokrycie po adresach plików. Arkusz formularza kontaktowego ładuje się na stronie głównej, choć formularz jest tylko na podstronie kontaktu. Biblioteka ikon z kilkuset znakami służy do wyświetlenia trzech. Rozbudowana biblioteka układu strony dostarcza komponenty, z których projekt nigdy nie skorzystał. W sklepie style koszyka i zamówienia trafiają na wpisy blogowe.

WordPress i wtyczki

Dla WordPressa dokumentacja Lighthouse formułuje zalecenie krótko: zmniejszyć liczbę wtyczek ładujących nieużywany CSS albo zastąpić je innymi. Przy opisie innego systemu to samo źródło dodaje zasadę, którą warto stosować wszędzie: motywy i moduły powinny dołączać arkusz tylko wtedy, gdy dana podstrona faktycznie z niego korzysta.

Jeżeli wtyczka jest potrzebna, a jej autor nie przewidział ładowania warunkowego, arkusz można odłączyć samodzielnie. Służy do tego funkcja opisana w dokumentacji WordPressa dla deweloperów, która usuwa z kolejki wcześniej dodany arkusz o podanym identyfikatorze. W uwagach do dokumentacji użytkownicy zaznaczają, że arkusz musi być już zarejestrowany, dlatego kod uruchamia się z późniejszym priorytetem niż domyślny.

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_page( 'kontakt' ) ) {
        wp_dequeue_style( 'identyfikator-arkusza-wtyczki' );
    }
}, 11 );

Taki kod powinien trafić do motywu potomnego albo własnej wtyczki i zostać sprawdzony na kopii testowej. Odłączenie arkusza na podstronie, na której element jednak występuje, na przykład formularz w stopce, zepsuje jego wygląd.

Biblioteki z zewnętrznych serwerów i czcionki

Osobną grupą są arkusze pobierane z innych domen, między innymi te, które deklarują czcionki. One również blokują rysowanie, a właściciel strony nie ma wpływu na ich zawartość. Liczbę odmian pisma i sposób ich ładowania omawiamy we wpisie o czcionkach internetowych. Najtaniej jest zdecydować o bibliotekach od początku, dlatego uwzględniamy ten temat już na etapie tworzenia stron.

Kolejność prac, typowe pomyłki i moment na pomoc specjalisty

Prace warto prowadzić od zmian najprostszych i najbezpieczniejszych do najtrudniejszych, a po każdej z nich powtarzać pomiar. Najpierw porządki w tym, co się ładuje, potem zmniejszenie plików i podział według zastosowania, a krytyczny CSS z odroczeniem reszty na końcu, i tylko wtedy, gdy pierwsze wyświetlenie nadal jest wolne.

• Pomiar wyjściowy kilku typów podstron w PageSpeed Insights i zapisanie wartości FCP.
• Nagranie w panelu Pokrycie, osobno w oknie o szerokości telefonu i komputera.
• Wyłączenie zbędnych wtyczek i bibliotek oraz odłączenie arkuszy tam, gdzie nie są potrzebne.
• Zastąpienie reguł @import znacznikami link i włączenie minifikacji.
• Wydzielenie stylów do druku i innych zastosowań do plików z atrybutem media.
• Na końcu: krytyczny CSS w nagłówku i odroczone ładowanie pełnego arkusza, najpierw na kopii testowej.
• Ręczne sprawdzenie menu, formularzy, okien i ścieżki zakupu po każdej zmianie.

Pomyłki, które widujemy najczęściej

Pierwsza to traktowanie odsetka z panelu Pokrycie jako celu. Zero nieużywanych bajtów na jednej podstronie nie jest ani realne, ani potrzebne, bo arkusz wspólny dla serwisu zawsze zawiera reguły dla innych podstron. Druga pomyłka to wpisanie do nagłówka zbyt dużego bloku stylów, czasem całego arkusza, co powiększa każdą odpowiedź HTML i niweczy zysk. Trzecia to jeden zestaw krytycznych stylów dla wszystkich szablonów: górna część strony głównej, wpisu i karty produktu wygląda inaczej, więc każdy szablon potrzebuje własnego zestawu.

Czwarta pomyłka dotyczy skutków ubocznych. Jeżeli style krytyczne nie obejmują wymiarów nagłówka czy siatki układu, elementy przeskakują w chwili dołączenia pełnego arkusza, co pogarsza stabilność opisaną we wpisie o wskaźniku CLS. Zdarza się też oczekiwanie, że odchudzenie arkuszy samo zmieni widoczność serwisu. Szybkość jest jednym z wielu czynników, o czym piszemy we wpisie o szybkości strony i pozycjach w Google.

Kiedy potrzebna jest pomoc

Porządki we wtyczkach i włączenie minifikacji właściciel strony często przeprowadzi samodzielnie. Pomoc specjalisty przydaje się wtedy, gdy serwis korzysta z kreatora stron generującego style dynamicznie, gdy sklep ma wiele szablonów i dodatków, gdy po włączeniu optymalizacji pojawiły się błędy wyglądu albo gdy mimo zmian FCP pozostaje słaby. Taką diagnozę obejmuje audyt SEO, a wdrożenie zaleceń jest częścią usługi SEO technicznego.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl