Core Web Vitals w 2026 — co naprawdę warto poprawić?

WYDAJNOŚĆ STRONY

Core Web Vitals warto poprawiać wtedy, gdy pokazują realny problem użytkowników: główna treść ładuje się zbyt długo, strona reaguje z opóźnieniem albo elementy przesuwają się w trakcie korzystania. Nie warto natomiast przebudowywać pół serwisu tylko po to, aby PageSpeed Insights zmienił wynik z 93 na 100.

W praktyce najważniejsza jest kolejność: najpierw dane realnych użytkowników, potem konkretna metryka, następnie przyczyna problemu i dopiero na końcu optymalizacja.

Krótka odpowiedź

W 2026 roku Google używa trzech podstawowych wskaźników Core Web Vitals: LCP, INP i CLS. Dobry wynik to odpowiednio LCP do 2,5 s, INP do 200 ms i CLS do 0,1. Ocena nie powstaje na podstawie jednego testu na naszym komputerze, lecz w oparciu o doświadczenia realnych użytkowników, oceniane na 75. percentylu.

Jeżeli strona nie przechodzi Core Web Vitals, warto poprawić przyczynę problemu. Jeżeli przechodzi wszystkie trzy wskaźniki, a użytkownicy nie odczuwają problemów, dalsze polowanie na perfekcyjne 100/100 zwykle ma niższy priorytet niż treść, UX, konwersja czy rozwój ważnych podstron.

Czym są Core Web Vitals?

Core Web Vitals to zestaw metryk, które Google wykorzystuje do oceny wybranych elementów doświadczenia użytkownika związanych z wydajnością strony.

W 2026 roku są trzy:

Wskaźnik	Co mierzy	Dobry wynik
LCP — Largest Contentful Paint	jak szybko pojawia się główna treść strony	≤ 2,5 s
INP — Interaction to Next Paint	jak szybko strona reaguje na działania użytkownika	≤ 200 ms
CLS — Cumulative Layout Shift	czy elementy strony nie przesuwają się niespodziewanie	≤ 0,1

Warto zauważyć jedną rzecz: Core Web Vitals nie mierzą całej jakości strony.

Nie powiedzą, czy oferta jest zrozumiała, czy formularz ma sens, czy użytkownik znajduje odpowiednią usługę ani czy treść odpowiada na jego pytanie. Są ważnym fragmentem jakości serwisu, ale nie zastępują UX, treści ani SEO.

Czy Core Web Vitals wpływają na SEO?

Tak. Google potwierdza, że Core Web Vitals są wykorzystywane przez jego systemy rankingowe.

Nie oznacza to jednak, że strona z wynikiem 100 w PageSpeed automatycznie wyprzedzi stronę z wynikiem 85. Google nadal stara się pokazywać przede wszystkim najbardziej trafną i pomocną treść.

Dlatego właściwe podejście brzmi:

osiągnąć dobrą jakość techniczną, usunąć realne problemy użytkowników i nie traktować wyniku narzędzia jako celu biznesowego samego w sobie.

To ważne, bo optymalizacja potrafi pochłonąć wiele godzin. Jeżeli wszystkie Core Web Vitals są już w zielonym zakresie, kolejne godziny pracy mogą przynieść mniejszy efekt niż poprawa strony usługi, formularza, treści albo wersji mobilnej.

Najpierw sprawdź, jakie dane właściwie oglądasz

To jeden z najczęściej pomijanych elementów PageSpeed Insights.

Po wpisaniu adresu strony możemy zobaczyć dwa różne rodzaje danych.

Dane realnych użytkowników — CrUX

Sekcja dotycząca rzeczywistych użytkowników opiera się na danych Chrome UX Report, czyli CrUX.

Pokazuje, jak strona zachowywała się w prawdziwych warunkach: na różnych urządzeniach, połączeniach i podczas realnych wizyt.

To właśnie te dane są najważniejsze przy ocenie Core Web Vitals.

Test laboratoryjny — Lighthouse

Niżej PageSpeed Insights wykonuje kontrolowany test laboratoryjny.

Jest bardzo przydatny do diagnozy, bo może wskazać między innymi:

ciężkie obrazy
blokujące zasoby CSS i JavaScript
długie zadania JavaScript
problemy z cache
nadmiar kodu
element odpowiedzialny za LCP

Ale jeden test Lighthouse nie opisuje doświadczenia wszystkich użytkowników.

Co jeśli wyniki są różne?

To normalne.

Możesz zobaczyć na przykład:

dobre dane CrUX, ale słabszy test laboratoryjny
dobry test Lighthouse, ale problem w danych realnych użytkowników

W pierwszym przypadku nie ma sensu panikować z powodu jednego słabszego testu. W drugim nie należy ignorować problemu tylko dlatego, że na szybkim komputerze strona osiąga 95 punktów.

Dane terenowe mówią, co dzieje się użytkownikom. Test laboratoryjny pomaga ustalić dlaczego.

Dlaczego Google używa 75. percentyla?

Core Web Vitals nie są oceniane na podstawie średniej ani najlepszego wyniku.

Google patrzy na 75. percentyl doświadczeń. W dużym uproszczeniu oznacza to, że strona powinna zapewniać dobry wynik co najmniej dla zdecydowanej większości wizyt, a nie tylko dla użytkowników z szybkim internetem i nowym telefonem.

To ma praktyczny sens.

Jeżeli właściciel strony testuje ją na światłowodzie i nowym laptopie, może mieć wrażenie, że wszystko działa świetnie. Klient korzystający z telefonu w sieci komórkowej może doświadczać zupełnie innej strony.

Dlatego w FreenetPro przy ocenie wydajności patrzymy szczególnie na mobile i realne dane, a nie tylko na pojedynczy screenshot z wynikiem PageSpeed.

Co poprawiać najpierw?

Nie każda rekomendacja z PageSpeed ma taki sam priorytet.

Najpierw sprawdzamy:

czy strona przechodzi Core Web Vitals w danych realnych użytkowników
która z trzech metryk jest problemem
czy problem dotyczy konkretnego URL-a, grupy stron czy całego serwisu
czy problem jest widoczny przede wszystkim na mobile
co jest jego realną przyczyną

Dopiero wtedy zaczynamy optymalizację.

LCP — gdy główna treść pojawia się zbyt późno

Largest Contentful Paint mierzy czas, po którym użytkownik widzi największy istotny element znajdujący się w pierwszym widoku strony.

Często jest to:

zdjęcie hero
duża grafika
banner
duży blok tekstu
element z obrazem tła

Dobry wynik LCP to maksymalnie 2,5 sekundy.

Co najczęściej psuje LCP?

W praktyce warto zacząć od sprawdzenia kilku rzeczy.

Zbyt ciężki obraz hero

Duże zdjęcie może ważyć kilka megabajtów, mimo że na ekranie jest wyświetlane w znacznie mniejszym rozmiarze.

Najpierw warto sprawdzić:

rzeczywisty rozmiar obrazu
format pliku
kompresję
czy przeglądarka pobiera właściwy rozmiar dla danego ekranu

WebP lub AVIF może pomóc, ale sam format nie naprawi obrazu, który ma niepotrzebnie 4000 px szerokości.

Lazy loading na najważniejszym obrazie

Lazy loading jest bardzo przydatny dla grafik znajdujących się niżej na stronie.

Jeżeli jednak obraz będący LCP znajduje się w hero, opóźnianie jego pobrania może pogorszyć wynik zamiast go poprawić.

To dobry przykład, dlaczego nie warto stosować jednej „optymalizacji” automatycznie do wszystkich obrazów.

Wolna odpowiedź serwera

Jeżeli HTML zaczyna docierać zbyt późno, przeglądarka później dowiaduje się również o obrazie, CSS i innych zasobach.

W WordPressie problem może wynikać między innymi z:

słabego hostingu
ciężkich zapytań
zbyt wielu operacji wykonywanych przy każdym wejściu
problemów z cache
rozbudowanego zestawu wtyczek

Zasoby blokujące renderowanie

Duża ilość CSS, JavaScript albo fontów ładowanych przed pierwszym renderem może opóźnić wyświetlenie najważniejszego elementu.

Tu jednak również trzeba zachować rozsądek. Nie chodzi o usunięcie każdego pliku CSS, ale o sprawdzenie, co naprawdę blokuje pierwszy widok.

INP — gdy klikasz i nic się nie dzieje

Interaction to Next Paint mierzy responsywność strony podczas interakcji użytkownika.

Przykłady:

kliknięcie menu
otwarcie akordeonu
wybranie wariantu produktu
użycie filtra
kliknięcie przycisku
wpisywanie danych w bardziej rozbudowanym interfejsie

Dobry INP to maksymalnie 200 ms.

Co najczęściej pogarsza INP?

Najczęściej problemem jest JavaScript, który zajmuje główny wątek przeglądarki w momencie, gdy użytkownik próbuje coś zrobić.

Warto sprawdzić:

długie zadania JavaScript
ciężkie skrypty zewnętrzne
niepotrzebne biblioteki
kilka skryptów realizujących podobne funkcje
duże operacje wykonywane po każdym kliknięciu
bardzo rozbudowany DOM
widgety marketingowe i trackingowe

Dlaczego INP jest ważny biznesowo?

Bo użytkownik nie zna pojęcia INP. On po prostu czuje, że strona „muli”.

Jeżeli menu otwiera się z opóźnieniem, filtr w sklepie reaguje po chwili albo przycisk wydaje się martwy, użytkownik może kliknąć drugi raz, zrezygnować albo uznać, że serwis jest zepsuty.

Dlatego poprawa INP nie jest tylko technicznym zadaniem pod Google. Może bezpośrednio poprawić komfort korzystania ze strony.

CLS — gdy strona skacze podczas ładowania

Cumulative Layout Shift mierzy nieoczekiwane przesunięcia elementów na stronie.

Dobry wynik CLS to maksymalnie 0,1.

Najbardziej irytujący przykład wygląda tak: użytkownik chce kliknąć przycisk, ale w ostatniej chwili nad nim pojawia się obraz lub banner i przycisk przesuwa się niżej.

Typowe przyczyny CLS

Obrazy bez zarezerwowanego miejsca

Jeżeli przeglądarka nie zna proporcji obrazu przed jego pobraniem, po załadowaniu grafiki może przesunąć treść.

Dlatego warto podawać właściwe wymiary lub proporcje elementu.

Elementy dokładane nad istniejącą treścią

Cookie bar, reklama, komunikat, formularz lub banner pojawiający się po chwili może przepchnąć całą stronę.

Jeżeli taki element jest potrzebny, warto zaplanować jego zachowanie tak, aby nie powodował nagłego przesunięcia głównej treści.

Fonty

Zmiana fontu po jego pobraniu może zmienić szerokość tekstu i wysokość linii.

Problem jest szczególnie widoczny przy dużych nagłówkach, gdzie inna metryka fontu może przesunąć kilka kolejnych elementów.

Czy wynik 100/100 w PageSpeed Insights jest potrzebny?

Nie.

To jedna z najważniejszych rzeczy, które warto wiedzieć przed optymalizacją strony.

Google sam zaznacza, że pogoń za perfekcyjnym wynikiem tylko z powodów SEO może nie być najlepszym wykorzystaniem czasu.

Co jest lepszym celem?

Zamiast pytać:

„Jak dojść do 100?”

lepiej zapytać:

„Czy realni użytkownicy mają problem i która poprawka da im największą różnicę?”

Jeżeli:

Core Web Vitals są dobre
strona szybko pokazuje najważniejszą treść
interakcje są płynne
layout nie skacze
mobile działa dobrze

wynik 92 zamiast 100 sam w sobie nie jest problemem biznesowym.

Kiedy warto walczyć dalej?

Dalsza optymalizacja może mieć sens, jeśli:

kluczowa strona sprzedażowa jest blisko granicy „poor”
mobile wyraźnie odstaje od desktopu
nowe skrypty stopniowo pogarszają wydajność
serwis ma duży ruch i nawet niewielka poprawa może dotyczyć wielu użytkowników
problemy wpływają również na konwersję

Najczęstszy błąd: optymalizacja wyniku zamiast strony

Można poprawić liczbę w narzędziu, a jednocześnie pogorszyć stronę.

Przykłady:

usunięcie ważnych funkcji tylko po to, aby zmniejszyć JavaScript
agresywne opóźnianie skryptów, przez które formularz działa zbyt późno
lazy loading obrazu hero
ukrywanie elementów podczas testu
preloadowanie zbyt wielu zasobów naraz
instalowanie kilku wtyczek „speed optimization”, które zaczynają ze sobą konkurować

Wydajność powinna być częścią architektury strony, a nie konkursem na wynik testu.

WordPress i Core Web Vitals — co zwykle ma największy wpływ?

W WordPressie problemem rzadko jest sam WordPress. Najczęściej liczy się sposób, w jaki strona została zbudowana.

Największy wpływ mogą mieć:

ciężki motyw
rozbudowany page builder
duża liczba wtyczek
nieoptymalne zdjęcia
fonty z wielu źródeł
skrypty reklamowe i analityczne
popupy i widgety
brak rozsądnego cache
wolny hosting
niepotrzebny JavaScript na każdej podstronie

Czy wystarczy zainstalować wtyczkę do cache?

Czasem pomoże, ale nie naprawi każdej przyczyny.

Cache może skrócić część procesu generowania i dostarczania strony, ale nie usunie automatycznie ciężkiego interfejsu, 4 MB obrazów, kilku systemów sliderów czy nadmiarowego JavaScriptu.

W FreenetPro staramy się zaczynać od źródła problemu. Jeżeli strona ma zbyt dużo kodu, lepszym rozwiązaniem jest usunięcie zbędnego kodu niż dokładanie kolejnej warstwy, która próbuje go „optymalizować”.

Co z animacjami?

Animacja nie jest automatycznie problemem.

Dobrze wykonany ruch może poprawić odbiór strony i pomóc użytkownikowi zrozumieć interfejs.

Problem zaczyna się, gdy animacja:

blokuje interakcję
wymaga ciężkiej biblioteki dla prostego efektu
działa stale mimo braku potrzeby
powoduje przesunięcia layoutu
mocno obciąża słabsze urządzenia
opóźnia główną treść

Dlatego pytanie nie brzmi „czy wolno mieć animacje?”, tylko „czy ten efekt jest wart swojego kosztu?”.

Co z Google Tag Manager, analityką i chatem?

Skrypty zewnętrzne często mają duży udział w obciążeniu strony, ale nie można usuwać ich bez zrozumienia celu biznesowego.

Przed wyłączeniem czegokolwiek warto sprawdzić:

czy dany tag jest nadal potrzebny
czy nie ma duplikatów
czy uruchamia się na właściwych podstronach
czy musi ładować się natychmiast
czy widget jest faktycznie używany przez klientów

Dobrze skonfigurowany pomiar jest potrzebny. Dziesięć starych tagów, których nikt już nie analizuje, nie jest.

Jak sprawdzić Core Web Vitals krok po kroku?

1. Search Console

Zacznij od raportu Core Web Vitals w Google Search Console.

Pozwala zobaczyć, czy Google grupuje adresy jako:

dobre
wymagające poprawy
słabe

To dobry punkt startowy do znalezienia problematycznych typów stron.

2. PageSpeed Insights

Sprawdź kilka reprezentatywnych adresów, nie tylko homepage.

Dla strony firmowej mogą to być:

strona główna
główna usługa
artykuł
case study
kontakt

Dla sklepu dodatkowo:

kategoria
produkt
koszyk
checkout

3. Najpierw mobile

Jeżeli większość klientów korzysta z telefonu, desktop nie może być jedynym punktem odniesienia.

Strona może działać świetnie na laptopie, a mieć problem na słabszym smartfonie.

4. Znajdź konkretną metrykę

Nie poprawiaj wszystkiego naraz.

Jeżeli problemem jest CLS, optymalizacja serwera może niewiele zmienić. Jeżeli problemem jest INP, kompresowanie hero może nie rozwiązać przyczyny.

5. Ustal element lub kod odpowiedzialny za problem

Dopiero teraz używamy diagnostyki Lighthouse i DevTools, aby znaleźć konkretną przyczynę.

6. Wprowadź zmianę i sprawdź, czy nie powstał nowy problem

Optymalizacja jednego wskaźnika nie powinna psuć UX, funkcji ani innej metryki.

7. Poczekaj na nowe dane terenowe

Dane realnych użytkowników nie zmieniają się natychmiast po wdrożeniu poprawki. PageSpeed Insights pokazuje CrUX obejmujący okres ostatnich 28 dni, więc efekty w danych terenowych pojawiają się stopniowo.

Co naprawdę warto poprawić — priorytety

Jeżeli mamy ograniczony czas lub budżet, kolejność może wyglądać tak:

Priorytet 1 — problem odczuwalny przez użytkownika

Na przykład:

hero pojawia się po kilku sekundach
menu reaguje z wyraźnym opóźnieniem
checkout zacina się
strona skacze podczas ładowania

Priorytet 2 — słabe Core Web Vitals w danych terenowych

Szczególnie na ważnych podstronach i mobile.

Priorytet 3 — problem powtarzalny na całym typie stron

Naprawa jednego komponentu może poprawić kilkadziesiąt lub kilkaset URL-i naraz.

Priorytet 4 — element wpływający również na konwersję

Przykładowo wolny wybór wariantu produktu ma większy priorytet niż drobna uwaga Lighthouse dotycząca podstrony, której prawie nikt nie odwiedza.

Priorytet 5 — dalsza kosmetyczna optymalizacja

Dopiero na końcu warto zajmować się rzeczami, które poprawiają głównie wynik narzędzia, ale nie rozwiązują istotnego problemu użytkownika.

Core Web Vitals podczas tworzenia nowej strony

Najłatwiej optymalizować wydajność wtedy, gdy myślimy o niej od początku.

W projekcie warto od razu ustalić:

rozsądny rozmiar hero
sposób ładowania fontów
strategię obrazów responsive
które skrypty są naprawdę potrzebne
jak będą działać animacje
ile zewnętrznych narzędzi trafia na stronę
jak działa mobile
które elementy mają być interaktywne

To zwykle tańsze niż budowa ciężkiego serwisu, a później próba „ratowania PageSpeed” zestawem kolejnych optymalizatorów.

W naszych projektach preferujemy możliwie lekką implementację i ograniczanie zależności wtedy, gdy nie dają użytkownikowi realnej wartości. Nie oznacza to rezygnacji z designu czy interakcji. Chodzi o to, aby każdy cięższy element miał konkretny powód, dla którego znajduje się na stronie.

Czy szybka strona zawsze sprzedaje lepiej?

Nie można obiecać, że poprawa LCP o pół sekundy automatycznie zwiększy sprzedaż o konkretny procent.

Wydajność jest jednym z elementów całego doświadczenia.

Szybka strona może nadal nie sprzedawać, jeśli:

oferta jest niejasna
użytkownik nie ufa firmie
checkout jest zbyt skomplikowany
formularz nie działa
ceny lub warunki są niezrozumiałe
treść nie odpowiada na pytania klienta

Ale wolna i niestabilna strona może przeszkadzać nawet wtedy, gdy reszta została dobrze zaprojektowana.

Dlatego najlepszy efekt daje połączenie wydajności, UX, treści i właściwej architektury strony.

Checklista Core Web Vitals

Przed rozpoczęciem większej optymalizacji sprawdź:

☐ Czy patrzę na dane realnych użytkowników, czy tylko Lighthouse?
☐ Czy problem występuje na mobile?
☐ Czy wiem, która metryka nie przechodzi?
☐ Czy znam konkretny element odpowiedzialny za LCP?
☐ Czy JavaScript blokuje interakcje?
☐ Czy obrazy i inne media mają zarezerwowane miejsce?
☐ Czy skrypty zewnętrzne są naprawdę potrzebne?
☐ Czy nie instaluję kolejnej wtyczki zamiast usunąć przyczynę?
☐ Czy poprawka nie psuje UX lub funkcji strony?
☐ Czy testuję więcej niż samą stronę główną?
☐ Czy po wdrożeniu monitoruję dane przez kolejne tygodnie?

Z praktyki FreenetPro

Najczęstszy problem nie polega na tym, że właściciel strony „nie zna Core Web Vitals”. Problem polega na tym, że narzędzie pokazuje kilkadziesiąt technicznych uwag i trudno ustalić, które z nich są naprawdę ważne.

Dlatego zaczynamy od wpływu na użytkownika i od przyczyny.

Jeżeli LCP psuje jeden źle przygotowany obraz, poprawiamy obraz. Jeżeli INP wynika z nadmiaru JavaScriptu, szukamy zbędnego kodu. Jeżeli cały serwis jest zbudowany z wielu ciężkich zależności i każda kolejna poprawka tworzy nowy konflikt, wtedy trzeba ocenić, czy problem nie jest architektoniczny.

Nie chodzi o to, aby strona wyglądała świetnie w raporcie. Ma działać szybko i stabilnie dla ludzi, którzy naprawdę z niej korzystają.

FAQ

Jakie są Core Web Vitals w 2026 roku?

Aktualne Core Web Vitals to LCP, INP i CLS. LCP mierzy szybkość pokazania głównej treści, INP responsywność podczas interakcji, a CLS stabilność układu strony.

Jaki wynik LCP jest dobry?

Google uznaje LCP do 2,5 sekundy za dobry. Wynik między 2,5 a 4 sekundami wymaga poprawy, a powyżej 4 sekund jest klasyfikowany jako słaby.

Jaki wynik INP jest dobry?

Dobry INP to maksymalnie 200 ms. Wartości powyżej 500 ms są klasyfikowane jako słabe.

Jaki wynik CLS jest dobry?

Dobry CLS to maksymalnie 0,1. Wartości powyżej 0,25 są uznawane za słabe.

Czy PageSpeed 100/100 poprawi pozycję w Google?

Nie ma takiej gwarancji. Core Web Vitals są używane przez systemy rankingowe Google, ale pozycja zależy od wielu czynników, przede wszystkim trafności i jakości treści. Google samo wskazuje, że pogoń za perfekcyjnym wynikiem wyłącznie dla SEO może nie być najlepszym wykorzystaniem czasu.

Dlaczego PageSpeed za każdym razem pokazuje inny wynik?

Test laboratoryjny zależy od warunków pomiaru i może się nieznacznie zmieniać między uruchomieniami. Dlatego do oceny Core Web Vitals warto patrzeć przede wszystkim na dane terenowe CrUX oraz trend, a nie pojedynczy test.

Dlaczego nie widzę danych realnych użytkowników w PageSpeed Insights?

Nie każdy URL ma wystarczającą liczbę danych w Chrome UX Report. W takiej sytuacji PageSpeed może pokazać dane dla całego originu albo tylko część laboratoryjną. Brak danych CrUX nie oznacza automatycznie, że strona jest dobra lub zła.

Czy Core Web Vitals są ważniejsze na mobile?

Warto analizować oba typy urządzeń, ale dla wielu firm mobile jest kluczowy ze względu na sposób, w jaki klienci korzystają z internetu. Słabsze telefony i sieci komórkowe częściej ujawniają problemy, których nie widać na szybkim komputerze.

Czy wtyczka do cache naprawi Core Web Vitals w WordPressie?

Może pomóc w części problemów, ale nie jest uniwersalnym rozwiązaniem. Jeżeli przyczyną jest ciężki JavaScript, źle przygotowane obrazy, rozbudowany builder lub zewnętrzne widgety, sam cache może nie wystarczyć.

Ile czasu potrzeba, żeby zobaczyć poprawę w Core Web Vitals?

Zmianę w testach laboratoryjnych można zobaczyć od razu po wdrożeniu. Dane terenowe CrUX opierają się na ruchomym okresie 28 dni, dlatego poprawa w doświadczeniach realnych użytkowników pojawia się w raportach stopniowo.

Co dalej?

Jeżeli problem dotyczy pojedynczego obrazu albo jednej funkcji, pełna przebudowa strony zwykle nie jest potrzebna. Warto naprawić konkretną przyczynę.

Jeżeli jednak słabe wyniki są skutkiem całej architektury serwisu — ciężkiego motywu, wielu zależności, starego kodu i kolejnych warstw optymalizatorów — wtedy warto połączyć analizę wydajności z audytem technicznym i oceną, czy dalsze poprawianie obecnej strony ma jeszcze sens.

Sprawdź: Tworzenie stron internetowych Powiązany temat: Redesign strony internetowej — kiedy jest potrzebny? Dla WordPress: Tworzenie stron WordPress Diagnostyka SEO: Audyt SEO