Jak przyspieszyć WordPress: cache, CDN, obrazy i optymalizacja bazy danych

Dlaczego WordPress działa wolno – anatomia problemu

Jak użytkownik odczuwa wolny WordPress

Wolny WordPress to nie tylko niski wynik w PageSpeed, ale przede wszystkim odczucie użytkownika, że strona „mieli” i nie reaguje. Przekłada się to na wyższy współczynnik odrzuceń, mniejszą liczbę zapytań ofertowych lub porzucone koszyki.

Najczęstsze objawy:

• długi TTFB (Time To First Byte) – po kliknięciu linku przez 1–3 sekundy nic się nie dzieje, a pasek ładowania w przeglądarce stoi w miejscu,
• powolne przejścia między podstronami – każda zmiana widoku powoduje krótkie „zawiechy”,
• strona pojawia się dopiero po kilku sekundach, mimo że łącze internetowe jest szybkie,
• panel administratora WordPress („Kokpit”) reaguje ociężale, zapisywanie wpisów trwa zbyt długo.

Użytkownik rzadko rozróżnia, czy problem leży po stronie serwera, motywu czy obrazów. Po prostu ma poczucie, że „ta strona jest wolna” i szuka innej.

Źródła problemów z wydajnością WordPress

WordPress sam w sobie nie jest ani wyjątkowo szybki, ani wyjątkowo wolny. O wszystkim decyduje konfiguracja i otoczenie techniczne. Przyspieszanie WordPressa zaczyna się od identyfikacji najsłabszego ogniwa.

Najczęstsze źródła spowolnień:

• Hosting – przeładowany shared hosting, wolne dyski, zbyt niskie limity CPU/RAM, brak cache po stronie serwera.
• Motyw – przeładowane „page buildery”, setki opcji, dziesiątki skryptów JS i CSS ładowanych na każdej podstronie.
• Wtyczki – zbyt duża liczba wtyczek, duplikujące się funkcje, wtyczki źle napisane lub przestarzałe.
• Media – obrazy w pełnej rozdzielczości z aparatu, brak kompresji, brak lazy loading, niepotrzebne wideo z autoodtwarzaniem.
• Baza danych – tysiące wersji wpisów, śmieci po odinstalowanych wtyczkach, nieoptymalne zapytania.
• Zewnętrzne skrypty – czaty, popupy, widgety social media, kilka instancji Google Analytics, zewnętrzne fonty, mapy.

W praktyce wolny WordPress to zwykle kombinacja przynajmniej dwóch–trzech elementów, a rzadko pojedyncza przyczyna.

Front‑end a back‑end – gdzie faktycznie tracisz czas

Wydajność WordPressa opiera się na dwóch obszarach: back‑end (serwer, PHP, baza danych) i front‑end (HTML, CSS, JS, obrazy w przeglądarce). Problemy na każdym z nich odczuwane są inaczej.

Back‑end odpowiada za to, jak szybko serwer „złoży” stronę i wyśle pierwszy bajt. Jeśli TTFB jest wysoki, potrzebne są działania typu: lepszy hosting, cache stron, optymalizacja bazy, aktualizacja PHP, ograniczenie ciężkich zapytań (np. zbyt zaawansowane wyszukiwarki, filtry WooCommerce).

Front‑end decyduje o tym, jak szybko użytkownik widzi treść i czy strona jest interaktywna. Tu kluczowe są: optymalizacja obrazów, ograniczenie skryptów, opóźnianie ładowania JS, CSS‑critical, lazy load obrazów i iframe, CDN.

Typowy scenariusz: na szybkim serwerze TTFB jest niski, ale strona dalej ładuje się 4–6 sekund. Przyczyna leży wtedy w ciężkich plikach front‑end, a nie w WordPressie jako takim.

Co mierzą PageSpeed Insights, GTmetrix i WebPageTest

Narzędzia do testowania prędkości nie są celem samym w sobie, tylko wskaźnikiem kierunku. Trzeba rozumieć, co faktycznie mierzą.

• PageSpeed Insights – używa Lighthouse, pokazuje Core Web Vitals (LCP, FID/INP, CLS), ocenia strukturę strony, kolejność ładowania, ciężar zasobów. Wynik w punktach bywa mylący, ważniejsze są konkretne metryki czasowe i sugestie.
• GTmetrix – łączy Lighthouse i Web Vitals z czytelnym podglądem waterfall (kolejność i czas ładowania zasobów). Pozwala wybrać lokalizację testu i przeglądarkę.
• WebPageTest – narzędzie dla bardziej technicznych osób. Daje szczegółowy waterfall, pomiary dla pierwszego i kolejnych ładowań, wizualizację filmu z ładowania strony.

Korzystając z kilku narzędzi, łatwiej odróżnić realny problem z czasem odpowiedzi serwera od lokalnych problemów z przeglądarką lub pojedynczym skryptem.

Krótki przykład z praktyki

Sklep na WordPress + WooCommerce, kilkaset produktów, tani hostelowy shared hosting. Czas ładowania strony głównej: około 5–7 sekund, wysoki TTFB, częste błędy 503 przy większym ruchu.

Po migracji na hosting zoptymalizowany pod WordPress, z włączonym cache po stronie serwera (np. LiteSpeed) i podstawowym cache stron w wtyczce, czas ładowania dla nowych użytkowników spadł do ok. 1–1,5 sekundy. Większość poprawy dała zmiana hostingu i page cache, dopiero kolejne optymalizacje (obrazy, ograniczenie wtyczek) poprawiły wynik w Lighthouse.

Punkt wyjścia – jak zmierzyć obecną szybkość WordPressa

Najważniejsze wskaźniki prędkości

Przed optymalizacją WordPressa trzeba wiedzieć, od czego się startuje. Kluczowe metryki:

• TTFB (Time To First Byte) – ile czasu mija od wysłania żądania do otrzymania pierwszego bajtu. Pokazuje wydajność serwera i back‑endu.
• LCP (Largest Contentful Paint) – kiedy największy element widoczny w oknie przeglądarki jest wyrenderowany (np. duże zdjęcie, nagłówek). Pokazuje, po jakim czasie użytkownik widzi główną treść.
• FID/INP – czas reakcji strony na pierwszą interakcję (kliknięcie, przewinięcie). Ważne przy ciężkich skryptach JS.
• CLS (Cumulative Layout Shift) – stabilność układu. Gdy elementy „skaczą” podczas ładowania, wskaźnik rośnie.
• Czas pełnego załadowania – kiedy wszystkie zasoby są pobrane. Mniej istotne niż LCP i TTI, ale przydatne porównawczo.
• Liczba żądań HTTP – ile plików (CSS, JS, obrazy, fonty, XHR) jest wczytywanych. Im mniej, tym łatwiej przyspieszyć stronę.

Narzędzia do testowania szybkości WordPressa

Do analizy wydajności WordPressa przydaje się kilka różnych narzędzi – każde pokazuje nieco inne dane.

• PageSpeed Insights – wynik mobilny i desktop, realne dane użytkowników (jeśli jest ruch), propozycje optymalizacji. Dobre do oceny Core Web Vitals.
• GTmetrix – czytelny raport i waterfall, proste do zrozumienia wykresy. Pozwala na wybór lokalizacji testu (np. Europa, USA).
• WebPageTest – szczegółowe testy z wieloma próbami, pomiary dla pierwszego i kolejnych wejść, nagranie wideo z ładowania strony.
• DevTools w przeglądarce – zakładka „Network” w Chrome/Firefox pozwala zobaczyć TTFB, rozmiary plików, kolejność ładowania zasobów.

Korzystanie wyłącznie z jednego narzędzia może prowadzić do błędnych wniosków. Lepsza praktyka to porównanie 2–3 raportów.

Jak poprawnie testować wydajność strony

Źle wykonane testy szybkości dają mylne wyniki. Kilka prostych zasad pozwala tego uniknąć.

• Testuj bez logowania do WordPressa (sesja administratora wyłącza cache stron).
• Używaj trybu incognito w przeglądarce, bez rozszerzeń i adblocków.
• Wykonaj kilka powtórzeń testu dla tej samej podstrony i patrz na średnią.
• Testuj kluczowe podstrony: stronę główną, wpis blogowy, kartę produktu, koszyk/checkout (jeśli to sklep).
• Sprawdź działanie z różnych lokalizacji (np. Europa vs USA), szczególnie jeśli masz ruch międzynarodowy.

Dzięki temu wiesz, jak zachowuje się WordPress dla typowego użytkownika, a nie dla zalogowanego administratora na lokalnej sieci.

Jak rozróżnić problemy globalne od lokalnych

Jeżeli wszystkie podstrony ładują się wolno i TTFB jest wysoki, problem jest globalny: serwer, PHP, baza danych, brak cache, źle napisany motyw lub kluczowa wtyczka.

Gdy jedna, konkretna podstrona jest wyraźnie cięższa (np. landing z wieloma zdjęciami), a reszta działa przyzwoicie, źródło kłopotu leży w:

• zbyt dużych obrazach,
• wideo w tle lub wielu osadzonych iframe,
• dodatkowych wtyczkach aktywnych tylko na tej stronie (np. z buildera, suwaka, formularza).

Dobrym nawykiem jest porównanie raportu dla strony głównej z raportem dla prostego wpisu tekstowego. Jeśli wpis ładuje się szybko, a strona główna nie – problemem jest jej zawartość, a nie cała instalacja WordPressa.

Tworzenie punktu odniesienia przed optymalizacją

Przed zmianami w konfiguracji cache, CDN czy bazy danych warto zapisać wyniki testów. Wystarczy prosty plik tekstowy lub arkusz, gdzie notujesz:

• adres testowanej podstrony,
• narzędzie testowe i lokalizację,
• TTFB, LCP, czas pełnego ładowania, liczbę żądań, wagę strony,
• datę i godzinę.

Po wdrożeniu zmian powtarzasz testy w tych samych warunkach i porównujesz. Tylko tak można rzetelnie ocenić, czy np. nowa wtyczka cache lub CDN realnie przyspieszyły WordPressa.

Fundament: hosting, PHP i podstawowa konfiguracja serwera

Shared hosting, VPS, managed WordPress, chmura – co wybrać

Najsprawniejsza konfiguracja cache i CDN nie nadrobi fatalnego hostingu. Wydajność serwera jest fundamentem, na którym stoi WordPress.

• Shared hosting – serwer współdzielony z innymi użytkownikami. Tani i prosty, ale obciążenie innych stron wpływa na twoją. Dobry na start dla małych, prostych stron.
• VPS – własny wirtualny serwer z gwarantowanymi zasobami. Wymaga administracji (Linux, konfiguracja www, bezpieczeństwo), ale daje znacznie większą kontrolę i wydajność.
• Managed WordPress – hosting zarządzany, gdzie dostawca optymalizuje serwer pod WordPressa, dba o cache, aktualizacje i backupy. Wyższa cena, ale mniej pracy technicznej.
• Chmura (np. AWS, GCP) – elastyczność i skalowanie, lecz wymagają wiedzy administracyjnej. Dobre dla dużych projektów, raczej nadmiarowe dla małych stron.

Dla większości małych i średnich stron biznesowych sensowny jest dobrej jakości shared lub managed WordPress. Dla sklepu WooCommerce z większym ruchem – wydajny managed lub VPS.

Dlaczego wersja PHP ma ogromne znaczenie

WordPress działa w PHP, dlatego wersja PHP bezpośrednio wpływa na szybkość wykonywania kodu. Nowe wersje PHP działają wielokrotnie szybciej od starych, a jednocześnie są bezpieczniejsze.

Przykładowo, przejście z PHP 7.4 na PHP 8.x w wielu przypadkach redukuje czas generowania strony o kilkadziesiąt procent. Dla użytkownika oznacza to niższy TTFB.

Jak sprawdzić wersję PHP:

• w kokpicie WordPress: Narzędzia → Stan witryny → Informacje,
• w panelu hostingu (często sekcja „PHP”),
• za pomocą pliku phpinfo() (dla bardziej technicznych).

Przed aktualizacją PHP wykonaj kopię zapasową i sprawdź kompatybilność motywu i wtyczek. W razie błędów możesz chwilowo wrócić do poprzedniej wersji.

Opcache, HTTP/2, HTTP/3, gzip i brotli

Na wydajność serwera wpływają także dodatkowe moduły i protokoły, które powinny być włączone po stronie hostingu.

• Opcache – moduł PHP przechowujący skompilowany kod w pamięci. Skraca czas wykonania skryptów WordPressa.
• HTTP/2 – nowszy protokół HTTP, który pozwala na równoległe ładowanie wielu plików przez jedno połączenie. Zmniejsza opóźnienia.
• HTTP/3 – jeszcze nowszy protokół oparty na QUIC, przydatny szczególnie na mobilnych i słabszych łączach.
• gzip / brotli – kompresja zasobów tekstowych (HTML, CSS, JS) po stronie serwera. Brotli zwykle daje lepszą kompresję niż gzip.

W większości dobrych hostingów opcje te są włączone domyślnie lub dostępne w panelu. Jeśli nie masz do nich dostępu, to poważny argument za zmianą dostawcy.

Lokalizacja serwera, DNS i czas odpowiedzi

Lokalizacja serwera i wpływ odległości na TTFB

Im dalej serwer od użytkownika, tym wyższy TTFB. Różnica między serwerem w Polsce a w USA przy tym samym hostingu potrafi być odczuwalna przy każdej wizycie.

Dla strony kierowanej głównie na Polskę i Europę środkową najlepszy będzie serwer w tym regionie. Przy ruchu globalnym lepiej postawić na infrastrukturę z dobrym peeringiem i uzupełnić ją CDN.

Jeśli masz już hosting, zmierz TTFB z różnych lokalizacji w WebPageTest. Gdy z jednego kontynentu wyniki są dobre, a z innego fatalne, łatwiej podjąć decyzję: zmiana lokalizacji serwera, nowy dostawca lub wdrożenie CDN.

DNS, czas propagacji i rekordy

Czas odpowiedzi DNS to pierwszy krok w podróży żądania. Słaby dostawca DNS potrafi dołożyć setki milisekund przed nawiązaniem połączenia z serwerem.

Dobrym rozwiązaniem jest użycie szybkiego zewnętrznego DNS, np. w ramach Cloudflare, AWS Route 53 czy innego dostawcy z globalnym anycastem. Zmiana DNS zwykle nie wymaga przenoszenia hostingu.

Przy zmianach DNS pilnuj czasu życia rekordów (TTL). Zbyt wysoki TTL utrudnia płynne przenosiny, zbyt niski może generować zbędne obciążenie przy ogromnym ruchu, ale dla większości stron ustawienie rzędu 300–1800 sekund jest rozsądnym kompromisem.

Podstawowe zabezpieczenia a wydajność

Źle ustawione zabezpieczenia potrafią spowolnić stronę równie skutecznie, jak słaby hosting. Chodzi głównie o nadmiarowe wtyczki bezpieczeństwa i filtry nakładane warstwami.

Rozsądny model to filtracja na poziomie serwera/WAF (np. ochrona przed DDoS, blokada oczywistego spamu) oraz jedna lekka wtyczka w WordPressie do podstawowych zadań (zmiana adresu logowania, ograniczenie prób logowania).

Jeżeli ruch jest filtrowany jednocześnie przez kilka ciężkich wtyczek, każda z nich robi zapytania do bazy i loguje zdarzenia. Skutkiem jest wysoki TTFB, szczególnie przy atakach typu brute force.

Cache w WordPressie – mechanizm, rodzaje i wybór rozwiązania

Jak działa cache stron (page cache)

Bez cache każdy request do WordPressa uruchamia cały stos: PHP, zapytania do bazy, generowanie HTML. Page cache zapisuje gotowy HTML i przy kolejnych wejściach serwuje go bez dotykania WordPressa.

Kluczowy efekt: drastyczne obniżenie TTFB przy kolejnych wizytach oraz znaczące odciążenie procesora i bazy danych.

Page cache może być realizowany przez wtyczkę (np. zapis statycznych plików na dysku) albo przez warstwę serwera (np. Nginx, Varnish, cache w panelu hostingu).

Cache obiektów (object cache) i transients

WordPress intensywnie korzysta z bazy danych. Cache obiektów zapisuje wyniki zapytań (np. pobrane wpisy, ustawienia) w pamięci, by nie odpytywać bazy przy każdym requestcie.

Do stałego cache obiektów używa się zwykle Redis albo Memcached. W prostszej wersji WordPress może trzymać cache obiektów w plikach, ale to mniej efektywne.

Mechanizm transients pozwala programistom przechowywać dane tymczasowe (np. wyniki z API) z datą wygaśnięcia. Dobrze użyty znacząco zmniejsza liczbę ciężkich operacji.

Cache przeglądarki (browser cache)

Cache po stronie użytkownika przechowuje CSS, JS, obrazy i fonty lokalnie na urządzeniu. Przy kolejnych wizytach przeglądarka nie musi pobierać ich ponownie.

Ustawienia cache przeglądarki definiuje się nagłówkami HTTP (Cache-Control, Expires, ETag, Last-Modified). Część hostingów i wtyczek cache konfiguruje je automatycznie.

Dla statycznych elementów (logo, ikony, fonty) można spokojnie ustawić długi czas ważności, np. 1 rok. Przy zmianie pliku stosuje się wersjonowanie w nazwie (np. style.css?ver=3).

Fragment cache i cache dla dynamicznych elementów

W sklepach lub serwisach z personalizacją cała strona nie może być w pełni statyczna. Fragment cache pozwala cache’ować część widoku, a resztę generować dynamicznie.

Przykład: lista produktów lub blogowych wpisów w cache, ale koszyk i informacje o użytkowniku renderowane na bieżąco.

Niektóre page cache’e i frameworki szablonów pozwalają oznaczyć „bloki” wyłączone z cache. W WordPressie często wykorzystuje się do tego funkcje warunkowe (np. is_user_logged_in) i osobne reguły w konfiguracji wtyczki cache.

Cache pełnostronicowy po stronie serwera i reverse proxy

Gdy hosting udostępnia Nginx/Varnish jako reverse proxy, można cache’ować całe strony „przed” WordPressem. To najszybsza metoda page cache.

Taki cache działa już na poziomie HTTP, często bez uruchamiania PHP. Przy dobrze ustawionych regułach TTFB spada do ułamków sekundy, nawet przy większym ruchu.

Konfiguracja bywa jednak bardziej złożona (np. różne reguły dla zalogowanych, koszyka, stron z parametrami). Część managed hostingów dostarcza gotowy panel do ustawiania takich reguł bez grzebania w konfiguracji serwera.

Jak wybrać wtyczkę cache do WordPressa

Dostępnych wtyczek cache jest dużo, ale różnią się podejściem i poziomem komplikacji. Zanim zainstalujesz kolejną, oceń sytuację na hostingu.

• Jeśli hosting ma wbudowany page cache – często lepiej go użyć i dobrać prostą wtyczkę do optymalizacji statycznych plików.
• Jeśli hosting nie ma własnego cache – wtyczka page cache jest niemal obowiązkowa.
• Jeśli ruch jest spory, a strona rozbudowana – przyda się wtyczka łącząca page cache i object cache lub możliwość podpięcia Redis.

Przy wyborze zwróć uwagę na: wsparcie dla WooCommerce (wykluczenia koszyka, checkoutu), integrację z CDN, możliwość ustawiania TTL i czyszczenia cache przy aktualizacji treści.

Konfiguracja cache krok po kroku – scenariusze praktyczne

Prosta strona firmowa na hostingu współdzielonym

Cel: szybkie skrócenie TTFB i czasu ładowania bez dużej ingerencji w serwer.

1. Zainstaluj lekką wtyczkę cache z trybem „simple” lub „recommended settings”.
2. Włącz page cache dla użytkowników niezalogowanych i ustaw automatyczne czyszczenie cache przy aktualizacji wpisów/stron.
3. Aktywuj kompresję gzip/brotli, jeśli wtyczka to oferuje (jeżeli nie – sprawdź w panelu hostingu).
4. Skonfiguruj nagłówki cache przeglądarki dla CSS/JS/obrazów na minimum 1 miesiąc.
5. Wyłącz minifikację, jeśli hosting jest wolniejszy lub masz dużo wtyczek – minifikację można dołożyć później po testach.

Po wdrożeniu zrób kilka testów w PageSpeed Insights i GTmetrix. Jeśli pojawią się błędy w stylach lub JS, wyłącz scalanie plików, zostawiając sam page cache.

Sklep WooCommerce z ruchem i częstymi zmianami

W sklepie kwestia cache jest delikatniejsza: nie można „mrozić” koszyka i checkoutu, a jednocześnie lista produktów i strony kategorii mogą być mocno cache’owane.

1. Wybierz wtyczkę lub rozwiązanie serwerowe z natywnym wsparciem WooCommerce.
2. Wyłącz page cache dla:
   • stron koszyka i zamówienia,
   • panelu klienta,
   • wszystkich URL-i z parametrami typu ?add-to-cart,
   • użytkowników zalogowanych (jeśli to możliwe bez dużej straty wydajności).
3. Włącz page cache dla:
   • strony głównej,
   • stron kategorii,
   • kart produktów (z rozsądnym czasem ważności, np. kilkanaście minut).
4. Aktywuj object cache (Redis/Memcached) – sklepy szczególnie zyskują na redukcji zapytań do bazy.
5. Ustaw automatyczne czyszczenie cache dla konkretnych produktów przy zmianie stanu magazynowego lub ceny.

Po konfiguracji przetestuj cały proces zakupu w trybie prywatnym, zwracając uwagę na poprawność koszyka, rabatów i wysyłek.

Serwis contentowy z ruchem z social media

W przypadku blogów i serwisów newsowych szczyty ruchu bywają krótkie, ale intensywne – np. po publikacji artykułu na Facebooku czy X.

Przy takim profilu:

• maksymalnie cache’uj pojedyncze wpisy,
• włącz preloading cache (wtyczka generuje kopie stron zawczasu),
• po publikacji artykułu pozwól systemowi natychmiast wygenerować jego wersję z cache, by fala wejść nie zabiła serwera,
• rozważ CDN dla obrazów – treści często zawierają wiele dużych grafik.

Dodatkowo można skrócić TTL cache strony głównej, by szybciej pokazywać nowe wpisy, zostawiając dłuższy TTL dla archiwów i pojedynczych artykułów.

Radzenie sobie z problemami po włączeniu cache

Typowe problemy po aktywacji cache to: nieaktualna treść, złe działanie formularzy, błędy logowania.

Przy diagnozie przejdź przez prostą listę:

• sprawdź, czy problem występuje w trybie incognito i na innym urządzeniu,
• przeczyść globalnie cache strony i cache przeglądarki,
• wyklucz z page cache newralgiczne adresy (logowanie, formularze kontaktowe, strony z dynamicznym JS),
• czasowo wyłącz minifikację i scalanie plików – wiele konfliktów wynika właśnie z nich, nie z samego page cache.

CDN dla WordPressa – kiedy pomaga, jak go podłączyć

Kiedy CDN ma sens, a kiedy niewiele da

CDN (Content Delivery Network) najwięcej daje przy ruchu rozproszonym geograficznie oraz przy dużej liczbie ciężkich zasobów statycznych (obrazy, JS, CSS, fonty, wideo).

Jeśli większość użytkowników jest z jednego kraju, a serwer stoi blisko nich i strona jest lekka, CDN może poprawić wyniki tylko minimalnie, za to skomplikuje konfigurację.

Za to przy dużym ruchu z różnych kontynentów, kampaniach międzynarodowych lub rozbudowanych portalach CDN potrafi mocno obniżyć TTFB i LCP, a przy okazji odciążyć główny serwer.

Jakie typy treści podawać przez CDN

CDN najlepiej sprawdza się dla zasobów statycznych:

• obrazów (JPG, PNG, WebP, AVIF),
• plików CSS i JS,
• fontów, ikon,
• pliku theme i child theme (jeśli są serwowane jako statyczne zasoby).

Strony HTML mogą być również serwowane z CDN (tzw. full page caching), ale konfiguracja jest bardziej wrażliwa na logowanie, cache koszyka czy treść personalizowaną.

Modele integracji CDN z WordPressem

Są trzy podstawowe modele spięcia CDN z WordPressem.

• Pull CDN – CDN pobiera zasoby z twojego serwera przy pierwszym żądaniu, a później serwuje je z własnych edge’ów. Najczęściej spotykane rozwiązanie.
• Push CDN – zasoby są „wypy chane” na CDN (np. za pomocą skryptu lub wtyczki) i serwowane tylko stamtąd. Przydatne przy dużych bibliotekach plików.
• Reverse proxy (np. Cloudflare) – cały ruch przechodzi przez CDN, który działa jak warstwa pośrednia z możliwością cache pełnostronicowego i WAF.

Krok po kroku: proste podłączenie CDN do WordPressa

Przy klasycznym pull CDN konfiguracja zwykle wygląda podobnie.

1. Załóż konto u dostawcy CDN i dodaj domenę jako „pull zone” albo projekt.
2. Skonfiguruj adres źródłowy (origin) – to domena lub adres IP twojego serwera.
3. Otrzymasz adres CDN, np. cdn.twojadomena.com lub adres techniczny dostawcy.
4. W WordPressie zainstaluj wtyczkę do integracji z CDN (często ta sama wtyczka cache ma taką funkcję).
5. Ustaw, by adresy do zasobów statycznych (wp-content/uploads, wp-includes, CSS/JS motywu) były przepisywane na adres CDN.

Po kilku minutach pierwsze żądania zaczną napełniać cache na CDN. Raporty w panelu dostawcy pokażą, jaka część ruchu jest obsługiwana z jego infrastruktury.

Cloudflare i podobne usługi „proxy CDN”

Cloudflare, Fastly i inne usługi tego typu działają jak reverse proxy: otrzymują cały ruch i mogą cache’ować zarówno statyczne zasoby, jak i HTML.

Podłączenie zwykle polega na zmianie serwerów nazw (DNS) na te od dostawcy. Potem konfiguruje się reguły cache, zabezpieczenia i ewentualne „page rules” dla wybranych adresów.

W WordPressie trzeba logicznie pogodzić cache po stronie CDN i cache po stronie serwera/wtyczki. Często najlepiej zacząć od cache zasobów statycznych w Cloudflare, zostawiając HTML po stronie serwera, a dopiero później testować pełny cache HTML.

Typowe problemy po wdrożeniu CDN i ich rozwiązania

Przy CDN często pojawiają się podobne problemy:

Przy problemach z CDN najpierw wyklucz konflikt z cache po stronie WordPressa i przeglądarki, dopiero później szukaj winy w samym CDN.

• Przestarzała treść – skróć TTL po stronie CDN dla HTML, włącz automatyczne czyszczenie cache po zmianie treści (webhooki, wtyczka integracyjna) albo ustaw „cache by query string” dla stron z filtrami.
• Mieszana treść (mixed content) – upewnij się, że WordPress ma poprawnie ustawione adresy HTTPS w Ustawienia → Ogólne i przepuść stronę przez narzędzie do zamiany URL-i na https (np. Better Search Replace).
• Problemy z logowaniem i koszykiem – wyklucz z pełnego cache HTML strony logowania, koszyka, checkoutu i panelu klienta; na poziomie CDN ustaw reguły „Bypass cache” dla tych adresów.
• „Rozjechany” CSS lub brak JS – sprawdź, czy CDN nie minifikuje plików drugi raz i czy nagłówki Content-Type są poprawne; jeśli korzystasz z funkcji „Rocket Loader” lub podobnych, przetestuj stronę z wyłączonymi „ulepszeniami” JS.

Obrazy – kompresja, formaty, wymiary i lazy loading

Dlaczego obrazy zabijają wydajność WordPressa

Największą część „wagi” strony stanowią zwykle zdjęcia. Jeden nieprzycięty baner z aparatu potrafi ważyć więcej niż cała reszta strony.

Przy wolniejszych łączach lub na telefonie bez Wi-Fi kilka takich plików może wydłużyć LCP o kilka sekund, nawet jeśli TTFB jest już zoptymalizowane.

Dobór formatu: JPG, PNG, WebP, AVIF

Format dobiera się do typu grafiki. Nie ma jednego idealnego rozwiązania.

• JPG – zdjęcia, tła, banery z przejściami tonalnymi. Dobre kompromis między jakością i wagą.
• PNG – logotypy, ikony, zrzuty ekranu z tekstem, elementy wymagające przezroczystości i ostrości krawędzi.
• WebP – zamiennik JPG/PNG, zwykle lżejszy przy podobnej jakości. Powinien być domyślną opcją dla nowych projektów.
• AVIF – jeszcze mniejsze pliki niż WebP, ale gorsze wsparcie w przeglądarkach i nie wszystkie narzędzia go obsługują.

Praktyczny schemat: przechowuj oryginały w JPG/PNG, a na froncie serwuj WebP (lub WebP + fallback do JPG/PNG) za pomocą wtyczki albo funkcji serwera.

Kompresja obrazów: poziomy i narzędzia

Kompresję można zrobić przed wgraniem plików lub automatycznie po stronie WordPressa.

Offline dobrze sprawdzają się: TinyPNG (online), ImageOptim (macOS), RIOT (Windows) czy wbudowane eksporty z Photoshopa, GIMPa, Figma.

Online i w WordPressie wygodniejsze są wtyczki, np.

• Imagify, ShortPixel, Optimus, EWWW Image Optimizer,
• wbudowane optymalizacje w niektórych hostingach (kompresja po stronie serwera lub CDN).

Przy ustawianiu poziomu kompresji zacznij od profilu „lossy”/„aggressive” i porównaj kilka kluczowych grafik. Jeśli widać artefakty, cofnij na „balanced”.

Rozmiary obrazów i skalowanie w WordPressie

Częsty błąd to wgrywanie obrazów z aparatu lub stocka w pełnym rozmiarze i wstawianie ich w bloki bez przycinania.

WordPress generuje kilka wersji rozmiarów (miniatura, medium, large, itp.), ale motyw może wymagać własnych wymiarów. Przy zmianie motywu dobrze jest przebudować miniatury (np. wtyczką Regenerate Thumbnails).

Przed wgraniem do mediów ustaw maksymalną szerokość grafiki pod projekt, np. 1920 px dla pełnoekranowych teł, 1200 px dla zdjęć w treści. Zmniejsza to wagę i przyspiesza generowanie miniatur.

Responsywne obrazy: srcset i sizes

Od kilku wersji WordPress sam dodaje atrybuty srcset i sizes do obrazów w treści. Przeglądarka może dzięki temu pobrać mniejszą wersję na małym ekranie.

Problem pojawia się, gdy motyw wymusza skalowanie w CSS (np. obraz 4000 px zwężany do 400 px). HTML sugeruje wtedy pobranie zbyt dużej wersji, bo WordPress nie zna realnej szerokości kontenera.

Rozwiązaniem jest dopasowanie rozmiarów obrazów używanych w motywie (funkcja add_image_size()) oraz poprawne ustawienie szerokości kolumn w CSS i opcjach motywu.

Lazy loading – kiedy pomaga, kiedy szkodzi

Lazy loading opóźnia ładowanie obrazów spoza pierwszego widoku (below the fold). W praktyce mocno zmniejsza wagę początkowego żądania.

Od WordPressa 5.5 lazy loading jest domyślnie włączony dla obrazów (loading="lazy"). Wtyczki potrafią jednak dodawać własne mechanizmy (np. z JS), co czasem powoduje konflikty.

Podstawowa zasada: wyłącz lazy loading dla kluczowych grafik nad linią zgięcia – slidera hero, głównego banera, logotypu w nagłówku. Te obrazy powinny być dostępne od razu, inaczej LCP może się pogorszyć.

Techniki zaawansowane: preloading i obraz w tle

Dla głównego obrazu LCP można dodać <link rel="preload" as="image"> w <head>. Część wtyczek performance ma opcję oznaczenia jednego lub kilku plików jako preload.

Jeśli hero jest ustawiony jako background-image w CSS, przeglądarka może go pobrać później niż <img>. W takim przypadku opłaca się przenieść kluczowy obraz do HTML albo zastosować preload dla pliku z tłem.

Optymalizacja galerii i sliderów

Galerie i slidery ładują często kilkanaście obrazów na raz. Jeśli każdy waży po kilka megabajtów, nie pomoże nawet najlepszy cache.

Rozsądny schemat:

• wszystkie miniatury przycinaj do jednego rozmiaru (np. 400×400 px) i pokazuj je w siatce,
• duże wersje ładuj dopiero po kliknięciu (lightbox),
• w sliderach ogranicz liczbę slajdów startowych i włącz lazy loading dla dalszych.

Jeśli wtyczka slidera nie wspiera lazy loadingu, poszukaj alternatywy – ciężki, przestarzały slider potrafi unieważnić większość pozostałych optymalizacji.

Obrazy a CDN – sensowny podział ról

Największy efekt daje połączenie kompresji i właściwych rozmiarów z dostarczaniem przez CDN z najbliższego węzła.

Część CDN-ów potrafi samodzielnie generować WebP/AVIF z oryginałów JPG/PNG i serwować odpowiednią wersję w zależności od przeglądarki. Wtedy nie trzeba dodatkowej wtyczki do konwersji na WordPressie.

Przy takiej konfiguracji:

• na serwerze przechowujesz dobrej jakości JPG/PNG,
• CDN podmienia format na WebP/AVIF „w locie”,
• obciążenie CPU i dysku po stronie hostingu spada, bo nie generujesz dodatkowych plików.

Optymalizacja bazy danych WordPressa

Dlaczego baza danych spowalnia WordPressa

Z czasem tabela wp_posts, wp_postmeta, wp_options i inne rosną przez:

• wersje wpisów, autosave’y, śmieci w koszu,
• porzucone dane po odinstalowanych wtyczkach,
• przewymiarowane transients i opcje autoload.

To przekłada się na wolniejsze zapytania SQL, „zamyślenia” panelu admina i dłuższy TTFB przy bardziej złożonych stronach.

Bezpieczny punkt startu: kopia zapasowa

Przed czyszczeniem bazy zrób pełny backup: plików i MySQL. Najprościej użyć narzędzia hostingu albo wtyczki backupowej (UpdraftPlus, Duplicator, All-in-One WP Migration).

Przy większych serwisach lepiej wykonać kopię i testy na środowisku staging, nie na produkcji.

Podstawowe czyszczenie: wersje, kosz, spam

W panelu WordPressa możesz ograniczyć liczbę wersji wpisów, np. dodając do wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

Aktualne „śmieci” usuniesz ręcznie:

• opróżnij kosz wpisów i stron,
• usuń komentarze ze spamu i kosza,
• skasuj stare wersje szkiców, jeśli nie będą potrzebne.

Część wtyczek optymalizacyjnych (np. WP-Optimize) pozwala to zrobić hurtowo jednym kliknięciem, ale warto obejrzeć opcje przed zatwierdzeniem.

Opcje autoload i transients – cichy zabójca wydajności

Przy każdym wejściu na stronę WordPress ładuje opcje z wp_options oznaczone jako autoload = 'yes'. Jeśli jest ich dużo i są duże, każdy request zaczyna się od ciężkiego SELECT-a.

Typowy problem: wtyczka zapisuje dane statystyk, cache lub logów jako autoload i nie czyści ich po odinstalowaniu.

Analizę możesz zrobić w narzędziu typu Query Monitor lub jednym z dedykowanych skryptów (np. Advanced Database Cleaner). Szukaj opcji ważących po kilkaset kilobajtów i oznaczonych jako autoload.

Zmiana autoload na „no” lub usunięcie wpisu powinna być świadoma – usuń tylko te opcje, które na pewno należą do nieużywanych wtyczek lub są opisane jako dane tymczasowe.

Indeksy w bazie – kiedy mają znaczenie

Przy bardzo rozbudowanych stronach (tysiące produktów, setki tysięcy wpisów) zapytania do wp_postmeta lub wp_comments zaczynają być wolne bez dodatkowych indeksów.

Niektóre wtyczki ecommerce lub katalogów dodają zoptymalizowane indeksy same. Jeśli nie, przy zaawansowanych problemach opłaca się skonsultować z administratorem baz danych, który:

• przejrzy najwolniejsze zapytania (slow query log),
• zaproponuje indeksy pod konkretne scenariusze (np. filtrowanie po meta_key/meta_value),
• zweryfikuje, czy indeksy nie spowolnią innych operacji.

Optymalizacja tabel i porządkowanie struktur

Po latach użytkowania baza może mieć „dziury” po skasowanych rekordach i stare tabele po wtyczkach, których już nie ma.

Prosty krok to wykonanie OPTIMIZE TABLE na wybranych tabelach (hostingi często mają do tego przycisk w phpMyAdmin). Zmniejsza to rozmiar i czas skanowania.

Stare tabele można zidentyfikować po prefiksie lub nazwie wtyczki. Jeśli wiesz, że danej wtyczki już nigdy nie użyjesz, a jej dane nie są potrzebne, taka tabela może zostać usunięta po wykonaniu kopii zapasowej.

Planowanie regularnej konserwacji bazy

Zamiast jednorazowego dużego sprzątania lepiej ustawić cykliczne, małe zadania.

• raz na miesiąc: czyszczenie wersji wpisów powyżej określonej liczby, opróżnianie kosza, usuwanie spamu,
• raz na kwartał: przegląd wp_options pod kątem rozmiaru i autoload,
• przy każdej większej zmianie wtyczek: usunięcie zbędnych tabel i opcji po odinstalowanych rozszerzeniach.

Proste serwisy można obsłużyć pojedynczą wtyczką do optymalizacji bazy, większe projekty lepiej mieć pod opieką administracyjną z dostępem do logów SQL.