Pewnie znasz to z własnego doświadczenia: wpisujesz w Google nazwę firmy, klikasz w link, czekasz… 4 sekundy. Cofasz się i klikasz w następny wynik. Tak postępuje większość użytkowników w 2026 roku — i Google to wie.
Od kilku lat algorytm wyszukiwarki bierze pod uwagę nie tylko to, czy strona ma dobre treści, ale też to, jak szybko i wygodnie się ładuje. Trzy konkretne metryki, zbiorczo nazywane Core Web Vitals, są w 2026 jednym z czynników rankingowych Google. Nie najważniejszym — ale wystarczająco istotnym, żeby przy podobnej jakości treści przełożyć się na wyraźną różnicę w pozycjach.
W tym artykule wyjaśniamy, czym dokładnie są Core Web Vitals, jak je sprawdzić u siebie, co najczęściej je psuje i kiedy warto zająć się tym samodzielnie, a kiedy poprosić o pomoc specjalistów.
Czym są Core Web Vitals
Core Web Vitals to zestaw trzech metryk wprowadzonych przez Google w 2020 roku. Mierzą one doświadczenie użytkownika podczas korzystania ze strony — w przeciwieństwie do czysto technicznych wskaźników typu „czas ładowania”, które nie zawsze mają związek z tym, co realnie czuje człowiek po drugiej stronie ekranu.
Trzy metryki, na które patrzy Google w 2026 roku, to:
- LCP (Largest Contentful Paint) — jak szybko ładuje się największy widoczny element strony
- INP (Interaction to Next Paint) — jak szybko strona reaguje na kliknięcie czy dotknięcie
- CLS (Cumulative Layout Shift) — czy elementy strony „skaczą” podczas ładowania
W marcu 2024 Google zastąpił dotychczasową metrykę FID (First Input Delay) bardziej rygorystyczną INP. Jeśli twoja strona była ostatnio sprawdzana w narzędziach pokazujących stare metryki, warto zrobić to ponownie — INP wykrywa problemy, których FID nie widział.
Trzy metryki — co każda znaczy w praktyce
LCP — czas do pojawienia się głównej treści
LCP mierzy, ile sekund mija od momentu kliknięcia w link, do chwili gdy największy widoczny element strony (zwykle zdjęcie nagłówkowe, duży nagłówek lub blok tekstu) pojawi się na ekranie użytkownika.
Progi Google’a:
- Dobre: do 2,5 sekundy
- Wymaga poprawy: 2,5–4 sekundy
- Słabe: powyżej 4 sekund
Co najczęściej psuje LCP: nieoptymalizowane zdjęcia (JPG-i ważące 2 MB zamiast WebP po 200 KB), wolny serwer hostingu, ciężkie czcionki ładowane przed treścią, zbyt wiele wtyczek dorzucających skrypty na samym początku.
W praktyce — jeśli strona ma LCP powyżej 4 sekund na telefonie (a Google mierzy przede wszystkim wersję mobilną), tracisz nie tylko pozycje w wyszukiwarce, ale przede wszystkim realnych klientów, którzy zamykają kartę przed pojawieniem się oferty.
INP — opóźnienie po kliknięciu
INP mierzy, ile milisekund mija między kliknięciem (lub dotknięciem na telefonie) a momentem, w którym strona faktycznie reaguje. To metryka „wrażenia z używania” — czy strona jest responsywna, czy „mulista”.
Progi:
- Dobre: do 200 ms
- Wymaga poprawy: 200–500 ms
- Słabe: powyżej 500 ms
Co psuje INP: ciężki JavaScript działający w tle, zbyt wiele animacji, nieoptymalizowane wtyczki, narzędzia zewnętrzne (chat boty, livechat, narzędzia analityczne).
Jeśli klient kliknie „Zamów” i strona reaguje po 800 milisekundach — wystarczy, żeby pomyślał „chyba nie zadziałało” i kliknął jeszcze raz, generując duplikat zgłoszenia albo po prostu się zniechęcając.
CLS — skacząca strona
CLS mierzy, jak bardzo elementy strony przesuwają się podczas ładowania. Każdy z nas to widział: zaczynasz czytać artykuł, nagle nad treścią pojawia się reklama lub ikonka i tekst skacze w dół, a ty klikasz w niewłaściwe miejsce.
Progi:
- Dobre: do 0,1
- Wymaga poprawy: 0,1–0,25
- Słabe: powyżej 0,25
Co psuje CLS: zdjęcia bez podanych wymiarów, czcionki ładowane bez fallbacku, dynamicznie wstawiane bannery i pop-upy, reklamy, niektóre wtyczki cookies.
Niski CLS to nie tylko lepsze pozycje w Google — to też mniej zirytowanych użytkowników i niższy współczynnik odrzuceń.
Jak sprawdzić swoją stronę
Trzy bezpłatne narzędzia, które dają obraz sytuacji w 5 minut:
1. PageSpeed Insights (PSI) — adres pagespeed.web.dev. Wpisujesz adres swojej strony, klikasz „Analizuj” i dostajesz wynik dla wersji mobilnej i desktopowej. To podstawowe narzędzie i pierwszy punkt kontaktu z Core Web Vitals.
2. Google Search Console — raport Core Web Vitals. Jeśli masz skonfigurowany GSC dla swojej domeny, w sekcji „Stan” znajdziesz raport pokazujący, ile twoich URL-i ma „dobre”, „wymaga poprawy” i „słabe” wskaźniki — agregowane z realnych odwiedzin użytkowników, a nie testu laboratoryjnego.
3. Lighthouse w Chrome DevTools — wbudowany w przeglądarkę. F12 → zakładka „Lighthouse” → „Generate report”. Bardziej szczegółowy niż PSI, dla osób, które chcą poznać konkretne sugestie.
Ważne: PSI mierzy laboratoryjnie, GSC pokazuje dane od realnych użytkowników. Wyniki mogą się różnić — i te z GSC są ważniejsze, bo to z nich Google korzysta przy rankingowaniu.
Co najczęściej spowalnia stronę
Z naszej praktyki, kiedy strona ma słabe Core Web Vitals, problem zwykle leży w jednej (lub kilku) z poniższych przyczyn:
1. Ciężkie zdjęcia. To absolutny lider. Zdjęcie nagłówkowe ważące 2,5 MB w formacie JPG zamiast 250 KB w formacie WebP albo AVIF to gotowy LCP powyżej 4 sekund. Jeden plik potrafi pogrążyć całą stronę.
2. Zbyt wiele wtyczek. Każda wtyczka WordPressa zwykle dorzuca własne pliki CSS i JS — często ładowane na każdej podstronie, nawet jeśli wtyczka działa tylko w jednym miejscu. Strona z 25 aktywnymi wtyczkami jest niemal zawsze wolniejsza od strony z 8.
3. Słaby hosting. Współdzielony hosting po kilka złotych miesięcznie, na którym razem z tobą działa kilkaset innych stron, oznacza wolny czas reakcji serwera. Nawet idealnie zoptymalizowana strona nie wybroni się przed słabym hostingiem.
4. Pliki blokujące wyświetlenie strony. CSS i JavaScript, które blokują pojawienie się treści, dopóki się w pełni nie wczytają. Klasyczny problem domyślnej konfiguracji WordPressa.
5. Narzędzia zewnętrzne. Google Analytics, Facebook Pixel, livechat, narzędzia heatmap, kalkulatory zewnętrzne — każde z nich dodaje skrypty. Same w sobie nie są problemem, ale pięć takich naraz potrafi solidnie obciążyć stronę.
Co realnie pomaga
Kierunki działania, w kolejności od „prostych” do „wymagających specjalisty”:
Optymalizacja zdjęć. Konwersja do WebP/AVIF, kompresja, lazy loading (zdjęcia ładowane dopiero gdy użytkownik je zobaczy). Sporo wtyczek robi to automatycznie po podstawowej konfiguracji.
Buforowanie (caching). Strona zostaje „złapana” jako gotowy plik HTML — przy kolejnych odwiedzinach serwowany w ułamku sekundy, bez ponownego przetwarzania. Standardowe rozwiązanie dla każdej strony WordPressowej.
Minifikacja CSS i JS. Usunięcie spacji, komentarzy i zbędnych znaków z plików kodu. Sam plik staje się 20–30% mniejszy.
Critical CSS. Wczytywanie najpierw tych styli, które są potrzebne do wyświetlenia widocznej części strony — reszta dochodzi w tle. Wymaga już bardziej technicznej konfiguracji.
Optymalizacja czcionek. Wczytywanie czcionek z własnego serwera zamiast z zewnętrznego, ograniczenie liczby wariantów, ustawienie zachowania na czas ładowania.
Hosting o odpowiednim profilu. Czasem najprostsza zmiana hostingu na dedykowany pod WordPressa daje 30–40% poprawy bez ruszania samej strony.
Większość z tych rzeczy da się wdrożyć z odpowiednią wtyczką (np. WP Rocket, LiteSpeed Cache, Autoptimize) — ale każda wtyczka wymaga poprawnej konfiguracji. Niedobrze skonfigurowana potrafi zepsuć więcej niż naprawić.
Page builder czy custom theme — co jest szybsze
To jedno z częstszych pytań, jakie pojawiają się przy planowaniu nowej strony. Odpowiedź uczciwa: obie opcje mogą być szybkie, obie mogą być wolne.
Strony budowane na page builderach (jak Elementor, Divi, WPBakery) są bardziej elastyczne w edycji wizualnej i pozwalają na samodzielne wprowadzanie zmian bez znajomości kodu. W zamian dorzucają więcej zasobów technicznych — każdy moduł ma swój kontener, swoje style i swoje skrypty. Przy dobrej konfiguracji potrafią dawać przyzwoite wyniki, ale „od podstaw szybkie” wymaga świadomej pracy nad optymalizacją.
Strony custom theme w czystym kodzie startują z mniejszym bagażem — mają tylko to, co programista celowo umieścił. Daje to wyższą bazę performance, ale są mniej elastyczne dla osoby bez umiejętności technicznych — zmiany w układzie strony zwykle wymagają edycji kodu albo zlecenia ich komuś.
Dla większości firm decyzja powinna opierać się na innym pytaniu: kto i jak często będzie zmieniał treści? Performance to jeden z czynników wyboru, ale nie jedyny.
Realny budżet — od „samodzielnie” do „pod klucz”
Ile to kosztuje, jeśli chcesz poprawić Core Web Vitals istniejącej strony? W zależności od stanu wyjściowego:
0–200 zł — DIY z dobrą wtyczką cache. Zainstalowanie i podstawowa konfiguracja wtyczki typu LiteSpeed Cache (bezpłatna) lub WP Rocket (płatna jednorazowo). Daje zwykle 20–40% poprawy. Wymaga kilku godzin czasu na czytanie dokumentacji i testowanie.
500–1 500 zł — audyt + szybkie poprawki. Specjalista przegląda stronę, identyfikuje konkretne problemy, wdraża najważniejsze poprawki: kompresja zdjęć, dobra konfiguracja cache, optymalizacja czcionek i critical CSS. Zwykle 5–10 godzin pracy.
1 500–4 000 zł — pełna optymalizacja istniejącej strony. Głęboka praca: audyt wtyczek, refactor problematycznych miejsc, własna konfiguracja, testy z Lighthouse, monitoring po wdrożeniu. Wynik: stabilne zielone wskaźniki.
Cena nowej strony — strona budowana od zera z myślą o performance. W projektach „od pomysłu do wdrożenia” Core Web Vitals są częścią procesu, nie dodatkiem. Wycena zależy od skali — szczegóły w dziale tworzenie stron internetowych.
Kiedy warto zlecić specjalistom
Samodzielne rozwiązanie ma sens, jeśli twoja strona w PSI ma 60–80 punktów na mobilu i głównym problemem są zdjęcia albo cache. To do ogarnięcia w jedno popołudnie z dobrą wtyczką.
Wsparcie specjalistów bywa potrzebne, gdy:
- PSI pokazuje poniżej 50 punktów na mobilu mimo wprowadzonych zmian
- Wykonałeś podstawowe optymalizacje, a wskaźniki dalej są czerwone
- Strona traci pozycje w Google mimo dobrych treści
- Klienci skarżą się na wolne ładowanie albo „dziwne zachowanie strony”
- Wkrótce uruchamiasz kampanię reklamową i nie możesz pozwolić sobie na 60% odrzuceń
- Robisz nową stronę i zależy ci, żeby od pierwszego dnia była zoptymalizowana
W tych sytuacjach koszt audytu i optymalizacji zwykle zwraca się w kilka miesięcy — przez wzrost konwersji i lepsze pozycje w wyszukiwarce. Często też strona po optymalizacji przestaje wymagać codziennego pilnowania, co warto połączyć z regularną opieką techniczną, żeby wskaźniki nie obniżały się z czasem.
Co dalej
Core Web Vitals to nie sport olimpijski — nie chodzi o to, żeby mieć 100/100 punktów za wszelką cenę. Chodzi o to, żeby strona była wystarczająco szybka i wygodna, żeby klient nie zamknął jej z frustracji, a Google nie zepchnął jej w wynikach.
Pierwsze kroki, które warto zrobić w tym tygodniu:
- Sprawdź PSI dla swojej strony głównej i 2–3 najważniejszych podstron
- Sprawdź raport Core Web Vitals w Google Search Console (jeśli go nie masz, warto założyć)
- Zobacz, ile waży główne zdjęcie hero i w jakim formacie jest
- Policz aktywne wtyczki — czy wszystkie są naprawdę potrzebne
Jeśli wyniki są słabe, a samodzielne poprawki nie wchodzą w grę albo nie dają efektu — chętnie pomożemy. Robimy zarówno audyty istniejących stron, jak i nowe strony zoptymalizowane od podstaw, gdzie performance jest częścią procesu od pierwszego dnia. Zerknij też na pozycjonowanie SEO, bo Core Web Vitals to tylko jeden z elementów ogólnej widoczności w Google.
Daj znać przez formularz kontaktowy — odpowiadamy zwykle w ciągu doby.
