Czy twoja strona na WordPress jest wolna?

Gdy właściciel serwisu zauważa, że jego WordPress zaczyna działać ociężale, pierwszym odruchem jest zazwyczaj kontakt z hostingodawcą i zakup droższego pakietu serwerowego. To jednak w większości przypadków leczenie objawowe, które nie usuwa rzeczywistych przyczyn problemu. Jeśli aplikacja wykonuje setki nieoptymalnych zapytań do bazy danych, wczytuje megabajty danych autoload przy każdym żądaniu i blokuje wątek główny przeglądarki dziesiątkami skryptów zewnętrznych, nawet mocny serwer dedykowany nie zapewni płynnego działania.

W tym przewodniku przechodzę przez pełny proces diagnostyki i technicznej optymalizacji wolnej strony na WordPressie: od metryk serwerowych (TTFB, PHP-FPM, MySQL), przez bazę danych i pamięć podręczną obiektów, aż po obrazy, skrypty i zasoby ładowane w przeglądarce użytkownika.

#Czy lepszy hosting przyspieszy WordPressa

Zmiana serwera może pomóc, ale tylko w jednej części problemu. Hosting wpływa przede wszystkim na TTFB (Time to First Byte), czyli czas, po którym serwer zaczyna odpowiadać. Większość czasu, który użytkownik odczuwa jako ładowanie, przypada jednak na pobieranie, parsowanie i wykonywanie zasobów frontendu: obrazów, CSS, JavaScriptu i fontów. Jeśli te zasoby są źle obsłużone, nawet drogi serwer dedykowany poda wolną stronę.

Zanim zapłacisz za wyższy pakiet, sprawdź, gdzie naprawdę powstaje opóźnienie. Prosta reguła: wysoki TTFB wskazuje na serwer, PHP lub bazę danych, a dobry TTFB przy wolnej stronie wskazuje na frontend. Obie sytuacje wymagają zupełnie innych działań.

#Jak mierzyć wydajność WordPressa bez pozorów

Zanim przejdziesz do instalacji wtyczek optymalizacyjnych czy modyfikacji kodu szablonu, musisz mieć twarde dane pomiarowe. Testowanie prędkości we własnej przeglądarce jest obarczone błędem ze względu na lokalną pamięć podręczną oraz bliskość geograficzną do serwera.

#Czym jest TTFB i jak go zmierzyć

Time to First Byte to czas od wysłania żądania HTTP do odebrania pierwszego bajta odpowiedzi. Według web.dev obejmuje on przekierowania, start service workera, zapytanie DNS, zestawienie połączenia razem z negocjacją TLS oraz samo żądanie. Dobry TTFB to 0,8 sekundy lub mniej, a wartości powyżej 1,8 sekundy web.dev uznaje za słabe. W praktyce WordPressa:

• Poniżej 200 ms: wynik typowy dla stron serwowanych z buforowania stron (Page Cache) lub z krawędzi sieci (Edge Cache).
• 200-800 ms: zakres, w którym zwykle mieszczą się dynamiczne podstrony generowane przez PHP bez buforowania.
• Powyżej 800 ms: sygnał, że trzeba szukać przyczyny w bazie danych, powolnych zapytaniach SQL, braku OPcache lub zbyt małej puli procesów PHP-FPM.

TTFB zmierzysz z konsoli za pomocą cURL:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Połączenie: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s | Łącznie: %{time_total}s\n" https://twojadomena.pl/

#Jak znaleźć wolne zapytania w Query Monitor

Najlepszym bezpłatnym narzędziem do inspekcji procesów wewnętrznych WordPressa na środowisku deweloperskim lub stagingowym jest wtyczka Query Monitor. Po jej aktywacji administrator dostaje panel zawierający:

• Liczbę zapytań SQL wykonanych podczas renderowania strony.
• Czas trwania poszczególnych zapytań z oznaczeniem zapytań powolnych (domyślnie przekraczających 0,05 s).
• Wykaz zduplikowanych zapytań do tabel wp_posts czy wp_postmeta.
• Zużycie pamięci przez proces PHP.
• Listę wywołań zewnętrznych API HTTP (wp_remote_get), które mogą blokować generowanie strony.

#W jakiej kolejności diagnozować wolną stronę

Kolejność pomiarów decyduje o tym, czy szukasz problemu we właściwym miejscu:

1. PageSpeed Insights. Daje dane terenowe Core Web Vitals (jeśli strona ma wystarczający ruch) oraz listę możliwości poprawy uszeregowanych według wpływu.
2. Wykres kaskadowy (waterfall). WebPageTest albo zakładka Network w Chrome DevTools pokazują, jakie zasoby się ładują, w jakiej kolejności i ile trwa każdy z nich.
3. Query Monitor. Diagnostyka backendu: zapytania SQL, hooki, błędy PHP i czas poszczególnych komponentów.
4. TTFB. Jeśli przekracza 800 ms, problem leży po stronie serwera lub przetwarzania PHP.
5. Analiza kaskady przy dobrym TTFB. Gdy serwer odpowiada szybko, a strona nadal jest wolna, winne są zasoby frontendu: ciężkie obrazy, zbyt wiele plików CSS i JS albo skrypty zewnętrzne blokujące renderowanie.

#Jakie wąskie gardła spowalniają WordPressa najczęściej

Gdy znasz już skalę problemu, pora przeanalizować obszary, w których najczęściej dochodzi do spadku wydajności.

#1. Tabela wp_options i rekordy autoload

Globalne ustawienia WordPressa i większości wtyczek trafiają do tabeli wp_options. Rekordy oznaczone do automatycznego ładowania są pobierane jednym zapytaniem przy każdym żądaniu, także do REST API i admin-ajax.

Od WordPressa 6.6 kolumna autoload przyjmuje nowe wartości: on, off, auto, auto-on i auto-off, obok starszych yes i no. Ta sama wersja przestała domyślnie autoloadować pojedyncze opcje większe niż 150 000 bajtów i dodała test w Zdrowiu witryny, który ostrzega, gdy łączny rozmiar autoloadowanych opcji przekracza 800 KB (ogłoszenie na make.wordpress.org). W serwisach, na których przez lata testowano dziesiątki wtyczek, ten limit bywa przekroczony kilkukrotnie, a PHP przy każdym żądaniu deserializuje dane, których nikt nie używa.

Łączny rozmiar danych autoload sprawdzisz zapytaniem SQL w phpMyAdmin lub przez wp db query. Lista wartości obejmuje zarówno stary, jak i nowy zapis:

SELECT SUM(LENGTH(option_value)) / 1024 AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Aby zidentyfikować największe pojedyncze rekordy:

SELECT option_name, LENGTH(option_value) AS option_size
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY option_size DESC
LIMIT 15;

Często okazuje się, że dawno odinstalowana wtyczka analityczna, logi transakcji lub duże tablice transientów nadal są ładowane przy każdym otwarciu strony.

#2. Niewydajne zapytania WP_Query i problem zapytań N+1

Problem N+1 pojawia się, gdy kod pobiera listę wpisów bez wczytania ich metadanych, a potem w pętli odpytuje bazę o każde pole osobno. Standardowe get_posts() i WP_Query tego nie robią: get_posts() korzysta z WP_Query (dokumentacja funkcji), a ta domyślnie wczytuje metadane wszystkich wpisów jednym zapytaniem (update_post_meta_cache ma domyślnie wartość true). Kłopot zaczyna się, gdy ktoś tę flagę wyłączy albo pobiera identyfikatory własnym zapytaniem przez $wpdb:

// Problem N+1: identyfikatory z własnego zapytania, metadane bez wczytanego cache.
$ids = $wpdb->get_col( "SELECT ID FROM {$wpdb->posts} WHERE post_type = 'product' AND post_status = 'publish' LIMIT 50" );
foreach ( $ids as $id ) {
    $cena = get_post_meta( $id, 'cena', true ); // Osobne zapytanie SQL dla każdego wpisu.
}

Rozwiązaniem jest wczytanie metadanych z góry jednym zapytaniem:

update_postmeta_cache( $ids ); // Jedno zapytanie o metadane wszystkich wpisów.
foreach ( $ids as $id ) {
    $cena = get_post_meta( $id, 'cena', true ); // Odczyt z cache, bez SQL.
}

Przy WP_Query bez paginacji dodaj też 'no_found_rows' => true. Flaga pomija liczenie wszystkich pasujących wierszy, które jest potrzebne tylko do budowy stronicowania. get_posts() ustawia ją automatycznie.

#3. Brak trwałego object cache (Redis, Memcached)

Domyślny Object Cache WordPressa działa tylko w ramach jednego żądania HTTP (non-persistent cache). Po wyrenderowaniu strony pamięć jest czyszczona, a kolejne żądanie odpytuje bazę od nowa.

Rozwiązaniem na poziomie serwera jest Redis lub Memcached. Obiekty WordPressa (dane użytkowników, termy taksonomii, wyniki zapytań) zostają wtedy w pamięci RAM między żądaniami. Dla deweloperów kluczowe jest korzystanie z API obiektów:

function wppoland_pobierz_dane_partnerow(): array {
    $cache_key = 'wppoland_partnerzy_dane';
    $group     = 'partnerzy';

    $dane = wp_cache_get($cache_key, $group);

    if (false === $dane) {
        // Obliczenia lub ciężkie zapytanie SQL
        $dane = wppoland_wykonaj_ciezkie_zapytanie();
        // Zapis do trwałego cache na 12 godzin (43200 s)
        wp_cache_set($cache_key, $dane, $group, 43200);
    }

    return $dane;
}

#4. Nieoptymalne obrazy

Zdjęcie prosto z aparatu waży kilka megabajtów, a przeglądarka musi je pobrać w całości, nawet jeśli szablon wyświetla je w ramce szerokości 800 pikseli. Najczęstsze błędy to:

• Zbyt duże wymiary. Plik 4000 na 3000 pikseli w miejscu, które ma 800 na 600, marnuje transfer i czas dekodowania.
• Zły format. PNG dla fotografii albo brak formatów WebP i AVIF. Według Google stratny WebP jest o 25-34% mniejszy od porównywalnego JPEG, a bezstratny o 26% mniejszy od PNG.
• Brak kompresji. Pliki wgrywane bez żadnego przetworzenia. Wtyczki takie jak Smush, ShortPixel czy Imagify kompresują każdy obraz trafiający do biblioteki mediów.

WordPress od wersji 4.4 generuje atrybut srcset, dzięki któremu przeglądarka pobiera wariant obrazu dopasowany do ekranu, a od wersji 5.5 dodaje natywne loading="lazy". Wersja 6.3 poszła dalej: sama oznacza obraz, który najpewniej będzie elementem LCP, atrybutem fetchpriority="high" i nie ustawia leniwego ładowania dla obrazów na górze strony (notatka deweloperska 6.3). Jeśli szablon wstawia obraz nagłówka w tle CSS lub poza standardowymi funkcjami, te mechanizmy go nie obejmą i trzeba dodać preload ręcznie:

<link rel="preload" as="image" href="/sciezka/do/hero.webp" type="image/webp" fetchpriority="high">

#5. Nadmiar skryptów zewnętrznych

Fonty Google, analityka, widżety społecznościowe, czaty na żywo, piksele reklamowe: każdy z tych dodatków to kolejne żądania HTTP i JavaScript, który trzeba pobrać, sparsować i wykonać, a jego szybkość nie zależy od ciebie. Nie chodzi o usunięcie wszystkiego, tylko o kontrolę:

• Opóźnione ładowanie. Skrypty niepotrzebne do pierwszego widoku ładuj dopiero po interakcji użytkownika.
• Ładowanie warunkowe. Czat lub mapę ładuj tylko na podstronach, które ich używają.
• Lokalne fonty. Pliki WOFF2 na własnym serwerze eliminują dodatkowe połączenie z zewnętrzną domeną.

Ciężki JavaScript odbija się przede wszystkim na INP, więc szczegóły tej metryki opisałem w osobnym poradniku o INP.

#Jak ograniczyć opcje autoload w wp_options

WordPress wczytuje wszystkie autoloadowane opcje funkcją wp_load_alloptions() na samym początku każdego żądania, zarówno na froncie, jak i w panelu. Te dane siedzą w pamięci, zanim szablon wykona choćby jedną linijkę. Puchną od ustawień dawno usuniętych wtyczek, rozbudowanych opcji motywu i narzędzi marketingowych, które trzymają całą konfigurację w jednej wielkiej zserializowanej tablicy.

Jak opisałem wyżej, od WordPressa 6.6 kolumna autoload może mieć wartości on, off, auto, auto-on i auto-off obok starszych yes i no. Za autoloadowane rdzeń uznaje yes, on, auto-on i auto (funkcja wp_autoload_values_to_autoload). Próg 150 000 bajtów pochodzi z filtra wp_max_autoloaded_option_size i działa w chwili zapisu opcji. Nie sprząta wierszy, które latami gromadziły się w bazie przed aktualizacją.

Łączny rozmiar autoloadowanych opcji podaje też WP-CLI. Polecenie z dokumentacji wp option list zwraca sumę w bajtach:

wp option list --autoload=on --format=total_bytes

Pamiętaj, że flaga --autoload filtruje po jednej wartości kolumny, więc w bazie, która ma jeszcze stare wiersze yes, wynik nie obejmie wszystkiego. Zapytanie SQL z listą czterech wartości, pokazane wcześniej, jest pełniejsze.

Zasady porządkowania na stagingu:

• usuń opcje odinstalowanych wtyczek dopiero wtedy, gdy potwierdzisz, że nic innego ich nie czyta
• duże, rzadko potrzebne opcje przestaw na off (lub no) i pobieraj funkcją get_option() tylko tam, gdzie są używane
• nie trzymaj w wp_options danych JSON liczonych w megabajtach; przenieś je do własnej tabeli, do pliku albo do object cache z jawnym kluczem

Odchudzony autoload obniża TTFB tam, gdzie page cache nie pomaga: przy żądaniach zalogowanych użytkowników, w koszyku i w panelu, bo PHP przestaje przy każdym starcie deserializować martwą konfigurację.

#Jak przyspieszyć WP_Query flagą no_found_rows

Domyślnie WP_Query każe MySQL policzyć wszystkie pasujące wiersze, żeby zbudować paginację. Ta praca idzie na marne, gdy potrzebujesz stałej liczby wpisów i nie korzystasz z max_num_pages.

W pętlach pomocniczych (powiązane wpisy, pięć najnowszych artykułów, zajawki w stopce) przekaż:

$powiazane = new WP_Query(
	array(
		'post_type'              => 'post',
		'posts_per_page'         => 5,
		'post_status'            => 'publish',
		'no_found_rows'          => true,
		'ignore_sticky_posts'    => true,
		'update_post_meta_cache' => false,
		'update_post_term_cache' => false,
	)
);

Co ma znaczenie na produkcji:

• no_found_rows ustawiaj na true tylko wtedy, gdy dane zapytanie nie potrzebuje liczenia stron
• wyłączaj wstępne wczytywanie metadanych i termów tylko w pętlach, które nie wyświetlają taksonomii ani pól własnych; w przeciwnym razie wracasz do problemu N+1 opisanego wyżej
• gdy potrzebujesz samych identyfikatorów do późniejszego odczytu z cache, użyj 'fields' => 'ids'
• unikaj połączeń meta_query i tax_query, które nie mogą skorzystać z indeksów; jeśli filtrowanie po metadanych jest konieczne, sprawdź plan EXPLAIN na stagingu

Główne pętle archiwów sterowane przez pre_get_posts nadal potrzebują liczenia wierszy, jeśli motyw wyświetla paginację. Oszczędne flagi stosuj do dodatków doklejonych do single.php i obszarów widżetów.

Stabilne zapytanie pomocnicze, które renderuje się na wielu adresach, warto dodatkowo opakować w object cache:

function wppoland_zajawki_wpisow() {
	$klucz = 'zajawki_wpisow_v1';
	$dane  = wp_cache_get( $klucz );

	if ( false !== $dane ) {
		return $dane;
	}

	$dane = new WP_Query(
		array(
			'posts_per_page' => 5,
			'post_status'    => 'publish',
			'no_found_rows'  => true,
		)
	);

	wp_cache_set( $klucz, $dane, '', HOUR_IN_SECONDS );
	return $dane;
}

Bez trwałego backendu object cache funkcje wp_cache_* działają tylko w obrębie jednego żądania. Wzorzec i tak dokumentuje intencję, a zysk między żądaniami daje dopiero Redis albo Memcached.

#Czy Redis object cache przyspiesza WordPressa

WordPress ma wbudowane API object cache, ale w domyślnej instalacji jest ono nietrwałe. Drop-in dla Redis (lub Memcached) trzyma opcje, fragmenty wyników zapytań i własne klucze w pamięci między żądaniami. Warstwy buforowania opisuje dokumentacja optymalizacji wydajności na developer.wordpress.org.

Po instalacji drop-inu dopasowanego do połączenia Redis u twojego hostingodawcy sprawdź, czy działa: polecenie wp cache type zgaduje, która implementacja object cache jest aktywna, a Query Monitor pokazuje to samo w panelu. Potem przetestuj unieważnianie cache przy publikacji wpisu i zmianie stanu magazynowego.

Kiedy Redis pomaga:

• przy dużym ruchu na szablonach, które przy każdym żądaniu powtarzają te same odczyty opcji i zapytania
• w sklepach WooCommerce i serwisach członkowskich, gdzie jedna strona wykonuje wiele drobnych odczytów
• gdy autoload jest już uporządkowany, a kosztowne zduplikowane zapytania nadal zostają

Kiedy Redis nie pomoże:

• HTML dla anonimowych użytkowników jest już w całości w page cache, a ty mierzysz wyłącznie trafienia w cache
• wąskim gardłem jest jedno zapytanie SQL trwające kilka sekund; cache ukryje je tylko do wygaśnięcia klucza
• hosting nie oferuje Redis, a ty nie możesz uruchomić go bezpiecznie

Page cache (cały HTML) i object cache (dane PHP) to różne warstwy i zwykle potrzebujesz obu. Pierwsza obsługuje anonimowe odsłony, druga przyspiesza PHP, które nadal działa przy chybieniach cache, w koszyku i w panelu.

#Co oznaczają LCP, INP i CLS w WordPressie

Google ocenia doświadczenie strony trzema metrykami Core Web Vitals. Progi dobrego wyniku według web.dev mierzy się na 75. percentylu odsłon, osobno dla urządzeń mobilnych i komputerów:

• Largest Contentful Paint (LCP), do 2,5 s. Największy element treści, zwykle zdjęcie w nagłówku, pojawia się za późno, bo przeglądarka najpierw przetwarza blokujące pliki CSS i JavaScript albo serwer odpowiada wolno.
• Interaction to Next Paint (INP), do 200 ms. Użytkownik klika menu lub przycisk koszyka, a strona reaguje z opóźnieniem, bo wątek główny jest zajęty skryptami analitycznymi, czatami i bibliotekami animacji.
• Cumulative Layout Shift (CLS), do 0,1. Elementy przesuwają się podczas ładowania z powodu obrazów bez wymiarów (width i height) albo doładowywanych reklam.

Dane terenowe znajdziesz w PageSpeed Insights i w raporcie Core Web Vitals w Google Search Console, a laboratoryjne w Chrome DevTools.

#Jak naprawić wolnego WordPressa krok po kroku

Poniżej plan optymalizacji podzielony na etapy, które najlepiej wdrażać po kolei.

#Etap 1: Optymalizacja środowiska serwerowego i PHP

1. Wersja PHP: WordPress zaleca PHP 8.3 lub nowsze. PHP 8.2 dostaje już tylko poprawki bezpieczeństwa i według harmonogramu php.net traci wsparcie 31 grudnia 2026, więc aktualizację zaplanuj od razu. Przed zmianą sprawdź zgodność szablonu i wtyczek na stagingu.
2. Aktywacja OPcache: OPcache przechowuje skompilowany kod bajtowy PHP w pamięci RAM, więc pliki nie są kompilowane przy każdym żądaniu. Sprawdź, czy opcache.enable=1 i czy przydzielono wystarczająco pamięci (np. opcache.memory_consumption=256).
3. Konfiguracja PHP-FPM: przy dużym ruchu dobierz liczbę procesów potomnych (pm.max_children) tak, aby serwer nie kolejkował żądań podczas skoków odwiedzin.

#Etap 2: Wdrożenie buforowania stron (Page Caching)

Dla użytkowników niezalogowanych WordPress powinien serwować gotowy HTML zamiast za każdym razem uruchamiać PHP i MySQL. Pełny przegląd warstw opisałem w przewodniku po strategiach cachowania.

• Wtyczki buforujące: WP Rocket, LiteSpeed Cache czy Cache Enabler zapisują statyczny HTML po pierwszej wizycie i serwują go kolejnym użytkownikom.
• Cache na poziomie serwera: Nginx FastCGI Cache lub moduł cache LiteSpeed obsługują żądanie, zanim w ogóle dotrze ono do PHP.
• Edge cache i CDN: usługi takie jak Cloudflare czy BunnyCDN serwują strony i pliki statyczne z serwerów najbliższych użytkownikowi.
• Cache przeglądarki: nagłówki wygasania mówią przeglądarce, jak długo trzymać obrazy, CSS i JS. Na Apache z modułem mod_expires:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Długi czas ma sens tylko wtedy, gdy nazwy plików zmieniają się przy każdej nowej wersji (np. przez parametr ver w adresie zasobu).

Do trwałego object cache najczęściej używa się wtyczki Redis Object Cache. Połączenie ustawiasz stałymi w wp-config.php (poniższe wartości są domyślne), a cache włączasz poleceniem wp redis enable:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );

#Etap 3: Czyszczenie i higiena bazy danych

1. Ograniczenie rewizji wpisów: dodaj do pliku wp-config.php:

   define( 'WP_POST_REVISIONS', 5 );

2. Czyszczenie wygasłych transientów: tymczasowe wpisy, które utraciły ważność, potrafią zalegać w bazie w dużych ilościach. Usuniesz je poleceniem WP-CLI:

   wp transient delete --expired

3. Optymalizacja tabel: okresowo uruchamiaj optymalizację tabel, aby zwolnić nieużywaną przestrzeń:

   wp db optimize

#Etap 4: Audyt wtyczek

1. Zmierz. Query Monitor pokaże, ile zapytań i czasu zużywa każda wtyczka oraz jakie pliki CSS i JS dołącza.
2. Wskaż najcięższe. Posortuj komponenty według liczby zapytań i czasu wykonania. Zacznij od tych, które dokładają zapytania na każdej podstronie.
3. Oceń zamienniki. Dla każdej ciężkiej wtyczki sprawdź lżejszą alternatywę albo to, czy jej funkcję da się zastąpić kilkoma linijkami kodu.
4. Usuń zbędne. Nieużywane slidery, wtyczki statystyk dublujące analitykę, dodatki społecznościowe powielające funkcje szablonu.
5. Ładuj warunkowo. Wtyczkę potrzebną na jednej podstronie, na przykład formularz kontaktowy Contact Form 7, ogranicz do tej podstrony:

function wppoland_ogranicz_cf7() {
    if ( ! is_page( 'kontakt' ) ) {
        wp_dequeue_style( 'contact-form-7' );
        wp_dequeue_script( 'contact-form-7' );
    }
}
add_action( 'wp_enqueue_scripts', 'wppoland_ogranicz_cf7', 99 );

#Etap 5: Odchudzenie frontendu

1. Nowoczesne formaty graficzne (WebP / AVIF): konwertuj zdjęcia do formatów, które przy tej samej jakości ważą mniej niż JPEG czy PNG.
2. Natywne leniwe ładowanie: obrazy poza pierwszym ekranem powinny mieć loading="lazy", a obraz LCP w nagłówku fetchpriority="high" i żadnego opóźnienia.
3. Odroczenie JavaScriptu: stosuj defer lub async dla skryptów, które nie biorą udziału w budowie pierwszego widoku. Szczegóły w poradniku o usuwaniu blokady renderowania przez JavaScript i CSS.
4. Lokalne czcionki: pobierz pliki WOFF2 na własny serwer zamiast ładować je z Google Fonts, co eliminuje dodatkowe zapytanie DNS i negocjację TLS.

#Co optymalizować najpierw w WordPressie

Nie każda poprawka daje ten sam zysk. Kolejność od największego wpływu:

1. Page cache. Jeśli strona go nie ma, to zwykle największa pojedyncza poprawa, bo anonimowe żądania przestają uruchamiać PHP i MySQL.
2. Obrazy. Właściwe wymiary, format i kompresja zmniejszają wagę strony i przyspieszają LCP.
3. Blokujące CSS i JS. Odroczenie skryptów i krytyczny CSS poprawiają FCP i LCP.
4. Wtyczki. Każda usunięta wtyczka to mniej zapytań, plików i kodu PHP.
5. Object cache (Redis lub Memcached). Szczególnie dla WooCommerce i stron z treścią personalizowaną, których nie da się w całości zbuforować.
6. CDN. Krótsza droga do odległych użytkowników i mniejsze obciążenie serwera głównego.
7. Aktualizacja PHP. Zmiana konfiguracji bez zmian w kodzie, o ile szablon i wtyczki są zgodne.

#Co zrobić, gdy WordPress jest wolny

Optymalizacja wydajności WordPressa nie jest jednorazowym zabiegiem. Zacznij od pomiaru, rozdziel problem na serwer i frontend, a potem usuwaj wąskie gardła w kolejności ich wpływu. Dopiero gdy TTFB pozostaje wysoki po uporządkowaniu kodu, bazy i buforowania, zmiana hostingu ma uzasadnienie.

Zmagasz się z powolnym działaniem sklepu internetowego lub chcesz przygotować serwis na intensywny ruch kampanijny? Skorzystaj z mojej usługi przyspieszania stron WordPress lub skonsultuj się z WordPress developerem, który przeprowadzi audyt Twojego kodu.