Когда сайт открывается медленно, первым подозреваемым часто становится сервер. Но одинаковое ощущение у посетителя может возникать из-за тяжёлого изображения, ожидания ответа PHP, запроса к базе данных или задержки внешнего API. Увеличивать ресурсы до измерений — значит рисковать потратить деньги, сохранив причину проблемы.
Задача диагностики — найти участок, на котором теряется время, воспроизвести задержку и сравнить результат после изменения. Ниже — последовательность проверки для сайта на CMS или собственного PHP-приложения.
Сначала опишите медленный сценарий
«Сайт тормозит» — слишком общее описание. Запишите конкретный адрес и действие: открытие каталога, поиск, вход в кабинет, отправка формы или сохранение записи. Укажите время, устройство, сеть и состояние пользователя: гость или авторизованный посетитель.
- Проблема возникает постоянно или только в часы нагрузки?
- Медленные все страницы или один раздел?
- Первое открытие отличается от повторного?
- Задержка появилась после обновления, импорта данных или изменения конфигурации?
Сохраните несколько измерений до исправлений. Один быстрый ответ не доказывает, что проблема исчезла, как и один медленный ответ не описывает работу всего сайта.
Разделите ожидание сервера и работу браузера
Откройте вкладку Network в инструментах разработчика браузера и перезагрузите страницу. Посмотрите отдельно на основной HTML-документ и на изображения, стили, скрипты и запросы приложения.
Долгое ожидание первого байта у HTML — повод исследовать сеть до сервера, очередь обработки, приложение и базу данных. Быстрый HTML при медленном появлении содержимого указывает на другую часть цепочки: загрузку ресурсов, выполнение JavaScript или отрисовку. TTFB помогает разделить гипотезы, но сам по себе не называет виновника.
Проверяйте страницу с обычным кешем и без него. Отдельно сравните гостевой и авторизованный сценарии: кеширование публичной страницы может скрывать дорогую обработку запросов пользователя.
Сопоставьте запрос с журналами сервера
Зафиксируйте точное время проверки и найдите соответствующие записи в журналах веб-сервера и приложения. Полезны путь запроса, HTTP-статус, длительность обработки и, если настроено, время ожидания upstream. Идентификатор запроса помогает связать записи разных компонентов.
Далее проверьте загрузку процессора, доступную память, обращения к диску, свободное место и очередь рабочих процессов PHP. Если все обработчики заняты, новые запросы могут ждать даже при свободном процессоре. Причиной занятых обработчиков иногда оказывается внешний сервис, а не вычисления внутри приложения.
Оценивайте метрики в момент задержки. Средняя загрузка за день легко скрывает короткий период, когда посетители получали ошибки или ждали ответа.
Проверьте приложение и базу данных
На тестовой копии воспроизведите сценарий и выясните, какие участки кода и запросы занимают время. В WordPress проверьте плагины, тему, обработчики запросов и фоновые операции. Отключайте компоненты по одному в контролируемой среде: массовое отключение на рабочем сайте может сломать оплату, формы или интеграции.
Для базы данных начните со списка дорогих запросов и ожиданий блокировок. Журнал медленных запросов MySQL помогает собрать кандидатов, а EXPLAIN показывает план выполнения выбранного запроса. Наличие индекса само по себе не означает, что запрос его использует: важны условия фильтрации, соединения таблиц и объём результата.
Сначала изучайте обычный EXPLAIN. EXPLAIN ANALYZE выполняет запрос для измерения фактического поведения, поэтому дорогие запросы с ним следует проверять в подходящей среде. Включение подробного журналирования тоже требует контроля нагрузки и объёма логов.
Отдельно проверьте кеш и внешние сервисы
Уточните, какой кеш реально работает: страницы, объекты приложения, результаты отдельных вычислений или статические ресурсы. Проверьте попадания и промахи, правила исключений и инвалидирование после изменений.
Авторизованные страницы, корзину и персональные ответы нельзя бездумно кешировать как общедоступный HTML. Сначала задайте правила разделения данных и проверьте, что один посетитель не получает содержимое другого.
Для внешних API измерьте время ответа, тайм-ауты и повторные попытки. Если некритичный сервис задерживает всю страницу, рассмотрите кеширование его результата, фоновое обновление или понятный запасной сценарий при недоступности.
Исправляйте по одной гипотезе
После каждого изменения повторяйте тот же сценарий в сопоставимых условиях. Сравнивайте время ответа, частоту ошибок и потребление ресурсов. Для переменных задержек полезны перцентили: например, p95 показывает границу, быстрее которой завершились 95% измеренных запросов.
- Сформулируйте причину и ожидаемый эффект изменения.
- Подготовьте возможность вернуть прежнюю конфигурацию.
- Примените изменение и повторите измерения.
- Проверьте смежные сценарии: вход, формы, поиск и оформление заказа.
- Зафиксируйте результат и добавьте наблюдение за проблемным участком.
Если узкое место подтверждено ресурсами сервера, масштабирование может быть правильным решением. Но оно должно следовать из измерений: дорогой запрос, бесконечные повторы или неверные правила кеша часто остаются проблемой и на более мощной машине.
Что подготовить для разбора
Перед обращением соберите адреса медленных страниц, шаги воспроизведения, время возникновения проблемы и список недавних изменений. Это позволит начать с проверяемой ситуации. Если предстоят работы на сервере или с базой, заранее проверьте возможность восстановления из резервной копии.
Для диагностики и поддержки проекта напишите в HOMEWEB. Опишите, что именно ждёт посетитель и когда появилась задержка.
Если нужна помощь с этой задачей или хотите уточнить детали, свяжитесь с нами через форму внизу страницы.
