Strona na WordPress zwalnia przy 50 odwiedzających, choć serwer nie jest obciążony? Znajoma sytuacja dla tych, którzy wynajęli tani hosting na Apache i nie zagłębiali się w stos technologiczny. Przyczyna jest prawie zawsze ta sama: serwer WWW nie radzi sobie z jednoczesnymi połączeniami.

Zmiana hostingu rozwiązuje problem. Ale ważniejsze jest zrozumienie, jaki serwer WWW stoi za daną taryfą. Od tego zależy, czy strona wytrzyma nagły wzrost ruchu, czy padnie po udostępnieniu linku na Telegramie.

Poniżej, bez lania wody: jak działają Apache i nginx, jaka jest różnica w praktyce i dlaczego nginx stał się standardem dla hostingu WordPress w 2026 roku.

💡 Szybki przegląd:

• Serwer WWW przyjmuje żądania HTTP od przeglądarki i zwraca odpowiedź: statykę odsyła sam, dynamikę przetwarza przez połączenie z PHP.
• Apache tworzy proces dla każdego połączenia, jest elastyczny, ale pod obciążeniem kończy się pamięć. Nginx wykorzystuje architekturę zdarzeniową i utrzymuje tysiące połączeń w jednym procesie.
• Dla WordPressa krytyczne są jednoczesne połączenia, praca z pamięcią podręczną i zużycie pamięci. Nginx wygrywa we wszystkich trzech parametrach.
• Hosting na nginx daje szybszą stronę przy tej samej taryfie. Jeśli chcą Państwo sprawdzić swój, proszę zapytać dział wsparcia technicznego o stos serwera WWW.

Czym jest serwer WWW i do czego służy WordPressowi

Serwer WWW to program, który przyjmuje żądania HTTP i zwraca odpowiedź. Gdy odwiedzający otwiera stronę, przeglądarka łączy się z serwerem, a ten odsyła stronę HTML. Dla WordPressa schemat jest nieco bardziej złożony: procesor PHP składa stronę z szablonu i bazy danych, a serwer WWW przekazuje wynik użytkownikowi.

Na rynku dominują dwa serwery WWW o otwartym kodzie źródłowym: Apache oraz nginx. Według danych W3Techs z czerwca 2026, nginx obsługuje 31,9% stron ze znanym serwerem WWW, Apache, 23,9%. Razem pokrywają ponad połowę internetu. IIS od Microsoftu jest trzeci, ze znacznym opóźnieniem.

Różnica między nimi nie jest kosmetyczna. Ma bezpośredni wpływ na to, ilu odwiedzających jednocześnie wytrzyma strona i jak szybko się otworzy.

Apache: sprawdzony, ale ciężki

Apache HTTP Server pojawił się w 1995 roku i przez dekady był standardem. Leży u podstaw cPanel, najpopularniejszego panelu zarządzania hostingiem. Większość hostingów współdzielonych nadal używa Apache po prostu dlatego, że „tak się historycznie przyjęło".

Mocną stroną Apache jest modułowość. Można dynamicznie ładować moduły i zmieniać zachowanie serwera przez .htaccess bezpośrednio w folderze strony, bez restartu. Dla programisty jest to wygodne: włączył przekierowanie, zablokował dostęp do pliku, skonfigurował buforowanie, wszystko za pomocą reguł w pliku tekstowym.

Ale ta elastyczność ma swoją cenę. Apache tworzy osobny wątek lub proces dla każdego połączenia. Przy 100 jednoczesnych odwiedzających, 100 procesów. Przy 500 kończy się pamięć, serwer odpowiada z opóźnieniem lub zrywa część połączeń. Nazywa się to problemem C10K, czyli 10 000 jednoczesnych połączeń, którego Apache w standardowym trybie nie udźwignie.

W praktyce strona na Apache bez dodatkowego buforowania zaczyna zauważalnie zwalniać już przy kilkudziesięciu jednoczesnych użytkownikach. WordPress ze swoją dynamiczną naturą tylko pogarsza sytuację: każde żądanie uruchamia PHP, ten sięga do bazy, a proces wisi aż do pełnego wykonania.

Nginx: podejście zdarzeniowe i dlaczego jest szybszy

Nginx napisał Igor Sysojew w 2002 roku właśnie po to, by rozwiązać problem C10K. Pierwsze publiczne wydanie ukazało się w 2004 roku. W przeciwieństwie do Apache, nginx jest zbudowany na architekturze zdarzeniowej: jeden proces roboczy obsługuje tysiące połączeń, nie tworząc dla każdego osobnego wątku.

Jak to działa. Nginx nasłuchuje zdarzeń na gniazdach i reaguje tylko wtedy, gdy są dane do przetworzenia. Przyszło nowe żądanie, przetworzył. Klient wolno odbiera odpowiedź, nie blokujemy się, przełączamy na innego. Właśnie asynchroniczność pozwala nginx utrzymywać więcej połączeń przy mniejszym zużyciu pamięci.

Nginx ma ograniczenie: nie potrafi samodzielnie przetwarzać dynamicznej treści. Potrzebuje zewnętrznego procesora, PHP-FPM, FastCGI lub proxy do tego samego Apache. Ale w praktyce to nie minus, a plus: dynamika jest odizolowana, nie przeszkadza w odsyłaniu statyki, a każdy komponent można konfigurować niezależnie.

Historycznie głównym problemem nginx była dokumentacja. Sysojew pisał ją po rosyjsku i wczesne wersje cierpiały z powodu skąpych opisów. Obecnie dokumentacja jest przetłumaczona, społeczność ogromna, a dla WordPressa istnieją gotowe konfiguracje na każdy scenariusz. Ten sam DigitalOcean prowadzi szczegółowe poradniki dotyczące połączenia nginx + WordPress.

Kolejna różnica: nginx nie potrafi dynamicznie ładować modułów i nie obsługuje .htaccess. Wszystkie ustawienia znajdują się w plikach konfiguracyjnych serwera, a do ich zastosowania potrzebny jest reload. Jest to mniej wygodne przy codziennym poprawianiu drobiazgów, ale daje przewidywalność: serwer nie skanuje katalogów w locie w poszukiwaniu reguł i nie marnuje na to czasu procesora.

Sześć powodów, by wybrać nginx dla WordPressa

Konkretne argumenty, dlaczego nginx jest lepszy od Apache dla strony na WordPressie.

Prosta instalacja

Nginx instaluje się jedną komendą na dowolnej dystrybucji Linuksa:

1
apt install nginx

Lub dla RHEL/CentOS:

1
yum install nginx

Po instalacji nginx od razu działa jako usługa. Dla WordPressa trzeba będzie dodać PHP-FPM i minimalną konfigurację, typowy plik konfiguracyjny z 20 linijek, który nie zmienia się od projektu do projektu.

Tryb proxy dla Apache

Jeśli strona już działa na Apache i przeprowadzka jest straszna, nginx można postawić przed nim jako reverse proxy. Cała statyka idzie przez nginx, a żądania PHP są przez niego przekierowywane do Apache. Wzrost wydajności widać od razu, a .htaccess i znana struktura modułowa nadal działają.

Na schemacie wygląda to tak: przeglądarka → nginx (statyka + cache) → Apache (tylko PHP). Według benchmarków, nawet takie połączenie daje dwukrotny zysk w liczbie przetwarzanych żądań na sekundę.

Wbudowana pamięć podręczna

Nginx ma fastcgi_cache, który buforuje odpowiedzi PHP-FPM i odsyła je jako statykę. Dla WordPressa jest to radykalna zmiana: strona złożona raz, leci z cache do wszystkich kolejnych odwiedzających bez uruchamiania PHP i zapytań do bazy.

W praktyce dobrze skonfigurowany fastcgi_cache obniża czas odpowiedzi serwera z 600-800 ms do 20-40 ms. Żadna zewnętrzna wtyczka buforująca dla WordPressa nie daje takiego efektu na poziomie serwera.

Szybkość odsyłania statyki

Obrazy, CSS, JavaScript, czcionki, wszystko, co nie wymaga PHP, nginx rozsyła bezpośrednio, bez dodatkowych warstw. Jedna dyrektywa try_files zastępuje kilkanaście reguł Apache. Rezultat: pliki statyczne są odsyłane w milisekundach, a procesy robocze PHP nie są zajęte zbędną pracą.

Więcej połączeń przy mniejszym zużyciu

Nginx utrzymuje około cztery razy więcej jednoczesnych połączeń niż Apache przy porównywalnym zużyciu pamięci. To nie abstrakcyjna liczba, dane W3Techs pokazują, że wśród stron o wysokim ruchu nginx ma udział ponad 60%.

Dwie praktyczne korzyści dla właściciela strony na WordPressie:

• Przy wzroście liczby odwiedzających nie trzeba od razu przechodzić na droższą taryfę.
• Serwer zużywa mniej CPU i RAM, dostawca hostingu może utrzymywać niższą cenę lub dawać więcej zasobów za te same pieniądze.

Lekkość

Nginx jest zaprojektowany tak, aby zużywać minimum zasobów. Proces roboczy nasłuchuje zdarzeń i aktywuje się tylko w razie potrzeby. Argument on demand w konfiguracji pozwala całkowicie usuwać nieużywane procesy robocze z pamięci.

Apache próbował wdrożyć tryb zdarzeniowy przez mpm_event, ale jest to nadbudowa nad architekturą procesową, a nie przeprojektowanie. Wydajność mpm_event nie dorównuje nginx właśnie dlatego, że Apache jest od podstaw zbudowany inaczej.

Równoważenie obciążenia

Nginx potrafi rozdzielać żądania między kilka serwerów backendowych. Dla wysoko obciążonego projektu WordPress oznacza to: można uruchomić dwa-trzy serwery aplikacji, postawić przed nimi nginx jako load balancer, a strona utrzyma dziesiątki tysięcy jednoczesnych odwiedzających. Duże hostingi WordPress, WP Engine, Kinsta, wykorzystują właśnie taką architekturę.

⁉️🤔 Często zadawane pytania

Czy koniecznie trzeba przechodzić na nginx, jeśli strona na Apache działa normalnie?

Jeśli strona jest stabilna przy obecnym ruchu, pilna wymiana nie jest potrzebna. Ale przy planach rozwoju, uruchomieniu reklamy lub sezonowych skokach, proszę postawić nginx jako proxy przed Apache. Da to zapas wydajności bez migracji.

Czy to prawda, że nginx trudniej skonfigurować dla WordPressa?

Podstawowa konfiguracja składa się z jednego pliku konfiguracyjnego i typowego zestawu reguł dla przyjaznych linków bezpośrednich. DigitalOcean i WordPress.org publikują sprawdzone pliki konfiguracyjne. Różnica w stosunku do Apache: zamiast edycji .htaccess edytuje się nginx.conf i wykonuje nginx -s reload. Na starcie jest to trochę niecodzienne, ale plik konfiguracyjny czyta się łatwiej.

Jaki hosting wybrać: od razu z nginx czy dowolny z obsługą nginx jako proxy?

Jeśli biorą Państwo zarządzany WordPress, proszę sprawdzić, czy nginx jest w stosie jako główny serwer WWW. WP Engine, Kinsta, Rocket.net działają właśnie tak. Jeśli VPS, proszę postawić nginx + PHP-FPM, to standard dla WordPressa w 2026 roku. Hosting współdzielony z nginx jako proxy przed Apache to opcja kompromisowa, ale wciąż korzystna.

Czy tracę coś ważnego przy przejściu z Apache na nginx?

Tracą Państwo .htaccess. Wszystko, co było przez niego edytowane (przekierowania, blokady dostępu, buforowanie), przenosi się do konfiguracji nginx, jednorazowo i centralnie. Wtyczki WordPress, które polegają na .htaccess (na przykład niektóre wtyczki bezpieczeństwa), mogą wymagać ręcznej adaptacji reguł. Ale duże wtyczki od dawna są dostarczane z plikami konfiguracyjnymi dla nginx.

Czy Apache ma przyszłość dla WordPressa?

Apache nigdzie nie zniknie, zbyt wiele hostingów jest na nim zbudowanych. Ale trend jest jednoznaczny: udział Apache spada, udział nginx rośnie. Nowe projekty WordPress i hostingi są domyślnie uruchamiane na nginx. Jeśli zaczynają Państwo od zera, proszę zacząć od nginx.

Nginx czy Apache: co wybrać w 2026 roku

Krótko mówiąc: dla WordPressa proszę wybrać nginx. Nie dlatego, że Apache jest zły, ale dlatego, że nginx rozwiązuje konkretny problem, utrzymuje wielu odwiedzających na skromnym sprzęcie i szybciej rozsyła treści.

Schemat działania dla trzech typowych sytuacji:

• Uruchamiają Państwo nową stronę. Proszę wziąć hosting z nginx w stosie lub skonfigurować VPS na połączeniu nginx + PHP-FPM. Szablonowych plików konfiguracyjnych dla WordPressa są dziesiątki, nie ma trudności z konfiguracją.
• Strona już jest na Apache i zwalnia. Proszę postawić nginx jako reverse proxy. To godzina pracy administratora systemu i natychmiastowy wzrost wydajności.
• Strona na Apache, wszystko śmiga. Proszę żyć spokojnie. Ale proszę mieć z tyłu głowy, że przy wzroście ruchu nginx da większy zapas niż próba wyciśnięcia czegoś jeszcze z Apache.

Proszę sprawdzić obecny stos: proszę wejść do konsoli hostingu lub zapytać dział wsparcia technicznego. Jeśli usłyszą Państwo „nginx", dobrze. Jeśli „Apache", teraz wiedzą już Państwo, co z tym zrobić.