Optymalizacja szybkości WordPressa: WPO, cache i Core Web Vitals | WPPoland

Mariusz Szatkowski

Kompleksowa optymalizacja WordPressa, jak przyspieszyć stronę? (WPO)

Ostatnio zweryfikowano: 12 października 2026

17 min czytania

Przewodnik

500+ projektów WP

“Mój WordPress muli”. To zdanie słyszymy w wppoland.com co tydzień, w sumie już tysiące razy. I zazwyczaj odpowiedź nie brzmi “zainstaluj kolejną wtyczkę”, ale “posprzątaj to, co masz”. Najpierw trzeba zrozumieć, gdzie leży wąskie gardło, i usunąć jego przyczynę. Optymalizacja wydajności (WPO, Web Performance Optimization) to proces holistyczny. Nie wystarczy skompresować zdjęć, jeśli baza danych “kaszle” przy każdym zapytaniu. To uporządkowana praca na kilku warstwach naraz: hosting, kod, zasoby i zachowanie przeglądarki.

Oto kompletna mapa drogowa optymalizacji WordPressa, od podstaw po techniki zaawansowane. Przechodzimy przez każdą warstwę, od konfiguracji serwera po ostatnie malowanie na ekranie, z prawdziwymi liczbami i kodem, który możesz wdrożyć od razu.

#Jak szybkość strony WordPress wpływa na konwersję

Szybkość przekłada się wprost na wyniki biznesowe. Badania Google pokazują, że gdy czas ładowania rośnie z 1 do 3 sekund, prawdopodobieństwo odrzucenia (bounce) wzrasta o 32%. Przy 5 sekundach to prawdopodobieństwo skacze do 90%. W e-commerce Amazon zmierzył, że każde dodatkowe 100 ms opóźnienia kosztowało go 1% sprzedaży (Greg Linden, Amazon, 2006).

Core Web Vitals stały się potwierdzonym czynnikiem rankingowym Google w 2021 roku. Strony, które spełniają wszystkie trzy progi (LCP poniżej 2,5 sekundy, CLS poniżej 0,1 i INP poniżej 200 ms), dostają premię w mobilnych wynikach wyszukiwania. Według danych Chrome User Experience Report (CrUX) z końca 2025 roku tylko 43% domen na WordPressie przechodzi wszystkie trzy Core Web Vitals na urządzeniach mobilnych. Ponad połowa stron na WordPressie zostawia więc potencjał rankingowy na stole.

Badanie Deloitte “Milliseconds Make Millions” wykazało, że poprawa szybkości strony mobilnej o 0,1 sekundy podniosła współczynnik konwersji o 8,4% w handlu detalicznym i o 10,1% w branży turystycznej. Gdy przeliczysz to na własny ruch, koszt wolnej strony staje się konkretny. Sklep WooCommerce z przychodem 50 000 € miesięcznie może tracić 4000-5000 € co miesiąc, jeśli strona ładuje się w 4 sekundy zamiast w 2.

Optymalizacja szybkości to inwestycja techniczna o najwyższym zwrocie, jaką możesz zrobić.

#Jak zmierzyć szybkość strony WordPress

Nigdy nie zaczynaj optymalizacji bez punktu odniesienia. Potrzebujesz danych, a domysły tylko przeszkadzają.

PageSpeed Insights (PSI) pokazuje zarówno dane laboratoryjne (Lighthouse), jak i dane terenowe (CrUX). Dane laboratoryjne przydają się do debugowania, ale do rankingu Google używa danych terenowych, zbieranych od prawdziwych użytkowników Chrome przez 28 dni. Zawsze sprawdzaj “Origin Summary”, aby zobaczyć wynik całej domeny, a nie tylko pojedynczych podstron.

WebPageTest (webpagetest.org) oferuje wykresy kaskadowe (waterfall), widok klatek (filmstrip) i testy wieloetapowe. Uruchamiaj testy z lokalizacji blisko Twoich odbiorców. Użyj “repeat view”, aby zobaczyć, jak cache wpływa na kolejne wczytania. Wykres kaskadowy to najlepsze narzędzie diagnostyczne do wyłapywania wolnych skryptów zewnętrznych i zasobów blokujących renderowanie.

Zakładka Performance w Chrome DevTools pozwala nagrać pełne ładowanie strony i obejrzeć każdą klatkę, każde przesunięcie układu i każde długie zadanie. Użyj zakładki “Coverage” (Ctrl+Shift+P, potem wpisz “Coverage”), aby znaleźć nieużywany CSS i JavaScript. Tak wskażesz kandydatów do usunięcia albo odroczenia.

CrUX Vis (cruxvis.withgoogle.com) daje dane historyczne z CrUX History API. Google wycofał starszy CrUX Dashboard w Looker Studio na rzecz tego narzędzia. Śledź Core Web Vitals w czasie, bo pojedynczy wynik bez kontekstu niewiele mówi. Ustaw automatyczny monitoring w narzędziach takich jak SpeedCurve albo Calibre, aby wyłapać regresje, zanim trafią na produkcję.

Zapisz wartości wyjściowe: TTFB, LCP, CLS, INP, łączną wagę strony i liczbę żądań. Bez tych liczb nie udowodnisz, że optymalizacja zadziałała.

#Co naprawić w hostingu, serwerze i DNS WordPressa

Jeśli Twój serwer odpowiada wolno (TTFB > 600ms), żadna wtyczka Ci nie pomoże. Żadna sztuczka we frontendzie tego nie nadrobi. Time to First Byte (TTFB) powinien wynosić poniżej 200 ms dla stron z cache i poniżej 600 ms dla odpowiedzi dynamicznych.

Wersja PHP: PHP 8.3 lub nowszy, zgodnie z zaleceniem WordPress.org.
Baza danych: MySQL 8.0 lub nowszy albo MariaDB 10.11 lub nowsza.
Protokół: HTTP/2 lub HTTP/3 (QUIC) to konieczność. Pozwala przeglądarce pobierać wiele plików naraz jednym połączeniem.

#Która wersja PHP jest najszybsza dla WordPressa

WordPress.org zaleca PHP 8.3 lub nowszy. PHP 8.1 i starsze gałęzie nie dostają już poprawek bezpieczeństwa, więc zostając przy nich, tracisz i na szybkości, i na bezpieczeństwie. O ile przyspieszy konkretna strona po aktualizacji, zależy od motywu, wtyczek i cache. Zmierz TTFB przed zmianą i po niej, zamiast wierzyć w jeden mnożnik. Wersję PHP sprawdzisz przez phpinfo() albo w Narzędzia, Kondycja witryny, Informacje. Aktualizację przetestuj najpierw na stagingu: stare wtyczki to najczęstsze źródło fatal errorów po skoku wersji PHP.

#Jak skonfigurować OPcache dla WordPressa

OPcache kompiluje skrypty PHP do kodu bajtowego i trzyma je w pamięci współdzielonej. Włącz go i ustaw te wartości w php.ini:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.jit=1255
opcache.jit_buffer_size=128M

Ustawienie jit=1255 włącza tracing JIT w PHP 8.x, co pomaga przy operacjach obciążających procesor, takich jak budowanie strony.

#Object cache z Redis lub Memcached

WordPress domyślnie trzyma transienty, wyniki zapytań i dane sesji w tabeli wp_options. Redis lub Memcached przenoszą je do pamięci operacyjnej i mocno ograniczają liczbę zapytań do bazy. Typowa strona WordPress, która wykonuje 50-80 zapytań do bazy, może zejść do 5-10 dzięki trwałemu object cache. Zainstaluj rozszerzenie PHP redis, dodaj WP_REDIS_HOST do wp-config.php i użyj drop-inu object-cache.php z wtyczki Redis Object Cache.

#HTTP/2, HTTP/3 i CDN dla WordPressa

Multipleksowanie w HTTP/2 pozwala przeglądarce pobrać dziesiątki zasobów jednym połączeniem i usuwa stary problem blokowania kolejki (head-of-line blocking) z HTTP/1.1. HTTP/3 (QUIC) idzie dalej: nawiązuje połączenie bez dodatkowej wymiany pakietów (zero round trip) i lepiej radzi sobie z utratą pakietów. Cloudflare, Fastly i AWS CloudFront obsługują dziś HTTP/3.

CDN (Content Delivery Network): Jeśli masz ruch z całego świata, użyj Cloudflare, aby serwować pliki z serwera najbliższego użytkownikowi. Przy ruchu międzynarodowym CDN jest obowiązkowy. Umieść statyczne zasoby (obrazy, CSS, JS, fonty) na serwerach brzegowych. W WordPressie skonfiguruj CDN tak, aby cache’ował pełne strony HTML dla niezalogowanych odwiedzających. Samo to potrafi obniżyć TTFB poniżej 50 ms na całym świecie.

#Dlaczego hosting współdzielony spowalnia WordPressa

Hosting współdzielony to w wppoland.com najczęstsze wąskie gardło. Przeciążone serwery, przestarzałe wersje PHP i brak obsługi object cache sprawiają, że optymalizacja wydajności jest prawie niemożliwa. Przenieś się na zarządzany hosting WordPress albo VPS z poprawnie skonfigurowanym NGINX lub LiteSpeed.

#Jak przyspieszyć backend i bazę danych WordPressa

To tutaj dzieje się “magia”, której nie widać, ale którą czuć przy pracy w panelu admina. Bazy danych WordPressa z czasem obrastają śmieciami. Rewizje wpisów, osierocone metadane, wygasłe transienty i komentarze ze spamem powiększają tabele i spowalniają zapytania.

#Jak wyczyścić rewizje, transienty i autoload

Revisions: WordPress domyślnie trzyma nieskończoną liczbę wersji każdego wpisu. Jeśli edytujesz post 100 razy, masz 100 kopii w bazie. Ogranicz to w wp-config.php:

define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 14 );

Transients: Wyczyść stare “transients” (dane tymczasowe) z bazy danych. Często wtyczki zostawiają tam śmieci. Wygasłe transienty mnożą się, gdy wtyczki nie sprzątają po sobie. Uruchom to zapytanie SQL, aby sprawdzić, ile danych ładujesz przez autoload:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

Jeśli wynik przekracza 1 MB, masz problem. Najcięższe wiersze znajdziesz tak:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Typowi winowajcy to ustawienia porzuconych wtyczek, zserializowane dane widżetów i rozdęte opcje motywu. Usuń to, czego nie potrzebujesz.

#Jak znaleźć wolne zapytania do bazy danych

Użyj wtyczki Query Monitor, aby znaleźć wolne zapytania podczas ładowania strony. Szukaj zapytań bez właściwych indeksów, zapytań wykonywanych w pętli (problem N+1) i zapytań pobierających dane, których nikt nie wyświetla. W zapytaniach własnych zawsze używaj WP_Query z konkretnymi fields i posts_per_page oraz z no_found_rows => true, gdy nie potrzebujesz paginacji:

$query = new WP_Query( [
    'post_type'      => 'product',
    'posts_per_page' => 10,
    'no_found_rows'  => true,
    'fields'         => 'ids',
] );

Parametr no_found_rows pomija kosztowne wywołanie SQL_CALC_FOUND_ROWS, co na dużych tabelach potrafi skrócić czas zapytania o połowę.

#WP-Optimize czy ręczne czyszczenie bazy danych

WP-Optimize to solidna wtyczka do planowego czyszczenia rewizji, szkiców, wpisów w koszu, spamu w komentarzach i transientów. Na stronach, gdzie potrzebujesz pełnej kontroli, połącz ręczne czyszczenie SQL z zadaniami zaplanowanymi w wp-cron. Liczy się regularność: konserwuj bazę co tydzień, a nie raz w roku, gdy coś się zepsuje.

#Jak ograniczyć Heartbeat API w WordPressie

Heartbeat API: Ogranicz “puls” WordPressa (autozapis, powiadomienia w adminie) za pomocą wtyczki “Heartbeat Control”, aby nie obciążać procesora serwera.

#Jak optymalizować obrazy w WordPressie

Obrazy to największa pojedyncza pozycja w wadze strony: według Web Almanac 2025 stanowią około 37% mediany strony mobilnej. Ich optymalizacja daje największą pojedynczą poprawę czasu ładowania.

#WebP czy AVIF dla obrazów w WordPressie

WebP daje pliki mniejsze o 25-35% niż JPEG przy tej samej jakości wizualnej. AVIF idzie dalej: przy zdjęciach pliki są o 30-50% mniejsze niż w WebP. Obsługa WebP w przeglądarkach jest dziś powszechna (ponad 98% globalnie). Obsługa AVIF to około 92% i wciąż rośnie.

Prawdziwe porównanie rozmiarów plików z projektu wppoland.com:

Format	Rozmiar pliku	Jakość
JPEG (oryginał)	285 KB	Punkt odniesienia
WebP	192 KB	Wizualnie identyczna
AVIF	128 KB	Wizualnie identyczna

To 55% mniej tylko dzięki zmianie formatu. Pomnóż to przez 40 obrazów na stronie, a oszczędzasz megabajty.

#Obrazy responsywne i lazy loading

WordPress przy wgrywaniu generuje kilka rozmiarów obrazu. Używaj atrybutów srcset i sizes, aby przeglądarka pobierała obraz w odpowiednim rozmiarze. Od WordPressa 5.5 atrybut loading="lazy" jest dodawany do obrazów automatycznie. Przy obrazach hero widocznych bez przewijania wyłącz lazy loading, aby nie opóźniać LCP:

add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
    if ( str_contains( $image, 'hero-image' ) ) {
        return false; // Wyłącz lazy loading dla obrazu hero
    }
    return $value;
}, 10, 3 );

#CDN dla obrazów w WordPressie

Usługi takie jak Cloudflare Images, imgix i Bunny Optimizer przetwarzają obrazy w locie: zmieniają rozmiar, konwertują do WebP/AVIF i usuwają metadane na serwerach brzegowych. Dzięki temu serwer nie musi generować dziesiątek miniatur. Dodaj fetchpriority="high" do elementu LCP, aby przeglądarka pobrała go w pierwszej kolejności:

<img src="hero.webp" fetchpriority="high" width="1200" height="630"
     alt="WordPress performance optimization dashboard">

#Jak usunąć blokujące renderowanie CSS i JavaScript

Tutaj walczymy o wynik w Google PageSpeed Insights i Core Web Vitals. Zasoby blokujące renderowanie to najczęstsza przyczyna słabego LCP. Przeglądarka nie namaluje ani jednego piksela, dopóki nie przetworzy całego synchronicznego CSS i JavaScriptu w <head>.

Minifikacja: Usuń zbędne spacje i komentarze z CSS/JS/HTML. (Robi to np. wtyczka Autoptimize lub WP Rocket).

#Jak ładować niekrytyczny CSS asynchronicznie

Przenieś niekrytyczny CSS poza <head> i ładuj go asynchronicznie:

<link rel="preload" href="/css/below-fold.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/below-fold.css"></noscript>

Defer JS: Przesuń ładowanie skryptów JavaScript na koniec (po załadowaniu HTML), aby nie blokowały renderowania strony. Używaj defer dla skryptów, które potrzebują dostępu do DOM, i async dla niezależnych skryptów, na przykład analityki:

add_filter( 'script_loader_tag', function( $tag, $handle ) {
    $defer_scripts = [ 'comment-reply', 'contact-form', 'analytics' ];
    if ( in_array( $handle, $defer_scripts, true ) ) {
        return str_replace( ' src=', ' defer src=', $tag );
    }
    return $tag;
}, 10, 2 );

#Jak wstawić krytyczny CSS inline

Wyodrębnij CSS potrzebny do wyrenderowania treści widocznej bez przewijania i wstaw go bezpośrednio w <head>. Automatyzują to narzędzia takie jak Critical (autorstwa Addy’ego Osmaniego) albo generator krytycznego CSS w WP Rocket. CSS wstawiony inline powinien mieć mniej niż 14 KB (tyle mieści pierwsze okno przeciążenia TCP), dzięki czemu przeglądarka wyrenderuje sensowną treść już po pierwszej odpowiedzi serwera.

#Jak usunąć nieużywany CSS za pomocą PurgeCSS

Użyj PurgeCSS albo UnCSS, aby przeanalizować wyrenderowane strony i usunąć nieużywane reguły CSS. Typowa strona WordPress z page builderem ładuje 300-500 KB CSS, z czego 70-80% nie jest używane na danej podstronie. Po oczyszczeniu:

# Przykładowa konfiguracja PurgeCSS
purgecss --css ./style.css \
         --content ./**/*.php ./**/*.html \
         --output ./style.purged.css

Regularnie widzimy, jak pliki CSS spadają z 400 KB do poniżej 60 KB po porządnym tree shakingu. Połącz to z minifikacją (cssnano) i kompresją Brotli, aby oszczędzić najwięcej.

#Jak wyłączyć skrypty i style wtyczek

Wiele wtyczek ładuje swoje zasoby na każdej stronie, także tam, gdzie nie są potrzebne. Wyłączaj je warunkowo:

add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_style( 'contact-form-7-css' );
        wp_dequeue_script( 'contact-form-7-js' );
    }
}, 100 );

#Warstwy cache w WordPressie od CDN do przeglądarki

Cache to najskuteczniejsza technika wydajności, bo całkowicie eliminuje pracę. Dobra strategia cachowania działa warstwami.

#Page cache

Zapisuj w pełni wyrenderowany HTML, aby WordPress i PHP nie uruchamiały się przy każdym żądaniu. NGINX FastCGI cache, LiteSpeed cache albo wtyczki takie jak WP Super Cache i WP Rocket serwują niezalogowanym odwiedzającym statyczny HTML. Strona, której dynamiczne wygenerowanie zajmuje 800 ms, z cache może przyjść w 10 ms.

#Object cache

Redis lub Memcached trzymają w pamięci wyniki zapytań do bazy, wywołań API i obliczonych wartości. Trwały object cache to warstwa, która najbardziej pomaga zalogowanym użytkownikom i dynamicznym stronom, których nie da się w całości objąć page cache.

#Nagłówki Cache-Control dla zasobów statycznych

Ustaw poprawne nagłówki Cache-Control dla zasobów statycznych. Niezmienne zasoby (wersjonowane pliki CSS/JS) cache’uj agresywnie:

location ~* \.(css|js|woff2|avif|webp|jpg|png|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Dla stron HTML używaj krótszych czasów cache albo stale-while-revalidate, aby pogodzić świeżość z szybkością:

Cache-Control: public, max-age=300, stale-while-revalidate=86400

#Cache w CDN

CDN powinien cache’ować zasoby statyczne w lokalizacjach brzegowych na całym świecie. Skonfiguruj czyszczenie cache tak, aby uruchamiało się przy aktualizacji treści. Cloudflare APO (Automatic Platform Optimization) dla WordPressa cache’uje pełne strony HTML na brzegu sieci i automatycznie je czyści, gdy publikujesz lub aktualizujesz treść.

Warstwy działają w tej kolejności: cache brzegowy CDN, potem page cache na serwerze, potem object cache, na końcu cache przeglądarki. Każda warstwa łapie to, co przepuściła poprzednia.

#Jakie sztuczki developerskie dają największy zysk WPO

Zablokuj hotlinkowanie: Nie pozwól innym stronom kraść Twojego transferu wyświetlając Twoje obrazki u siebie.

#Jak zoptymalizować ładowanie fontów w WordPressie

Fonty webowe po cichu zabijają wydajność. Jedno żądanie do Google Fonts może dodać 200-500 ms do ścieżki krytycznego renderowania przez zapytanie DNS, nawiązanie połączenia i pobranie pliku z zewnętrznej domeny.

Fonty: Ładuj czcionki Google lokalnie lub używaj font-display: swap, aby tekst był widoczny natychmiast, zanim załaduje się ładny krój pisma.

#Jak hostować fonty lokalnie w WordPressie

Pobierz pliki fontów i serwuj je z własnej domeny. Znika wtedy narzut połączenia z zewnętrzną domeną, a Twój CDN może je cache’ować. Używaj wyłącznie formatu woff2: ma ponad 99% obsługi w przeglądarkach i najlepszą kompresję.

@font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-var.woff2') format('woff2');
    font-weight: 100 900;
    font-display: swap;
    unicode-range: U+0000-024F; /* Podzbiór łaciński */
}

#Jak używać font-display swap i preload fontów

Deklaracja font-display: swap każe przeglądarce od razu pokazać tekst w foncie zastępczym i podmienić go na własny font, gdy ten się załaduje. To zapobiega niewidocznemu tekstowi (FOIT) i poprawia LCP.

Załaduj główny font z wyprzedzeniem (preload), aby przeglądarka pobrała go w pierwszej kolejności:

<link rel="preload" href="/fonts/inter-var.woff2" as="font"
      type="font/woff2" crossorigin>

#Fonty zmienne i subsetting

Fonty zmienne (variable fonts) zawierają wiele grubości i stylów w jednym pliku. Zamiast ładować osobne pliki dla regular (400), medium (500), semibold (600) i bold (700), jeden plik fontu zmiennego obejmuje cały zakres. Zmienny font Inter waży 97 KB w woff2, a 4 osobne pliki statyczne razem 180 KB.

Ogranicz fonty do zakresów znaków, których naprawdę potrzebujesz. Podzbiór tylko łaciński może zmniejszyć plik o 40-60% w porównaniu z pełnym pokryciem Unicode. Pomogą w tym narzędzia takie jak glyphhanger albo parametr &text= w Google Fonts API.

#Jak poprawić LCP, CLS i INP w WordPressie

Core Web Vitals od Google to trzy metryki, które bezpośrednio wpływają na pozycję w wyszukiwarce. Żeby optymalizować celnie, musisz wiedzieć, co psuje każdą z nich.

#Jak poprawić LCP

LCP mierzy, jak szybko renderuje się największy widoczny element (zwykle obraz hero albo nagłówek). Cel to poniżej 2,5 sekundy.

Typowe przyczyny słabego LCP:

wolna odpowiedź serwera (wysoki TTFB),
CSS i JavaScript blokujące renderowanie,
niezoptymalizowane obrazy hero bez fetchpriority="high",
obrazy LCP z lazy loadingiem (usuń loading="lazy" z obrazów widocznych bez przewijania),
fonty webowe blokujące renderowanie tekstu.

LCP naprawisz, obniżając TTFB przez cache, wstawiając krytyczny CSS inline, ładując obraz LCP z wyprzedzeniem (preload) i dodając fetchpriority="high" do elementu hero.

#Jak zmniejszyć CLS

CLS mierzy stabilność wizualną, czyli to, jak bardzo układ strony nieoczekiwanie przesuwa się podczas ładowania. Cel to poniżej 0,1.

Typowe przyczyny słabego CLS:

obrazy i iframe’y bez jawnych atrybutów width i height,
treść wstrzykiwana dynamicznie (reklamy, osadzenia, banery cookie),
fonty webowe powodujące przeskok tekstu (FOUT),
późno ładowany CSS, który zmienia wymiary elementów.

Zawsze ustawiaj wymiary elementów multimedialnych. Dla responsywnych kontenerów używaj aspect-ratio w CSS. Rezerwuj miejsce na reklamy i treść dynamiczną za pomocą min-height.

#Jak poprawić INP

INP zastąpił FID w marcu 2024 roku i mierzy responsywność przez cały cykl życia strony, a nie tylko przy pierwszej interakcji. Cel to poniżej 200 ms.

Typowe przyczyny słabego INP:

długie zadania JavaScript blokujące wątek główny,
ciężkie obsługi zdarzeń click, scroll lub input,
zbyt duży DOM (ponad 1500 węzłów),
skrypty zewnętrzne konkurujące o czas wątku głównego.

Dziel długie zadania na mniejsze kawałki za pomocą requestIdleCallback albo scheduler.yield(). Używaj delegacji zdarzeń zamiast podpinać nasłuchiwacze do setek pojedynczych elementów. Bezwzględnie przeglądaj skrypty zewnętrzne: każdy usunięty to odzyskany czas wątku głównego.

// Break long tasks with yield points
async function processItems(items) {
    for (const item of items) {
        processItem(item);
        // Yield to the browser between items
        await scheduler.yield();
    }
}

#Lista kontrolna optymalizacji szybkości WordPressa

Przejdź tę listę krok po kroku przy każdym projekcie WordPress. Kolejność ma znaczenie: zacznij od serwera i idź na zewnątrz, w stronę przeglądarki.

#Warstwa serwera

Przejdź na PHP 8.3+ z włączonym OPcache i JIT
Skonfiguruj MySQL/MariaDB z właściwym rozmiarem buffer pool
Włącz HTTP/2 (albo HTTP/3, jeśli jest dostępny)
Uruchom Redis lub Memcached jako object cache
Przenieś się z hostingu współdzielonego na zarządzany albo VPS

#Warstwa bazy danych

Ogranicz rewizje wpisów do 5
Usuń wygasłe transienty i osierocone metadane
Sprawdź opcje ładowane przez autoload (trzymaj poniżej 800 KB)
Dodaj indeksy dla własnych zapytań po meta

#Warstwa zasobów

Konwertuj obrazy do WebP/AVIF z właściwymi wariantami zapasowymi
Dodaj width, height i fetchpriority="high" do obrazów LCP
Usuń loading="lazy" z obrazów widocznych bez przewijania
Hostuj fonty lokalnie w formacie woff2 z font-display: swap
Ładuj z wyprzedzeniem krytyczne fonty i obrazy LCP

#Warstwa kodu

Wstaw krytyczny CSS inline (poniżej 14 KB)
Dodaj defer albo async do całego niekrytycznego JavaScriptu
Wyłącz CSS/JS wtyczek na podstronach, gdzie nie są potrzebne
Usuń nieużywany CSS za pomocą PurgeCSS
Minifikuj i kompresuj wszystkie zasoby przez Brotli

#Warstwa cache

Włącz cache pełnych stron dla niezalogowanych odwiedzających
Skonfiguruj CDN z właściwymi nagłówkami cache
Ustaw Cache-Control: immutable dla wersjonowanych zasobów statycznych
Wdróż stale-while-revalidate dla odpowiedzi HTML

#Monitoring

Śledź 28-dniowe trendy danych terenowych w CrUX Vis
Monitoruj Core Web Vitals w Search Console
Uruchamiaj Lighthouse CI w procesie wdrożenia
Ustal budżety wydajności (waga strony, liczba żądań, cel LCP)

#Jak utrzymać szybkość WordPressa po optymalizacji

Optymalizacja wydajności to stała praktyka, a nie jednorazowy projekt. Każda nowa wtyczka, każda aktualizacja motywu i każdy skrypt zewnętrzny może przynieść regresję. Mierz na bieżąco, optymalizuj systematycznie i traktuj szybkość jako podstawową cechę produktu od pierwszego dnia.

Pamiętaj: szybka strona to nie cel sam w sobie. To narzędzie do wyższej konwersji i lepszego SEO. Każde 100ms opóźnienia kosztuje Cię utraconych klientów.

Potrzebujesz profesjonalnej optymalizacji? Sprawdź cennik usług WordPress, aby zlecić nam kompleksową optymalizację Twojej strony.

Po stronie wdrożenia ten temat trzymamy pod audyt Core Web Vitals.