🔎 Почему сайт тормозит: VPS, база, CMS или код?

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

Базовая диагностика строится по симптомам:

Высокий TTFB — проверить PHP, базу данных, кеш, внешний API и очередь запросов;
100% CPU — посмотреть процессы, PHP-FPM, MySQL, cron-задачи, ботов и фоновые операции;
Нехватка RAM — проверить free, swap, PHP-процессы, MySQL и Redis;
Медленный диск — посмотреть свободное место, I/O и iostat;
Долгие SQL-запросы — включить или проверить MySQL slow log;
Ошибки 502 и 503 — смотреть Nginx, PHP-FPM, память и логи приложения;
Резкий рост запросов — проверить access log, ботов, DDoS, wp-login, xmlrpc и подозрительные URL;
Нормальный TTFB, но медленная загрузка — искать проблему во фронтенде: изображениях, JavaScript, CSS, шрифтах и сторонних скриптах.

Минимальный набор инструментов для первичной проверки: top или htop, free, df, iostat, логи Nginx, статус PHP-FPM и MySQL slow log. Уже по ним часто видно, что именно упирается в лимит: CPU, RAM, диск, база, PHP или поток запросов.

PageSpeed и Core Web Vitals полезны, но они не заменяют серверную диагностику. Они могут показать, что пользователь видит медленную страницу, но не всегда объясняют, почему сервер долго отвечает или почему PHP-процессы стоят в очереди.

Правильный порядок такой: сначала зафиксировать симптом, затем проверить метрики VPS, потом логи веб-сервера, PHP и базы данных, после этого смотреть CMS, плагины, код, cron-задачи и внешние API.

Переезд на более дорогой VPS оправдан только тогда, когда диагностика показывает реальную нехватку ресурсов. Если сайт тормозит из-за slow queries, тяжёлого плагина, неудачного кода, внешнего API или фронтенда, новый тариф может лишь временно скрыть проблему.

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

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

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

Один симптом может иметь разные причины

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

Высокий TTFB может указывать на перегруженный PHP-FPM, медленную базу данных, отсутствие кеша, ожидание ответа внешнего API или нехватку ресурсов на VPS.

Ошибки 502 и 503 могут появляться из-за падения PHP-FPM, нехватки RAM, слишком длинных запросов, неправильных таймаутов или резкого всплеска обращений от ботов.

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

Поэтому диагноз нельзя ставить только по ощущению “сайт тормозит”. Сначала нужно понять, на каком уровне возникает задержка: сеть, VPS, веб-сервер, PHP, база данных, CMS, код или браузер.

PageSpeed не показывает всю картину

PageSpeed и похожие инструменты полезны, но они не заменяют диагностику сервера. Они хорошо показывают проблемы пользовательской загрузки: изображения, JavaScript, CSS, шрифты, LCP, CLS и другие фронтенд-метрики.

Но отчёт PageSpeed не всегда объясняет, почему PHP-процесс выполняется слишком долго, почему MySQL упирается в диск или почему на VPS закончилась память.

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

Поэтому PageSpeed стоит использовать как один из инструментов, а не как единственный источник правды. Если проблема похожа на серверную, нужно смотреть метрики VPS, логи Nginx, статус PHP-FPM и slow log базы данных.

Иначе можно начать с минификации CSS, хотя реальная задержка возникает ещё до того, как браузер получил HTML.

Диагностика должна идти от метрик к гипотезам

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

Например, если TTFB высокий, нужно проверить нагрузку CPU, RAM, PHP-FPM, MySQL и логи. Если при этом CPU свободен, RAM хватает, а slow log показывает долгие SQL-запросы, гипотеза смещается в сторону базы данных или плагина.

Если CPU держится на 100%, нужно смотреть, кто его потребляет: PHP, MySQL, cron, архиватор, бот-атака или другой процесс, вплоть до вируса-майнера.

Если RAM закончилась и активно используется swap, причина может быть в слишком большом числе PHP-процессов, тяжёлой базе, Redis, утечке памяти или фоне, который съедает ресурсы.

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

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

Алгоритм диагностики: от симптома к причине

Высокий TTFB

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

Причина может быть в VPS, PHP, базе данных, CMS, коде, внешнем API или отсутствии кеша.

Что проверить	Возможная причина
CPU и RAM	сервер упирается в ресурсы
PHP-FPM status	запросы ждут свободный PHP-процесс
MySQL slow log	база долго выполняет SQL-запросы
Nginx/PHP logs	ошибки, таймауты, падение процессов
внешний API	приложение ждёт ответ стороннего сервиса
кеш	страница каждый раз генерируется заново

Если TTFB высокий только у отдельных страниц, вероятнее всего проблема в конкретном коде, запросе к базе, плагине или внешней интеграции. Если высокий TTFB у всего сайта, нужно начинать с VPS, PHP-FPM, базы и кеша.

100% CPU

Постоянная загрузка CPU на 100% говорит о том, что серверу не хватает вычислительных ресурсов или какой-то процесс забирает их слишком активно.

Сначала нужно посмотреть, кто именно нагружает процессор: PHP-FPM, MySQL, Node.js, cron-задача, архиватор, антивирус, парсер, бот или другой процесс.

Для первичной проверки используют top или htop. Они показывают процессы, потребление CPU, память и общую нагрузку на систему.

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

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

Нехватка RAM и активный swap

Когда оперативной памяти не хватает, система начинает использовать swap — область на диске, куда временно выгружаются данные из RAM. Для сайта это почти всегда означает заметное замедление.

Проверить память можно командой: free -h

Если свободной памяти мало, а swap активно используется, нужно понять, кто потребляет RAM: PHP-FPM, MySQL, Redis, фоновые задачи, CMS, панель управления или сторонний сервис.

Частая ошибка — слишком большое количество PHP-FPM процессов. В теории это должно позволить обрабатывать больше запросов, но на практике каждый процесс потребляет память. Если процессов больше, чем может выдержать VPS, сервер начинает уходить в swap.

Нехватка RAM может проявляться как медленная админка, ошибки 502 и 503, падение MySQL, зависание PHP-процессов и нестабильная работа сайта под нагрузкой.

Медленный диск

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

Сначала нужно проверить свободное место: df -h

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

Для оценки дисковой нагрузки используют iostat. Он помогает увидеть, не упирается ли сервер в операции чтения и записи.

Высокий iowait часто говорит о том, что процессы ждут диск. Внешне это может выглядеть как “сайт думает”, хотя CPU не загружен полностью.

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

Долгие SQL-запросы

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

Для диагностики используют MySQL slow log. Он показывает запросы, которые выполняются дольше заданного порога.

Долгие SQL-запросы могут возникать из-за:

Отсутствия нужных индексов;
Больших таблиц;
Сложных фильтров;
Тяжёлых плагинов;
Неудачных JOIN;
Разросшихся логов и временных данных;
Большого объёма autoload-настроек в CMS.

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

Внешний API тормозит ответ

Иногда сайт тормозит не из-за VPS, CMS или базы, а из-за ожидания ответа внешнего сервиса. Это может быть платёжная система, CRM, служба доставки, сервис аналитики, карта, антифрод, API курса валют или любая другая интеграция.

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

Такой сценарий часто выглядит как высокий TTFB при нормальной нагрузке CPU, RAM и базы данных.

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

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

Cron-задачи создают пики нагрузки

Cron-задачи запускают фоновые операции: бэкапы, импорт товаров, рассылки, очистку кеша, генерацию отчётов, обновление остатков, синхронизацию с CRM и другие регулярные процессы.

Если cron настроен неудачно, несколько тяжёлых задач могут стартовать одновременно и резко нагрузить CPU, RAM, диск или базу данных.

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

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

Cron-задачи лучше разносить по времени, ограничивать по ресурсам и выносить тяжёлые операции за пределы пикового трафика. Для CMS также важно проверять встроенные планировщики задач, потому что они могут запускаться при посещениях сайта.

DDoS, боты и всплески запросов

Резкий рост запросов не всегда означает рост реальных посетителей. Сайт могут нагружать поисковые боты, парсеры, сканеры уязвимостей, переборщики паролей, DDoS-атаки или агрессивные интеграции.

Первый источник информации — access log Nginx. В нём можно увидеть IP-адреса, URL, частоту запросов, коды ответов и user-agent.

Подозрительные признаки:

Много запросов к wp-login.php, xmlrpc.php или административным URL;
Резкий рост 404;
Частые POST-запросы;
Повторяющиеся запросы с одного IP или подсети;
Странные user-agent;
Всплеск запросов к тяжёлым страницам поиска, фильтров или корзины.

Если сайт тормозит только во время таких всплесков, проблема может быть не в тарифе VPS, а в отсутствии ограничений, WAF, rate limiting, кеша или защиты от ботов.

После такого первичного разбора можно переходить к конкретным инструментам VPS: top, htop, free, df, iostat, логам Nginx, PHP-FPM status и slow log базы данных.

Что проверить на VPS в первую очередь

CPU и процессы через top или htop

Первое, что стоит проверить на VPS, — кто потребляет CPU прямо сейчас. Для этого используют top или более удобный htop. Эти команды показывают процессы, потребление CPU, память и общую нагрузку на систему.

В этих утилитах нужно смотреть не только общий процент загрузки CPU, но и список процессов. Важно понять, что именно создаёт нагрузку: PHP-FPM, MySQL, веб-сервер, Node.js, cron-задача, архиватор, антивирус, скрипт импорта или другой процесс.

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

Если же CPU забирает MySQL, нужно переходить к slow log, индексам, размеру таблиц и запросам, которые генерирует CMS или приложение.

Также стоит смотреть load average. Если значение стабильно выше числа доступных vCPU, сервер может не успевать обрабатывать задачи. Разовый пик не всегда критичен, но постоянная высокая нагрузка во время обычного трафика — повод продолжать диагностику.

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

Память через free

Оперативную память можно быстро проверить командой: free -h

Она показывает общий объём RAM, занятую память, кеш, доступную память и swap.

Главное — не паниковать из-за строки used. Linux активно использует свободную память под кеш, и это нормально. Важнее смотреть на доступную память и использование swap.

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

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

Частые причины нехватки RAM:

Слишком много процессов PHP-FPM;
Тяжёлые плагины или модули CMS;
MySQL забирает слишком много памяти;
Redis настроен без учёта лимитов;
Одновременно запускаются бэкапы, импорт и cron-задачи;
На VPS работает лишний софт или панель управления.

Если памяти не хватает, увеличение pm.max_children в PHP-FPM только ухудшит ситуацию. Сначала нужно понять, какие процессы потребляют RAM, и убрать лишнюю нагрузку.

Следующий базовый уровень — диск: даже свободные CPU и RAM не спасут сайт, если на VPS закончилось место или диск не успевает читать и писать данные.

Диск и свободное место через df

Проверить свободное место на дисках можно командой: df -h

Она показывает, какие разделы подключены, сколько места занято и сколько осталось.

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

Особенно опасна ситуация, когда заканчивается место на разделе, где лежат:

Файлы сайта;
База данных;
Системные логи;
Временные файлы;
Кеш;
Резервные копии.

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

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

Но свободное место — это только часть картины. Диск может быть не заполнен, но всё равно работать медленно под нагрузкой.

Дисковая нагрузка через iostat

Для оценки дисковой нагрузки используют iostat. Если утилиты нет, её обычно устанавливают в составе пакета sysstat.

Команда для наблюдения в реальном времени: iostat -xz 1

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

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

Причины высокой дисковой нагрузки могут быть разными:

MySQL активно читает большие таблицы;
Сайт использует swap из-за нехватки RAM;
Одновременно идут бэкап и импорт;
Логи пишутся слишком интенсивно;
Кеш постоянно создаётся и удаляется;
Диск VPS слишком медленный для текущей нагрузки.

Если дисковая нагрузка связана с базой, нужно смотреть slow queries и настройки MySQL. Если причина в swap, возвращаемся к RAM. Если проблему создают бэкапы или cron, их нужно разнести по времени.

После CPU, памяти и диска остаётся проверить сеть: иногда тормоза вызывает не код и не VPS, а всплеск запросов.

Сетевые подключения и всплески трафика

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

Первый источник информации — access log веб-сервера. Но для быстрой проверки сетевых подключений можно использовать команды вроде: ss -tunap или netstat -tunap.

В них можно увидеть активные соединения, порты и процессы, которые их обслуживают.

Если подозрение на всплеск HTTP-запросов, нужно смотреть логи Nginx: какие URL запрашивают чаще всего, с каких IP идут обращения, какие коды ответа возвращаются и какие user-agent повторяются.

Подозрительными могут быть:

Частые запросы к странице входа;
Перебор несуществующих URL;
Большое количество 404;
Много POST-запросов;
Частые обращения к тяжёлым страницам поиска или фильтров;
Всплеск запросов с одной подсети;
Необычные user-agent.

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

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

Логи веб-сервера и приложения

Nginx access log

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

Обычно лог находится в каталоге вроде: /var/log/nginx/access.log

или в отдельном файле конкретного сайта: /var/log/nginx/example.com.access.log

Быстро посмотреть последние строки можно командой: tail -f /var/log/nginx/access.log

В access log важно смотреть:

Какие URL запрашивают чаще всего;
С каких IP идут обращения;
Какие коды ответа возвращает сервер;
Сколько запросов приходит в минуту;
Какие user-agent повторяются;
Нет ли всплеска запросов к тяжёлым страницам.

Если в логе много запросов к странице входа, поиску, фильтрам, корзине, xmlrpc.php, API или несуществующим URL, нагрузку может создавать не реальная аудитория, а боты, сканеры или переборщики.

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

Nginx error log

error log показывает ошибки веб-сервера и проблемы при передаче запросов в backend. Именно здесь часто видны причины 502 Bad Gateway, 504 Gateway Timeout, проблем с PHP-FPM, правами файлов и таймаутами.

Обычно файл находится здесь: /var/log/nginx/error.log

Посмотреть последние ошибки можно так: tail -n 100 /var/log/nginx/error.log

В error log стоит искать сообщения о:

Недоступном PHP-FPM;
Превышении таймаутов;
Ошибках прав доступа;
Слишком больших запросах;
Проблемах с SSL;
Отсутствии файлов;
Невозможности подключиться к backend;
Ошибках проксирования.

Например, если Nginx пишет, что upstream недоступен, проблема может быть в PHP-FPM, приложении или сокете. Если часто появляются timeout-сообщения, backend может слишком долго обрабатывать запросы.

Error log не всегда даёт финальный ответ, но он показывает направление: проблема на уровне Nginx, PHP-FPM, приложения, прав доступа или таймаутов.

После логов Nginx нужно проверить сам PHP-FPM, потому что именно он часто становится узким местом для CMS и PHP-приложений.

PHP-FPM status и slowlog

PHP-FPM status показывает, как работает пул PHP-процессов: сколько процессов занято, сколько свободно, есть ли очередь и хватает ли воркеров для текущей нагрузки.

Если status-страница настроена, по ней можно увидеть, не ждут ли запросы свободный PHP-процесс. Очередь в PHP-FPM часто объясняет высокий TTFB и периодические 502 или 503.

Особенно важны такие признаки:

Все процессы заняты;
Есть очередь запросов;
Растёт число медленных запросов;
Процессы выполняются слишком долго;
Пул часто достигает лимита.

PHP-FPM slowlog помогает понять, какой PHP-код выполняется слишком долго. Это полезно, когда сайт не падает, но отдельные страницы, плагины или действия в админке стабильно тормозят.

Slowlog может показать, что задержка появляется не в Nginx и не в сети, а внутри PHP: в конкретном скрипте, функции, плагине, модуле CMS или обращении к внешнему API.

Если PHP-FPM работает на пределе, не всегда нужно сразу увеличивать pm.max_children. Сначала нужно проверить RAM: слишком большой пул процессов может привести к swap и сделать сайт ещё медленнее.

Когда Nginx и PHP-FPM не показывают очевидной причины, стоит переходить к логам самой CMS или приложения.

Ошибки CMS и приложения

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

В логах приложения нужно искать:

fatal error;
warning и notice, которые повторяются слишком часто;
Ошибки подключения к базе;
Таймауты внешних API;
Ошибки авторизации;
Проблемы с правами файлов;
Неудачные задачи cron;
Повторяющиеся исключения.

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

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

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

База данных как причина тормозов

MySQL slow log

MySQL slow log показывает SQL-запросы, которые выполняются дольше заданного времени. Это один из главных инструментов, если сайт тормозит в админке, каталоге, поиске, личном кабинете или при оформлении заказа.

Slow log особенно полезен, когда внешне всё выглядит как “медленный сайт”, но CPU, RAM и Nginx не дают очевидного ответа. В таком случае задержка может быть внутри базы данных.

В slow log стоит смотреть:

Какой запрос выполнялся долго;
Сколько времени заняло выполнение;
Сколько строк было просмотрено;
Как часто запрос повторяется;
С какой страницей, модулем или действием он связан.

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

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

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

Тяжёлые запросы и отсутствие индексов

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

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

Тяжёлые запросы часто появляются в:

Поиске;
Фильтрах товаров;
Каталогах;
Отчётах;
Личных кабинетах;
Административных панелях;
Блоках рекомендаций;
Плагинах статистики;
Кастомных выборках в коде.

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

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

Иногда проблема не в одном запросе, а в том, что база годами накапливала лишние данные.

Разросшиеся таблицы и autoload

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

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

В WordPress отдельная частая проблема — разросшийся autoload в таблице wp_options. Autoload-записи загружаются при каждом запросе. Если их слишком много, сайт тратит время и память на данные, которые могут не требоваться конкретной странице.

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

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

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

Если таблицы очищены, запросы понятны, но база всё равно тормозит, нужно проверить, не упирается ли она в ресурсы VPS.

Когда база упирается в диск или RAM

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

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

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

Высокий iowait;
Активный swap;
Медленные запросы даже без сложной логики;
Рост времени ответа при обычном трафике;
Долгие бэкапы и импорты;
Задержки в админке и поиске;
Ошибки подключения к базе под нагрузкой.

В таком случае нужно смотреть не только slow log, но и общие метрики VPS: free, iostat, загрузку MySQL, размер таблиц и настройки памяти базы.

Иногда достаточно очистить таблицы, добавить нужный индекс или уменьшить нагрузку от плагинов. Но если база действительно выросла и постоянно упирается в RAM или диск, может понадобиться более мощный VPS, отдельный сервер базы данных или managed database.

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

CMS, плагины и код

Тяжёлые плагины и модули

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

Особенно внимательно стоит проверять:

Конструкторы страниц;
Фильтры товаров;
Поиск;
Статистику;
SEO-модули;
Плагины безопасности;
Резервное копирование;
Мультиязычность;
Рекомендации и “похожие материалы”;
Интеграции с CRM, доставкой и оплатой.

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

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

Отключать всё подряд на production-сайте рискованно. Лучше проверять гипотезы на staging-копии, смотреть логи, профилировщик CMS и slow queries. Если после отключения конкретного плагина время ответа резко падает, причина становится понятнее.

Но даже без тяжёлых расширений сайт может тормозить из-за самой темы или шаблонов.

Неудачные темы и шаблоны

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

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

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

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

Тормозят страницы одного типа;
После смены шаблона время ответа меняется;
На странице много одинаковых запросов;
Тема подключает лишние CSS и JavaScript;
Блоки рекомендаций и похожих записей работают слишком медленно;
Админка быстрая, а публичные шаблоны тормозят.

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

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

Ошибки в коде и бесконечные циклы

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

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

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

Проверять нужно:

PHP error log;
Лог CMS или приложения;
PHP-FPM slowlog;
Повторяющиеся warning и fatal error;
Участки кода, которые выполняются на каждой странице;
Циклы с запросами к базе;
Тяжёлые операции в момент открытия страницы.

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

Отдельная разновидность такой проблемы — ожидание стороннего API.

Сторонние API и долгие ожидания ответа

Сайт может зависеть от внешних сервисов: платёжных систем, CRM, служб доставки, карт, аналитики, антифрода, курсов валют, маркетинговых платформ или внутренних API компании.

Если приложение ждёт ответ такого сервиса до отдачи страницы, задержка внешнего API превращается в задержку сайта.

Это особенно заметно, когда VPS не перегружен, база отвечает нормально, но TTFB всё равно высокий на конкретных страницах: форме заказа, личном кабинете, корзине, карточке товара или странице заявки.

Проблема может быть в долгом ответе API, отсутствии таймаутов, повторных попытках, медленном DNS, сетевой задержке или ошибке интеграции.

В логах стоит искать HTTP-запросы к внешним сервисам, их длительность, коды ответа и таймауты. Если один и тот же API регулярно отвечает по несколько секунд, его нельзя оставлять в критическом пути загрузки страницы.

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

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

Как отличить фронтенд-тормоза от серверных

Когда виноват сервер

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

Причина может быть в VPS, PHP-FPM, базе данных, CMS, коде, внешнем API или отсутствии кеша. Браузер в такой ситуации почти ничего не может сделать: он ждёт, пока backend подготовит ответ.

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

Если в момент замедления растёт нагрузка CPU, заканчивается RAM, появляется swap, увеличивается очередь PHP-FPM или в MySQL slow log попадают долгие запросы, проблему нужно искать на backend-стороне.

Внешне это может выглядеть как “сайт просто долго открывается”. Но технически задержка возникает ещё до загрузки изображений, CSS и JavaScript.

Когда первый HTML приходит быстро, но страница всё равно долго становится удобной для пользователя, подозрение смещается в сторону браузера и фронтенда.

Когда виноват браузер

Фронтенд-проблема начинается после того, как сервер уже отдал HTML. Браузер получил страницу, но ему ещё нужно загрузить стили, скрипты, изображения, шрифты и внешние ресурсы.

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

Частые причины — тяжёлые изображения, блокирующий JavaScript, лишний CSS, web-шрифты, рекламные скрипты, карты, чаты, аналитика и виджеты соцсетей.

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

Поэтому важно разделять метрики. TTFB больше говорит о сервере и backend-части. LCP, CLS и INP чаще помогают понять, что происходит уже в браузере пользователя.

Для этого удобно смотреть waterfall в DevTools.

Как читать waterfall в DevTools

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

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

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

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

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

Такой разбор помогает не путать разные типы тормозов. Если медленный первый ответ — проверяем сервер, PHP, базу и код. Если медленная отрисовка после быстрого ответа — работаем с изображениями, CSS, JavaScript, шрифтами и внешними скриптами.

Типовые ошибки диагностики

Ошибки в диагностике опасны тем, что уводят в сторону от настоящей причины. Сайт может тормозить из-за базы, PHP, диска, внешнего API или ботов, а владелец при этом будет менять изображения, ставить кеш-плагин или покупать более дорогой VPS.

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

Смотреть только на PageSpeed

PageSpeed полезен для оценки пользовательской загрузки, но он не показывает всю внутреннюю картину сервера. Сервис может подсветить тяжёлые изображения, блокирующий JavaScript, проблемы LCP или CLS, но не всегда объяснит, почему PHP долго генерирует страницу.

Если сайт получает низкую оценку, это ещё не означает, что проблема именно в VPS. И наоборот: страница может иметь нормальные фронтенд-показатели, но высокий TTFB из-за базы данных, очереди PHP-FPM или внешнего API.

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

Если ориентироваться только на один отчёт, можно начать оптимизировать CSS и изображения, хотя сайт тормозит из-за slow queries или нехватки RAM.

Не проверять логи

Логи часто дают больше информации, чем визуальные тесты скорости. В них видно, какие запросы приходят на сайт, какие ошибки повторяются, какие страницы отдают 500, 502 или 504, и где backend не успевает ответить вовремя.

Без логов диагностика превращается в угадывание. Можно предположить, что сайт тормозит из-за слабого VPS, хотя в access log в этот момент идут тысячи запросов от ботов. Или можно думать, что виноват Nginx, хотя error log показывает падение PHP-FPM.

Проверять нужно как минимум access log и error log веб-сервера, PHP-ошибки, PHP-FPM slowlog и MySQL slow log. Для CMS и фреймворков также важны собственные логи приложения.

Логи не всегда дают готовый ответ, но они сильно сужают круг причин. Вместо “сайт иногда тормозит” появляется конкретика: какой URL, какой код ответа, какой процесс, какой запрос и в какое время.

Путать фронтенд-тормоза с серверными

Пользователь видит один общий симптом: сайт медленный. Но технически задержка может возникать в разных местах.

Если сервер долго отдаёт первый HTML, проблема ближе к VPS, PHP, базе данных, CMS, коду или внешнему API. Здесь нужно смотреть TTFB, PHP-FPM, MySQL, логи и ресурсы сервера.

Если HTML приходит быстро, но страница долго отрисовывается, причина чаще во фронтенде: изображениях, CSS, JavaScript, шрифтах, рекламе, картах, виджетах и сторонних скриптах.

Ошибка возникает, когда эти два сценария лечат одинаково. Например, увеличивают тариф VPS, хотя страница тормозит из-за огромного hero-изображения. Или минифицируют CSS, хотя сервер отвечает две секунды до начала загрузки страницы.

Разделение backend и frontend помогает выбрать правильное действие. Серверные проблемы ищут через метрики и логи, фронтенд-проблемы — через waterfall, Core Web Vitals и анализ ресурсов страницы.

Сразу переезжать на более дорогой VPS

Переезд на более мощный VPS иногда нужен, но он должен быть результатом диагностики, а не первым действием.

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

Но если тормоза создаёт тяжёлый плагин, медленный SQL-запрос, внешний API, неправильно настроенный cron или поток ботов, новый тариф только временно замаскирует причину.

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

Правильная последовательность другая: сначала зафиксировать симптом, проверить метрики, посмотреть логи, найти узкое место и только потом решать, нужен ли апгрейд VPS.

Так диагностика превращается не в набор догадок, а в понятный процесс: от симптома к причине и от причины к конкретному решению.

Короткий чек-лист диагностики

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

Дальше проверьте VPS:

top или htop — какие процессы нагружают CPU;
free -h — хватает ли RAM и используется ли swap;
df -h — не заканчивается ли место на диске;
iostat -xz 1 — нет ли высокой дисковой нагрузки и iowait;
сетевые подключения и access log — нет ли всплеска запросов, ботов или DDoS.

После этого переходите к логам:

Nginx access log — какие URL запрашивают чаще всего;
Nginx error log — нет ли ошибок 502, 504, timeout и проблем с backend;
PHP-FPM status — есть ли очередь и свободные процессы;
PHP-FPM slowlog — какой PHP-код выполняется слишком долго;
MySQL slow log — какие SQL-запросы тормозят;
логи CMS или приложения — нет ли fatal error, повторяющихся warning, таймаутов API и ошибок cron.

Затем разделите проблему на backend и frontend. Если медленно приходит первый HTML-ответ, смотрите VPS, PHP, базу, CMS, код, кеш и внешние API. Если HTML приходит быстро, но страница долго отрисовывается, проверяйте изображения, CSS, JavaScript, шрифты и сторонние скрипты.

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

Заключение

Причину медленной работы сайта нельзя надёжно определить по одному ощущению “страница долго открывается”. Один и тот же симптом может указывать на VPS, базу данных, CMS, код, внешний API, фронтенд, cron-задачи, ботов или проблемы с диском.

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

PageSpeed, Core Web Vitals и waterfall помогают понять, что видит пользователь в браузере. Но они не заменяют top, free, df, iostat, access log, error log, PHP-FPM status и MySQL slow log.

Апгрейд VPS стоит рассматривать только тогда, когда метрики действительно показывают нехватку ресурсов. Если сайт тормозит из-за slow queries, тяжёлого плагина, бесконечного цикла, внешнего API или ботов, более дорогой тариф не устранит причину.

Хорошая диагностика не начинается с покупки нового сервера. Она начинается с вопроса: где именно возникает задержка и какая метрика это подтверждает.

FAQ

Что проверить первым, если сайт стал медленным?

Сначала нужно понять, где возникает задержка: до ответа сервера или уже в браузере пользователя.

Если страница долго ждёт первый ответ, проверяют TTFB, VPS, PHP-FPM, базу данных, кеш, логи и внешние API. Если HTML приходит быстро, но страница медленно отрисовывается, нужно смотреть изображения, CSS, JavaScript, шрифты и сторонние скрипты.

Для первичной проверки на VPS обычно достаточно открыть top или htop, посмотреть память через free -h, свободное место через df -h, дисковую нагрузку через iostat, а затем перейти к логам Nginx, PHP-FPM и MySQL.

Главное — не менять всё сразу. Сначала симптом, потом метрики, потом гипотеза и только после этого исправление.

Как понять, что не хватает RAM?

Нехватку RAM обычно видно по активному использованию swap. Проверить память можно командой: free -h

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

Также о нехватке RAM могут говорить ошибки 502 и 503, падение MySQL, завершение процессов через OOM killer, медленная админка и нестабильная работа сайта под нагрузкой.

Причину нужно искать в процессах: PHP-FPM, MySQL, Redis, cron-задачах, панели управления, бэкапах или других сервисах на VPS.

Что означает высокий TTFB?

Высокий TTFB означает, что браузер долго ждёт первый байт ответа от сервера. То есть проблема возникает ещё до полноценной загрузки страницы.

Причина может быть в PHP, базе данных, CMS, коде, внешнем API, очереди PHP-FPM, нехватке ресурсов VPS или отсутствии кеша.

Если высокий TTFB наблюдается на всех страницах, стоит начинать с VPS, PHP-FPM, MySQL и кеширования. Если тормозит только отдельная страница, вероятнее проблема в конкретном модуле, SQL-запросе, внешней интеграции или участке кода.

TTFB не объясняет всё, но хорошо отделяет серверные задержки от фронтенд-проблем.

Может ли база данных тормозить весь сайт?

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

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

Проблемы могут быть связаны с slow queries, отсутствием индексов, разросшимися таблицами, большим autoload, нехваткой RAM или медленным диском.

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

Когда действительно нужно менять VPS?

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

Поводом для апгрейда могут быть постоянная загрузка CPU, нехватка RAM, активный swap, высокий iowait, медленный диск, очередь PHP-FPM, ошибки 502 или 503 под обычной нагрузкой.

Но если сайт тормозит из-за тяжёлого плагина, медленного SQL-запроса, внешнего API, ботов, бесконечного цикла или фронтенда, более дорогой VPS не решит проблему полностью.

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