Czym są Core Web Vitals?

Core Web Vitals to zestaw konkretnych, mierzalnych metryk, których Google używa do oceny rzeczywistego doświadczenia użytkownika strony internetowej. Skupiają się na trzech podstawowych aspektach tego, jak strona odczuwana jest przez odwiedzających: jak szybko pojawia się główna treść, jak szybko strona reaguje na interakcję i jak stabilny jest layout podczas ładowania. Google używa Core Web Vitals jako oficjalnego sygnału rankingowego w wynikach wyszukiwania od czerwca 2021 roku, co oznacza, że te metryki bezpośrednio wpływają na to, gdzie Twoja witryna WordPress pojawia się w wynikach wyszukiwania.

Trzy Core Web Vitals wyjaśnione

Każdy Core Web Vital mierzy inny wymiar doświadczenia użytkownika, a każdy ma konkretny próg, który definiuje "dobrą", "wymagającą poprawy" i "słabą" wydajność.

Largest Contentful Paint (LCP)

LCP mierzy, ile czasu zajmuje pełne wyrenderowanie największego widocznego elementu treści na ekranie. Jest to zazwyczaj obraz hero, duży blok tekstu lub plakat wideo. Zegar startuje, gdy użytkownik po raz pierwszy nawiguje do strony, i zatrzymuje się, gdy ten największy element zakończy rysowanie.

• Dobre: 2,5 sekundy lub mniej
• Wymagające poprawy: między 2,5 a 4,0 sekundy
• Słabe: powyżej 4,0 sekundy

LCP to metryka, która najbardziej bezpośrednio odzwierciedla postrzeganą szybkość ładowania. Strona może mieć szybki Time to First Byte (TTFB), ale nadal mieć słabe LCP, jeśli największy element długo renderuje się z powodu dużych obrazów, zasobów blokujących renderowanie lub powolnych odpowiedzi serwera dla krytycznych zasobów.

Interaction to Next Paint (INP)

INP zastąpił First Input Delay (FID) jako Core Web Vital w marcu 2024 roku. Podczas gdy FID mierzył tylko opóźnienie pierwszej interakcji, INP mierzy responsywność wszystkich interakcji w trakcie życia strony. Śledzi kliknięcia, dotknięcia i wejście klawiatury, rejestrując czas od interakcji do momentu, gdy przeglądarka faktycznie aktualizuje ekran. Ostateczna wartość INP to zazwyczaj najgorsza zaobserwowana interakcja (z pewnymi dostosowaniami dla wartości odstających).

• Dobre: 200 milisekund lub mniej
• Wymagające poprawy: między 200 a 500 milisekund
• Słabe: powyżej 500 milisekund

INP to trudniejsza do zoptymalizowania metryka niż FID, ponieważ obejmuje każdą interakcję, nie tylko pierwszą. Strona może szybko reagować na pierwsze kliknięcie, ale później stać się powolna, gdy uruchamiany jest ciężki JavaScript.

Cumulative Layout Shift (CLS)

CLS mierzy, jak bardzo widoczna treść niespodziewanie przesuwa się podczas ładowania strony i podczas sesji użytkownika. Za każdym razem, gdy element zmienia pozycję bez inicjacji przez użytkownika (na przykład kliknięcia przycisku), to przesunięcie dodaje się do wyniku CLS. Wynik jest obliczany przez pomnożenie ułamka wpływu (jak duża część viewportu jest dotknięta) przez ułamek odległości (jak daleko element się przesunął).

• Dobre: 0,1 lub mniej
• Wymagające poprawy: między 0,1 a 0,25
• Słabe: powyżej 0,25

CLS jest szczególnie frustrujące dla użytkowników. Wyobraź sobie, że próbujesz kliknąć przycisk, ale tuż przed tym, jak Twoje kliknięcie zostanie zarejestrowane, reklama ładuje się powyżej i przesuwa przycisk w dół. Kończysz klikając reklamę. To dokładnie ten rodzaj doświadczenia, który mierzy CLS.

Jak Google używa Core Web Vitals jako sygnału rankingowego

Core Web Vitals są częścią szerszych sygnałów rankingowych Google "page experience", które obejmują również przyjazność dla urządzeń mobilnych, HTTPS i brak natrętnych interstitials. Google ocenia Core Web Vitals przy użyciu rzeczywistych danych użytkowników z Chrome User Experience Report (CrUX). Oznacza to, że Google używa rzeczywistych danych z pola od prawdziwych użytkowników Chrome odwiedzających Twoją witrynę, a nie danych laboratoryjnych z pojedynczego testu. Wpływ rankingowy dotyczy zarówno wyników wyszukiwania mobilnego, jak i desktopowego. Choć trafność treści pozostaje najsilniejszym czynnikiem rankingowym, Core Web Vitals mogą przechylić szalę między stronami o podobnej jakości treści.

Mierzenie Core Web Vitals

Istnieje kilka narzędzi do mierzenia Core Web Vitals i dzielą się one na dwie kategorie: dane z pola (rzeczywiste pomiary użytkowników) i dane laboratoryjne (symulowane testy).

• PageSpeed Insights: narzędzie Google, które pokazuje zarówno dane z pola (z CrUX), jak i dane laboratoryjne (z Lighthouse). Sekcja danych z pola pokazuje rzeczywiste wyniki Core Web Vitals na podstawie prawdziwych użytkowników z ostatnich 28 dni. To najważniejsza sekcja, ponieważ odzwierciedla to, czego Google używa do rankingu.
• Google Search Console: raport Core Web Vitals grupuje Twoje URL-e według statusu (dobre, wymagające poprawy, słabe) na podstawie rzeczywistych danych użytkowników. Pomaga zidentyfikować wzorce na Twojej witrynie zamiast sprawdzania pojedynczych stron.
• Chrome User Experience Report (CrUX): surowy zbiór danych, który zasila PageSpeed Insights i Search Console. Możesz odpytywać go bezpośrednio przez CrUX API lub BigQuery do niestandardowej analizy.
• Lighthouse: narzędzie testowania laboratoryjnego wbudowane w Chrome DevTools. Symuluje ładowanie strony na spowolnionym połączeniu i raportuje LCP i CLS (INP wymaga rzeczywistej interakcji użytkownika i nie może być rzetelnie zmierzony w warunkach laboratoryjnych). Przydatne do debugowania, ale nie odzwierciedla rzeczywistego doświadczenia użytkownika.
• Rozszerzenie Web Vitals Chrome: rozszerzenie przeglądarki, które pokazuje wyniki Core Web Vitals w czasie rzeczywistym podczas przeglądania, ułatwiając wychwytywanie problemów podczas rozwoju i testowania.

Rzeczywiste dane użytkowników vs. dane laboratoryjne

To rozróżnienie jest ważniejsze, niż wielu właścicieli witryn zdaje sobie sprawę. Dane laboratoryjne (z Lighthouse lub podobnych narzędzi) symulują ładowanie strony w kontrolowanych warunkach: na konkretnym urządzeniu, prędkości sieci i lokalizacji. Jest przydatne do debugowania i identyfikowania problemów technicznych, ale nie odzwierciedla tego, czego doświadczają prawdziwi odwiedzający. Rzeczywiste dane użytkowników (dane z pola) pochodzą od prawdziwych użytkowników Chrome odwiedzających Twoją witrynę. Wychwytują pełny zakres urządzeń, prędkości sieci i lokalizacji geograficznych, których używają Twoi odwiedzający. Algorytm rankingowy Google używa danych z pola, a nie danych laboratoryjnych. Strona może uzyskać 95 w Lighthouse, ale nadal mieć słabe Core Web Vitals w polu, ponieważ prawdziwi użytkownicy na wolniejszych urządzeniach mają inne doświadczenie.

Częste problemy WordPress dla LCP

Witryny WordPress często zmagają się z LCP z powodu kilku częstych problemów:

• Duże, niezoptymalizowane obrazy hero: obraz hero o rozmiarze 3 MB potrzebuje znacznie więcej czasu na pobranie i wyrenderowanie niż poprawnie skompresowana wersja WebP o rozmiarze 200 KB. Zawsze kompresuj obrazy, używaj nowoczesnych formatów (WebP lub AVIF) i dostarczaj obrazy o odpowiedniej wielkości dla ekranu odwiedzającego.
• CSS i JavaScript blokujące renderowanie: gdy przeglądarka napotyka pliki CSS lub JavaScript w <head>, musi je pobrać i sparsować przed wyrenderowaniem treści. Zbyt wiele lub zbyt duże arkusze stylów znacznie spowalniają LCP. Inline'uj krytyczny CSS i odraczaj nieistotne arkusze stylów, aby to naprawić.
• Wolny czas odpowiedzi serwera (TTFB): jeśli Twój serwer hostingowy potrzebuje 2 sekundy tylko na wygenerowanie HTML, Twoje LCP nie może być poniżej 2,5 sekundy. Uaktualnij hosting, włącz cache po stronie serwera i używaj CDN, aby zmniejszyć TTFB.
• Zbyt wiele wtyczek: każda wtyczka potencjalnie dodaje CSS i JavaScript do każdej strony. Witryny z 30+ aktywnymi wtyczkami często mają dziesiątki zasobów blokujących renderowanie konkurujących o przepustowość.
• Brakujący atrybut fetchpriority: element LCP powinien mieć fetchpriority="high", aby zasygnalizować przeglądarce, że ma go pobrać najpierw. Bez tego przeglądarka może priorytetyzować inne zasoby nad najważniejszym.

Częste problemy WordPress dla INP

Problemy z INP w WordPress zazwyczaj sprowadzają się do wykonania JavaScript:

• Ciężki JavaScript z wtyczek: slidery, popupy, narzędzia analityczne, widgety czatu i wtyczki udostępniania społecznościowego wszystkie dodają JavaScript działający na głównym wątku. Gdy użytkownik na coś klika, przeglądarka może musieć najpierw wykonać inne skrypty przed reakcją.
• Skrypty zewnętrzne: Google Analytics, Facebook Pixel, skrypty reklamowe i narzędzia live chat często uruchamiają długie zadania, które blokują główny wątek. Ładowanie tych skryptów z async lub defer pomaga, ale nadal konsumują czas przetwarzania.
• Nadmierny rozmiar DOM: strony z tysiącami elementów DOM (częste przy konstruktorach stron, takich jak Elementor czy Divi) wymagają od przeglądarki dłuższej aktualizacji, gdy zachodzą interakcje. Kliknięcie zmieniające klasę CSS może wyzwolić kosztowne przeliczanie stylów na tysiącach elementów.
• Długie zadania głównego wątku: każde zadanie JavaScript trwające dłużej niż 50 milisekund jest uważane za "długie zadanie", które blokuje responsywność. Rozbijanie dużych zadań na mniejsze fragmenty przy użyciu wzorców requestAnimationFrame lub setTimeout może pomóc.

Częste problemy WordPress dla CLS

Przesunięcia layoutu na witrynach WordPress są zwykle spowodowane przez:

• Obrazy bez atrybutów szerokości i wysokości: gdy obraz ładuje się bez jawnych wymiarów, przeglądarka nie wie, ile miejsca zarezerwować. Treść poniżej przesuwa się, gdy obraz w końcu renderuje. Zawsze ustawiaj atrybuty width i height na obrazach (WordPress robi to automatycznie dla obrazów dodanych przez bibliotekę mediów).
• Ładowanie webfontów: niestandardowe czcionki ładujące się po początkowym renderowaniu mogą powodować przepływ tekstu, gdy czcionka jest podmieniana. Użyj font-display: swap w połączeniu z preloadingiem czcionek, aby zminimalizować ten efekt, lub rozważ font-display: optional dla niekrytycznych czcionek.
• Wstrzykiwanie reklam: reklamy ładowane dynamicznie przesuwają treść. Zarezerwuj miejsce na sloty reklamowe za pomocą kontenerów o stałym rozmiarze, nawet zanim reklama się załaduje.
• Dynamicznie wstrzykiwana treść: banery zgody na cookies, popupy newslettera i paski powiadomień pojawiające się po załadowaniu strony mogą przesuwać treść, jeśli są wstawiane do przepływu dokumentu zamiast nakładane na wierzch.
• Osadzenia i iframe bez wymiarów: filmy YouTube, tweety i inne osadzone treści bez jawnych wymiarów powodują przesunięcia, gdy się ładują.

Poprawianie Core Web Vitals dla WordPress

Oto praktyczne podejście do poprawy każdej metryki na witrynie WordPress:

• Dla LCP: zoptymalizuj i skompresuj obrazy (użyj WebP/AVIF), używaj CDN, włącz cache po stronie serwera, inline'uj krytyczny CSS, odraczaj nieistotny JavaScript i dodaj fetchpriority="high" do obrazu LCP. Usuń nieużywane wtyczki, które dodają zasoby blokujące renderowanie.
• Dla INP: skontroluj i usuń niepotrzebny JavaScript, odraczaj skrypty zewnętrzne, zmniejsz rozmiar DOM (rozważ lżejsze konstruktory stron lub natywne bloki WordPress) i rozbijaj długie zadania JavaScript na mniejsze fragmenty. Użyj zakładki Performance w Chrome DevTools, aby zidentyfikować, które skrypty blokują główny wątek.
• Dla CLS: ustawiaj jawne wymiary na wszystkich obrazach, filmach i iframe. Preloaduj czcionki i używaj font-display: swap. Rezerwuj miejsce na reklamy i dynamiczną treść. Unikaj wstawiania treści nad istniejącą treścią po załadowaniu strony.

Co sprawdza InspectWP

InspectWP analizuje kilka czynników, które bezpośrednio wpływają na wyniki Core Web Vitals. Sprawdza kompresję HTTP (która wpływa na LCP), użycie HTTP/2 (umożliwiające równoległe ładowanie zasobów), liczbę plików JavaScript i CSS (które mogą powodować blokowanie renderowania i wpływać zarówno na LCP, jak i INP), możliwości optymalizacji obrazów, rozmiar dokumentu HTML i inne wskaźniki związane z wydajnością. Daje to jasny obraz tego, co należy poprawić, aby osiągnąć lepsze wyniki Core Web Vitals.