Core Web Vitals

TL;DR — Core Web Vitals to trzy wyniki, których Google używa do mierzenia, jak strona odczuwalnie działa dla prawdziwych użytkowników: jak szybko się ładuje (LCP), jak szybko reaguje, gdy dotkniesz lub klikniesz (INP) oraz jak bardzo elementy przeskakują podczas ładowania (CLS). „Dobrze” oznacza LCP poniżej 2,5 sekundy, INP poniżej 200 milisekund i CLS poniżej 0,1. Mają niewielki wpływ na ranking — ale dobra treść ma znacznie większe znaczenie.

Czym są Core Web Vitals

Google chce nagradzać strony, które są przyjemne w użyciu, więc sprowadziło „dobrą jakość strony” do trzech mierzalnych rzeczy. Razem tworzą one Core Web Vitals (często skracane do CWV):

• Largest Contentful Paint (LCP) — ładowanie. Jak długo trwa, zanim największy element na ekranie (zwykle obraz hero lub nagłówek) się pojawi. Dobrze to ≤ 2,5 sekundy.
• Interaction to Next Paint (INP) — responsywność. Gdy dotkniesz przycisku lub wpiszesz tekst, jak długo trwa reakcja strony. Dobrze to ≤ 200 milisekund.
• Cumulative Layout Shift (CLS) — stabilność wizualna. Jak bardzo strona przeskakuje podczas ładowania (reklama przesuwa tekst w dół dokładnie wtedy, gdy chcesz dotknąć). Dobrze to ≤ 0,1.

Skąd pochodzą wyniki

Wyniki, których Google faktycznie używa, pochodzą od prawdziwych osób odwiedzających Twoją witrynę w Chrome — a nie z testu, który sam uruchamiasz. Google zbiera te dane, a strona jest oceniana na podstawie tego, czego doświadczyło 75 % odwiedzających. Nie możesz więc „zdać”, uzyskując jeden szybki wynik na własnym urządzeniu; większość Twoich prawdziwych odwiedzających musi mieć dobre doświadczenie. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Dlatego idealny wynik w narzędziu do testowania szybkości nie gwarantuje zdania. Te narzędzia (takie jak PageSpeed Insights i Lighthouse) przeprowadzają pojedynczy test laboratoryjny na symulowanym telefonie — świetne do znajdowania problemów, ale to nie są liczby, na podstawie których Google tworzy ranking.

Czy wpływają na ranking?

Trochę. Google twierdzi, że Core Web Vitals są używane przez jego systemy rankingowe — ale nie ma oficjalnej wagi ani procentu przypisanego do nich, a Google wyraźnie stwierdza, że istotna treść może nadal wyprzedzić stronę z gorszym doświadczeniem strony. Jeśli Twoja treść nie jest istotna, szybkość i stabilność Cię nie uratują. Jak ujął to John Mueller z Google, „nie sprawi, że ranking Twojej witryny nagle wzrośnie”.

Moja szczera opinia po latach pracy w tej branży: większość witryn nie zobaczy dużej korzyści rankingowej z gonienia tych liczb. Ale nie ma nic złego w uczynieniu swojej witryny szybszą i bardziej stabilną — Twoi odwiedzający to zauważą, a to pomaga w konwersjach, nawet gdy nie przekłada się na ranking.

Jedna rzecz, którą ludzie mylą

Alert o starej nazwie: możesz nadal widzieć FID (First Input Delay) wymieniane jako Core Web Vital. To już przeszłość — INP zastąpiło FID 12 marca 2024 r. Jeśli narzędzie lub artykuł nadal mówi Ci, aby optymalizować FID, jest nieaktualne.

Chcesz bardziej szczegółową wersję — dokładne progi, dane terenowe vs laboratoryjne, jak duże znaczenie to naprawdę ma dla rankingu i którego narzędzia użyć w danej sytuacji? Przełącz się na zakładkę Zaawansowane.

TL;DR — Core Web Vitals to trzy mierzone w terenie metryki UX: LCP (ładowanie, „dobrze” ≤ 2,5 s), INP (responsywność, ≤ 200 ms) i CLS (stabilność wizualna, ≤ 0,1), każda oceniana na 75. percentylu prawdziwych użytkowników Chrome (CrUX) w ruchomym oknie 28-dniowym. Progi są takie same dla urządzeń mobilnych i desktopowych, ale Google ocenia każdy z nich osobno i oczekuje, że wszystkie trzy metryki będą dobre — nie tylko jedna. INP zastąpiło FID 12 marca 2024 r. Google twierdzi, że jego systemy rankingowe używają Core Web Vitals, ale nie ma oficjalnej wagi ani procentu „decydującego” przypisanego do nich — dobry wynik nie gwarantuje lepszego rankingu, a istotność treści może nadal wygrać. Wyniki laboratoryjne (Lighthouse/PSI) to pomiary diagnostyczne i często nie pokrywają się z danymi terenowymi. TTFB i FCP to diagnostyczne „inne Web Vitals”; TBT i Speed Index to laboratoryjne przybliżenia.

Co liczy się jako Core Web Vital

Google definiuje Core Web Vitals jako “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.” (tłumaczenie) „podzbiór Web Vitals, który ma zastosowanie do wszystkich stron internetowych, powinien być mierzony przez wszystkich właścicieli witryn i będzie widoczny we wszystkich narzędziach Google”. Są ich dokładnie trzy, każdy mierzy inny wymiar tego, jak strona się odczuwa:

Google ocenia trzy progi „dobry” na 75. percentylu: LCP przy 2,5 sekundy, INP przy 200 milisekundach i CLS przy 0,1. Strona jest oceniana jako „dobra” tylko wtedy, gdy wszystkie trzy przekroczą swój próg na p75 — nie tylko jeden lub dwa. Progi są takie same dla urządzeń mobilnych i komputerów stacjonarnych, chociaż Google ocenia i raportuje każdą klasę urządzeń osobno. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

Wszystko inne, o czym słyszałeś — TTFB, FCP, TBT, Speed Index — nie jest Core Web Vital. Więcej o tym poniżej.

LCP — ładowanie

LCP “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (tłumaczenie) „raportuje czas renderowania największego obrazu, bloku tekstu lub wideo widocznego w obszarze roboczym względem momentu, gdy użytkownik po raz pierwszy przeszedł na stronę”. W praktyce elementem LCP jest zwykle obraz hero, duży obraz tła albo blok nagłówka. Zauważ, że chodzi o największy widoczny element — różne rozmiary viewportu mogą mieć różne elementy LCP, co jest jednym z powodów rozbieżności między danymi terenowymi a laboratoryjnymi.

INP — responsywność

INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (tłumaczenie) „ocenia ogólną responsywność strony na interakcje użytkownika, obserwując opóźnienie wszystkich kliknięć, dotknięć i interakcji klawiatury występujących przez cały czas wizyty użytkownika na stronie”. Mierzy pełną interakcję: opóźnienie wejścia → przetwarzanie procedury obsługi zdarzenia → czas do namalowania następnej klatki.

To duża poprawa w porównaniu z metryką, którą zastąpił. INP poprawia FID, obserwując wszystkie interakcje, nie tylko pierwszą — FID mierzył tylko opóźnienie wejścia pierwszej interakcji. INP stał się Core Web Vital 12 marca 2024 roku, zastępując First Input Delay (FID). Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch FID został usunięty z Search Console tego samego dnia. Jest w pełni wycofany — nie optymalizuj pod niego.

Jedna warto zapamiętać: INP to nie Twoja najgorsza pojedyncza interakcja, to wysoki percentyl wszystkich interakcji. Pojedyncze zacinające się kliknięcie nie zepsuje ogólnie dobrej strony.

CLS — stabilność wizualna

CLS “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (tłumaczenie) „jest miarą największej serii wyników przesunięcia układu dla każdego nieoczekiwanego przesunięcia występującego w całym cyklu życia strony”. „Seria” (okno sesji) grupuje przesunięcia, które występują w ciągu 1 sekundy od siebie, aż do 5-sekundowego całkowitego okna. Typowe przyczyny wymieniane przez Google to “images or videos with unknown dimensions,” (tłumaczenie) „obrazy lub filmy o nieznanych wymiarach”, “fonts that render larger or smaller than its initial fallback,” (tłumaczenie) „fonty renderowane jako większe lub mniejsze niż ich początkowy krój zastępczy” oraz “third-party ads or widgets that dynamically resize themselves.” (tłumaczenie) „reklamy lub widżety innych firm, które dynamicznie zmieniają swój rozmiar”.

Dane terenowe a dane laboratoryjne — pomiar i diagnoza

To rozróżnienie powoduje najwięcej zamieszania, więc bądź precyzyjny.

• Dane terenowe (CrUX) to “data collected from the real users visiting your site.” (tłumaczenie) „dane zebrane od prawdziwych użytkowników odwiedzających witrynę”. Są raportowane na 75. percentylu, w ruchomym oknie 28-dniowym, podzielone na urządzenia mobilne i komputery stacjonarne. Core Web Vitals reprezentują tego rodzaju doświadczenie w świecie rzeczywistym i są używane przez systemy rankingowe Google. Odzwierciedlają prawdziwe urządzenia, sieci, stany pamięci podręcznej i pamięć podręczną wstecz/do przodu.
• Dane laboratoryjne to “data collected in a controlled environment with predefined device and network settings” (tłumaczenie) „dane zebrane w kontrolowanym środowisku ze zdefiniowanymi ustawieniami urządzenia i sieci” — pojedynczy emulowany telefon, zimna pamięć podręczna, brak prawdziwego użytkownika. Lighthouse i sekcja laboratoryjna PageSpeed Insights produkują te dane. To narzędzie diagnostyczne do znajdowania problemów, a nie pomiar terenowy. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Własne wytyczne Google: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (tłumaczenie) „Jeśli dla danej strony masz zarówno dane terenowe, jak i laboratoryjne, do ustalania priorytetów używaj danych terenowych”. Wynik Performance Score z Lighthouse “often does not correlate with field Core Web Vitals.” (tłumaczenie) „często nie koreluje z terenowymi Core Web Vitals”. Mówię to samo w moim przewodniku po Core Web Vitals: dane laboratoryjne są bardziej przydatne do testowania i iteracji, ponieważ terenowe dane CWV są oparte na 28-dniowej średniej kroczącej — nie zobaczysz efektu swojej poprawki przez tygodnie.

Zasada p75 i dlaczego ma znaczenie

Strona przechodzi tylko wtedy, gdy 75% prawdziwych użytkowników osiągnie próg „dobry”. To celowo wyrozumiała, ale realistyczna poprzeczka: większość Twoich odwiedzających (3 z 4) miała dobre doświadczenia, a nie jesteś zakładnikiem kilku odstających przypadków na fatalnych połączeniach. To także powód, dla którego samo pokazanie 1,8 s ładowania na Twoim telefonie nic nie znaczy — liczy się Twój p75 dla wszystkich.

Poziom strony a poziom origin — nie daj się zwieść

Wiele narzędzi domyślnie pokazuje wynik na poziomie origin (średnia dla całej witryny), który może być znacznie bardziej różowy niż wyniki poszczególnych stron. W moim badaniu danych CWV (CrUX plus 5,2 mln stron z Ahrefs Site Audit) tylko 21,2% poszczególnych stron spełniło wszystkie trzy progi, w porównaniu z 33% na poziomie origin. Dokumentacja Google dotycząca doświadczeń strony mówi, że jej systemy zazwyczaj oceniają strony indywidualnie, choć przeprowadza też szersze oceny całej witryny — więc origin, który „przechodzi”, może wciąż ukrywać wiele niezdających poszczególnych stron. Gdy narzędzie oferuje oba widoki, nie zakładaj, że średnia na poziomie origin mówi Ci, co robi konkretna strona; sprawdź też liczbę na poziomie strony.

Powiązana pułapka: strony bez wystarczającego ruchu nie mają żadnych danych terenowych CrUX, a CrUX obejmuje tylko użytkowników Chrome, którzy wyrazili zgodę na statystyki użytkowania (bez Chrome na iOS, bez innych przeglądarek). To luka w kwalifikowalności danych, a nie porażka — brak danych terenowych to nie to samo co słaby wynik. Dokładnie to, jak dane narzędzie grupuje podobne strony lub stosuje fallback dla adresów URL o niskim ruchu (PSI, Search Console, API CrUX), jest udokumentowane przez ten konkretny produkt, a nie przez jedną uniwersalną zasadę.

Jak bardzo Core Web Vitals faktycznie wpływają na ranking?

Są potwierdzonym sygnałem rankingowym — Google mówi, że jego systemy rankingowe korzystają z Core Web Vitals. Tego, czego obecna dokumentacja Google nie robi, to przypisanie oficjalnej wagi, procentu lub etykiety „rozstrzygającego” do tego sygnału, więc uważaj, aby nie powtarzać tych ram, jakby były własnymi słowami Google.

Po stronie „to realne”: dokumentacja Google mówi, że Core Web Vitals “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (tłumaczenie) „wraz z innymi aspektami jakości strony odpowiadają temu, co nasze podstawowe systemy rankingowe starają się nagradzać”, a John Mueller publicznie stwierdził, że to “more than a tie-breaker, but it also doesn’t replace relevance.” (tłumaczenie) „więcej niż czynnik rozstrzygający, ale nie zastępuje trafności”.

Po stronie „nie przesadzaj”: Mueller powiedział też “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (tłumaczenie) „Core Web Vitals nie są ogromnymi czynnikami rankingowymi i wątpię, by tylko z tego powodu nastąpił duży spadek”, a przy aktualizacji dokumentacji w marcu 2024 dodał przez LinkedIn, że “it’s not going to make your site’s rankings jump up.” (tłumaczenie) „nie sprawi to, że pozycje witryny nagle wzrosną”. Dokumentacja Google dotycząca jakości strony stwierdza: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (tłumaczenie) „Wyszukiwarka Google zawsze stara się pokazywać najbardziej trafną treść, nawet jeśli jakość strony jest poniżej przeciętnej”. Dokumentacja z 2024 roku ostrzega również, że “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (tłumaczenie) „dążenie do idealnego wyniku wyłącznie ze względów SEO może nie być najlepszym wykorzystaniem czasu”. Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience

Moja pragmatyczna ocena: trafność dominuje, Google nie podało liczby określającej, ile CWV się liczy, a większość witryn nie zobaczy wielkich korzyści z pracy nad nimi dla rankingów. To powiedziawszy, leżące u podstaw ulepszenia UX są warte zrobienia dla użytkowników i konwersji — a platformy (WordPress, Cloudflare, frameworki) automatycznie przejmują coraz większą część ciężaru optymalizacji. Zwłaszcza dla małych i lokalnych firm zwykle nie powinno to być na szczycie listy.

Jeszcze jedno wyjaśnienie z aktualizacji 2024: z szerszych sygnałów page experience tylko Core Web Vitals są potwierdzone jako bezpośrednio wpływające na ranking. HTTPS, przyjazność dla urządzeń mobilnych, brak natrętnych interstitiali, klarowność treści — wszystko to dobra praktyka, ale nie wpływa bezpośrednio na ranking tak, jak kiedyś sugerowała dokumentacja.

„Inne Web Vitals” — diagnostyczne, nie Core

Te pojawiają się ciągle i są błędnie kategoryzowane. Żadne z nich nie jest Core Web Vitals:

• Time to First Byte (TTFB) — jak długo trwa dotarcie pierwszego bajtu odpowiedzi. „Poprzedza każdy inny znaczący wskaźnik wydajności ładowania” i wpływa na LCP, ale Google jest jednoznaczne: „Ponieważ TTFB nie jest metryką Core Web Vitals, nie jest absolutnie konieczne, aby witryny spełniały próg ‘dobry’ dla TTFB.” (Dobry ≤ 0,8 s.) Diagnostyczny.
• First Contentful Paint (FCP) — czas do pojawienia się jakiejkolwiek treści. Przydatny wskaźnik diagnostyczny ładowania (dobry ≤ 1,8 s), ale nie Core.
• Total Blocking Time (TBT) — laboratoryjny odpowiednik INP. Narzędzia takie jak Lighthouse „nie mogą zmierzyć INP” bez prawdziwego użytkownika, więc raportują TBT zamiast tego. Tylko laboratoryjny.
• Speed Index — laboratoryjny odpowiednik postrzeganej szybkości ładowania. Tylko w Lighthouse.

Używaj ich do debugowania. Nie raportuj ich jako Core Web Vitals ani nie traktuj ich progów jako bramek rankingowych.

Mit do obalenia

Możesz spotkać się z „Engagement Reliability” jako nowym Core Web Vital. Nie ma żadnego oficjalnego ogłoszenia Google dotyczącego takiej metryki — krąży ona tylko w treściach stron trzecich. Core Web Vitals to LCP, INP i CLS. Dopóki Google nie powie inaczej, to jest lista.

Jak mierzyć — i które narzędzie do czego

Dopasuj narzędzie do zadania:

• Istotne dla rankingu (dane terenowe): PageSpeed Insights (pokazuje dane terenowe CrUX na poziomie strony i domeny), raport Core Web Vitals w Google Search Console (grupuje podobne strony, ujawnia wzorce w całej witrynie), API CrUX / BigQuery (analiza niestandardowa i na poziomie kraju) oraz biblioteka JS web-vitals (zbieraj własny RUM).
• Debugowanie (dane laboratoryjne): Lighthouse, panel Performance w Chrome DevTools oraz sekcja laboratoryjna PSI. Te narzędzia znajdują przyczynę; nie decydują o Twoim rankingu.

Proponowany przeze mnie przepływ pracy: użyj GSC, aby znaleźć, które grupy stron zawodzą w terenie, potwierdź za pomocą PageSpeed Insights na poziomie strony, a następnie przejdź do Lighthouse / DevTools, aby zdiagnozować i iterować — pamiętając, że dane terenowe nie zaktualizują się przez maksymalnie 28 dni.

Gdzie dalej: klaster wydajności sieci

To centrum jest mapą. Każdy temat poniżej to osobne szczegółowe omówienie.

Trzy Core Web Vitals

• Largest Contentful Paint — metryka ładowania: co liczy się jako element LCP, cel ≤2,5 s i jak sprawić, by pojawił się wcześniej.
• Interaction to Next Paint — metryka responsywności, która zastąpiła FID: opóźnienie wejścia, przetwarzanie zdarzeń i opóźnienie prezentacji oraz jak je skrócić.
• Cumulative Layout Shift — metryka stabilności wizualnej: okna sesji, typowe przyczyny (media z rozmiarami, czcionki, wstrzykiwane reklamy) i jak osiągnąć ≤0,1.

Metryki wspierające i diagnostyczne

• Time to First Byte — opóźnienie serwera/odpowiedzi, które wpływa na LCP; przydatne do debugowania, nie jest Core Web Vital.
• First Contentful Paint — kiedy pojawia się pierwsza treść; diagnostyka ładowania.
• Total Blocking Time — laboratoryjny odpowiednik, którego Lighthouse używa do przybliżenia INP.
• Speed Index — laboratoryjny odpowiednik postrzeganej szybkości ładowania.

Jak są mierzone

• PageSpeed Insights — dane terenowe (CrUX) plus raport laboratoryjny Lighthouse w jednym miejscu.
• Google Lighthouse — silnik laboratoryjny/diagnostyczny stojący za PSI i DevTools.
• Chrome UX Report (CrUX) — zbiór danych od prawdziwych użytkowników, na którym opiera się ocena Google.

Dla całego klastra zobacz centrum Web Performance. Każdy powiązany artykuł automatycznie linkuje tutaj, gdy zostanie opublikowany.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Core Web Vitals = trzy metryki terenowe: LCP (ładowanie, dobre ≤ 2,5 s), INP (responsywność, ≤ 200 ms), CLS (stabilność wizualna, ≤ 0,1). Wszystko inne (TTFB, FCP, TBT, Speed Index) nie jest Core.
• Oceniane na danych terenowych: realni użytkownicy Chrome przez CrUX, na 75. percentylu, w ruchomym oknie 28 dni. Progi są takie same dla urządzeń mobilnych/desktopów, ale oceniane osobno, a Google oczekuje, że wszystkie trzy metryki będą dobre, nie tylko jedna.
• INP zastąpiło FID 12 marca 2024. FID jest całkowicie wycofane; INP mierzy wszystkie interakcje, nie tylko pierwszą.
• Narzędzia laboratoryjne (Lighthouse/PSI) są diagnostyczne, a nie pomiarami terenowymi, i często nie pokrywają się z terenowym CWV. Użyj ich, aby znaleźć przyczyny; liczby terenowe opóźniają się do 28 dni.
• Poziom strony vs poziom originu ma znaczenie: ~21,2 % stron przechodzi vs ~33 % originów (moje badanie CWV). Google używa poziomu strony — średnie originu ukrywają niezdające strony.
• Waga w rankingu: używana, ale nieważona. Google mówi, że jego systemy rankingowe używają Core Web Vitals, bez oficjalnego procentu ani etykiety „tiebreaker”; trafność dominuje, a dobry wynik nie jest gwarancją rankingu. Mueller: „not giant factors in ranking.” (tłumaczenie) „nie są to ogromne czynniki w rankingu.” Tylko CWV (nie HTTPS, przyjazność dla urządzeń mobilnych, interstitials) bezpośrednio się przyczynia według dokumentacji z 2024.
• Mit do pominięcia: „Engagement Reliability” nie jest potwierdzonym Core Web Vital.
• Narzędzia: teren = PSI, raport CWV w GSC, API CrUX, web-vitals.js; debugowanie = Lighthouse, DevTools, sekcja lab w PSI.

Oficjalna dokumentacja

Podstawowa dokumentacja źródłowa od Google.

web.dev (zespół Chrome)

• Web Vitals — inicjatywa, trzy metryki, zasada p75 i dlaczego TTFB/FCP to „inne” Web Vitals.
• Largest Contentful Paint (LCP) — definicja, progi i kwalifikujące się elementy LCP.
• Interaction to Next Paint (INP) — definicja, progi i podział na opóźnienie wejścia → przetwarzanie → prezentację.
• Cumulative Layout Shift (CLS) — definicja, okna sesji i typowe przyczyny.
• Definiowanie progów metryk Core Web Vitals — dlaczego wybrano każdy „dobry” próg i 75. percentyl.
• Różnice między danymi laboratoryjnymi i terenowymi — dlaczego liczby terenowe (CrUX) i laboratoryjne (Lighthouse) się różnią.
• Przepływy pracy i narzędzia Core Web Vitals — które narzędzie raportuje dane terenowe, a które laboratoryjne.
• INP zostanie metryką Core Web Vitals (maj 2023) — ogłoszenie, że INP zastąpi FID.
• Interaction to Next Paint oficjalnie staje się Core Web Vital (12 marca 2024) — potwierdzenie premiery.
• TTFB i FCP — diagnostyczne „inne Web Vitals”.

Google Search Central

• Core Web Vitals a wyniki wyszukiwania Google — jak CWV odnoszą się do rankingu.
• Jakość strony w wynikach wyszukiwania Google — szerszy obraz doświadczenia strony i ramy „trafność wygrywa”.
• Wprowadzenie INP do Core Web Vitals (maj 2023) — ogłoszenie Search Central.

Chrome dla deweloperów

• Raport o doświadczeniach użytkowników Chrome (CrUX) — zbiór danych o realnych użytkownikach, kwalifikowalność i okno 28 dni.

Cytaty ze źródła

Oficjalne wypowiedzi Google. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Google — czym są Core Web Vitals

• “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.” (tłumaczenie) „Core Web Vitals to podzbiór Web Vitals mający zastosowanie do wszystkich stron internetowych, który powinien być mierzony przez wszystkich właścicieli witryn i będzie widoczny we wszystkich narzędziach Google”. — Philip Walton, web.dev. Skocz do cytatu
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (tłumaczenie) „LCP raportuje czas renderowania największego obrazu, bloku tekstu lub wideo widocznego w obszarze roboczym względem momentu, gdy użytkownik po raz pierwszy przeszedł na stronę”. — web.dev (LCP). Skocz do cytatu
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (tłumaczenie) „INP to metryka oceniająca ogólną responsywność strony na interakcje użytkownika przez obserwację opóźnienia wszystkich kliknięć, dotknięć i interakcji klawiatury podczas wizyty użytkownika na stronie”. — web.dev (INP). Skocz do cytatu
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (tłumaczenie) „CLS jest miarą największej serii wyników przesunięcia układu dla każdego nieoczekiwanego przesunięcia występującego w całym cyklu życia strony”. — web.dev (CLS). Skocz do cytatu

Google — INP zastępuje FID

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” (tłumaczenie) „Interaction to Next Paint (INP) jest teraz stabilną metryką Core Web Vital, zastępującą First Input Delay (FID)”. — Rick Viscomi, web.dev (12 marca 2024). Skocz do cytatu

Google — dane terenowe a laboratoryjne oraz ranking

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (tłumaczenie) „Jeśli dla danej strony masz zarówno dane terenowe, jak i laboratoryjne, do ustalania priorytetów używaj danych terenowych”. — Philip Walton, web.dev. Skocz do cytatu
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (tłumaczenie) „Chrome User Experience Report, nazywany też Chrome UX Report lub w skrócie CrUX, to zbiór danych odzwierciedlający doświadczenia prawdziwych użytkowników Chrome w popularnych miejscach w internecie”. — Chrome for Developers (dokumentacja CrUX). Skocz do cytatu

John Mueller, Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (tłumaczenie) „To czynnik rankingowy i coś więcej niż czynnik rozstrzygający, ale nie zastępuje trafności”. — za pośrednictwem Search Engine Journal (Reddit, sierpień 2021). Przeczytaj relację
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (tłumaczenie) „Core Web Vitals nie są ogromnymi czynnikami rankingowymi i wątpię, by tylko z tego powodu nastąpił duży spadek”. — za pośrednictwem Stan Ventures (2024). Przeczytaj relację

Lista kontrolna Core Web Vitals

Szybkie sprawdzenie, czy mierzysz właściwe rzeczy i naprawiasz właściwe strony:

• Czytasz dane terenowe (CrUX), a nie tylko wynik laboratoryjny, dla metryk, na których opiera się Google.
• Patrzysz na liczby na poziomie strony, a nie tylko na średnią dla całego originu.
• Sprawdzane są wszystkie trzy: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 na poziomie p75.
• Wersja mobilna i desktopowa są analizowane osobno (Google ocenia każdą z nich).
• Nie optymalizujesz FID — został wycofany 12 marca 2024 r. (użyj INP).
• Raport Core Web Vitals w GSC jest sprawdzany pod kątem grup stron z problemami, a nie pojedynczych przypadków.
• Rozumiesz, że strony z małym ruchem mogą nie mieć żadnych danych terenowych CrUX.
• Narzędzia laboratoryjne (Lighthouse/PSI) służą do diagnozowania, a nie jako kryterium zaliczenia/niezaliczenia — i nie czekasz na idealny wynik Performance Score.
• Dajesz do 28 dni na pojawienie się poprawek w danych terenowych.
• Nie gonisz za CWV kosztem trafności treści i większych korzyści SEO.

Modele mentalne

1. Trzy wymiary, trzy metryki. LCP = ładowanie, INP = responsywność, CLS = stabilność wizualna. Jeśli potrafisz określić, w którym wymiarze leży problem, wiesz, którą metrykę (i które szczegółowe omówienie) otworzyć.

2. Dane terenowe służą do rankingu; laboratorium do napraw. Google rankuje na podstawie danych terenowych CrUX na poziomie p75 w ciągu 28 dni. Wyniki laboratoryjne Lighthouse/PSI znajdują przyczyny. Nigdy nie traktuj wyniku laboratoryjnego jako swojego numeru rankingowego — często nawet nie są ze sobą skorelowane.

3. Poziom strony przewyższa poziom originu. Origin, który „zalicza”, może ukrywać strony z problemami. Google używa danych na poziomie strony, gdy je ma. Gdy narzędzie pokazuje oba, ufaj widokowi na poziomie strony.

4. Używany, ale bez wagi. CWV to potwierdzony sygnał rankingowy, któremu Google nigdy nie przypisał oficjalnej wagi — trafność może go nadal przeważyć. Napraw CWV dla użytkowników i konwersji; nie oczekuj, że rankingi skoczą.

5. Test „czy to w ogóle Core?”. Tylko LCP, INP i CLS to Core Web Vitals. TTFB i FCP są diagnostyczne; TBT i Speed Index to proxy laboratoryjne. „Engagement Reliability” nie jest w ogóle potwierdzone.

Core Web Vitals — ściągawka

Trzy Core Web Vitals (dane terenowe, p75)

Metryki diagnostyczne — NIE są Core Web Vitals

Szybkie fakty

• Ocena = dane terenowe CrUX, 75. percentyl, 28-dniowe okno kroczące, mobilne i desktopowe osobno.
• INP zastąpił FID 12 marca 2024 r. FID jest całkowicie wycofany.
• Wyniki laboratoryjne (Lighthouse/PSI) są diagnostyczne, a nie pomiarami terenowymi — i często nie pokrywają się z terenowym CWV.
• Poziom strony jest tym, czego używa Google; średnie dla originu mogą mylić (~21,2 % stron zalicza vs ~33 % originów w moim badaniu CWV).
• Waga rankingowa: używane przez systemy rankingowe Google, bez oficjalnej wagi — trafność dominuje, a dobry wynik nie jest gwarancją.
• „Engagement Reliability” nie jest potwierdzonym Core Web Vital.

Który Core Web Vital powinienem zbadać najpierw?

Core Web Vitals pogarszają się po wydaniu

1. Potwierdź sygnał. Oddziel dane terenowe od laboratoryjnych, URL od origin oraz mobile od desktop. Jeśli zmienił się tylko jeden wynik laboratoryjny, powtórz test, zanim ogłosisz incydent.
2. Zidentyfikuj zawodny wskaźnik. LCP, INP i CLS oznaczają różne problemy. Jeśli zmieniło się kilka, najpierw sprawdź wspólne zmiany w wydaniu i skrypty stron trzecich.
3. Powiąż regresję z wdrożeniem. Porównaj dane RUM lub powtarzalne ślady laboratoryjne przed i po wydaniu. Jeśli czas nie pasuje, zamiast tego sprawdź mix ruchu i urządzeń.
4. Diagnozuj metrykę, a nie wynik. Dla LCP sprawdź element i podczęści; dla INP sprawdź wolne interakcje i pracę głównego wątku; dla CLS sprawdź źródła przesunięć.
5. Wdróż najmniejszą możliwą poprawkę. Natychmiast zweryfikuj ją w laboratorium. Jeśli łamie funkcjonalność lub pogarsza inny wskaźnik, wycofaj ją.
6. Obserwuj prawdziwych użytkowników. Użyj RUM jako wiodącego sygnału oraz CrUX/Search Console dla ciągłej oceny terenowej. Udokumentuj zakres i okno, aby interesariusze nie oczekiwali resetu CrUX tego samego dnia.

Błędy Core Web Vitals, które marnują pracę

Optymalizacja zagregowanego wyniku Lighthouse

Ocena terenowa Google wykorzystuje LCP, INP i CLS z danych rzeczywistych użytkowników, a nie pojedynczy wynik wydajności Lighthouse. Diagnozuj zawodną metrykę terenową i używaj Lighthouse jako jednego kontrolowanego środowiska debugowania.

Traktowanie Core Web Vitals jako skrótu do rankingu

CWV to sygnał doświadczenia strony, któremu Google nigdy nie przypisał oficjalnej wagi; istotność nadal dominuje. Napraw złe doświadczenie dla użytkowników, ale nie obiecuj skoku w rankingu ani nie wypieraj ważniejszej pracy nad treścią i indeksowaniem bez dowodów.

Mieszanie wartości URL, origin, mobile i desktop

Różne zakresy mogą opowiadać różne historie. Oznacz każdą wartość i nie twierdź, że strona przechodzi test, ponieważ fallback origin lub agregat desktop jest zielony.

Czekanie na CrUX przed sprawdzeniem wydania

Ruchome okno 28-dniowe jest zbyt wolne na QA wdrożenia. Zweryfikuj mechanizm w laboratorium i RUM natychmiast, a następnie użyj CrUX, aby potwierdzić dłuższy wynik terenowy.

Narzędzia do pomiaru Core Web Vitals

Sprawdź to za pomocą Core Web Vitals History & Competitor Comparison:

1. Dodaj witrynę (goły origin, np. example.com, ma najwięcej danych CrUX; dodaj do 5, aby porównać).
2. Wybierz mobile lub desktop, a następnie uruchom porównanie.
3. Przeczytaj kartę wyników dla dzisiejszego zaliczenia/niezaliczenia LCP, INP i CLS, a następnie tygodniowy wykres trendów, aby zobaczyć, czy każda metryka zbliża się do dobrego zakresu, czy się od niego oddala.

Dane terenowe — pomiar Core Web Vitals od rzeczywistych użytkowników

• PageSpeed Insights — dane terenowe CrUX na poziomie strony i origin, plus raport laboratoryjny Lighthouse obok.
• Google Search Console — raport Core Web Vitals — grupuje podobne strony i pokazuje wzorce terenowe w całej witrynie; najszybszy sposób na znalezienie grup niezaliczających stron.
• CrUX API / BigQuery — niestandardowe analizy i analizy na poziomie kraju bezpośrednio ze źródłowego zestawu danych.
• Biblioteka JavaScript web-vitals — zbieraj własne dane rzeczywistych użytkowników (RUM), np. przesyłaj je do analityki.

Dane laboratoryjne — do debugowania (nie do rankingu)

• Lighthouse — możliwości diagnostyczne i (nie rankingowy) wynik wydajności.
• Panel wydajności Chrome DevTools — debugowanie na poziomie śladów LCP, przesunięć układu i długich zadań.
• Sekcja laboratoryjna PageSpeed Insights — rekomendacje oparte na Lighthouse pod danymi terenowymi.

Zasada kciuka: GSC, aby znaleźć gdzie zawodzisz w terenie → PSI, aby potwierdzić na poziomie strony → Lighthouse / DevTools, aby diagnozować i iterować.

Zasoby warte Twojego czasu

Moje powiązane artykuły

• Core Web Vitals: jak je poprawić (Ahrefs) — mój pełny praktyczny przewodnik po trzech metrykach i tym, co naprawić.
• Badanie danych Core Web Vitals (Ahrefs) — CrUX + 5,2 mln stron; ustalenie dotyczące wskaźników zdawalności na poziomie strony i originu.
• Przewodnik po Largest Contentful Paint (LCP) (Ahrefs).
• Przewodnik po Cumulative Layout Shift (CLS) (Ahrefs).
• Przewodnik po PageSpeed Insights (Ahrefs).
• Przewodnik dla początkujących po technicznym SEO — gdzie doświadczenie strony wpisuje się w szerszy obraz.

Oficjalne

• web.dev — Web Vitals oraz artykuły o poszczególnych metrykach, do których linki znajdują się w sekcji Official Docs.
• Google aktualizuje dokumentację jakości strony, aby wyjaśnić sygnały rankingowe (Search Engine Land) — Barry Schwartz o zmianie w dokumentacji z marca 2024 r.

Z branży

• Core Web Vitals jako czynnik rankingowy Google: więcej niż rozstrzygnięcie (Search Engine Journal) — relacja z wypowiedzi Johna Muellera na Reddicie, że CWV to “more than a tie-breaker” (tłumaczenie) „więcej niż czynnik rozstrzygający”, ale nie zastępuje trafności.
• Priorytet Core Web Vitals dla małych i lokalnych firm (Search Engine Roundtable) — komentarz Muellera na Mastodonie, że praca nad CWV nie powinna być najwyższym priorytetem dla małych lub lokalnych firm.
• Potwierdzone: Core Web Vitals nie są dużym czynnikiem rankingowym (Stan Ventures) — cytat Muellera “not giant factors in ranking” (tłumaczenie) „nie są ogromnymi czynnikami rankingowymi” w kontekście.
• Wpływ Core Web Vitals na SEO (RUMvision) — zaktualizowane w listopadzie 2025 r.; dokładne podsumowanie w formacie FAQ z cytatami przedstawicieli Google i niuansami dotyczącymi sygnałów rankingowych.
• Aktualizacja jakości strony Google: czynnik rozstrzygający (Search Engine Roundtable) — wczesne ujęcie czynnika rozstrzygającego przez Muellera i Illyesa sprzed premiery aktualizacji.

Statystyki, które warto cytować

• Tylko ~21,2 % pojedynczych stron przechodzi wszystkie trzy Core Web Vitals — w porównaniu z ~33 % na poziomie origin — z mojego badania danych CWV (CrUX + 5,2 mln stron z Ahrefs Site Audit). Systemy Google zazwyczaj oceniają strony indywidualnie, więc różowa średnia na poziomie origin może wciąż ukrywać wiele stron, które nie przechodzą. Źródło
• Strony mają największe problemy z LCP. To badanie wykazało, że strony robią postępy w zakresie starego FID i CLS, ale pozostają w tyle pod względem LCP — oraz “almost no sites on 3G or slower connections are passing.” Źródło
• Progi “dobre”: LCP ≤2,5 s, INP ≤200 ms, CLS ≤0,1, każdy na 75. percentylu danych terenowych — udokumentowane cele Core Web Vitals od Google. Źródło
• INP zastąpił FID 12 marca 2024 r. — data, od której FID przestał być Core Web Vital i został usunięty z Search Console. Źródło

Sprawdź się: Core Web Vitals

Pięć szybkich pytań o Core Web Vitals. Wybierz odpowiedź na każde, a następnie sprawdź.

Udowodnij, że poprawka LCP/INP/CLS faktycznie zadziałała

Pułapka z poprawką wydajności polega na świętowaniu wyniku laboratoryjnego w dniu wdrożenia. Lab (Lighthouse) mówi ci, czy zmiana może zadziałać; tylko dane terenowe (CrUX) mówią ci, czy zadziałała dla prawdziwych użytkowników — a one przesuwają się z 28-dniowym opóźnieniem kroczącym. Uruchom oba, w tej kolejności.

Test 1 — Poprawka poprawiła metrykę laboratoryjną

• Test do przeprowadzenia — Przepuść stronę przez Core Web Vitals Checker (lub Lighthouse / PageSpeed Insights) przed i po zmianie.
• Oczekiwany wynik — Docelowy wskaźnik laboratoryjny przesuwa się we właściwym kierunku — np. element LCP renderuje się szybciej, brak nowego przesunięcia układu, konkretny diagnostyczny problem, który naprawiałeś, znika.
• Interpretacja niepowodzenia — Brak zmiany w laboratorium oznacza, że zmiana nie dotknęła ścieżki krytycznej (zoptymalizowałeś element, który nie był elementem LCP, lub skrypt, który nie blokował).
• Okno monitorowania — Natychmiastowe — testy laboratoryjne działają na żądanie.
• Wyzwalacz wycofania — Regresja w innym wskaźniku (naprawiłeś LCP, ale wprowadziłeś CLS, lub dodałeś JS, który pogorszył INP) — laboratorium łapie to zanim zrobią to prawdziwi użytkownicy.

Test 2 — Prawdziwi użytkownicy faktycznie to odczuwają (dane terenowe)

• Test do przeprowadzenia — Śledź p75 dla LCP, INP i CLS na stronie/originie w CrUX — Core Web Vitals History & Competitor Comparison lub raport Core Web Vitals w GSC.
• Oczekiwany wynik — p75 dla naprawionego wskaźnika przekracza próg “Dobry” i tam pozostaje (progi Google: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1).
• Interpretacja niepowodzenia — Laboratorium się poprawiło, ale pole nie — poprawka pomogła w teście na szybkim połączeniu, ale nie w rzeczywistej mieszance urządzeń/sieci, albo zbyt mało URL-i w grupie ma tę poprawkę.
• Okno monitorowania — 28-dniowe kroczące — CrUX to kroczące okno 28-dniowe, więc poprawka potrzebuje ~4 tygodni zgromadzonych danych terenowych, zanim p75 będzie wiarygodne. Nie oceniaj tego w pierwszym tygodniu.
• Wyzwalacz wycofania — p75 przekracza z powrotem próg “słaby”, lub liczba URL-i “Dobry” w GSC spada po zmianie szablonu — silny sygnał, że wdrożenie pogorszyło wydajność dla prawdziwych użytkowników.

Stały KPI dla tego tematu

Niezależnie od walidacji pojedynczej poprawki, to jest to, co obserwujesz kwartał po kwartale, aby wiedzieć, że wydajność strony jest zdrowa. Istnieje tu obronny benchmark — Google publikuje progi — więc żadne liczby nie są zmyślone.

p75 LCP, INP i CLS (dane terenowe)

• Wskaźnik — Wartość 75. percentyla każdego Core Web Vital przy rzeczywistych wizytach, na grupę stron i urządzenie.
• Co ci to mówi — Czy 75 % prawdziwych użytkowników ma dobre doświadczenie — dokładnie ten próg, którego Google używa do klasyfikacji URL-a jako przechodzącego. p75 (nie średnia) to liczba, która się liczy, ponieważ odzwierciedla wolniejszy długi ogon.
• Jak to pobrać — CrUX przez Core Web Vitals History & Competitor Comparison, raport Core Web Vitals w GSC (dane terenowe pogrupowane według wzorca URL), lub PageSpeed Insights dla pojedynczego URL-a.
• Benchmark / realistyczny zakres — Własne progi Google: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1 dla “Dobry”; pasma “Wymaga poprawy” / “Słaby” to 2,5–4 s / >4 s, 200–500ms /

  500ms, i 0,1–0,25 / >0,25. To są opublikowane linie, nie zmyślony cel.

• Częstotliwość — 28-dniowe kroczące, więc przeglądaj miesięcznie — codzienne sprawdzanie to tylko ponowne czytanie tego samego kroczącego okna. Traktuj wyniki laboratoryjne jako wskaźnik wyprzedzający, a CrUX p75 jako opóźniony.

Pokrycie “Dobrych URL-i” w całej witrynie

• Wskaźnik — Udział Twoich zindeksowanych URL-i w kategorii “Dobry” w raporcie Core Web Vitals w GSC (mobile i desktop śledzone osobno).
• Co ci to mówi — Jak szeroko poprawki się rozprzestrzeniły — pojedyncza szybka strona nie zmienia witryny; wygrane na poziomie szablonu tak.
• Jak to pobrać — GSC → raport Core Web Vitals → liczba URL-i Dobry / Wymaga poprawy / Słaby w czasie.
• Benchmark / realistyczny zakres — Zależny od sytuacji — zależy od Twoich szablonów i mieszanki ruchu, więc ustal własną bazę i zwiększaj udział Dobrych z czasem, zamiast gonić za zmyślonym procentem.
• Częstotliwość — Miesięcznie, lub tygodniowo tuż po zmianie szablonu/motywu, podczas gdy okno terenowe nadrabia zaległości.

Dziennik zmian