LiteSpeed, Nginx i Apache: co realnie oznacza silnik serwera dla właściciela strony

Kupując hosting, rzadko zwracamy uwagę na to, jaki silnik serwera WWW obsługuje nasze pliki. A to właśnie ten komponent decyduje, czy strona odda gotową stronę w 30 milisekund, czy będzie się mozolić przez sekundę. Apache, Nginx i LiteSpeed to trzy najczęściej spotykane serwery na rynku hostingu współdzielonego. Różnią się architekturą, sposobem cache'owania i zgodnością z plikiem .htaccess — a te różnice realnie wpływają na to, jak szybko działa Twój WordPress i ile pracy będzie Cię kosztować konfiguracja.

Trzy różne filozofie obsługi ruchu

Apache to najstarszy i wciąż najpopularniejszy serwer. Działa w modelu „proces na połączenie" (prefork) lub w trybie wątkowym, a PHP najczęściej uruchamia przez mod_php. Jego zaletą jest elastyczność: czyta plik .htaccess w każdym katalogu, więc reguły przepisywania adresów czy przekierowania można zmieniać bez dostępu do konfiguracji serwera. Wadą jest zużycie pamięci — przy dużym ruchu każde połączenie to osobny proces, a tych szybko przybywa.

Nginx powstał właśnie po to, żeby rozwiązać „problem 10 tysięcy połączeń". Działa asynchronicznie, zdarzeniowo — jeden proces obsługuje tysiące połączeń bez tworzenia osobnego procesu na każde z nich. Dlatego świetnie radzi sobie z plikami statycznymi i wysokim ruchem przy niskim zużyciu RAM. Haczyk: Nginx nie czyta .htaccess. Reguły WordPressa dotyczące przyjaznych adresów trzeba przepisać na składnię rewrite w głównej konfiguracji, do której na hostingu współdzielonym zwykle nie masz dostępu.

LiteSpeed to komercyjny serwer (jest też darmowy OpenLiteSpeed), który łączy zalety obu. Ma zdarzeniową architekturę jak Nginx, ale natywnie czyta pliki .htaccess w stylu Apache — istniejąca strona WordPress działa bez tłumaczenia reguł. Jego główny atut to wbudowany cache LSCache.

Cache — tu rozjeżdżają się wyniki

To cache, a nie sam silnik, najczęściej decyduje o realnej szybkości. Każdy z serwerów podchodzi do tego inaczej:

Kluczowa różnica: LSCache jest zintegrowany na poziomie serwera, więc cache'owana strona odpowiada w okolicach 30–50 ms, nie wchodząc w ogóle do PHP. Apache z mod_php zdaje się niemal w całości na wtyczki cache działające w warstwie PHP, które z natury są wolniejsze. Nginx ma własny FastCGI cache, który serwuje gotowe strony z dysku z pominięciem PHP, ale wymaga ręcznej konfiguracji dla każdej strony, a unieważnianie cache trzeba obsłużyć skryptami lub modułem.

Co mówią benchmarki — i jak je czytać

Producent LiteSpeed publikuje testy, w których jego serwer bije Nginx nawet kilkunastokrotnie, a Apache osiemdziesięciokrotnie. Do takich liczb podchodź ostrożnie — to wyniki marketingowe z idealnego scenariusza, a większość rzetelnych porównań „X szybsze od Y" mieści się w przedziale 1,2–2x. Bardziej realistyczne pomiary pokazują dla WordPressa z włączonym cache około 5 100 żądań na sekundę dla LiteSpeed, około 2 200 dla Nginx z FastCGI cache i około 1 500 dla Apache z Varnishem.

Ważny niuans: dla niecache'owanej, dynamicznej treści wydajność Nginx z PHP-FPM jest porównywalna z LiteSpeed na LSAPI. Przewaga LiteSpeed bierze się głównie z tego, że jego natywny cache działa dobrze od razu, bez ręcznego strojenia. Jeśli Twoja strona to głównie dynamiczne, niecache'owalne zapytania (np. zalogowani użytkownicy, koszyk sklepu), różnica między silnikami topnieje, a większego znaczenia nabiera object cache po stronie serwera.

Co to znaczy dla właściciela strony

Dla zdecydowanej większości stron WordPress wybór silnika sprowadza się do trzech praktycznych konsekwencji:

• Mniej konfiguracji. Na LiteSpeed instalujesz wtyczkę LiteSpeed Cache i dostajesz cache strony, optymalizację obrazów i minifikację z jednego miejsca. Na czystym Nginx te same efekty wymagają współpracy hostingu.
• Zgodność reguł. Jeśli masz stronę z rozbudowanym .htaccess (przekierowania, ochrona katalogów, reguły bezpieczeństwa), Apache i LiteSpeed przeniosą ją bez zmian. Na Nginx trzeba je przetłumaczyć.
• Zachowanie pod obciążeniem. Przy nagłym skoku ruchu Apache z mod_php najszybciej wyczerpie pamięć i procesy. Nginx i LiteSpeed znoszą takie skoki spokojniej.

Nie oznacza to, że Apache jest „zły" — w połączeniu z PHP-FPM i dobrą wtyczką cache spokojnie obsłuży typową witrynę firmową. Silnik serwera to jeden z wielu czynników, obok jakości dysków NVMe, wersji PHP i sąsiadów na serwerze współdzielonym.

Sprawdź, jak zmierzyć realną szybkość hostingu

Najczęściej zadawane pytania

Czy LiteSpeed jest zawsze szybszy od Nginx?

Nie. Dla treści serwowanej z cache LiteSpeed ma przewagę dzięki LSCache działającemu od razu. Dla niecache'owanej, dynamicznej treści Nginx z PHP-FPM wypada porównywalnie. Różnica „od ręki" wynika głównie z gotowego, zintegrowanego cache.

Czy mogę zmienić silnik serwera na hostingu współdzielonym?

Zwykle nie — to decyzja hostingu. Wybierasz ją pośrednio, wybierając dostawcę. Część polskich hostingów stawia na LiteSpeed właśnie ze względu na LSCache i zgodność z .htaccess.

Czy moja wtyczka cache zadziała na każdym silniku?

Nie każda. LiteSpeed Cache wymaga serwera LiteSpeed/OpenLiteSpeed. Wtyczki typu W3 Total Cache czy WP Rocket działają niezależnie od silnika, ale nie wykorzystają natywnego cache serwerowego.

Czy warto dopłacać do hostingu z LiteSpeed?

Jeśli zależy Ci na szybkim cache bez konfiguracji i masz stronę na WordPressie, to wygodne rozwiązanie. Dla strony niecache'owalnej (rozbudowany sklep z wieloma zalogowanymi użytkownikami) ważniejszy będzie object cache i moc procesora niż sam silnik.

Podsumowanie

Silnik serwera to nie marketingowy detal — decyduje o tym, jak strona zachowuje się pod obciążeniem i ile pracy kosztuje konfiguracja. Apache daje maksymalną elastyczność i zgodność z .htaccess, ale jest pamięciożerny. Nginx to mistrz plików statycznych i wysokiego ruchu, lecz wymaga tłumaczenia reguł WordPressa. LiteSpeed łączy zdarzeniową architekturę ze zgodnością z Apache i wbudowanym cache, dlatego dla typowej strony WordPress jest najwygodniejszym wyborem „z pudełka". Najważniejsze: nie patrz na same liczby z benchmarków producenta, tylko na to, jaki cache realnie obsłuży Twój typ ruchu.

Źródła i dalsza lektura