Jak przeprowadzić audyt Core Web Vitals w 2026 roku (i co się zmieniło, odkąd INP zastąpiło FID)

TL;DR: Core Web Vitals w 2026 r. to LCP, INP i CLS. FID został wycofany, a 12 marca 2024 r. jego miejsce zajął INP. Waga rankingu jest mniejsza, niż sugeruje większość SEO-wców (dokumentacja Google jasno stwierdza, że trafność wygrywa z page experience), ale wpływ na UX jest realny, więc audyt nadal się opłaca. To jest przewodnik audytowy, który dostarczam klientom: trzy progi metryk, dwustopniowe narzędzia (lab + field), lista poprawek uporządkowana według zwrotu z inwestycji oraz kwartalny rytm, który nie przepala zespołu inżynierskiego na złe zadania.

Prowadzę kwartalne audyty serwisów dla portfela średnich witryn w mindnow i seojuice.io. Za każdym razem ktoś pyta, czy trzeba poświęcić kolejny sprint na Core Web Vitals. Uczciwa odpowiedź zazwyczaj brzmi: nie. Protokół zmienił się w 2024 r., waga rankingowa jest niewielka, a większość artykułów o CWV przeszacowuje potencjał ruchu z wyszukiwarek. Audyt jednak wciąż ma znaczenie, bo powolne strony nadal obniżają konwersję, a INP jest zupełnie inną metryką niż FID. Ten artykuł to playbook audytowy. Nie jest to techniczny poradnik „jak zoptymalizować INP”; zespół web.dev pisze je lepiej ode mnie. To warstwa interpretacyjna, która kładzie się na wierzchu.

Co zmieniło się w Core Web Vitals między 2024 a 2026 r.

Najważniejsza zmiana: First Input Delay (FID) został wycofany, a Interaction to Next Paint (INP) stał się oficjalnym Core Web Vital 12 marca 2024 r. Zespół Chrome ogłosił to wprost:

"INP will officially become a Core Web Vital and replace FID on March 12 of this year." Jeremy Wagner and Rick Viscomi, web.dev blog, March 2024

Jeśli twój szablon audytu nadal pobiera FID, korzystasz z wycofanej metryki. Search Console usunął FID tego samego dnia. PageSpeed Insights pokazuje INP. Biblioteka Web Vitals JS w wersji 4 oznaczyła pomiar FID jako przestarzały. Narzędzia labowe, które wciąż raportują FID, są przydatne do triage’u, ale nie do decyzji rankingowych.

Dlaczego zamiana? FID mierzył tylko pierwszą interakcję na stronie i wyłącznie opóźnienie wejściowe tej interakcji. Strona mogła mieć szybkie pierwsze kliknięcie, a potem zacinać się przy każdym kolejnym tapnięciu. Metrykę dało się też łatwo oszukać: niczego nie odkładać na landing, a całość ładować przy drugim działaniu. INP zamyka oba luki, próbkując każdą interakcję i licząc pełne opóźnienie aż do kolejnego renderu:

"INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers, and finally up until the browser has painted the next frame." Jeremy Wagner and Barry Pollard, web.dev, Interaction to Next Paint

Praktyczny efekt w audytach: większość stron, które były na zielono przy FID, jest dziś na żółto lub czerwono przy INP. To zmiana mechaniczna, nie znak, że strona się pogorszyła. Zaplanuj nową bazę odniesienia, zanim powiesz interesariuszom, że wynik spadł.

Dwie mniejsze zmiany wpadły także w oknie 2024–2026. CrUX, czyli źródło danych field za raportem CWV w Search Console, zwiększył głębokość próbkowania, więc progi percentyla 75 liczone są na większej liczbie sesji. LCP zyskał diagnostykę składowych (TTFB, opóźnienie ładowania zasobu, opóźnienie renderu elementu) w PageSpeed Insights – to najcenniejsze usprawnienie diagnostyczne od lat.

Trzy aktualne metryki i ich progi audytowe

Trzy metryki, jedna tabela progów, stosowane w percentylu 75 ruchu rzeczywistych użytkowników osobno dla mobile i desktopu. Strona kanoniczna web.dev mówi o tym wprost:

"Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools." Philip Walton, web.dev, Web Vitals

Cięcie na percentylu 75 to punkt, który najczęściej umyka operatorom. Nie musisz mieć każdej sesji strony poniżej progu. Wystarczy trzy czwarte. Najwolniejszy ogon urządzeń, sieci i podstron może siedzieć w żółtej strefie, a URL i tak dostanie ocenę Good w CrUX.

Krok audytu dla każdej metryki. LCP: pobierz składowe LCP z PageSpeed Insights. Gdy TTFB przekracza 800 ms, poprawka leży po stronie serwera lub CDN, nie front-endu. Jeśli dominuje opóźnienie renderu elementu, naprawą jest preload obrazu lub krytyczne CSS. INP: otwórz stronę na średniej klasy telefonie z Androidem, kliknij każdy element interaktywny, obserwuj panel Performance pod kątem długich zadań powyżej 50 ms. Wynik bierze najwolniejsza interakcja. CLS: przewiń stronę na wolnym łączu. Jeśli układ przesuwa się przy podmianie fontu lub ładowaniu obrazu above the fold, naprawą jest zarezerwowanie miejsca (aspect-ratio w CSS) lub font-display swap z dobranym metrycznie fallbackiem.

Jeden anty-wzorzec w audytach do porzucenia. Nie optymalizuj wyniku Performance w Lighthouse jako zamiennika CWV. Lighthouse Performance to ważona kompozycja lab, zawiera Speed Index i Total Blocking Time, które nie są Core Web Vitals. Strona może mieć 95 w Lighthouse, a nadal oblać CWV w danych field, bo Lighthouse symuluje jeden profil urządzenia, a CWV mierzy każdego realnego użytkownika.

Jak Google faktycznie wykorzystuje CWV w rankingu

Przeczytaj dokumentację page experience Google. Linijka podsumowania jest dosadna:

"Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Google Search Central, Page Experience documentation

To zdanie jest ukryte w FAQ pod hasłem „How important is page experience to ranking success?” i jest najważniejszym publicznym stwierdzeniem Google o wadze CWV, które większość treści SEO pomija. Trafność i autorytet dominują. Page experience to jeden z wielu sygnałów, który przechyla ranking, gdy trafność jest zbliżona.

Ten sam dokument dopytuje i doprecyzowuje. Google potwierdza, że „Core Web Vitals are used by our ranking systems”, a następnie od razu wyjaśnia strukturę: „There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.” (Oba cytaty z tej samej dokumentacji.)

Jak czytać te trzy zdania razem. CWV jest w systemie. Nie ma dużej wagi. Nie istnieje jeden wynik page experience, który przełącza ranking; to klaster sygnałów, który pomaga Google rozstrzygać remisy, gdy inne sygnały są w miarę równe. Uczciwe przedstawienie dla interesariuszy: poprawa CWV na stronie z słabą treścią i linkami nie uratuje jej. Poprawa CWV na stronie z mocną treścią i linkami, która siedzi na pozycji 4 lub 5, może realnie pomóc przesunąć ją na pozycję 2 lub 3 w ciągu kilku miesięcy. Matematyka najpierw przechodzi przez trafność.

Szerszy obraz sygnałów rankingowych opisujemy w naszym artykule o pewności sygnałów rankingowych i audycie. CWV to tylko jeden panel na szerszym dashboardzie. Traktuj go właśnie tak.

Co faktycznie biorą pod uwagę wyszukiwarki AI

Zużywają inny protokół. Google AI Mode, ChatGPT browse, Perplexity czy narzędzie webowe Claude’a to systemy retrieval-and-summarization. Pobierają twoją stronę, parsują odpowiednie treści i cytują lub parafrazują je użytkownikowi. Szybkość strony w rozumieniu Core Web Vitals nie pojawia się w kryteriach selekcji; pobieranie odbywa się po stronie serwera, a budżet czasu jest hojniejszy niż u realnego użytkownika.

Na co zwracają uwagę: responsywność serwera (TTFB 30 s wytnie crawlera), HTTPS, treść renderująca się bez JavaScriptu (lub którą fetcher potrafi wykonać), dane strukturalne do parsowania oraz czysty semantyczny HTML. To częściowo pokrywa się z CWV na poziomie TTFB, ale reszta to inny audyt. Optymalizacja INP pod ChatGPT browse to strata czasu; agent nie wchodzi w interakcję z twoją stroną.

Implikacja praktyczna dla audytu 2026. Utrzymuj jeden cel TTFB (poniżej 800 ms), który służy obu audytom. Oddziel prace nad INP i CLS od prac pod AI search; to różne listy priorytetów. Jeśli twój miks ruchu przesuwa się w stronę sesji z AI-referali, godzina inżynierska lepiej pracuje nad renderowalnością treści i danymi strukturalnymi niż nad zbijaniem 50 ms z interakcji.

Narzędzia do pomiaru Core Web Vitals w 2026 r.

Zestaw narzędzi skonsolidował się od 2022 r. Sześć narzędzi pokrywa workflow lab + field, którego potrzebuje większość operatorów.

Dwustopniowy workflow. Zacznij od PageSpeed Insights dla jednego URL-a, by zobaczyć lab i field obok siebie. Liczba lab pokazuje, co jest technicznie osiągalne na czystym profilu urządzenia; liczba field mówi, co widzą realni użytkownicy. Gdy się rozjeżdżają, liczy się field, a luka to diagnoza. Lab na zielono + field na czerwono oznacza, że użytkownicy mają wolniejszy sprzęt lub sieci niż maszyny deweloperskie.

Dla powtarzalnych raportów i śledzenia trendów SEOJuice Lighthouse Score Checker wykonuje realny skan strony i daje link do udostępnienia plus historię trendu; wewnętrznie używamy go do śledzenia postępów klientów bez ręcznego uruchamiania Lighthouse co cykl audytu. Szerzej o interpretacji wyniku Lighthouse (co uchodzi za zdany wynik, jak składają się kategorie) piszemy w rozkładzie punktacji SEO w Lighthouse.

Jeśli chcesz zobaczyć, jak metryki CWV faktycznie korelują z ruchem z wyszukiwarki na puli prawdziwych stron, nasz kalkulator CWV Impact prezentuje zagregowane korelacje z ponad 164 000 przeaudytowanych stron. Główne wnioski pokrywają się z ramami Google: korelacje są realne, ale umiarkowane i różnią się między metrykami. CLS pokazuje najsłabszą korelację; LCP i INP są silniejsze, lecz wciąż niżej niż sugerują marketingowe hasła o CWV.

Typowe poprawki uporządkowane według zwrotu

Godziny inżynierskie są ograniczone. Porządkuj poprawki według wpływu na najgorszą metrykę, a nie według łatwości wdrożenia. Poniżej lista priorytetów, której używam po siedmiu latach audytów CWV.

Tier 1, czas odpowiedzi serwera. Jeśli TTFB przekracza 800 ms, każda front-endowa poprawka startuje z opóźnioną linią. Postaw CDN przed originem. Keszujsz HTML, gdy to możliwe. Przenieś zapytania bazy poza krytyczną ścieżkę renderu. Poprawa TTFB o 400 ms często przesuwa LCP o 600 ms, bo ładowanie zasobów przesuwa się w takt.

Tier 1, strategia obrazów. Elementem LCP jest zazwyczaj obraz. Preloaduj go priorytetowym hintem. Serwuj responsywne rozmiary via srcset. Używaj AVIF lub WebP z fallbackiem JPEG. Wszystkie inne obrazy lazy-loaduj natywnym atrybutem loading="lazy". Nie ustawiaj lazy-load na sam obraz LCP; to najczęstszy samobój w audytach CWV.

Tier 2, higiena JavaScript. Odkładaj skrypty niekrytyczne. Dziel bundlowanie. Audytuj tagi third-party; większość stron ma 4–6 skryptów z tag managera, które od lat nie zasługują na czas głównego wątku. Regresje INP niemal zawsze sprowadzają się do skryptu, który planuje długie zadanie w trakcie interakcji. Code-splituj ciężkie komponenty interaktywne, zwłaszcza search, filter lub carousel.

Tier 2, ładowanie fontów. Używaj font-display: swap z systemowym fallbackiem dopasowanym metrycznie, by swap nie powodował przeskoku układu. Preloaduj główny plik fontu. Jeśli ładujesz trzy webfonty, zostaw jeden.

Tier 3, rzeczy sprzątające. Ustawiaj width i height na każdym obrazie i embedzie. Rezerwuj miejsce na reklamy za pomocą min-height. Elementy podatne na CLS (powiadomienia, bannery, cookie-bannery) przenieś below the fold lub renderuj z transformem translate, który nie zmienia layoutu.

Czego nie robić. Nie gonimy za 100 w Lighthouse Performance. Nie blokujemy wdrożenia z powodu regresji CLS o 0,01. Nie pozwalamy, by interesariusz CWV zamawiał trzeci audyt, zanim wdrożono poprawki z drugiego. Metryka jest hałaśliwa, a raport ma opóźnienie.

Co AI Overviews mylą w temacie CWV

W odpowiedziach AI Overview na zapytania typu „core web vitals 2026” powtarzają się trzy schematy.

Pierwszy to duch FID. AI Overviews nadal często wymieniają FID jako Core Web Vital. Dane treningowe pochodzą sprzed marca 2024 r., a informacja o deprecjacji ma niską wagę w indeksie. Weryfikuj na web.dev lub Search Central, nie w podsumowaniu AI.

Drugi to nadmuchanie wagi rankingowej. Większość podsumowań AI upraszcza zawoalowany język Google do formuły „Core Web Vitals to kluczowy czynnik rankingowy”. Zwrot „key ranking factor” pojawia się w postach marketingowych, które model zapamiętał; faktyczna dokumentacja Google mówi, że trafność bije page experience. Kompresja spłaszcza niuanse.

Trzeci to pętla samo-AI-SEO. AI Overviews zalecają optymalizację pod wyszukiwarki AI poprzez CWV. Jak już ustaliliśmy, wyszukiwarki AI nie mierzą twojego INP. Szybkość strony w rozumieniu CWV jest nieistotna dla pobierania. Zbiór treningowy myli „szybka strona = dobre SEO”, nie rozróżniając powierzchni wyszukiwania.

Wniosek dla operatorów. Traktuj odpowiedzi AI Overview o CWV jako punkt wyjścia, nie źródło prawdy. Weryfikuj w dokumentacji Google i web.dev, zanim podejmiesz działania.

Kwartalny rytm audytu

Cztery checkpointy w roku, 90 minut każdy. Tyle potrzebuje większość średnich serwisów. Częściej to przerost kosztów; rzadziej – regresje wpadają, zanim je złapiesz.

Pobierz raport Core Web Vitals w Search Console. Zanotuj grupy URL-i, które zmieniły status od poprzedniego kwartału. Dla każdej odwróconej grupy uruchom PageSpeed Insights na przykładowym URL-u i zapisz diagnostykę składowych.

Labs-kanuj dziesięć głównych landing pages według ruchu. Porównaj z poprzednim kwartałem. Jeśli strona pogorszyła LCP o ponad 200 ms lub INP o 50 ms, oznacz ją do przeglądu inżynierskiego.

Próbkuj dane field z własnego RUM (biblioteka Web Vitals v4). Dane CrUX, które widzi Google, mają 28-dniowe opóźnienie; twoje są w czasie rzeczywistym. Porównaj kształt rozkładu, nie tylko średnie.

Triaguj listę poprawek według powyższych priorytetów. Wdrażaj jedną poprawkę z tieru 1 na kwartał, nawet gdy jest niewygodna. Sprzątanie z tieru 3 wjeżdża w normalnych cyklach release. Dla serwisów, które już mają kwartalny audyt SEO, nasz produkt audytowy automatyzuje lab-scan, by ręczny czas szedł na interpretację.

Czego ten audyt NIE rozwiązuje

Core Web Vitals to sygnał UX i lekki sygnał rankingowy. Nie jest to sygnał jakości treści, backlinków ani zaufania do marki. Jeśli twoja strona tkwi na drugiej stronie wyników dla konkurencyjnego zapytania, naprawa CLS nie przeniesie cię na pierwszą. Najpierw musi nastąpić praca nad trafnością i autorytetem.

CWV nie rozwiązuje też konwersji w sposób, którego niektórzy oczekują. 200 ms szybsze LCP koreluje z lepszą konwersją, ale elastyczność różni się drastycznie w zależności od typu serwisu. Procesy checkout w e-commerce reagują silnie; długie treści – słabo. Zmierz własny lift konwersji, zanim zbudujesz case dla inżynierii.

I CWV nie rozwiązuje audytu wyszukiwarek AI. Inny protokół, inny fetcher, inne priorytety. Jeśli twój ruch przesuwa się ku sesjom z AI, audyt page experience nie odpowie na to pytanie.

FAQ

Czy FID nadal jest Core Web Vital? Nie. FID został wycofany i usunięty z programu Core Web Vitals 12 marca 2024 r. Jego miejsce zajął Interaction to Next Paint (INP). Search Console tego samego dnia usunął FID z raportu CWV. Jeśli twój szablon audytu nadal pobiera FID, zaktualizuj go.

Jaki jest próg INP? 200 ms lub mniej to Good. 200–500 ms to Needs Improvement. Powyżej 500 ms to Poor. Próg dotyczy percentyla 75 rzeczywistych interakcji użytkowników osobno dla mobile i desktopu.

Jak bardzo Core Web Vitals wpływa na ranking Google? Mniej, niż twierdzi większość treści SEO. Dokumentacja page-experience Google mówi wprost, że Search „zawsze stara się pokazać najbardziej trafne treści, nawet jeśli page experience jest słaby”. CWV to realny sygnał, ale jeden z wielu, a trafność i autorytet dominują. Traktuj go jako dogrywkę między porównywalnymi stronami, nie główną dźwignię.

Czy wyszukiwarki AI, takie jak ChatGPT czy Google AI Mode, używają Core Web Vitals? Nie w ten sam sposób. Ich fetchery pobierają strony po stronie serwera i parsują treść do podsumowania. Szybkość strony w rozumieniu CWV jest nieistotna dla pobierania. Liczy się dostępność serwera (TTFB), renderowalność treści bez JS i dane strukturalne; INP i CLS nie.

Jaki jest najczęstszy błąd w audycie Core Web Vitals? Optymalizacja wyniku Lighthouse Performance jako zastępnik CWV. Lighthouse Performance to ważona labowa kompozycja zawierająca metryki spoza CWV (Speed Index, Total Blocking Time). Strona może mieć 95 w Lighthouse, a nadal oblać CWV w danych field, bo Lighthouse symuluje jeden profil sprzętowy, a CWV mierzy każdego odwiedzającego.

Jak często powinienem audytować Core Web Vitals? Kwartalnie wystarczy dla większości średnich serwisów. Częściej to przerost kosztów; dane CrUX mają 28-dniowe opóźnienie, a cykl wdrożeniowy rzadko jest szybszy. Używaj ciągłego monitoringu RUM (Web Vitals v4) do alertów w czasie rzeczywistym między audytami.