WooCommerce на shared-хостинге: когда пора переезжать на VPS
Сколько товаров и заказов держит обычный виртуальный хостинг, по каким признакам магазин упирается в лимиты и что даёт переезд.
Содержание
Магазин тяжелее визитки на том же движке: у него нет полноценного кэша страниц для корзины и личного кабинета. Обычный хостинг за 200-600 рублей держит каталог до нескольких сотен товаров. Первый признак упора в потолок это список заказов, открывающийся дольше 5-7 секунд.
Владелец магазина на WooCommerce обычно приходит с одной и той же жалобой: «сайт нормально работал полгода, а теперь по вечерам виснет». Почти всегда это не поломка, а магазин, который перерос тариф хостинга, купленный под визитку. Разберу, где проходит реальная граница возможностей shared-хостинга для интернет-магазина, по каким симптомам её видно и что конкретно происходит при переезде на VPS.
Сразу оговорюсь: WooCommerce не тяжелее WordPress сам по себе, тяжелее становится сайт, потому что магазин работает иначе, чем блог или визитка. Об этом и пойдёт речь.
Почему магазин тяжелее визитки на том же движке
Статичная страница WordPress почти всегда отдаётся из кэша: один раз собрал HTML, дальше сервер просто раздаёт готовый файл, пока контент не поменялся. Кэш снимает с сервера 90 процентов нагрузки, и на этом держится вся экономика shared-хостинга: тысяча сайтов на одном сервере работает, пока большинство запросов дешёвые.
У магазина часть страниц кэшировать нельзя в принципе:
- корзина и оформление заказа, там у каждого посетителя свои данные;
- страница «Мой аккаунт», тоже персональная для каждого пользователя;
- запросы
admin-ajax.php, через них живёт добавление в корзину, применение купона, обновление количества; - REST API склада, если товар синхронизируется с 1С или другой учётной системой.
Каждый такой запрос генерируется заново PHP-процессом, обращается к базе, иногда не один раз. На визитке таких запросов в день десятки. На магазине с сотней посетителей в час их тысячи, и каждый ест реальные CPU-секунды тарифа.
Добавьте сюда крон WordPress (wp-cron.php), который в WooCommerce отвечает за отмену неоплаченных заказов по таймауту, пересчёт остатков, синхронизацию с внешними системами. По умолчанию он запускается почти на каждом заходе посетителя, и на нагруженном магазине это ещё один процесс, соревнующийся за тот же лимит.
Реальные пороги shared-хостинга
Цифры условные и зависят от конкретного тарифа, но по моим наблюдениям на типичных российских shared-тарифах (200-600 рублей в месяц, ограничение по CPU и числу процессов) граница выглядит так.
| Показатель | Обычно тянет | Начинаются проблемы |
|---|---|---|
| Товаров в каталоге | до 1 000-1 500 | от 3 000-5 000 |
| Заказов в сутки | до 15-20 | от 40-50 |
| Одновременных посетителей в пик | до 20-30 | от 60-80 |
| Плагинов активно | до 20-25 | от 35-40 |
| Интеграция 1С/склад | синхронизация раз в час без проблем | синхронизация каждые 5 минут уже давит |
Магазин с 300 товарами и пятью заказами в день будет прекрасно жить на shared-хостинге годами. Магазин с 4 000 товаров, ежедневной синхронизацией остатков с 1С и рекламной кампанией в Директе на пике сезона на том же тарифе начинает сыпаться в первый же час пиковой нагрузки.
Важный нюанс: пороги считаются не по одному параметру, а по их сумме. 1 500 товаров без интеграций и с редкими заказами это не то же самое, что 800 товаров с синхронизацией остатков каждые пять минут и виджетом «с этим товаром покупают». Второй случай упрётся в лимиты раньше при формально меньшем магазине.
Признаки, что магазин упёрся в лимиты
Список симптомов, с которыми клиенты приходят чаще всего, и что на самом деле за ними стоит.
503 Service Unavailable в час пик. Хостинг физически отказывается запускать новый PHP-процесс, потому что упёрлись в лимит одновременных процессов по тарифу. Обычно происходит вечером в будни или во время рекламной акции, то есть именно тогда, когда магазин больше всего нуждается в стабильности.
Долгая загрузка админки. WooCommerce тянет в панели управления списки заказов, отчёты, склад, и на большом каталоге запросы к базе становятся медленными. Если открытие списка заказов занимает больше 5-7 секунд, база или процессор уже на пределе.
Зависший импорт или экспорт товаров. Массовые операции (обновление 2 000 товаров через CSV, полная синхронизация с 1С) требуют времени выполнения скрипта дольше, чем разрешает max_execution_time на shared-тарифе. Импорт обрывается на середине, часть товаров не обновляется, и это не баг плагина, а упор в лимит хостинга.
Письма о заказе уходят с задержкой. Отправка письма через wp_mail при оформлении заказа, если сервер перегружен, встаёт в очередь вместе со всем остальным. Клиент оформил заказ, письмо с подтверждением пришло через 20 минут, а не сразу, и это выглядит как будто магазин не работает.
Периодические 500 ошибки без видимой причины. Часто это исчерпание памяти PHP (memory_limit), которое на shared-тарифе фиксировано и не поднимается по запросу. Плагины для WooCommerce (динамическое ценообразование, комплекты товаров, интеграция с маркетплейсами) в сумме легко выедают лимит в 256 МБ.
Проверить текущую загрузку без доступа к панели мониторинга хостинга можно грубо, но информативно: замерить время ответа сервера в разное время суток.
curl -w "time_total: %{time_total}sncode: %{http_code}n" -o /dev/null -s https://your-shop.ru/Если днём ответ укладывается в 0,3-0,5 секунды, а вечером в пик регулярно вылезает за 3-5 секунд или отдаёт ошибку, это прямой сигнал упора в лимиты, а не разовая случайность.
Что можно выжать без переезда
Прежде чем платить за VPS, есть смысл проверить, не упирается ли магазин в собственные настройки, а не в тариф.
Кэш страниц каталога и карточек товара. Кэшируется всё, кроме корзины, оформления и личного кабинета. Плагины уровня LiteSpeed Cache (если хостинг на LiteSpeed) или WP Super Cache с правильными исключениями снимают заметную часть нагрузки бесплатно.
Отключение лишних плагинов. На аудитах регулярно нахожу активные плагины, которые магазину не нужны: старый слайдер, статистика посещений внутри WordPress вместо внешней Метрики, дублирующий SEO-плагин. Каждый лишний плагин это лишние SQL-запросы на каждой странице.
Индексы в таблицах базы данных. WooCommerce создаёт собственные таблицы, и на старых установках, переживших несколько обновлений, часть индексов может быть повреждена или отсутствовать. Проверяется через wp db check, чинится через wp db repair (WP-CLI, если хостинг его разрешает) или через phpMyAdmin вручную.
Чистка сессий и временных данных. Таблица wp_woocommerce_sessions у магазина с трафиком от ботов и брошенными корзинами разрастается быстро и не чистится сама вовремя. Разовая чистка старше двух-трёх дней снимает часть нагрузки на базу.
Отказ от синхронизации по крону в пользу вебхуков. Если 1С или другая система дёргает магазин каждые пять минут «на всякий случай», а не по событию, это постоянная фоновая нагрузка. Переход на вебхуки (сервер уведомляет только при реальном изменении) снижает число запросов на порядок.
Эти меры откладывают переезд на VPS на несколько месяцев, иногда навсегда, если магазин небольшой. Но если каталог и трафик продолжают расти, оптимизация лишь отодвигает потолок, а не убирает его.
Что даёт VPS и во сколько обходится обслуживание
VPS решает проблему не магией, а тем, что сервер больше не делится ресурсами с чужими сайтами. Процессор, память и число процессов принадлежат только вам, и лимиты можно наращивать по мере роста магазина, а не упираться в фиксированный потолок тарифа.
Ориентир по деньгам на 2026 год:
| Вариант | Стоимость в месяц | Что входит |
|---|---|---|
| Shared-хостинг для магазина | 300-800 руб. | сервер общий, лимиты фиксированы |
| VPS начального уровня (2 CPU, 4 ГБ) | 1 500-3 000 руб. | сервер выделен, но администрирование ваше |
| VPS с управляемой панелью (ISPmanager, VestaCP) | 2 500-5 000 руб. | панель упрощает часть настроек |
| Администрирование VPS у подрядчика | от 5 000 руб./мес. | обновления, мониторинг, бэкапы, реакция на инциденты |
Ключевой момент, который часто упускают: VPS без администратора это не готовое решение, а голая машина. Никто не поставит автоматически обновления безопасности, не настроит файрвол, не отреагирует ночью, если сервер перестанет отвечать. На shared-хостинге это делает хостер как часть тарифа, на VPS это либо ваша забота, либо отдельная строка в бюджете на обслуживание.
Для малого магазина (до 1 000 заказов в месяц) я обычно советую сначала выжать всё из оптимизации на shared, и переезжать на VPS только когда лимиты процессов реально начинают резать конверсию, а не про запас. Переезд ради переезда добавляет расходы без немедленной отдачи.
План переезда магазина без потери заказов
Перенос работающего магазина отличается от переноса визитки тем, что нельзя просто «выключить старое, включить новое»: заказы продолжают приходить, пока идёт перенос.
# Порядок действий в ночь переезда
# 1. Снимок текущей базы с отметкой времени
wp db export backup-before-migrate-$(date +%Y%m%d-%H%M).sql
# 2. Перенос файлов и базы на новый сервер (общая схема)
rsync -avz /path/to/site/ user@newserver:/path/to/site/
mysqldump -u user -p old_db > dump.sql
# 3. Импорт на новом сервере и проверка целостности заказов
mysql -u user -p new_db < dump.sql
wp db checkПорядок действий по шагам:
- Предупредить о технических работах: короткое окно (обычно 1-2 часа ночью) с минимальным трафиком, по логам Метрики видно, когда магазин спит.
- Снять свежий бэкап файлов и базы непосредственно перед переносом, а не использовать вчерашний.
- Развернуть копию на новом сервере, проверить работоспособность через тестовый домен или файл hosts, не трогая боевой DNS.
- Сверить количество заказов, товаров и пользователей на старом и новом сервере, эта цифра должна совпасть буквально до единицы.
- Проверить оформление тестового заказа целиком: добавление в корзину, применение купона, оплата в тестовом режиме, письмо с подтверждением.
- Переключить DNS на новый сервер, дождаться прохождения (обычно от 10 минут до нескольких часов в зависимости от TTL записи).
- В первые сутки после переключения мониторить количество заказов и ошибок оплаты внимательнее обычного.
Отдельно проверьте интеграции: CRM вроде amoCRM или Битрикс24, куда падают заявки, платёжный шлюз, службу доставки. Каждая из них может быть завязана на конкретный IP или URL старого сервера, и это частая причина «заказы вроде оформляются, а в CRM не попадают» после переезда. Если у магазина есть интеграция с CRM, отдельно разобрал её настройку и типовые грабли в статье про интеграцию amoCRM и Битрикс24.
Медленный отклик сервера на shared-хостинге, если проблема не столько в лимитах процессов, сколько в самом времени ответа, разбирается отдельно, там другая методика диагностики: смотрите статью про TTFB больше 600 мс на shared-хостинге. А если магазин тормозит не из-за хостинга, а из-за самого WordPress, накопившего балласт за несколько лет, там своя причина, описанная в статье WordPress тормозит после трёх лет.
Если пока непонятно, где именно магазин упирается в потолок, отправьте мне ссылку через форму на главной, обычно диагностика по логам и нагрузочному профилю занимает один рабочий день и сразу даёт ответ: чинить настройки или пора переезжать.
Частые вопросы
Когда WooCommerce перерастает обычный хостинг
Когда админка и список заказов открываются дольше 5-7 секунд, а вечером сайт начинает подвисать. Второй признак это регулярные превышения лимитов по процессору в панели.
Почему магазин тяжелее обычного сайта
Потому что корзину, оформление и личный кабинет нельзя отдавать из кэша: каждому посетителю нужна своя страница. Кэш снимает основную нагрузку с обычного сайта, а с магазина не снимает.
Что можно выжать без переезда
Кэш для каталога и статических страниц, разгрузку базы, отказ от лишних плагинов, реже запускаемую синхронизацию с учётной системой и вынос картинок на внешнее хранилище.
Как переезжать без потери заказов
Поднять копию на новом сервере, проверить, снизить время жизни DNS заранее, переключить домен в ночное окно и первые сутки следить за обоими серверами: заказы могут прийти на старый.
