Core Web Vitals pozostają w 2026 roku podstawowym zestawem wskaźników, którymi Google mierzy rzeczywiste doświadczenie użytkownika na stronie. Largest Contentful Paint, Interaction to Next Paint i Cumulative Layout Shift opisują trzy różne aspekty tego doświadczenia: czas pojawienia się treści, płynność reakcji na działania użytkownika i stabilność układu strony. Nie są jedynym czynnikiem rankingowym i nie zastąpią dobrej treści. Mają natomiast realne znaczenie tam, gdzie kilkanaście serwisów walczy o te same frazy z porównywalnym materiałem. WordPress da się doprowadzić do dobrych wyników, ale wymaga to decyzji architektonicznych, nie samej konfiguracji wtyczek.
Czym są Core Web Vitals i co dokładnie mierzą?
Core Web Vitals to trzy wskaźniki, którymi Google opisuje doświadczenie rzeczywistych użytkowników odwiedzających stronę. Largest Contentful Paint (LCP) mierzy czas wyświetlenia największego elementu treści. Interaction to Next Paint (INP) mierzy responsywność, czyli czas od interakcji użytkownika do widocznej reakcji interfejsu. Cumulative Layout Shift (CLS) mierzy stabilność wizualną, czyli skalę nieoczekiwanych przesunięć układu podczas wczytywania.
Aktualne progi wyglądają następująco:
| Wskaźnik | Dobry | Wymaga poprawy | Słaby |
|---|---|---|---|
| LCP | do 2,5 s | 2,5 – 4 s | powyżej 4 s |
| INP | do 200 ms | 200 – 500 ms | powyżej 500 ms |
| CLS | do 0,1 | 0,1 – 0,25 | powyżej 0,25 |
Dwie rzeczy warto tu wyjaśnić od razu, bo najczęściej prowadzą do nieporozumień w rozmowach z zespołami marketingu.
Po pierwsze, Google ocenia wynik na 75. percentylu danych rzeczywistych. Oznacza to, że 75 procent wizyt musi mieścić się w progu „dobry”. Mediana nie wystarczy. Jeżeli co czwarty użytkownik ma słabe doświadczenie, strona nie przechodzi oceny.
Po drugie, liczy się wynik ze wszystkich trzech wskaźników. Dwa dobre i jeden słaby to wynik negatywny. Nie ma tu punktacji częściowej.
Wskaźniki nie są abstrakcją techniczną. LCP mówi, czy główna treść pojawia się na tyle szybko, żeby użytkownik został. INP pokazuje, czy interfejs reaguje na kliknięcia i wpisywanie w tempie, które wydaje się naturalne. CLS opisuje, czy treść nie przeskakuje w trakcie wczytywania, powodując przypadkowe kliknięcia.
Jak mocno Core Web Vitals wpływają na pozycje w Google?
Core Web Vitals są jednym z wielu sygnałów rankingowych, nie przełącznikiem decydującym o pozycji. Działają obok jakości treści, dopasowania do intencji wyszukiwania i autorytetu domeny. Najlepiej myśleć o nich jak o kryterium rozstrzygającym, którego waga rośnie w miarę wyrównywania się pozostałych czynników.
W praktyce oznacza to dwie rzeczy.
Słabe wyniki nie zniszczą serwisu, który ma mocną treść i wysoki autorytet. Ograniczą natomiast jego potencjał. Odwrotna zależność też obowiązuje: wzorowe wyniki nie uratują treści powierzchownej ani nie nadrobią braku autorytetu tematycznego.
Tam, gdzie kilkanaście serwisów pokrywa ten sam temat na podobnym poziomie, wydajność zaczyna rozstrzygać. Różnica między trzecią a ósmą pozycją przekłada się bezpośrednio na ruch i przychód, a przy porównywalnej treści to często wydajność decyduje o tym, kto stoi wyżej.
Warto też zauważyć zmianę kontekstu. Wydajność przestała dotyczyć wyłącznie klasycznych wyników wyszukiwania. Systemy generatywne, które cytują źródła w odpowiedziach, sięgają po serwisy dostępne i szybkie w indeksowaniu. To nie jest ta sama mechanika co ranking Google, ale kierunek zależności jest zbieżny.
Co zmieniło się w Core Web Vitals do 2026 roku?
Najważniejsza zmiana ostatnich lat to zastąpienie wskaźnika First Input Delay (FID) przez Interaction to Next Paint (INP), które weszło w życie 12 marca 2024 roku. FID mierzył wyłącznie opóźnienie przed reakcją przeglądarki na pierwszą interakcję. INP mierzy pełny czas do pojawienia się widocznej reakcji i obejmuje wszystkie interakcje w trakcie wizyty. To znacznie ostrzejsze kryterium, szczególnie dla serwisów z rozbudowanym JavaScriptem.
Jeżeli w Waszych raportach albo dokumentacji technicznej nadal figuruje FID, materiał jest nieaktualny.
Tu potrzebne jest sprostowanie, bo w wynikach wyszukiwania krąży teza, którą warto zweryfikować u źródła. Część publikacji z 2026 roku twierdzi, że Google zaostrzył próg LCP z 2,5 do 2,0 sekundy, zrównał wagi wskaźników albo zaczął oceniać wydajność na poziomie całej domeny. Dokumentacja Google tego nie potwierdza. Progi pozostają bez zmian: 2,5 sekundy dla LCP, 200 milisekund dla INP, 0,1 dla CLS. Zanim przebudujesz priorytety zespołu pod nową liczbę, sprawdź, czy publikacja podaje odniesienie do materiałów Google. W większości przypadków nie podaje.
Realna zmiana zaszła gdzie indziej, w metodologii pomiaru i w rozkładzie akcentów. Google mocniej opiera ocenę na danych z rzeczywistego ruchu niż na testach laboratoryjnych, a wyniki na urządzeniach mobilnych mają większe znaczenie niż wyniki desktopowe. Dla właściciela serwisu ma to konkretną konsekwencję: wynik 95 w Lighthouse nic nie znaczy, jeżeli dane z Chrome User Experience Report pokazują coś innego.
Po stronie WordPressa też coś się zmieniło, choć nie tak spektakularnie, jak sugerują materiały marketingowe. Motywy blokowe generują mniej kodu niż klasyczne kreatory stron. Edytor blokowy produkuje czystszy HTML niż shortcode’y i skomplikowane układy oparte na kreatorach. Hostingi wyspecjalizowane w WordPressie oferują cache na poziomie serwera. To realne usprawnienia, ale żadne z nich nie naprawia serwisu, w którym przez pięć lat narastał dług techniczny.
Jak mierzyć Core Web Vitals w WordPressie?
Podstawowym źródłem jest raport Core Web Vitals w Google Search Console, ponieważ pokazuje dane z rzeczywistego ruchu. Raport grupuje adresy według statusu i wskazuje, które wzorce stron mają problem. To te dane Google wykorzystuje przy ocenie, więc od nich zaczynaj.
PageSpeed Insights daje analizę pojedynczego adresu i pokazuje jednocześnie dane laboratoryjne oraz rzeczywiste, jeżeli są dostępne. Dane laboratoryjne służą do diagnozy konkretnych problemów technicznych. Dane rzeczywiste pokazują, jak stronę odbierają użytkownicy.
Chrome User Experience Report agreguje dane wydajnościowe z milionów serwisów i pozwala porównać wyniki z rynkiem. Narzędzia do monitoringu rzeczywistych użytkowników (RUM) dają ciągły pomiar i alert, gdy wydajność spada.
Rozróżnienie między danymi laboratoryjnymi a rzeczywistymi jest kluczowe i warto je wyjaśnić zespołowi raz a porządnie. Dane laboratoryjne pokazują potencjał w warunkach kontrolowanych. Dane rzeczywiste pokazują, co dostaje użytkownik na swoim telefonie, w swojej sieci, ze swoim zestawem rozszerzeń przeglądarki. Do oceny SEO liczą się dane rzeczywiste. Dane laboratoryjne służą do diagnozy.
Jedno zastrzeżenie praktyczne. Dane rzeczywiste pojawiają się dopiero przy odpowiednim wolumenie ruchu na danym adresie. Podstrony rzadko odwiedzane nie będą miały własnych danych i zostaną ocenione na poziomie grupy adresów albo całej domeny. Dla serwisów z długim ogonem treści oznacza to, że wyniki szablonu ciągną za sobą tysiące podstron.
Monitoring musi być ciągły. Aktualizacja wtyczki, nowa integracja albo dodanie skryptu marketingowego potrafią zepsuć wynik z dnia na dzień, bez żadnej zmiany w kodzie serwisu.
Co psuje Core Web Vitals w WordPressie?
Przyczyny słabych wyników powtarzają się w audytach na tyle regularnie, że da się je wymienić w kolejności częstotliwości.
Ciężkie motywy uniwersalne. Motyw, który ma obsłużyć każdy scenariusz, ładuje CSS i JavaScript na każdej podstronie, niezależnie od tego, co jest na niej potrzebne. Kilkadziesiąt funkcji, z których korzystacie z trzech, kosztuje przy każdym wczytaniu strony.
Nagromadzenie wtyczek. Każda wtyczka dokłada własne skrypty i style, często globalnie. Efekt kumuluje się. Kilkanaście wtyczek, z których każda z osobna wygląda niewinnie, potrafi wspólnie zniszczyć wynik.
Nieoptymalizowane obrazy. Duże pliki bez kompresji i bez nowoczesnych formatów obciążają LCP. Obrazy bez zadeklarowanych wymiarów powodują przesunięcia układu i psują CLS. Problem jest znany od lat i nadal wraca w większości audytów.
Zasoby blokujące renderowanie. Pliki CSS i JavaScript, które muszą się załadować, zanim przeglądarka wyświetli cokolwiek, bezpośrednio opóźniają LCP.
Skrypty zewnętrzne. Analityka, narzędzia marketing automation, czaty, piksele reklamowe, testy A/B. Każdy z tych elementów dokłada się do INP, a użytkownik nie dostaje w zamian nic, co widzi.
Niewystarczający hosting. Wolny czas odpowiedzi serwera wyznacza sufit, którego nie przebijesz optymalizacją front-endu. Żadna wtyczka cache’ująca nie naprawi infrastruktury, która nie nadąża.
Złożone integracje danych. Katalogi produktowe z tysiącami pozycji, tabele porównawcze zaciągające dane na żywo, kalkulatory, wykresy, widgety zewnętrzne. Te funkcje mają realną wartość biznesową, ale wdrożone bez planu wydajnościowego kosztują dokładnie tyle, ile dają.
Jak poprawić Core Web Vitals bez zespołu developerskiego?
Część usprawnień da się wdrożyć bez pisania kodu i warto zacząć właśnie od nich, bo dają najwięcej za najmniejszy nakład.
Zmiana motywu na lżejszy jest zwykle decyzją o największym wpływie. Motywy blokowe przygotowane pod Full Site Editing wypadają lepiej niż motywy oparte na kreatorach stron i shortcode’ach. To jednak decyzja projektowa, nie kosmetyczna, więc wymaga zaplanowania.
Wtyczka cache’ująca poprawia wynik natychmiast, serwując statyczne wersje stron zamiast generować je przy każdym wejściu. Większość rozwiązań ma kreatory konfiguracji z rozsądnymi ustawieniami domyślnymi.
Sieć CDN rozkłada zasoby statyczne na serwery bliżej użytkownika i skraca opóźnienia. Ma szczególne znaczenie przy odbiorcach z kilku krajów.
Wtyczki do optymalizacji obrazów kompresują pliki i konwertują je do nowoczesnych formatów automatycznie, zarówno w istniejącej bibliotece mediów, jak i przy nowych wgraniach.
Hosting dopasowany do WordPressa obejmuje cache na poziomie serwera, właściwy przydział zasobów i konfigurację przygotowaną pod tę platformę. Różnica w czasie odpowiedzi serwera bywa większa niż suma wszystkich optymalizacji front-endowych.
Przegląd wtyczek i skryptów zewnętrznych to działanie, które nic nie kosztuje poza czasem. Zestawcie listę aktywnych wtyczek i skryptów marketingowych z tym, co realnie jest używane. W większości serwisów da się usunąć od kilku do kilkunastu pozycji bez żadnej straty.
Jakie techniki zaawansowane realnie poprawiają wydajność WordPressa?
Powyżej pewnego progu złożoności ustawienia wtyczek przestają wystarczać i potrzebna jest praca na poziomie architektury.
Renderowanie po stronie serwera generuje kompletny HTML przed wysłaniem go do przeglądarki, co bezpośrednio poprawia LCP. Ma znaczenie zwłaszcza tam, gdzie treść dynamiczna byłaby budowana przez JavaScript po stronie klienta.
Critical CSS polega na wyodrębnieniu i osadzeniu w kodzie tylko tych styli, które są potrzebne do wyrenderowania widocznej części strony. Reszta ładuje się asynchronicznie i nie blokuje wyświetlenia.
Optymalizacja JavaScriptu obejmuje odroczenie skryptów niekrytycznych, usunięcie nieużywanego kodu i podział pakietów, żeby ładować tylko to, co potrzebne na danej podstronie. To główna dźwignia przy poprawie INP, bo INP zależy od obciążenia głównego wątku przeglądarki.
Optymalizacja zapytań do bazy danych ma znaczenie w serwisach z dużym wolumenem treści i złożonymi relacjami. Indeksy, przepisanie wolnych zapytań i cache obiektowy na Redisie skracają czas odpowiedzi serwera, a ten wpływa na wszystko, co dzieje się później.
Nowoczesna architektura projektu. Frameworki takie jak Sage, Bedrock czy Radicle wymuszają porządek: rozdzielenie konfiguracji od kodu, zarządzanie zależnościami, przewidywalną strukturę szablonów. Efektem jest instalacja, którą da się utrzymywać przez lata bez narastania długu technicznego.
Warstwowe cache’owanie. Cache stron to tylko pierwszy poziom. Powyżej niego dochodzi cache obiektowy, cache fragmentów dla elementów dynamicznych i cache na brzegu sieci przez CDN.
Budżety wydajnościowe w procesie wdrożeniowym. To technika, która najbardziej zmienia sytuację długoterminowo. Automatyczne testy wydajności w pipeline CI/CD zatrzymują regresję, zanim trafi na produkcję. Bez tego każda optymalizacja jest jednorazowa, a serwis wraca do stanu wyjściowego w ciągu kilku miesięcy.
Gdzie Core Web Vitals bolą najbardziej: wzorce z audytów
Skala i typ serwisu zmieniają charakter problemu.
E-commerce B2B. Katalog z tysiącami indeksów, filtrowanie, konfiguratory, ceny zależne od kontraktu. Strony kategorii i wyszukiwarka produktów to zwykle najsłabsze punkty, a jednocześnie miejsca o najwyższej wartości biznesowej. Poprawa INP na liście produktów daje tu więcej niż poprawa LCP na stronie głównej.
Grupy multi-brand. Kilka marek na wspólnej infrastrukturze, każda z własnym zespołem marketingu i własnym zestawem skryptów zewnętrznych. Wydajność rozjeżdża się między markami, bo nikt nie odpowiada za wynik na poziomie całej platformy.
Wydawcy i portale treściowe. Duży wolumen archiwów, reklamy i skrypty monetyzujące, treści osadzane z zewnątrz. CLS bywa tu największym problemem, bo bloki reklamowe wczytują się po treści i przesuwają układ.
Platformy edukacyjne. Odtwarzacze wideo, interaktywne testy, panele użytkownika. Wydajność części zalogowanej wypada poza cache stron, więc wymaga innego podejścia niż strony publiczne.
Wspólny mianownik jest jeden. W każdym z tych przypadków wynik da się poprawić punktowo i w każdym wróci on do poprzedniego stanu, jeżeli wydajność nie ma właściciela i nie jest mierzona przy każdym wdrożeniu.
Jak Core Web Vitals przekładają się na konwersję?
Zależność jest bezpośrednia, bo te wskaźniki mierzą dokładnie te aspekty doświadczenia, które wpływają na zachowanie użytkownika.
Strona, której główna treść pojawia się poniżej 2,5 sekundy, zatrzymuje użytkownika zamiast odsyłać go z powrotem do wyników wyszukiwania. Interfejs reagujący poniżej 200 milisekund buduje przekonanie, że serwis działa poprawnie. Stabilny układ strony chroni przed przypadkowymi kliknięciami, które są jednym z najbardziej irytujących doświadczeń w sieci.
Największą różnicę widać na urządzeniach mobilnych, gdzie użytkownicy częściej korzystają z wolniejszych połączeń i słabszego sprzętu. To także tam próg cierpliwości jest najniższy.
Efekt składa się z dwóch elementów, które się mnożą. Lepsze wyniki podnoszą widoczność w wyszukiwarce, co daje więcej ruchu. Ten sam ruch konwertuje lepiej, bo mniej użytkowników odpada po drodze. Serwis, który przesuwa się z ósmej pozycji na trzecią i jednocześnie konwertuje wyżej, generuje wielokrotność wyniku wyjściowego, mimo że pracowaliście nad jedną rzeczą.
Od czego zacząć
Kolejność działań, którą rekomendujemy w projektach optymalizacyjnych:
- Zmierz stan wyjściowy na danych rzeczywistych. Raport Core Web Vitals w Search Console, podział na urządzenia mobilne i desktop, identyfikacja grup adresów z najgorszym wynikiem.
- Ustal, które wzorce stron mają największą wartość biznesową. Optymalizacja strony głównej rzadko jest najlepszą inwestycją. Zwykle są nią karty produktu, strony kategorii albo landing pages kampanii.
- Napraw fundament, zanim zaczniesz od front-endu. Czas odpowiedzi serwera i hosting wyznaczają sufit dla wszystkiego, co zrobicie później.
- Rozwiąż jeden wskaźnik na raz. Zaczynaj od tego, który blokuje ocenę na najważniejszych wzorcach stron.
- Wpisz wydajność w proces wdrożeniowy. Budżety wydajnościowe w CI/CD i monitoring danych rzeczywistych. Bez tego wracacie do punktu wyjścia w ciągu kilku miesięcy.
FAQ
Czy Core Web Vitals są czynnikiem rankingowym?
Tak, od aktualizacji Page Experience w 2021 roku. Ich waga jest jednak umiarkowana. Działają jako kryterium rozstrzygające przy porównywalnej jakości treści i autorytecie domeny, a nie jako samodzielna dźwignia pozycji.
Czy Google zaostrzył próg LCP do 2,0 sekundy w 2026 roku?
Dokumentacja Google tego nie potwierdza. Obowiązujący próg dla oceny „dobry” to nadal 2,5 sekundy, mierzone na 75. percentylu danych rzeczywistych. Publikacje podające wartość 2,0 sekundy nie wskazują źródła w materiałach Google.
Czy wynik 100 w PageSpeed Insights oznacza, że strona przechodzi ocenę?
Nie. Wynik w PageSpeed Insights pochodzi z testu laboratoryjnego Lighthouse. Google ocenia serwis na danych rzeczywistych z Chrome User Experience Report. Strona z wynikiem laboratoryjnym bliskim 100 może nie przechodzić oceny, jeżeli realni użytkownicy korzystają z niej w gorszych warunkach.
Jak długo trwa poprawa wyników po wdrożeniu zmian?
Dane rzeczywiste liczone są w oknie 28 dni, więc pełny efekt widać po około miesiącu od wdrożenia. Wcześniejsze wahania w raporcie mogą wynikać z częściowego okna pomiarowego, nie z rzeczywistej zmiany.
Czy WordPress może osiągnąć dobre wyniki Core Web Vitals?
Tak, choć wymaga to decyzji, które zwykle zapadają na etapie architektury, a nie konfiguracji. Lekki motyw blokowy, zdyscyplinowany zestaw wtyczek, właściwy hosting i kontrola nad skryptami zewnętrznymi wystarczają w większości przypadków. Problemem nie jest platforma, tylko sposób jej wdrożenia i utrzymania.
Który wskaźnik poprawić najpierw?
Ten, który blokuje ocenę na najważniejszych biznesowo wzorcach stron. Statystycznie najczęściej jest to LCP, ale w serwisach z rozbudowanym JavaScriptem, filtrowaniem i interaktywnymi elementami częściej wąskim gardłem okazuje się INP.
Twój WordPress „działa, ale wolno”? Zaczniemy od pomiaru na danych rzeczywistych i wskażemy, gdzie leży sufit wydajności. → Zamów audyt
