Wydajność witryny WordPress to znacznie więcej niż suche parametry techniczne czy czasy ładowania liczone w milisekundach. Współczesna optymalizacja tworzy złożony ekosystem, w którym infrastruktura hostingu, konfiguracja serwera, mechanizmy dostarczania treści i specyficzne wdrożenia WordPressa łączą się, by w ułamku sekundy tworzyć doświadczenia użytkownika, które albo angażują, albo frustrują. Badania konsekwentnie pokazują, że wydajność strony bezpośrednio przekłada się na wyniki biznesowe: nawet 1 sekunda opóźnienia może oznaczać spadek konwersji o ok. 7%. BBC odnotowało, że 10% użytkowników porzuca witrynę z każdą kolejną sekundą ładowania, a współczynniki konwersji mogą maleć nawet o 20% na każdą dodatkową sekundę. Wniosek jest prosty: optymalizacja to nie tylko kwestia techniczna, lecz krytyczny imperatyw biznesowy w konkurencyjnej gospodarce cyfrowej. Wyzwanie polega nie tyle na zrozumieniu, że optymalizacja jest ważna, ile na uchwyceniu jej wielowymiarowości i identyfikacji czynników, które odróżniają strony naprawdę szybkie od tych jedynie „wystarczająco działających”.
Fundamentalna zależność między infrastrukturą hostingową a wydajnością witryny
Wybór infrastruktury hostingowej tworzy fundament, na którym wszystkie późniejsze działania optymalizacyjne albo rozkwitają, albo upadają. Często błędnie zakłada się, że jeśli strona działa wolno, winny jest wyłącznie hosting. Choć hosting ma bezsprzeczny wpływ na szybkość, zależność ta bywa znacznie bardziej zniuansowana. Dobrym wskaźnikiem jakości hostingu jest TTFB (Time to First Byte), który mierzy, jak szybko serwer odpowiada na żądanie. Warto go regularnie testować i sprawdzać, czy środowisko (np. najnowsza wersja PHP) działa efektywnie. Jeśli jednak źródłem problemów są nieoptymalne skrypty, nadmiar wtyczek, „ciężkie” page buildery lub przestarzały, nieutrzymany kod, sama zmiana hostingu nie rozwiąże problemu — to serwis wymaga optymalizacji.
Umiejętność odróżnienia problemów hostingu od kłopotów na poziomie aplikacji jest kluczowa i pozwala uniknąć niepotrzebnych wydatków. Wysokiej jakości usługi hostingowe oferują szybkie procesory, SSD/NVMe, optymalną konfigurację i potrafią znacząco przyspieszyć wiele serwisów. NVMe może odczytywać i zapisywać dane wielokrotnie szybciej niż tradycyjne HDD — różnica bywa tak duża, jak między starym dyskiem a współczesnym SSD. Liczba i taktowanie procesorów również mają znaczenie. Gdzie to możliwe, warto rozdzielać usługi (np. HTTP i MySQL) na kilka serwerów/VPS, najlepiej w tym samym regionie. Na hostingu współdzielonym rozważ upgrade planu z wyższymi limitami (np. I/O, IOPS, NPROC, liczba procesów), jeśli obecne są wyczerpywane.
W praktyce, przy ocenie hostingu dla WordPressa, zwróć uwagę na:
- TTFB – realny czas pierwszego bajtu dla kluczowych podstron, mierzony z lokalizacji Twoich użytkowników;
- PHP – aktualną, wspieraną i szybką wersję oraz aktywny OPcache;
- NVMe/SSD – szybkie dyski i odpowiednią liczbę rdzeni/taktowanie CPU;
- limity planu – I/O, IOPS, pamięć, NPROC i procesy PHP (FPM), które nie dławią aplikacji.
Potencjał środowiska hostingu to nie tylko sprzęt, lecz także oprogramowanie serwera i jego konfiguracja. Wydajność można podnosić m.in. przez cache po stronie serwera i nagłówki cache. Warto szukać optymalizacji pod konkretny serwer (np. „Apache optimization”) i rozważyć rozwiązania premium o wyższej wydajności. Apache można stroić (np. z pomocą Memcached), ale w środowiskach WordPressa przewagę często daje LiteSpeed Web Server, który jest „drop-in replacement” dla Apache (czyta jego konfigurację, obsługuje .htaccess i mod_rewrite). Przejście na LiteSpeed potrafi podwoić przepustowość i wyeliminować potrzebę zewnętrznych warstw cache przy migracji bez przestojów.
Lokalizacja serwera to kolejny niedoceniany wymiar. Fizyczna odległość od użytkownika wpływa na latencję i szybkość dostarczania treści. Dla serwisów lokalnych wybierz serwer blisko odbiorców. Dla globalnych nie wystarczy geograficzna bliskość — potrzebny jest CDN. Klasyczne CDN-y keszują pliki statyczne (obrazy, CSS, JS). Rozwiązania zaawansowane, jak QUIC.cloud, potrafią inteligentnie keszować dynamiczną treść WordPressa, integrując cache na poziomie serwera i analizując zależności, by z dużą precyzją serwować treści z globalnej sieci. QUIC jako protokół transferu skraca czas transmisji dla wszystkich użytkowników, niezależnie od ich lokalizacji.
Optymalizacja backendu i konfiguracja infrastruktury
Backend WordPressa obejmuje wiele elementów wymagających właściwej konfiguracji i regularnej konserwacji. Kluczową, a często zaniedbywaną dźwignią jest optymalizacja PHP. Akceleratory (np. OPcache, historycznie APC) znacząco przyspieszają wykonywanie kodu PHP. Część wtyczek cache współpracuje z Memcached czy systemami opcode, tworząc synergię między warstwą aplikacyjną i serwerową. Nowsze wersje PHP zwykle są szybsze, więc aktualizacja często daje wymierny zysk. Testy na WordPress 6.5.5 (motyw Twenty Twenty-Four, bez wtyczek) na backendzie 6 vCPU i 16 GB RAM pokazały, że dobór wersji PHP ma duże znaczenie.
Poniższe zestawienie ilustruje różnice średnich i maksymalnych czasów przetwarzania dla wybranych wersji PHP:
Wersja PHP 7.4
- Średni czas: 68,6 ms
- Maksymalny czas: 91,1 ms
Wersja PHP 8.0
- Średni czas: 51,1 ms
- Maksymalny czas: 70,4 ms
Wersja PHP 8.1
- Średni czas: 71,3 ms
- Maksymalny czas: 135 ms
Wersja PHP 8.2
- Średni czas: 67,2 ms
- Maksymalny czas: 93,3 ms
Wniosek: przejście z linii 7.x na 8.0 najczęściej daje duży zysk, ale kolejne wersje wymagają testów kompatybilności i wydajności na danej konfiguracji. Pamiętaj, że wyniki zależą od sprzętu i realnych konfiguracji (wiele wtyczek, motywy custom), dlatego testuj przed aktualizacją.
Optymalizacja bazy na poziomie serwera to kolejny wymiar. MySQL/MariaDB potrafią zyskać wiele na zmianie kilku kluczowych parametrów. Domyślnym silnikiem jest InnoDB — upewnij się, że Twoje tabele go używają. InnoDB można szeroko stroić (poszukaj: „mysql innodb performance”, „innodb optimization”). Dla zabytkowych instalacji z MyISAM rozważ migrację do InnoDB („mysql convert myisam to innodb”), by poprawić szybkość zapytań, transakcje i współbieżność. Dobór silnika i konfiguracji to fundament wydajności zapytań.
Dla administracji bazą zacznij od trzech praktyk, które niemal zawsze przynoszą efekty:
- upewnij się, że wszystkie tabele używają silnika InnoDB,
- zastosuj podstawowe strojenie (rozmiar innodb_buffer_pool, logi, flush, cache),
- zmigruj z MyISAM do InnoDB tam, gdzie to możliwe.
Cache obiektów to zaawansowana technika, która zmniejsza obciążenie bazy przez przechowywanie wyników złożonych zapytań w pamięci RAM. Najpopularniejsze są Redis i Memcached. Oba działają w pamięci (submilisekundowe opóźnienia), świetnie skalują się w rozproszonych środowiskach, ale różnią się funkcjonalnością. Redis oferuje złożone struktury danych i trwałość (persistence), dzięki czemu cache może przetrwać restart — Memcached tego nie ma. Wybór zależy od potrzeb: Redis dla rozbudowanych zastosowań i wysokiej dostępności, Memcached dla prostszego cache i mniejszych serwisów. Uwaga: nie każda witryna skorzysta. Jeśli aplikacja używa niewielu obiektów, narzut może przeważyć korzyści. Gdy obiektów są setki, zyski bywają ogromne. Zawsze testuj na swojej konfiguracji.
Aby szybko porównać Redis i Memcached, przeanalizuj kluczowe różnice:
Redis oferuje następujące cechy:
- Trwałość danych: Tak (obsługuje RDB/AOF)
- Struktury danych: klucze, listy, sety, hash, sorted set
- Skalowanie: klaster, replikacja
- Opóźnienia: bardzo niskie
Memcached charakteryzuje się:
- Trwałość danych: Nie
- Struktury danych: klucz–wartość
- Skalowanie: sharding po stronie klienta
- Opóźnienia: bardzo niskie
Optymalizacja warstwy aplikacji WordPress
Warstwa aplikacji to praktyki wpływające na przetwarzanie żądań, generowanie stron i serwowanie treści. Najczęstszą barierą są wtyczki. Pierwszy krok: usuń zbędne wtyczki, a te konieczne aktualizuj. Wyłączaj selektywnie i mierz wpływ na wydajność. Jeśli pojedyncza wtyczka mocno spowalnia, sprawdź jej dokumentację, wsparcie i alternatywy. Nie chodzi tylko o liczbę, lecz o jakość kodu. Lepiej mieć mniej wtyczek o szerszym zakresie, niż wiele drobnych z własnym narzutem.
Trzy praktyki, które natychmiast poprawiają kondycję warstwy aplikacji:
- redukuj liczbę wtyczek i eliminuj duplikaty funkcjonalności,
- aktualizuj krytyczne komponenty (motyw, wtyczki, WordPress Core) po testach na stagingu,
- mierz wpływ zmian narzędziami Query Monitor i New Relic (APM).
Znaczenie ma też dobór motywów i page builderów. Często optymalizacja nie była priorytetem podczas tworzenia strony — wtedy dobre praktyki pozwalają dużo naprawić, ale optymalizacja WordPressa to proces ciągły. Wybieraj lekkie motywy i analizuj wtyczki narzędziami takimi jak Query Monitor czy WP Hive. Lekkie motywy to nie tylko mniejszy rozmiar, lecz także architektura i praktyki kodowania, które minimalizują zużycie zasobów i skracają renderowanie.
Oto polecane, lekkie motywy i ich mocne strony:
- Astra – szybka, wszechstronna i dobrze współpracuje z popularnymi builderami;
- GeneratePress – modułowa architektura i wyjątkowo mały rozmiar pakietu;
- Neve – domyślne praktyki zgodne z Core Web Vitals;
- Blocksy – dynamiczne ładowanie zasobów i granularna kontrola skryptów;
- OceanWP – elastyczna konfiguracja i szeroka baza gotowych szablonów.
Zaawansowana optymalizacja zapytań to domena deweloperów. Kluczowa jest klasa WP_Query, której parametry należy dobierać świadomie. Prawidłowe parametry potrafią radykalnie odciążyć bazę. Najważniejsze ustawienia i kiedy je stosować:
- fields=ids – gdy potrzebujesz tylko identyfikatorów, bez pełnych obiektów;
- no_found_rows=true – gdy nie potrzebujesz paginacji/łącznej liczby wyników (omija SQL_CALC_FOUND_ROWS);
- update_post_meta_cache=false – gdy nie korzystasz z metadanych postów w pętli;
- update_post_term_cache=false – gdy taksonomie nie są potrzebne dla wyników;
- include_children=false – aby ograniczyć zakres w kategoriach/terminach;
- post_status=publish – by pominąć wersje robocze i śmieci;
- ignore_sticky_posts=true – gdy kolejność nie zależy od przyklejonych postów.
Opracowanie: https://hostingwordpress.pl/jak-przyspieszyc-wordpressa/
Strategie utrzymania i optymalizacji bazy danych
Optymalizacja bazy WordPressa jest podstawowa, a często pomijana. Każdy wpis może mieć wiele rewizji, które rosną w bazie i spowalniają działanie. Wyczyść stare wersje (np. pluginem Optimize Database after Deleting Revisions) i inne tabele. Regularne czyszczenie usuwa balast i przyspiesza stronę. Celuj w trzy obszary: redukcję rozmiaru bazy (zbędne wpisy), indeksowanie mniejszej ilości danych na czyszczonych tabelach oraz przebudowę indeksów. To poprawi wydajność i obniży obciążenie serwera.
Możesz to zrobić ręcznie w phpMyAdmin (cPanel → phpMyAdmin → zakładka struktury → zaznacz tabele → „optimize table”), albo automatycznie przy użyciu wtyczek. WP Rocket (oprócz cache) jednym kliknięciem optymalizuje bazę i automatyzuje ~80% dobrych praktyk wydajności. Advanced Database Cleaner specjalizuje się w czyszczeniu osieroconych rekordów (stare rewizje, spam itp.). WP-Optimize łączy czyszczenie bazy, kompresję obrazów i cache stron, pokazując statystyki i potencjalne oszczędności.
Dla porządku w bazie i mniejszego TTFB, skup się na poniższych aspektach:
- transients – usuwaj wygasłe, które zalegają w wp_options;
- zadania cron – czyść osierocone wpisy (np. _wp_session) i harmonogramy;
- indeksy – przebudowuj/ dodawaj rozsądnie do dużych tabel po analizie zapytań;
- autoloaded data – kontroluj rozmiar autoload=yes (powyżej 1 MB konieczne działania).
Autoloaded data w wp_options ładuje się na każdej stronie (ustawienia aktywnych wtyczek, motywów, widgetów, dane cache). Gdy rozmiar autoload przekracza 1 MB (a już zwłaszcza 5 MB), pora na porządki. Problemem są m.in. wtyczki ładujące dane globalnie zamiast selektywnie, śmieci zostawione po odinstalowanych wtyczkach/motywach i nadmierne użycie autoload przez słabo napisane rozszerzenia.
Mechanizmy cache i strategie wdrożenia
Cache to jedna z najskuteczniejszych i najprostszych technik przyspieszających WordPressa. Cache stron przechowuje gotowe HTML, dzięki czemu kolejne żądania nie wywołują PHP ani bazy. Efekt: drastycznie niższe obciążenie serwera i szybsze ładowanie, zwłaszcza przy ruchu na te same podstrony.
Najpopularniejsze wtyczki cache i ich wyróżniki:
- WP Rocket – prosty interfejs, crawler budujący cache, automatyczne rekomendacje (cache stron, cache przeglądarki, GZIP, lazy load, optymalizacje CSS/JS, czyszczenie bazy), zgodność z WooCommerce;
- LiteSpeed Cache – błyszczy z LiteSpeed Web Server, serwerowy cache, QUIC.cloud CDN, Guest Mode, ESI dla fragmentów dynamicznych, precyzyjne TTL, UCSS, LQIP, WebP;
- W3 Total Cache – rozbudowane, darmowe narzędzie (przewodnik konfiguracji Redis/Memcached/dysk, minifikacja z defer/async, lazy load, kompresja obrazów), choć część funkcji premium dostępna jest w innych rozwiązaniach.
Cache przeglądarki uzupełnia cache serwerowy — przeglądarka przechowuje zasoby lokalnie, co przyspiesza kolejne wizyty. Włączaj stopniowo minifikację, opóźnianie skryptów i optymalizację fontów, każdorazowo testując działanie. Połączenie cache stron + cache przeglądarki + cache obiektów minimalizuje zapytania do bazy i wykonanie PHP.
Optymalizacja treści i usprawnienie dostarczania
Obrazy często stanowią największą część wagi strony — dlatego ich optymalizacja daje szybkie i duże korzyści. Zacznij od kompresji przed uploadem (lub automatycznie w WordPressie). Lazy loading doładowuje obraz dopiero, gdy użytkownik do niego dojdzie, co znacznie przyspiesza start renderowania.
Praktyczne wtyczki i usługi do optymalizacji obrazów:
- Smush – bezstratna kompresja, lazy load i szybka konfiguracja;
- ShortPixel – tryby lossy/glossy/lossless i automatyczna konwersja do WebP;
- Imagify – obsługa wielu formatów, lazy load, smart crop i znaki wodne;
- EWWW Image Optimizer – lokalna lub chmurowa kompresja i generowanie WebP/AVIF;
- Optimole – serwowanie obrazów dopasowanych do urządzenia z CDN i lazy load.
Imagify w testach potrafił zmniejszyć plik 657 KB do 256 KB (oszczędność 61%), skrócić czas z 2,2 s do 1,9 s i zredukować liczbę żądań. ShortPixel oferuje tryby lossy/glossy/lossless. Optimole serwuje mniejsze obrazy dopasowane do urządzenia, z lazy load i znakami wodnymi; wyniki zbliżone do Imagify.
Minifikacja CSS i JS usuwa zbędne znaki (spacje, komentarze), zmniejszając pliki bez utraty funkcjonalności. Popularny jest Autoptimize. PageSpeed Insights wskaże zasoby wymagające minifikacji. Można użyć narzędzi online (np. Toptal JS Minifier, CleanCSS), narzędzi developerskich (UglifyJS) lub wtyczek.
Najwygodniejsze ścieżki minifikacji, zależnie od środowiska:
- WP Rocket – włącz minifikację w File Optimization i testuj zgodność,
- SiteGround Optimizer – minifikacja dla klientów SG,
- Autoptimize – bezpłatnie łączy i minifikuje JS/CSS/HTML,
- Cloudflare – minifikuje pliki na krawędzi w ramach CDN.
CDN rozprowadza treści geograficznie, zmniejszając opóźnienia i TTFB. Przykłady: Cloudflare, Fastly, Amazon CloudFront, QUIC.cloud. CDN działa jak rozszerzone cache, serwując zasoby z węzłów najbliższych użytkownikowi.
Dla zobrazowania wpływu CDN na czasy odpowiedzi, porównaj wyniki przed i po wdrożeniu (test z punktu bliskiego POP):
Bez CDN:
- Czas ładowania: ~1,45 s
- TTFB: ~136 ms
Z CDN:
- Czas ładowania: ~788 ms
- TTFB: ~37 ms
Zaawansowany monitoring i optymalizacja Core Web Vitals
Ocena wydajności to dziś nie tylko czas ładowania, ale także Core Web Vitals — metryki UX uwzględniane w rankingach Google. To najważniejsze wskaźniki jakości doświadczenia użytkownika. Obejmują trzy kluczowe obszary:
- LCP (Largest Contentful Paint) – szybkość renderu największego elementu na stronie;
- CLS (Cumulative Layout Shift) – stabilność wizualna i brak nieoczekiwanych przesunięć;
- INP (Interaction to Next Paint) – responsywność interfejsu po interakcjach użytkownika.
Rekomendowane działania pod każdą metrykę:
- LCP – skróć TTFB, zoptymalizuj obrazy (formaty WebP/AVIF), usuń render‑blocking zasoby i stosuj wydajny cache;
- CLS – rezerwuj miejsce na obrazy/wideo, nie wstawiaj treści nad już wyrenderowane i używaj font-display z właściwymi fallbackami;
- INP – ogranicz czas wykonywania JavaScript, pracę w głównym wątku i optymalizuj reakcje UI (debounce/throttle).
Wybór szybkiego hostingu poprawia responsywność serwera i oceny LCP. Optymalizacja obrazów wpływa zarówno na LCP, jak i INP. Wtyczki często ładują CSS/JS globalnie — ogranicz je do potrzebnych podstron (np. Asset CleanUp, Perfmatters). Page buildery nierzadko oferują wbudowane sterowanie zasobami. Monitoruj wyniki w PageSpeed Insights i Google Search Console (zakładka Core Web Vitals), by śledzić realne doświadczenia użytkowników.
Kompresja GZIP i optymalizacja transferu
GZIP to podstawowa, często pomijana technika, która zmniejsza rozmiary transferu bez utraty jakości. Kompresuje HTML, CSS, JS (najlepsze efekty na zasobach tekstowych) i opiera się na algorytmie DEFLATE (LZ77 + kodowanie Huffmana). Typowe oszczędności: 70% dla małych plików, a przy większych nawet do 90%. Obrazy/wideo (już skompresowane) nie zyskają na GZIP, a czasem urosną. Siła GZIP to świetna relacja szybkości kompresji/dekompresji do uzyskiwanych rozmiarów, idealna dla protokołów web. HTTP/1.1 standardowo wspiera GZIP.
Wdrożenie: najprościej przez wtyczki. WP Rocket automatycznie włącza GZIP na Apache. Darmową alternatywą jest WP Super Cache (opcje: „Compress pages…”). Autoptimize koncentruje się na minifikacji, ale współgra z GZIP. Manualnie: na Apache dodaj reguły do .htaccess (mod_deflate), na Nginx skonfiguruj w nginx.conf (poziomy kompresji, typy MIME). Zweryfikuj działanie testerem GZIP — potwierdzi kompresję i realne korzyści.
Nowe technologie optymalizacji i co dalej
Nowe standardy ciągle zmieniają krajobraz wydajności. HTTP/3 i QUIC skracają zestawianie połączeń i lepiej radzą sobie z utratą pakietów (brak blokowania „head-of-line” jak w TCP). LiteSpeed Web Server oferuje produkcyjną implementację tych protokołów. Korzyści są transparentne dla aplikacji WordPress — wymagana jest jedynie obsługa po stronie serwera.
Nowoczesne formaty obrazów: WebP (zwykle 25–35% mniejsze niż JPEG przy tej samej jakości) i AVIF (często jeszcze lepsza kompresja zdjęć, ale większe wymagania i wciąż rosnące wsparcie przeglądarek). WordPress ma natywne wsparcie WebP i potrafi serwować najlepszy format obsługiwany przez przeglądarkę. Wtyczki coraz częściej automatycznie konwertują do WebP/AVIF i serwują wariant per-przeglądarka.
Edge computing przesuwa obliczenia bliżej użytkownika (np. Cloudflare Workers, AWS Lambda@Edge): cache HTML dla zalogowanych z personalizacją na krawędzi, generowanie odpowiedzi API bez dotykania origin, A/B testy bez obciążania serwera źródłowego. To duża szansa dla wydajności WordPressa, choć wymaga dojrzałych wzorców wdrożeniowych.
Budżety wydajności i ciągły monitoring zapobiegają regresjom. Ustal limity (waga strony, rozmiar bundli JS, progi ładowania), testuj automatycznie na dev/stage, monitoruj RUM i dane w Search Console (CWV). Połączenie testów syntetycznych i rzeczywistych danych użytkowników daje pełny obraz i wspiera decyzje.
Bezpieczeństwo a optymalizacja wydajności
Przyspieszając, nie zapominaj o bezpieczeństwie. Cache może ujawnić dane prywatne, jeśli skonfigurujesz go błędnie (np. strony koszyka/kasy w WooCommerce nie mogą być publicznie keszowane). Dobre wtyczki (np. WP Rocket) wykluczają wrażliwe podstrony automatycznie, ale przy implementacjach custom wszystko trzeba zweryfikować.
Najważniejsze dobre praktyki łączące bezpieczeństwo i wydajność:
- CDN + HTTPS – używaj pełnego SSL/TLS end‑to‑end (bez „elastycznego” połączenia do origin),
- DDoS/WAF – aktywuj ochronę (np. QUIC.cloud, reguły w LiteSpeed Web Server),
- higiena wtyczek – instaluj z zaufanych źródeł, ogranicz liczbę i aktualizuj po testach,
- backup – pełna kopia danych przed pracą na bazie (np. snapshoty co godzinę w Pressable),
- dostępy – silne hasła i ograniczony dostęp do phpMyAdmin/SSH.
Kompleksowa mapa wdrożenia optymalizacji
Skuteczne wdrożenie to podejście systemowe i priorytetyzacja zadań wg wpływu i złożoności. Zacznij od audytu i ustalenia punktu odniesienia: użyj PageSpeed Insights, GTmetrix, zmierz TTFB i Core Web Vitals. Przejrzyj autoloaded data (jeśli >1 MB, działaj), zrób przegląd wtyczek (usuń zbędne), oceń motyw (czy jest lekki), sprawdź hosting (SSD/NVMe, aktualny PHP, HTTP/2/HTTP/3).
Lista „szybkich wygranych”, które dają natychmiastowy efekt przy niskiej złożoności:
- włącz cache stron (WP Rocket/LiteSpeed Cache/W3TC),
- skompresuj obrazy i włącz lazy load,
- uruchom minifikację CSS/JS i kompresję GZIP,
- zaktualizuj do szybszej wersji PHP po testach zgodności,
- ogranicz zbędne JS/CSS na stronach i ładuj je selektywnie,
- włącz CDN dla globalnej publiczności,
- wyczyść bazę danych (rewizje, transients, osierocone rekordy).
Każdą zmianę mierz i testuj, a następnie iteruj, aż osiągniesz założone cele wydajności i UX.
Więcej: https://hostingserwerow.pl/hosting-wordpress/