Сайт стал медленнее, страницы периодически открываются по несколько секунд, в панели управления появляются сообщения о превышении лимитов, а посетители иногда сталкиваются с ошибками 500, 502 или 503. В такой ситуации легко решить, что виноват хостинг и пора переходить на более дорогой тариф. Иногда это действительно правильное решение. Но точно такие же симптомы могут появиться из-за плохо работающего плагина, разросшейся базы данных, агрессивных ботов, неправильного кэширования или ошибки в коде.
Покупать дополнительные ресурсы, не разобравшись в причине, не всегда разумно. Если один неудачный плагин постоянно загружает процессор, он продолжит делать это и на более дорогом тарифе. Сайт какое-то время будет работать быстрее только потому, что получил больше мощности, но сама проблема никуда не исчезнет.
Бывает и наоборот. Владелец месяцами оптимизирует изображения, удаляет плагины и чистит базу данных, хотя проект давно вырос из возможностей самого дешевого тарифа. В таком случае оптимизация полезна, но кардинально ситуацию уже не изменит.
Чтобы понять, хватает ли сайту ресурсов хостинга, нужно смотреть не на один показатель, а сразу на несколько: CPU, оперативную память, PHP-процессы, базу данных, дисковые операции, свободное место и поведение сайта во время роста нагрузки.
Какие ресурсы хостинга использует сайт
Когда в описании тарифа указано 10, 20 или 50 ГБ NVMe, это только объем дискового пространства. Большой диск еще не означает высокую производительность. Сайт может занимать всего 1 ГБ из доступных 20 ГБ и при этом регулярно достигать процессорных ограничений тарифа.
Для работы динамического сайта используются процессорное время CPU, оперативная память RAM, дисковая подсистема, PHP-процессы, база данных и сетевые ресурсы. На виртуальном хостинге дополнительно устанавливаются ограничения на количество одновременно выполняемых процессов, число файлов, операции ввода-вывода и другие параметры.
Такие ограничения необходимы потому, что на одном физическом сервере работают сайты разных клиентов. Если одному аккаунту разрешить бесконтрольно использовать процессор или память, его нагрузка начнет влиять на остальных пользователей сервера.
Поэтому при выборе тарифа важно смотреть не только на объем диска и количество сайтов. Два предложения с одинаковыми «20 ГБ NVMe» могут заметно отличаться по реальной производительности.
Как понять, что хостинг не справляется с сайтом
Самый очевидный признак сайт начинает работать медленнее, но одной низкой скорости недостаточно, чтобы обвинять сервер. Загрузка страницы состоит из нескольких этапов. Сначала браузер определяет IP-адрес домена через DNS, устанавливает соединение, получает ответ сервера, загружает HTML, CSS, JavaScript, изображения, шрифты и только после этого окончательно отображает страницу. Если сервер возвращает HTML быстро, а затем браузер долго скачивает фотографии размером по несколько мегабайт, переход на более мощный тариф почти ничего не даст. Здесь нужно оптимизировать сам сайт.
Гораздо интереснее другая ситуация: после отправки запроса сервер долго не начинает передавать страницу. Особенно подозрительно, если задержка появляется именно в часы высокой посещаемости и одновременно панель хостинга фиксирует превышение ресурсов. Поэтому первым делом необходимо определить, где именно возникает замедление.
Высокий TTFB как признак проблем с сервером
Для диагностики серверной части полезно обратить внимание на TTFB — Time to First Byte. Это время между запросом браузера и получением первого байта ответа от сервера.
Высокий TTFB может появляться из-за медленной обработки PHP, тяжелых запросов к базе данных, отсутствия кэширования, перегрузки сервера, ограничений тарифа или обращения сайта к медленным внешним сервисам.
Один только высокий TTFB еще не доказывает нехватку ресурсов. Намного полезнее сравнивать показатели в разные периоды.
Например, ночью страница начинает отвечать быстро, а днем время ожидания первого байта возрастает в несколько раз. Если в те же часы увеличивается нагрузка на CPU и достигаются ограничения PHP-процессов, вероятность нехватки ресурсов становится гораздо выше.
Если же TTFB постоянно высокий даже при практически нулевой посещаемости, сначала стоит проверить CMS, плагины, базу данных и конфигурацию сайта.
Как понять, что сайту не хватает CPU
CPU — один из основных ресурсов динамического сайта. Процессор выполняет PHP-код, обрабатывает запросы CMS, участвует в работе плагинов, формировании страниц и множестве других операций.
На виртуальном хостинге пользователь обычно получает не процессор целиком, а определенную долю вычислительных ресурсов. Конкретный способ ограничения зависит от провайдера и используемой инфраструктуры.
Кратковременная загрузка CPU до максимума сама по себе не является проблемой. Например, процессор может активно использоваться во время обновления CMS, создания резервной копии, импорта товаров, сканирования файлов или генерации изображений.
Совсем другая ситуация, когда лимит CPU достигается регулярно и остается на максимуме продолжительное время. Если одновременно сайт начинает отвечать медленнее, это уже серьезный повод для диагностики.
Но даже здесь не нужно сразу переходить на дорогой тариф. Сначала следует выяснить, кто именно потребляет процессорное время.
Почему сайт создает высокую нагрузку на CPU
Высокое потребление процессора бывает естественным и ненормальным. Естественная причина рост проекта. Посетителей стало больше, страниц больше, операций больше, поэтому сервер выполняет больше работы.
Но процессор могут нагружать и совершенно другие вещи: плохо написанный плагин, некорректно работающий cron, тяжелая тема WordPress, постоянная генерация страниц без кэша, агрессивные поисковые роботы, перебор паролей, вредоносный код или сложные запросы к базе данных.
Иногда один бот способен создать нагрузку, сопоставимую с тысячами обычных посетителей. Он быстро перебирает страницы, фильтры, параметры URL или обращается к поиску сайта. Владелец видит высокий CPU и считает, что проект вырос, хотя реальных пользователей больше не стало.
Поэтому при постоянной загрузке процессора полезно сопоставить графики CPU с посещаемостью и журналами запросов.
Если посещаемость выросла в три раза и одновременно увеличилась нагрузка, все логично. Если пользователей столько же, а CPU внезапно начал постоянно достигать лимита, нужно искать изменение внутри сайта или необычный внешний трафик.
Как понять, что сайту не хватает оперативной памяти
С оперативной памятью ситуация немного сложнее, особенно на виртуальном хостинге. Пользователь не всегда видит реальный объем RAM физического сервера. Провайдер может показывать лимит памяти для аккаунта или отдельных процессов. Кроме того, существует PHP memory_limit, который часто принимают за общий объем доступной оперативной памяти. Если WordPress сообщает об ошибке вида «Allowed memory size exhausted», это означает, что конкретный PHP-процесс достиг установленного ограничения памяти. Это не обязательно говорит о том, что вся RAM сервера полностью занята.
На VPS уже можно анализировать общую память системы. Если свободной RAM практически не остается, сервер начинает испытывать проблемы. При использовании swap часть данных переносится на диск, который значительно медленнее оперативной памяти. Небольшое использование swap само по себе не всегда означает аварию, но постоянный активный обмен данными между RAM и диском способен серьезно ухудшить производительность.
Если память заканчивается регулярно, необходимо выяснить, какие процессы ее используют. Простое увеличение RAM иногда решает проблему, но при утечке памяти или неправильно работающем приложении новый объем тоже со временем будет заполнен.
Почему появляется ошибка 503 Service Unavailable
Ошибка 503 означает, что сервер в данный момент не может нормально обработать запрос. У нее есть несколько возможных причин, и превышение ресурсов является одной из них.
Для виртуального хостинга характерен сценарий, когда сайт нормально работает большую часть времени, но при увеличении количества одновременных запросов начинает периодически возвращать 503. Через некоторое время нагрузка снижается, и страницы снова открываются как обычно.
Если панель хостинга в этот же период показывает достижение ограничений CPU, памяти или процессов, связь становится очевиднее.
Однако считать каждую ошибку 503 доказательством нехватки ресурсов нельзя. Она может быть вызвана техническими работами, программной ошибкой, неправильной конфигурацией веб-сервера или проблемами приложения.
Именно поэтому при диагностике важна не сама ошибка, а события, которые происходили на сервере одновременно с ней.
Что такое лимит PHP-процессов и почему он важен
На динамическом сайте PHP участвует в формировании страниц. Когда посетитель запрашивает страницу WordPress, серверу может потребоваться выполнить PHP-код, обратиться к базе данных, обработать полученную информацию и сформировать HTML.
При большом количестве одновременных запросов требуется больше рабочих процессов. На виртуальном хостинге их количество обычно ограничивается.
Пока нагрузка небольшая, пользователь ничего не замечает. Но если все доступные процессы заняты, новым запросам приходится ждать освобождения ресурсов. При определенных условиях посетитель может получить ошибку вместо страницы.
Здесь особенно хорошо видно, почему нельзя оценивать мощность хостинга только по количеству гигабайт. У аккаунта может оставаться 90 ГБ свободного пространства из 100 ГБ, но это никак не поможет, если сайт достиг лимита одновременно выполняемых процессов.
Для WordPress и других популярных CMS правильно настроенное кэширование значительно снижает такую нагрузку. Если готовая страница может быть отдана без полноценного выполнения всей цепочки PHP и SQL, сервер способен обслужить больше запросов на тех же ресурсах.
Сайт начал тормозить после роста посещаемости
Один из наиболее понятных признаков нехватки ресурсов проблемы появились одновременно с реальным ростом аудитории. Допустим, сайт несколько лет получал 500 посетителей в сутки и прекрасно работал на недорогом виртуальном хостинге. Затем посещаемость выросла до нескольких тысяч человек. Одновременно увеличился TTFB, процессор начал регулярно достигать лимита, а в часы пик появились ошибки. В таком случае вполне возможно, что проект действительно перерос тариф.
Но перед переходом на более дорогой вариант все равно стоит проверить кэширование и самые тяжелые операции. Иногда небольшая оптимизация позволяет обслуживать значительно больше пользователей без увеличения расходов на сервер.
Особенно это касается информационных сайтов. Если тысячи посетителей читают одни и те же статьи, нет необходимости каждый раз заново выполнять одинаковые PHP-операции и запросы к базе данных. Грамотно настроенный кэш способен существенно снизить нагрузку.
У интернет-магазина ситуация сложнее. Корзина, личный кабинет, оформление заказа, индивидуальные цены и некоторые другие страницы требуют динамической обработки. Поэтому возможности полного кэширования здесь ограничены.
Превышение лимитов в панели управления хостингом
Если хостинг предоставляет статистику использования ресурсов, именно с нее лучше начинать диагностику. В зависимости от панели и провайдера можно увидеть загрузку CPU, потребление памяти, количество процессов, дисковые операции, трафик, место на диске и другие показатели.
Смотреть нужно не только на текущие значения. Гораздо полезнее история за сутки, неделю или месяц. Допустим, сегодня в 14:00 сайт работал очень медленно. Открываем статистику за этот период и видим, что процессор находился на предельном значении с 13:50 до 14:20. Это уже полезная информация.
Если подобная картина повторяется каждый день в часы максимальной посещаемости, повышение доступных ресурсов действительно может быть оправдано. А вот единичный всплеск нагрузки в три часа ночи, когда выполнялось резервное копирование, вряд ли является причиной менять тариф.
Что делать, если хостер сообщает о превышении нагрузки
Иногда ждать симптомов не приходится — провайдер сам присылает уведомление о том, что аккаунт регулярно превышает допустимую нагрузку. Игнорировать такое письмо не стоит, но и немедленно покупать самый дорогой тариф тоже не обязательно. Сначала попросите техническую поддержку уточнить, какой именно ресурс превышен, когда это происходило и какие процессы создавали нагрузку.
Фраза «ваш сайт потребляет слишком много ресурсов» дает мало полезной информации. Гораздо интереснее получить конкретику: в определенное время аккаунт достиг ограничения CPU, основная нагрузка пришлась на PHP-запросы к определенному сайту. После этого уже можно искать причину.
Хорошая техническая поддержка часто способна подсказать, где находится источник аномальной нагрузки, хотя оптимизация самого сайта обычно не входит в обязанности хостера.
Почему WordPress тормозит в админке, а сам сайт работает быстро
Это отдельный случай, который легко принять за нехватку мощности. Посетители быстро открывают страницы, но администратор ждет по пять или десять секунд при переходе между разделами WordPress.
Дело может быть в том, что публичная часть сайта хорошо кэшируется, а административная панель работает динамически. Кроме того, некоторые плагины выполняют дополнительные операции именно внутри wp-admin. Например, модуль статистики при каждом открытии страницы может строить сложный отчет, плагин резервного копирования — проверять состояние архивов, а внешний сервис — слишком долго отвечать на запрос.
В таком случае увеличение мощности сервера способно немного улучшить ситуацию, но сначала правильнее найти конкретную причину медленной работы административной панели.
Как база данных влияет на скорость сайта
MySQL или MariaDB часто становится еще одним источником задержек. Особенно это заметно на давно работающих сайтах. База WordPress постепенно накапливает ревизии записей, временные данные, настройки, служебные записи и информацию, оставшуюся после некоторых удаленных плагинов. Отдельные плагины могут создавать собственные таблицы и годами записывать туда статистику или журналы событий.
Но размер базы сам по себе еще не определяет ее скорость. Намного важнее структура таблиц, индексы и характер запросов. Небольшая база с неудачным запросом способна создавать больше проблем, чем гораздо более крупная, но нормально оптимизированная. Если определенный запрос при каждом открытии страницы перебирает огромный массив данных, по мере роста проекта он будет выполняться все дольше.
Можно перенести сайт на мощный VPS и временно получить ускорение. Но плохой запрос останется плохим запросом. Поэтому при подозрении на базу данных лучше сначала определить самые тяжелые операции.
Может ли сайт тормозить из-за заполненного диска
Да. Хотя свободное место и вычислительная производительность являются разными ресурсами, почти полностью заполненный диск способен вызвать серьезные проблемы.
Сайту требуется свободное пространство для временных файлов, кэша, логов, обновлений и других операций. Базе данных тоже необходимо нормально записывать изменения.
Если тариф предоставляет 10 ГБ и занято уже 9,9 ГБ, формально лимит еще не превышен, но комфортного пространства для работы практически нет.
Особенно часто диск неожиданно заполняют резервные копии. Например, рабочий сайт занимает 3 ГБ, а внутри аккаунта лежат пять его полных архивов. В результате сами страницы занимают небольшую часть пространства, а основная емкость расходуется на старые бэкапы.
Еще одна распространенная причина — журналы ошибок. При программной проблеме лог может постоянно пополняться и за несколько дней вырасти до внушительного размера.
Поэтому при неожиданной нехватке места сначала нужно выяснить, какие именно каталоги и файлы занимают диск.
Что такое inode и почему свободные гигабайты могут не помочь
Некоторые тарифы ограничивают не только общий размер данных, но и количество файлов и каталогов, которое может создать пользователь. Такое ограничение часто связано с inode.
Представим аккаунт, на котором разрешено хранить 20 ГБ. Использовано только 8 ГБ, поэтому кажется, что места еще предостаточно. Но сайт создал огромное количество мелких файлов и достиг допустимого количества inode.
В результате новые файлы создавать уже нельзя, хотя свободные гигабайты остаются.
С большим количеством файлов особенно часто сталкиваются сайты с кэшем, множеством изображений и их миниатюр, почтой или большим количеством отдельных проектов в одном аккаунте.
Поэтому при странной ситуации «место есть, а хостинг сообщает о лимите» стоит проверить ограничения по количеству файлов.
Как боты создают нагрузку на хостинг
Не вся посещаемость сайта состоит из людей. Страницы постоянно обходят поисковые роботы, SEO-сервисы, парсеры, сканеры уязвимостей и множество других автоматических систем.
Обычные поисковые роботы необходимы для индексации и обычно ведут себя достаточно предсказуемо. Проблему могут создавать агрессивные парсеры и боты, которые отправляют сотни или тысячи запросов за короткое время.
Особенно тяжелыми оказываются запросы к внутреннему поиску, фильтрам интернет-магазина и динамическим страницам, которые плохо кэшируются.
В статистике при этом может выглядеть так, будто посещаемость резко выросла. На практике реальных покупателей или читателей больше не стало — сервер просто занят обработкой автоматических запросов.
Перед покупкой нового тарифа полезно проверить журналы доступа. Если огромная доля запросов поступает от нежелательных ботов, правильная фильтрация способна освободить значительную часть ресурсов.
Как плагины WordPress могут перегрузить хостинг
Само количество плагинов почти ничего не говорит о производительности WordPress. Двадцать аккуратно написанных расширений могут работать легче, чем один неудачный плагин.
Особенно внимательно стоит относиться к расширениям, которые постоянно выполняют фоновые задачи, собирают статистику, сканируют файлы, создают резервные копии, обращаются к внешним сервисам или выполняют сложные запросы к базе.
Если проблемы начались после установки или обновления определенного плагина, это важная подсказка.
Можно временно отключить подозрительное расширение и сравнить нагрузку. Делать такие эксперименты на рабочем интернет-магазине лучше осторожно, а при возможности — на тестовой копии сайта.
Если после отключения одного модуля CPU падает в несколько раз, покупать дополнительный процессор ради сохранения проблемного плагина вряд ли разумно.
Как проверить, хватает ли сайту ресурсов хостинга
Диагностику удобнее проводить последовательно. Сначала зафиксируйте проблему: когда именно сайт тормозит, какие страницы открываются медленно и появляются ли ошибки.
Затем откройте статистику хостинга за тот же период. Проверьте CPU, память, процессы, дисковые ограничения и свободное место.
После этого сравните нагрузку с посещаемостью. Если проблемы возникают при увеличении реального трафика, проект может действительно приближаться к пределам тарифа.
Если посещаемость не менялась, посмотрите, что изменилось на самом сайте. Возможно, недавно обновился плагин, был установлен новый модуль, запущен импорт или появилась необычная активность ботов.
Отдельно проверьте кэширование. Для WordPress отсутствие нормального страничного кэша способно многократно увеличить количество PHP-операций.
Затем стоит посмотреть базу данных, фоновые задачи и журналы ошибок. Если самостоятельно определить причину сложно, обратитесь в поддержку хостинга и попросите данные о превышениях за конкретное время.
Такой подход гораздо информативнее вопроса «почему мой сайт тормозит?».
Когда нужно переходить на более мощный тариф хостинга
Повышение тарифа оправдано, когда сайт нормально оптимизирован, но реальные потребности проекта выросли.
Например, увеличилась посещаемость, расширился каталог интернет-магазина, появилось больше одновременных пользователей или добавились функции, которые объективно требуют дополнительных вычислений.
Хороший признак — повторяемость проблемы. Ресурсы достигают лимита каждый день, это совпадает с периодами реальной нагрузки, а очевидных программных ошибок нет.
В такой ситуации переход на следующий тариф может быть самым простым и правильным решением.
Особенно удобно, если хостер позволяет изменить тариф без переноса сайта и длительного простоя.
Когда увеличение тарифа не решит проблему
Дополнительные ресурсы не являются универсальным лекарством.
Если сайт заражен вредоносным кодом и тот постоянно выполняет посторонние процессы, новый тариф лишь даст вредоносной программе больше мощности.
Если плагин создает бесконечные фоновые задачи, он продолжит их создавать.
Если база выполняет неоптимальный запрос, более быстрый процессор ускорит его, но причина останется.
Если страницы весят по 15 МБ из-за огромных изображений, дополнительная RAM на сервере не сделает интернет пользователя быстрее.
Поэтому перед повышением тарифа нужно хотя бы приблизительно понимать источник проблемы.
Когда пора переходить с виртуального хостинга на VPS
VPS нужен не каждому растущему сайту. Современный качественный виртуальный хостинг способен обслуживать достаточно серьезные проекты, а управление собственным сервером добавляет новые обязанности.
На VPS стоит смотреть, когда ограничения обычного хостинга действительно начинают мешать проекту или требуется конфигурация, которую провайдер не позволяет изменить.
Причинами перехода могут стать стабильно высокая нагрузка, необходимость гарантированного объема RAM, особые версии программного обеспечения, собственная конфигурация веб-сервера, специфические фоновые службы или потребность в полном контроле над окружением.
При этом VPS не делает сайт быстрым автоматически.
Неуправляемый и плохо настроенный VPS способен работать хуже хорошего виртуального хостинга. Кроме производительности придется заниматься обновлениями системы, безопасностью, резервным копированием, мониторингом и восстановлением после сбоев либо оплачивать администрирование.
Поэтому переходить на VPS стоит тогда, когда понятно, зачем именно он нужен.
Сколько ресурсов нужно сайту
Универсальной формулы вида «1000 посетителей = 1 ГБ RAM» не существует.
Два сайта с одинаковой посещаемостью способны отличаться по нагрузке в десятки раз.
Статическая страница почти не требует серверных вычислений. Хорошо кэшируемый информационный WordPress-сайт тоже может обслуживать значительный трафик на относительно скромном сервере.
Интернет-магазин с фильтрами, поиском, личными кабинетами и корзинами создает совершенно другую нагрузку.
На потребление ресурсов влияют CMS, плагины, тема, версия PHP, кэширование, количество запросов к базе, структура базы данных, поведение пользователей, количество одновременных посетителей и даже характер поисковых роботов.
Поэтому выбирать тариф только по посещаемости неправильно. Надежнее смотреть на фактическую нагрузку конкретного проекта.
Как отличить плохой хостинг от нехватки ресурсов тарифа
Это важное различие.
Если сайт достиг установленных ограничений своего тарифа, это еще не означает, что хостинг плохой. Возможно, проект просто вырос.
Но если сервер работает нестабильно даже при небольшой нагрузке, регулярно возникают проблемы на стороне провайдера, поддержка не может объяснить причины сбоев, а производительность сильно меняется без связи с вашим трафиком, стоит задуматься уже о качестве самой площадки.
Полезный эксперимент — временно протестировать сайт в другом окружении с сопоставимыми ресурсами. Если на новом сервере тот же проект без дополнительной оптимизации работает заметно стабильнее, причина может находиться в инфраструктуре прежнего провайдера.
При этом сравнение должно быть корректным. Бессмысленно переносить сайт с самого дешевого виртуального тарифа на мощный VPS и после этого делать вывод, что первый хостер был плохим.
Что проверить перед сменой хостинга
Перед переездом полезно собрать факты. Проверьте историю нагрузки CPU и памяти, количество процессов, свободное место, inode, TTFB, журналы ошибок и статистику посещаемости.
Уточните у поддержки, какие ограничения достигаются и в какое время.
Проверьте кэширование, плагины, фоновые задачи и базу данных. Посмотрите, нет ли аномальной активности ботов.
Если после этого становится понятно, что проект стабильно упирается именно в возможности тарифа, можно выбирать более мощное решение.
Если же источник нагрузки обнаружен внутри сайта, сначала имеет смысл исправить его и посмотреть на результат.
Так можно избежать ситуации, когда сайт переезжает на новый сервер вместе со всеми старыми проблемами.
Что делать, если сайту не хватает ресурсов хостинга
Если нехватка ресурсов подтверждена, вариантов несколько.
Самый простой — перейти на следующий тариф у текущего провайдера. Это удобно, когда качество хостинга устраивает, а проекту просто стало тесно в прежних ограничениях.
Второй вариант — оптимизировать сайт. Кэширование, исправление тяжелых запросов, настройка базы, удаление ненужных фоновых операций и фильтрация агрессивных ботов иногда позволяют заметно снизить нагрузку.
Третий вариант — сменить хостинг, если текущий провайдер предлагает невыгодные условия масштабирования или качество его инфраструктуры не устраивает.
Четвертый — перейти на VPS/VDS, когда проекту требуется больше ресурсов и контроля над сервером.
Эти варианты не исключают друг друга. Нередко лучший результат дает комбинация: сначала устраняются очевидные проблемы сайта, затем проект переносится на тариф, соответствующий его реальной нагрузке.
Как выбрать хостинг, чтобы сайту хватало ресурсов
При выборе нового хостинга не стоит ориентироваться только на рекламные цифры вроде «50 ГБ NVMe», «безлимитный трафик» или «100 сайтов».
Для динамического проекта намного интереснее реальные ограничения CPU, RAM, PHP-процессов, базы данных и дисковых операций.
Хорошо, если провайдер открыто публикует эти параметры и позволяет посмотреть статистику их использования в панели управления.
Также важна возможность масштабирования. Сегодня небольшому сайту хватает начального тарифа, но через год посещаемость может вырасти в несколько раз. Чем проще перейти на следующий уровень без сложного переноса, тем спокойнее будет развитие проекта.
Стоит обратить внимание и на техническую поддержку. Когда сайт внезапно начинает тормозить, ответ «оптимизируйте ваш сайт» помогает мало. Намного полезнее, если специалист может указать, какой лимит был достигнут и в какое время это произошло.
Как понять, что действительно пора менять тариф
Один медленный вечер еще не повод переносить сайт. Разовый пик CPU после создания резервной копии тоже.
О нехватке ресурсов лучше говорить тогда, когда появляется устойчивая картина: сайт регулярно достигает ограничений, проблемы совпадают по времени с высокой нагрузкой, оптимизация не устраняет их полностью, а проект продолжает расти.
В этом случае более мощный тариф — не лишняя трата денег, а нормальный этап развития сайта.
Если же нагрузка возникла внезапно при прежней посещаемости, сначала нужно искать причину. Проверить плагины, базу данных, cron, ботов, кэш и журналы ошибок обычно дешевле, чем бесконечно увеличивать серверные мощности.
Главное — не пытаться определить состояние хостинга по одному признаку. Медленный сайт еще не означает слабый сервер, высокий CPU еще не означает необходимость VPS, а десятки свободных гигабайт не говорят о наличии свободных вычислительных ресурсов.
Смотрите на показатели вместе и сравнивайте их во времени. CPU, память, процессы, TTFB, база данных, посещаемость и ошибки обычно довольно быстро показывают, где находится настоящее узкое место. И только после этого имеет смысл решать, что выгоднее — оптимизировать сайт, повысить тариф, сменить хостинг или переходить на VPS.
