Case study: serwer 6× szybszy, z 0,45 s do 0,07 s

To jest pierwszy z serii wpisów, w których pokazujemy, jak budowaliśmy i poprawialiśmy własną stronę nexowork.pl. Nie ma tu ogólników ani cudzych statystyk. Wszystkie liczby pochodzą z naszych pomiarów z listopada 2026 roku, zrobionych na tym samym serwerze, na którym czytasz ten tekst.

Tym razem bierzemy na warsztat czas odpowiedzi serwera, czyli TTFB (Time To First Byte). To czas od kliknięcia w link do chwili, gdy serwer zaczyna odsyłać stronę. Klient tego nie nazywa, ale czuje to jako „strona chwilę myśli, zanim cokolwiek się pokaże”.

Punkt wyjścia: strona „lekko laguje”

Sygnał był prosty: strona zaczęła się wydawać wolniejsza od konkurencji. Zanim cokolwiek zmieniliśmy, zmierzyliśmy, gdzie ucieka czas.

Strona	Czas odpowiedzi serwera (przed)
nexowork.pl: główna, blog, oferta, wpis	ok. 0,45 s
vetroarte.pl (sklep na tym samym koncie)	ok. 0,47 s
typowa strona z dobrze ustawionym cache	ok. 0,05–0,15 s

0,45 s to nie katastrofa, ale to prawie pół sekundy, zanim przeglądarka dostanie pierwszy bajt. Do tego dochodzą style, zdjęcia, fonty i rysowanie strony. Na telefonie z przeciętnym zasięgiem każda taka strata się sumuje.

Pierwsze podejrzenie było błędne

Na tym samym koncie hostingowym działają dwie strony: nasza i sklep Vetroarte. Naturalne pytanie brzmiało: „czy to nie przez to, że są dwie strony na jednym serwerze?”. Drugie: „może trzeba przesunąć suwak przestrzeni dyskowej (4000 MB) albo kupić większy pakiet?”.

Pomiar odpowiedział: nie. Obie strony miały prawie identyczny czas (0,45 s i 0,47 s), a obciążenie było małe. Suwak przestrzeni to tylko miejsce na pliki i nie ma żadnego wpływu na szybkość. Większy pakiet byłby wydanym pieniądzem bez efektu.

Diagnoza: cztery przyczyny

Po sprawdzeniu konfiguracji wyszły cztery rzeczy, od najważniejszej:

1. Brak cache stron. Przy każdym wejściu WordPress budował stronę od zera: zapytania do bazy, szablony, bloki, filtry.
2. Włączony WooCommerce, choć nexowork.pl nic nie sprzedaje. Miał 0 produktów i 0 zamówień, a ładował się przy każdym wejściu i dokładał własne style.
3. Niewykorzystany Redis. Hosting miał go w pakiecie i był włączony w panelu, ale WordPress z niego nie korzystał.
4. Ciężki plik stylów: 505 KB, czyli 68 KB po kompresji. Ten temat opisujemy osobno w case study o odchudzaniu CSS.

Zmiany krok po kroku, z pomiarem po każdej

Najważniejsza zasada: jedna zmiana, jeden pomiar. Inaczej nie wiadomo, co naprawdę pomogło.

Krok	Czas odpowiedzi serwera	Zysk względem startu
Na początku	ok. 0,45 s	–
Po wyłączeniu WooCommerce	ok. 0,25 s	−44%
Po podłączeniu Redisa	ok. 0,23 s	−49%
Po włączeniu cache stron	ok. 0,07 s	−84%

Krok 1: wyłączenie zbędnej wtyczki (0,45 → 0,25 s)

Największy pojedynczy zysk przed cache dało wyłączenie jednej wtyczki, która nic nie robiła. WooCommerce to potężne narzędzie, ale na stronie firmowej bez sklepu jest tylko balastem. Jego puste strony (sklep, koszyk, zamówienie, konto) przenieśliśmy do szkiców, żeby nie trafiały do Google.

Wniosek dla każdej firmy: policz wtyczki, których naprawdę używasz. Każda aktywna wtyczka ładuje swój kod przy każdym wejściu, nawet jeśli jej funkcja jest nieużywana.

Krok 2: Redis jako pamięć obiektów (0,25 → 0,23 s)

Redis trzyma w pamięci RAM wyniki zapytań do bazy. Zysk na pojedynczym wejściu był mały, bo strona nie ma wielu zapytań. Redis najbardziej pomaga tam, gdzie cache stron nie działa: w panelu administratora, przy formularzach i dla zalogowanych użytkowników. Nasza strona dostała własny prefiks kluczy, żeby jej dane nie mieszały się ze sklepem na tym samym serwerze.

Krok 3: cache stron (0,23 → 0,07 s)

To był główny zysk. Cache stron zapisuje gotowy HTML i podaje go bez uruchamiania całego WordPressa. Ustawiliśmy go tak:

• cache odświeża się co 10 godzin i czyści się automatycznie po każdej zmianie treści,
• strona kontaktu, formularze i adresy wp-json zawsze idą na żywo, żeby formularz i kalendarz rezerwacji działały poprawnie,
• filtry i wyszukiwarka bloga omijają cache, bo każdy wynik jest inny,
• zalogowany administrator widzi stronę bez cache, czyli zawsze najnowszą wersję.

Pułapka pomiarowa, która kosztowała nas kwadrans

Po włączeniu cache pierwszy test z linii poleceń pokazał, że… nic się nie zmieniło. Strona dalej odpowiadała w ok. 0,23 s.

Przyczyna: użyta wtyczka cache podaje zapisaną wersję tylko wtedy, gdy zapytanie zawiera nagłówek Accept: text/html. Każda przeglądarka go wysyła, ale proste narzędzia testowe już nie. Po dodaniu nagłówka do testu wynik spadł do 0,07 s. Wniosek: testuj tak, jak zachowuje się prawdziwa przeglądarka, inaczej możesz „naprawiać” coś, co już działa.

Co sprawdziliśmy po zmianach

Przyspieszenie nic nie daje, jeśli coś się przy okazji zepsuje. Po wdrożeniu przeszliśmy listę kontrolną:

• Kalendarz rezerwacji pokazywał 17 wolnych dni. Terminy pobiera na żywo, więc zajęte godziny są zawsze aktualne.
• Formularz kontaktowy i zapis w stopce miały ważne zabezpieczenia (token formularza nie był zapisany w cache).
• Style WooCommerce zniknęły z kodu strony, a nasze ładowały się poprawnie.
• Kopia pliku konfiguracyjnego wp-config.php była zrobiona przed zmianą.

Wynik po kilku dniach

W listopadzie 2026 roku przepuściliśmy wszystkie 27 adresów z mapy strony przez nasz automatyczny audyt:

Pomiar	Wynik
Średni czas odpowiedzi, 27 podstron, pierwsze wejście	0,21 s
Najwolniejsza podstrona	0,27 s
Strona główna z cache	0,066 s
Strona bloga z cache	0,047 s
Różnica względem startu (strona główna)	ok. 6,8× szybciej

Średnia 0,21 s to wejścia, których nie było jeszcze w cache. Kolejne wejście na tę samą podstronę jest już w okolicach 0,05–0,07 s.

Ile to kosztowało?

Pozycja	Koszt
Wtyczka cache stron	0 zł (darmowa z wordpress.org)
Wtyczka Redis Object Cache	0 zł (darmowa)
Redis na serwerze	0 zł (był w pakiecie hostingu)
Zmiana pakietu hostingu	0 zł (niepotrzebna)

Całe przyspieszenie zrobiliśmy bez wydania złotówki na hosting. To częsty scenariusz: firma płaci za droższy pakiet, a problem leży w konfiguracji.

Lekcje, które stosujemy u klientów

1. Najpierw pomiar, potem decyzja. Bez liczb łatwo kupić niepotrzebny pakiet.
2. Jedna zmiana, jeden pomiar. Wiesz wtedy, co działa, a co jest placebo.
3. Wyłącz to, czego nie używasz. Jedna zbędna wtyczka kosztowała nas 0,2 s na każdym wejściu.
4. Cache musi omijać formularze. Inaczej klient zobaczy cudzą, zapisaną wersję albo formularz odrzuci wysyłkę.
5. Testuj jak przeglądarka. Nagłówki zapytania potrafią całkowicie zmienić wynik.

Więcej praktycznych sposobów znajdziesz w poradniku jak przyspieszyć stronę na WordPressie. Nasze podejście do lekkiego kodu opisujemy na stronie Nexo Core.

Najczęstsze pytania

Czy większy pakiet hostingu przyspieszy moją stronę?

Zwykle nie, jeśli strona nie ma cache i ma zbędne wtyczki. U nas zmiana konfiguracji dała 6× szybszy serwer bez zmiany pakietu. Większy pakiet ma sens dopiero wtedy, gdy pomiar pokazuje, że serwer jest naprawdę przeciążony.

Czy cache stron może zepsuć formularz?

Może, jeśli jest źle ustawiony. Strony z formularzami, rezerwacjami i koszykiem trzeba wyłączyć z cache albo podawać na żywo. Tak zrobiliśmy z kontaktem i kalendarzem na nexowork.pl.

Co to jest TTFB i jaki wynik jest dobry?

To czas do pierwszego bajtu odpowiedzi serwera. Google uznaje za dobre wartości poniżej ok. 0,8 s, ale dla strony firmowej z cache realne jest 0,05–0,2 s. Nasza strona główna ma ok. 0,07 s.

Czy dwie strony na jednym hostingu spowalniają się nawzajem?

Przy małym ruchu praktycznie nie. U nas sklep i strona firmowa miały prawie ten sam czas (0,47 s i 0,45 s), a przyczyną był brak cache, a nie sąsiad na serwerze.