Strony www

Core Web Vitals w WordPressie – jak poprawić krok po kroku

Google używa Core Web Vitals jako czynnika rankingowego od 2021 roku. W 2026 wskaźniki te są jeszcze ważniejsze – Google jawnie komunikuje, że strony z dobrymi CWV dostają przewagę w wynikach mobilnych.

Kapitan WEB

Z artykułu dowiesz się

Google używa Core Web Vitals jako czynnika rankingowego od 2021 roku. W 2026 wskaźniki te są jeszcze ważniejsze – Google jawnie komunikuje, że strony z dobrymi CWV dostają przewagę w wynikach mobilnych. Problem? 56% stron opartych na WordPressie nie przechodzi testu Core Web Vitals na urządzeniach mobilnych według danych z Chrome UX Report. Ten artykuł pokazuje, jak to naprawić – wskaźnik po wskaźniku, z konkretnymi narzędziami i ustawieniami.

Czym są Core Web Vitals i dlaczego WordPress ma z nimi problem

Core Web Vitals to trzy metryki mierzące doświadczenie użytkownika:

  • LCP (Largest Contentful Paint) – czas ładowania największego widocznego elementu na ekranie. Cel: poniżej 2,5 sekundy. Typowo to hero image, nagłówek H1 z dużą czcionką lub wideo w tle.
  • INP (Interaction to Next Paint) – opóźnienie reakcji na interakcję użytkownika (zastąpił FID w marcu 2024). Cel: poniżej 200 ms. Mierzy, jak szybko strona reaguje na kliknięcia, tapnięcia i wciśnięcia klawiszy.
  • CLS (Cumulative Layout Shift) – stabilność wizualna, czyli jak bardzo elementy „skaczą” podczas ładowania. Cel: poniżej 0,1. Każdy, kto próbował kliknąć przycisk i trafił w reklamę, bo strona „skoczyła” – zna ten problem.

WordPress ma z CWV systemowy problem z kilku powodów:

  • Ładowanie wtyczek – przeciętna strona WP ma 20-30 aktywnych wtyczek, każda dodaje własne pliki CSS i JS. Wtyczka do formularza kontaktowego ładuje swój CSS i JS na każdej stronie, choć formularz jest tylko na podstronie kontakt.
  • Motyw + page builder – Elementor, Divi czy WPBakery generują nadmiarowy HTML i CSS. Elementor potrafi wygenerować 50-100 KB nieskompresowanego CSS na pojedynczej stronie. Divi dodaje inline CSS do każdego elementu. WPBakery używa shortcode’ow, które generują złożony DOM.
  • Brak lazy loading w starszych motywach – WordPress od wersji 5.5 domyślnie dodaje loading="lazy" do obrazków, ale wiele motywów nadpisuje to zachowanie własnymi implementacjami.
  • Hosting – tani shared hosting z czasem odpowiedzi serwera (TTFB) powyżej 800 ms zabija LCP, zanim jeszcze zacznie się renderowanie. Jeśli serwer potrzebuje sekundy na wygenerowanie HTML-a, nie ma szans na LCP poniżej 2,5 s na wolniejszym połączeniu mobilnym.
  • Baza danych – WordPressowe tabele wp_options i wp_postmeta rosną z czasem. Strona z 500 wpisami i 30 wtyczkami może mieć tablicę options z 10 000 wierszy, z których 8 000 to autoload. Każde ładowanie strony czyta je wszystkie.

LCP – diagnoza i naprawa

LCP to najczęstszy problem na stronach WordPress. Zanim zaczniesz optymalizować, musisz wiedzieć, co jest Twoim elementem LCP.

Krok 1: Zidentyfikuj element LCP

Otwórz stronę w Chrome, wciśnij F12, przejdź do zakładki Performance, nagraj załadowanie strony (Ctrl+Shift+E). W sekcji „Timings” znajdziesz znacznik LCP z podświetlonym elementem. Możesz też użyć rozszerzenia Web Vitals, które pokaże element LCP bezpośrednio na stronie. Najczęściej to:

  • Hero image lub slider na stronie głównej
  • Nagłówek <h1> z dużą czcionką web (jeśli nie ma obrazu above the fold)
  • Wideo w tle lub featured image wpisu blogowego

Krok 2: Optymalizacja obrazu LCP

Jeśli elementem LCP jest obraz (najczęstszy przypadek):

  • Konwertuj na format WebP lub AVIF (ShortPixel robi to automatycznie). WebP daje 25-34% mniejszy rozmiar niż JPEG przy tej samej jakości. AVIF jeszcze więcej, ale wolniej się dekoduje na starszych urządzeniach.
  • Ustaw fetchpriority="high" na elemencie LCP – WordPress 6.3+ robi to automatycznie dla pierwszego obrazu, ale sprawdź w źródle strony, czy atrybut jest obecny.
  • Usuń loading="lazy" z obrazu LCP – lazy loading na obrazie above-the-fold opóźnia jego załadowanie, bo przeglądarka czeka z pobraniem do momentu, gdy obraz zbliży się do viewportu.
  • Skaluj obraz do rzeczywistego rozmiaru wyświetlania. Jeśli hero image wyświetla się w 1200x600px, nie ładuj pliku 4000x2000px.
  • Dodaj preload w <head>:
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" 
      type="image/webp" fetchpriority="high">

W functions.php możesz to zautomatyzować:

add_action('wp_head', function() {
    if (is_front_page()) {
        echo '<link rel="preload" as="image" href="' 
             . get_template_directory_uri() 
             . '/images/hero.webp" type="image/webp">';
    }
}, 1);

Krok 3: Optymalizacja TTFB

Czas odpowiedzi serwera bezpośrednio wpływa na LCP. Każda milisekunda TTFB to milisekunda dodana do LCP. Działania od najważniejszego:

  • Włącz cache strony – WP Rocket, W3 Total Cache lub LiteSpeed Cache (jeśli hosting obsługuje OpenLiteSpeed). Page cache redukuje TTFB z 800-2000 ms do 50-200 ms, bo serwer serwuje gotowy HTML zamiast odpalać PHP i odpytywać bazę danych.
  • Rozważ CDN – Cloudflare Free wystarcza dla większości stron. CDN serwuje statyczne zasoby z serwera najbliżej użytkownika. Dla polskiej strony z polskimi użytkownikami różnica jest mniejsza niż dla stron międzynarodowych, ale nadal znacząca przy większym ruchu.
  • Jeśli TTFB przekracza 600 ms na shared hostingu – zmiana hostingu jest jedyną skuteczną interwencją. Szukaj serwerów z dyskami NVMe, PHP 8.2+ i HTTP/2. W Polsce LH.pl, cyber_Folks i zenbox oferują plany z TTFB poniżej 200 ms.
  • Włącz OPcache – większość hostingów ma włączone domyślnie, ale sprawdź. OPcache przechowuje skompilowany bytecode PHP w pamięci, eliminując konieczność kompilacji przy każdym żądaniu.

Krok 4: Eliminacja render-blocking resources

Pliki CSS i JS w <head>, które nie są krytyczne, blokują renderowanie. Przeglądarka musi pobrać i przetworzyć te pliki zanim zacznie rysować stronę. Rozwiązania:

  • WP Rocket – opcja „Remove Unused CSS” (od wersji 3.15 działa stabilnie) + „Delay JavaScript Execution”. WP Rocket automatycznie generuje krytyczny CSS i wstawia go inline, a resztę ładuje asynchronicznie.
  • Autoptimize + Async JavaScript – darmowa alternatywa. Autoptimize łączy i minifikuje CSS/JS, Async JavaScript dodaje atrybuty defer i async. Razem dają 80% efektu WP Rocket za 0 zł.

INP – przyspieszenie reakcji na interakcje

INP (Interaction to Next Paint) zastąpił FID w marcu 2024 i jest trudniejszy do spełnienia. FID mierzył tylko pierwsze kliknięcie na stronie, INP mierzy każdą interakcję w trakcie całej wizyty i raportuje 75. percentyl. To oznacza, że nawet jeśli strona ładuje się szybko, ciężki JavaScript uruchamiany po kliknięciu menu, otwarciu dropdowna lub zatwierdzeniu formularza może pogarszać INP.

Jak działa INP? Użytkownik klika przycisk → przeglądarka musi wykonać event handler (JavaScript) → potem przerysować ekran (paint). INP mierzy czas od kliknięcia do przerysowania. Jeśli main thread jest zajęty ciężkim skryptem, kliknięcie czeka w kolejce.

Najczęstsze przyczyny złego INP na WordPressie:

  • Ciężkie wtyczki JS – slajdery (Revolution Slider zajmuje 200-500 KB JS), animacje (WOW.js), popupy (Popup Maker z złożonymi warunkami wyświetlania), mega menu z efektami CSS.
  • Third-party scripts – Google Tag Manager z dziesiątkami tagów, live chat (Tawk.to, Tidio), Hotjar, piksele reklamowe (Facebook Pixel, Google Ads). Każdy z tych skryptów dodaje event listenery i okresowo uruchamia kod na main thread.
  • Page buildery – Elementor ładuje własny framework JS (frontend.min.js ~150 KB) na każdej stronie, nawet jeśli dana strona nie używa żadnych dynamicznych widgetów Elementora.
  • jQuery i jego pluginy – WordPress nadal domyślnie ładuje jQuery. Wiele motywów i wtyczek używa jQuery plugins, które blokują main thread.

Jak naprawić:

  • Delay JavaScript – WP Rocket pozwala opóźnić ładowanie JS do pierwszej interakcji użytkownika (scroll, kliknięcie, tapnięcie). Dodaj do listy wykluczonych tylko skrypty krytyczne (np. menu mobilne, krytyczne animacje above the fold). Darmowa alternatywa: wtyczka Flying Scripts.
  • Ogranicz wtyczki – każda wtyczka to potencjalny JS. Audytuj listę wtyczek raz na kwartał. Jeśli wtyczka dodaje JS na każdej stronie, a jest potrzebna tylko na jednej – użyj warunkowego ładowania:
add_action('wp_enqueue_scripts', function() {
    // Laduj Contact Form 7 tylko na stronie kontakt
    if (!is_page('kontakt')) {
        wp_dequeue_script('contact-form-7');
        wp_dequeue_style('contact-form-7');
    }
    // Laduj WooCommerce JS tylko w sklepie
    if (!is_woocommerce() && !is_cart() && !is_checkout()) {
        wp_dequeue_script('wc-cart-fragments');
    }
});

Wtyczka Perfmatters ($24.95/rok) daje graficzny interfejs do tego samego – Script Manager, w którym klikasz, które skrypty ładować na których stronach.

  • Zamień ciężkie rozwiązania na lekkie – Revolution Slider → statyczny obraz z CSS (lub lekki Splide.js – 2 KB vs 200 KB), WOW.js → CSS @keyframes z IntersectionObserver, jQuery-based modal → natywny element <dialog>, który jest obsługiwany przez wszystkie nowoczesne przeglądarki.
  • Web Workers – jeśli masz złożone obliczenia w JS (np. filtrowanie produktów na stronie, sortowanie tabel), przenieś je do Web Workera, żeby nie blokować main thread. To zaawansowana technika, ale daje realne rezultaty w sklepach z dużą liczbą produktów.
  • Podziel długie taski JS – jeśli masz własny kod JavaScript, który wykonuje się dłużej niż 50 ms, podziel go na mniejsze fragmenty używając requestAnimationFrame() lub scheduler.yield() (nowe API dostępne w Chrome).

CLS – stabilność wizualna strony

CLS to metryka, którą najczęściej psują proste błędy, łatwe do naprawienia. Paradoksalnie, to też metryka, którą najczęściej ignorują developerzy, bo problem nie jest widoczny na szybkim łączu desktopowym – ale użytkownik mobilny na 3G widzi go wyraźnie.

Najczęstsze przyczyny CLS na WordPressie:

  • Obrazy bez wymiarów – brak atrybutów width i height na <img>. Przeglądarka nie wie, ile miejsca zarezerwować, więc treść „skacze” po załadowaniu obrazu. WordPress 6.1+ automatycznie dodaje wymiary do nowo uploadowanych obrazów, ale starsze treści (migrowane z innych CMS-ów, dodane przez stare wtyczki) mogą ich nie mieć.
  • Reklamy i embedy – reklamy Google AdSense, osadzone filmy z YouTube, mapy Google, widgety social mediów – jeśli nie mają zarezerwowanego miejsca, powodują przesunięcia. iframe YouTube bez określonych wymiarów to klasyczny błąd CLS.
  • Czcionki web – FOUT (Flash of Unstyled Text) lub FOIT (Flash of Invisible Text) powodują przesunięcia, gdy czcionka się załaduje i zmieni wielkość tekstu. Google Fonts ładowane z CDN Google to dodatkowe opóźnienie DNS + TLS + download.
  • Dynamicznie wstrzykiwane elementy – cookie bary, powiadomienia push, popupy subskrypcji newslettera – jeśli przesuwają treść strony zamiast nakładać się na nią jako overlay.
  • Late-loading sidebar/widgety – widgety ładowane przez JavaScript (popularne posty, reklamy, formularze) wstrzykiwane po załadowaniu DOM.

Jak naprawić:

  • Aspect ratio dla obrazów – dodaj CSS globlanie w motywie:
img {
    max-width: 100%;
    height: auto;
}

/* Kontenery embedów wideo */
.video-container {
    aspect-ratio: 16/9;
    width: 100%;
}

/* Kontenery reklam */
.ad-slot {
    min-height: 250px; /* rozmiar 300x250 */
    background: #f5f5f5;
}
  • Font-display: swap + preload + lokalne hostowanie:
<link rel="preload" href="/fonts/inter-var.woff2" as="font" 
      type="font/woff2" crossorigin>

/* W CSS */
@font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-var.woff2') format('woff2');
    font-display: swap;
    size-adjust: 100%;
    unicode-range: U+0000-024F, U+0100-024F; /* lacinskie + PL */
}

Wtyczka OMGF (darmowa) automatyzuje lokalne hostowanie Google Fonts – pobiera pliki czcionek, generuje @font-face i eliminuje zewnętrzne żądanie do fonts.googleapis.com.

  • Cookie bar jako overlay – użyj position: fixed na dole ekranu, nie position: relative u góry strony. Cookie bar na górze, który przesuwa całą stronę w dół po załadowaniu, to jeden z najczęstszych powodów złego CLS.
  • Lazy load iframe’ów z placeholderem – zamiast ładować iframe YouTube od razu, załaduj miniaturkę zdjęcia i zamień na iframe po kliknięciu. Wtyczka WP YouTube Lyte robi to automatycznie i przy okazji oszczędza 500+ KB JS na każdym osadzonym filmie.

Narzędzia do pomiaru Core Web Vitals

Nie optymalizuj na ślepo. Zmierz, napraw, zmierz ponownie. Każde narzędzie daje nieco inną perspektywę:

Narzędzie Typ danych Koszt Kiedy używać
PageSpeed Insights Lab + Field Darmowe Szybka diagnoza pojedynczej strony
Google Search Console (CWV) Field (28 dni) Darmowe Monitoring całej witryny, trendy
Chrome DevTools (Performance) Lab Darmowe Debugowanie konkretnych problemów, identyfikacja długich tasków JS
Web Vitals Extension Lab (realtime) Darmowe Szybki podgląd CWV w trakcie pracy nad stroną
CrUX Dashboard (Looker Studio) Field (miesięczne) Darmowe Trendy historyczne, porównanie z konkurencją
DebugBear / Treo Lab + Field Od $12/msc Monitoring ciągły z alertami email/Slack
WebPageTest Lab Darmowe Zaawansowana analiza waterfall, test z różnych lokalizacji

Ważna uwaga: wyniki lab (symulowane na standardowym sprzęcie) i field (od prawdziwych użytkowników z Chrome UX Report) często się różnią. Google używa danych field do rankingu. Jeśli PageSpeed Insights pokazuje zły wynik lab (np. Performance Score 45), ale dane field są zielone – nie masz problemu z SEO. Ale nadal warto optymalizować pod UX, bo dane field reprezentują 75. percentyl – 25% użytkowników ma gorsze doświadczenie niż raportowane.

Jak czytać PageSpeed Insights: najpierw sprawdź sekcję „Field data” na górze – to dane od prawdziwych użytkowników. Jeśli jest dostępna (wymaga wystarczającego ruchu), to Twoja rzeczywistość. Sekcja „Lab data” poniżej to symulacja na Moto G Power z wolnym 4G – przydatna do diagnozy, ale nie odzwierciedla bezpośrednio Twojej pozycji w rankingu.

Top 10 wtyczek do optymalizacji wydajności WordPressa

Poniższe wtyczki są sprawdzone w praktyce na dziesiątkach stron. Nie instaluj wszystkich naraz – wybierz zestaw, który pasuje do Twojej konfiguracji. Niektóre wtyczki wzajemnie się wykluczają (np. WP Rocket i LiteSpeed Cache – nie używaj dwóch wtyczek cache jednocześnie).

  • WP Rocket (od $59/rok) – najlepsza wtyczka cache all-in-one. Cache stron, minifikacja CSS/JS, lazy load obrazów i iframe, preload, delay JS, remove unused CSS, krytyczny CSS. Działa z większością hostingów i motywów. Jedyna wada: płatna, bez free tiera.
  • LiteSpeed Cache (darmowa) – alternatywa dla WP Rocket jeśli Twój hosting działa na serwerze LiteSpeed/OpenLiteSpeed. Wyśmienita integracja na poziomie serwera, często szybsza niż WP Rocket na kompatybilnych hostingach. Obsługuje też CDN QUIC.cloud (darmowy tier dostępny).
  • Autoptimize (darmowa) – łączenie i minifikacja CSS/JS. Solidna baza, jeśli nie chcesz płacić za WP Rocket. Najlepiej działa w parze z Async JavaScript i wtyczką cache (np. Cache Enabler).
  • ShortPixel (darmowe 100 obrazów/msc, potem od $3.99/msc) – kompresja i automatyczna konwersja obrazów do WebP/AVIF. Działa przy uploadzie i masowo na istniejących obrazach. Oferuje lossy, glossy i lossless kompresję. Alternatywa: Imagify (od twórców WP Rocket) lub Smush.
  • Perfmatters ($24.95/rok) – kontrola nad ładowaniem skryptów per strona/typ posta. Script Manager pozwala wizualnie wyłączyć skrypty i style na stronach, które ich nie potrzebują. Możesz wyłączyć WooCommerce JS na stronach, które nie są sklepem, Contact Form 7 poza stroną kontaktową, itp.
  • OMGF (darmowa) – hostuje Google Fonts lokalnie zamiast ładować z CDN Google. Eliminuje zewnętrzne żądania DNS i TLS + poprawia prywatność (RODO – nie wysyłasz IP użytkowników do Google).
  • Flying Scripts (darmowa) – opóźnia ładowanie wybranych skryptów do pierwszej interakcji użytkownika. Darmowa alternatywa dla funkcji „Delay JavaScript” w WP Rocket. Wpisujesz URL-e skryptów do opóźnienia – proste i skuteczne.
  • Async JavaScript (darmowa) – dodaje async lub defer do skryptów. Naturalny partner Autoptimize. Pozwala ręcznie wykluczyć skrypty, które się psują po asynchronicznym załadowaniu.
  • Query Monitor (darmowa) – narzędzie diagnostyczne. Pokazuje wolne zapytania do bazy danych, czas ładowania każdej wtyczki, hooks, HTTP API calls. Używaj do diagnozy, nie zostawiaj na produkcji – samo dodaje 10-30 ms do każdego ładowania.
  • Pre* Party Resource Hints (darmowa) – automatycznie dodaje dns-prefetch, preconnect, prefetch i preload dla zewnętrznych zasobów. Przydatna, jeśli ładujesz zasoby z wielu zewnętrznych domen (CDN, analytics, czcionki, widgety).

Rekomendowany zestaw budżetowy (0 zł): LiteSpeed Cache (jeśli hosting obsługuje) lub Autoptimize + Async JavaScript + Flying Scripts + ShortPixel (free tier) + OMGF. To da Ci 70-80% efektu zestawu premium.

Rekomendowany zestaw premium (~$85/rok): WP Rocket + ShortPixel (paid) + Perfmatters. Mniej wtyczek, mniej konfiguracji, lepsze wyniki.

Checklista optymalizacji CWV – krok po kroku

Wykonuj w tej kolejności. Każdy krok mierz przed i po za pomocą PageSpeed Insights:

  • 1. Pomiar bazowy – zapisz wyniki PageSpeed Insights (mobile + desktop) dla 3-5 kluczowych stron (główna, oferta/produkt, wpis blogowy, kontakt, kategoria). Zapisz dokładne wartości LCP, INP, CLS – nie tylko wynik Performance Score.
  • 2. Hosting i PHP – sprawdź TTFB w DevTools (zakładka Network, pierwszy request HTML, kolumna „Waiting”). Jeśli przekracza 600 ms – rozważ migrację hostingu. Upewnij się, że działasz na PHP 8.1 lub nowszym. Różnica wydajności między PHP 7.4 a 8.2 to 20-40% szybsze działanie WordPressa.
  • 3. Audyt wtyczek – dezaktywuj wtyczki, których nie używasz. Zainstaluj Query Monitor i sprawdź, które wtyczki dodają najwięcej zapytań SQL i skryptów. Usuń niepotrzebne. Niektóre wtyczki można zastąpić kilkoma linijkami w functions.php.
  • 4. Cache – skonfiguruj cache całej strony (page cache). To pojedyncza zmiana, która daje największy efekt. Sprawdź, czy cache działa – w nagłówkach HTTP powinien pojawić się x-cache: HIT lub odpowiednik Twojej wtyczki.
  • 5. Obrazy – kompresja + WebP/AVIF + lazy loading (poza LCP) + wymiary width/height. Sam ten krok potrafi zmniejszyć wagę strony o 40-60%.
  • 6. CSS – remove unused CSS + inline critical CSS. WP Rocket robi oba automatycznie. W zestawie darmowym: Autoptimize + ręczne wycięcie nieuzywanych styli (DevTools → Coverage).
  • 7. JavaScript – defer/async na wszystkich skryptach non-critical + delay na third-party (GTM, piksele, chatboty) + warunkowe ładowanie per strona (Perfmatters lub ręcznie w functions.php).
  • 8. Czcionki – hostuj lokalnie (OMGF) + preload + font-display: swap. Rozważ zmniejszenie liczby wariacji czcionek – czy naprawdę potrzebujesz 6 wag (300, 400, 500, 600, 700, 800)?
  • 9. Baza danych – wyczyść tablicę wp_options z transientów i starych danych wtyczek. WP-Optimize (darmowa) robi to automatycznie. Sprawdź też wp_postmeta pod kątem osięroconych rekordów.
  • 10. Pomiar końcowy – ponowny test PSI. Porównaj z bazowym. Dane field w Search Console zaktualizują się po 28 dniach – nie oczekuj natychmiastowej zmiany w raporcie CWV.

Optymalizacja CWV to nie jednorazowa akcja. Każda aktualizacja motywu, nowa wtyczka, zmiana treści czy dodanie nowego widgetu może wpłynąć na wyniki. Ustaw monitoring (choćby darmowy CrUX Dashboard w Looker Studio albo alerty w Search Console) i reaguj, gdy wskaźniki się pogarszają. Strona, która stabilnie przechodzi CWV, ma mierzalną przewagę – i w pozycji w Google, i w doświadczeniu użytkowników, którzy zostają dłużej i chętniej konwertują.

Zabacz także Pokaż wszystkie
Linkbuilding 2026 – strategie które działają i te które szkodzą
Linkbuilding 2026 – strategie które działają i te które szkodzą
Linkbuilding w 2026 roku – co się zmieniło Linki zwrotne nadal są jednym z trzech najważniejszych czynników rankingowych Google.
Czytaj więcej
Dostępność stron WCAG 2026 – co musisz wiedzieć
Dostępność stron WCAG 2026 – co musisz wiedzieć
Dostępność cyfrowa nie jest już opcjonalna 28 czerwca 2025 roku weszła w życie Europejska Dyrektywa o Dostępności (European Accessibility Act – EAA).
Czytaj więcej
Konwersja w sklepie internetowym – 12 trików które działają
Konwersja w sklepie internetowym – 12 trików które działają
Czym jest konwersja i dlaczego to najważniejszy wskaźnik Twojego sklepu Średni współczynnik konwersji w polskich sklepach internetowych oscyluje wokół 1-2%.
Czytaj więcej