Strona główna  /  Szybkość strony  /  Jak poprawić Core Web Vitals w WordPress?

Nowoczesne stanowisko pracy z laptopem wyświetlającym wykresy optymalizacji wydajności strony internetowej.

Jak poprawić Core Web Vitals w WordPress?

Poprawa Core Web Vitals w WordPressie nie polega na instalowaniu kolejnej wtyczki i oczekiwaniu na wynik 100/100. Najpierw zmierz stronę, sprawdź dane realnych użytkowników, znajdź wąskie gardło, wdroż jedną grupę zmian i wykonaj ponowny pomiar.

Dlaczego WordPress może mieć słabe Core Web Vitals?

Core Web Vitals opisują doświadczenie użytkownika podczas korzystania ze strony. Użytkownik powinien szybko zobaczyć główną treść, bez opóźnienia otworzyć menu lub formularz, a także nie tracić miejsca na stronie przez przesuwające się elementy.

Wolny serwis może utrudniać kontakt, zakup lub przejście do kolejnej podstrony. Wydajność jest też jednym z sygnałów wykorzystywanych przez Google przy ocenie jakości strony, ale sama poprawa CWV nie zastępuje wartościowej treści, dobrej oferty ani poprawnej struktury serwisu.

Co mierzą LCP, INP i CLS?

Trzy podstawowe wskaźniki dotyczą różnych etapów korzystania ze strony. Ich wartości mogą różnić się między urządzeniami, podstronami i warunkami sieciowymi.

Wskaźnik Co mierzy Cel Typowy winowajca w WordPressie
LCP Czas wyświetlenia największego elementu widocznego w obszarze ekranu, zwykle obrazu, nagłówka lub sekcji hero. poniżej 2,5 s Duży obraz, wolny serwer, brak cache lub nieprawidłowe ładowanie głównej treści.
INP Responsywność strony po kliknięciu, dotknięciu ekranu lub użyciu klawiatury. poniżej 200 ms Nadmiar JavaScriptu, ciężkie wtyczki i skrypty zewnętrzne.
CLS Stabilność układu podczas ładowania i korzystania ze strony. poniżej 0,1 Obrazy bez wymiarów, reklamy, fonty i moduły wstawiane po załadowaniu treści.

LCP najczęściej poprawia się przez optymalizację głównego obrazu i skrócenie czasu odpowiedzi serwera. INP zależy przede wszystkim od ilości pracy wykonywanej przez JavaScript. CLS wymaga zarezerwowania miejsca na elementy, które pojawiają się z opóźnieniem.

Jak mierzyć Core Web Vitals, żeby nie wyciągać błędnych wniosków?

PageSpeed Insights pokazuje zarówno wynik laboratoryjny, jak i – jeśli są dostępne – dane z Chrome User Experience Report, czyli CrUX. Test laboratoryjny jest wykonywany w określonych warunkach i pomaga znaleźć techniczną przyczynę problemu. CrUX bazuje na doświadczeniach realnych użytkowników Chrome.

Te wyniki mogą się różnić. Pojedynczy test nie jest wystarczającą podstawą do oceny całej witryny. Raport w Search Console grupuje adresy o podobnych problemach, a WebPageTest pomaga przeanalizować kolejność ładowania zasobów i czas odpowiedzi serwera.

Przed rozpoczęciem prac przygotuj podstawowy punkt odniesienia:

  • Wykonaj kopię zapasową strony i bazy danych.
  • Zmierz najważniejsze podstrony w wersji mobilnej i desktopowej.
  • Zapisz LCP, INP, CLS, TTFB oraz element wskazany jako przyczyna problemu.
  • Sprawdź raport Core Web Vitals w Search Console i porównaj go z wynikiem PageSpeed Insights.

Warto mierzyć stronę główną, stronę oferty, wpis, formularz kontaktowy oraz – w przypadku WooCommerce – kategorię, kartę produktu, koszyk i proces zamówienia. Każdy adres może ładować inny zestaw skryptów.

Jak poprawić Core Web Vitals w WordPressie?

1. Zoptymalizuj obrazy i główny element LCP

Duże grafiki często odpowiadają za znaczną część transferu. Najpierw ustal, który element PageSpeed Insights wskazuje jako LCP. Dopiero potem optymalizuj konkretny obraz, nagłówek lub sekcję hero, zamiast zmieniać przypadkowe zasoby.

Obrazy powinny mieć rozmiar dopasowany do miejsca, w którym są wyświetlane. Nie przesyłaj grafiki o szerokości kilku tysięcy pikseli, jeśli motyw pokazuje ją w znacznie mniejszym rozmiarze.

Przy optymalizacji biblioteki mediów sprawdź przede wszystkim:

  • Konwersję ciężkich plików do formatów WebP lub AVIF.
  • Wymiary grafik dopasowane do rzeczywistego rozmiaru wyświetlania.
  • Lazy loading dla obrazów znajdujących się poniżej pierwszego ekranu.
  • Wyłączenie opóźnionego ładowania dla głównego obrazu LCP.
  • Generowanie responsywnych wariantów przez atrybuty srcset.

Lazy loading zastosowany do obrazu widocznego od razu po wejściu na stronę może pogorszyć LCP, ponieważ przeglądarka zacznie pobierać go zbyt późno. Główny zasób powinien być dostępny możliwie szybko, ale preload należy stosować oszczędnie, tylko dla rzeczywiście krytycznych elementów.

2. Ogranicz JavaScript i popraw INP

Wysoki INP często wynika z tego, że przeglądarka wykonuje zbyt dużo kodu po stronie JavaScript. Strona może wyglądać na załadowaną, ale kliknięcie menu, przycisku lub formularza nadal czeka na zwolnienie głównego wątku.

Przejrzyj wtyczki pod kątem ich funkcji, a nie tylko liczby. Sama obecność wtyczki nie oznacza automatycznie problemu, lecz każda może dodawać style, skrypty, zapytania lub elementy ładowane na wielu podstronach.

Najczęściej pomaga:

  • Usunięcie nieużywanych wtyczek, motywów i funkcji.
  • Wyłączanie skryptów na podstronach, na których nie są potrzebne.
  • Opóźnienie skryptów analitycznych, reklamowych i widgetów zewnętrznych.
  • Minifikacja CSS i JavaScriptu po wcześniejszym sprawdzeniu strony na kopii testowej.
  • Ograniczenie ciężkich animacji, sliderów i efektów wykonywanych w przeglądarce.

Nie łącz automatycznie wszystkich plików CSS i JavaScript. Na HTTP/2 lub HTTP/3 wiele małych zasobów nie musi być problemem, a agresywne łączenie może utrudnić cache i wywołać konflikty. Liczy się rzeczywista kolejność ładowania oraz czas pracy głównego wątku.

3. Zadbaj o hosting, TTFB i cache

Optymalizacja frontendu nie naprawi serwera, który długo generuje odpowiedź. TTFB, czyli czas od wysłania żądania do otrzymania pierwszego bajtu, jest jednym z fundamentów szybkości. Wpływa na niego między innymi hosting, obciążenie serwera, zapytania do bazy danych i konfiguracja WordPressa.

Włącz cache strony, przeglądarki i – jeśli infrastruktura na to pozwala – cache obiektowy. Zcache’owana wersja strony ogranicza konieczność wykonywania tych samych operacji przy każdym wejściu użytkownika.

Przy większym ruchu lub użytkownikach z różnych regionów przydatny może być CDN. Rozproszona sieć dostarcza statyczne zasoby z lokalizacji położonej bliżej odbiorcy i zmniejsza obciążenie serwera źródłowego. CDN nie zastępuje jednak optymalizacji WordPressa, poprawnych nagłówków cache ani sprawnego hostingu.

W sklepie WooCommerce trzeba zachować ostrożność. Koszyk, konto klienta i checkout zawierają dane dynamiczne, dlatego nie mogą być traktowane tak samo jak statyczna strona informacyjna.

Nie instaluj kilku wtyczek cache i optymalizacji jednocześnie. Ich ustawienia mogą się dublować, powodować konflikty i opóźniać stronę zamiast ją przyspieszać. Funkcje takie jak opóźnianie JavaScriptu, usuwanie nieużywanego CSS czy preload fontów wdrażaj pojedynczo i testuj po każdej zmianie.

4. Usuń źródła przesunięć układu

CLS rośnie, gdy przeglądarka nie zna rozmiaru elementu przed jego pobraniem. Obraz, reklama, baner lub formularz pojawia się wtedy bez zarezerwowanego miejsca i przesuwa treść.

Aby ustabilizować układ:

  • Ustawiaj szerokość i wysokość obrazów albo zachowuj ich proporcje w CSS.
  • Rezerwuj miejsce na reklamy, bannery, zgody i moduły ładowane dynamicznie.
  • Nie wstawiaj nowych elementów nad już wyświetloną treścią bez stałego obszaru.
  • Ogranicz liczbę fontów i ich odmian oraz sprawdź zachowanie font-display.

Przetestuj osobno stronę główną, ofertę, kontakt i landing page. Motyw może być stabilny na jednej podstronie, a powodować przesunięcia na innej, jeśli używa ona dodatkowych bloków lub skryptów.

Jak bezpiecznie wdrażać poprawki?

Najbezpieczniejszy model pracy to pomiar, jedna grupa zmian, ponowny pomiar i dopiero później kolejny etap. Dzięki temu wiesz, która modyfikacja przyniosła efekt i łatwiej wycofasz zmianę, która uszkodziła funkcję.

  1. Wykonaj kopię zapasową i, jeśli to możliwe, przygotuj środowisko stagingowe.
  2. Zapisz wyniki PageSpeed Insights, WebPageTest i Search Console dla najważniejszych adresów.
  3. Wdróż jedną grupę zmian, na przykład optymalizację obrazów albo konfigurację cache.
  4. Wyczyść właściwe warstwy cache, sprawdź formularze, menu, koszyk i wersję mobilną.
  5. Uruchom ponowny pomiar na tych samych adresach i porównaj wyniki z punktem wyjścia.
  6. Po wdrożeniu obserwuj dane CrUX przez około 28 dni, ponieważ dopiero wtedy widać wpływ zmian na grupę realnych użytkowników.

Jeśli po podstawowej optymalizacji strona nadal jest wolna, sprawdź logi wolnych zapytań, motyw, bazę danych i skrypty zewnętrzne. W przypadku WooCommerce przeanalizuj także koszyk, checkout oraz działanie integracji płatności i dostaw.

Co zapamiętać z optymalizacji WordPressa?

Najpierw popraw element wskazany przez pomiar, a nie wynik samego testu. Obrazy i cache zwykle pomagają w LCP, ograniczenie JavaScriptu poprawia INP, a rezerwowanie miejsca na elementy dynamiczne stabilizuje CLS. Dane laboratoryjne ułatwiają diagnozę, lecz o rzeczywistym doświadczeniu użytkowników najlepiej informuje CrUX.

Core Web Vitals wymagają stałego monitoringu. Każda większa zmiana motywu, wtyczek, reklam lub funkcji sklepu może zmienić wydajność, dlatego proces pomiar–zmiana–pomiar powinien towarzyszyć dalszemu rozwojowi strony.

Redakcja wpinternals.pl

WordPressa znamy od kuchni – budujemy na nim strony, migrujemy serwisy i optymalizujemy ich wydajność. Piszemy o wtyczkach, motywach, hostingu i bezpieczeństwie tak, by poradzili sobie także początkujący. Dbamy o to, by Twoja strona była szybka, stabilna i bezpieczna.

Może Cię również zainteresować

Potrzebujesz więcej informacji?