Konfiguracja serwera dla szybkiej strony: cache, PHP, kompresja

Po stronie serwera strona przyspiesza głównie dzięki pięciu rzeczom: cache na serwerze (Redis lub Memcached), rozsądnym limitom PHP, kompresji GZIP lub Brotli, indeksom w bazie danych i właściwemu serwerowi WWW, a do tego monitoringowi, który pokaże, kiedy coś się pogarsza. Na hostingu współdzielonym część z tego zmienisz sam (wartości PHP, .htaccess, indeksy), resztę tylko na własnym serwerze. Mierz TTFB przed każdą zmianą i po niej, zamiast wierzyć obiecanym procentom.

Poniżej przy każdym ustawieniu znajdziesz polecenie do sprawdzenia, oficjalne wartości domyślne i tabelę tego, co może zmienić użytkownik hostingu współdzielonego.

Cache na poziomie serwera: gotowe odpowiedzi w pamięci

Cache to po prostu przechowywanie gotowych odpowiedzi. Zamiast generować tę samą stronę albo wykonywać to samo zapytanie dla każdego odwiedzającego, serwer trzyma wynik w pamięci. Przeglądarka i PHP też korzystają z cache, ale cache po stronie serwera działa głębiej.

Najpopularniejsze rozwiązania to Redis i Memcached: bufor między bazą danych a stroną, który podaje z RAM wyniki powtarzających się zapytań. Ile to przyspieszy Twoją stronę, trzeba zmierzyć: porównaj TTFB przed włączeniem cache i po nim za pomocą curl -o /dev/null -s -w "TTFB: %{time_starttransfer} s\n" https://your-site/. Przewodnik Google web.dev uznaje TTFB do 0,8 sekundy za dobry, a powyżej 1,8 sekundy za słaby (sprawdzono 30.10.2026).

Gdzie go włączyć, zależy od rodzaju hostingu. Na hostingu współdzielonym Redis lub Memcached są dostępne tylko wtedy, gdy dostawca oferuje je jako usługę; samodzielnie ich nie zainstalujesz. Na własnym serwerze instalujesz usługę, a potem podłączasz do niej aplikację (w WordPressie przez wtyczkę do cache obiektów).

• Redis: więcej struktur danych (listy, hashe, zbiory) i opcjonalny zapis na dysk
• Memcached: prosty, wielowątkowy cache klucz-wartość dla ciągów znaków i obiektów
• Czas życia cache (TTL): zależy od tego, jak często zmieniają się dane: rzadko zmieniana treść może być w cache godzinami, często zmieniane dane tylko minuty
• Limit pamięci: ustal, ile RAM może zająć cache (maxmemory w Redis, -m w Memcached)

Sprawdź obciążenie CPU przed włączeniem cache i po nim, w panelu hostingu lub poleceniem top na serwerze. Im więcej identycznych zapytań do bazy wykonuje strona, tym większy efekt.

Konfiguracja PHP: parametry, które mają znaczenie

Plik php.ini zawiera dziesiątki dyrektyw, ale pięć z nich powoduje większość problemów na stronach opartych na CMS:

Wartości domyślne i zasady rozmiarów (upload_max_filesize mniejszy niż post_max_size, post_max_size mniejszy niż memory_limit) pochodzą z dokumentacji PHP (sprawdzono 30.10.2026). Kolumna z przykładem to wskazówka, nie norma: ustaw tyle, ile strona naprawdę potrzebuje i na ile pozwala Twój pakiet. Polecenie php -i | grep -E "memory_limit|upload_max_filesize|post_max_size" albo funkcja phpinfo() pokazuje bieżące wartości. Jeśli błędy już się pojawiają, zajrzyj do naszych poradników o błędzie Allowed memory size exhausted i o tym, jak zwiększyć upload_max_filesize.

Na hostingu współdzielonym główny php.ini należy do dostawcy. Wartości dla pojedynczej strony zmienia się zwykle w panelu, w pliku .user.ini w katalogu głównym strony (gdy PHP działa przez FastCGI lub PHP-FPM, zob. stronę dokumentacji PHP o .user.ini) albo przez php_value w .htaccess (gdy PHP działa jako moduł Apache), i to tylko w granicach ustalonych przez dostawcę. memory_limit i max_execution_time można też ustawić w kodzie funkcją ini_set(), a upload_max_filesize, post_max_size i max_input_vars już nie (tryb INI_PERDIR). PHP domyślnie odczytuje .user.ini ponownie co 300 sekund, więc zmiana może zacząć działać dopiero po 5 minutach. Na własnym serwerze edytujesz php.ini lub pulę PHP-FPM i restartujesz PHP-FPM.

Ważne: nie zmieniaj wartości na ślepo. Zachowaj kopię pierwotnych ustawień: jedna błędna wartość może położyć całą stronę.

Kompresja: lżejsze pliki tekstowe

Strona wysyła do przeglądarki HTML, CSS i JavaScript. Tekst dobrze się kompresuje: serwer zmniejsza pliki przed wysłaniem, a przeglądarka je rozpakowuje, czego użytkownik nawet nie zauważa. To kompresja GZIP lub Brotli.

Jeśli stronę obsługuje Apache z mod_deflate, wystarczy kilka linii w .htaccess:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
</IfModule>

Jeśli odpowiedzi wysyła Nginx (samodzielnie lub jako proxy przed Apache), .htaccess nie steruje kompresją: ustawia się ją w konfiguracji Nginx. Według dokumentacji nginx.org dyrektywa gzip jest domyślnie wyłączona, a Brotli nie należy do standardowych modułów Nginx. Na hostingu współdzielonym to zadanie dostawcy, na własnym serwerze włączasz to sam.

O ile zmniejszy się transfer, zależy od Twoich plików, więc sprawdź to sam. Polecenie curl -sI -H "Accept-Encoding: gzip, br" https://your-site/ | grep -i content-encoding powinno zwrócić gzip lub br. Jeśli tej linii brak, kompresja nie działa.

gtmetrix.com i pagespeed.web.dev również pokazują rozmiary plików i wskazują zasoby bez kompresji.

Optymalizacja bazy danych: indeksy i wolne zapytania

Baza danych to serce każdej dynamicznej strony i często właśnie ona ją spowalnia. Typowy problem to brakujące indeksy, czyli struktury pozwalające znaleźć wiersze bez czytania całej tabeli.

Wyobraź sobie bibliotekę bez katalogu: książka tam jest, ale trzeba przejrzeć każdą półkę. Z indeksem baza danych wie dokładnie, gdzie szukać.

Co zrobić:

1. Otwórz phpMyAdmin lub inne narzędzie do zarządzania bazą danych.
2. Sprawdź, czy kolumny często używane w wyszukiwaniu i złączeniach (ID, user_id, status) mają indeksy.
3. Po masowym usuwaniu danych uruchom OPTIMIZE TABLE table_name;. Dla tabel InnoDB MySQL odtwarza tabelę i aktualizuje jej statystyki (ALTER TABLE … FORCE); dokumentacja MySQL odradza robienie tego rutynowo.
4. Usuń tabele pozostałe po odinstalowanych wtyczkach i starych wersjach (po wykonaniu kopii zapasowej).
5. Włącz dziennik wolnych zapytań (slow query log) i zobacz, które zapytania trwają za długo. Jest domyślnie wyłączony, long_query_time wynosi 10 sekund, a włączenie go w trakcie działania wymaga uprawnienia SYSTEM_VARIABLES_ADMIN. Dlatego na hostingu współdzielonym może go włączyć tylko dostawca; na własnym serwerze ustawiasz go w konfiguracji MySQL.

Im większa tabela, tym bardziej szkodzi brak indeksu: zapytanie, które na małej bazie wykonywało się błyskawicznie, na dużej spowalnia całą stronę.

Nginx czy Apache: który serwer WWW wybrać

Apache to starszy, uniwersalny serwer z elastyczną konfiguracją dla katalogów (.htaccess). Nginx jest młodszy, działa w oparciu o zdarzenia i serwuje pliki statyczne przy mniejszym zużyciu pamięci, ale nie ma .htaccess i konfiguruje się go na serwerze.

W skrócie:

• Apache: z MPM prefork jeden proces na połączenie; domyślny MPM event pracuje na wątkach (dokumentacja Apache); elastyczny i dobry do złożonych konfiguracji
• Nginx: architektura asynchroniczna: jeden proces roboczy obsługuje tysiące połączeń, szybki przy plikach statycznych
• Wybór zależy od obciążenia: mały blog dobrze działa na Apache, a przy wielu jednoczesnych połączeniach Nginx oszczędniej gospodaruje pamięcią. Częstym kompromisem jest Nginx przed Apache.

Jeśli przechodzisz całkowicie na Nginx, przygotuj się na przepisanie reguł mod_rewrite na składnię Nginx. To nic trudnego, ale wymaga czasu.

Na hostingu współdzielonym serwer WWW wybiera dostawca; Ty konfigurujesz tylko to, na co pozwalają .htaccess i panel. Wybór między Nginx a Apache to decyzja dla własnego serwera.

Monitoring: wiedz o problemach, zanim napiszą klienci

Konfiguracji serwera nie robi się raz na zawsze. Po każdej zmianie, a potem regularnie, obserwuj te wskaźniki:

• CPU i RAM: jeśli CPU długo dobija do limitu pakietu, strona zwalnia i może zwracać błąd 504 Gateway Timeout
• Miejsce na dysku: gdy dysk jest prawie pełny, baza danych może nie zapisać nowych danych
• Zapytania do bazy: śledź wolne zapytania w logach
• Dostępność: zewnętrzna usługa, np. Pingdom, powiadomi Cię, gdy strona padnie w nocy

Panele takie jak cPanel i Plesk pokazują zużycie dysku i transferu, a Google Cloud Monitoring i Datadog sprawdzą się w większych projektach. Jakie wskaźniki śledzić i jak ustawić alerty, opisujemy w poradniku o monitoringu serwera hostingu.

Najważniejsze: optymalizacja to ciągła praca. Zmień jedną rzecz, zmierz efekt i dopiero wtedy zrób kolejny krok.

Co zmienisz na hostingu współdzielonym, a co tylko na własnym serwerze

Ta tabela odpowiada na najczęstsze pytanie. Hosting współdzielony oznacza, że serwerem zarządza dostawca. Własny serwer (VPS lub dedykowany) oznacza, że wszystkim zarządzasz sam.

Pakiety hostingowe RichHost działają na dyskach NVMe z własnym panelem sterowania z asystentem AI, na serwerach w Europie i USA, od 8 USD miesięcznie. Jeśli Twoja strona stoi na WordPressie, przeczytaj też, jak przyspieszyć WordPress.

FAQ

Jakie są domyślne wartości PHP dla pamięci i przesyłania plików?

Według dokumentacji PHP: memory_limit 128M, max_execution_time 30 sekund, upload_max_filesize 2M, post_max_size 8M, max_input_vars 1000. Twój dostawca może stosować inne wartości; phpinfo() pokaże rzeczywiste.

Czy mogę włączyć Redis na hostingu współdzielonym?

Tylko jeśli dostawca oferuje Redis lub Memcached jako usługę. W przeciwnym razie użyj cache stron na poziomie CMS albo przejdź na własny serwer, na którym sam zainstalujesz Redis.

Czy warto regularnie uruchamiać OPTIMIZE TABLE?

Nie. W InnoDB polecenie odtwarza tabelę, a dokumentacja MySQL zaleca je tylko przy realnie zmarnowanym miejscu, np. po usunięciu wielu wierszy.

Jak sprawdzić, czy kompresja działa?

Uruchom polecenie curl z sekcji o kompresji: nagłówek content-encoding musi pokazać gzip lub br.

Jaki TTFB jest dobry?

Przewodnik Google web.dev uznaje 0,8 sekundy lub mniej za dobry wynik, a ponad 1,8 sekundy za słaby. Mierz kilka razy i z regionu, w którym są Twoi odwiedzający.