Wydajność WordPress 2026: Core Web Vitals, cache i obrazy

W roku 2026 “szybkość” to nie tylko czas ładowania strony. To Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS) i utrzymanie kosztów serwera na niskim poziomie podczas skoków ruchu.

Wiele “poradników prędkości” mówi: “zainstaluj wtyczkę i módl się”. Ten przewodnik jest inny. To mapa całego stosu: progi, którymi Google mierzy stronę, źródła danych, warstwa serwera, baza, frontend, cache i to, co WordPress robi już sam w rdzeniu. Szczegółowe instrukcje dla pojedynczych tematów mają osobne artykuły, do których linkujemy w odpowiednich miejscach.

#Jakie są progi Core Web Vitals w 2026

Progi publikuje zespół Chrome na web.dev i od czasu, gdy INP zastąpił FID, nie zmieniły się. Według strony Web Vitals INP stał się stabilną metryką Core Web Vitals w 2024 roku. Granice “dobry” i “słaby” opisuje artykuł Defining the Core Web Vitals metrics thresholds:

Dwa szczegóły zmieniają sposób czytania tych liczb. Pierwszy: ocenę liczy się na 75. percentylu odsłon, osobno dla urządzeń mobilnych i desktopu. Strona przechodzi więc próg dopiero wtedy, gdy co najmniej trzy na cztery wizyty mieszczą się w granicy. Według web.dev 75. percentyl “rzadziej ulega wpływowi wartości odstających” (tłumaczenie własne, źródło: web.dev, Defining the Core Web Vitals metrics thresholds). Drugi: telefon i desktop to dwa osobne wyniki. Sklep może mieć zielony desktop i czerwony mobile, a Google indeksuje wersję mobilną. Ten wątek rozwija artykuł o wydajności mobile-first.

Web.dev zastrzega też, że metryki stabilne “nie muszą być trwałe” i mogą zostać zastąpione. Tak stało się z FID. Dlatego lepiej optymalizować przyczyny (wolny serwer, ciężki JavaScript, obrazy bez wymiarów) niż pod konkretną liczbę.

#Czy Core Web Vitals wpływają na pozycje w Google

Tak, ale słabiej, niż sugerują oferty “100/100 w PageSpeed”. Dokumentacja Google Search Central o page experience mówi wprost:

“Core Web Vitals są wykorzystywane przez nasze systemy rankingowe.”

Google Search Central, Understanding page experience in Google Search results (tłumaczenie własne)

W tym samym dokumencie Google dodaje, że dobre wyniki w raporcie “nie gwarantują, że strony będą na szczycie wyników wyszukiwania”, oraz że wyszukiwarka “zawsze stara się pokazać najtrafniejszą treść, nawet jeśli doświadczenie strony jest słabsze” (tłumaczenie własne). Nie ma też jednego sygnału “page experience”.

Wniosek praktyczny: wydajność nie wypchnie słabej treści, ale przy kilku równie trafnych wynikach może przesądzić o kolejności. Większy zysk z szybkości widać zwykle w zachowaniu użytkownika: w koszyku, w filtrach, w formularzu kontaktowym.

#Skąd brać dane: lab czy field

Lighthouse i zakładka “Diagnostyka” w PageSpeed Insights to dane laboratoryjne. Dokumentacja PageSpeed Insights opisuje różnicę tak: dane lab przydają się do debugowania, bo powstają w kontrolowanym środowisku, a dane field oddają rzeczywiste doświadczenie użytkowników (tłumaczenie własne).

Dane field w PSI pochodzą z Chrome User Experience Report (CrUX) i obejmują poprzednie 28 dni. Z tego wynikają trzy konsekwencje dla WordPressa:

• Poprawka wdrożona dziś pokaże się w pełni w danych field dopiero po około czterech tygodniach.
• Nowa albo mało odwiedzana podstrona często nie ma własnych danych. PSI pokazuje wtedy dane całej domeny (origin), a gdy i tych brakuje, nie pokazuje danych użytkowników w ogóle.
• Wynik Lighthouse z laptopa na szybkim łączu nie mówi nic o 75. percentylu użytkowników na telefonach.

Dlatego na liście kontrolnej na końcu stoi pomiar Real User Metrics (RUM). CrUX daje obraz z opóźnieniem, a własny RUM (biblioteka web-vitals albo narzędzie analityczne) pokazuje skutki zmiany szybciej i na poziomie konkretnych szablonów.

#Jak zbudować stos serwerowy dla szybkiego WordPressa

Nie naprawisz wolnego serwera wtyczką. Jeśli Twój Time To First Byte (TTFB) wynosi > 500ms, żadna minifikacja CSS Ci nie pomoże. TTFB nie jest jedną z trzech metryk Core Web Vitals, ale wlicza się w LCP: przeglądarka nie zacznie rysować niczego, zanim nie dostanie HTML.

#1. PHP 8.3 lub nowsze

Upewnij się, że używasz PHP 8.3 lub 8.4. Strona wymagań WordPressa zaleca PHP w wersji 8.3 lub wyższej oraz MySQL 8.0+ albo MariaDB 10.11+.

• Działanie: Sprawdź php -v. Jeśli widzisz 7.4, aktualizuj natychmiast.

Kompilator JIT (Just-In-Time) wprowadzony w PHP 8.0 kompiluje części kodu PHP bezpośrednio do kodu maszynowego, omijając wirtualną maszynę Zend dla zadań obciążających procesor. Dla typowego WordPressa nie jest to jednak główny zysk. Dokument RFC JIT podaje, że JIT przyspieszył bench.php ponad dwukrotnie (0,140 s wobec 0,320 s), ale “nie wydaje się znacząco poprawiać realnych aplikacji, takich jak WordPress” (tłumaczenie własne): 326 żądań na sekundę z JIT wobec 315 bez niego. WordPress spędza większość czasu na zapytaniach do bazy i operacjach wejścia/wyjścia, więc ważniejsze są aktualna wersja PHP i włączony OPcache.

#2. Nginx zamiast Apache

Apache jest świetny dla kompatybilności (.htaccess), ale Nginx lepiej radzi sobie ze współbieżnością. Nginx używa architektury sterowanej zdarzeniami. Według nginx.org 10 000 nieaktywnych połączeń keep-alive zajmuje około 2,5 MB pamięci, podczas gdy Apache w klasycznych trybach (prefork) obsługuje każde połączenie osobnym procesem lub wątkiem.

#3. Object cache (Redis/Valkey)

To najważniejsze “odblokowanie” dla dynamicznych stron (WooCommerce). WordPress naturalnie odpytuje bazę danych o wszystko (opcje, użytkownicy, post meta). Redis przechowuje wyniki tych zapytań w pamięci RAM.

• Bez Redisa: obiekty zbuforowane w trakcie jednego żądania znikają po jego zakończeniu, więc każda odsłona ponownie pyta bazę o te same opcje i metadane.
• Z Redisem: cache obiektów przeżywa między żądaniami. Do bazy trafiają zapytania, których wynik nie jest jeszcze w cache, oraz te, których WordPress nie buforuje.
• Konfiguracja: Najpopularniejszy drop-in to wtyczka Redis Object Cache autorstwa Tilla Krüssa (ponad 500 000 aktywnych instalacji), działająca z klientami PhpRedis, Predis i Relay. Stan połączenia sprawdzisz poleceniem wp redis status.

#Jak poprawić Core Web Vitals na frontendzie

Core Web Vitals od Google to punkt odniesienia dla całego frontendu. W 2026 roku metryką, z którą najwięcej stron WordPress ma kłopot, jest INP (Interaction to Next Paint).

#Jak poprawić INP w WordPressie

INP mierzy, jak szybko przeglądarka reaguje po kliknięciu, dotknięciu lub naciśnięciu klawisza. Web.dev w artykule Optimize INP dzieli każdą interakcję na trzy fazy: opóźnienie wejścia (od akcji użytkownika do startu obsługi zdarzenia), czas przetwarzania (wykonanie callbacków) i opóźnienie prezentacji (czas do narysowania następnej klatki). Każda faza ma inną przyczynę i inną poprawkę. Jeśli wątek główny jest zablokowany przez wykonywanie JavaScriptu, Twój INP cierpi.

• Winowajca: Ciężkie page buildery, nieoptymalizowane skrypty zewnętrzne (widgety czatu, piksele śledzące).
• Rozwiązanie:
  1. Ustąp głównemu wątkowi (yield to main thread): Odłóż (defer) nieistotny JS i dziel długie zadania na mniejsze.
  2. Web Workers: Przenieś ciężką logikę (np. skomplikowane obliczenia) poza główny wątek.
  3. Debouncing: Nie wysyłaj zapytania PHP przy każdym naciśnięciu klawisza w wyszukiwarce; poczekaj, aż użytkownik przestanie pisać przez 300ms.

Web.dev zauważa też, że przy małym DOM renderowanie zwykle kończy się szybko, a duże drzewo DOM wymaga więcej pracy. Ciężkie page buildery uderzają więc w INP dwa razy: skryptami i liczbą węzłów. Szczegóły, od scheduler.yield() po pomiar w Chrome DevTools, opisuje przewodnik po optymalizacji INP. Osobnym tematem są skrypty firm trzecich, im poświęcony jest artykuł o redukcji wpływu skryptów zewnętrznych.

#Nowe formaty obrazów (AVIF vs WEBP)

AVIF jest w 2026 roku najlepiej skompresowanym formatem, który WordPress obsługuje w rdzeniu, a WebP zostaje rozsądnym wariantem zapasowym. Według ogłoszenia zespołu WordPress obrazy AVIF mogą być nawet o 50% mniejsze niż JPEG przy tej samej jakości.

• WordPress 6.5+ obsługuje AVIF natywnie, o ile biblioteka obrazów na serwerze (Imagick albo GD) ma wsparcie AVIF. Sprawdzisz to w Narzędzia, Zdrowie witryny, Informacje, sekcja “Obsługa mediów”.
• Działanie: Upewnij się, że Twój potok optymalizacji obrazów (lub CDN) tworzy wersję AVIF automatycznie. W samym WordPressie służy do tego filtr image_editor_output_format, który pozwala zapisywać miniatury przesłanych plików JPEG jako AVIF.

#Co WordPress optymalizuje sam w rdzeniu

Część pracy, którą kilka lat temu robiły wtyczki, wykonuje dziś rdzeń. Warto wiedzieć, co już działa, zanim doinstaluje się kolejną wtyczkę, która zrobi to samo drugi raz.

Priorytet obrazu LCP (WordPress 6.3). Według notatki zespołu WordPress rdzeń dodaje fetchpriority="high" do obrazu, który uznaje za najbardziej prawdopodobny element LCP. Obraz musi być w widoku i mieć co najmniej 50 000 pikseli powierzchni (szerokość razy wysokość). Ten sam obraz nigdy nie dostaje jednocześnie loading="lazy". Domyślna wartość filtra wp_omit_loading_attr_threshold wzrosła z 1 do 3, więc pierwsze obrazy na stronie nie są leniwie ładowane. Motyw albo wtyczka, która wymusza lazy loading na wszystkim, psuje ten mechanizm i opóźnia LCP.

AVIF (WordPress 6.5). Opisany wyżej: przesyłanie plików AVIF i konwersja przez image_editor_output_format.

Autoload opcji (WordPress 6.6). Opisany niżej w części o bazie danych: duże opcje bez jawnej flagi autoload przestały ładować się przy każdym żądaniu.

Speculative loading (WordPress 6.8). Według notatki deweloperskiej rdzeń włącza domyślnie spekulatywne ładowanie na froncie wszystkich stron, z wyjątkiem zalogowanych użytkowników i witryn bez przyjaznych bezpośrednich odnośników. Używa prefetch (nie prerender) z gorliwością conservative, czyli pobieranie zaczyna się, gdy użytkownik zaczyna klikać link. Adresy z parametrami zapytania są wykluczone automatycznie. Speculation Rules API obsługują Chrome, Edge i Opera, inne przeglądarki je ignorują. Konfigurację zmienia filtr wp_speculation_rules_configuration (zwrócenie null wyłącza funkcję dla danego żądania), a ścieżki wyklucza wp_speculation_rules_href_exclude_paths. Pojedynczy blok można wyłączyć klasą CSS no-prefetch albo no-prerender. Sklep, w którym linki prowadzą do akcji (dodanie do koszyka, wylogowanie), powinien takie ścieżki wykluczyć.

Performance Lab. Następne funkcje rdzenia testuje wtyczka Performance Lab prowadzona przez WordPress Performance Team. Zarządza osobnymi wtyczkami funkcyjnymi, m.in. Modern Image Formats, Image Prioritizer, Embed Optimizer, Enhanced Responsive Images, Image Placeholders, Instant Back/Forward, Performant Translations, Speculation Rules i eksperymentalną View Transitions. Dodaje też testy w Zdrowiu witryny, w tym sprawdzenie nagłówka Cache-Control: no-store blokującego bfcache, nagłówków wygasania zasobów statycznych i wsparcia AVIF. Na stagingu jest to tani sposób, żeby sprawdzić, czy serwer i motyw są gotowe na kolejne wersje WordPressa.

#Jak zoptymalizować bazę danych WordPressa

Rozdęta tabela wp_options może rzucić serwer na kolana.

#1. Opcje autoload w wp_options

WordPress ładuje każdą opcję oznaczoną do autoloadu przy każdym ładowaniu strony. Jeśli wtyczka zapisuje blob JSON o wielkości 1MB w opcjach i ustawia go na autoload, ładujesz 1MB zmarnowanych danych z bazy do RAM przy każdej odsłonie.

WordPress 6.6 zmienił zasady. Według notatki zespołu WordPress kolumna autoload przyjmuje teraz pięć wartości: on, off, auto, auto-on i auto-off. Opcja bez jawnego true, większa niż 150 000 bajtów, nie jest już ładowana automatycznie (próg zmienia filtr wp_max_autoloaded_option_size, którego nie warto podnosić). Od wersji 6.6 Zdrowie witryny ostrzega, gdy łączny rozmiar opcji ładowanych automatycznie przekroczy 800 KB.

• Działanie: Sprawdź zużycie: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto'); Jeśli jest > 800KB, masz problem. Starsze opcje mogą wciąż mieć wartość yes, dlatego zapytanie obejmuje oba zestawy wartości.

#2. Czyszczenie wygasłych transients

Transients to tymczasowe dane w cache (np. “Wyniki Twitter Feed”). Powinny wygasać i znikać. Jednak, jeśli cron job je przegapi, gromadzą się w nieskończoność.

• Działanie: Użyj WP-CLI, aby je wyczyścić: wp transient delete --expired.

Przy aktywnym trwałym object cache (Redis) transients trafiają do Redisa, a nie do wp_options, więc ten problem dotyczy głównie stron bez object cache.

#3. InnoDB zamiast MyISAM

Upewnij się, że Twoje tabele używają InnoDB (lub MyRocks dla ogromnych zbiorów danych). Nigdy nie używaj MyISAM (blokuje całą tabelę przy każdym zapisie, zabijając współbieżność).

#Jak zbudować strategię cache w WordPressie

1. Browser Cache: Najszybszy cache to ten, którego nigdy nie tworzysz. Ustaw długie nagłówki Cache-Control (1 rok) dla zasobów statycznych.
2. CDN / Edge Cache: Cloudflare lub Fastly serwujące Twój HTML z serwera blisko użytkownika. Użyj strategii Stale-While-Revalidate.
3. Page Cache (Serwer): Nginx FastCGI Cache lub Varnish. Serwuje HTML z RAM.
4. Object Cache: Redis. Opisane powyżej.
5. OpCache: Kod PHP skompilowany do bajtkodu w RAM.

Unikaj nagłówka Cache-Control: no-store na zwykłych stronach HTML: Performance Lab zgłasza go w Zdrowiu witryny, bo wyłącza pamięć podręczną wstecz/dalej (bfcache), czyli natychmiastowy powrót do poprzedniej strony. Konfigurację każdej warstwy krok po kroku opisuje kompleksowy przewodnik po optymalizacji WordPressa (WPO).

#W jakiej kolejności optymalizować wydajność WordPressa

Części tego przewodnika działają najlepiej stosowane po kolei i pojedynczo, z pomiarem przed i po każdej zmianie.

Zacznij od serwera. Zapisz TTFB najważniejszych podstron i wersję zwracaną przez php -v. Dopóki TTFB przekracza 500ms, żadna optymalizacja frontendu nie zrekompensuje opóźnienia.

W bazie danych uruchom zapytanie o rozmiar opcji autoload i zapisz wynik. Po wyczyszczeniu opcji i uruchomieniu wp transient delete --expired powtórz zapytanie, żeby potwierdzić, że wartość spadła.

Na frontendzie metryką do obserwowania jest INP. Spisz, które skrypty zewnętrzne ładują się na każdej stronie, na przykład widgety czatu i piksele śledzące, i odkładaj nieistotne pojedynczo, żeby wiedzieć, który z nich faktycznie ważył.

W cache włączaj jedną warstwę naraz i sprawdzaj, czy serwowany HTML aktualizuje się po opublikowaniu nowej treści.

Na każdej warstwie obowiązuje ta sama zasada co na liście kontrolnej: wyniki Lighthouse służą za wskazówkę, a ostateczną decyzję podejmuje się na danych RUM od prawdziwych użytkowników. Pamiętaj o 28-dniowym oknie CrUX: werdykt w Search Console przyjdzie po kilku tygodniach.

#Lista kontrolna wydajności WordPressa na 2026

• Serwer działa na PHP 8.3+ z włączonym OPcache.
• Baza danych używa InnoDB, a opcje autoload mieszczą się poniżej 800 KB.
• Object Cache (Redis) jest aktywny.
• Obrazy są serwowane jako AVIF, a obraz LCP nie ma loading="lazy".
• JavaScript jest odłożony (deferred), aby naprawić INP.
• Spekulatywne ładowanie z WordPressa 6.8 nie obejmuje linków wykonujących akcje.
• Mierzysz Real User Metrics (RUM), a nie tylko wyniki Lighthouse, osobno dla mobile i desktopu.

Wydajność to doświadczenie użytkownika. Szybka strona szanuje czas Twojego użytkownika.

Potrzebujesz profesjonalnej optymalizacji? Jako specjalista WordPress pomagam w przyspieszaniu stron. Sprawdź także cennik usług WordPress.