Почему сайт на WordPress тормозит на дешёвом хостинге

Сам движок редко бывает причиной. Упирается проект обычно в лимиты shared-тарифа: общий процессор, узкий канал к диску, ограничение на число PHP-процессов и соединений с базой. Пять страниц и блог этого не замечают. Каталог WooCommerce, формы, выгрузка товаров и админка начинают упираться в потолок. Ниже разберу, где этот потолок проходит, когда пора переезжать на VPS и как сделать переезд так, чтобы не потерять заказы и письма.

Что именно тормозит WordPress на дешёвом хостинге?

WordPress экономен к ресурсам, пока сайт небольшой. Проблемы начинаются, когда на одном сервере работают десятки аккаунтов и делят между собой процессор, память и дисковые операции. Дальше включаются жёсткие правила провайдера: сколько PHP-процессов можно запустить одновременно, сколько держать соединений с MySQL, как часто делать бэкап. Ошибка 502 в момент пика или при массовой правке товаров — как раз из этой оперы.

• Общий пул CPU и RAM: сосед по серверу выгружает каталог — проседает ваш сайт.
• Диск с общим доступом: операции ввода-вывода достаются по остаточному принципу.
• Лимит PHP-процессов и соединений с базой: часть запросов просто сбрасывается.
• Стандартный стек без тонкой настройки: OPcache, PHP-FPM и Redis настроены «для всех».
• Кэш хостинга сбрасывается при каждом изменении, и страница снова собирается с нуля.
• Бэкапы по расписанию провайдера: восстановить отдельную таблицу или файл почти нереально.

Где заканчивается ресурс shared-тарифа

Разница между shared-тарифом и VPS не в том, что один «плохой», а второй «хороший». Разница в том, кому принадлежит ресурс и кто отвечает за его настройку.

VPS добавляет статью расходов, которой на shared нет: сервер нужно обновлять, бэкапы проверять, следить за мониторингом и реакцией на инциденты. По этому пункту как раз стоит посчитать заранее, что дешевле — переплата за тариф повыше или время своего специалиста.

Как понять, что сайту пора на VPS?

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

• TTFB растёт в часы пик: утром и вечером сайт отвечает заметно медленнее.
• При сохранении товара или массовой правке вылезают 502 и 504.
• В логах базы мелькает превышение max_connections.
• Админка открывается дольше, чем сам сайт.
• Экспорт заказов или импорт прайса обрывается на середине.
• Письма из форм уходят с задержкой или не уходят вовсе.
• Обновление плагинов превращается в лотерею: сайт падает и поднимается не сразу.

Перед решением соберите факты: посмотрите в панели статистику по CPU, памяти и дисковым операциям, замерьте TTFB с нескольких точек, откройте лог ошибок PHP и MySQL. Если всё это упирается в лимиты тарифа, дело не в плагинах и не в теме. Здесь уже имеет смысл считать параметры сервера под нагрузку — об этом подробно в статье как выбрать VPS под WordPress. Если же проект на стыке CMS, кэша и обменов с внешними системами, поможет более широкий разбор как выбрать хостинг под нагрузку и стек.

Как перенести сайт на VPS без потери заказов и писем?

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

1. Зафиксируйте текущие версии PHP, MySQL и список активных плагинов. Если обновляете стек, делайте это отдельным шагом, а не вместе с переездом.
2. Снимите полные копии файлов и базы. Проверьте, что архив открывается и дамп восстанавливается на тестовой машине.
3. Разверните копию на VPS на временном домене или через локальный hosts. Продакшн пока не трогайте.
4. Проверьте формы, письма, оплату, крон-задачи, интеграции с 1С или CRM, редиректы. Всё, что раньше работало само, здесь надо протестировать руками.
5. За сутки до переключения снизьте TTL домена. Это сократит окно, когда часть пользователей видит старый сервер, а часть — новый.
6. Переключите DNS, установите SSL, проверьте отправку писем с нового сервера: SPF и DKIM должны указывать на новую площадку, а не на старую.
7. Старый хостинг не отключайте минимум неделю. Заказы и письма в это время легко проверить на обеих сторонах.

Что настроить на VPS, чтобы история не повторилась

Перенос без настройки даст тот же результат, только на своём сервере. После переезда стоит выделить пул PHP-FPM под сайт, включить OPcache, подключить объектный кэш вроде Redis для WooCommerce, поднять параметр innodb_buffer_pool_size под объём базы и оставить мониторинг с бэкапами, которые кто-то проверяет. Тогда VPS даёт не только ресурсы, но и предсказуемость.

Типичные ошибки при переезде

• Переезжать без проверенной резервной копии: архив не открывается именно в тот день, когда он нужен.
• Менять DNS с прежним TTL — часть клиентов остаётся на старом сервере часами.
• Забыть про почту: после переключения письма уходят в спам, потому что записи SPF и DKIM остались на старом хостинге.
• Игнорировать крон и интеграции: обмен с 1С, выгрузки на маркетплейсы, напоминания клиентам перестают работать молча.
• Взять VPS без администрирования: сервер обновляется сам, но кто-то должен проверять, что после обновления сайт открывается, а бэкап восстанавливается.
• Совместить переезд с обновлением PHP и MySQL: непонятно, что именно сломало сайт.

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

1. Соберите факты: лог ошибок, замеры TTFB, статистика по CPU и памяти в панели хостинга.
2. Посчитайте, сколько часов в месяц уходит на «подождать, пока откроется» и на разбор инцидентов после пиковой нагрузки.
3. Сверьте эти цифры со стоимостью VPS и настройки, чтобы решение было по расчёту, а не по ощущению.