Что делать, если сайт на WordPress потребляет слишком много CP

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

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

Причины избыточного потребления CP у сайтов на WordPress

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

Итак, давайте начнём с того, что вообще такое эти CP.

CP (CPU time, Process Time, процессорное время) — это время, которое затрачивает процессор на выполнение определённой задачи. Например, на обработку скриптов, интерпретируемого кода или выполнение задач планировщика.

У меня на сайте есть статья о том, что такое CP, можете почитать, если интересно.

Конкретно для нашего случая это как раз процессорное время, затраченное на работу с сайтом на базе CMS WordPress. Данная система управления содержимым как раз и построена на интерпретируемом коде (это код, который не требует предварительной компиляции). PHP не требует компиляции, а файлы выполняются непосредственно при запросе. С одной стороны это удобный вариант, с другой может создавать чуть большую нагрузку, чем предварительно скомпилированный код.

Также содержит скрипты. Зависит о типа сайта, обычно скрипты на базе javascript, но при желании можно прикрутить и TipeScript. Да и вообще что угодно, зависит от фантазии разработчика.

Также у WordPress есть HTML, CSS, которые тоже подъедают немного процессорного времени, не забываем про собственный планировщик задач.

В общем, WP в силу своей универсальности довольно громоздкая система. Но зато заметно упрощает жизнь.

А теперь давайте посмотрим на самые распространённые проблемы, которые вынуждают сайт на WordPress «кушать» слишком много процессорного времени.

Попытки взлома и DDoS

Если потребление CP возросло внезапно, причём на очень высокие значения, то вас могут пытаться взломать. Или ваш сайт попал под DDoS-атаку. Такую проблему можно решить лишь частично, например, подключение AntiDDoS-защиты. Можно взять тот же AntiDDoS от CloudFlare.

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

От хакерских атак могут помочь плагины для защиты сайта, например, Wordfence. Но от DDoS это не спасёт. Такая атака генерирует колоссальное количество запросов к серверу, что попросту делает сайт нерабочим, а также может помочь злоумышленникам выявить уязвимости. А хостеров вынуждает отключать вашу услугу, так как DDoS-атака негативно сказывается и на других пользователях хостинга.

Так что если это DDoS, то лучше подключить защиту от него. Либо отключить сайт на время, атака прекратится, если сайт не будет доступен. Но нет никаких гарантий, что не возобновится вновь.

Вирусы

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

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

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

Проверить сайт на вирусы можно с помощью:

1. Virustotal: https://www.virustotal.com. Неплохой инструмент, но находит далеко не все вирусы.
2. Dr.Web: https://vms.drweb.ru/online/. Тоже вариант, но также находит не все вирусы. «Спящие» точно не заметит.
3. Imunify360. Это бывший AI-Bolit, который был просто топовым для поиска вирусни на сайтах. Но его выкупили, сделав Imunify360, а также выкатили минимальную цену в 12$. В принципе, вы до сих пор можете собрать AI-Bolit из исходников, хотя он сильно устарел. Впрочем, многие вирусы до сих пор находит.

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

Либо нужно искать хостинг со встроенным антивирусом.

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

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

Как правило они на своей стороне могут проанализировать работу вашего сайта. И либо найдут ошибки у вас, либо у себя.

У меня был один случай, что сайт внезапно начал потреблять слишком много CP. Проверял и логи сайта, и анализировал на атаку ботов, думая, что меня дудосят.

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

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

CDN

CDN (Content Delivery Network) или сеть доставки контента. Эта система предназначена для быстрой доставки контента. Как правило, скриптов, изображений, кэшированны HTML-страниц и других статических файлов.

Многие владельцы сайтов на WordPress частенько используют CDN, например, CloudFlare, так как она популярна по всему миру, некоторые используют региональные CDN, например те, что обеспечивают быструю доставку контента по целевому региону. Например, в России это Selectel или CDN от VK Group.

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

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

Боты

Я бы назвал это пусть и не главной, но очень большой проблемой. Ваш сайт индексируют роботы поисковых систем. И это не только Google и Яндекс. Есть ещё Bing, Yahoo, Baidu. И ещё куча мелких поисковых систем, которые тоже периодически обходят ваш сайт и создают дополнительную нагрузку.

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

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

Заблокировав маркетинговых ботов, я сократил нагрузку на сайт на 20%! Колоссальное число, верно? Учитывая, что иногда приходится биться чуть ли не за каждый CP.

У меня на сайте есть статьи про вредные и полезные боты, а также есть статья о том, как их блокировать.

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

Сначала заходим в личный кабинет сервера. А потом переходим в раздел «Журналы».

Там для нужных сайтов выбираем «Журнал доступа» и включаем его.

Если у вас несколько сайтов, а вы хотите узнать, какой именно сайт потребляет много CP, то перейдите в раздел «Сайты».

А там вы сможете посмотреть статистику по отдельным сайтам.

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

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

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

Ошибки

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

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

Но помогу с очевидными. Первым делом переходим в админку WordPress → Инструменты → Здоровье сайта.

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

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

Сам движок WordPress сделан хорошо и ошибки постоянно исправляют. Так что ваши проблемы кроются в теме и плагинах.

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

К сожалению, такое исправление требует понимания WordPress, понимание PHP, JS. Так что без подготовки этого не сделаешь. И на самом деле смысла исправлять чужие темы и плагины мало, так как при обновлении все ваши наработки слетят. Или придётся делать форк темы и плагинов, а потом поддерживать их самостоятельно.

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

Ну и ещё способ найти очевидные ошибки. Просто включите лог ошибок на вашем сайте. Например, на Бегет это можно сделать так. Перейдите в личный кабинет → Журналы → Включите лог ошибок.

И если на сайте будут ошибки PHP, то в логах ошибок вы увидите примерно следующее:

[Thu Oct 21 17:20:18 2021] [error] [client 77.88.9.137:47393] PHP Fatal error: Array and string offset access syntax with curly braces is no longer supported in /home/r/workinnet.ru/public_html/wp-content/plugins/rss-for-yandex-turbo/inc/Contents.php on line 177

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

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

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

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

Expiries (время истечения файлов), кэширование и gzip

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

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

Начнём с кэширования. Вам нужно установить плагин для него. Я обычно использую WP Super Cache, но для сервера с LSAPI вам понадобится плагин LiteSpeed Cache. Но суть у обоих простая. Рекомендую почитать инструкции по настройке WP Super Cache: https://sheensay.ru/wp-super-cache и Lite Speed Cache: https://tuthost.ua/faq/litespeed-cache-wordpress-settings/.

Но учтите, у WP Super Cache есть фишка, которая может создать огромную нагрузку на сайт: предварительная загрузка кэша.

Например, на одном сайте я увидел, что раз в 600 минут кэш полностью обновляется (на деле раз в 720 минут, так как это минимальное значение). И это создаёт гигантскую нагрузку на сервере. Если у вас много страниц, то вы можете из-за этой функции получить большие проблемы.

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

А теперь давайте добавим сжатие gzip. Это нужно сделать в файле .htaccess в корневой папке сайта. Туда добавьте следующий код после # END WordPress:

# сжатие text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/html text/css text/javascript text/xml text/plain image/x-icon image/svg+xml application/rss+xml application/javascript application/x-javascript application/xml application/xhtml+xml application/x-font application/x-font-truetype application/x-font-ttf  application/x-font-otf application/x-font-opentype application/vnd.ms-fontobject font/ttf font/otf font/opentype
# Совместимость с устаревшими браузерами
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

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

Потому добавляем в тот же файл ещё один код:

# кеш браузера: разрешаем истечение срока 
ExpiresActive On
#по умолчанию кеш в 5 секунд
ExpiresDefault "access plus 120 minutes"
# Включаем кэширование изображений и флэш на месяц
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType image/jpeg "access plus 4 weeks"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/gif "access plus 30 days"
ExpiresByType application/x-shockwave-flash "access plus 30 days"
# Включаем кэширование css, javascript и текстовых файлов на одиннадцать часов
ExpiresByType text/css "access plus 11 hours"
ExpiresByType text/javascript "access plus 11 hours"
ExpiresByType application/javascript "access plus 11 hours"
ExpiresByType application/x-javascript "access plus 11 hours"
# Включаем кэширование html и htm файлов на 2 часа
ExpiresByType text/html "access plus 120 minutes"
# Включаем кэширование xml файлов на десять минут
ExpiresByType application/xhtml+xml "access plus 600 seconds"
# Нестандартные шрифты сайта 
ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType application/x-font-woff "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"

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

WP Cron

Есть ещё одна проблема у WordPress — планировщик задач или wp-cron.php. И некоторые плагины прямо провоцируют его ежеминутно запускаться. Яркий пример — Rank Math. Планировщик задач — важный элемент, но иногда следует с ним поработать, чтобы он не грузил слишком сильно сайт.

Если запросить статистику от хостера, то можно увидеть следующее:

О файле admin-ajax поговорим дальше, а вот WP Cron может создать существенную нагрузку на сайт, если будет запускаться ежеминутно.

Предложу наиболее оптимальный вариант решения данной проблемы, начать следует с установки плагина WP Crontrol: https://wordpress.org/plugins/wp-crontrol/.

После его установки перейдите в настройки → Расписание Cron.

И в расписаниях найдите минимальное время событий помимо самой инициализации Cron.

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

Итак, заходим в корневую папку сайта через FTP или менеджер файлов хостинга и находим там файл wp-config.php.

Открываем его и находим в этом файле следующие строки:

/* Произвольные значения добавляйте между этой строкой и надписью "дальше не редактируем". */
(Код вставляем здесь, без скобок)
/* Это всё, дальше не редактируем. Успехов! */

И между этими комментариями добавляем следующий код:

define('DISABLE_WP_CRON', true);

Сохраняем файл.

Теперь нужно настроить Cron сервера, чтобы он запускал наш файл Cron PHP, в противном случае можем получить ошибки работы некоторых плагинов и Rest API.

Переходим в личный кабинет хостинга, находим там CronTab и переходим туда.

А теперь добавляем следующий параметр (не забудьте поменять домен на свой):

wget -O /dev/null -t 1 -q 'https://домен-вашего-сайта.ru/wp-cron.php'

Добавляем описание на всякий случай, а параметры запуска ставим «каждую 5-ю минуту». Теперь Cron запускаться будет раз в 5 минут. Если у вас в Cron нет задач на 5 минут, а минимальное значение, например, 30 минут, то ставим значение «каждую 30-ю минуту». И по аналогии. Зависит от минимального времени у вашего планировщика.

А в подразделе «В указанные часы», ставим «Каждый час».

Нажмите кнопку «Добавить задание». А теперь в обязательном порядке нужно протестировать работоспособность задания. Для этого нажмите кнопку «Старт».

Потом нажмите кнопку «Запустить скрипт».

И если задача работает, то после запуска будет красоваться надпись «Выполнено». Если есть ошибка, то об этом также будет сообщено в диалоговом окне.

Готово, Cron мы немного разгрузили. Раздел «Здоровье сайта» может начать ругаться на отсутствие планировщика, но на самом деле его запускает сервер, так что отложенные публикации и прочее будет работать.

Много запросов к admin-ajax.php

Итак, ещё одним виновником повышенной нагрузки на сайт может стать какой-либо плагин или тема, который генерирует много запросов к admin-ajax.php. Да, для работы многих плагинов, а также админ-панели WordPress этот файл попросту необходим. Но некоторые плагины или темы могут генерировать непомерное количество запросов к этом файлу.

И в логах я такую ситуацию и вижу:

А значит пришло время выявить проблему. К сожалению, выявить не значит решить. Иногда плагин, который генерирует прорву запросов, может оказаться очень нужным. Тогда остаётся только писать разработчику плагина на форуме поддержки и сообщить о проблеме.

Но давайте сначала выявим проблему. Нам нужно узнать, что именно генерирует запросы к admin-ajax.php. Перед началом проверки рекомендую отключить все плагины для минификации кода, кеширования, а также всякие ускорители вроде Autoptimize и WP Rocket.

Итак, чтобы выполнить проверку, вам понадобится браузер Google Chrome. В принципе, такие инструменты есть и на других браузерах, но я привык такие задачи выполнять в Хроме, так что инструкцию буду писать под него.

Итак, открываем главную страницу сайта, который желаем проверить, после нажимаем клавишу F12. Откроется DevTools браузера Chrome. Перейдите во вкладку Network.

Теперь, не закрывая DevTools, перезагрузите главную страницу сайта с помощью сочетания клавиш ctrl+F5. Или на самой вкладке DevTools нужно нажать сочетание ctrl+R. Подождите минуту, прежде чем продолжать. Дайте инструменту набрать данных, ведь даже после того, как сайт прогрузится, всё равно будут генерироваться новые запросы, например, из-за выполнения отложенных скриптов или обращения к счётчикам.

Теперь вводим admin-ajax.php в фильтры, находим нужный файл, нажимаем на него.

В разделе Initiator вы сможете увидеть, какой код инициирует запуск admin-ajax.php. Например, в данном случае это админ-панель WordPress, а также плагин PhastPress.

Если мы нажмём на любой из инициаторов, лучше искать что-нибудь с пометкой trigger, то нам покажет код. Например, такой:

И здесь по коду наглядно видно, что триггер настроен так, что раз в 4000 миллисекунд идёт новое обращение к admin-ajax.php.

Эти запросы плагин отправляет только в том случае, если вы авторизованы в админ-панели. То бишь гости сайта новые запросы не генерируют. Но если авторов много, а админ-панель WordPress целыми днями не закрывается, то подобный код может создать существенную нагрузку на процессор сервера и, соответственно, увеличивает потребление CP.

Чтобы уменьшить количество CP, которое потребляет admin-ajax.php, лучше обратиться к разработчику плагина на странице плагина в репозитории. Или попытаться увеличить данное значение самостоятельно.

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

Лучшим вариантом будет о проблеме сообщить автору плагина.

Уменьшение потребления CP — уменьшение расходов

Вот, например, результат работы над парой сайтов WordPress, расположенных на одном хостинге:

Человек начал работу сам. Отключил ненужные плагины, настроил кэширование. Но с более сложными вещами самостоятельно не справился, например, с WP Cron, а также не заметил, что WP Super Cache устроил непотребство и раз в 12 часов полностью перестраивал статический кэш.

Исправление этих проблем теперь позволит ему отключить дополнительные CP, которые он докупил, соответственно, меньше платить.

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

На этом с вами прощаюсь, желаю успехов и рабочих сайтов, всего доброго!