Core Web Vitals opisują trzy części doświadczenia na stronie: moment pokazania głównej treści, szybkość reakcji po interakcji i stabilność układu. Obecny zestaw obejmuje LCP, INP i CLS. Wynik ma sens dopiero wtedy, gdy wiadomo, czy pochodzi od prawdziwych użytkowników, czy z testu laboratoryjnego, jakiego adresu dotyczy i który element strony odpowiada za problem.
- LCP: nie więcej niż 2,5 sekundy.
- INP: poniżej 200 milisekund.
- CLS: nie więcej niż 0,1.
Ocena dotyczy 75. percentyla wizyt, osobno dla urządzeń mobilnych i stacjonarnych. Spełnienie progów nie zastępuje testu funkcji, treści, dostępności ani całego UX.
LCP, INP i CLS mierzą różne problemy
Largest Contentful Paint wskazuje czas wyrenderowania największego kwalifikującego się elementu treści w obszarze widocznym na początku. Często jest nim zdjęcie otwierające, duży nagłówek albo blok tekstu. LCP nie mówi, kiedy strona pobrała ostatni plik. Pomaga ocenić moment, w którym główna treść pierwszego widoku stała się widoczna.
Wynik LCP tworzy cały łańcuch: odpowiedź dokumentu, odkrycie zasobu, pobranie i render. Jeśli duży obraz pojawia się późno, przyczyną może być wolny serwer, ukrycie adresu w skrypcie, niewłaściwy priorytet, ciężki plik lub CSS blokujący wyświetlenie. Kompresja obrazu pomaga tylko w części przypadków. Najpierw trzeba znaleźć etap, na którym powstaje opóźnienie.
Interaction to Next Paint ocenia responsywność po interakcjach użytkownika, takich jak kliknięcie, dotknięcie lub użycie klawiatury. Uwzględnia opóźnienie wejścia, czas przetwarzania i możliwość pokazania kolejnej klatki. INP nie jest testem szybkości samej animacji. Wysoka wartość oznacza, że przeglądarka przez dłuższy czas nie mogła dać widocznej odpowiedzi.
Cumulative Layout Shift opisuje nieoczekiwane przesunięcia widocznych elementów. Problemem jest na przykład przycisk uciekający spod kursora, gdy nad nim pojawia się baner, albo akapit spychany przez obraz bez zarezerwowanego miejsca. Zmiana po świadomej interakcji nie zawsze jest błędem. Liczą się przesunięcia, których użytkownik nie przewidział i które utrudniają wykonanie zadania.
| Wskaźnik | Dobry próg | Pytanie diagnostyczne |
|---|---|---|
| LCP | ≤ 2,5 s | Dlaczego główny element pojawia się za późno? |
| INP | < 200 ms | Co zajmuje główny wątek po działaniu użytkownika? |
| CLS | ≤ 0,1 | Który element zmienia położenie bez rezerwacji miejsca? |
Progi są wspólne, lecz droga do poprawy zależy od szablonu. Ten sam serwis może mieć dobry wynik wpisów i słaby stron kategorii. Osobno traktuj mobile oraz desktop, bo różnią się mocą urządzenia, szerokością, siecią i układem. Nie uśredniaj problemu w jedną ocenę dla domeny, jeśli narzędzie pokazuje konkretne grupy adresów.
Core Web Vitals są jednym z sygnałów doświadczenia strony w wyszukiwarce, ale dobry wynik nie gwarantuje wysokiej pozycji. Nie zastępuje odpowiedzi na intencję, jakości treści, indeksowalności, architektury i reputacji. Praca nad wskaźnikami ma największy sens wtedy, gdy poprawia realne korzystanie z serwisu, a nie tylko kolor pojedynczego raportu.
Dane terenowe i laboratoryjne odpowiadają na inne pytania
Dane terenowe pochodzą z wizyt rzeczywistych użytkowników. Zawierają różne telefony, sieci, lokalizacje i zachowania. Pokazują rozkład doświadczeń w określonym okresie, dlatego reagują wolniej na wdrożenie. Są podstawą oceny tego, co faktycznie przeżywa grupa odbiorców, lecz nie zawsze wskażą plik lub funkcję odpowiedzialną za opóźnienie.
Dane laboratoryjne powstają w kontrolowanym teście. Można go powtórzyć, śledzić żądania, zadania głównego wątku i kolejność renderowania. To dobre środowisko do diagnozy i porównania wersji przed publikacją. Nie jest jednak reprezentatywnym zapisem wszystkich użytkowników. Wynik zależy od profilu urządzenia, ograniczenia sieci, lokalizacji i chwilowej odpowiedzi serwera.
Rozbieżność nie oznacza, że jedno źródło kłamie. Laboratorium może testować pusty cache i wolny profil telefonu, podczas gdy część odbiorców wraca na szybkim urządzeniu. Z drugiej strony pojedynczy test wykonany na komputerze redaktora może wyglądać świetnie, choć użytkownicy mobilni nadal doświadczają blokady skryptu. Zapisuj źródło wyniku i nie przenoś wniosku między populacjami bez sprawdzenia.
Przy małym ruchu raport terenowy może nie mieć wystarczających danych dla konkretnego URL-a. Narzędzie może pokazać grupę podobnych stron albo wynik całego źródła. Wtedy laboratorium i własny pomiar użytkowników pomagają budować obraz, ale nie należy udawać precyzji, której nie ma. Opisz zakres i poziom agregacji w raporcie.
Zmiana wdrożona dzisiaj może od razu poprawić test kontrolowany, natomiast okno danych terenowych odświeża się stopniowo. Nie cofaj działającej poprawki tylko dlatego, że raport grupowy nie zmienił koloru po jednym dniu. Najpierw upewnij się, że nowa wersja jest publiczna, cache został odświeżony i metryka mierzona lokalnie rzeczywiście spadła.
Raport strony głównej nie jest raportem wpisu, kategorii, formularza ani strony docelowej kampanii. Mierz reprezentatywne szablony oraz trasy o znaczeniu biznesowym. Dopiero wtedy priorytety odpowiadają realnemu ruchowi.
Jak znaleźć przyczynę słabego LCP, INP lub CLS
Przy LCP zacznij od identyfikacji elementu wskazanego przez narzędzie. Jeśli to obraz, sprawdź, czy jego adres znajduje się wcześnie w HTML, czy nie jest lazy-loadowany, jaki ma rozmiar, format oraz priorytet. Jeśli to tekst, zbadaj odpowiedź serwera, arkusze stylów i fonty. Jeżeli element zmienia się między testami, przeanalizuj warianty widoku i treści, zamiast optymalizować tylko jeden przypadek.
Rozbij czas LCP na etapy. Wolny dokument kieruje uwagę na hosting, PHP, bazę i cache. Późne rozpoczęcie pobrania zasobu sugeruje sposób odkrywania lub kolejność priorytetów. Długie pobieranie wskazuje rozmiar, sieć albo serwer pliku. Opóźnienie renderowania może wynikać z CSS, fontu, animacji wejścia lub JavaScriptu ukrywającego element. Taki podział chroni przed przypadkową listą zmian.
Przy wysokim INP odtwórz konkretną interakcję: otwarcie menu, wybór filtra, wpisanie tekstu, dodanie do koszyka. Obejrzyj ślad głównego wątku i długie zadania. Częstą przyczyną jest zbyt dużo pracy synchronicznej, rozbudowane nasłuchiwanie zdarzeń, kosztowne przeliczanie układu lub zewnętrzny skrypt. Podziel długą pracę, ogranicz zakres aktualizacji DOM i pozwól przeglądarce wcześniej pokazać reakcję.
Nie poprawiaj INP przez usunięcie widocznego stanu bez rozwiązania zadania. Użytkownik potrzebuje potwierdzenia kliknięcia, informacji o ładowaniu i wyniku. Czasami właściwą zmianą jest szybka odpowiedź interfejsu oraz przeniesienie cięższej operacji poza krytyczny moment. Przy formularzu zachowaj blokadę wielokrotnego wysłania i komunikat o błędzie.
Przy CLS obserwuj nagranie lub warstwy przesunięć. Dodaj wymiary obrazom, proporcje osadzeniom i stałe miejsce na banery, komunikaty oraz reklamy. Font zastępczy powinien mieć zbliżone metryki, aby tekst nie przełamywał się gwałtownie po pobraniu kroju. Nie wstawiaj nowej treści ponad aktualnym miejscem czytania, jeśli nie wynika to bezpośrednio z działania użytkownika.
Porównuj stan przed i po na tej samej trasie. Jeśli optymalizacja LCP zwiększyła CLS, wynik całościowy nie jest poprawą. Podobnie agresywne opóźnienie skryptu może skrócić pierwszy widok i pogorszyć pierwsze użycie menu. Metryki trzeba traktować razem z funkcją, dostępnością i zatwierdzonym wyglądem.
- Dokładny URL, szablon, urządzenie i warunki testu.
- Źródło wyniku: terenowe lub laboratoryjne.
- Element LCP, interakcja INP albo węzeł powodujący CLS.
- Hipoteza oparta na śladzie, żądaniu lub zachowaniu renderu.
- Jedna zmiana i wynik porównawczy.
- Test funkcji oraz wyglądu po wdrożeniu.
Co najczęściej psuje Core Web Vitals w WordPressie
W WordPressie problem często nie leży w samym rdzeniu, lecz w połączeniu motywu, buildera, wtyczek, treści i hostingu. Duże zdjęcie otwierające przesłane bez wariantów może pogorszyć LCP. Slider ładowany po inicjalizacji skryptu opóźnia odkrycie obrazu. Pasek informacji dodany bez miejsca zwiększa CLS, a rozbudowany pakiet filtrów może blokować reakcję po kliknięciu.
Wtyczka optymalizacyjna potrafi pomóc, ale jej domyślny zestaw ustawień nie zna wszystkich zależności witryny. Opóźnienie skryptów może zepsuć nawigację, formularz, zgodę cookies lub analitykę. Usunięcie nieużywanego CSS może błędnie wyciąć style stanu otwieranego dopiero po interakcji. Wprowadzaj funkcje pojedynczo i testuj kilka typów stron, nie tylko ekran startowy.
Obraz LCP powinien być przygotowany w rozmiarze odpowiadającym kontenerowi i wariantom responsywnym. Nie należy go ukrywać w tle ładowanym dopiero przez późny CSS, jeśli można umieścić semantyczny obraz w dokumencie. Nie ustawiaj lazy loadingu dla kluczowego elementu pierwszego widoku. Obrazy niżej mogą korzystać z leniwego ładowania, o ile zachowują stabilne proporcje.
Motyw i komponenty powinny ładować zasoby tylko tam, gdzie są potrzebne. Biblioteka slidera nie musi działać na każdym wpisie, a skrypt formularza na stronie bez formularza. Ten podział redukuje transfer i pracę głównego wątku. Przed usunięciem zależności sprawdź widoki warunkowe, wersję mobilną i elementy otwierane dopiero po kliknięciu.
Na wynik wpływa także redakcja. Wielki GIF, tabela wklejona z obcymi stylami albo kilka osadzonych filmów może zmienić wydajność pojedynczego poradnika. Wprowadź zasady wymiarów, formatów, kadrowania i osadzeń. Podgląd w edytorze nie wystarczy; po publikacji sprawdź publiczny adres oraz to, jakie pliki rzeczywiście pobiera przeglądarka.
Strony docelowe kampanii wymagają dodatkowej uwagi, ponieważ tagi reklamowe, mapy ciepła, testy A/B i widżety mogą konkurować z treścią. Jeśli wynik dotyczy płatnego ruchu, audyt strony docelowej kampanii Google Ads powinien łączyć szybkość z czytelnością oferty, działaniem formularza i pomiarem konwersji. Sama redukcja czasu nie naprawi niejasnej decyzji użytkownika.
Techniczną kolejność optymalizacji rozwija poradnik jak przyspieszyć WordPressa. Jeśli raport wskazuje problemy po aktualizacji lub zmianie motywu, sprawdź także kopie, logi i procedury opisane w materiale o tym, jak zabezpieczyć WordPressa.
Plan poprawy bez pogoni za przypadkowym wynikiem
Utwórz listę szablonów według ruchu i znaczenia. Dla każdego zapisz wynik terenowy, wynik kontrolowany, dominujący problem oraz właściciela zmiany. Priorytet otrzymują trasy, które mają słabe doświadczenie i wpływają na ważne zadanie użytkownika. To rozsądniejsze niż wielodniowa optymalizacja rzadko odwiedzanej strony tylko dlatego, że łatwo osiągnąć na niej zielony wynik.
Jedna iteracja powinna mieć hipotezę: „obraz otwierający zaczyna pobieranie za późno, ponieważ jest wstawiany przez skrypt”. Następnie zmianę: umieszczenie zasobu w początkowym dokumencie z właściwym priorytetem. Potem dowód: ślad sieciowy, poprawiony czas i brak regresji układu. Tak sformułowana praca jest audytowalna i pozwala odróżnić przyczynę od korelacji.
Testuj na stagingu, ale potwierdzaj na produkcji, bo infrastruktura, cache, zgody i skrypty mogą się różnić. Przy publikacji kontroluj najważniejsze funkcje, konsolę, błędy sieciowe i screenshoty desktop/mobile. Jeżeli optymalizacja zmienia render względem zaakceptowanego projektu, nie jest automatycznie sukcesem. Trzeba znaleźć rozwiązanie wydajnościowe zachowujące kompozycję.
Po wdrożeniu odczekaj na dane terenowe, jednocześnie obserwując własny pomiar. Zapisuj wersję, datę i zakres. Gdy pojawi się regresja, historia pozwoli wskazać aktualizację wtyczki, nowy skrypt lub zmianę treści. Bez rejestru zespół wraca do losowego włączania i wyłączania ustawień.
Ustal budżety: maksymalny rozmiar obrazu otwierającego, liczbę i wagę fontów, zasady skryptów zewnętrznych oraz próg, przy którym zmiana wymaga poprawy przed publikacją. Budżet ma odzwierciedlać realny projekt i funkcję, a nie arbitralną liczbę skopiowaną z innego serwisu. Jeśli nowy element przekracza koszt, osoba wdrażająca powinna wskazać, co usuwa albo dlaczego korzyść uzasadnia wyjątek.
Wyniki warto przeglądać po większych wydaniach i okresowo, ponieważ portal zmienia się przez treść, integracje oraz aktualizacje. Monitorowanie nie zastępuje diagnozy, ale wcześniej pokazuje odchylenie. Alert powinien prowadzić do konkretnej trasy i wersji, a nie generować ogólne poczucie, że „strona zwolniła”.
Najczęstsze pytania o Core Web Vitals
Czy Core Web Vitals bezpośrednio decydują o pozycji?
Są częścią sygnałów doświadczenia strony, ale nie działają jako samodzielna przepustka do wysokich pozycji. Trafność, jakość treści, możliwość indeksowania, linkowanie i inne sygnały pozostają istotne. Poprawa ma największą wartość wtedy, gdy usuwa realne utrudnienie użytkownika.
Dlaczego Search Console pokazuje grupę adresów?
Raport może łączyć podobne strony, zwłaszcza gdy dla pojedynczego URL-a jest za mało danych. Obejrzyj przykładowe adresy i ustal wspólny szablon. Po poprawie sprawdź kilka reprezentantów, zamiast zakładać, że jeden przypadek rozwiązuje całą grupę.
Czy wynik 100 w teście jest potrzebny?
Nie. Ważniejsze są dobre doświadczenie prawdziwych odbiorców, spełnienie progów, stabilne działanie i rozsądny koszt dalszej poprawy. Ostatnie punkty mogą wymagać rezygnacji z funkcji przynoszącej większą wartość niż sam wynik. Decyzję dokumentuj na podstawie danych.
Jak długo trzeba czekać na zmianę danych terenowych?
Nie aktualizują się natychmiast po wdrożeniu, ponieważ przedstawiają okres i rozkład rzeczywistych wizyt. Do bieżącej weryfikacji użyj powtarzalnego testu laboratoryjnego oraz własnej telemetrii, a raport terenowy traktuj jako potwierdzenie po zebraniu nowej próbki.
Czy wtyczka cache poprawi wszystkie trzy wskaźniki?
Może poprawić odpowiedź serwera i pośrednio LCP, ale nie gwarantuje szybkiej reakcji ani stabilnego układu. INP zależy często od pracy JavaScriptu, a CLS od rezerwacji przestrzeni i zachowania fontów lub komponentów. Każdy wskaźnik wymaga osobnej diagnozy.
Co zrobić, gdy mobile jest słaby, a desktop dobry?
Traktuj mobile jako osobny przypadek. Sprawdź wolniejszy procesor, sieć, wariant układu, menu i obrazy dobierane dla mniejszego ekranu. Nie przenoś automatycznie rozwiązania z desktopu. Potwierdź zmianę na profilu mobilnym oraz prawdziwym urządzeniu.