Почему мой сайт на WordPress медленно работает на виртуальном хостинге? В первую очередь проверьте эти пять моментов.

«Хостинг тормозит» — обычный диагноз, и чаще всего он ошибочный. В девяти случаях из десяти с сервером всё в порядке, а что-то работающее поверх него выполняет гораздо больше работы, чем необходимо.

Вот порядок, в котором мы обычно проводим проверку. И примерно в таком же порядке эти причины встречаются на практике.

1. Кеш. Кешируется ли вообще хоть что-нибудь? Проверьте заголовки ответа в приватном окне.
2. База данных. Сколько времени занимают запросы и сколько их выполняется?
3. Версия PHP. Та версия, на которой сайт действительно работает, а не та, которую показывает панель.
4. Плагины. Какой из них запускает медленные запросы и обработчики.
5. Соседи по серверу. Только теперь стоит подозревать общие ресурсы CPU и диска.

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

1. Кешируется ли вообще хоть что-нибудь?

Откройте сайт в приватном окне и посмотрите заголовки ответа:

curl -sI https://example.com/ | grep -iE 'x-litespeed-cache|cf-cache-status|age|cache-control'

x-litespeed-cache: hit означает, что страница была отдана из кеша и запрос вообще не дошёл до PHP. Если при каждом запросе вы получаете miss, каждый посетитель заставляет WordPress заново формировать страницу, обращаясь к базе данных. Обычно это 200–800 мс работы вместо примерно 5 мс.

Наиболее распространённые причины постоянного miss: отсутствие плагина кеширования, установленный, но не включённый плагин кеширования, cookie, устанавливаемая при каждом запросе — так делают многие плагины чатов и управления согласием на cookies, из-за чего страницу невозможно кешировать, — либо отсутствие WP_CACHE в wp-config.php.

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

2. Сколько времени занимает работа базы данных?

Установите Query Monitor, откройте медленную страницу от имени администратора и посмотрите на два показателя: общее время выполнения запросов и их количество.

Для обычной страницы разумным показателем можно считать менее 100 запросов и менее 50 мс суммарного времени работы с базой данных. Сотни запросов обычно означают, что какой-то плагин запрашивает данные внутри цикла. А 500 мс работы базы данных на небольшом сайте часто указывают на запрос, для которого отсутствует необходимый индекс.

wp db query "SHOW FULL PROCESSLIST;" --allow-root   # что выполняется прямо сейчас
wp option get cron --format=json | head -c 400      # список cron, который никогда не очищается, — симптом проблемы

WordPress хранит временные данные (transients), сессии и оставшиеся от удалённых плагинов автоматически загружаемые параметры в wp_options. При каждой загрузке страницы WordPress считывает все записи с включённой автозагрузкой.

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

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb
             FROM wp_options WHERE autoload='yes';" --allow-root

Если размер превышает примерно 1 МБ — уже стоит заняться очисткой. Если больше 5 МБ — скорее всего, вы нашли свою проблему.

3. Какая версия PHP используется на самом деле?

Не та, которая указана в панели управления, а та, на которой действительно работает сайт.

PHP 8.3 примерно вдвое быстрее PHP 7.4 на типичных нагрузках WordPress, а поддержка безопасности PHP 7.4 закончилась ещё в 2022 году.

wp eval 'echo PHP_VERSION;' --allow-root

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

4. Найдите плагин, который создаёт нагрузку

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

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

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

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

5. И только теперь подозревайте соседей по серверу

Виртуальный хостинг подразумевает совместное использование ресурсов CPU и дисковой подсистемы.

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

В этом случае важны лимиты CPU и I/O вашего контейнера и то, достигаете ли вы этих ограничений. Нормальная панель управления должна показывать оба показателя.

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

На тарифах inSave каждый сайт работает в собственном контейнере со своими лимитами CPU, RAM и I/O, поэтому нагрузка соседнего сайта не может забрать ресурсы вашего проекта настолько, чтобы вывести его из строя. Панель при этом показывает, насколько близко сайт находится к установленным ограничениям.

LiteSpeed и LSCache доступны на всех тарифах, что для большинства сайтов сразу решает первый пункт из этого списка. А начиная с Shared Pro также доступен объектный кеш Redis.

Коротко

Сначала кеш, затем база данных, версия PHP, плагины — и только после этого соседи по серверу.

Четыре из пяти этих проблем можно исправить самостоятельно практически на любом хостинге. Именно поэтому совет «переехать на более быстрый хостинг» так часто разочаровывает: новый сервер запускает тот же самый неоптимизированный и ресурсоёмкий код — только теперь за большие деньги.