By Pamiętam dokładnie ten moment, kiedy po raz pierwszy zobaczyłem stronę klienta w Google PageSpeed Insights i przeczytałem wynik 23 na 100. Strona miała ładny design, klient był z niej dumny, ale Google nie podzielał tego entuzjazmu. Wtedy zacząłem poważnie zajmować się wydajnością WordPressa i przez kolejne lata nauczyłem się, że dobry wynik w Lighthouse nie jest ani łatwy, ani niemożliwy — i że można go osiągnąć bez wydawania fortuny na drogie narzędzia.
W tym artykule wyjaśnię, czym są Core Web Vitals, jak Google ocenia strony w 2026 roku i co konkretnie możesz zrobić, żeby Twoja strona WordPress osiągnęła wynik powyżej 90.
Co to są Core Web Vitals i dlaczego mają znaczenie dla SEO
Core Web Vitals to zestaw trzech mierników, którymi Google mierzy “doświadczenie użytkownika” na stronie internetowej. Nie są to metryki stricte techniczne dla deweloperów — są zaprojektowane tak, żeby oddawać realne odczucia osoby odwiedzającej stronę.
Pierwsza metryka to LCP, czyli Largest Contentful Paint. Mierzy czas, po jakim na ekranie pojawia się największy widoczny element — zazwyczaj główne zdjęcie, baner lub duży nagłówek. Google oczekuje, że ten element załaduje się w ciągu 2,5 sekundy od otwarcia strony. Jeśli Twój LCP wynosi 4 sekundy, użytkownik siedzi przed pustym lub połowicznie załadowanym ekranem przez bardzo długi czas.
Druga metryka to INP, czyli Interaction to Next Paint. Zastąpiła w 2024 roku starszy miernik FID i mierzy responsywność strony na działania użytkownika — kliknięcia, dotknięcia, interakcje z formularzami. Dobry INP to poniżej 200 milisekund. Strona, która reaguje na kliknięcie po 800ms, czuje się “martwa” i frustruje odwiedzających.
Trzecia metryka to CLS, czyli Cumulative Layout Shift. Mierzy, jak bardzo elementy na stronie “skaczą” podczas ładowania. Jeśli czytasz artykuł i nagle cały tekst przesuwa się w dół, bo załadowała się reklama — właśnie doświadczyłeś wysokiego CLS. Google oczekuje wartości poniżej 0,1.
Dlaczego to ważne dla SEO? Google oficjalnie uwzględnia Core Web Vitals jako jeden z sygnałów rankingowych. Nie jest to czynnik decydujący — dobra treść i linki wychodzące nadal mają większe znaczenie — ale przy zbliżonym poziomie merytorycznym strona z lepszymi CVW wygra z tą o gorszych wynikach. A co ważniejsze, lepsza wydajność oznacza lepsze współczynniki konwersji i dłuższy czas spędzony na stronie.
Jak mierzyć Core Web Vitals na WordPressie
Zanim zaczniesz optymalizować, musisz wiedzieć, co dokładnie naprawić. Do dyspozycji masz kilka bezpłatnych narzędzi.
Google PageSpeed Insights (pagespeed.web.dev) to punkt wyjścia. Wklej URL swojej strony i dostaniesz szczegółowy raport z podziałem na dane laboratoryjne (symulacja) i dane z rzeczywistych użytkowników (jeśli strona ma wystarczający ruch). Dane laboratoryjne są przydatne do debugowania, ale to dane z real-world użytkowników (Core Web Vitals raport w Google Search Console) są tym, co Google realnie bierze pod uwagę przy rankingu.
Google Search Console to drugie obowiązkowe narzędzie. W sekcji “Ogólne wrażenia” znajdziesz raport Core Web Vitals z podziałem na “dobre”, “wymagające poprawy” i “słabe” strony. Co ważne, Google grupuje podobne adresy URL, więc raport pokazuje systemowe problemy, nie pojedyncze przypadki.
GTmetrix i WebPageTest to uzupełnienia, które dają dodatkowe informacje — szczególnie waterfall załadowania zasobów, który pomaga znaleźć konkretne pliki odpowiedzialne za spowolnienia.
Optymalizacja LCP w WordPress — od czego zacząć
Najczęstszą przyczyną słabego LCP na stronach WordPress jest duże, nieoptymalizowane zdjęcie w sekcji hero — tym wielkim banerze na górze strony głównej. To logiczne: skoro to największy element na stronie, to on jest LCP i to on musi załadować się szybko.
Pierwszym krokiem jest optymalizacja obrazów. Format WebP zamiast JPEG lub PNG to standard w 2026 roku — obrazy WebP są o 25–35% mniejsze przy porównywalnej jakości. WordPress od wersji 5.8 natywnie obsługuje WebP, ale konwersja starych obrazów wymaga narzędzia. ShortPixel, Imagify lub Smush to popularne wtyczki do automatycznej konwersji — wszystkie mają bezpłatne plany z limitem obrazów miesięcznie.
Rozmiar obrazu to drugie ważne zagadnienie. Jeśli uploadujesz zdjęcie 4000×3000 pikseli i wyświetlasz je w kontenerze 1200×600 pikseli, przeglądarka pobiera wielokrotnie więcej danych niż potrzebuje. Przed uploadem przeskaluj zdjęcia do maksymalnej szerokości wyświetlania — zazwyczaj 1920 pikseli dla pełnoekranowych bannerów i 1200 pikseli dla standardowych obrazów w treści.
Atrybut fetchpriority="high" na obrazie LCP to mały trick, który robi dużą różnicę. Dodanie tego atrybutu do tagu <img> obrazu hero mówi przeglądarce, żeby pobrała go jako priorytetowy zasób. W WordPress możesz to zrobić ręcznie w motywach lub przez filtr wp_get_attachment_image_attributes.
Hosting ma ogromne znaczenie dla LCP. Jeśli Twoja strona jest na tanim współdzielonym hostingu z czasem TTFB (Time To First Byte) powyżej 800ms, nawet najlepiej zoptymalizowane obrazy nie dadzą dobrego LCP. Dobry hosting VPS z Nginx i PHP-FPM potrafi zejść z TTFB do 50–100ms. To różnica, która od razu widać w wynikach.
Jak poprawić INP na stronie WordPress
INP jest najtrudniejszą z trzech metryk do optymalizacji, bo dotyczy głównie JavaScriptu — a WordPress ładuje sporo JS przez wtyczki, które często działają na każdej stronie, choć są potrzebne tylko na kilku.
Pierwszym krokiem jest audyt załadowanych skryptów. Możesz to zrobić przez DevTools przeglądarki (zakładka Network → JS) albo przez wtyczkę Query Monitor, która pokazuje wszystkie skrypty załadowane na danej stronie. Często okazuje się, że wtyczka do formularzy ładuje swoje skrypty na każdej stronie, podczas gdy formularz jest tylko na jednej.
Ograniczenie ładowania skryptów do stron, na których są potrzebne, to jeden z najskuteczniejszych sposobów poprawy INP. W WordPressie można to osiągnąć przez warunkowe kolejkowanie skryptów w kodzie wtyczki lub motywu, albo przez dedykowane wtyczki jak Asset CleanUp, które pozwalają wyłączyć poszczególne skrypty na wybranych podstronach.
Opóźnione ładowanie skryptów (defer i async) pomaga w przypadku skryptów, które nie są potrzebne do pierwszego renderowania strony. Większość nowoczesnych motywów i wtyczek powinna to robić domyślnie, ale starszy kod często tego nie uwzględnia.
Eliminacja CLS — skoki layoutu najczęściej powodowane przez te elementy
CLS to metryka, przy której stosunkowo najłatwiej osiągnąć dobry wynik, jeśli wiesz, gdzie szukać problemów.
Obrazy bez zadeklarowanych wymiarów to klasyczna przyczyna CLS. Przeglądarka nie wie, ile miejsca zarezerwować na obraz, dopóki go nie pobierze — więc tekst wokół “skacze” w momencie załadowania zdjęcia. Rozwiązanie: zawsze dodawaj atrybuty width i height do tagów <img>. WordPress robi to automatycznie dla obrazów z biblioteki mediów, ale zewnętrzne obrazy lub stare treści mogą tego wymagać.
Reklamy i widżety zewnętrzne to drugi częsty winowajca. Jeśli masz reklamy AdSense lub inne bannery ładowane dynamicznie, zarezerwuj dla nich miejsce o stałych wymiarach przez CSS (min-height). To zapobiega przeskakiwaniu treści, kiedy reklama się załaduje.
Czcionki internetowe (Google Fonts, Adobe Fonts) mogą powodować FOUT (Flash of Unstyled Text) lub FOIT (Flash of Invisible Text), co przyczynia się do CLS. Rozwiązaniem jest preload czcionek i użycie font-display: swap lub optional. Alternatywnie — rozważ hostowanie czcionek lokalnie na swoim serwerze zamiast pobierania ich z zewnętrznych CDN-ów. Jest to zalecane też ze względu na prywatność (RODO).
Konfiguracja cache jako fundament wydajności WordPress
Żaden z powyższych punktów nie zadziała tak skutecznie, jak dobre cache. Cache to mechanizm, który zapisuje wygenerowaną stronę HTML i serwuje ją kolejnym użytkownikom bez każdorazowego generowania przez PHP i odpytywania bazy danych.
W środowisku Nginx na VPS najlepszym rozwiązaniem jest FastCGI Cache skonfigurowany bezpośrednio na poziomie serwera. To najszybsza możliwa opcja, bo żądanie jest obsługiwane przez Nginx zanim w ogóle dotrze do PHP. Skonfigurowanie FastCGI Cache wymaga wiedzy technicznej, ale efekty są natychmiastowe.
Jeśli nie masz dostępu do konfiguracji serwera, wtyczka WP Rocket to najczęściej rekomendowane rozwiązanie na rynku. Obsługuje page cache, minifikację CSS i JS, lazy load, preload i wiele innych optymalizacji z poziomu jednego panelu. Kosztuje 59 dolarów rocznie za jedną stronę. Alternatywą bezpłatną jest W3 Total Cache lub LiteSpeed Cache (jeśli Twój hosting używa serwera LiteSpeed).
Redis Object Cache to uzupełnienie page cache — przyspiesza zapytania do bazy danych przez cache’owanie wyników w pamięci RAM. Dla stron z dużą liczbą dynamicznych elementów (sklepy, portale zalogowanych użytkowników) Redis robi ogromną różnicę. Wymaga Redis zainstalowanego na serwerze i wtyczki Redis Object Cache dla WordPress.
CDN — ostatni element układanki
Content Delivery Network to sieć serwerów rozlokowanych po całym świecie, która serwuje statyczne zasoby (obrazy, CSS, JS) z lokalizacji geograficznie bliskiej użytkownikowi. Dla strony polskiej skierowanej do polskich użytkowników CDN może nie być priorytetem — ale dla każdego, kto ma odbiorców w różnych krajach lub po prostu chce jeszcze szybszego ładowania, CDN to ostatni krok w optymalizacji.
Cloudflare w darmowym planie to oczywisty wybór dla większości stron. Dostarcza CDN, dodatkową ochronę przed atakami DDoS i pewne możliwości cache’owania na poziomie sieci. Nie jest idealny dla wszystkich scenariuszy (szczególnie dla stron z dużą ilością dynamicznych treści), ale jako bezpłatne rozwiązanie ciężko znaleźć lepszą alternatywę.
Osiągnięcie wyniku 90+ w PageSpeed Insights na WordPressie w 2026 roku jest całkowicie realne bez płatnych narzędzi. Wymaga to dobrego hostingu, zoptymalizowanych obrazów, rozsądnego zarządzania skryptami i poprawnej konfiguracji cache. Każdy z tych kroków można zrealizować z bezpłatnymi narzędziami i odrobiną technicznej wiedzy. A jeśli wolisz oddać to w ręce eksperta — teraz wiesz dokładnie, o co pytać i czego oczekiwać.