Zdecyduj, czy critical CSS to właściwy problem do rozwiązania
Zacznij od dowodów, a nie etykiety audytu. Zarejestruj ładowanie z zimnym cache dla priorytetowej strony na reprezentatywnych profilach mobilnych i desktopowych. Sprawdź waterfall i trace: czy arkusz stylów opóźnia pierwsze elementy wizualne i czy jest na tyle duży, że ma znaczenie? DevTools Coverage pokazuje CSS użyty w jednej sesji, nie na każdej trasie lub w każdym stanie.
Najpierw wypróbuj rozwiązania o niższej konserwacyjności: usuń nieużywane reguły, zminimalizuj i skompresuj output, ładuj CSS specyficzny dla trasy tylko tam, gdzie jest potrzebny, i unikaj łańcuchów @import w czystym CSS. web.dev nazywa ekstrakcję i odroczenie technikami zaawansowanymi.
Zmierzony opóźnienie pierwszego renderowania wiąże się z CSS, wizyta z zimnym cache ma znaczenie, a układ początkowy można zachować.
Jeśli wąskim gardłem są opóźnienia serwera, obrazy, fonty, JavaScript lub już niewielki arkusz styli, wstawianie CSS raczej nie pomoże.
Zdefiniuj widok początkowy jako macierz testową
Widok początkowy, czasem zwany above the fold, to to, co odwiedzający widzi przed przewinięciem. Nie ma uniwersalnej wysokości: urządzenia, powiększenie, język, ciasteczka i warianty treści ją zmieniają. Jedno desktopowe zrzut ekranu może pominąć telefon lub przetłumaczony nagłówek.
Użyj nazwanych profili. Uwzględnij układy wąskie i szerokie, kluczowe breakpointy, różne struktury logowania oraz każdy baner zgód, promocję, komunikat serwisowy lub błąd walidacji pojawiający się przy górze strony.
Zarejestruj szablon, viewport, lokalizację, uwierzytelnienie, zgodę i warianty top-of-page używane do generowania i testowania zestawu.
Przetestuj szybkie przewijanie, menu i fokus formularzy; reguła odroczona jest niebezpieczna, jeśli jej kontrolka może pojawić się zanim zaaplikowany zostanie pełny CSS.
Wyodrębnij niewielki zestaw z jednego źródła prawdy
Generuj critical CSS z produkcyjnego buildu. Ekstrakcja może zidentyfikować reguły użyte w widoku, ale sprawdź reguły warunkowe, dynamiczne i dotyczące przejść. Nie kopiuj ręcznie drugiego systemu projektowego do szablonów; będzie on dryfować w miarę rozwoju komponentów i znacznika.
Trzymaj output generowany i wersjonowany razem z wydaniem, podczas gdy źródłowy CSS pozostaje autorytatywny. Wstawiaj tylko reguły potrzebne do pierwszego użytecznego stanu. Duże bloki inline opóźniają HTML i nie mogą być ponownie użyte z zewnętrznego cache arkusza na późniejszych stronach. Porównaj nawigację z zimnym i ciepłym cache zanim nazwiesz zmianę poprawą.
Śledź skompresowane bajty inline, pozostałe bajty arkusza i zduplikowane reguły. Jedno mniej blokujące żądanie nie musi być netto zyskiem.
Oznacz build, gdy ekstrakcja jest pusta, przekracza limit rozmiaru inline lub zmienia się niespodziewanie względem przeglądanego bazowego wyniku.
Ładuj pozostały CSS bezpiecznie i szanuj ograniczenia polityki
Pozostały arkusz styli musi dotrzeć zanim niższa zawartość i późniejsze stany będą wyglądać kompletne. Udokumentowany wzorzec preładuje CSS jako style, a po załadowaniu zamienia go na arkusz, z fallbackiem bez JavaScriptu. preload żąda zasobu wcześniej; nie stosuje CSS. Niekompletny zestaw może powodować widoczne przestylowanie.
Sprawdź Content Security Policy przed użyciem inline-owego handlera ładowania. web.dev zauważa, że polityka może zabraniać inline-owego JavaScriptu w onload, więc użyj kompatybilnego loadera lub innego podejścia. Testuj też z wyłączonym JavaScriptem. Pliki kwalifikowane media queries pomagają przy prawdziwie warunkowych stylach, np. do druku; niepasujące zapytanie nie blokuje renderowania, choć może nadal pobierać zasób.
Zweryfikuj, że odwiedzający bez JavaScriptu otrzymuje pełny CSS i może ukończyć priorytetową ścieżkę.
Zbadaj oddzielnie późny font lub obraz widoczny w pierwszym widoku; critical CSS nie naprawi zachowania ich fetchowania.
Testuj regresje wizualne, funkcjonalne i cache'owe
Użyj porównania wizualnego dla każdego nazwanego viewportu i stanu top-of-page. Sprawdź nieostylowany tekst, nakładanie się, ukrytą nawigację, brak wskaźników fokusu, shift layoutu i skok przy zastosowaniu odroczonego CSS. Przetestuj nawigację klawiaturą, ścieżki dotykowe, błędy i szybkie przewijanie. Jeśli odroczona reguła powoduje, że kontrolka jest nieużywalna, należy ją umieścić w ścieżce krytycznej lub zmienić projekt.
Testuj wizyty zimne i ciepłe. Testy z zimnym cache pokazują, czy usunięcie oczekiwania na CSS poprawia renderowanie; testy z ciepłym cache pokazują koszt powtarzanego HTML-a z inline. Przetestuj poprzednie cachowane HTML i powrót po wdrożeniu. Zachowaj kompatybilne zasoby, podczas gdy cachowane dokumenty mogą ich oczekiwać, i nie nadpisuj fingerprintowanych URL-i arkuszy styli.
Porównaj pierwsze elementy treści i główną widoczną zawartość, a następnie użyj trace, by wyjaśnić zysk lub regresję.
Uwzględnij fokus, kontrast, preferencje ruchu, powiększenie i czytelną kolejność. Szybsze renderowanie nie jest zaliczeniem, jeśli interfejs jest niedostępny.
Operuj tym jako odwracalną funkcją dostarczania
Nadaj pipeline właściciela i zdokumentuj jego wejścia, artefakt, szablony, profile testowe i limit rozmiaru inline. Uruchamiaj testy przy każdej zmianie CSS, znacznika, biblioteki komponentów, flagi funkcji lub zewnętrznego elementu pojawiającego się above the fold. Coverage kieruje przeglądem, ale jedno nagranie nie może udowodnić, że reguła jest bezpieczna wszędzie.
Wdrażaj za odwracalną konfiguracją tam, gdzie to praktyczne. Zarejestruj znaną-dobrą ścieżkę arkusza styli, wersję artefaktu, identyfikator builda i metodę odzyskiwania. Jeśli pojawi się regresja, najpierw przywróć kompatybilne dostarczanie, potem diagnozuj pominięty stan. SIU używa tego workflow, by ustabilizować krytyczne ścieżki zanim wpływ na klientów się rozprzestrzeni.
Nowy baner, flow zgód, lokalizacja, breakpoint lub układ konta wymaga regeneracji i testów.
Cofnij szablon i konfigurację dostarczania do kompatybilnej generacji; nie edytuj niezmiennych URL-i zasobów, które mogą referencjonować starsze dokumenty.