Core Web Vitals w 2026: aktualny zestaw wskaźników
Aktualny zestaw Core Web Vitals obejmuje LCP, INP i CLS. LCP mierzy wydajność ładowania głównej treści, INP responsywność interakcji, a CLS stabilność wizualną. Google opisuje je jako trzy podstawowe aspekty doświadczenia użytkownika mierzalne w warunkach rzeczywistych. [1][3]
FID nie jest już częścią Core Web Vitals. INP zastąpił FID w marcu 2024, a FID został później usunięty z narzędzi CrUX. W 2026 należy więc monitorować LCP, INP i CLS, a nie dawny zestaw z FID. [7][14]
Progi LCP, INP i CLS oraz 75. percentyl
| Wskaźnik | Dobry | Wymaga poprawy | Słaby | Co mierzy |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Szybkość wyświetlenia głównej treści |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Responsywność interakcji |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Stabilność wizualną |
Dobre wartości to LCP do 2,5 s, INP do 200 ms i CLS do 0,1. Zakres wymagający poprawy to odpowiednio 2,5 do 4,0 s, 200 do 500 ms i 0,1 do 0,25. Wyniki powyżej 4,0 s dla LCP, 500 ms dla INP i 0,25 dla CLS są klasyfikowane jako słabe. [3][4]
Ocena nie opiera się na średniej. Google używa 75. percentyla, co oznacza, że co najmniej 75% doświadczeń powinno osiągać dany próg lub lepszy wynik. Ocena jest rozdzielana między urządzenia mobilne i komputery. [3][4]
Aby strona spełniała Core Web Vitals, wszystkie trzy wskaźniki muszą osiągać dobry próg na 75. percentylu. Jeden słaby wskaźnik oznacza, że całość nie przechodzi oceny. [3]
Core Web Vitals a SEO: ważny sygnał, ale nie samodzielny ranking
Google potwierdza, że Core Web Vitals są używane przez systemy rankingowe jako część oceny doświadczenia strony. Jednocześnie dobre wyniki Core Web Vitals nie gwarantują wysokiej pozycji, ponieważ wyszukiwarka bierze pod uwagę wiele innych sygnałów, przede wszystkim trafność i jakość treści. [1][2]
Optymalizacja wydajności ma więc dwa cele: poprawę realnego doświadczenia użytkownika i usunięcie technicznej słabości mogącej wpływać na wyniki wyszukiwania. Nie należy traktować LCP, INP i CLS jako osobnego systemu punktowego oderwanego od jakości strony.
LCP: co dokładnie mierzy
Largest Contentful Paint mierzy czas od rozpoczęcia nawigacji do wyrenderowania największego obrazu, bloku tekstu lub innego kwalifikującego się elementu treści w widocznym obszarze. W danych terenowych LCP może obejmować również przekierowania, zestawienie połączenia i TTFB, dlatego wynik laboratoryjny może różnić się od doświadczenia użytkownika. [5]
Najczęstszym błędem jest założenie, że LCP to po prostu czas pobierania największego obrazu. Element LCP może być obrazem, tekstem albo innym kwalifikującym się elementem, a problem może powstać dużo wcześniej niż samo pobieranie zasobu. [5][6]
LCP w praktyce: rozbij wynik na cztery części
web.dev rozkłada LCP na cztery części: TTFB, resource load delay, resource load duration i element render delay. Razem tworzą pełny czas LCP. [6]
Jeżeli zasób LCP zostaje odkryty zbyt późno, samo zmniejszenie pliku może nie poprawić wyniku. Źródło LCP powinno być możliwie wcześnie widoczne w początkowym HTML, a obrazu LCP nie należy lazy-loadować. W razie potrzeby można użyć odpowiedniego priorytetu pobierania lub preload. [6]
Praktyczna kolejność diagnozy to: sprawdzić TTFB, sprawdzić kiedy przeglądarka odkrywa zasób LCP, zmierzyć czas jego transferu, a na końcu ustalić, co blokuje renderowanie po zakończeniu pobierania. [6]
- Zmniejsz TTFB przez cache, CDN, ograniczenie przekierowań i szybszy backend.
- Umieść zasób LCP w początkowym HTML, jeśli to możliwe.
- Nie używaj `loading="lazy"` dla obrazu LCP.
- Użyj odpowiedniego `fetchpriority` lub preload, gdy zasób jest odkrywany za późno.
- Optymalizuj rozmiar obrazu, format i dostarczanie, ale sprawdzaj, czy to faktyczny wąskie gardło.
- Usuń JavaScript lub CSS, które niepotrzebnie opóźniają pokazanie gotowego elementu.
INP: mierzy responsywność całej wizyty, nie tylko pierwsze kliknięcie
Interaction to Next Paint obserwuje opóźnienia kliknięć, dotknięć i interakcji klawiatury w całym okresie wizyty. Dla większości stron raportowana jest najwolniejsza interakcja. Przy dużej liczbie interakcji algorytm pomija jedną najgorszą interakcję na każde 50 interakcji, aby ograniczyć wpływ przypadkowych anomalii. [7]
INP nie jest tym samym co dawny FID. FID mierzył tylko opóźnienie wejścia pierwszej interakcji, natomiast INP obejmuje opóźnienie wejścia, wykonanie handlerów oraz opóźnienie do następnego paint. [7][8]
Jeżeli użytkownik nie kliknie, nie dotknie ani nie użyje klawiatury, dana wizyta może nie mieć wartości INP. Scroll i hover nie są interakcjami uwzględnianymi w INP. [7]
INP w praktyce: trzy miejsca, w których powstaje opóźnienie
Całkowity czas interakcji składa się z input delay, processing duration i presentation delay. Wolny INP może więc wynikać z zajętego głównego wątku przed handlerem, zbyt długiego kodu obsługującego zdarzenie albo kosztownego layoutu i renderowania przed następną klatką. [8]
Najbardziej użyteczne optymalizacje to skracanie długich zadań, dzielenie pracy, ograniczenie ciężkiego JavaScriptu, redukcja kosztownego layoutu, przenoszenie obliczeń do Web Workers tam, gdzie ma to sens, oraz szybkie pokazanie informacji zwrotnej użytkownikowi. [8]
W przypadku wysokiego INP warto zaczynać od danych RUM wskazujących konkretną interakcję, a dopiero później odtwarzać ją w DevTools. Sam wynik Lighthouse nie wskaże pełnego INP z realnej wizyty. [8][11][12]
CLS: stabilność układu przez cały okres życia strony
Cumulative Layout Shift mierzy nieoczekiwane przesunięcia widocznych elementów. Wynik opiera się na największym oknie sesji przesunięć, gdzie kolejne przesunięcia występują w odstępach krótszych niż 1 s, a całe okno trwa maksymalnie 5 s. [9]
CLS jest bezwymiarowy. Nie mierzy czasu, tylko wpływ i dystans nieoczekiwanych zmian położenia elementów. Przesunięcia będące bezpośrednią konsekwencją niektórych działań użytkownika mogą być wyłączone z oceny. [9]
W praktyce problem CLS często pojawia się po pierwszym załadowaniu, na przykład po wstrzyknięciu reklamy, banera, widgetu lub zmianie fontu. Dlatego test jednego cold load może nie pokazać pełnego problemu. [10][11]
CLS w praktyce: najczęstsze przyczyny i poprawki
web.dev wskazuje jako typowe źródła złego CLS obrazy bez wymiarów, reklamy, embedy i iframe bez zarezerwowanego miejsca, dynamicznie wstawiany content oraz web fonts. [10]
Najważniejszą zasadą jest rezerwowanie miejsca przed pojawieniem się elementu. Obrazy powinny mieć `width` i `height` lub stabilny `aspect-ratio`, sloty reklamowe i embedy przewidywalne wymiary, a nowe elementy nie powinny być wstawiane nad treścią, którą użytkownik już czyta. [10]
W przypadku fontów należy ograniczyć zmianę metryk tekstu i testować realny wpływ fallbacku. Sama zmiana `font-display` nie rozwiązuje automatycznie wszystkich przypadków CLS. [10]
Dane terenowe kontra laboratorium: nie mieszaj dwóch różnych pytań
Core Web Vitals są przede wszystkim metrykami terenowymi. CrUX i własny RUM pokazują, czego doświadczają prawdziwi użytkownicy na różnych urządzeniach i sieciach. Lighthouse jest narzędziem laboratoryjnym, które pomaga odtworzyć i diagnozować problemy w kontrolowanych warunkach. [11][12]
Lighthouse nie raportuje rzeczywistego INP z wizyty, ponieważ nie obserwuje naturalnych interakcji użytkownika. Zamiast tego używa między innymi Total Blocking Time jako laboratoryjnego wskaźnika pomocniczego. CLS w laboratorium także może być niższy, jeśli przesunięcia pojawiają się dopiero po późniejszych interakcjach. [11][12]
Dlatego decyzja, czy strona ma problem, powinna wynikać z danych terenowych. Laboratorium służy do znalezienia przyczyny i szybkiego testowania poprawek.
PageSpeed Insights, Search Console, DevTools i RUM: kiedy używać czego
| Narzędzie | Rodzaj danych | Najlepsze zastosowanie |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Szybka ocena URL-a i originu |
| Search Console | CrUX, grupy URL-i | Wyszukiwanie grup stron z problemami SEO |
| Chrome DevTools | Laboratorium + kontekst CrUX | Diagnoza LCP, INP i CLS krok po kroku |
| Lighthouse | Laboratorium | Automatyczne audyty i regresje w CI |
| RUM / web-vitals | Dane własnych użytkowników | Najdokładniejszy monitoring i diagnoza po wdrożeniu |
PageSpeed Insights łączy dane terenowe CrUX z diagnostyką Lighthouse. Search Console grupuje podobne URL-e i pomaga znaleźć typy stron, które nie przechodzą Core Web Vitals. Chrome DevTools pozwala analizować metryki na żywo i nagrywać szczegółowe ślady wydajności. [12][13]
CrUX API i PageSpeed Insights wykorzystują w praktyce ruchomy okres około 28 dni dla danych terenowych. Zmiana wdrożona dziś nie musi więc od razu zmienić publicznego wyniku p75. Własny RUM pozwala zobaczyć efekt znacznie szybciej i z większą ilością kontekstu. [12][13]
Dla zespołu produktowego najlepszy proces to RUM do monitoringu, Search Console do obserwacji SEO, PageSpeed Insights do szybkiej kontroli publicznych danych i DevTools do diagnozy konkretnego problemu.
CrUX w 2026: co mówią najnowsze dostępne dane
| Metryka | Odsetek originów z dobrym wynikiem, lipiec 2026 |
|---|---|
| LCP | 68,3% |
| INP | 85,7% |
| CLS | 81,6% |
| Wszystkie Core Web Vitals | 55,7% |
Najnowszy opublikowany przed 4 września 2026 miesięczny zestaw CrUX obejmuje lipiec 2026 i został opublikowany 11 sierpnia. Zawiera 18 059 068 originów. 68,3% originów miało dobry LCP, 81,6% dobry CLS, 85,7% dobry INP, a 55,7% spełniało wszystkie Core Web Vitals. [14]
To dane zagregowane dla webu reprezentowanego w CrUX, a nie cel dla konkretnej witryny. CrUX obejmuje tylko strony i originy spełniające kryteria kwalifikacji, między innymi publiczną dostępność i wystarczającą popularność. [13][14]
Brak danych CrUX dla małego lub nowego URL-a nie oznacza, że strona jest szybka albo wolna. Oznacza jedynie, że publiczny zbiór nie ma wystarczających danych do raportowania.
SPA i miękkie nawigacje: istotna zmiana w 2026
Klasyczne Core Web Vitals historycznie były mocno związane z pełnymi nawigacjami dokumentu, co utrudniało pomiar przejść wewnątrz aplikacji SPA. W 2026 Chrome 151 wprowadził nowe API umożliwiające pomiar Core Web Vitals dla soft navigations, a dokumentacja została zaktualizowana 2 września 2026. [15]
Chrome DevTools 152, wydany 25 sierpnia 2026, pokazuje Core Web Vitals dla miękkich nawigacji w widoku Live Metrics domyślnie, korzystając z `web-vitals` 6.0.0. [16]
To ważne dla React, Angular, Vue i innych SPA, ponieważ problemy z LCP, INP lub CLS mogą występować po przejściu klientowym, mimo że pierwsze pełne załadowanie wygląda dobrze. Nie należy jednak automatycznie zakładać, że wszystkie publiczne raporty CrUX już raportują te soft navigations w ten sam sposób.
Monitoring produkcyjny: mierz problem razem z kontekstem
Publiczny p75 mówi, że istnieje problem, ale często nie mówi, gdzie dokładnie powstaje. Własny RUM może wysyłać LCP element, podczęści LCP, identyfikator interakcji INP, typ zdarzenia, informacje o route, urządzeniu i wersji aplikacji. web.dev rekomenduje własny RUM jako uzupełnienie CrUX, szczególnie do diagnozy. [3][8][12]
Dobrą praktyką jest oznaczanie każdego wdrożenia wersją aplikacji i porównywanie rozkładów metryk przed oraz po zmianie. Średnia może ukrywać regresję u wolniejszych urządzeń, dlatego należy obserwować percentyle i segmenty ruchu.
CI powinno chronić przed oczywistymi regresjami laboratoryjnymi, ale nie może zastąpić monitoringu produkcji. Finalnym źródłem oceny Core Web Vitals pozostaje doświadczenie realnych użytkowników. [11][12]
Praktyczny plan poprawy Core Web Vitals
Najpierw ustal, który wskaźnik nie przechodzi p75 i na jakich typach stron. Następnie użyj RUM lub CrUX do zawężenia problemu, odtwórz go w DevTools, wprowadź najmniejszą zmianę rozwiązującą konkretną przyczynę i monitoruj efekt po wdrożeniu. [12]
Nie optymalizuj wszystkiego naraz. Dla LCP znajdź dominującą podczęść, dla INP najwolniejszą realną interakcję, a dla CLS konkretne przesunięcia i elementy, które je powodują.
Po poprawce sprawdź zarówno dane laboratoryjne, jak i terenowe. Publiczne dane CrUX potrzebują czasu na odzwierciedlenie nowej wersji, dlatego własny RUM jest szczególnie przydatny do szybkiego potwierdzenia, że regresja rzeczywiście zniknęła.
- Zidentyfikuj problem w danych terenowych, nie tylko w Lighthouse.
- Rozdziel mobile i desktop oraz grupy podobnych stron.
- Dla LCP analizuj TTFB, discovery zasobu, transfer i render delay.
- Dla INP znajdź konkretną wolną interakcję i jej input, processing oraz presentation delay.
- Dla CLS nagraj przesunięcia podczas całej sesji, nie tylko load.
- Wprowadź jedną mierzalną poprawkę i porównaj wynik przed oraz po wdrożeniu.
- Utrzymuj monitoring RUM i alerty regresji po wydaniu.
