Nginx dobrze sprawdza się jako serwer WWW dla WordPressa, ponieważ obsługuje wiele połączeń przy niewielkim zużyciu pamięci, szybko dostarcza pliki statyczne i może buforować odpowiedzi przed przekazaniem ich do PHP. Nie zastępuje jednak PHP-FPM – Nginx przyjmuje żądania i przekazuje kod dynamiczny do backendu, który go wykonuje.
Dlaczego Nginx wygrywa w WordPressie?
Nginx korzysta z architektury event-driven, czyli zdarzeniowego modelu obsługi połączeń. Zamiast tworzyć osobny proces lub wątek dla każdego żądania, niewielka liczba procesów roboczych reaguje na zdarzenia sieciowe i obsługuje wiele połączeń jednocześnie. Na systemach Linux służą do tego między innymi mechanizmy asynchronicznego wejścia i wyjścia, takie jak epoll.
Ma to znaczenie przy dużej liczbie równoczesnych odwiedzin. Nginx nie angażuje PHP ani bazy danych przy pobieraniu pliku CSS, JavaScriptu, obrazu czy fontu. Taki zasób może zostać odczytany bezpośrednio z systemu plików albo z pamięci podręcznej. Krótsza ścieżka obsługi zwykle ogranicza TTFB i pozostawia więcej pamięci dla PHP-FPM oraz bazy danych.
Apache również może wydajnie obsługiwać WordPressa, szczególnie po zastosowaniu nowoczesnego modelu MPM i właściwego backendu PHP. Różnica polega na tym, że Nginx od początku projektowano z myślą o dużej liczbie połączeń i roli reverse proxy. Tabela pokazuje najważniejsze konsekwencje obu podejść:
| Cecha | Nginx | Apache |
|---|---|---|
| Model obsługi połączeń | Event-driven, z niewielką liczbą procesów roboczych | Model procesowy lub wątkowy zależny od użytego MPM |
| Zużycie zasobów | Zwykle niskie przy dużej liczbie połączeń | Może rosnąć szybciej przy ciężkich konfiguracjach i dużym ruchu |
| Obsługa .htaccess | Brak. Reguły zapisuje się w konfiguracji serwera | Obsługuje .htaccess, co ułatwia konfigurację na hostingu współdzielonym |
| Skalowalność | Dobrze sprawdza się jako frontend, reverse proxy i load balancer | Jest elastyczny i ma szeroki wybór modułów |
| Typowe zastosowanie | VPS, serwery dedykowane, strony o dużym ruchu | Hosting współdzielony, aplikacje wymagające konfiguracji per katalog |
Brak pliku .htaccess nie jest wadą wydajnościową, ale wymaga dostępu do konfiguracji serwera. Na VPS administrator musi samodzielnie przenieść reguły przekierowań i zabezpieczeń do bloków server oraz location. To jeden z powodów, dla których konfiguracja Nginx wymaga większej kontroli nad środowiskiem.
Jak Nginx obsługuje żądanie WordPressa?
Nginx pełni rolę frontendu. Odbiera połączenie HTTP lub HTTPS, może zakończyć połączenie TLS, sprawdza pamięć podręczną i decyduje, czy odpowiedź da się zwrócić bez uruchamiania WordPressa. PHP-FPM jest osobnym backendem. To on uruchamia kod PHP, a następnie może pobrać dane z bazy i wygenerować odpowiedź.
Typowa ścieżka żądania wygląda następująco:
- Przeglądarka wysyła żądanie do Nginx. Serwer sprawdza domenę, protokół, nagłówki i reguły lokalizacji.
- Nginx szuka pliku statycznego, takiego jak obraz, arkusz CSS lub skrypt JavaScript. Jeśli plik istnieje, serwuje go bezpośrednio.
- Przy żądaniu strony WordPressa dyrektywa try_files sprawdza ścieżkę, a następnie kieruje żądanie do index.php.
- Dyrektywa fastcgi_pass przekazuje żądanie do PHP-FPM przez gniazdo Unix albo port TCP.
- PHP-FPM wykonuje WordPressa. Aplikacja może odczytać dane z bazy i zbudować dynamiczną odpowiedź HTML.
- Nginx odbiera odpowiedź, może ją zapisać w cache i zwraca ją przeglądarce.
Treść statyczna powstaje wcześniej i nie wymaga wykonywania kodu. Treść dynamiczna zależy od żądania, sesji, użytkownika, zapytań do bazy lub danych z formularza. Dlatego pliki CSS i obrazy można zwykle cache’ować długo, natomiast strony koszyka, panelu użytkownika i checkoutu wymagają wyjątków.
Buforowanie odpowiedzi ogranicza liczbę uruchomień PHP. Przy kolejnych żądaniach Nginx może zwrócić gotowy HTML bez ponownego ładowania WordPressa. Trzeba jednak pilnować spójności cache. Podwójne buforowanie, na przykład jednocześnie na serwerze i w niezależnej wtyczce WordPressa, może prowadzić do nieaktualnych treści, konfliktów i problemów z funkcjami zależnymi od sesji.
Kluczowe elementy konfiguracji Nginx dla WordPressa
Nie ma jednego bezpiecznego pliku konfiguracyjnego pasującego do każdego VPS-a. Inne będą ścieżki do katalogu strony, gniazdo PHP-FPM, ustawienia TLS, limity przesyłania i reguły cache. Zamiast kopiować cały plik, sprawdź jego najważniejsze elementy:
Podstawowa lista kontrolna konfiguracji powinna obejmować:
- Blok server – domenę, katalog główny strony, porty oraz przekierowanie z HTTP do HTTPS.
- try_files – obsługę bezpośrednich plików i przekierowanie nieznalezionych ścieżek do /index.php?$args, dzięki czemu działają przyjazne adresy WordPressa.
- fastcgi_pass – połączenie z właściwą wersją PHP-FPM przez gniazdo Unix lub port TCP.
- Blok location dla PHP – przekazywanie wyłącznie wymaganych plików PHP i blokadę wykonywania kodu w katalogach, które powinny zawierać tylko dane.
- Nagłówki bezpieczeństwa – między innymi X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security i, po przetestowaniu kompatybilności, Content-Security-Policy.
- Cache plików statycznych – dłuższe nagłówki wygasania dla wersjonowanych CSS, JavaScriptu, fontów i obrazów.
- Limity i logi – limit rozmiaru przesyłanych plików, kontrolę dostępu do plików ukrytych oraz logowanie błędów potrzebne podczas diagnostyki.
Najczęstszy błąd polega na pomyleniu konfiguracji Nginx z konfiguracją PHP-FPM. Nginx decyduje, dokąd przekazać żądanie, ale nie wykonuje kodu PHP. PHP-FPM zarządza pulą procesów PHP, a jej parametry, takie jak pm.max_children, trzeba dobrać do dostępnej pamięci i ciężaru aplikacji. Zbyt duża pula może wyczerpać RAM, a zbyt mała spowoduje kolejki żądań.
Warto też ograniczyć wykonywanie PHP do rzeczywiście potrzebnych lokalizacji. Reguły bezpieczeństwa powinny blokować dostęp do plików konfiguracyjnych, kopii zapasowych i katalogów z danymi. Nagłówek HSTS stosuj dopiero wtedy, gdy cała domena działa poprawnie przez HTTPS, także subdomeny objęte daną polityką.
Cache Nginx a wtyczki WordPressa
Cache dynamiczny przechowuje gotowe odpowiedzi HTML wygenerowane przez WordPressa. Dzięki temu kolejne żądania mogą zostać obsłużone bez uruchamiania PHP. Cache statyczny dotyczy CSS, JavaScriptu i fontów, a cache obrazów przechowuje zasoby graficzne. Każdy z tych mechanizmów działa na innej części ścieżki żądania.
Po zmianie motywu, treści, CSS, JavaScriptu lub obrazu trzeba odświeżyć właściwą warstwę cache. Podczas prac administracyjnych przydatny jest tryb developerski, który tymczasowo wstrzymuje buforowanie. Nie należy jednak zostawiać go włączonego na produkcji, ponieważ wyłącza korzyści z cache.
Wtyczka WordPressa może nadal minifikować lub łączyć pliki, ale jej cache stron powinien być wyłączony, gdy tę funkcję realizuje Nginx. Jedna warstwa odpowiedzialna za buforowanie dokumentów HTML upraszcza diagnostykę i zmniejsza ryzyko niespójnych odpowiedzi.
Co przynosi nowoczesny Nginx?
Informacje o funkcjach konkretnej gałęzi trzeba zawsze sprawdzić w dokumentacji i pakietach dostępnych dla używanego systemu. Sama numeracja wersji nie gwarantuje, że dana dyrektywa znajduje się w każdej kompilacji. Przy opisywanej w materiałach wersji Nginx 1.30 można wskazać kilka obszarów interesujących administratorów WordPressa:
- 103 Early Hints – serwer może wcześniej wysłać przeglądarce nagłówki Link dotyczące zasobów, które prawdopodobnie będą potrzebne. Przeglądarka zaczyna pobierać CSS, JavaScript lub font przed otrzymaniem pełnej odpowiedzi z PHP. Może to skrócić oczekiwanie na główny element strony, czyli LCP, ale wymaga poprawnego rozpoznania zasobów i wsparcia po stronie infrastruktury.
- HTTP/2 i HTTP/3 – HTTP/2 usprawnia obsługę wielu zasobów w jednym połączeniu, a HTTP/3 korzysta z QUIC. HTTP/3 wymaga odpowiedniej wersji Nginx, bibliotek TLS i konfiguracji, więc nie powinien być włączany wyłącznie przez zmianę jednego wpisu.
- HTTP/2 do upstreamów – w architekturach z wieloma backendami komunikacja Nginx z serwerem aplikacji może ograniczać opóźnienia, ale zysk zależy od backendu, sieci i sposobu obsługi protokołu. Nie należy zakładać automatycznej poprawy dla połączenia Nginx z PHP-FPM, które korzysta z FastCGI, a nie z HTTP.
- Encrypted Client Hello – ECH może ograniczyć ujawnianie nazwy domeny podczas negocjacji TLS. Jego zastosowanie zależy od obsługi przez biblioteki kryptograficzne, serwer i klientów.
- Sticky sessions – w środowisku z kilkoma backendami przypięcie klienta do konkretnego serwera może pomóc aplikacjom korzystającym z sesji, w tym niektórym instalacjom WooCommerce. Nie zastępuje to jednak współdzielonego magazynu sesji ani poprawnego wykluczenia koszyka i checkoutu z cache.
Kiedy Nginx jest dobrym wyborem dla WordPressa?
Nginx szczególnie dobrze pasuje do VPS-ów, serwerów dedykowanych i stron, na których występuje dużo jednoczesnych połączeń. Daje administratorowi kontrolę nad ruchem, cache, TLS i przekazywaniem żądań do PHP-FPM. Na hostingu współdzielonym Apache może być wygodniejszy, ponieważ użytkownik często może zmieniać reguły przez .htaccess bez dostępu do konfiguracji serwera.
Notatka ekspercka: sama zmiana Apache na Nginx nie rozwiąże problemów z wolnym WordPressem. TTFB zależy także od liczby procesów PHP-FPM, ciężaru motywu i wtyczek, zapytań do bazy, cache oraz konfiguracji systemu. Nginx tworzy wydajny frontend, ale dopiero spójna konfiguracja całego stosu daje stabilne rezultaty.
