Shared-хостинг под WordPress работает до определённого момента. Потом приходит день, когда WooCommerce тормозит при 30 одновременных покупателях, плагин кеширования не спасает, а поддержка хостинга отвечает: «У вас превышен лимит CPU, перейдите на более дорогой тариф». Переход на VDS решает проблему, но только если выбрать сервер под конкретную нагрузку, а не наобум.
В этой статье разберём, как подобрать VDS для WordPress — от небольшого блога до нагруженного интернет-магазина: минимальные ресурсы, тип диска, стек, кеширование и то, что провайдеры обычно не афишируют.
Когда shared-хостинг уже не справляется
WordPress сам по себе не тяжёлый. Проблема в том, что он работает через PHP, каждый запрос к странице генерирует десятки SQL-запросов, а с ростом плагинов это число растёт кратно. WooCommerce с активными корзинами, формами и сессиями — это уже постоянная запись в БД. Кеш-плагины типа WP Rocket или W3 Total Cache помогают со статическими страницами, но не с динамическими запросами оформления заказа.
На shared-хостинге все эти процессы делят ресурсы с соседями. Нет гарантий по CPU и RAM — провайдер режет процессы, если кто-то рядом «жрёт» больше нормы. Итог: TTFB 1,5–3 секунды, периодические 503, упавшие обновления плагинов в самый неподходящий момент.
VDS даёт выделенные ресурсы. Сервер ваш — соседи на TTFB не влияют.
Минимальные ресурсы по уровням нагрузки
Нет смысла переплачивать за 16 ГБ RAM под блог с 500 посетителей в сутки. Но и экономить до дна на магазине с 10 000 заказов в месяц — верный путь к падениям. Вот реалистичные цифры по уровням:
| Уровень | Трафик (сутки) | CPU | RAM | Диск |
|---|---|---|---|---|
| Блог / портфолио | до 5 000 | 1–2 vCPU | 2 ГБ | 20–40 ГБ NVMe |
| Новостной сайт / СМИ | 10 000–50 000 | 2–4 vCPU | 4–8 ГБ | 60–100 ГБ NVMe |
| WooCommerce / e-commerce | 50 000+ | 4–8 vCPU | 8–16 ГБ | 100+ ГБ NVMe |
Цифры ориентировочные — многое зависит от количества плагинов и настройки стека. Сайт с 20 тяжёлыми плагинами и без кеширования может требовать вдвое больше ресурсов, чем аналогичный по трафику, но оптимизированный.
NVMe против SATA SSD — почему для WordPress это принципиально
WordPress активно работает с базой данных. Каждый просмотр страницы без кеша — это 30–80 SQL-запросов к MySQL. При одновременных посетителях запросы множатся, и скорость дискового I/O становится узким горлышком.
Разница между типами дисков по случайному чтению (IOPS):
- SATA SSD — 30 000–50 000 IOPS
- NVMe — 200 000–500 000 IOPS
На практике это выражается в TTFB. На NVMe WordPress отвечает за 50–150 мс до первого байта (при правильно настроенном стеке). На SATA SSD с аналогичной конфигурацией — 200–400 мс. Для SEO и поведенческих факторов разница ощутимая.
Если провайдер предлагает только SATA SSD — это не приговор для небольшого блога с кешем. Но под WooCommerce или новостник с высоким трафиком NVMe обязателен. Смотрите как оптимизировать VPS под нагрузку после запуска.
PHP-FPM под WordPress: версии, OPcache, JIT
PHP-FPM — обязательный компонент для производительного WordPress. В отличие от mod_php, FPM обрабатывает запросы в отдельных пулах процессов, что даёт лучшую изоляцию и управление ресурсами.
Версия PHP. По данным WordPress.org, официально поддерживаются PHP 7.4+, но рекомендуется 8.1 и выше. PHP 8.2 и 8.3 заметно быстрее 7.x на синтетических тестах (до 20% прироста на типичных WP-операциях). Проверьте совместимость ваших плагинов перед переходом на 8.3 — некоторые старые плагины ещё не обновлены.
OPcache. Кеширует скомпилированный байткод PHP, чтобы не компилировать скрипты при каждом запросе. Для WordPress это обязательная настройка:
opcache.memory_consumption=128— минимум для нормальной работы, лучше 256opcache.max_accelerated_files=10000— WordPress с плагинами легко набирает 5–8 тысяч файловopcache.validate_timestamps=0— отключить на продакшене для скорости (включить при деплое)
JIT (Just-In-Time компиляция) появился в PHP 8.0. Для WordPress эффект скромный — JIT помогает CPU-интенсивным задачам, а WordPress — это прежде всего I/O и база данных. Включать можно, но не ждать магии.
База данных: MySQL, MariaDB и тюнинг под WordPress
WordPress официально поддерживает MySQL 5.7+ и MariaDB 10.4+. На практике MariaDB работает чуть быстрее на типичных WP-запросах и активно развивается. Большинство провайдеров предлагают оба варианта.
Ключевой параметр тюнинга — innodb_buffer_pool_size. Это размер буфера InnoDB, в котором MySQL держит данные и индексы в оперативной памяти. Правило: выделять 50–70% от общего RAM на серверах, где MySQL — основная нагрузка.
- 2 ГБ RAM на VDS →
innodb_buffer_pool_size=512M - 4 ГБ RAM →
innodb_buffer_pool_size=2G - 8 ГБ RAM →
innodb_buffer_pool_size=4G
Для крупных проектов с объёмной базой (каталог товаров от 50 000 позиций, новостник с историей за 5+ лет) — рассматривайте вынос базы данных на отдельный инстанс. Это разделяет нагрузку: веб-сервер получает все CPU-ресурсы под PHP-FPM, а БД-сервер — под запросы. Часть провайдеров даёт managed MySQL как отдельную услугу.
Кеширование: три уровня, которые нужны WordPress
Правильно настроенное кеширование — это разница между VDS за 500 рублей, который тянет 10 000 посетителей, и VDS за 2000 рублей без кеша, который падает на 3000. Уровней три:
Object cache (Redis или Memcached). WordPress по умолчанию хранит кеш объектов в памяти только в рамках одного запроса. Redis и Memcached делают его персистентным — результаты тяжёлых запросов к БД сохраняются между запросами. Для WooCommerce и сайтов с авторизацией это критично. Redis предпочтительнее: поддерживает сложные структуры данных, атомарные операции и persistence.
OPcache (описан выше) — кеш байткода PHP. Работает на уровне файловой системы, не требует отдельного демона.
FastCGI cache (Nginx) — кеш полных HTML-страниц на уровне веб-сервера. Nginx отдаёт страницу из кеша, не доходя до PHP. Скорость отдачи — единицы миллисекунд. Настраивается через директиву fastcgi_cache в конфиге Nginx. Не подходит для страниц с авторизованными пользователями и корзиной — их нужно исключать через fastcgi_cache_bypass.
Плагины типа WP Rocket и W3 Total Cache управляют кешем страниц через свои механизмы, но FastCGI cache быстрее — он работает до PHP. Идеальная связка: Nginx FastCGI cache для анонимных посетителей + Redis для авторизованных.
Готовые WordPress-образы у провайдеров
Ставить стек руками — полезно один раз, чтобы понять, как всё работает. В продакшене удобнее использовать готовые образы. У большинства провайдеров они есть:
- Aeza — образ с WordPress, Nginx, PHP-FPM, MariaDB. Быстрые NVMe-диски, удобен для разработчиков, есть поддержка Docker-стека.
- Beget — панель с одноклик-установкой WordPress, автоматические бэкапы, понятный интерфейс для нетехнических пользователей. Один из самых популярных в рунете вариантов под WP.
- Timeweb Cloud — готовые шаблоны с предустановленным WordPress, SLA 99,9%, автобэкапы. Хорошо подходит агентствам, которые управляют несколькими сайтами клиентов.
- AdminVPS — ориентирован на CMS-проекты, есть управляемые конфигурации с WordPress-стеком, техподдержка помогает с настройкой.
Если планируете перенести уже существующий WordPress-сайт на VPS, образ с совместимыми версиями PHP и MySQL сэкономит время. Смотрите версию PHP на текущем хостинге заранее.
Сравнить все доступные VDS-провайдеры с фильтрами по RAM, диску и типу виртуализации можно в каталоге. Там же — раздел хостингов если VDS избыточен для задачи.
Резервное копирование WordPress
Бэкап — это не «хорошо бы сделать», это базовая гигиена. WordPress-сайт нужно бэкапить на двух уровнях: файлы (wp-content, темы, плагины) и база данных.
Плагинные бэкапы. UpdraftPlus — стандарт отрасли. Бесплатная версия умеет бэкапить по расписанию в облако (Google Drive, Dropbox, S3). Duplicator удобен для миграции: упаковывает сайт в zip-архив с установщиком. BackWPup — хороший бесплатный вариант с гибкой настройкой.
Провайдерские бэкапы. Большинство провайдеров из списка выше делают снапшоты сервера автоматически. Это удобнее — восстановить VDS до состояния «вчера в 4 утра» можно за несколько минут. Минус: снапшоты стоят дополнительно (обычно 10–20% от цены тарифа). Подробнее о настройке — в гайде как настроить бэкапы VPS.
Оптимальная стратегия: провайдерские снапшоты раз в сутки + плагинный бэкап в отдельное облако раз в неделю. Не храните бэкапы только на том же сервере — это не бэкап, это иллюзия безопасности.
SSL и доменные настройки
HTTPS — обязательное условие для WordPress-сайта. Google с 2018 года помечает HTTP-сайты как небезопасные, Chrome показывает предупреждение. Без SSL не будет cookie-авторизации через современные браузеры.
Все нормальные провайдеры поддерживают Let’s Encrypt — бесплатные сертификаты с автопродлением. Установить сертификат на VDS можно через Certbot за 10 минут. Пошаговый процесс разобран в гайде как установить SSL Let’s Encrypt.
После установки SSL в WordPress нужно обновить URL в настройках (Настройки → Общие → WordPress адрес и адрес сайта) и принудительно перенаправлять HTTP на HTTPS через конфиг Nginx или .htaccess. Без этого часть ресурсов будет грузиться по HTTP, браузер покажет предупреждение о смешанном контенте.
Настройку VPS с нуля — от первого подключения по SSH до работающего Nginx с PHP-FPM — разобрали в отдельном туториале по настройке VPS.
Чек-лист выбора VDS под WordPress
- Тип диска NVMe — не SATA SSD, особенно при трафике выше 5000/сутки
- PHP 8.1 или 8.2 с возможностью смены версии без переустановки стека
- PHP-FPM в комплекте или возможность установить самостоятельно
- OPcache включён и настроен — проверить через phpinfo()
- Поддержка Redis или Memcached для object cache
- Nginx с поддержкой fastcgi_cache или возможность его настроить
- MariaDB 10.6+ или MySQL 8.0+ с возможностью тюнинга innodb_buffer_pool_size
- Автоматические бэкапы у провайдера — желательно раз в сутки с хранением 7 дней
- Let’s Encrypt поддерживается — автопродление сертификатов
- KVM-виртуализация, а не OpenVZ/LXC — полная изоляция, меньше ограничений
- Географически близкий дата-центр к целевой аудитории — Москва, Амстердам, Франкфурт
- Техническая поддержка реагирует в разумные сроки — проверить отзывы до покупки
- Возможность upgrade тарифа без переноса сайта — масштабируемость важна при росте трафика
Ну и в заключение
Выбор VDS под WordPress — это не про максимальные характеристики, а про соответствие нагрузке. Блогу с 2000 посетителей в сутки хватит 2 vCPU и 2 ГБ RAM с правильно настроенным кешем. WooCommerce с тысячей заказов в день потребует совсем другого разговора — и отдельной БД-инстанции в том числе.
Критичные параметры в порядке приоритета: тип диска (NVMe обязателен для серьёзных проектов), версия PHP с OPcache, наличие Redis, качество поддержки провайдера. Готовые WordPress-образы у Aeza, Beget, Timeweb Cloud и AdminVPS закрывают базовую настройку — дальше тюнинг под конкретный проект.
