Core Web Vitals 2026 – Google łączy wszystkie metryki w jeden wynik, który może zadecydować o Twoim rankingu

Przez ostatnie pięć lat zespoły techniczne miały komfort dzielenia problemu na trzy osobne fronty: szybkość ładowania (LCP), reakcja na klik (INP) i stabilność wizualna (CLS). Można było wygrać dwa fronty, przegrać jeden i wciąż utrzymać przyzwoity ranking. W 2026 roku ten komfort się skończył. Google ocenia teraz Core Web Vitals jako jeden zbiorczy wynik wydajności – strona przechodząca wszystkie trzy progi widzi silniejsze korzyści rankingowe niż wcześniej, a niepowodzenie nawet jednej metryki tworzy złożony, negatywny efekt.

Co dokładnie zmienił Google w ocenie Core Web Vitals i jak działa nowy model zbiorczy?

Core Web Vitals to trzy metryki, które Google wprowadził w 2020 roku jako oficjalny sygnał rankingowy mierzący jakość użytkowania strony:

• Largest Contentful Paint (LCP) mierzy szybkość ładowania – czas, w którym pojawia się największy widoczny element strony, najczęściej zdjęcie albo blok tekstu^[1]. Próg „dobry” to mniej niż 2,5 sekundy.
• Interaction to Next Paint (INP) mierzy szybkość reakcji strony na działania użytkownika – kliknięcia, dotyk, naciśnięcie klawisza^[2]. Próg „dobry” to mniej niż 200 milisekund.
• Cumulative Layout Shift (CLS) mierzy wizualną stabilność – jak bardzo elementy strony przesuwają się w trakcie ładowania, co denerwuje użytkownika klikającego w przycisk, który nagle skacze w bok^[3]. Próg „dobry” to mniej niż 0,1.

W 2026 roku Google zmienił sposób oceny tych metryk. Wcześniej każda była rozpatrywana osobno – strona mogła przejść dwie i nie przejść trzeciej, a algorytm rankingowy traktował ten wynik jako sumę trzech ocen. Od początku 2026 roku liczy się to, jak metryki współgrają ze sobą jako jeden zestaw^[4]. Strona, która przechodzi wszystkie trzy progi w 75. percentylu (czyli u 75 % prawdziwych użytkowników, mierzonych w zbiorze danych Chrome User Experience Report, w skrócie CrUX), widzi silniejszy efekt rankingowy niż wcześniej. Strona, która nie przechodzi nawet jednej metryki, dostaje złożony negatywny sygnał – nie ma już bezpieczeństwa „dwa z trzech wystarczą”.

Według niezależnych analiz na podstawie danych CrUX strony przechodzące wszystkie trzy progi mają o 24 % niższy wskaźnik odrzuceń niż strony przegrywające co najmniej jedną metrykę^[5]. W e-commerce ten sam efekt widać w konwersji – sklepy spełniające wszystkie trzy progi mają o 24 % wyższą konwersję niż konkurencja^[6]. Liderzy branży (Amazon, Zalando, ASOS) utrzymują medianę LCP poniżej 1,8 sekundy, CLS poniżej 0,04 i INP poniżej 150 milisekund – znacznie lepiej niż wymaga oficjalny próg „dobry”^[7].

Drugim ważnym zwrotem w 2026 roku jest dominacja INP jako metryki najtrudniejszej do spełnienia. 43 % wszystkich stron w skali globalnej nie przechodzi progu INP 200 milisekund^[8]. To metryka znacznie surowsza niż jej poprzednik First Input Delay (FID, czyli czas reakcji na pierwsze działanie użytkownika), który mierzył tylko pierwszą interakcję. INP ocenia wszystkie kliknięcia, dotknięcia i naciśnięcia klawisza w trakcie sesji, a do oceny bierze najgorszą z nich. Strona, która ma świetną pierwszą reakcję, ale później zatrzymuje się przy każdym kliknięciu formularza, w 2026 roku oblewa cały test.

W trzecim kwartale 2025 roku Google rozszerzył też zakres samego pomiaru. Jak zauważyli analitycy z Mewa Studio, w 2026 roku obok klasycznego CLS, mierzącego skoki podczas ładowania, pojawił się Visual Stability Index – wskaźnik mierzący stabilność wizualną także po pełnym załadowaniu strony^[9]. Wcześniej element, który skoczył dwie sekundy po załadowaniu strony, nie wpływał na ocenę. Teraz takie późne przesunięcia także są karane, zwłaszcza jeśli wpływają na elementy interaktywne (przyciski, formularze, linki).

Ponad 60 % wszystkich wyszukiwań w Google odbywa się dziś na telefonach^[10], a Google używa pomiarów mobilnych jako głównego sygnału rankingowego nawet dla wyników wyszukiwania wyświetlanych na komputerze. To ma konkretną konsekwencję: strona, która działa świetnie na MacBooku z szybkim internetem, ale wolno na średniej klasy Androidzie z 4G, w 2026 roku traci pozycje – bo to ten drugi pomiar liczy się dla algorytmu rankingowego. 53 % użytkowników mobilnych opuszcza stronę, która ładuje się dłużej niż trzy sekundy^[11]. Połowa potencjalnych odbiorców znika, zanim zobaczy treść.

Ocena Core Web Vitals nie jest już ograniczona do klasycznego rankingu. Wyniki wydajności wpływają teraz także na widoczność strony w odpowiedziach AI Overviews, ChatGPT Search, Perplexity i innych systemów generatywnych^[12]. Modele AI preferują strony, które dobrze działają, bo szybko otrzymują od nich potrzebne informacje – wolne strony oznaczają dłuższy czas indeksowania i niższą pewność co do wiarygodności danych. Według dostępnych analiz strony z LCP poniżej 0,4 sekundy zdobywają średnio 6,7 cytowania w odpowiedziach AI, a strony wolniejsze (powyżej 1,13 sekundy) – tylko 2,1 cytowania. Wydajność z dyscypliny stricte SEO awansuje do roli sygnału, którego znaczenie wykracza poza klasyczne wyniki wyszukiwania.

Warto też wspomnieć o tym, czego nowy model nie zmienił. Próg „dobry” dla każdej metryki pozostał ten sam co w 2024 roku – LCP poniżej 2,5 sekundy, INP poniżej 200 milisekund, CLS poniżej 0,1^[13]. Google nie podniósł progu, tylko zmienił sposób łączenia wyników w jeden zbiorczy sygnał rankingowy. Dla zespołów technicznych to ułatwienie i utrudnienie jednocześnie. Ułatwienie, bo można skupić się na osiągnięciu jednego celu – przejścia wszystkich trzech progów. Utrudnienie, bo nie ma już „lekkich punktów zaliczeniowych” za przejście tylko dwóch z trzech.

Co ta zmiana oznacza dla zespołów technicznych i jak ułożyć priorytety w 2026 roku?

Optymalizacja Core Web Vitals musi być ciągła, co oznacza, że każda nowa funkcja, każdy zewnętrzny skrypt, każdy nowy element designu może popsuć któryś z trzech progów. W modelu zbiorczym taki regres ma silniejszy negatywny efekt niż wcześniej – jedna metryka, która spadnie poniżej progu, podważa całość. Zalecenie pragmatyczne: każdy zespół deweloperski powinien mieć ustalone wewnętrzne progi alarmowe na poziomie 80 % wartości Google’a (INP poniżej 160 ms, LCP poniżej 2,0 s, CLS poniżej 0,08), a nie minimum oficjalnych progów. Bufor 20 % chroni przed wpadnięciem w „needs improvement” przy każdym wahaniu.

INP jest dziś najtrudniejszą do spełnienia metryką – tu wymagana jest najgłębsza zmiana w architekturze JavaScriptu. Trzy najmocniejsze działania to dzielenie długich zadań JavaScript na mniejsze kawałki, odraczanie nieistotnego kodu (analityka, banery cookie, widgety mediów społecznościowych) do momentu po załadowaniu strony oraz redukcja złożoności drzewa DOM (czyli struktury elementów HTML, którą przeglądarka musi przeanalizować). Każdy zewnętrzny skrypt, który blokuje wątek główny przeglądarki, jest dziś bezpośrednim zagrożeniem dla rankingu.

LCP wymaga z kolei zmian na poziomie infrastruktury. Trzy najmocniejsze działania to:

• wprowadzenie sieci CDN (Content Delivery Network, czyli rozproszonej sieci serwerów, które dostarczają treści z lokalizacji najbliższej użytkownikowi),
• preload głównego zdjęcia hero (czyli największego widocznego obrazu w górnej części strony),
• wbudowywanie krytycznego CSS, czyli umieszczenie najważniejszych stylów bezpośrednio w HTML zamiast ładowania ich z osobnego pliku.

Częsty błąd to lazy loading głównego zdjęcia – zamiast przyspieszyć stronę, opóźnia ten konkretny element o pół sekundy lub więcej i niszczy LCP.

CLS to metryka z najprostszymi rozwiązaniami, ale najczęściej zaniedbywana. Każdy obraz, każdy film, każdy iframe na stronie powinien mieć określoną szerokość i wysokość w HTML – bez tego przeglądarka rezerwuje przestrzeń dopiero w momencie załadowania elementu, co powoduje przesunięcie reszty treści. Drugi częsty winowajca to banery zgody na cookies, które wpychają się na górę strony i pchają wszystko w dół. Banery powinny być zatem umieszczone w warstwie „nad” treścią (overlay), a nie wpychane do struktury DOM.

Optymalizacja Core Web Vitals przekłada się bezpośrednio na przychody. Analiza Webgaro pokazuje, że poprawa LCP z 4,1 sekundy do 2,2 sekundy wygenerowała w jednym przypadku spadek wskaźnika odrzuceń o 18 %, wzrost ruchu organicznego o 28 % i wzrost przychodów o 15 %^[14]. To są liczby, które uzasadniają konkretną inwestycję w wydajność – nie jako koszt techniczny, lecz jako działanie zwracające się w przychodach. Każdy dyrektor finansowy powinien dostać raport zestawiający aktualny stan Core Web Vitals z potencjalnym wzrostem przychodu po optymalizacji.

Wolny serwer współdzielony (czyli taki, na którym setki stron dzielą tę samą maszynę) praktycznie uniemożliwia przejście LCP poniżej 2,5 sekundy^[15]. Jeśli czas odpowiedzi serwera (TTFB – Time to First Byte, czyli moment, w którym przeglądarka dostaje pierwszą odpowiedź od serwera) przekracza 600 milisekund, nawet doskonała optymalizacja kodu nie zbawi strony. Polskie agencje wciąż często rekomendują tani hosting dla mniejszych klientów, ale w 2026 roku to wybór, który kosztuje pozycje w rankingu. Zatem dla każdej strony, na której Core Web Vitals mają znaczenie biznesowe (e-commerce, wydawca treści, SaaS, B2B), warto rozważyć managed WordPress, VPS lub hosting w chmurze. Różnica miesięczna 50–200 zł zwraca się zwykle przez kilka pierwszych konwersji z poprawionych rankingów.

Strony oparte na frameworkach typu React czy Vue w wersji domyślnej (czyli z renderowaniem po stronie przeglądarki, tzw. client-side rendering) mają strukturalny problem z INP i LCP. Każde kliknięcie wymaga uruchomienia JavaScriptu, każde załadowanie strony wymaga oczekiwania na pobranie i wykonanie kodu. Rozwiązaniem są nowoczesne meta-frameworki, takie jak Next.js, Nuxt czy Astro, które domyślnie renderują treść po stronie serwera (server-side rendering) albo generują statyczne strony przy każdej publikacji (static generation). Strony generowane statycznie mają niemal zerowy TTFB i automatycznie dobry LCP – co jest dziś poważnym argumentem za przebudową technologii.

Optymalizacja Core Web Vitals wymaga współpracy zespołów, które historycznie pracowały osobno: SEO, frontend, backend, design, marketing. SEO mówi, że LCP musi spaść poniżej 2 sekund. Design mówi, że hero image musi być pełnoekranowy z animacją. Frontend mówi, że framework jest sztywny. Marketing mówi, że nie wolno wyrzucić banera cookie. W 2026 roku zespoły muszą siadać razem do rozmowy, w której rozstrzyga się, czego nie da się obejść. To zwykle kompromis – mniejsze hero image, baner cookie jako overlay, lżejszy framework – ale bez dialogu każda kampania optymalizacyjna kończy się tym, że jeden zespół nadrabia, a drugi pogarsza wyniki.

Połączenie Core Web Vitals w jeden zbiorczy wynik to sygnał, że Google traktuje wydajność strony nie jako pomniejszą metrykę, lecz jako fundament jakości witryny. Marki, które do końca 2026 roku nie przejdą trzech progów u 75 % użytkowników, w 2027 roku zaczną tracić pozycje na rzecz konkurentów, dla których wydajność jest stałą dyscypliną.