Когда пора уходить с шаред-хостинга: расчёт по нагрузке и деньгам

MAATRIX

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

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

Шаред-хостинг физически не может дать вам предсказуемые ресурсы — на одном сервере крутятся сотни аккаунтов, и панель управления (обычно на базе CloudLinux) следит, чтобы ни один из них не съел общий пул. Это делается через LVE (Lightweight Virtual Environment) — лимиты по CPU, памяти, числу одновременных процессов (NPROC) и параллельных PHP-обработчиков (EP, entry processes). Как только ваш сайт упирается в свой персональный лимит внутри общего сервера, он не «тормозит плавно» — он получает жёсткий отказ.

Смотрите на такие сигналы:

• Ошибки 508 (Resource Limit Is Reached) или 509. Это прямое сообщение: ваш аккаунт выбрал квоту CPU/памяти/процессов, выделенную панелью, независимо от того, сколько ресурсов простаивает у соседей.
• Раздел «Resource Usage» / «Использование ресурсов» в панели (cPanel, ISPmanager) регулярно показывает пики в 90–100% по CPU, памяти или числу процессов — не разово при deploy, а стабильно в часы пиковой посещаемости.
• PHP падает с "Allowed memory size exhausted" на страницах, которые раньше открывались нормально — то есть вырос трафик или тяжесть плагинов, а лимит памяти на тарифе остался тем же.
• Периодические 503/500 без видимой причины в коде — по логам приложения всё чисто, но хостинг в это же время фиксирует превышение лимита в панели ресурсов.
• Служба поддержки просит "снизить нагрузку" вместо того, чтобы предложить решение — это значит, что вы уже вышли за рамки, на которые рассчитан тариф, и дальше будет только хуже.

Если один из этих пунктов происходит эпизодически раз в квартал при рекламном всплеске — это ещё не приговор, можно пережить. Если это происходит еженедельно или чаще — вы уже платите за тариф, который не соответствует вашей реальной нагрузке, и вопрос не «если», а «когда» переезжать.

Время отклика растёт вместе с посещаемостью

Второй сигнал даже честнее первого, потому что его не нужно ждать от панели хостинга — вы измеряете его сами. Смысл в том, чтобы отследить не абсолютное время загрузки (оно зависит от десятков факторов), а его зависимость от нагрузки: если TTFB растёт вместе с числом одновременных посетителей — это явный признак, что вы упираетесь в общий процессор или диск сервера, а не в свой код.

Простой замер с любой машины:

curl -o /dev/null -s -w "connect: %{time_connect}s ttfb: %{time_starttransfer}s total: %{time_total}s\n" https://ваш-сайт.ru/

Снимайте этот показатель в разное время суток несколько дней подряд и сопоставляйте с данными о посещаемости из аналитики (Яндекс.Метрика, счётчики хостинга). Если в часы пик TTFB стабильно растёт в 2-3 раза относительно ночных значений — это переподписанный CPU шаред-сервера отдаёт вам меньше такта в моменты, когда он нужнее всего, то есть именно тогда, когда к вам приходит больше всего реальных посетителей.

Дополнительно проверьте внешним сервисом (PageSpeed Insights, GTmetrix, Pingdom) метрику Server Response Time / TTFB отдельно от остальных факторов рендера — она изолирует именно серверную часть от JS/CSS на клиенте. Если статика (CSS, JS, картинки) грузится нормально, а именно первый байт HTML приходит с задержкой — проблема не в оптимизации фронтенда, а в том, что PHP-обработчик и БД конкурируют за ресурсы с соседями по серверу.

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

Когда нужны возможности, которых на шаред просто нет

Отдельная категория причин для переезда — не в том, что шаред «не тянет», а в том, что определённые задачи там технически невозможны, сколько бы вы ни доплачивали за тариф повыше.

• Фоновые процессы и демоны. Очередь задач (Redis-worker, Celery, node-процесс, свой Telegram-бот) требует постоянно работающего процесса. На шаред-хостинге такого не бывает в принципе — там разрешён только код, который выполняется в ответ на HTTP-запрос и завершается.
• Гибкий cron. На шаред-тарифах cron обычно ограничен минимальным интервалом (нередко не чаще раза в 15-30 минут) и списком разрешённых команд — вызвать произвольный бинарник или скрипт на другом языке чаще всего нельзя.
• Своё системное ПО. Нужна конкретная версия PHP/Node/Python, специфическое расширение, отдельная база данных не из списка провайдера (ClickHouse, MongoDB, отдельный Redis) — на шаред это либо недоступно, либо требует обхода через костыли.
• Полноценный SSH и root-доступ. Установить свой сертификат, настроить firewall правила под конкретную задачу, поднять reverse-proxy перед несколькими приложениями — всё это требует доступа, которого на шаред-хостинге не даёт ни один тариф.
• Изоляция ресурсов между своими же проектами. Если у вас несколько сайтов на одном шаред-аккаунте и один "тяжёлый" начинает утаскивать ресурсы у остальных — разделить их можно только физически, то есть на разные машины или хотя бы контейнеры; ориентир по тому, сколько ресурсов реально нужно под несколько сайтов на одном VPS, поможет не переплатить при выборе тарифа.

Если вы регулярно упираетесь в один из этих пунктов и пытаетесь обойти ограничение внешними сервисами (сторонний cron-джоб дергает URL, очередь эмулируется через таблицу в БД с опросом раз в минуту) — это уже сигнал, что архитектура вашего проекта переросла модель шаред-хостинга, и обходные пути стоят вам больше времени, чем стоила бы аренда VPS.

Считаем полную стоимость: тариф, ваше время и потери от тормозов

Здесь чаще всего ошибаются в обе стороны. Одни сравнивают только цифру в счёте («шаред 300 ₽/мес против VPS 600 ₽/мес — конечно шаред дешевле») и не учитывают ничего больше. Другие наоборот пугаются администрирования VPS и остаются на шаред, даже когда он объективно уже стоит бизнесу дороже. Честная формула полной стоимости владения (TCO) выглядит так:

TCO_шаред = Тариф_шаред + Время_на_костыли × Ставка_часа + Потери_от_тормозов
TCO_VPS    = Тариф_VPS + Время_на_администрирование × Ставка_часа + Доплата_за_managed (если нужна)

Разберём каждое слагаемое по отдельности.

Тариф. Это единственное слагаемое, которое действительно почти всегда выше у VPS в моменте — минимальный VPS с гарантированным (не переподписанным) CPU и памятью обычно стоит дороже входного тарифа шаред-хостинга. Тут нет смысла спорить — так и есть, VPS в моменте почти всегда дороже голого шаред-тарифа, и на этом иногда спекулируют, продавая избыточно дешёвые тарифы за счёт скрытой переподписки — как устроена эта разница на практике, разобрано отдельно.

Время на костыли vs время на администрирование. На шаред-хостинге вы тратите время не на администрирование (панель делает это за вас), а на обход ограничений: ищете, как эмулировать фоновую задачу через cron раз в 15 минут, разбираетесь, почему упал лимит процессов, переписываете код под чужие ограничения памяти. На VPS вы тратите время иначе — на настройку сервера один раз (веб-сервер, база, firewall, бэкапы) и периодическое обновление системы. Если считать честно, второе занимает меньше повторяющихся часов в месяц, чем постоянная борьба с чужими лимитами, но требует более редкой и специфической экспертизы — отсюда и вариант с доплатой за managed-обслуживание, если своего времени или навыков не хватает.

Потери от медленной работы — самое недооцененное слагаемое. Замедление отклика на 1-2 секунды в пиковые часы напрямую бьёт по конверсии и по SEO-ранжированию (скорость страницы — один из факторов ранжирования). Дальше механика простая: часть посетителей уходит, не дождавшись загрузки, часть заказов/заявок не оформляется, а поисковик со временем занижает позиции медленного сайта, снижая органический трафик. Точные цифры "сколько именно вы теряете" зависят от ниши, среднего чека и конверсии — универсальной формулы с готовым процентом здесь дать нельзя, это всегда ориентир, а не измеренный факт. Но сам принцип учёта важен: если сайт монетизируется (магазин, услуги, реклама), потери от медленной работы в пиковые часы — реальная статья расходов, просто она не приходит вам отдельным счётом, как тариф хостинга, а тихо вычитается из выручки.

Практический расчёт: пример сравнения на условных цифрах

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

Порядок действий для собственного расчёта:

1. Возьмите свой реальный счёт за шаред-хостинг за последний месяц.
2. Оцените в часах, сколько времени вы (или разработчик) потратили на борьбу с ограничениями тарифа — оптимизацию под лимит памяти, разбор ошибок 508, обходные пути для фоновых задач.
3. Посмотрите в аналитике долю отказов (bounce rate) и время на сайте отдельно в часы, где TTFB был высоким, и сравните с "нормальными" часами — оцените разницу в конверсии, если она измерима.
4. Сложите тариф, время (переведённое в деньги по вашей ставке часа или ставке разработчика) и оценку потерь — это ваша реальная стоимость владения шаред-хостингом сегодня.
5. Сравните с ценой минимального VPS под вашу нагрузку плюс время на разовую настройку — если пункт 4 выше пункта 5, экономического смысла оставаться на шаред уже нет, даже если тариф VPS в моменте выглядит дороже.

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

Чек-лист: пора переезжать, если...

Соберём все признаки в одном месте — чем больше пунктов отмечено, тем меньше смысла оставаться на шаред:

• [ ] Панель регулярно показывает 90-100% использования CPU/памяти/процессов в часы пиковой посещаемости, а не разово.
• [ ] Вы видите ошибки 508/509 или "Resource Limit Is Reached" чаще раза в месяц.
• [ ] TTFB заметно растёт вместе с трафиком — сервер тормозит именно тогда, когда у вас больше всего посетителей.
• [ ] Поддержка хостинга советует "оптимизировать код/снизить нагрузку" вместо решения проблемы.
• [ ] Вам нужен постоянно работающий процесс (очередь, бот, воркер), а не только реакция на HTTP-запрос.
• [ ] Cron должен запускаться чаще, чем позволяет тариф, или запускать команды за пределами разрешённого списка.
• [ ] Нужна конкретная версия языка/БД/расширения, которой нет в панели хостинга.
• [ ] У вас несколько сайтов на одном аккаунте, и "тяжёлый" начал мешать остальным.
• [ ] Расчёт по методике выше (тариф + время + потери) показывает, что шаред уже дороже минимального VPS.
• [ ] Рост бизнеса предсказуем на ближайшие полгода-год, и вопрос "когда переезжать" всё равно не "если", а "когда" — тогда логичнее сделать это на своих условиях, а не в панике при очередном падении в пиковый день.

Если совпало 3 и больше пунктов — это уже не гипотетический вопрос "а может подождать", а прямой сигнал начинать планировать переезд, пока это можно сделать спокойно, а не разгребая аварию.

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