Коротко
- Для більшості PHP-сайтів вибір Nginx проти Apache рухає продуктивність менше, ніж шари навколо: PHP-FPM, OPcache і повносторінковий кеш.
- Справжня архітектурна відмінність — це конкурентність. Цикл подій Nginx дешево тримає тисячі неактивних з’єднань; процесно-потокова модель Apache за того ж навантаження витрачає більше пам’яті.
- Запускайте PHP через PHP-FPM на будь-якому сервері.
mod_phpприв’язує інтерпретатор PHP до кожного процесу Apache і це найбільша legacy-помилка продуктивності. - «Nginx перед Apache» — реальний патерн, а не відмовка: Nginx термінує TLS і віддає статику, Apache зберігає сумісність із
.htaccessдля застосунку.
Раз на кілька місяців мене питають, чи не варто «перейти на Nginx, щоб сайт став швидшим», і чесна відповідь зазвичай — ні: не тому, що Nginx повільний, а тому, що вебсервер рідко там, куди йде їхній час. Я бачив, як сайт зрізав час відповіді вдвічі, увімкнувши OPcache і повносторінковий кеш, лишившись на тому самому Apache, з якого починав. Серверне ПЗ ніколи не було вузьким місцем.
Тож це не стаття «хто переможе», бо в такій постановці питання майже не важливе. Вона про те, звідки насправді береться продуктивність вебсервера, що реально різниться між Nginx і Apache і як обирати, не перетворюючи це на рішення про бренд.
Відмінність, яка реальна: конкурентність
Apache і Nginx обробляють з’єднання принципово різними моделями, і це єдине місце, де вибір має реальні наслідки для продуктивності.
Apache в типових конфігураціях відображає з’єднання на процеси чи потоки. Під навантаженням із безліччю повільних чи неактивних клієнтів — мобільні мережі, keep-alive-з’єднання, довгі завантаження — кожен займає воркер, і споживання пам’яті зростає з конкурентністю. Nginx використовує подієво-орієнтований цикл: невеликий фіксований набір воркер-процесів мультиплексує тисячі з’єднань, а неактивні майже нічого не коштують. Тому Nginx сяє як зворотний проксі й за високої конкурентності, і тому став дефолтом перед API та CDN.
Для сайту, що обслуговує кілька сотень одночасних користувачів, обидва комфортно швидкі. Відмінність проявляється на хвості — висока конкурентність, багато неактивних з’єднань — а не в медіанному запиті.
Шар, який важливіший: як працює PHP
mod_php — це legacy-помилка
Старий дефолт Apache вбудовує інтерпретатор PHP у кожен процес Apache, тож кожен несе пам’ять PHP навіть при віддачі статичного файлу. Запускайте PHP через PHP-FPM — окремий, налаштовуваний пул PHP-воркерів, з яким і Apache, і Nginx спілкуються по FastCGI. Одна ця зміна зазвичай дає пропускній здатності більше, ніж зміна вебсервера.
Коли PHP-FPM на місці, важелі, що реально рухають продуктивність, здебільшого взагалі не вебсервер:
OPcache
Кешує скомпільований байткод PHP у пам’яті. Часто найбільший одиничний виграш, і часто вимкнений.
Повносторінковий кеш
Віддача закешованої HTML-відповіді повністю минає PHP і базу — найбільший виграш для контентних сайтів.
Об’єктний кеш
Redis або Memcached зрізають повторні запити до бази на динамічних сторінках.
Тюнінг пулу FPM
Підберіть число воркерів під вашу RAM, щоб не голодувати й не свопитися під навантаженням.
Для WordPress-сайту зокрема повносторінковий кеш (FastCGI-кеш на Nginx або плагін кешування на кшталт LiteSpeed, чи за Varnish) — це різниця між перезбіркою кожної сторінки з PHP і бази на кожен хіт і віддачею статичного файлу за мікросекунди. Це рішення затьмарює вибір Nginx проти Apache.
Де Apache досі виправдовує місце: .htaccess
Підиректорні файли .htaccess Apache — це водночас його суперсила сумісності й тиха ціна продуктивності. Вони дозволяють плагіну, фреймворку чи користувачу шаред-хостингу міняти правила переписування й доступу, не чіпаючи центральний конфіг — саме тому так багато екосистеми WordPress і legacy-PHP їх передбачає. Ціна в тому, що Apache перевіряє наявність файлів .htaccess на кожен запит уздовж шляху. У Nginx еквівалента немає; його правила живуть в одному центральному конфігу, що швидше, але означає, що зміни вимагають перезавантаження й доступу до сервера.
Якщо ваш застосунок чи хостинг залежить від .htaccess, ця залежність — реальна причина лишити Apache в стеку, а не провал модернізації.
Nginx перед Apache: прагматичний гібрид
Обирати не обов’язково. Поширена продакшен-форма ставить Nginx на край, а Apache за ним: Nginx термінує TLS, віддає статичні ассети напряму й зворотним проксі шле динамічні запити Apache, який запускає застосунок із недоторканою сумісністю .htaccess. Ви отримуєте обробку з’єднань і швидкість статики Nginx спереду і сумісність екосистеми Apache ззаду. Багато managed-хостингів WordPress запускають щось подібне, не рекламуючи цього.
Практичний спосіб обрати
Зміна сервера заради швидкості
Перед зміною вебсервера переконайтеся, що OPcache, повносторінковий кеш і PHP-FPM на місці. Зазвичай вони важливіші.
Запуск mod_php у 2026
Вбудовування PHP у процеси Apache марнує пам’ять на кожен запит. Переходьте на PHP-FPM незалежно від того, який сервер лишаєте.
Немає повносторінкового кешу на контентному сайті
Перезбірка кожної сторінки з PHP і бази на кожен хіт — найчастіше усувне вузьке місце.
Тюнінг не того шару
Ручний тюнінг директив воркерів, поки база робить неіндексовані повні скани, оптимізує частину, яка не була повільною.
Якщо коротко: беріть Nginx, коли навантаження висококонкурентне, проксі-орієнтоване чи API-driven, і коли ви керуєте конфігом сервера. Лишайте Apache, коли залежите від .htaccess, працюєте на шаред-хостингу або ваша команда вже добре ним оперує. А потім витрачайте реальні сили на кешування, PHP-FPM і базу — ось де виграші.
FAQ
- Nginx швидший за Apache?
- Для висококонкурентних і проксі-навантажень подієва модель Nginx витрачає менше пам’яті й ефективніше тримає неактивні з’єднання. Для типового трафіку обидва швидкі, а OPcache, повносторінковий кеш і PHP-FPM впливають на реальну продуктивність куди сильніше, ніж вибір між ними.
- Використовувати mod_php чи PHP-FPM?
- PHP-FPM майже в усіх випадках. Він запускає PHP в окремому, налаштовуваному пулі воркерів, який і Apache, і Nginx використовують по FastCGI, замість вбудовування інтерпретатора в кожен процес вебсервера. Перехід із
mod_phpна PHP-FPM зазвичай покращує пропускну здатність сильніше, ніж зміна вебсервера. - Який найбільший виграш продуктивності для WordPress-сайту?
- Повносторінковий кеш. Віддача закешованої HTML-відповіді повністю минає PHP і базу, перетворюючи багатозапитну збірку сторінки на читання статичного файлу. Після цього OPcache і об’єктний кеш Redis — наступні найбільші виграші, і всі вони не залежать від того, Nginx у вас чи Apache.
- Чи можна запускати Nginx і Apache разом?
- Так, і це поширений патерн. Nginx стоїть на краю, термінуючи TLS і віддаючи статику, потім зворотним проксі шле динамічні запити Apache, який запускає застосунок і зберігає підтримку
.htaccess. Ви отримуєте обробку з’єднань Nginx із сумісністю Apache.
Схожі статті
- Docker і WordPress: як контейнери спрощують розробку — спрощує бенчмаркінг цих серверних варіантів у відтворюваному стеку.
- WordPress Bedrock з Docker локально і чистим PHP у продакшені — про повносторінковий кеш LiteSpeed і деплой на реальному шаред-хостингу.
