Języki

Krytyczny CSS

Krytyczny CSS — wyodrębnianie stylów widocznych nad linią zagięcia, umieszczanie ich bezpośrednio w kodzie HTML i odraczanie reszty w celu przyspieszenia pierwszego malowania. Dlaczego Google nazywa to techniką zaawansowaną i opcjonalną, realne kompromisy (utrata pamięci podręcznej, ryzyko konserwacji, wyścigi), oraz jak sprawdzić, czy CSS jest w ogóle Twoim wąskim gardłem.

Opublikowano po raz pierwszy: 3 lip 2026 · Ostatnia aktualizacja: 11 sie 2026 · Advanced
Języki
AIAutor:AI v2

Krytyczny CSS to technika wydajnościowa: wyodrębnij CSS potrzebny do wyrenderowania wybranego widoku nad linią zagięcia, umieść go bezpośrednio w sekcji <head> i odrocz resztę arkusza stylów asynchronicznie. Działa, ponieważ CSS domyślnie blokuje renderowanie — przeglądarka nie maluje, dopóki nie zostanie zbudowany CSSOM. Nie ma uniwersalnej wysokości nad linią zagięcia (urządzenie, orientacja, powiększenie i stan strony ją zmieniają), więc traktuj podział jako decyzję, a nie stały punkt odcięcia w pikselach. Najważniejsza rzecz do zapamiętania: Google przedstawia krytyczny CSS jako zaawansowaną, opcjonalną technikę, a nie domyślne zalecenie — jego własna dokumentacja mówi: „Większość witryn powinna być w stanie osiągnąć wszystkie nasze zalecane cele wydajnościowe bez wdrażania tej techniki”. Kompromisy są realne: wbudowany CSS nie jest buforowany dla powtarzających się wizyt (drugie widoki mogą być wolniejsze), podział na krytyczny/niekrytyczny cicho psuje się, gdy zmieniają się szablony lub stany, polityka CSP style-src może całkowicie zablokować wbudowany blok, a odroczenie preload/onload może powodować wyścigi lub przesunięcie układu. Najpierw zdiagnozuj — potwierdź, że CSS (a nie JavaScript lub czas odpowiedzi serwera) jest faktycznie Twoim wąskim gardłem renderowania, zanim się nim zajmiesz. Wpływ na SEO jest pośredni, poprzez Core Web Vitals/LCP, a nie bezpośredni sygnał rankingowy. Nie ma wytycznych specyficznych dla Bing. Ta strona jest zagnieżdżona w centrum ścieżki krytycznego renderowania.

TL;DR — Krytyczny CSS = wyodrębnij style powyżej linii zagięcia, umieść je bezpośrednio w <head>, a resztę arkusza stylów wczytuj asynchronicznie (rel="preload" + zamiana onload, fallback <noscript> lub loadCSS). Działa to, ponieważ CSS domyślnie blokuje renderowanie. Kluczowa kwestia: Google przedstawia to jako zaawansowaną i opcjonalną technikę, a nie domyślne zalecenie — “Most sites should be able to achieve all of our recommended performance targets without implementing this technique.” (tłumaczenie) „Większość witryn powinna być w stanie osiągnąć wszystkie nasze zalecane cele wydajnościowe bez wdrażania tej techniki.” Zachowaj mały rozmiar wbudowanego kodu. Kompromisy są realne: wbudowany CSS nie jest buforowany między kolejnymi wczytaniami strony (powtórne wizyty mogą być wolniejsze), podział na krytyczne/niekrytyczne style psuje się przy zmianach szablonów, a opóźnienie może powodować wyścigi lub FOUC/CLS. Najpierw zdiagnozuj — potwierdź, że to CSS (a nie JavaScript czy czas serwera) jest faktycznym wąskim gardłem. Uważaj na pułapki, których nie pokaże szybkie demo: polityka CSP style-src może całkowicie zablokować Twój wbudowany blok <style>, „nieużywany w momencie przechwycenia” nie oznacza „bezpieczny do odroczenia” w różnych motywach/personalizacji/stanach, a wbudowanie nie rozwiązuje problemu czasu ładowania czcionek. Wpływ na SEO jest pośredni poprzez Core Web Vitals/LCP. Nie istnieją wytyczne specyficzne dla Bing.

Czym właściwie jest krytyczny CSS

Problem, który rozwiązuje, to CSS blokujący renderowanie. Google web.dev jest jednoznaczne: Domyślnie CSS jest traktowany jako zasób blokujący renderowanie, co oznacza, że przeglądarka nie wyrenderuje żadnej przetworzonej treści, dopóki CSSOM nie zostanie zbudowany. To jest cały powód istnienia tej techniki — przeglądarka odmawia malowania, dopóki nie ma Twoich stylów, więc wszystko, co opóźnia CSS, opóźnia pierwsze malowanie. (Pełny potok, który leży u podstaw, znajdziesz w hubie ścieżka krytycznego renderowania, pod którym znajduje się ta strona, oraz w jego towarzyszącym artykule, zasoby blokujące renderowanie.)

Krytyczny CSS rozwiązuje to, dzieląc Twój CSS na dwie części. Definicja web.dev: “Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible.” (tłumaczenie) „Krytyczny CSS to technika, która wyodrębnia CSS dla treści powyżej linii zagięcia, aby jak najszybciej wyrenderować treść użytkownikowi.” Oraz mechanika: Wbudowanie wyodrębnionych stylów w <head> dokumentu HTML eliminuje potrzebę dodatkowego żądania w celu pobrania tych stylów. Pozostała część CSS może być ładowana asynchronicznie.

Evidence for this claim Critical CSS extracts and inlines above-the-fold styles so the remaining CSS can load asynchronously. Scope: web.dev definition and implementation outline for critical CSS. Confidence: high · Verified: web.dev: Extract critical CSS

Jedna rzecz, o której web.dev mówi wprost, a wiele pobocznych przewodników pomija: nie ma jednej, uniwersalnej wysokości linii zagięcia — rozmiar urządzenia, orientacja, elementy przeglądarki, poziom zoomu i stan strony (otwarte menu, załadowana personalizacja, stan błędu) — wszystko to zmienia to, co faktycznie musi znaleźć się w zbiorze „krytycznym”. Traktuj krytyczny CSS jako decyzję o wybranym początkowym viewportcie/stanie, a nie stałym odcięciu w pikselach, i waliduj względem swoich rzeczywistych punktów przerwania i stanów — a nie jednego zrzutu ekranu z desktopu.

Więc to dwa zadania, w kolejności:

  1. Wbuduj minimalny CSS powyżej linii zagięcia w <head> — bez dodatkowej podróży w obie strony przed pierwszym malowaniem.
  2. Odrocz resztę arkusza stylów — wczytaj go asynchronicznie, aby nigdy nie blokował tego pierwszego malowania.

Dokładnie tak podzieliłem to w moich prelekcjach o doświadczeniu strony. W mojej Co dalej z page experience — prezentacji z SMX Next 2021 podzieliłem pracę nad CSS na dwa koszyki: ścieżkę wczesną/krytyczną (usuń nieużywany CSS → zminifikuj CSS → wbuduj krytyczny CSS) i ścieżkę późną/odroczoną (odrocz niekrytyczny CSS). Ten sam kształt co w web.dev, tylko uporządkowany tak, jak o tym myślę.

Jak to wdrożyć

Krok 1 — wbuduj krytyczny CSS. Zalecenie samego Lighthouse brzmi: “inline critical styles required for the first paint inside a <style> block at the head of the HTML page” (tłumaczenie) „umieść style krytyczne wymagane do pierwszego malowania w bloku <style> w sekcji <head> strony HTML” (źródło). Docelowy rozmiar Google dla tego wbudowanego zasobu, z tej samej strony: aim to keep above-the-fold content under 14 KB (compressed), aby zmieścił się w pierwszym cyklu sieciowym. Traktuj tę liczbę jako historyczną wskazówkę transportową, a nie ponadczasową specyfikację — strona źródłowa pochodzi z 2019 roku i poprzedza dzisiejsze szerokie wdrożenie HTTP/2 i HTTP/3, które zmieniają matematykę pierwszego cyklu. To wciąż liczba, którą cytują dokumenty Google, ale jeśli dostrajasz się precyzyjnie, zweryfikuj ją względem swojego obecnego protokołu i zachowania serwera zamiast traktować 14 KB jako dogmat.

Krok 2 — odrocz resztę. Wzorzec zalecany przez web.dev dla deferring non-critical CSS to preload z zamianą onload plus fallback <noscript>:

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

Serwis web.dev zaleca w środowisku produkcyjnym: “use CSS-deferring functions, such as loadCSS, that encapsulate this behavior and work well across browsers” (tłumaczenie) „używaj funkcji odraczających CSS, takich jak loadCSS, które zamykają ten mechanizm i działają poprawnie w różnych przeglądarkach” (źródło), zamiast ręcznego implementowania zamiany. Przy odraczaniu za pomocą JavaScriptu serwis ostrzega również: “waiting for JavaScript to execute before loading non-critical CSS can cause delays in rendering when users scroll” (tłumaczenie) „oczekiwanie na wykonanie JavaScriptu przed załadowaniem niekrytycznego CSS może opóźniać renderowanie podczas przewijania” (źródło) — dlatego preload jest używany, aby przyspieszyć pobieranie.

Narzędzia. Rzadko wyodrębniasz krytyczny CSS ręcznie. Referencyjna implementacja Google to critical npm package (Addy Osmani) — “a tool that extracts, minifies and inlines above-the-fold CSS.” (tłumaczenie) „narzędzie, które wyodrębnia, minimalizuje i osadza CSS dla treści powyżej linii zagięcia”. Alternatywy obejmują Penthouse i CriticalCSS, plus mnóstwo generatorów SaaS/wtyczek dla WordPressa i Shopify. Aby samodzielnie znaleźć krytyczne reguły, Google kieruje cię do zakładki Coverage w Chrome DevTools, aby zidentyfikować niekrytyczny CSS i JavaScript.

Jeśli używasz wtyczki lub generatora (WP Rocket, Autoptimize i podobnych), nie przyjmuj UI walkthrough od dostawcy ani zrzutu ekranu z wynikiem przed/po jako gwarancji platformy — te strony mieszają wersje produktów i wyniki dla konkretnych witryn, a różnice w wynikach nie są niezależnie odtworzone. Zanim zaufasz jednej w produkcji: potwierdź zachowanie względem bieżącej dokumentacji i numeru wersji wtyczki i poddaj ją tej samej macierzy testów, której użyłbyś dla ręcznej implementacji — zimne i powtarzane ładowania, twoje rzeczywiste breakpointy/motywy/stany oraz twoja polityka CSP, jeśli ją stosujesz.

Zauważ, że krytyczny CSS to tylko jedno z rozwiązań na render-blocking CSS. Inne to ograniczanie arkuszy stylów atrybutem media (aby się pobierały, ale nie blokowały renderowania) i po prostu dostarczanie mniejszej ilości CSS na starcie — artykuł web.dev o render-blocking faktycznie opiera się na podejściu z atrybutem media, a nie na wbudowywaniu, więc Google ma więcej niż jedną oficjalną receptę, w zależności od tego, który dokument czytasz.

Rzeczywiste stanowisko Google (kręgosłup dokładności)

To jest część, którą prawie każdy konkurencyjny artykuł chowa, i to jest cały powód, dla którego chciałem napisać ten. Google nie przedstawia krytycznego CSS jako domyślnej porady. Jego codelab jest bezpośredni co do ryzyka: “This codelab describes an advanced performance technique that can improve performance, but can also lead to bugs if not implemented properly” (tłumaczenie) „Ten codelab opisuje zaawansowaną technikę wydajnościową, która może poprawić wydajność, ale przy nieprawidłowym wdrożeniu może też powodować błędy” (źródło). I dwukrotnie w swoich dokumentach Google mówi, że większość witryn nie powinna się tym przejmować: “Most sites should be able to achieve all of our recommended performance targets without implementing this technique” (tłumaczenie) „Większość witryn powinna być w stanie osiągnąć wszystkie zalecane przez nas cele wydajnościowe bez wdrażania tej techniki” (źródło).

Evidence for this claim web.dev presents critical CSS as an advanced technique that can cause bugs and says most sites can meet performance targets without it. Scope: web.dev codelab guidance; not a universal recommendation. Confidence: high · Verified: web.dev: Extract and inline critical CSS

Nawet pozytywna strona niesie ze sobą ostrzeżenie. web.dev zaznacza, że inlining ma też pewne wady, ponieważ uniemożliwia przeglądarce buforowanie CSS do ponownego wykorzystania przy kolejnych ładowaniach stron, więc najlepiej używać go oszczędnie — a przy przesadzie jeśli wszystko jest priorytetem, to nic nim nie jest. Przesadzisz z inliningiem i rozdęjesz HTML, który starasz się dostarczyć szybko.

Uczciwe ujęcie jest więc takie: krytyczny CSS to realna, udokumentowana, czasem potężna technika — ale zaawansowana, opcjonalna i stosowana w ostateczności, której według Google większość witryn nie potrzebuje, aby osiągnąć swoje cele. Traktuj ją w ten sposób.

Prawdziwe kompromisy

Niezależni inżynierowie wydajności byli tu najgłośniejszymi głosami i zgadzają się z zastrzeżeniami samego Google.

Utrata buforowania przy powtórnych wizytach. Matt Zeunert z DebugBear mówi to wprost: krytycznego CSS nie można ponownie wykorzystać między różnymi ładowaniami stron w Twojej witrynie. Dlatego kolejne odsłony stron mogą być faktycznie wolniejsze, niż byłyby bez krytycznego CSS. Zwykły zewnętrzny arkusz stylów jest buforowany raz i wykorzystywany wszędzie; wbudowany CSS jest pobierany ponownie w każdej odpowiedzi HTML.

Ryzyko utrzymania i regresji. Kontrowersyjny artykuł Harry’ego Robertsa jest najczęściej cytowanym ujęciem, a jego ostrzeżenie brzmi: “retrofitting Critical CSS is difficult and error prone” (tłumaczenie) „dodawanie krytycznego CSS do istniejącej witryny jest trudne i podatne na błędy” (źródło): gdy już zidentyfikujesz CSS jako swój wąski gardło, “you need to keep it that way… One wrong decision can undo everything.” (tłumaczenie) „musisz go takim utrzymać… Jedna błędna decyzja może zniweczyć wszystko.” Nie ma automatycznej ponownej walidacji — zmiana szablonu lub projektu może po cichu zepsuć Twój podział na CSS krytyczny i niekrytyczny.

Warunki wyścigu przy odroczeniu. Roberts zwraca też uwagę, że zamiana preload/onload może się zemścić na czasie: “if it takes 1s to parse your <head> and 0,5s to asynchronously fetch your non-Critical CSS, then the CSS will be turned back into a synchronous file 0,5s before you were ready to go anyway” (tłumaczenie) „jeśli parsowanie <head> trwa 1 s, a asynchroniczne pobranie niekrytycznego CSS zajmuje 0,5 s, to CSS ponownie stanie się plikiem synchronicznym 0,5 s przed chwilą, w której strona i tak byłaby gotowa” (źródło). A gdy niekrytyczny CSS pojawi się późno, ryzykujesz błyskiem nieostylowanej treści i przesunięciem układu.

Często to w ogóle nie jest wąskie gardło. Główna teza Robertsa brzmi: “Critical CSS only helps if CSS is your biggest render-blocking bottleneck, and quite often, it isn’t” (tłumaczenie) „Krytyczny CSS pomaga tylko wtedy, gdy CSS jest największym wąskim gardłem blokującym renderowanie, a bardzo często nim nie jest” (źródło). DebugBear się zgadza — przed inliningiem sprawdź, czy CSS faktycznie jest problemem, ponieważ “if you still have render-blocking JavaScript code, inlining CSS is unlikely to help” (tłumaczenie) „jeśli nadal masz JavaScript blokujący renderowanie, osadzenie CSS raczej nie pomoże” (źródło), a “often it’s not the most impactful optimization.” (tłumaczenie) „często to nie jest najbardziej wpływowa optymalizacja.”

Miny w produkcji: CSP, stan i czcionki

Trzy kolejne tryby awarii, które nie ujawniają się w szybkim demo, ale gryzą, gdy to już działa na żywo:

Polityka CSP może całkowicie zablokować Twój wbudowany blok <style>. Polityka Content-Security-Policy style-src może zablokować wbudowany krytyczny blok <style>, chyba że polityka wyraźnie na to zezwala — zwykle przez nonce lub pasujący hash. MDN dokumentuje przypadki naruszeń oraz mechanizmy nonce/hash. Sięganie po unsafe-inline, aby pozbyć się błędu z konsoli, osłabia politykę w całej witrynie i nie jest domyślną poprawką — podłącz generowanie nonce/hash do narzędzia, którą wyodrębnia krytyczny CSS, i po wdrożeniu sprawdzaj konsolę przeglądarki pod kątem naruszeń.

„Nie użyte podczas przechwytywania” to nie to samo co „bezpieczne do odroczenia”. Karta Coverage mówi Ci, jaki CSS wykonał się podczas jednego zarejestrowanego uruchomienia. Bezpieczny podział musi zachować kolejność kaskady i reguły potrzebne dla Twoich punktów przerwania responsywności, wariantów motywów, spersonalizowanych treści, stanów fokusu, otwartych menu/modalów oraz stanów błędów — a nie tylko to, co akurat wyrenderowało się w tym jednym przejściu. Roberts podnosi to samo pytanie z innej perspektywy: który widok, i które elementy poza ekranem lub nieinteraktywne (rozwijane menu, wysuwane panele), Twoja ekstrakcja faktycznie musi objąć?

To nie rozwiązuje problemu z czcionkami i może zwiększyć pracę renderowania. Osadzanie stylów elementów samo w sobie nie sprawia, że czcionka internetowa jest wykrywana wcześniej ani nie gwarantuje, że tekst renderuje się na czas — wykrywanie czcionek, preload, font-display i metryki rezerwowe to osobne zależności, których krytyczny CSS nie dotyka. A zastosowanie osadzonego podzbioru, po którym następuje większy arkusz stylów, może oznaczać dodatkowe przeliczanie stylów, układ i malowanie; skrócenie opóźnienia pobierania nie oznacza automatycznie mniejszej całkowitej pracy renderowania. Zmierz oba, nie tylko wodospad sieciowy.

Jak zdiagnozować, czy w ogóle tego potrzebujesz

Mając to na uwadze, nie zaczynaj od „dodaj krytyczny CSS” — zacznij od „potwierdź, że CSS jest moim wąskim gardłem renderowania” i nie poprzestawaj na tym. Cztery bramki, a wszystkie muszą być spełnione, zanim warto to zrobić:

1. CSS jest udowodnionym blokerem, a nie przypuszczeniem.

  • Otwórz raport PageSpeed Insights / Lighthouse. Od Lighthouse 13 stary audyt „Eliminate render-blocking resources” przeniósł się do insightu Render-blocking requests — więc starsze artykuły odwołujące się do starej nazwy audytu są nieaktualne.
  • Użyj zakładki Coverage w Chrome DevTools aby zobaczyć, ile z Twojego CSS (i JS) jest faktycznie nieużywane przy pierwszym malowaniu.
  • Rozdziel przyczyny. Jeśli Twoim wąskim gardłem jest blokujący renderowanie JavaScript lub wolna odpowiedź serwera (TTFB), osadzanie CSS tego nie naprawi — optymalizowałbyś niewłaściwą rzecz.

2. Możesz zbudować pokrycie ekstrakcji, które jest naprawdę stabilne — w różnych rzeczywistych punktach przerwania, motywach, personalizacji i stanach interaktywnych, a nie na jednym zrzucie ekranu z komputera stacjonarnego (patrz miny lądowe powyżej).

3. Koszt powtórnego wyświetlenia i CSP jest akceptowalny. Osadzony CSS nie jest buforowany, więc zważ to na to, jak głęboka jest typowa sesja. Jeśli używasz polityki CSP style-src, generowanie nonce/hash musi być podłączone do potoku zanim to trafi na produkcję, a nie odkryte później.

4. Będziesz to faktycznie utrzymywać. Generuj ponownie przy każdej zmianie szablonu lub projektu i uruchamiaj pełną macierz testów — zimne i powtórne ładowania, każda obsługiwana trasa/rzutnia/stan — a nie pojedyncze sprawdzenie wzrokowe po wdrożeniu.

Jeśli wszystkie cztery bramki są spełnione, krytyczny CSS jest wart kosztów utrzymania. Jeśli którakolwiek nie jest, tańsze poprawki — usunięcie nieużywanego CSS, minifikacja, ograniczenie niekrytycznych arkuszy stylów za pomocą media — są lepszym rozwiązaniem.

Aktualny problem na rok 2026

Jedna żywa niespodzianka, którą warto zaznaczyć: istnieje otwarty, nierozwiązany raport, że dokładny wzorzec <link rel="preload" as="style">, który Google zaleca do odraczania CSS, zaczął być ponownie oznaczany jako blokujący renderowanie po aktualizacji punktowej Lighthouse/PSI. GitHub issue #17031 dokumentuje wstępnie załadowany CSS pokazujący się na zielono w Lighthouse 13.0.1, a następnie oznaczony jako blokujący renderowanie w 13.3.0. W chwili pisania tego tekstu nie ma publicznego rozwiązania Google, więc traktuj to jako rozwijające się — ale praktyczna lekcja pozostaje: jeśli PSI flaguje Twój poprawnie odroczony CSS, sam audyt może być błędny, więc czytaj raport krytycznie, zamiast zakładać, że Twoja implementacja jest zepsuta.

Czy krytyczny CSS pomaga w SEO?

Pośrednio i umiarkowanie. Trzeba rozdzielić dwie rzeczy:

  • CSS nie jest bezpośrednim sygnałem rankingowym. Martin Splitt z Google powiedział o nazwach klas CSS: “I don’t think we care because the CSS class names are just that.” (tłumaczenie) „Nie sądzę, żeby nas to obchodziło, ponieważ nazwy klas CSS są po prostu tym.” To dotyczy konkretnie nazw klas, ale obala szerszy mit, że Twoje wybory CSS są odczytywane jako sygnał rankingowy.
  • Szybkość jest (małym) sygnałem, poprzez Core Web Vitals. Krytyczny CSS może poprawić pierwsze malowanie, co może poprawić LCP, który jest metryką Core Web Vitals zasilającą sygnały page-experience Google. To cały związek z SEO — szybsze malowanie, a nie bonus za samą technikę.

Tak więc argument SEO za krytycznym CSS jest dokładnie tak silny, jak jego wpływ na LCP na Twojej stronie — który, według Google i społeczności zajmującej się wydajnością, jest często mniejszy, niż sugerowałyby narzędzia sprzedawców go promujących.

A co z Bing?

Nic specyficznego dla Bing. W przeciwieństwie do Google — które ma wiele stron web.dev i codelab na ten temat — nie mogłem znaleźć żadnego dedykowanego dokumentu Bing/Microsoft dotyczącego krytycznego CSS. Ogólne wytyczne Bing dotyczące doświadczenia strony mają zastosowanie (utrzymuj szybkość, utrzymuj krytyczne treści dostępne), ale nie ma odpowiednika codelabu web.dev dotyczącego krytycznego CSS w Bing. Każdy, kto twierdzi, że Bing ma konkretne zalecenie dotyczące krytycznego CSS, wymyśla je.

Gdzie to się znajduje

Ta strona znajduje się w sekcji ścieżka renderowania krytycznego — krytyczny CSS to jedna z taktyk skracania tej ścieżki — i jest praktycznym odpowiednikiem zasobów blokujących renderowanie. Korzyść, jeśli występuje, pojawia się w Largest Contentful Paint (LCP), First Contentful Paint (FCP), oraz w szerszym zestawie Core Web Vitals. Aby uzyskać szerszy obraz wydajności, zobacz klaster wydajności sieci.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.