SEO

Core Web Vitals — jak poprawić wyniki i dlaczego to ważne dla SEO

· 12 min czytania

Google od lat powtarza, że doświadczenie użytkownika ma znaczenie. Ale od 2021 roku przestał tylko powtarzać — zaczął mierzyć. Core Web Vitals to trzy konkretne metryki, które Google używa do oceny, jak szybko i płynnie działa Twoja strona. Nie spełniasz progów? Tracisz pozycje na rzecz konkurentów, których strony ładują się szybciej. W tym artykule wyjaśniam, czym są Core Web Vitals, jakie wartości powinieneś osiągać i — co najważniejsze — jak konkretnie poprawić wyniki, jeśli Twoja strona nie przechodzi testu.

Ten artykuł jest rozszerzeniem technicznej części naszego kompletnego poradnika pozycjonowania stron w Google. Jeśli chcesz zobaczyć, jak Core Web Vitals wpisują się w szerszą strategię SEO — polecam zacząć od tamtego tekstu.

Czym są Core Web Vitals?

Core Web Vitals to zestaw trzech metryk, które mierzą trzy aspekty doświadczenia użytkownika na stronie:

  1. LCP (Largest Contentful Paint) — jak szybko ładuje się główna treść strony
  2. CLS (Cumulative Layout Shift) — jak stabilny jest układ strony podczas ładowania
  3. INP (Interaction to Next Paint) — jak szybko strona reaguje na działania użytkownika

Każda z tych metryk ma określone progi: dobry (zielony), wymaga poprawy (pomarańczowy) i słaby (czerwony). Google jasno komunikuje: strony, które spełniają wszystkie trzy progi, mają przewagę rankingową nad tymi, które ich nie spełniają.

Dlaczego Google tak bardzo zależy na szybkości?

Google zarabia na tym, że użytkownicy mu ufają. Jeśli użytkownik kliknie wynik w Google i trafi na stronę, która ładuje się 8 sekund, podskakuje podczas ładowania, a kliknięcie przycisku nie daje żadnej odpowiedzi — użytkownik wraca do wyników. Wraca sfrustrowany. Traci zaufanie do wyników Google. Dlatego Google aktywnie promuje strony, które działają szybko i płynnie — bo to w interesie samego Google.

LCP — Largest Contentful Paint

Co to mierzy?

LCP mierzy czas, który upływa od momentu kliknięcia w link do momentu wyrenderowania największego elementu widocznego na ekranie. Ten „największy element” to zazwyczaj zdjęcie hero, duży nagłówek, wideo lub grafika w tle.

Jakie są progi?

  • Dobry: poniżej 2,5 sekundy
  • Wymaga poprawy: 2,5–4,0 sekundy
  • Słaby: powyżej 4,0 sekund

Co najczęściej powoduje wolne LCP?

W mojej praktyce — bo analizuję strony klientów regularnie — trzy problemy odpowiadają za 90% przypadków wolnego LCP:

  1. Ciężkie, niezoptymalizowane zdjęcia — zdjęcie hero waży 3 MB zamiast 200 KB. Najczęstsza przyczyna, najprostsza do naprawienia.
  2. Wolny hosting — tani hosting współdzielony (shared hosting) po prostu nie jest w stanie odpowiedzieć na żądanie wystarczająco szybko. TTFB (Time to First Byte) powyżej 800 ms to czerwona flaga.
  3. Render-blocking CSS i JavaScript — przeglądarka musi pobrać i przetworzyć duże pliki CSS/JS, zanim w ogóle zacznie rysować stronę. Zewnętrzne fonty, niepotrzebne biblioteki JS, nieskomprymowane arkusze stylów.

Jak poprawić LCP — konkretne działania

  1. Optymalizuj obrazy — konwertuj do formatu WebP lub AVIF (oszczędność 30-50% w porównaniu z JPEG). Ustal maksymalną szerokość: hero 1920px, zdjęcia w treści 800-1200px. Kompresuj narzędziami: Squoosh, ShortPixel, TinyPNG. Dodaj atrybut width i height do każdego <img>.
  2. Lazy loading dla obrazów poniżej fold — dodaj loading="lazy" do wszystkich obrazów, które nie są widoczne od razu na ekranie. Ale NIE dodawaj go do zdjęcia hero — to musi się załadować natychmiast.
  3. Preload kluczowych zasobów — dodaj w <head> tag <link rel="preload"> dla zdjęcia hero i krytycznego fontu. Przeglądarka zacznie je pobierać wcześniej, zanim CSS poprosi o te zasoby.
  4. Zminimalizuj render-blocking — CSS krytyczny (above-the-fold) wstaw inline w <head>. Resztę CSS ładuj asynchronicznie. JavaScript z atrybutem defer lub na końcu <body>.
  5. Włącz kompresję Gzip/Brotli — serwer powinien kompresować pliki tekstowe (HTML, CSS, JS) przed wysłaniem. Oszczędność 60-80% rozmiaru transferu.
  6. Rozważ CDN — Content Delivery Network (np. Cloudflare, darmowy plan) serwuje pliki z serwerów bliżej użytkownika. Dla polskich stron z polskim hostingiem efekt jest mniejszy, ale wciąż mierzalny.
  7. Zmień hosting, jeśli TTFB jest wysoki — jeśli sam serwer odpowiada wolno (TTFB > 600 ms), żadna optymalizacja frontendowa tego nie naprawi. Dobry hosting z PHP OPcache, HTTP/2 i SSD to fundament.

CLS — Cumulative Layout Shift

Co to mierzy?

CLS mierzy wizualną stabilność strony — ile elementów „przeskakuje” podczas ładowania. Znasz ten problem: klikasz w przycisk, ale w tym momencie ładuje się reklama powyżej, strona się przesuwa i klikasz w coś innego. To jest layout shift i to jest problem, który CLS mierzy.

Jakie są progi?

  • Dobry: poniżej 0,1
  • Wymaga poprawy: 0,1–0,25
  • Słaby: powyżej 0,25

Co najczęściej powoduje wysokie CLS?

  • Obrazy bez wymiarów — jeśli <img> nie ma atrybutów width i height, przeglądarka nie wie, ile miejsca zarezerwować. Ładuje tekst, potem doładowuje obraz i tekst się przesuwa.
  • Fonty webowe (FOUT/FOIT) — przeglądarka wyświetla tekst fontem systemowym, potem ładuje font webowy i tekst „przeskakuje”, bo zmienił się rozmiar i kształt liter.
  • Reklamy i embedy — dynamicznie ładowane banery, widgety social media, mapy Google — wszystko, co „wpycha się” w stronę po załadowaniu.
  • Dynamicznie wstrzykiwany content — powiadomienia cookie, sticky headery, bannery promujące aplikację — jeśli dodają się do strony po załadowaniu i przesuwają resztę treści w dół.

Jak poprawić CLS — konkretne działania

  1. Zawsze deklaruj wymiary obrazów — każdy <img> powinien mieć width i height. Dzięki temu przeglądarka rezerwuje miejsce jeszcze przed pobraniem obrazu. CSS: img { max-width: 100%; height: auto; } zapewni responsywność bez zmiany proporcji.
  2. Użyj font-display: swap z rozsądkiem — dodaj font-display: swap do deklaracji @font-face. Tekst wyświetli się od razu fontem zastępczym, a po załadowaniu zamieni się na docelowy. Żeby zminimalizować shift, dobierz font zastępczy o podobnych proporcjach do docelowego.
  3. Rezerwuj miejsce na embedy i reklamy — jeśli masz na stronie Google Ads, mapę czy widget, ustaw kontener z minimalną wysokością (min-height), zanim treść się załaduje.
  4. Baner cookies na dole strony — pasek informacyjny o ciasteczkach powinien być na dole ekranu (position: fixed) i nie przesuwać treści strony. Nigdy na górze, jeśli push-uje resztę w dół.
  5. Unikaj wstrzykiwania treści nad istniejący content — jeśli musisz dodać element dynamicznie, dodawaj go pod istniejącą treścią lub jako overlay (position: fixed/absolute), który nie przesuwa layoutu.

INP — Interaction to Next Paint

Co to mierzy?

INP zastąpił FID (First Input Delay) w marcu 2024 roku. Mierzy responsywność strony — ile czasu upływa od momentu, gdy użytkownik kliknie, tapnie lub naciśnie klawisz, do momentu, gdy przeglądarka wyświetli wizualną odpowiedź na to działanie.

Kluczowa różnica wobec FID: FID mierzył tylko pierwszą interakcję. INP mierzy WSZYSTKIE interakcje na stronie i bierze pod uwagę najgorszą (z pominięciem outlierów). To znacznie trudniejsza metryka do spełnienia.

Jakie są progi?

  • Dobry: poniżej 200 milisekund
  • Wymaga poprawy: 200–500 milisekund
  • Słaby: powyżej 500 milisekund

Co najczęściej powoduje wolne INP?

  • Ciężki JavaScript — duże biblioteki JS (React, Angular, ciężkie pluginy jQuery) blokują główny wątek przeglądarki. Kiedy wątek jest zajęty przetwarzaniem skryptu, nie może obsłużyć kliknięcia użytkownika.
  • Zbyt wiele event listenerów — każdy skrypt nasłuchujący na kliknięcia, scrolle, ruchy myszki obciąża przeglądarkę.
  • Kosztowne operacje DOM — skrypty, które manipulują setkami elementów DOM przy każdej interakcji (np. rozbudowane filtry, dynamiczne tabele).
  • Third-party scripts — skrypty śledzące, czaty, widgety social media, piksele konwersji. Każdy z osobna wydaje się lekki, ale 5-10 takich skryptów potrafi zablokować stronę na setki milisekund.

Jak poprawić INP — konkretne działania

  1. Zminimalizuj i odrocz JavaScript — usuń nieużywane biblioteki. Załaduj skrypty z atrybutem defer. Jeśli jakiś skrypt jest potrzebny tylko na jednej podstronie — nie ładuj go na pozostałych.
  2. Podziel długie taski — JavaScript, który wykonuje się dłużej niż 50 ms, blokuje interakcje. Podziel takie taski na mniejsze kawałki używając requestAnimationFrame, setTimeout(0) lub scheduler.yield() (nowe API).
  3. Ogranicz third-party scripts — przejrzyj wszystkie zewnętrzne skrypty na stronie. Czy naprawdę potrzebujesz czatu, piksel Facebooka, Google Tag Managera z 15 tagami, Hotjar, widgetu Instagrama i skryptu cookie jednocześnie? Każdy usunięty skrypt to poprawa INP.
  4. Debounce i throttle — event listenery na scroll, resize, input powinny być ograniczone częstotliwościowo. Nie potrzebujesz reagować 60 razy na sekundę na scrollowanie strony.
  5. Unikaj dużych reflow/repaint — operacje na DOM, które zmieniają układ strony (dodawanie elementów, zmiana rozmiaru, animacje CSS na właściwości jak width/height) wymuszają przeliczenie layoutu. Preferuj animacje na transform i opacity, które nie powodują reflow.

Jak sprawdzić Core Web Vitals swojej strony?

Google udostępnia kilka narzędzi — każde mierzy trochę inaczej i każde ma swoje zastosowanie:

Dane terenowe (field data) vs. dane laboratoryjne (lab data)

To fundamentalne rozróżnienie, które wiele osób pomija:

  • Dane terenowe — zebrane od prawdziwych użytkowników Chrome przez ostatnie 28 dni. Google używa TYCH danych do oceny Twojej strony. Znajdziesz je w Google Search Console (raport „Core Web Vitals”) i w PageSpeed Insights (sekcja „Discover what your real users are experiencing”).
  • Dane laboratoryjne — symulacja na konkretnym urządzeniu i połączeniu. Przydatne do diagnozy problemów, ale nie odzwierciedlają realnego doświadczenia użytkowników. Lighthouse, PageSpeed Insights (dolna sekcja), Chrome DevTools.

Optymalizuj pod dane terenowe — bo to one wpływają na ranking. Ale diagnozuj problemy danymi laboratoryjnymi — bo są powtarzalne i łatwiejsze do analizy.

Narzędzia, których powinieneś używać

  1. Google Search Console → raport „Core Web Vitals” — pokazuje, ile Twoich stron spełnia progi, ile wymaga poprawy, a ile jest słabych. Grupuje strony po problemach. To powinien być Twój punkt wyjścia.
  2. PageSpeed Insights (pagespeed.web.dev) — wpisujesz URL, dostajesz ocenę terenową i laboratoryjną. Pokazuje konkretne problemy i sugestie naprawy, posortowane po potencjalnym wpływie.
  3. Chrome DevTools → zakładka Performance — nagraj interakcję na stronie i przeanalizuj, co blokuje wątek główny. Zaawansowane, ale niezbędne przy debugowaniu INP.
  4. Web Vitals Extension — rozszerzenie Chrome, które na żywo pokazuje LCP, CLS i INP podczas przeglądania strony. Szybki sposób na monitoring bez otwierania dodatkowych narzędzi.

Core Web Vitals a ranking — jak duży jest wpływ?

Pytanie, które wszyscy zadają: „czy Core Web Vitals naprawdę wpływają na pozycje?” Odpowiedź jest: tak, ale to nie jest najsilniejszy czynnik rankingowy.

Google sam mówi, że CWV to tiebreaker — czynnik, który rozstrzyga remis. Jeśli dwie strony mają podobną jakość treści i podobny profil linkowy — szybsza wygrywa. Treść i linki wciąż są ważniejsze od szybkości.

Ale w praktyce sytuacja jest bardziej złożona. Wolna strona powoduje:

  • Wyższy bounce rate — użytkownicy odchodzą, zanim strona się załaduje
  • Krótszy czas na stronie — frustracja = szybkie opuszczenie
  • Mniej konwersji — badania Google pokazują, że każda dodatkowa sekunda ładowania obniża konwersję o 7%
  • Pogo-sticking — użytkownicy wracają do wyników Google po sekundzie, co jest sygnałem, że wynik nie spełnia oczekiwań

Te pośrednie efekty mają realny wpływ na ranking. Core Web Vitals to nie tylko trzy metryki — to przybliżenie tego, jak użytkownicy odbierają Twoją stronę.

Typowe problemy polskich stron i jak je naprawić

Po przeanalizowaniu dziesiątek stron polskich firm, widzę powtarzające się wzorce:

Problem 1: Page builder + 40 pluginów

Strony zbudowane na Divi, Elementorze czy WPBakery z dziesiątkami pluginów ładują megabajty CSS i JS, z których strona używa może 10%. LCP 5-8 sekund to norma.

Rozwiązanie: albo optymalizuj (usuwaj nieużywane pluginy, ładuj CSS/JS warunkowo), albo — przy poważnym podejściu — przebuduj na lekki, customowy theme. Strona na czystym PHP + CSS waży 10-20 razy mniej niż ta sama strona na page builderze.

Problem 2: Niezoptymalizowane zdjęcia

Zdjęcia prosto z aparatu — 4000×3000 px, 5 MB, format JPEG. Ładowane na telefonie, gdzie ekran ma 375 px szerokości.

Rozwiązanie: WebP/AVIF, max 1920px szerokości, srcset dla responsywnych wariantów, lazy loading poniżej fold. Plugin ShortPixel lub Imagify zrobi to automatycznie w WordPressie.

Problem 3: Tani hosting

Hosting za 15 PLN/miesiąc z TTFB 1-2 sekundy. Żadna optymalizacja frontendowa nie pomoże, jeśli serwer odpowiada wolno.

Rozwiązanie: hosting z LiteSpeed, PHP OPcache, HTTP/2 i SSD. W Polsce przyzwoite opcje zaczynają się od 30-50 PLN miesięcznie. Różnica w TTFB jest dramatyczna — z 1500 ms do 200 ms.

Problem 4: Fonty blokujące renderowanie

Pięć wariantów Google Fonts ładowanych synchronicznie w <head>. Przeglądarka czeka na fonty, zanim wyświetli cokolwiek.

Rozwiązanie: ładuj fonty z atrybutem media="print" onload="this.media='all'" (async). Ogranicz się do 2 wariantów (regular + bold). Hostuj fonty lokalnie zamiast z Google CDN — eliminujesz dodatkowe połączenie DNS.

Core Web Vitals a WordPress — praktyczne wskazówki

WordPress to najpopularniejszy CMS na świecie i jednocześnie platforma, na której najłatwiej o kiepskie Core Web Vitals. Oto co możesz zrobić:

  • Caching — zainstaluj plugin cache (WP Super Cache, LiteSpeed Cache, W3 Total Cache). Strona generowana z cache ładuje się kilkukrotnie szybciej.
  • Minimalizacja CSS/JS — Autoptimize lub LiteSpeed Cache automatycznie minimalizują i łączą pliki.
  • Wyłącz zbędne skrypty — WordPress ładuje emoji, Gutenberg CSS, jQuery Migrate i inne skrypty, których wiele stron nie potrzebuje. Wyłącz je programistycznie w functions.php lub pluginem.
  • Używaj nowoczesnych formatów obrazów — od WP 6.1 WordPress wspiera WebP natywnie. Ale konwersja starych obrazów wymaga pluginu.
  • Ogranicz pluginy — każdy plugin dodaje CSS, JS, zapytania do bazy danych. 50 pluginów = wolna strona. Redukcja do niezbędnego minimum to jeden z najskuteczniejszych sposobów na poprawę CWV.

Jak monitorować Core Web Vitals na bieżąco?

Optymalizacja CWV to nie jednorazowe działanie — to ciągły proces. Nowy plugin, nowa treść, zmiana szablonu — każda z tych rzeczy może pogorszyć wyniki.

  1. Google Search Console — sprawdzaj raport „Core Web Vitals” raz w miesiącu. Zwracaj uwagę na trendy i nagłe pogorszenia.
  2. Alerty PageSpeed — ustaw monitoring w narzędziu typu DebugBear lub SpeedCurve, żeby dostawać alerty, gdy wyniki się pogarszają.
  3. Po każdej zmianie — dodajesz nowy plugin? Sprawdź CWV przed i po. Zmieniasz szablon? Sprawdź CWV. To trwa 2 minuty w PageSpeed Insights.

Podsumowanie — checklist Core Web Vitals

Zanim zamkniesz ten artykuł, oto lista kontrolna. Jeśli Twoja strona spełnia wszystkie te punkty — Twoje Core Web Vitals powinny być w zieleni:

  • Zdjęcia w formacie WebP/AVIF, skompresowane, z atrybutami width/height
  • Lazy loading na obrazach poniżej fold (ale NIE na hero)
  • Preload na zdjęciu hero i krytycznym foncie
  • Fonty ładowane asynchronicznie, max 2 warianty
  • CSS krytyczny inline, reszta asynchronicznie
  • JavaScript z defer, bez zbędnych bibliotek
  • Kompresja Gzip/Brotli na serwerze
  • TTFB poniżej 600 ms (hosting z LiteSpeed/OPcache)
  • Cache na serwerze i/lub plugin cache
  • Baner cookies jako overlay (position: fixed), nie push
  • Zarezerwowane miejsce na embedy i dynamiczne elementy
  • Minimum third-party scripts

Szybka strona to nie luksus — to warunek, żeby w ogóle grać w grę o wysokie pozycje w Google. Jeśli Twoja konkurencja ma stronę ładującą się w 1,5 sekundy, a Twoja w 6 sekund — tracisz nie tylko pozycje, ale i klientów, którzy nie chcą czekać.

Nie wiesz, co spowalnia Twoją stronę? Umów się na darmową konsultację — sprawdzimy Core Web Vitals Twojej strony, zidentyfikujemy konkretne problemy i pokażemy, co naprawić, żeby strona działała szybko i dobrze wyglądała w oczach Google. Bez zobowiązań, bez technicznego żargonu — konkrety w 30 minut.