Как понять, что проблема сайта не в CMS, а в хостинге

Когда сайт начинает тормозить, выдавать ошибки или странно вести себя в админке, первым подозреваемым часто становится CMS. Владелец думает: «Наверное, WordPress тяжёлый», «OpenCart опять глючит», «плагин что-то сломал», «тема плохо написана». Иногда так и есть. CMS, плагины, шаблоны и база данных действительно могут создавать много проблем.

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

В такие моменты нужно проверить не только CMS, но и хостинг. Сайт может быть собран нормально, но текущая площадка уже не даёт ему достаточно ресурсов или имеет ограничения, которые мешают работе.

Главная сложность в том, что проблемы CMS и хостинга часто выглядят похоже. Медленная страница может быть следствием тяжёлого плагина, плохого SQL-запроса, слабого тарифа, перегруженного диска или ботов. Поэтому нужен не спор «виновата CMS или хостинг», а спокойная диагностика.

CMS и хостинг работают вместе

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

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

Поэтому вопрос лучше формулировать так: сайт тормозит из-за плохой логики внутри CMS или из-за того, что хостинг не справляется с нормальной для этого проекта нагрузкой?

Проблема появляется только в часы нагрузки

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

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

А вот хостинговые лимиты часто проявляются волнами:

• при нескольких одновременных посетителях;
• во время работы бэкапа;
• при запуске импорта;
• после очистки кэша;
• во время рекламной кампании;
• при активном сканировании ботами;
• когда на общем сервере растёт нагрузка.

Если ошибки плавают и совпадают с нагрузкой, стоит смотреть лимиты CPU, памяти, процессов и базы.

Одинаковые ошибки появляются в разных частях сайта

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

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

Разные симптомы в разных местах могут говорить о нехватке общих ресурсов. Например:

• мало памяти для PHP;
• достигнут лимит процессов;
• заканчивается место на диске;
• база данных отвечает медленно;
• сервер прерывает долгие операции;
• файловая система работает с задержками.

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

Ошибки 500, 503 и 504 повторяются без явной причины

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

Ошибка 500 может появиться из-за ошибки в коде, неправильного.htaccess, несовместимой версии PHP, нехватки памяти или сбоя во время выполнения скрипта.

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

Ошибка 504 говорит о таймауте: один компонент слишком долго ждал ответа от другого.

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

Полезно сопоставить время ошибок с логами. Например, ошибка 503 в момент пика посещений может указывать на нехватку процессов. Ошибка 500 при импорте — на память или время выполнения. Ошибка 504 при открытии отчёта — на долгий запрос к базе.

Админка работает хуже после роста сайта

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

В такой ситуации часто винят CMS. Но админка выполняет много динамических действий, которые сильнее зависят от ресурсов хостинга. Кэш здесь помогает меньше.

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

Признаки, что проблема может быть не только в CMS:

• админка особенно тормозит при массовых действиях;
• сохранение иногда завершается ошибкой;
• бэкап или импорт обрывается;
• обновления проходят нестабильно;
• память PHP достигает лимита;
• в логах есть таймауты.

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

На тестовой копии в другой среде сайт работает быстрее

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

Такой тест не всегда идеален. Нужно учитывать версию PHP, настройки базы, кэш, конфигурацию сервера, включённые модули, размер ресурсов. Но если разница большая, это сильный аргумент.

Например:

• на старом хостинге админка открывается 8 секунд;
• на тестовом сервере с теми же файлами — 2 секунды;
• импорт на старом хостинге обрывается;
• на тестовом проходит полностью;
• та же страница на другом сервере не даёт ошибки памяти.

После такого сравнения уже сложнее утверждать, что виновата только CMS.

Версия PHP или лимиты PHP не подходят сайту

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

Проверить стоит:

• версию PHP;
• memory_limit;
• max_execution_time;
• upload_max_filesize;
• post_max_size;
• доступные расширения PHP;
• настройки OPcache;
• лимиты процессов.

Например, CMS может быть настроена нормально, но импорт товаров не проходит из-за слишком малого времени выполнения скрипта. Или резервное копирование падает из-за нехватки памяти. Или новая версия плагина требует расширение PHP, которого нет на сервере.

В таком случае проблема не в самой CMS. Ей просто не хватает подходящего окружения.

Сайт упирается в память

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

Типичные случаи:

• создание резервной копии;
• обработка большого изображения;
• массовый импорт товаров;
• генерация отчёта;
• обновление CMS или плагина;
• открытие тяжёлой страницы в админке;
• работа с большим количеством записей.

Если в логах встречаются сообщения о нехватке памяти, нужно не гадать, а проверить текущийmemory_limitи реальное потребление сайта.

Иногда проблему решает оптимизация кода или уменьшение объёма данных за один запуск. Иногда сайту нужен тариф с большим запасом памяти.

База данных работает медленно не из-за CMS

Медленная база может быть проблемой CMS: плохие запросы, отсутствие индексов, мусорные таблицы, тяжёлые плагины. Но бывает и серверная причина: база размещена на перегруженном узле, ограничены ресурсы, диск отвечает медленно, соединения ограничены.

Если медленно работают почти все запросы, а не один конкретный модуль, нужно проверять сервер базы. Особенно если:

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

CMS может делать запросы правильно, но если база работает медленно на уровне хостинга, сайт всё равно будет тормозить.

Диск или файловая система тормозят работу

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

Это особенно заметно на сайтах с большим количеством мелких файлов: кэш, миниатюры, галереи, почта, старые архивы, резервные копии.

Признаки проблемы:

• долго открывается файловый менеджер;
• медленно загружаются изображения в админке;
• кэш создаётся с задержкой;
• обновление CMS долго распаковывает файлы;
• резервное копирование идёт слишком медленно;
• сайт тормозит при операциях с файлами.

Если CMS та же, а на сервере с быстрым диском операции проходят заметно быстрее, причина может быть в хостинге или типе хранилища.

Лимит количества файлов уже близко

Владелец часто смотрит только на место: занято 5 ГБ из 20 ГБ, значит, всё нормально. Но на хостинге может быть лимит количества файлов и папок. Его часто называют inode.

CMS может создавать много мелких файлов: кэш, миниатюры изображений, временные данные, сессии, старые бэкапы, почта. В итоге место ещё есть, а лимит файлов уже близко.

Когда такой лимит достигается, сайт может перестать создавать новые файлы. Это выглядит как ошибка CMS: не загружается картинка, не создаётся кэш, не сохраняется файл. Но настоящая причина — ограничение файловой системы на хостинге.

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

Фоновые задачи ломают работу сайта

CMS часто запускает фоновые процессы: cron, очистка кэша, резервные копии, импорт, отправка писем, генерация sitemap, обновление цен, проверка безопасности. Если ресурсов мало, такие задачи могут мешать посетителям и админке.

Например, сайт работает нормально, пока не начинается бэкап. Или всё хорошо, пока не стартует импорт. Или каждую ночь после cron в логах появляются ошибки.

Это не обязательно проблема CMS. Возможно, задача нормальная, но текущий хостинг не даёт ей достаточно ресурсов или времени.

Что проверить:

• какие cron-задачи запускаются;
• в какое время;
• сколько они выполняются;
• нет ли дублирующихся задач;
• не запускается ли бэкап в часы посещаемости;
• не пишет ли задача огромные логи;
• не достигает ли PHP лимита времени.

Иногда проблему решает перенос тяжёлых задач на другое время. Иногда — разделение задач на части. Иногда — более подходящий хостинг.

Боты создают нагрузку, а CMS кажется виноватой

В обычной аналитике может быть мало посетителей, но серверные логи показывают сотни запросов от роботов. Они обходят страницы, параметры, фильтры, поиск, несуществующие адреса, старые URL и формы.

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

Владелец видит медленный сайт и думает, что CMS тяжёлая. На самом деле часть проблемы создаёт нежелательный трафик. Хостинг при этом может упираться в лимиты процессов или CPU.

Проверять нужно не только Google Analytics, а серверные access-логи:

• частые IP;
• User-Agent;
• запрашиваемые URL;
• количество запросов в минуту;
• обращения к фильтрам и поиску;
• ошибки 404 и 403;
• пиковые интервалы.

Если нагрузку создают боты, замена CMS не решит проблему. Нужно ограничивать мусорные запросы, настраивать robots.txt, закрывать технические URL, включать защиту от частых обращений.

Почта и сайт мешают друг другу

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

Владелец может искать проблему в CMS, хотя часть ресурсов заняла почта. Например, место заканчивается не из-за изображений сайта, а из-за старых писем с вложениями.

Проверить стоит:

• размер почтовых ящиков;
• количество писем;
• очередь отправки;
• ошибки доставки;
• лимиты отправки писем;
• попадают ли формы сайта в почтовые ограничения.

Если сайт активно отправляет уведомления, почтовая часть тоже влияет на стабильность.

После оптимизации CMS проблема осталась

Хороший способ не ошибиться — сначала убрать очевидные проблемы CMS. Например:

• отключить лишние плагины;
• проверить тему;
• сжать изображения;
• настроить кэш;
• почистить базу;
• обновить PHP на совместимую версию;
• проверить ошибки в коде;
• убрать дублирующиеся модули;
• отключить тяжёлую статистику внутри CMS.

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

Важно: перенос на более мощный хостинг не должен заменять оптимизацию. Если сайт плохо собран, он будет потреблять лишние ресурсы в любой среде. Но если сайт уже приведён в порядок, а площадка остаётся узким местом, нужно менять условия размещения.

Как собрать данные перед обращением в поддержку

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

• Время, когда возникла проблема.
• Какая страница или действие тормозит.
• Какие ошибки видит пользователь.
• Есть ли ошибки в логах CMS.
• Есть ли ошибки в серверных логах.
• Сколько места занято на диске.
• Не достигнут ли лимит файлов.
• Какая версия PHP используется.
• Какие лимиты PHP установлены.
• Что показывает статистика ресурсов в панели.
• Не запускались ли в это время бэкапы, импорты или cron.

Такой набор помогает быстрее понять, где проблема: в коде, базе, настройках CMS или ресурсах хостинга.

Когда стоит смотреть в сторону другого тарифа

Переход на более мощный тариф или другой тип размещения стоит рассматривать, если совпадают несколько признаков:

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

Для сравнения параметров можно посмотреть, какие возможности обычно указывают для размещения сайтов на Linux: пример описания Linux-хостинга. При оценке важно смотреть не только на цену и диск, но и на версии PHP, работу с базами, почту, SSL, резервные копии, удобство управления и возможность роста.

Когда проблема всё-таки в CMS

Чтобы не сваливать всё на хостинг, нужно помнить и обратную сторону. CMS может быть настоящей причиной, если:

• ошибка началась сразу после установки плагина;
• конкретная страница всегда тормозит из-за одного модуля;
• тема подключает слишком много скриптов;
• база забита мусором и медленными запросами;
• код делает лишние обращения к API;
• кэш отключён или настроен неправильно;
• сайт использует устаревшие расширения;
• на тестовом сервере с теми же лимитами проблема повторяется.

В таких случаях смена хостинга может временно скрыть проблему, но не исправить её. Сайт продолжит расходовать ресурсы неэффективно.

Правильная диагностика экономит деньги

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

Лучше идти по порядку: смотреть логи, проверять ресурсы, тестировать копию, сравнивать поведение в разное время, отключать подозрительные модули на тесте, анализировать базу и только потом принимать решение.

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

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