Core Web Vitals i PageSpeed Insights – pełny poradnik

Wprowadzenie – Core Web Vitals i ich znaczenie dla SEO

Szybkość ładowania strony ma wpływ na wyniki biznesowe. Badania pokazują, że jedna sekunda opóźnienia przekłada się na 7% niższe konwersje. Według Google i Deloitte poprawa szybkości o 0,1 sekundy na urządzeniach mobilnych może zwiększyć współczynnik konwersji o 8,4%. Strona, która reaguje wolno lub jest niestabilna wizualnie, traci odwiedzających.

Core Web Vitals to zestaw trzech metryk wydajnościowych ogłoszonych przez Google w maju 2020 roku. Od czerwca 2021 roku stały się oficjalnym czynnikiem rankingowym. Mierzą rzeczywiste wrażenia użytkowników podczas przeglądania stron i obejmują trzy obszary:

• LCP (Largest Contentful Paint) – czas ładowania największego widocznego elementu strony
• INP (Interaction to Next Paint) – responsywność strony na interakcje użytkownika
• CLS (Cumulative Layout Shift) – stabilność wizualna układu strony

Google ocenia każdą z metryk na podstawie 75. percentyla w 28-dniowym oknie danych pochodzących od prawdziwych użytkowników korzystających z przeglądarki Chrome. Oznacza to, że 75% wizyt na stronie musi spełniać dany próg, by całą stronę uznać za spełniającą wymagania. Core Web Vitals nie są głównym czynnikiem rankingowym, ale w sytuacji, gdy dwie strony mają podobną jakość treści, ta z lepszymi wynikami wydajnościowymi może znaleźć się wyżej w wynikach wyszukiwania.

LCP – Largest Contentful Paint: największe wyzwanie optymalizacyjne

LCP mierzy czas od momentu rozpoczęcia nawigacji do chwili wyrenderowania największego widocznego elementu w oknie przeglądarki. Elementem tym może być obraz, nagłówek, wideo lub element z tłem graficznym. LCP jest najtrudniejszą do przejścia metryką spośród wszystkich Core Web Vitals i najczęściej stanowi główny powód, dla którego strony nie zdają oceny Google.

Progi Google dla LCP:

• Dobry: 2,5 sekundy lub mniej
• Wymaga poprawy: od 2,5 do 4,0 sekundy
• Słaby: powyżej 4,0 sekundy

Według danych z HTTP Archive Web Almanac 2025, dobry LCP osiąga 74% stron na urządzeniach desktopowych i 62% na urządzeniach mobilnych. To ogromny postęp w porównaniu z 2022 rokiem, gdy dobry wynik osiągało zaledwie około 44% stron mobilnych. Mimo to LCP pozostaje największym wąskim gardłem wśród wszystkich Core Web Vitals i dla wielu stron nadal jest główną barierą przed pozytywną oceną Google.

Najczęstsze przyczyny słabego LCP

Problemy z LCP mają zazwyczaj kilka nakładających się przyczyn. Wolny czas odpowiedzi serwera – spowodowany zbyt wieloma przekierowaniami, brakiem buforowania na sieci CDN lub wolnymi zapytaniami do bazy danych – to fundament, który wpływa na wszystko inne. Zasoby blokujące renderowanie, takie jak zewnętrzne arkusze CSS i synchroniczny JavaScript ładowane w nagłówku strony, opóźniają moment, w którym przeglądarka w ogóle zaczyna wyświetlać treść. Obrazy dodawane dynamicznie przez JavaScript, z włączonym opóźnionym ładowaniem, albo ustawione jako tło w CSS są przez przeglądarkę odkrywane późno – co wydłuża każdą kolejną fazę procesu. Zbyt duże pliki obrazów bez kompresji i bez nowoczesnych formatów to kolejna stała przyczyna, podobnie jak czcionki internetowe bez instrukcji, by przeglądarka nie czekała na ich załadowanie.

Cztery fazy LCP i jak je diagnozować

Google dzieli czas LCP na cztery podczęści, które sumują się do pełnego wyniku. Zrozumienie tej struktury jest kluczowe, bo tylko diagnoza na poziomie poszczególnych faz pozwala skutecznie wskazać, co należy poprawić.

Pierwsza faza: Czas do pierwszego bajtu (TTFB). Mierzy czas od momentu rozpoczęcia nawigacji do otrzymania pierwszego bajta danych z serwera. To fundament całego procesu – jeśli TTFB wynosi 2 sekundy, żadna optymalizacja obrazów ani JavaScriptu nie da dobrego wyniku LCP. Wolny TTFB to najczęściej efekt wolnego serwera, zbyt wielu przekierowań, braku buforowania na sieci CDN lub wolnych zapytań do bazy danych.

Druga faza: Opóźnienie pobierania zasobu (Resource Load Delay). To opóźnienie między otrzymaniem pierwszego bajta a momentem rozpoczęcia pobierania zasobu LCP. W praktyce oznacza sytuację, gdy przeglądarka musi najpierw przetworzyć kod CSS lub JavaScript, zanim „odkryje" główny element strony. Zdjęcia wstrzykiwane przez skrypty lub ukryte za właściwością tła w stylach są odkrywane późno.

Trzecia faza: Czas pobierania zasobu (Resource Load Duration). Czas potrzebny na faktyczne pobranie zasobu LCP – najczęściej głównego obrazu. Wpływ na tę fazę mają rozmiar pliku, format obrazu oraz przepustowość łącza użytkownika. Konwersja do formatów WebP i AVIF, kompresja obrazów i użycie sieci CDN skracają tę fazę.

Czwarta faza: Opóźnienie renderowania elementu (Element Render Delay). Czas między zakończeniem pobierania zasobu a jego faktycznym wyświetleniem przez przeglądarkę. Główną przyczyną opóźnień są długie zadania JavaScript blokujące główny wątek przeglądarki oraz brak instrukcji dla przeglądarki, by nie czekała na załadowanie czcionek przed renderowaniem tekstu.

Wszystkie cztery fazy wymagają jednoczesnej optymalizacji. Skupienie się na jednej przy zaniedbaniu pozostałych nie przyniesie oczekiwanych rezultatów.

Techniki optymalizacji LCP – od serwera po obrazy

Optymalizacja LCP to wielowarstwowy proces obejmujący zarówno infrastrukturę serwerową, jak i sposób budowania strony. Najważniejsze działania, które przynoszą najszybsze efekty:

Odkrycie zasobu LCP jak najwcześniej. Obraz LCP powinien być umieszczony bezpośrednio w kodzie HTML – nie ładowany przez JavaScript ani nie ustawiany jako tło w CSS, bo wtedy przeglądarka go nie widzi na etapie wstępnego skanowania dokumentu. Trzeba bezwzględnie usunąć opóźnione ładowanie z hero image – ten atrybut ma sens dla obrazów poniżej pierwszego ekranu, ale zastosowany do głównego elementu znacząco pogarsza LCP. Wskazanie przeglądarce, że dany obraz ma wysoki priorytet pobierania, pozwala jej odpowiednio wcześnie rozpocząć jego pobieranie.

Szybkie pobieranie zasobu. Nowoczesne formaty obrazów – WebP i AVIF – oferują znacznie lepszą kompresję niż tradycyjne JPG czy PNG przy zachowaniu podobnej jakości wizualnej. Responsywne obrazy z informacją o dostępnych rozmiarach pomagają przeglądarce wybrać plik optymalny dla urządzenia użytkownika. Sieć CDN redukuje fizyczną odległość między serwerem a użytkownikiem, co bezpośrednio skraca czas pobierania.

Wstępne połączenie z domenami zewnętrznymi. Instrukcja preconnect w nagłówku strony informuje przeglądarkę, by jeszcze przed załadowaniem zasobu zestawiła połączenie z zewnętrzną domeną – np. dostawcą czcionek czy siecią CDN – oszczędzając cenne milisekundy.

Eliminacja zasobów blokujących renderowanie. Krytyczne style – niezbędne do wyświetlenia pierwszego ekranu – warto wbudować bezpośrednio w HTML, a pozostałe arkusze stylów załadować asynchronicznie. Skrypty JavaScript niezbędne do wyświetlenia treści powinny być ładowane z opóźnieniem lub asynchronicznie.

Optymalizacja na poziomie serwera. Kluczowe jest włączenie kompresji Brotli lub Gzip, buforowania na sieci CDN oraz optymalizacja TTFB przez przyspieszenie zapytań do bazy danych lub wdrożenie mechanizmów buforowania odpowiedzi serwera.

Efekty biznesowe poprawy LCP są udokumentowane. Vodafone Italy odnotowało 8% wzrost sprzedaży po poprawie LCP o 31%. Tokopedia zanotowało 23% wzrost średniego czasu sesji po skróceniu LCP z 3,78 do 1,72 sekundy. Lazada odnotowała wzrost współczynnika konwersji na urządzeniach mobilnych o 16,9%.

INP – nowa metryka interaktywności, która zastąpiła FID

W marcu 2024 roku nastąpiła największa zmiana w Core Web Vitals od momentu ich wprowadzenia: metryka INP (Interaction to Next Paint) oficjalnie zastąpiła FID (First Input Delay). We wrześniu 2024 roku FID zostało całkowicie usunięte ze wszystkich narzędzi Google. To zmiana, którą każdy właściciel strony musi rozumieć.

FID mierzyło wyłącznie opóźnienie pierwszej interakcji użytkownika – czas między pierwszym kliknięciem a momentem, gdy przeglądarka zaczęła przetwarzać to zdarzenie. Miało poważną wadę: strona mogła lagować na każdym kolejnym kliknięciu po pierwszym i nadal osiągać dobry FID. Co więcej, FID ignorowało czas przetwarzania obsługi zdarzeń i czas renderowania – mierzyło samo opóźnienie wejścia, a nie pełne doświadczenie interakcji.

INP mierzy wszystkie interakcje w całej sesji użytkownika – kliknięcia myszą, dotknięcia ekranu, naciśnięcia klawiszy – i uwzględnia pełny cykl każdej z nich:

• Opóźnienie wejścia – czas oczekiwania, aż główny wątek będzie wolny i zdolny do obsługi zdarzenia
• Czas przetwarzania – wykonanie kodu obsługi zdarzenia
• Czas renderowania – aktualizacja obrazu na ekranie po przetworzeniu zdarzenia

Wynikiem jest najwolniejsza interakcja z całej sesji – dla stron z co najmniej 50 interakcjami jest to 98. percentyl wszystkich zarejestrowanych zdarzeń. Progi INP:

• Dobry: 200 milisekund lub mniej
• Wymaga poprawy: od 200 do 500 milisekund
• Słaby: powyżej 500 milisekund

W maju 2026 roku dobry INP osiągało około 86,6% wszystkich witryn. To ogromny wzrost w porównaniu z 2022 rokiem, gdy wynik dobry uzyskiwało około 55% stron. Warto jednak zauważyć pewien paradoks: popularniejsze strony z czołówki rankingów mają gorsze INP niż mniej popularne witryny. Wynika to z większej ilości JavaScriptu i większej liczby skryptów zewnętrznych, które są standardem w komercyjnych witrynach. Szczególnie trudna jest sytuacja w branży e-commerce – sklepy internetowe osiągają dobry INP tylko w 42% przypadków.

Co powoduje słaby INP i jak go poprawić

Słaby INP niemal zawsze ma związek z przeciążonym głównym wątkiem przeglądarki. Główny wątek to jedyna ścieżka, przez którą przeglądarka może obsługiwać zdarzenia użytkownika, wykonywać JavaScript i renderować widok. Gdy jest zajęty długim zadaniem, każda interakcja użytkownika musi czekać w kolejce – i właśnie ten czas oczekiwania mierzy INP.

Długie zadania JavaScript to najczęstsza przyczyna problemów z INP. Każdy blok kodu wykonujący się co najmniej 50 milisekund na głównym wątku blokuje możliwość reakcji na interakcje użytkownika. Gdy użytkownik kliknie przycisk w trakcie takiego zadania, przeglądarka nie może go przetworzyć, dopóki zadanie się nie skończy.

Ciężkie procedury obsługi zdarzeń to kolejna przyczyna. Gdy do jednego kliknięcia podpięta jest duża ilość logiki – walidacja formularza, przebudowa interfejsu, synchroniczne odczyty właściwości układu – przeglądarka musi wykonać to wszystko przed aktualizacją widoku. Brak technik takich jak debouncing czy throttling dla zdarzeń scroll, resize czy input sprawia, że procedury obsługi są wywoływane setki razy na sekundę.

Skrypty zewnętrzne według danych z 2026 roku odpowiadają za 41% wszystkich problemów z INP. Narzędzia analityczne, systemy czatów na żywo, reklamy, tagi eksperymentów A/B – wszystkie konkurują o główny wątek przeglądarki. To szczególnie frustrująca kategoria problemów, bo nad skryptami zewnętrznymi masz ograniczoną kontrolę.

Duże i złożone drzewo elementów DOM sprawia, że każda operacja zmiany układu wymaga od przeglądarki przeliczenia większej liczby elementów. Im większe drzewo, tym wolniejsze renderowanie po każdej interakcji.

Techniki poprawy INP:

• Przerywanie długich zadań – mechanizm oddawania kontroli do pętli zdarzeń pozwala przeglądarce obsłużyć oczekujące interakcje w środku długiego zadania
• Wątki robocze (Web Workers) – przeniesienie ciężkich obliczeń do osobnego wątku, poza główny wątek przeglądarki
• Podział kodu – ładowanie tylko tych modułów JavaScriptu, które są potrzebne na danej podstronie
• Debouncing i throttling – ograniczenie częstotliwości wywoływania procedur obsługi zdarzeń scroll i input
• CSS containment – informowanie przeglądarki, że zmiany w danym kontenerze nie wpływają na resztę strony, co przyspiesza renderowanie
• Wirtualizacja długich list – renderowanie tylko elementów widocznych w oknie przeglądarki zamiast całej listy
• Animowanie wyłącznie właściwości kompozytora – transform i opacity są obsługiwane przez kartę graficzną bez angażowania głównego wątku

Dokumentacja efektów potwierdza mierzalne wyniki poprawy INP. Indyjski portal redBus zanotował 72% poprawę INP (z około 870 ms do około 360 ms), która przełożyła się na 7% wzrost sprzedaży i wzrost współczynnika konwersji na urządzeniach mobilnych o 80–100%. The Economic Times odnotowało 50% spadek współczynnika odrzuceń po 61% poprawie INP.

CLS – stabilność wizualna strony

CLS mierzy nieoczekiwane przesunięcia układu strony. Jeśli kiedykolwiek czytałeś artykuł na telefonie i nagle tekst przeskoczył w dół, bo załadowało się zdjęcie lub pojawiła się reklama – doświadczyłeś złego CLS. To nie tylko irytujące, ale może też prowadzić do przypadkowego kliknięcia w element, którego użytkownik nie miał zamiaru kliknąć – na przykład reklamy zamiast przycisku kupna.

CLS jest wyliczany jako iloczyn dwóch wartości. Pierwsza to udział wpływowy – suma widocznych obszarów wszystkich niestabilnych elementów wyrażona jako ułamek okna przeglądarki. Druga to udział odległości – największa odległość przemieszczenia któregokolwiek elementu podzielona przez większy wymiar okna przeglądarki.

Google agreguje wyniki w oknach sesji – kolejnych przesunięciach występujących w odstępie mniejszym niż 1 sekunda, z maksymalnie 5 sekundami łącznego czasu trwania okna. CLS to wartość największego okna sesji, a nie suma wszystkich okien. Oznacza to, że strona z wieloma drobnymi, rozłożonymi w czasie przesunięciami może mieć dobry CLS, jeśli żadne pojedyncze skupisko przesunięć nie jest duże.

Progi CLS:

• Dobry: 0,1 lub mniej
• Wymaga poprawy: od 0,1 do 0,25
• Słaby: powyżej 0,25

Ważna cecha CLS: jest mierzony przez cały cykl życia strony, nie tylko do momentu jej załadowania. To odróżnia go od LCP i INP. Jeśli rzeczywiste dane użytkowników w CrUX pokazują gorszy CLS niż dane laboratoryjne, przyczyną są najczęściej przesunięcia po załadowaniu strony – podczas przewijania, dynamicznego ładowania kolejnych treści lub interakcji użytkownika.

Jak eliminować niechciane skoki układu strony

Najczęstsze przyczyny słabego CLS i sposoby ich eliminacji tworzą dobrze zdiagnozowaną listę problemów, z których większość da się rozwiązać bez dużych nakładów pracy.

Obrazy, filmy i ramki bez podanych wymiarów to klasyczna przyczyna skoków układu. Gdy przeglądarka nie wie z góry, jak duży będzie element, renderuje stronę bez rezerwowania dla niego miejsca. Gdy element się załaduje, wypycha pozostałe treści w dół. Rozwiązaniem jest zawsze podawanie szerokości i wysokości w znacznikach tych elementów. Jeśli wymagany jest responsywny układ, właściwość CSS aspect-ratio pozwala zachować proporcje elementu przy zmiennej szerokości.

Reklamy o dynamicznych rozmiarach to szczególnie trudna kategoria. Sieci reklamowe często w ostatniej chwili decydują o rozmiarze kreacji. Rozwiązaniem jest rezerwowanie stałego miejsca dla kontenera reklamowego przez określenie minimalnej wysokości lub użycie aspect-ratio. Reklamy pojawiające się nad istniejącą treścią są szczególnie szkodliwe dla CLS.

Dynamicznie wstrzykiwane treści – banery zgody na pliki cookie, powiadomienia systemowe, formularze zapisów do newslettera – gdy pojawiają się nad istniejącą treścią, powodują skoki układu. Najlepsza praktyka to rezerwowanie im miejsca od początku lub projektowanie ich tak, by pojawiały się w obszarze, który nie przesuwa istniejącej treści – na przykład jako stały pasek na dole ekranu.

Czcionki internetowe to subtelna przyczyna CLS. Gdy przeglądarka początkowo renderuje tekst w czcionce systemowej, a następnie ładuje czcionkę niestandardową, zmiana metryki czcionki może przestawić układ tekstu. Właściwość font-display: optional sprawia, że czcionka jest używana tylko wtedy, gdy zdąży się załadować przed pierwszym renderowaniem. Alternatywnie font-display: swap w połączeniu z dopasowaniem metryki czcionki zastępczej minimalizuje przesunięcie przy zmianie czcionki.

Animacje CSS na właściwościach układu, takich jak top, left, width, height, margin, padding, powodują przeliczanie układu i mogą prowadzić do przesunięć. Bezpieczne dla CLS są wyłącznie właściwości obsługiwane przez kartę graficzną: transform i opacity.

Warto wspomnieć o BFCache (pamięci podręcznej do nawigacji wstecz i wprzód) w Chrome. Strony przywrócone z tej pamięci mają CLS zerowany do zera, co poprawia postrzegane doświadczenie przy nawigacji między stronami.

Efekty biznesowe poprawy CLS: iCook zanotowało 10% wzrost przychodów z reklam po redukcji CLS o 15% przez standaryzację rozmiarów slotów reklamowych. AliExpress odnotowało spadek współczynnika odrzuceń o 15% po dziesięciokrotnej poprawie CLS. Yahoo! Japan po redukcji liczby stron ze słabym wynikiem o 98% zyskało 15% więcej odsłon na sesję.

PageSpeed Insights – jak prawidłowo interpretować wyniki

PageSpeed Insights (PSI) to narzędzie Google łączące dwa zupełnie różne źródła danych: laboratoryjne testy Lighthouse oraz rzeczywiste dane użytkowników z Chrome UX Report (CrUX). To pierwsze narzędzie, po które powinieneś sięgnąć diagnozując problemy z wydajnością strony. Ale by korzystać z niego skutecznie, trzeba rozumieć, czego dokładnie się w nim szuka.

Dane laboratoryjne – Lighthouse

Lighthouse to symulacja ładowania strony w kontrolowanym środowisku na serwerach Google. Dla urządzeń mobilnych emulowane jest urządzenie z ograniczonymi zasobami i przepustowością sieci symulującą 4G. Dla desktopów test wykonuje się bez ograniczania przepustowości. Lighthouse generuje wynik od 0 do 100 punktów, gdzie 90 i więcej oznacza dobry wynik, 50–89 wymaga poprawy, a poniżej 50 jest słabym wynikiem.

Waga składników wyniku Lighthouse:

• Total Blocking Time: 30% wyniku
• LCP: 25% wyniku
• CLS: 25% wyniku
• First Contentful Paint: 10% wyniku
• Speed Index: 10% wyniku

Dane terenowe – CrUX

CrUX to agregat rzeczywistych danych od użytkowników Chrome, którzy wyrazili zgodę na zbieranie danych o wydajności, zebranych w ciągu ostatnich 28 dni. Pokazuje rozkład wizyt w trzech kategoriach: dobry, wymaga poprawy i słaby. Przykładowe odczytanie: „11% w pomarańczowym LCP" oznacza, że 11% odsłon miało LCP między 2500 a 4000 milisekund. Strona przechodzi CWV, jeśli co najmniej 75% odsłon mieści się w kategorii dobry dla każdej z trzech metryk.

To rozróżnienie jest kluczowe i często pomijane: tylko dane terenowe (CrUX) wpływają na SEO. Lighthouse to wyłącznie narzędzie diagnostyczne. Strona może uzyskać 100 punktów Lighthouse i jednocześnie nie przechodzić Core Web Vitals w danych terenowych – na przykład dlatego, że użytkownicy korzystają z wolnych połączeń mobilnych lub starszych urządzeń.

Sekcja Opportunities – od czego zacząć

Sekcja Opportunities w raporcie PSI zawiera konkretne zalecenia z szacowanym czasem oszczędności. Warto zaczynać od trzech audytów z największą szacowaną oszczędnością. Często jedno działanie – na przykład optymalizacja formatu obrazów albo usunięcie zasobów blokujących renderowanie – może przynieść kilka sekund oszczędności i samo w sobie wystarczyć do przejścia progu LCP.

Ograniczenia PageSpeed Insights

PSI ma też swoje ograniczenia, o których warto wiedzieć. Narzędzie nie pokazuje diagramu sekwencji ładowania zasobów, który pozwala zobaczyć, co czeka na co podczas ładowania strony – do tego służy WebPageTest. Nie oferuje danych historycznych – każde uruchomienie to migawka bieżącego stanu. Testuje z jednej lokalizacji geograficznej. Wyniki Lighthouse mogą różnić się o 5–15 punktów między kolejnymi uruchomieniami ze względu na zmienne warunki serwerów testowych. Dane CrUX obejmują tylko Chrome i wymagają odpowiedniego natężenia ruchu – małe strony często nie mają wystarczającej ilości danych do pokazania wyników terenowych.

Integracja z Google Search Console

Raport Core Web Vitals w Google Search Console uzupełnia obraz, grupując strony o podobnym doświadczeniu i pokazując ich status w skali całego serwisu, osobno dla urządzeń mobilnych i desktopów. Pozwala szybko zidentyfikować, czy problem dotyczy pojedynczej podstrony, czy wzorca powtarzającego się w całym serwisie. Search Console i PageSpeed Insights działają najlepiej razem: Search Console wskazuje, które obszary serwisu wymagają uwagi, a PSI pozwala zbadać konkretny adres URL i zdiagnozować przyczynę problemu.

Praktyczny plan optymalizacji Core Web Vitals

Skuteczna optymalizacja Core Web Vitals to proces systematyczny i oparty na danych. Oto sprawdzony sposób postępowania:

Krok 1: Weryfikacja stanu bieżącego. Sprawdź CrUX w PageSpeed Insights – czy strona przechodzi Core Web Vitals? Czy problemy dotyczą desktopów, urządzeń mobilnych, czy obu? Uruchom test dla kilku kluczowych podstron: strony głównej, stron kategorii i stron produktów lub artykułów. To da obraz tego, czy masz do czynienia z problemem systemowym, czy lokalnym.

Krok 2: Identyfikacja trzech priorytetów. Jeśli strona nie przechodzi CWV, uruchom Lighthouse i zidentyfikuj trzy najważniejsze zalecenia z sekcji Opportunities – te z największą szacowaną oszczędnością czasu. Nie próbuj naprawiać wszystkiego naraz; skup się na najważniejszych.

Krok 3: Pogłębiona analiza. Dla dogłębnej diagnozy użyj WebPageTest – narzędzia, które pokazuje pełny diagram sekwencji ładowania zasobów i filmstrip ładowania strony. To pozwala zobaczyć dokładnie, co się dzieje podczas ładowania i co blokuje wyświetlenie głównego elementu strony.

Krok 4: Wdrożenie i weryfikacja. Po wprowadzeniu zmian zweryfikuj je w Lighthouse lokalnie lub na środowisku testowym, a następnie wdróż na produkcję. Odczekaj 28 dni – tyle trwa okno danych CrUX – i ponownie sprawdź PSI. Jednym z częstych błędów jest ocenianie efektów optymalizacji przed upływem pełnego okna CrUX.

Warto ustawić budżet wydajnościowy na poziomie 80% progów Google: LCP poniżej 2 sekund, INP poniżej 160 milisekund, CLS poniżej 0,08. Ten bufor bezpieczeństwa zapewnia, że nawet przy naturalnych wahaniach w 28-dniowym oknie CrUX strona utrzyma pozytywną ocenę.

Rekomendowana częstotliwość monitorowania:

• Codziennie: automatyczne testy Lighthouse w potoku wdrożeniowym
• Co tydzień: monitoring w WebPageTest lub GTmetrix
• Co miesiąc: sprawdzenie CrUX w PageSpeed Insights
• Co kwartał: pełny audyt wydajności i benchmark konkurencji

Aktualny stan CWV i ważne zmiany w 2026 roku

Dane z maja 2026 roku pokazują, że 55,9% stron przechodzi wszystkie trzy Core Web Vitals jednocześnie. To znaczący wzrost w porównaniu z 2021 rokiem, gdy odsetek ten wynosił około 32% dla urządzeń mobilnych. Jednak wciąż prawie połowa stron nie spełnia wymogów Google – co pokazuje, że optymalizacja wydajności wciąż jest obszarem z dużym potencjałem różnicowania na tle konkurencji.

Wyniki dla poszczególnych metryk w maju 2026 roku:

• LCP: 68,6% stron z wynikiem dobrym
• INP: 86,6% stron z wynikiem dobrym
• CLS: 81,3% stron z wynikiem dobrym

LCP pozostaje największym problemem. To dobra wiadomość dla stron, które poważnie podeszły do optymalizacji – bo każda poprawa LCP daje przewagę nad większością konkurencji.

Platformy CMS wykazują bardzo różne wyniki. Webflow prowadzi z 83,6% stron przechodzących wszystkie CWV. WordPress, który stanowi około 40% całego internetu, osiąga tylko 43,4%. To właśnie WordPress w największym stopniu wpływa na ogólną średnią. Jednocześnie oznacza to, że dobrze zoptymalizowana strona WordPress może znacząco wyróżnić się na tle większości innych witryn działających na tej samej platformie.

Zmiana modelu oceny w marcu 2026 roku

Marzec 2026 przyniósł istotną zmianę w tym, jak Google ocenia Core Web Vitals. Dotychczas ocena była prowadzona strona po stronie – każdy adres URL był oceniany indywidualnie. Nowy model ocenia całą domenę jako jednostkę. Jeśli ponad 25% adresów URL w domenie ma wynik słaby lub wymagający poprawy, cała domena otrzymuje negatywny sygnał rankingowy.

Wczesne obserwacje po tej zmianie wskazują na spadki ruchu od 20% do 35% dla serwisów ze słabymi wynikami. To potencjalny punkt zwrotny w postrzeganiu Core Web Vitals przez właścicieli stron – zaniedbanie choćby części podstron może teraz negatywnie wpłynąć na widoczność całego serwisu. Nie wystarczy już zadbać o stronę główną i kilka najważniejszych podstron – każdy adres URL w serwisie ma teraz bezpośredni wpływ na widoczność całej domeny.

Wnioski – wydajność strony jako przewaga konkurencyjna

Core Web Vitals to nie tylko techniczny wymóg Google – to przede wszystkim wskaźnik jakości doświadczenia użytkownika. Strony spełniające progi CWV mają niższy współczynnik odrzuceń, wyższe konwersje i lepsze zaangażowanie odwiedzających. Dane z dziesiątek udokumentowanych projektów potwierdzają, że poprawa wydajności przekłada się bezpośrednio na wyniki biznesowe – sprzedaż, przychody z reklam i lojalność użytkowników.

LCP pozostaje największym wyzwaniem i najczęstszym powodem niezdania oceny Google. Wymaga kompleksowego podejścia – od optymalizacji serwera przez budowanie strony po zarządzanie zasobami zewnętrznymi. INP, jako nowa metryka zastępująca FID, wymaga zmian w architekturze JavaScriptu, ale jej wskaźniki szybko się poprawiają w miarę rosnącej świadomości wśród twórców stron. CLS, po upowszechnieniu dobrych praktyk i wdrożeniu BFCache w Chrome, notuje największą poprawę rok do roku.

Kluczowa lekcja wynikająca z doświadczeń setek projektów: optymalizacja Core Web Vitals to proces, nie jednorazowe zadanie. Wymaga systematycznego monitorowania, testowania i iteracyjnych poprawek. Każda aktualizacja motywu, nowa wtyczka, nowy element na stronie może pogorszyć wyniki – dlatego automatyczne testy w potoku wdrożeniowym są tak ważne.

Zmiana z marca 2026 roku na ocenę całej domeny sprawia, że kompleksowe podejście jest ważniejsze niż kiedykolwiek. Core Web Vitals to nie opcja – to konieczność. Narzędzia takie jak PageSpeed Insights, Search Console i CrUX dają wszystko, czego potrzebujesz, by zacząć działać.