Klient klika Twoją stronę w wynikach Google. Przez kilka sekund widzi pusty ekran, potem tekst nagle przeskakuje, bo doładował się baner, a przycisk „Wyślij zapytanie” reaguje z opóźnieniem. Jest spora szansa, że wróci do wyników wyszukiwania i wybierze konkurencję. Core Web Vitals to sposób, w jaki Google próbuje zmierzyć właśnie takie sytuacje.
Czym są Core Web Vitals?
Core Web Vitals (w skrócie CWV) to trzy wskaźniki opracowane przez Google. Każdy z nich opisuje inny aspekt komfortu korzystania ze strony:
- szybkość ładowania: jak szybko pojawia się główna treść,
- responsywność: jak szybko strona reaguje na kliknięcia i dotknięcia,
- stabilność wizualna: czy elementy nie przesuwają się nieoczekiwanie podczas ładowania.
Wskaźniki są częścią szerszego zestawu sygnałów doświadczenia na stronie (page experience), obok m.in. obsługi HTTPS i braku natrętnych reklam pełnoekranowych. Google ocenia je przede wszystkim na podstawie danych od prawdziwych użytkowników, a nie wyłącznie testów laboratoryjnych. Jeśli któryś termin jest nowy, zajrzyj do naszego słownika SEO.
LCP, INP i CLS: co mierzą i jakie są progi
| Wskaźnik | Co mierzy | Dobry | Wymaga poprawy | Słaby |
|---|---|---|---|---|
| LCP Largest Contentful Paint | Czas wyświetlenia największego elementu treści w widocznym obszarze (np. zdjęcia w nagłówku lub dużego bloku tekstu). | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP Interaction to Next Paint | Opóźnienie między interakcją użytkownika (kliknięcie, dotknięcie, naciśnięcie klawisza) a wizualną reakcją strony. | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS Cumulative Layout Shift | Skala nieoczekiwanych przesunięć układu strony w trakcie jej używania. | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Strona jest uznana za „dobrą”, gdy próg spełnia co najmniej 75% wizyt (tzw. 75. percentyl), osobno na telefonach i komputerach. Nie wystarczy więc, że strona działa szybko na nowym laptopie podłączonym do światłowodu. Musi też sprawnie działać na przeciętnym telefonie z mobilnym internetem.
INP zastąpił FID. W marcu 2024 roku wskaźnik INP oficjalnie zastąpił wcześniejszy FID (First Input Delay). FID mierzył tylko opóźnienie pierwszej interakcji, a INP bierze pod uwagę responsywność w trakcie całej wizyty. Jest więc znacznie bardziej wymagający.
Jak szybkość strony wpływa na SEO?
Google potwierdza, że Core Web Vitals są wykorzystywane przez jego systemy rankingowe. Jednocześnie podkreśla, że najważniejsza pozostaje trafność i jakość treści. W praktyce świetne wyniki CWV nie wypromują słabej strony, ale przy porównywalnej jakości treści lepsze doświadczenie użytkownika może dać przewagę.
Szybkość wpływa na SEO także pośrednio, i to bywa ważniejsze niż sam sygnał rankingowy:
- użytkownicy rzadziej porzucają szybką stronę i chętniej przechodzą do kolejnych podstron,
- lekką, sprawnie działającą witrynę roboty wyszukiwarki skanują łatwiej i częściej,
- dobra wersja mobilna ma szczególne znaczenie, bo Google indeksuje strony przede wszystkim w wersji mobilnej (mobile-first indexing).
Jak szybkość wpływa na sprzedaż?
Nawet gdyby Core Web Vitals nie miały żadnego wpływu na pozycje, warto o nie zadbać ze względów czysto biznesowych. Każda sekunda czekania to okazja, żeby się rozmyślić. Przesuwające się elementy powodują przypadkowe kliknięcia i frustrację. Formularz, który reaguje z opóźnieniem, wygląda na zepsuty. A klient, który ma wątpliwości co do działania strony, ma też wątpliwości co do firmy.
W sklepach internetowych przekłada się to na porzucone koszyki, a na stronach usługowych na mniejszą liczbę zapytań. Dlatego optymalizację wydajności traktujemy jako element każdego projektu tworzenia stron internetowych i sklepów online, a nie dodatek „na później”.
Jak zmierzyć Core Web Vitals?
Warto rozróżniać dwa rodzaje danych:
- Dane terenowe (field data) zbiera Chrome od prawdziwych użytkowników i publikuje w raporcie CrUX (Chrome User Experience Report). To na nich opiera się ocena Google. Obejmują ostatnie 28 dni, więc efekty poprawek widać z opóźnieniem.
- Dane laboratoryjne (lab data) to wynik testu w kontrolowanych warunkach, np. w Lighthouse. Świetnie nadają się do diagnozowania problemów i sprawdzania poprawek od razu po wdrożeniu.
| Narzędzie | Do czego służy |
|---|---|
| PageSpeed Insights | Szybki test pojedynczego adresu: dane terenowe z CrUX (jeśli strona ma wystarczający ruch) oraz audyt Lighthouse z listą rekomendacji. |
| Google Search Console | Raport „Podstawowe wskaźniki internetowe”, który grupuje adresy URL całej witryny według stanu: dobre, wymagające poprawy i słabe. |
| Lighthouse | Audyt laboratoryjny dostępny w Chrome DevTools. Nie mierzy INP bezpośrednio, a jako przybliżenie podaje Total Blocking Time (TBT). |
| Chrome DevTools (panel Performance) | Szczegółowa analiza ładowania i interakcji: długie zadania JavaScript, element LCP, źródła przesunięć układu. |
Zacznij od Search Console. Raport pokazuje, które grupy podstron mają problem i z którym wskaźnikiem. Dopiero potem diagnozuj konkretne adresy w PageSpeed Insights i DevTools.
Jak czytać raport PageSpeed Insights?
Raport PageSpeed Insights bywa mylący, bo na jednym ekranie łączy dwa różne źródła danych. Czytaj go od góry:
- Sekcja z doświadczeniami prawdziwych użytkowników to dane terenowe z CrUX. Jeśli widzisz tu ocenę „zaliczone” dla podstawowych wskaźników, strona spełnia progi Google, nawet gdy wynik punktowy poniżej nie jest idealny.
- Przełącznik „ta strona / cała domena”: przy mniejszym ruchu dane mogą być dostępne tylko dla całej domeny, a nie dla konkretnego adresu.
- Wynik diagnostyczny Lighthouse (0–100) pochodzi z testu w symulowanych warunkach, zwykle z ograniczoną przepustowością i wolniejszym procesorem. Służy do znajdowania problemów, a nie do oceny w rankingu.
- Możliwości i diagnostyka to konkretne rekomendacje, np. „Zmniejsz nieużywany JavaScript” albo „Wyświetlaj obrazy w nowoczesnych formatach”. Zawsze sprawdzaj, którego wskaźnika dotyczy dana sugestia.
Testuj przede wszystkim wersję mobilną. To ją Google bierze pod uwagę w pierwszej kolejności, a wyniki na telefonach są zwykle wyraźnie słabsze niż na komputerach.
Najczęstsze przyczyny słabych wyników
| Przyczyna | Wskaźnik | Typowe rozwiązanie |
|---|---|---|
| Duże, nieskompresowane zdjęcia w nagłówku | LCP | WebP/AVIF, właściwe wymiary, srcset, priorytet ładowania |
| Wolny serwer, brak buforowania | LCP | Wydajniejszy hosting, cache stron, CDN |
| Slider lub karuzela na pierwszym ekranie | LCP, CLS | Statyczny nagłówek z jednym, zoptymalizowanym obrazem |
| Wiele skryptów zewnętrznych (czaty, piksele, widżety) | INP, LCP | Przegląd i opóźnione ładowanie skryptów |
| Rozbudowane wtyczki i kreatory stron | INP, LCP | Mniej wtyczek, lżejszy motyw, dedykowany kod |
| Obrazy i ramki iframe bez wymiarów | CLS | Atrybuty width/height lub aspect-ratio |
| Banery i komunikaty wstawiane nad treścią | CLS | Zarezerwowane miejsce lub nakładka, która nie przesuwa układu |
Jak poprawić LCP
Na LCP składa się czas odpowiedzi serwera, pobranie zasobów blokujących renderowanie i załadowanie samego elementu LCP, najczęściej dużego zdjęcia. Najskuteczniejsze działania:
- Szybki serwer i cache. Wydajny hosting, buforowanie stron i w razie potrzeby CDN skracają czas do pierwszego bajtu (TTFB).
- Optymalizacja obrazów. Nowoczesne formaty (WebP, AVIF), właściwe wymiary i atrybut
srcsetsprawiają, że telefon nie pobiera zdjęcia przygotowanego dla monitora 4K. - Priorytet dla elementu LCP. Nie stosuj leniwego ładowania (
loading="lazy") dla głównego zdjęcia u góry strony. Rozważfetchpriority="high"lub preload. - Mniej zasobów blokujących. Ogranicz i odrocz pliki CSS i JavaScript, które nie są potrzebne do wyświetlenia pierwszego ekranu.
- Fonty. Hostuj je lokalnie, ładuj tylko potrzebne odmiany i używaj
font-display: swap.
Jak poprawić INP
Słaby INP prawie zawsze oznacza, że główny wątek przeglądarki jest zajęty wykonywaniem JavaScriptu w chwili, gdy użytkownik próbuje coś kliknąć. Co pomaga:
- Mniej JavaScriptu. Usuń nieużywane skrypty i zrezygnuj z ciężkich bibliotek tam, gdzie wystarczy kilka linijek kodu.
- Dzielenie długich zadań. Operacje trwające dłużej niż 50 ms blokują interakcję. Rozbij je na mniejsze części, żeby przeglądarka mogła w międzyczasie reagować.
- Skrypty zewnętrzne pod kontrolą. Czaty, piksele reklamowe, widżety i mapy ładuj z opóźnieniem albo dopiero po interakcji.
- Mniejszy DOM. Rozbudowane, wielokrotnie zagnieżdżone struktury HTML spowalniają każdą aktualizację widoku.
- Natychmiastowa informacja zwrotna. Pokaż stan „wysyłanie…” od razu po kliknięciu, a ciężkie obliczenia wykonaj później.
Jak poprawić CLS
Przesunięcia układu najczęściej biorą się z elementów, które pojawiają się na stronie bez zarezerwowanego miejsca. Rozwiązania są zwykle proste:
- podawaj atrybuty
widthiheight(lubaspect-ratio) dla zdjęć, filmów i ramek iframe, - rezerwuj miejsce na banery, reklamy, osadzone treści i komunikaty o cookies,
- nie wstawiaj nowych elementów nad treścią, którą użytkownik już czyta,
- animuj elementy za pomocą właściwości
transformiopacity, a nie przez zmianę wymiarów czy położenia, - ogranicz „przeskok” tekstu przy ładowaniu fontów, dobierając podobny font zastępczy.
Przykład: od czego zaczęlibyśmy na typowej stronie firmowej
Weźmy przykładową stronę usługową, jakich wiele: slider z trzema dużymi zdjęciami na górze, motyw z kreatorem stron, kilkanaście wtyczek, czat na żywo, piksel reklamowy i mapa Google w stopce. W PageSpeed Insights na telefonie LCP przekracza 4 sekundy, a INP jest w strefie „wymaga poprawy”. Kolejność prac zwykle wygląda tak:
- Pierwszy ekran. Slider zamieniamy na jeden statyczny nagłówek ze zdjęciem w WebP, w kilku rozmiarach i z wysokim priorytetem ładowania. To często największa pojedyncza poprawa LCP.
- Skrypty zewnętrzne. Czat ładujemy dopiero po kliknięciu ikony, mapę zastępujemy statycznym obrazem z linkiem, a piksel uruchamiamy po wyświetleniu treści.
- Wtyczki. Usuwamy te, które dublują funkcje albo nie są używane, i sprawdzamy, które ładują swoje pliki na każdej podstronie.
- Serwer i cache. Włączamy buforowanie stron, kompresję i sprawdzamy czas odpowiedzi serwera.
- Pomiar. Po każdym kroku robimy test laboratoryjny, a po około czterech tygodniach sprawdzamy dane terenowe w Search Console.
To przykład, a nie gotowa recepta. Na innej stronie największym problemem może być np. ciężki motyw albo wolny serwer. Dlatego zaczynamy od pomiaru, a nie od zmian „na wyczucie”.
Core Web Vitals a WordPress
WordPress może być bardzo szybki, jeśli jest dobrze zbudowany. Problemy z wydajnością rzadko wynikają z samego systemu. Znacznie częściej powodują je nadmiar wtyczek, ciężkie motywy i kreatory generujące dużo kodu, zdjęcia wgrywane prosto z aparatu oraz słaby hosting.
Dlatego przy wdrożeniach na WordPressie stawiamy na lekki, dedykowany kod, minimalną liczbę wtyczek, automatyczną optymalizację obrazów, buforowanie i serwer dobrany do skali strony. Jeśli Twoja obecna witryna jest wolna, zwykle nie trzeba zaczynać od zera. Audyt SEO z częścią techniczną wskazuje kilka największych problemów, których usunięcie daje najszybszy efekt.
Szybkość w sklepie internetowym
W sklepie problem rzadko dotyczy jednej strony. Najczęściej wolne są całe typy podstron: listing kategorii z filtrami, karta produktu z galerią albo koszyk z dodatkowymi skryptami płatności i dostaw. Dlatego testy warto robić na każdym szablonie osobno.
- Kategorie: ogranicz liczbę produktów ładowanych naraz i sprawdź, czy filtry nie przeładowują całej strony.
- Karta produktu: pierwsze zdjęcie galerii ładuj z priorytetem, kolejne leniwie. Rezerwuj miejsce na warianty, ceny i opinie.
- Koszyk i zamówienie: skrypty bramek płatniczych i map punktów odbioru uruchamiaj tylko tam, gdzie są potrzebne.
Wybór platformy też ma znaczenie. Różnice między popularnymi rozwiązaniami opisujemy w porównaniu WooCommerce, Shopify i PrestaShop.
Optymalizacja czy nowa strona?
Jeśli strona ma kilka lat, ciężki motyw i dziesiątki wtyczek, czasem łatwiej zbudować ją od nowa niż łatać w nieskończoność. Zwykle sygnałem jest to, że po usunięciu oczywistych problemów wyniki dalej są słabe, a każda zmiana psuje coś innego. Wtedy warto rozważyć redesign strony. Przy przenosinach pamiętaj o przekierowaniach i zachowaniu treści, o czym piszemy w poradniku o migracji strony bez utraty pozycji.
Jak sprawdzić, czy poprawki przyniosły efekt biznesowy?
Lepszy wynik w PageSpeed Insights to dopiero połowa odpowiedzi. Druga połowa to pytanie, czy więcej osób wysyła formularz, dzwoni albo kupuje. Porównaj współczynnik konwersji i liczbę zapytań w tym samym okresie przed zmianami i po nich, najlepiej osobno dla ruchu mobilnego. Jak ustawić taki pomiar w GA4 i Search Console, pokazujemy w artykule o pomiarze efektów strony.
Plan działania: od czego zacząć?
- Sprawdź raport podstawowych wskaźników w Google Search Console i ustal, który wskaźnik wypada najsłabiej.
- Przetestuj w PageSpeed Insights najważniejsze szablony: stronę główną, podstronę usługi, kartę produktu, wpis na blogu.
- Znajdź element LCP na każdym szablonie i zoptymalizuj go w pierwszej kolejności.
- Przejrzyj skrypty zewnętrzne i wtyczki. Usuń zbędne, resztę odrocz.
- Dodaj wymiary do wszystkich obrazów i osadzonych elementów.
- Sprawdź wydajność hostingu i włącz buforowanie.
- Po wdrożeniu poprawek obserwuj dane terenowe. Pełny obraz zobaczysz po około czterech tygodniach.
Podsumowanie
Core Web Vitals to nie techniczna ciekawostka, tylko miara tego, jak klienci odbierają Twoją stronę. Dobre wyniki pomagają w SEO, ale przede wszystkim przekładają się na więcej zapytań i sprzedaży. Jeśli chcesz wiedzieć, jak wypada Twoja witryna i co konkretnie poprawić, napisz do nas, a przygotujemy bezpłatną analizę. Szybkość to także jeden z filarów skutecznego pozycjonowania stron, o którym piszemy również w poradniku o pozycjonowaniu lokalnym.