Optymalizacja WordPress: LiteSpeed Cache + Redis

Strona WordPress bez cache przy zwiększonym ruchu zwraca błędy 503 i przestaje działać. Po włączeniu LiteSpeed Cache z Redis ta sama strona obsługuje 38× więcej żądań przy 40× krótszym czasie odpowiedzi.

Poniższy poradnik pokazuje jak w kilka minut skonfigurować cache na hostingu Joton oraz wyjaśnia dlaczego te technologie dają tak znaczącą poprawę wydajności.

Testowana strona

Parametry środowiska:

• WordPress z Elementorem (najnowsza wersja)
• PHP 8.5
• Hosting współdzielony Joton.io
• Test obciążeniowy: 50 równoczesnych użytkowników przez 60 sekund (narzędzie Locust)

Bez cache strona zwracała błędy przy już 50 użytkownikach. Z cache obsługuje ruch bez problemów.

Wyniki testów

Przed włączeniem cache

Metryka	Wartość
Żądania na sekundę	44.52 req/s
Średni czas odpowiedzi	1043 ms
Mediana (P50)	1000 ms
P95	2000 ms
P99	2200 ms
Maksymalny czas	2955 ms
Błędy	32% (503 Service Unavailable)
Liczba żądań	3231

Przy 50 użytkownikach serwer nie nadążał z przetwarzaniem żądań. Co trzecie żądanie kończyło się błędem 503 - strona była praktycznie niedostępna.

Po włączeniu LiteSpeed Cache + Redis

Metryka	Wartość
Żądania na sekundę	1717.51 req/s
Średni czas odpowiedzi	26 ms
Mediana (P50)	25 ms
P95	39 ms
P99	58 ms
Maksymalny czas	283 ms
Błędy	0%
Liczba żądań	103 981

Porównanie wyników

Metryka	Przed	Po	Poprawa
Przepustowość	44.52 req/s	1717.51 req/s	38.6× więcej
Średni czas odpowiedzi	1043 ms	26 ms	40× szybciej
P95	2000 ms	39 ms	51× szybciej
P99	2200 ms	58 ms	38× szybciej
Błędy	32%	0%	100% dostępność

Wyniki GTmetrix (Core Web Vitals)

Locust mierzy wydajność serwera pod obciążeniem. GTmetrix mierzy doświadczenie użytkownika - jak szybko strona się ładuje i wyświetla w przeglądarce.

Przed włączeniem cache

Metryka	Wartość	Ocena
GTmetrix Grade	B	73% Performance
First Contentful Paint (FCP)	807 ms
Largest Contentful Paint (LCP)	807 ms
Total Blocking Time (TBT)	138 ms
Cumulative Layout Shift (CLS)	0.40
Time to First Byte (TTFB)	280 ms
Fully Loaded	4.7 s
Rozmiar strony	3.01 MB
Liczba żądań	141

Strona bez cache ładuje się prawie 5 sekund. Przeglądarka musi pobrać 141 plików o łącznym rozmiarze 3 MB.

Po włączeniu LiteSpeed Cache + Redis

Metryka	Wartość	Ocena
GTmetrix Grade	A	100% Performance
First Contentful Paint (FCP)	370 ms
Largest Contentful Paint (LCP)	370 ms
Total Blocking Time (TBT)	11 ms
Cumulative Layout Shift (CLS)	0
Time to First Byte (TTFB)	106 ms
Fully Loaded	595 ms
Rozmiar strony	457 KB
Liczba żądań	12

Porównanie GTmetrix

Metryka	Przed	Po	Poprawa
GTmetrix Grade	B (73%)	A (100%)	+27 punktów
Fully Loaded	4.7 s	595 ms	7.9× szybciej
LCP	807 ms	370 ms	2.2× szybciej
TTFB	280 ms	106 ms	2.6× szybciej
Rozmiar strony	3.01 MB	457 KB	6.6× mniejszy
Liczba żądań	141	12	11.8× mniej
CLS	0.40	0	Brak przeskoków

Co oznaczają metryki GTmetrix

Core Web Vitals to metryki Google używane do oceny jakości strony:

Metryka	Co mierzy	Dobry wynik
LCP (Largest Contentful Paint)	Kiedy główna treść jest widoczna	< 2.5 s
FCP (First Contentful Paint)	Kiedy cokolwiek pojawia się na ekranie	< 1.8 s
TBT (Total Blocking Time)	Jak długo strona jest "zamrożona"	< 200 ms
CLS (Cumulative Layout Shift)	Czy elementy przeskakują podczas ładowania	< 0.1
TTFB (Time to First Byte)	Jak szybko serwer odpowiada	< 200 ms

Dlaczego te metryki są ważne?

• SEO - Google używa Core Web Vitals jako czynnika rankingowego
• Konwersje - każda sekunda opóźnienia zmniejsza konwersję o 7%
• Bounce rate - 53% użytkowników opuszcza stronę która ładuje się dłużej niż 3 sekundy

Co zrobiło największą różnicę:

1. Łączenie plików CSS/JS - z 141 żądań do 12 (mniej round-tripów do serwera)
2. Minifikacja - rozmiar z 3 MB do 457 KB (szybsze pobieranie)
3. Page cache - TTFB z 280 ms do 106 ms (serwer odpowiada szybciej)
4. Lazy loading - CLS z 0.40 do 0 (obrazki nie przesuwają treści)

Jak czytać wyniki Locust

Locust to narzędzie do testów obciążeniowych - symuluje wielu użytkowników odwiedzających stronę jednocześnie. Wyniki pokazują jak strona radzi sobie pod presją.

Przepustowość (req/s)

Requests per second - ile żądań serwer obsługuje w ciągu sekundy.

• 44.52 req/s (przed) - serwer obsługiwał ~45 żądań na sekundę, ale przy tym generował błędy
• 1717.51 req/s (po) - serwer obsługuje ~1700 żądań na sekundę bez błędów

Im wyższa wartość, tym więcej użytkowników strona może obsłużyć jednocześnie. Wzrost z 45 do 1700 req/s oznacza, że strona może przyjąć 38× więcej ruchu zanim zacznie mieć problemy.

Czas odpowiedzi i percentyle

Czas odpowiedzi to ile milisekund serwer potrzebuje na wygenerowanie strony. Percentyle pokazują rozkład tych czasów:

Percentyl	Znaczenie	Przed	Po
P50 (mediana)	Połowa żądań była szybsza	1000 ms	25 ms
P95	95% żądań było szybszych	2000 ms	39 ms
P99	99% żądań było szybszych	2200 ms	58 ms

Dlaczego P95 i P99 są ważne?

Średnia może być myląca - jeśli 99 żądań trwa 10 ms, a jedno 10 000 ms, średnia wynosi 109 ms, ale użytkownik który trafił na to jedno żądanie czekał 10 sekund.

• P95 = 39 ms oznacza, że 95% użytkowników dostanie stronę w mniej niż 39 ms
• P99 = 58 ms oznacza, że nawet "pechowi" użytkownicy (1 na 100) czekają maksymalnie 58 ms

Przed optymalizacją P99 wynosił 2200 ms - co dziesiąty użytkownik czekał ponad 2 sekundy.

Błędy 503 Service Unavailable

Błąd 503 oznacza, że serwer jest przeciążony i nie może obsłużyć żądania. W naszym teście:

• Przed: 32% żądań kończyło się błędem 503 - co trzeci użytkownik widział stronę błędu
• Po: 0% błędów - każde żądanie zostało obsłużone

Jak czytać wykresy Locust

Górny wykres (Total Requests per Second):

• Zielona linia (RPS) - ile żądań serwer obsługuje
• Czerwona linia (Failures/s) - ile żądań kończy się błędem
• Przed: zielona i czerwona linie blisko siebie = dużo błędów
• Po: czerwona linia na zero = brak błędów

Środkowy wykres (Response Times):

• Pomarańczowa linia (50th percentile) - typowy czas odpowiedzi
• Fioletowa linia (95th percentile) - czas dla wolniejszych żądań
• Przed: linie na poziomie 1000-2000 ms
• Po: linie na poziomie 20-50 ms

Dolny wykres (Number of Users):

• Pokazuje ile wirtualnych użytkowników było aktywnych
• W obu testach: 50 użytkowników

Dlaczego strona bez cache jest wolna

Każde wejście na stronę WordPress bez cache uruchamia następujący proces:

Żądanie użytkownika
    ↓
Serwer WWW (LiteSpeed)
    ↓
PHP (uruchomienie interpretera)
    ↓
WordPress (ładowanie jądra, wtyczek, motywu)
    ↓
Zapytania do bazy danych MySQL (10-50+ zapytań)
    ↓
Generowanie HTML przez PHP
    ↓
Odpowiedź do użytkownika

Typowe czasy:

• Uruchomienie PHP: 10-50 ms
• Ładowanie WordPress: 50-200 ms
• Zapytania MySQL: 50-500 ms (zależnie od złożoności strony)
• Generowanie HTML: 100-500 ms

Suma: 200-1200 ms na każde żądanie

Przy 50 równoczesnych użytkownikach serwer musi wykonać tę operację 50 razy jednocześnie. Zasoby (CPU, RAM, połączenia do bazy) szybko się kończą i serwer zaczyna odrzucać żądania (błąd 503).

Jak działa LiteSpeed Cache

LiteSpeed Cache to wtyczka stworzona przez LiteSpeed Technologies - producenta serwera WWW na którym działa hosting Joton. Kluczowa różnica względem innych wtyczek cache: działa na poziomie serwera, nie PHP.

Cache na poziomie serwera vs PHP

Wtyczki cache oparte na PHP (WP Super Cache, W3 Total Cache):

Żądanie → Serwer WWW → PHP → Wtyczka sprawdza cache → Zwraca z cache

PHP musi się uruchomić żeby sprawdzić czy strona jest w cache.

LiteSpeed Cache:

Żądanie → Serwer WWW (sprawdza cache) → Zwraca z cache

Serwer WWW sam sprawdza cache zanim uruchomi PHP. Jeśli strona jest w cache, PHP w ogóle się nie uruchamia.

Efekt: LiteSpeed Cache jest 10-100× szybszy niż wtyczki oparte na PHP.

Co robi preset Advanced

Preset Advanced włącza zestaw optymalizacji przetestowanych na tysiącach stron WordPress:

1. Page Cache (cache stron)

• Zapisuje wygenerowany HTML na dysku
• Kolejne żądania dostają gotowy plik bez uruchamiania PHP
• Automatycznie czyści cache gdy edytujesz treść w WordPress

2. Browser Cache (cache przeglądarki)

• Ustawia nagłówki HTTP mówiące przeglądarce jak długo trzymać pliki
• Obrazki, CSS, JS są pobierane tylko raz - przy kolejnych wizytach ładują się z dysku użytkownika

3. Minifikacja CSS/JS

• Usuwa zbędne spacje, komentarze i znaki z plików CSS i JavaScript
• Zmniejsza rozmiar plików o 10-30%

4. Łączenie plików CSS/JS

• Zamiast 20 małych plików CSS ładuje 1 duży
• Zmniejsza liczbę żądań HTTP (każde żądanie to dodatkowe opóźnienie)

5. Lazy Load obrazków

• Obrazki poniżej widocznego ekranu ładują się dopiero gdy użytkownik przewinie stronę
• Strona wyświetla się szybciej bo nie czeka na wszystkie obrazki

6. Optymalizacja bazy danych

• Czyści tymczasowe dane, rewizje postów, spam
• Zmniejsza rozmiar bazy i przyspiesza zapytania

Jakie zmiany wprowadza w kodzie strony

Przed (bez cache):

<link rel="stylesheet" href="/wp-content/themes/theme/style.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 15 kolejnych plików CSS ... -->

<script src="/wp-includes/js/jquery/jquery.min.js"></script>
<script src="/wp-content/plugins/elementor/assets/js/frontend.js"></script>
<!-- ... 20 kolejnych plików JS ... -->

Po (z LiteSpeed Cache):

<link rel="stylesheet" href="/wp-content/litespeed/css/abc123.css">

<script src="/wp-content/litespeed/js/def456.js" defer></script>

<img src="placeholder.svg" data-src="/wp-content/uploads/photo.jpg" class="lazyload">

Zmiany:

• 18 plików CSS → 1 zminifikowany plik
• 22 pliki JS → 1 zminifikowany plik z atrybutem defer (nie blokuje ładowania strony)
• Obrazki mają data-src zamiast src (lazy loading)

Jak działa Redis Object Cache

Czym jest Object Cache w WordPress

WordPress podczas generowania strony wykonuje wiele zapytań do bazy danych:

• Pobierz ustawienia strony
• Pobierz menu nawigacyjne
• Pobierz widgety z sidebara
• Pobierz dane użytkownika (jeśli zalogowany)
• Pobierz treść strony
• Pobierz komentarze
• ...i dziesiątki innych

Wyniki tych zapytań WordPress zapisuje w obiektach PHP - zmiennych w pamięci. Problem: te obiekty znikają gdy PHP kończy przetwarzanie żądania. Przy następnym żądaniu wszystkie zapytania wykonują się od nowa.

Standardowy Object Cache (bez Redis)

Żądanie 1:
  WordPress → MySQL: "Pobierz ustawienia" (5 ms)
  WordPress → MySQL: "Pobierz menu" (3 ms)
  WordPress → MySQL: "Pobierz treść" (10 ms)
  → Zapisz w pamięci PHP
  → Koniec żądania, pamięć PHP wyczyszczona

Żądanie 2 (ta sama strona, inny użytkownik):
  WordPress → MySQL: "Pobierz ustawienia" (5 ms)  ← te same dane, ponowne zapytanie
  WordPress → MySQL: "Pobierz menu" (3 ms)        ← te same dane, ponowne zapytanie
  WordPress → MySQL: "Pobierz treść" (10 ms)      ← te same dane, ponowne zapytanie

Object Cache z Redis

Redis to serwer bazy danych działający w pamięci RAM. Dane w Redis są dostępne między żądaniami PHP:

Żądanie 1:
  WordPress → Redis: "Czy masz ustawienia?" → NIE
  WordPress → MySQL: "Pobierz ustawienia" (5 ms)
  WordPress → Redis: "Zapisz ustawienia"
  → Koniec żądania

Żądanie 2:
  WordPress → Redis: "Czy masz ustawienia?" → TAK (0.1 ms)
  → Brak zapytania do MySQL

Różnica w czasie:

• Zapytanie MySQL: 5-50 ms (dysk, parsowanie SQL, zwracanie wyników)
• Zapytanie Redis: 0.1-1 ms (pamięć RAM, prosty klucz-wartość)

Kiedy Redis najbardziej pomaga

1. Panel administracyjny WordPress

Panel admina nie może być cache'owany (każdy admin widzi inne dane). Bez Redis każde kliknięcie w panelu to 50-200 zapytań MySQL. Z Redis większość tych zapytań odpowiada cache.

2. Strony WooCommerce dla zalogowanych użytkowników

Koszyk, historia zamówień, panel klienta - te strony są spersonalizowane i nie mogą być w page cache. Redis przyspiesza zapytania o produkty, ceny, stany magazynowe.

3. Strony z dużą ilością dynamicznych danych

Fora dyskusyjne, portale członkowskie, strony z wieloma widgetami - wszędzie gdzie WordPress wykonuje dużo zapytań.

Redis na hostingu Joton

Redis w Joton działa jako lokalny serwer:

• Adres: 127.0.0.1:6379
• Bez hasła: dostęp tylko z Twojego konta (bezpieczne)
• Pamięć: przydzielona automatycznie
• Persistence: dane przeżywają restart serwera

Konfiguracja krok po kroku

1. Włączenie Redis na serwerze

1. Zaloguj się do Panelu administracyjnego hostingu
2. Przejdź do strony → Zaawansowane → Redis
3. Kliknij Włącz Redis

Redis uruchomi się jako lokalny serwer na 127.0.0.1:6379. Nie wymaga hasła i jest dostępny tylko z Twojego konta - bezpieczna konfiguracja domyślna.

2. Instalacja LiteSpeed Cache

1. W panelu WordPress przejdź do Wtyczki → Dodaj nową
2. Wyszukaj LiteSpeed Cache
3. Zainstaluj i aktywuj wtyczkę

3. Konfiguracja LiteSpeed Cache

1. Przejdź do LiteSpeed Cache → Toolbox → Import / Export
2. Kliknij Import (zaimportuje się domyślna konfiguracja dla hostingu Joton) Dotyczy to stron podłączonych do Cloudflare! Jeśli nie korzystasz z Cloudflare możesz ten krok pominąć
3. Przejdź do LiteSpeed Cache → Preset
4. Wybierz preset Advanced - jest to zalecany poziom cache dla większości stron (Domyślny)

Preset Advanced

Preset Advanced włącza cache strony, minimalizację CSS/JS, optymalizację obrazów i inne ustawienia. Jest bezpieczny dla większości stron WordPress i nie wymaga ręcznej konfiguracji.

4. Włączenie Object Cache (Redis)

1. Przejdź do LiteSpeed Cache → Cache → Object
2. Włącz Object Cache: ON
3. Ustaw Method: Redis
4. Host: 127.0.0.1
5. Port: 6379
6. Zapisz zmiany

Sprawdź status - powinien pokazywać Connected na zielono.

Kiedy cache nie pomoże

Cache stron działa dla treści która jest taka sama dla wszystkich użytkowników:

Można cache'ować	Nie można cache'ować
Strona główna	Koszyk (/cart/)
Podstrony informacyjne	Checkout (/checkout/)
Wpisy blogowe	Panel klienta (/my-account/)
Strony produktów	Wyniki wyszukiwania
Kategorie i archiwa	Strony z tokenami CSRF

Dla stron które nie mogą być cache'owane, Redis Object Cache nadal pomaga - przyspiesza zapytania do bazy danych nawet gdy cała strona musi być generowana dynamicznie.

Przykład - strona koszyka WooCommerce:

• Bez Redis: 80 zapytań MySQL × 5 ms = 400 ms tylko na bazę danych
• Z Redis: 80 zapytań, 70 z cache × 0.5 ms + 10 do MySQL × 5 ms = 85 ms

Rozwiązywanie problemów

Strona wygląda źle po włączeniu cache

Niektóre motywy lub wtyczki mogą nie działać poprawnie z minifikacją CSS/JS.

1. Przejdź do LiteSpeed Cache → Toolbox → Purge
2. Kliknij Purge All
3. Wyczyść cache przeglądarki (Ctrl+Shift+R)

Jeśli problem pozostaje:

1. Przejdź do LiteSpeed Cache → Page Optimization
2. Wyłącz CSS Minify lub JS Minify
3. Wyczyść cache ponownie

Zmiany nie są widoczne

LiteSpeed Cache automatycznie czyści cache przy edycji w WordPress. Jeśli zmieniasz pliki ręcznie (FTP/SSH):

1. Przejdź do LiteSpeed Cache → Toolbox → Purge
2. Kliknij Purge All

Redis nie łączy się

1. Sprawdź czy Redis jest włączony w panelu hostingu
2. Upewnij się że host to 127.0.0.1 (nie localhost)
3. Port: 6379
4. Hasło: puste (zostaw puste pole)

Strona działa wolno mimo cache

Sprawdź czy cache działa:

1. Otwórz stronę w trybie incognito
2. Sprawdź nagłówki HTTP (DevTools → Network → kliknij na żądanie → Headers)
3. Szukaj nagłówka X-LiteSpeed-Cache: hit

Jeśli widzisz miss zamiast hit:

• Strona może być wykluczona z cache (sprawdź ustawienia)
• Możesz być zalogowany (zalogowani użytkownicy nie dostają cache)
• Strona ma parametry GET które wykluczają ją z cache

Podsumowanie

Co zyskujesz

Aspekt	Bez cache	Z LiteSpeed Cache + Redis
Czas ładowania strony	1-3 sekundy	25-50 ms
Żądania na sekundę	~45 req/s	~1700 req/s
Stabilność przy ruchu	Błędy 503 przy 50 użytkownikach	Stabilna praca
Zużycie zasobów serwera	Wysokie (każde żądanie = PHP + MySQL)	Niskie (cache z pamięci)

Dla kogo to rozwiązanie

Idealne dla:

• Strony na Elementorze, Divi, WPBakery i innych page builderach
• Sklepy WooCommerce
• Blogi i portale informacyjne
• Strony firmowe

Działa na każdej stronie WordPress - preset Advanced jest przetestowany na tysiącach instalacji i nie wymaga ręcznej konfiguracji.

Kiedy warto włączyć

• Od razu - nie ma powodu żeby czekać. Cache przyspiesza stronę dla każdego użytkownika
• Przed kampanią marketingową - jeśli spodziewasz się zwiększonego ruchu
• Gdy strona jest wolna - cache to pierwsza rzecz do sprawdzenia
• Gdy widzisz błędy 503 - serwer jest przeciążony, cache zmniejszy obciążenie

Ile czasu zajmuje konfiguracja

Krok	Czas
Włączenie Redis w panelu hostingu	30 sekund
Instalacja LiteSpeed Cache	1 minuta
Wybór presetu Advanced	30 sekund
Konfiguracja Object Cache	1 minuta
Suma	~3 minuty

Trzy minuty konfiguracji za 38× większą przepustowość i 40× krótszy czas odpowiedzi.

Powiązane poradniki

• Kopie zapasowe - zawsze rób backup przed zmianami
• Bezpieczeństwo WordPress - ochrona zoptymalizowanej strony
• Statystyki strony - monitorowanie wydajności