Core Web Vitals w WordPressie, czyli LCP, INP i CLS krok po kroku

Dane z terenu i dane laboratoryjne

Zanim zaczniesz cokolwiek zmieniać, rozróżnij dwa rodzaje pomiaru. Dane z terenu pochodzą z raportu Chrome User Experience Report (CrUX): to zanonimizowane pomiary od prawdziwych użytkowników Chrome z ostatnich 28 dni. Na nich opiera się ocena Google. Dane laboratoryjne to jeden symulowany pomiar w kontrolowanych warunkach, na przykład w Lighthouse. Są powtarzalne i świetne do diagnozy, ale nie decydują o ocenie.

• PageSpeed Insights (pagespeed.web.dev) pokazuje na górze dane z terenu dla adresu i całej domeny, a niżej wynik Lighthouse z listą konkretnych problemów. Jeśli strona ma za mały ruch, sekcji danych z terenu po prostu nie ma.
• Google Search Console w raporcie „Podstawowe wskaźniki internetowe” grupuje adresy o podobnym problemie, na przykład „Problem z CLS: więcej niż 0,1 (urządzenia mobilne)”. To najlepsze miejsce, żeby zobaczyć skalę problemu na całej stronie, a nie na jednym adresie.
• Narzędzia deweloperskie Chrome (panel Performance) pokazują na żywo LCP, INP i CLS podczas klikania po Twojej stronie. Dzięki temu widzisz, która konkretna interakcja jest wolna.

Na co uważać przy pomiarach

Lighthouse nie mierzy INP, bo w teście nikt nie klika. Zamiast tego podaje Total Blocking Time, który dobrze wskazuje ryzyko słabego INP. Mierz zawsze wersję mobilną, bo tam wyniki są niemal zawsze gorsze. Zmiany w danych z terenu widać z opóźnieniem: okno CrUX obejmuje 28 dni, więc poprawka wdrożona dziś w pełni odbije się w raporcie po około czterech tygodniach.

Jak poprawić LCP w WordPressie

LCP to zwykle duże zdjęcie w nagłówku, slajd, baner albo blok tekstu w pierwszym ekranie. Na czas LCP składają się cztery etapy: odpowiedź serwera, opóźnienie startu ładowania zasobu, samo pobranie zasobu i jego narysowanie. Warto sprawdzać je w tej kolejności.

• Czas odpowiedzi serwera (TTFB). Włącz cache stron (na poziomie serwera albo wtyczki), aktualną wersję PHP z OPcache i cache obiektów, na przykład Redis. Jeśli HTML generuje się dłużej niż około 0,8 s, reszta optymalizacji niewiele da.
• Nie opóźniaj ładowania obrazu LCP. WordPress od wersji 5.5 dodaje obrazom atrybut loading="lazy", a od wersji 6.3 próbuje sam oznaczyć pierwszy duży obraz atrybutem fetchpriority="high". Motywy i kreatory stron potrafią to zepsuć, na przykład ładując zdjęcie nagłówka jako tło CSS albo przez skrypt slidera. Obraz LCP powinien być zwykłym znacznikiem img, bez lazy loadingu, z wysokim priorytetem.
• Zmniejsz obraz. Używaj formatu WebP albo AVIF (WordPress obsługuje AVIF od wersji 6.5), podawaj srcset z rozmiarami dopasowanymi do ekranu i nie wysyłaj na telefon zdjęcia o szerokości 2500 pikseli.
• Usuń zasoby blokujące renderowanie. Duże pliki CSS i skrypty w sekcji head wstrzymują rysowanie strony. Pomaga generowanie krytycznego CSS, ładowanie skryptów z atrybutem defer i wyłączanie na danej podstronie wtyczek, które nic tam nie robią.
• Uporządkuj fonty. Hostuj je lokalnie, ogranicz liczbę krojów i grubości, ustaw font-display: swap i dodaj preload dla fontu użytego w nagłówku.

Jak poprawić INP w WordPressie

Słaby INP prawie zawsze oznacza, że główny wątek przeglądarki jest zajęty wykonywaniem JavaScriptu w chwili, gdy użytkownik klika. Przeglądarka nie może wtedy narysować odpowiedzi. Każde zadanie dłuższe niż 50 ms jest tzw. długim zadaniem i opóźnia reakcję.

• Zrób spis skryptów. W panelu Coverage w Chrome i w raporcie PageSpeed Insights sprawdź, które skrypty są największe i które ładują się na każdej podstronie. Typowi winowajcy to kreatory stron, slidery, widżety czatu, mapy, piksele reklamowe i rozbudowane kontenery tagów.
• Opóźnij skrypty zewnętrzne. Czat, mapy czy piksele mogą ładować się dopiero po pierwszej interakcji albo po kilku sekundach. To często daje największą poprawę przy najmniejszym ryzyku.
• Zmniejsz DOM. Strony zbudowane z wielu zagnieżdżonych kontenerów kreatora mają kilka tysięcy węzłów, a każda zmiana na stronie jest przez to droższa. Prostsze sekcje i mniej zagnieżdżeń przyspieszają reakcję.
• Sprawdź formularze i koszyk. Walidacja przy każdym znaku, przeliczanie koszyka WooCommerce przez AJAX czy rozbudowane filtry produktów to częste źródła wolnych interakcji. Mierz je w panelu Performance, klikając dokładnie tak jak klient.
• Ogranicz zależności. Jeśli jedna funkcja wymaga dużej biblioteki, rozważ lżejsze rozwiązanie albo ładowanie jej tylko tam, gdzie jest potrzebna.

Jak poprawić CLS w WordPressie

CLS rośnie, gdy element pojawia się albo zmienia rozmiar po tym, jak treść została już narysowana, i przesuwa to, co użytkownik właśnie czyta albo chce kliknąć.

• Podawaj wymiary obrazów i filmów. Atrybuty width i height albo właściwość aspect-ratio pozwalają przeglądarce zarezerwować miejsce, zanim obraz się pobierze. WordPress dodaje je w treści wpisów, ale obrazy wstawiane przez motyw lub kreator często ich nie mają.
• Rezerwuj miejsce na elementy dynamiczne. Baner cookies, pasek promocji, reklama, osadzony film czy widżet opinii powinny mieć stałą wysokość albo pojawiać się jako nakładka, a nie wpychać się nad treść.
• Ustabilizuj fonty. Podmiana fontu zastępczego na docelowy potrafi przesunąć cały tekst. Pomaga preload fontu i dopasowanie fontu zastępczego (właściwości size-adjust i ascent-override).
• Nie wstrzykuj treści nad istniejącą. Komunikaty wtyczek, powiadomienia i dynamicznie doklejane sekcje ustawiaj poniżej widocznego obszaru albo w miejscu z zarezerwowaną wysokością.
• Animuj właściwości transform i opacity, a nie top, left czy height. Animacje przez transform nie przesuwają układu i nie liczą się do CLS.

Co najczęściej psuje wyniki na stronach WordPress

Przy przeglądzie stron na WordPressie te same przyczyny wracają bardzo często. Zanim zaczniesz optymalizować pojedyncze pliki, sprawdź, czy któraś z nich nie dotyczy Twojej strony.

• Hosting bez cache stron i ze starą wersją PHP. Każda odsłona generuje stronę od zera, więc TTFB rośnie wraz z ruchem, a LCP razem z nim.
• Kilka wtyczek robiących to samo. Dwie wtyczki cache, dwie wtyczki SEO albo optymalizator obrazów razem z optymalizatorem CDN potrafią się wzajemnie znosić i generować błędy trudne do wyśledzenia.
• Kreator stron ładujący wszystkie moduły na każdej podstronie, także te, których na niej nie ma.
• Slider w pierwszym ekranie. Zwykle jest elementem LCP, ładuje się skryptem, zmienia wysokość po starcie i obciąża główny wątek, więc psuje wszystkie trzy wskaźniki naraz.
• Zdjęcia wgrywane prosto z aparatu lub telefonu, bez zmniejszenia i kompresji.
• Baner cookies i widżety zewnętrzne dokładane z kontenera tagów bez zarezerwowanego miejsca.
• Zbyt agresywna optymalizacja: łączenie i opóźnianie wszystkich skryptów bez testu, po którym przestaje działać menu mobilne albo formularz. Wynik w teście rośnie, a klient nie może się skontaktować.

Każdą z tych przyczyn da się usunąć bez zmiany wyglądu strony. Różnica między stroną wolną a szybką często leży w konfiguracji, a nie w projekcie graficznym.

Plan poprawy wskaźników na jednej stronie

Najwięcej zyskujesz, gdy pracujesz na szablonach, a nie na pojedynczych adresach. Strona główna, wpis, strona usługi, karta produktu i kategoria to zwykle kilka szablonów, które odpowiadają za niemal cały ruch.

• Otwórz raport w Search Console i wybierz grupę adresów z najsłabszą oceną na urządzeniach mobilnych.
• Dla wzorcowego adresu z tej grupy uruchom PageSpeed Insights i zapisz wartości przed zmianą.
• Wprowadzaj zmiany na kopii testowej strony, jedną po drugiej, i mierz po każdej. Cache i optymalizacja skryptów potrafią zepsuć formularze, koszyk albo menu mobilne.
• Po wdrożeniu na produkcję sprawdź formularze, logowanie i proces zakupu, wyczyść cache i powtórz pomiar laboratoryjny.
• W Search Console kliknij „Sprawdź poprawkę”. Walidacja trwa około 28 dni, bo tyle obejmuje okno danych z terenu.
• Ustaw stały pomiar. Wskaźniki psują się po cichu: nowa wtyczka, nowy baner albo zdjęcie wgrane bez kompresji potrafi cofnąć miesiące pracy.

Szerzej o samej szybkości piszemy na stronie przyspieszenie WordPressa, a o stałym pilnowaniu strony na stronie monitoring WordPress.