LiteSpeed, Nginx или Apache: что выбрать под сайт малого бизнеса

Веб-сервер редко бывает узким местом маленького сайта. На закэшированной странице разница между Apache и LiteSpeed заметна, но без кэша все три дают близкие цифры, потому что время тратит PHP и база. Менять хостинг ради сервера стоит в последнюю очередь.

Раз в пару месяцев кто-то из клиентов присылает скриншот с форума, где написано «переходите на Nginx, ускорите сайт в три раза», и спрашивает, надо ли переезжать. Короткий ответ: почти никогда веб-сервер не является узким местом маленького сайта на WordPress или Битриксе. Длинный ответ на то, чем реально отличаются Apache, Nginx и LiteSpeed, где выигрыш есть, а где это просто повод для смены хостинга без ускорения, разберу ниже.

Как узнать за минуту, какой сервер отдаёт ваш сайт

Прежде чем спорить, что лучше, полезно узнать, что вообще стоит у вас. Проще всего посмотреть заголовок ответа сервера.

curl -I https://ваш-сайт.ru

В ответе будет строка Server, например:

Server: nginx
Server: Apache
Server: LiteSpeed

Часть хостингов из соображений безопасности скрывает эту информацию или подменяет заголовок, тогда точный ответ даст только тикет в поддержку хостера. Ещё один косвенный признак: если в панели управления сайтом есть отдельный раздел «LiteSpeed Cache» или одноимённый плагин работает без ошибок «сервер не поддерживается», значит, стоит именно LiteSpeed. Если в панели есть настройка nginx.conf или «прокси перед Apache», у вас связка из двух серверов сразу, об этом ниже.

Apache: гибкость через .htaccess и цена этой гибкости

Apache older, старый по историческим меркам сервер (с 1995 года), но именно он до сих пор стоит по умолчанию на большинстве бюджетных shared-хостингов в России. Его главная особенность для владельца сайта: файл .htaccess. Через него можно прямо из FTP или файлового менеджера хостинга менять правила редиректов, блокировать ботов, включать сжатие, задавать заголовки кэша, без доступа к конфигурации всего сервера.

Это удобно ровно потому, что не требует прав администратора сервера. Обратная сторона: Apache читает .htaccess при каждом запросе к каждой директории на пути от корня до файла, и если структура сайта глубокая, а .htaccess разросся правилами, это добавляет заметную накладную нагрузку. На типичном сайте с 20-40 правилами в .htaccess разница обычно не критична, но на сайте с раздутым файлом в 200+ строк я видел падение TTFB на десятки миллисекунд just из-за парсинга правил на каждый запрос.

Apache также тяжелее держит параллельные соединения при высокой нагрузке: классическая модель prefork создаёт отдельный процесс на каждое соединение, что съедает память быстрее, чем событийная модель Nginx. На сайте с трафиком до пары тысяч визитов в день разница почти не заметна, на сайте с наплывом трафика от рекламной кампании или в час пик магазина она становится ощутимой.

Nginx: скорость на статике и жизнь без .htaccess

Nginx проектировался изначально под высокие нагрузки и статические файлы. Событийная модель обработки соединений позволяет держать тысячи одновременных подключений при куда меньшем расходе памяти, чем у Apache. На отдаче картинок, CSS, JS и другой статики Nginx стабильно быстрее, это не маркетинг, а измеримый факт по любому нагрузочному тесту.

Главное практическое отличие для владельца сайта: у Nginx нет .htaccess. Все правила редиректов, блокировок и заголовков задаются в основном конфигурационном файле сервера, доступ к которому есть только у администратора хостинга. Это значит, что типичный совет «добавьте вот такие строчки в .htaccess», который легко найти в интернете, для сайта на чистом Nginx просто не сработает, и придётся писать тикет в поддержку хостера на каждое такое изменение.

Пример аналога правила из .htaccess в формате Nginx, блокировка запросов к xmlrpc.php у WordPress:

location = /xmlrpc.php {
    deny all;
}

Для человека без доступа к серверной конфигурации это уже не самостоятельная правка, а обращение в поддержку. На части хостингов эту проблему решают связкой: Nginx спереди отдаёт статику и работает прокси, а запросы к PHP передаёт на Apache сзади, который по-прежнему читает .htaccess. Такая гибридная схема (часто называется Nginx plus Apache mod_php или Nginx reverse proxy) встречается на многих российских хостингах и даёт часть преимуществ Nginx, сохраняя привычный .htaccess для динамики.

LiteSpeed: совместимость с .htaccess плюс кэш на уровне сервера

LiteSpeed старается взять лучшее из обоих миров: архитектура событийная и быстрая, как у Nginx, но при этом сервер поддерживает синтаксис .htaccess почти без изменений, то есть привычные правила Apache просто работают. Для владельца сайта на shared-хостинге это самый безболезненный вариант, миграция с Apache на LiteSpeed обычно не требует переписывать ни строчки конфигурации.

Отдельный плюс: LiteSpeed Cache, встроенный механизм кэширования на уровне сервера, который работает быстрее плагинов кэша уровня приложения вроде WP Super Cache, потому что отдаёт закэшированную страницу до того, как вообще запускается PHP. При правильной настройке разница в TTFB между «холодной» и закэшированной страницей может быть десятикратной.

Подвох в двух местах. Во-первых, полноценный LiteSpeed Enterprise это платная лицензия для хостинг-провайдера, и часть функций (продвинутый ESI-кэш, интеграция с CDN) доступна только на дорогих тарифах. Бесплатная версия OpenLiteSpeed урезана. Во-вторых, LiteSpeed Cache как плагин WordPress конфликтует с другими плагинами кэширования, если их не отключить до конца, получаются двойные, а иногда противоречащие друг другу правила кэша, и сайт начинает вести себя странно: то показывает старую версию страницы, то дважды применяет сжатие.

Пример из практики: магазин, который упирался не в сервер

Расскажу конкретный случай, чтобы показать, как легко перепутать симптом с причиной. Ко мне обратился владелец интернет-магазина на OpenCart, около 400 товаров, хостинг на Apache без LiteSpeed. Жалоба звучала стандартно: «сайт тормозит, наверное, дело в сервере, посоветуйте хостинг с Nginx».

Первым делом посмотрел TTFB на нескольких страницах через обычный curl с замером времени и через PageSpeed Insights. Главная грузилась 1,8 секунды до первого байта, карточка товара почти столько же. Дальше проверил, что вообще происходит на сервере во время запроса: логирование медленных запросов к MySQL показало, что один и тот же неиндексированный запрос к таблице остатков выполняется на каждой карточке товара по 900-1200 миллисекунд.

Добавил индекс на нужный столбец, TTFB карточки товара упал до 280 миллисекунд без единой правки в конфигурации сервера. Веб-сервер здесь был совершенно ни при чём, разница в цифрах, которую владелец принял за «надо менять сервер», на 80 процентов объяснялась одним неоптимальным SQL-запросом. Уже после этого включили LiteSpeed Cache на новом тарифе того же хостера, TTFB закэшированной страницы упал ещё раз, до 60-90 миллисекунд, но это была уже вишенка на торте, а не решение основной проблемы.

Мораль простая: прежде чем менять инфраструктуру, стоит десять минут потратить на измерение, где конкретно уходит время. Иначе есть риск заплатить за миграцию на новый хостинг и не получить того ускорения, на которое рассчитывали.

Что даёт смена сервера в цифрах, а что не даёт вообще

Вот сводная таблица по тому, что реально меняется при смене веб-сервера, а что нет, по моим замерам на однотипных сайтах WordPress с включённым кэшем страниц.

Метрика	Apache	Nginx	LiteSpeed
TTFB на закэшированной странице	250-450 мс	150-300 мс	40-120 мс (со встроенным кэшем)
TTFB без кэша, средний PHP-сайт	500-900 мс	450-800 мс	400-750 мс
Отдача статики (картинка 100 КБ)	60-100 мс	20-40 мс	20-40 мс
Совместимость с .htaccess	полная	нет	полная
Память на 100 одновременных соединений	высокая	низкая	низкая

Ключевой вывод из таблицы: разница в скорости на статике и при высокой параллельной нагрузке реальная. А вот TTFB на не закэшированной странице, где основное время уходит на выполнение PHP-кода и запросы к базе, от типа сервера зависит слабо. Если сайт тормозит из-за тяжёлых плагинов, раздутой базы или отсутствия кэширования на уровне приложения, смена Apache на Nginx этого не починит вообще. Проверить, где реально теряется время, помогает разбор конкретных цифр в статье про TTFB больше 600 мс на shared-хостинге.

Практический вывод: когда менять хостинг ради сервера, а когда чинить сайт

Смена веб-сервера сама по себе почти никогда не является отдельной задачей для владельца малого сайта, потому что веб-сервер обычно идёт в комплекте с хостингом, а не выбирается отдельно. Вопрос звучит не «какой сервер поставить», а «стоит ли менять хостинг ради другого сервера». Ситуации, где это оправдано:

• сайт получает резкие всплески трафика (реклама, рассылка, сезонный спрос), и на Apache-хостинге это регулярно кончается 503 ошибкой,
• на сайте много статики: галереи, каталог с десятками фото на карточку, и её отдача заметно тормозит на текущем хостинге,
• текущий хостинг на Apache без LiteSpeed и без адекватного кэша, а переход на тариф с LiteSpeed у того же провайдера стоит разумных денег.

Ситуации, где менять сервер не стоит, а нужно чинить сайт:

• TTFB высокий, но сайт получает до тысячи визитов в день без всплесков, тогда причина почти наверняка в PHP-коде, плагинах или базе,
• на сайте нет никакого кэширования вообще, тогда сначала настраивается кэш (плагин или .htaccess), а не меняется сервер,
• сжатие GZIP или Brotli не включено, картинки не оптимизированы, а разговор про сервер идёт раньше базовых настроек. Это разобрано отдельно в статье про gzip и brotli на shared-хостинге.

Короткий чек-лист перед тем, как писать хостеру запрос на смену сервера:

• проверили TTFB на закэшированной и не закэшированной странице отдельно,
• включили сжатие и проверили, что оно реально работает (заголовок Content-Encoding в ответе),
• настроили кэширование статики через .htaccess или аналогичный механизм, разобрано в статье кэширование через .htaccess,
• отключили или заменили тяжёлые плагины, если они есть,
• убедились, что проблема действительно в сервере, а не в коде.

Если после всех этих шагов сайт всё ещё упирается в лимиты именно веб-сервера, тогда разговор про смену хостинга оправдан. Как выбирать хостинг для малого бизнеса вообще, с чем сравнивать тарифы и на что смотреть кроме цены, писал отдельно в статье как выбрать хостинг малому бизнесу.

Если не хочется разбираться самому, пришлите ссылку на сайт через форму обратной связи, и я за один диагностический прогон покажу, где сайт реально теряет время: в сервере, в коде или в отсутствии базовых настроек кэша и сжатия. Диагностика скорости входит в мои тарифы на обслуживание как отдельная услуга или как часть абонентки.

Частые вопросы

Как узнать, какой сервер отдаёт мой сайт

Посмотреть заголовок Server в ответе сервера через инструменты разработчика или консольный запрос. Иногда хостинг его скрывает, тогда подсказку даёт панель управления.

Что быстрее: Apache, Nginx или LiteSpeed

На статике и на закэшированных страницах впереди LiteSpeed и Nginx. Без кэша все трое примерно равны. Время съедает генерация страницы, а не сервер.

Стоит ли переезжать ради Nginx

Только если упираетесь именно в сервер, а это редкость. Чаще замедление на 80 процентов объясняется одним неоптимальным запросом или тяжёлым плагином, и переезд его не вылечит.

Что теряется при уходе с Apache

Файл .htaccess: на чистом Nginx он не работает, и все правила переносят в конфиг сервера. LiteSpeed этот файл понимает, поэтому переход на него проходит мягче.