Konfiguracja krytycznego CSS

Co moduł robi — a czego nie robi

Dla każdego szablonu strony Kakapo pobiera przez HTTP prawdziwą stronę przykładową twojej witryny (tylko w obszarze administracyjnym albo przez cron, nigdy podczas budowania strony dla gościa), czyta podlinkowane tam lokalne arkusze stylów bezpośrednio z dysku twardego i sprawdza każdą pojedynczą regułę za pomocą DOMXPath wobec dokumentu. Powstają z tego dwa wyniki: krytyczny CSS, który umieszczany jest inline w nagłówku, oraz lista reguł, które w tym szablonie nie trafiły w ani jeden element.

Nic przy tym nie jest renderowane. Nie ma przeglądarki, nie ma widoku ani pozycji przewijania. „Widoczne u góry” to przybliżenie według jawnie opisanej reguły: wszystkie elementy poniżej body zostają ponumerowane, pierwsze 30 procent (ustawienie domyślne, do wyboru między 5 a 90) uchodzi za obszar u góry, a do tego wszystko wewnątrz wpisanych punktów orientacyjnych. Zawsze uwzględniane są html, body, :root i @font-face oraz @keyframes, które krytyczna reguła wskazuje przez animation. Reguły działające tylko przez stany (:hover, :focus, :active) pozostają na zewnątrz, tak samo @media print. Tam, gdzie metoda dochodzi do swojej granicy, zaokrągla w górę: reguła uchodzi za trafioną. Kilka kilobajtów za dużo kosztuje mniej niż brakująca reguła i migotanie.

Sprawdzenie warunków przed analizą

Dwie rzeczy muszą się zgadzać. Po pierwsze rozszerzenie PHP dom/libxml — moduł nie sprawdza go przez class_exists(), lecz buduje miniaturowy dokument i naprawdę go odpytuje. Powód: niektórzy hostingodawcy ustawiają disable_classes=DOMDocument, wtedy class_exists() nadal zgłasza „tak”, ale new kończy się błędem. Jeżeli rozszerzenia brakuje, „Analizuj” i „Odświeżaj codziennie” są zablokowane, a powód widnieje obok.

Po drugie loopback: witryna musi osiągnąć samą siebie przez HTTP. Służy do tego przycisk „Sprawdź loopback” w obszarze Warunki; zapamiętuje on kod HTTP, rozmiar odpowiedzi i czas. Jeżeli się nie powiedzie, każdy przebieg analizy kończy się niepowodzeniem — typowe przyczyny to zapora przed witryną, ochrona Basic Auth na środowisku staging albo nazwa hosta, która wewnętrznie się nie rozwiązuje.

Czego analiza nie może przeczytać, tego też nie opóźnia: arkusze stylów z obcych hostów, z CDN lub z Google Fonts nadal blokują renderowanie. To droga wolna, ale bezpieczna.

Postępowanie szablon po szablonie

Szablonów jest siedem: Strona startowa, Strona bloga, Pojedynczy wpis, Strona statyczna, Archiwum, Wyniki wyszukiwania i Strona błędu 404. Każdy analizowany jest osobno i osobno zatwierdzany. Jeżeli strona startowa pokazuje listę wpisów, „Strona bloga” nie ma zastosowania — przełącznik pozostaje zablokowany, ponieważ nie miałby żadnego skutku. Jeżeli nie ma opublikowanego wpisu ani żadnej strony, brakuje strony przykładowej i szablon również pozostaje zablokowany.

Zalecana droga: najpierw „Analizuj wszystkie” albo analiza pojedyncza. Następnie otwiera się dla szablonu „Podgląd” i „bez” w dwóch kartach — to ta sama prawdziwa strona raz z obsługą, raz bez niej, widoczna tylko dla zalogowanych administratorów i tylko z ważnym kluczem jednorazowym w adresie. Główny przełącznik nie musi być do tego włączony. Migotanie przy budowaniu strony najpewniej widać we własnej karcie z ograniczonym łączem, a nie w osadzonej ramce.

Dopiero gdy porównanie wygląda czysto, zatwierdza się szablon i włącza główny przełącznik. Zaczyna on w trybie testowym: obsługę widzą tam tylko zalogowani administratorzy, dla wszystkich pozostałych strona pozostaje niezmieniona. Na „ostry” przestawia się dopiero po przejrzeniu kilku szablonów.

Cztery hamulce i listy wyjątków

„Opóźnione ładowanie przeanalizowanych arkuszy stylów” to właściwa oszczędność czasu. Wyłączone oznacza: krytyczny CSS dochodzi dodatkowo inline, poza tym wszystko zostaje jak było — bez ryzyka, ale i bez zysku. Włączone oznacza: przeanalizowane arkusze stylów ładują się przez media="print" plus przestawienie w onload, z duplikatem noscript dla gości bez JavaScript. Opóźniane jest wyłącznie to, co naprawdę zostało przeczytane, i tylko wtedy, gdy uchwyt i adres pliku nadal pasują do tego, co przeanalizowano.

„Wstrzymaj przy zmienionych plikach źródłowych” zapamiętuje dla każdego przeanalizowanego pliku czas modyfikacji i rozmiar oraz aktywny motyw. Jeżeli coś się zmieni, strona nie jest obsługiwana w ogóle, zamiast być obsłużona z możliwie błędnym krytycznym CSS — w kodzie źródłowym znajduje się wtedy notatka z powodem.

Trzy pola tekstowe to wyjście awaryjne. Adresy URL do wykluczenia: jeden wiersz na ścieżkę, „*” jako symbol zastępczy, te strony nigdy nie są obsługiwane (typowo /checkout*, /mein-konto*). Nigdy nie opóźniaj arkuszy stylów: jeden uchwyt WordPressa w wierszu, domyślnie admin-bar i dashicons. Punkty orientacyjne: jeden selektor w wierszu, wszystko w środku uchodzi za obszar u góry — domyślnie są to header, [role="banner"], .site-header, #masthead, nav, .main-navigation, .site-branding, .hero i h1. Wiersze, których nie da się przetworzyć, są odrzucane, a nie po cichu zapisywane.

Zmiana udziału „u góry” albo punktów orientacyjnych działa dopiero po nowym przebiegu analizy. Wszystko inne natychmiast unieważnia cache stron, ponieważ leży tam gotowy HTML ze starym stanem.

Gdy coś pójdzie nie tak

„Budżet czasu wyczerpany”: przebieg osiągnął 25 sekund albo limit czasu PHP. Raport jest zapisany, krytyczny CSS świadomie nie — niekompletny krytyczny CSS powodowałby migotanie. Komunikat podaje plik, na którym nastąpił koniec. Przeanalizuj ponownie albo wyjmij bardzo duży arkusz stylów przez listę wyjątków.

„Odpowiedziała kodem HTTP …”: strona przykładowa nie zwróciła oczekiwanego kodu (200, przy stronie błędu 404). Nic nie jest zapisywane. Sprawdź, czy strona jest osiągalna w przeglądarce i czy nie stoi przed nią jakaś ochrona.

Szablon ma status „nieaktualny”: przeanalizowany plik CSS się zmienił albo motyw został zmieniony. Przeanalizuj ponownie. Jeżeli widnieje tam „inny udział”, szablon został utworzony z inną wartością procentową niż ustawiona obecnie — również przeanalizuj ponownie.

Żeby nie pozostawało to pracą ręczną, jest opcja „Codziennie sprawdzaj i odświeżaj”. Przebieg crona analizuje tylko szablony, które są już zatwierdzone i nieaktualne; nigdy niczego nie włącza i nie zakłada analizy dla niezatwierdzonego szablonu. Jego ostatni wynik widnieje jako notatka w obszarze Pas bezpieczeństwa.

Jeżeli strona mimo to pozostaje niespokojna, pomaga zajrzenie do kodu źródłowego: znajduje się tam komentarz z obsłużonym szablonem i stanem (podgląd, tryb testowy, ostry) albo powód, dla którego świadomie nie została obsłużona.