Почему сайт работает медленно: сервер, база, frontend или внешние сервисы
Как измерить путь запроса и найти реальное узкое место вместо случайного подключения кэша, нового сервера или очередного плагина оптимизации.
Медленная загрузка — не одна проблема. Браузер может долго искать домен, сервер — формировать ответ, база — выполнять запрос, а страница — ждать тяжелый скрипт. Если сразу ставить кэш или переносить сайт на более мощный сервер, можно не затронуть фактическое узкое место.
Зафиксируйте сценарий
Сначала определите, что именно медленно:
- первый заход на главную;
- каталог или фильтр;
- карточка товара;
- авторизация;
- административная панель;
- отправка формы;
- оформление заказа;
- API;
- загрузка файла.
Укажите устройство, сеть, время и состояние пользователя. Страница может быть быстрой для гостя из кэша и медленной после авторизации.
Разделите сервер и браузер
Ключевая граница — время до первого байта и время отображения после получения HTML. Если сервер начинает отвечать несколько секунд, оптимизация изображений не устранит основную задержку. Если HTML приходит быстро, а интерфейс появляется поздно, смотрят frontend и внешние ресурсы.
Полезные показатели:
- DNS и установка соединения;
- TLS;
- TTFB;
- размер HTML;
- момент основного контента;
- блокирующие стили и скрипты;
- длительные задачи браузера;
- количество и вес запросов.
Сеть, DNS и TLS
Медленный DNS, далекий сервер, повторные редиректы и проблемы TLS добавляют задержку до приложения. Проверьте цепочку переходов между http, https, www и основным доменом. Один правильный редирект допустим, несколько последовательных — лишняя работа.
Инфраструктурные причины домена и сертификата подробнее разобраны в статье о DNS и SSL.
Ресурсы сервера
На сервере смотрят не только среднюю загрузку CPU. Важно, что происходит в момент медленного запроса:
- заканчивается память;
- активно используется swap;
- диск имеет высокую задержку;
- пул процессов исчерпан;
- очередь запросов растет;
- контейнер ограничен по ресурсам;
- журналирование блокирует диск;
- другой сервис создает пиковую нагрузку.
Мощный сервер может быть медленным из-за конфигурации, а небольшой — стабильно обслуживать оптимизированное приложение.
Приложение
Приложение может выполнять лишнюю работу: пересчитывать данные на каждый запрос, обращаться к внешнему API, строить тяжелый отчет или загружать большой объект целиком.
Нужны измерения внутри запроса: какие операции занимают время, сколько раз вызывается один сервис, где отсутствует кэш и не выполняется ли фоновая работа синхронно.
Логи без длительности показывают ошибки, но редко отвечают, почему успешный запрос был медленным.
База данных
Типовые причины:
- отсутствующий индекс;
- выборка лишних полей;
- запрос в цикле;
- блокировка транзакции;
- сортировка большого объема;
- фильтр по вычисляемому значению;
- медленное соединение с удаленной базой;
- слишком маленький пул подключений.
Сначала находят фактически медленный запрос и план выполнения, затем меняют структуру. Добавление индексов на все поля увеличивает размер и замедляет запись.
Кэширование
Кэш полезен для повторяемых данных, но требует правил инвалидирования. Нельзя кэшировать персональную страницу как общую или показывать старый остаток после заказа.
Различают кэш браузера, CDN, веб-сервера, приложения и базы. Каждый слой решает свою задачу. Перед включением нужно понимать, какое вычисление исключается и когда данные должны обновиться.
Изображения и шрифты
Частая клиентская причина — оригинальные фотографии, уменьшенные только CSS. Используйте подходящий формат, размеры под экран и ленивую загрузку вне первого экрана.
Для шрифтов ограничивают количество начертаний, заранее загружают действительно критичный файл и задают безопасное отображение до его получения.
JavaScript и сторонние виджеты
Чаты, аналитика, карты, рекламные пиксели и персонализация могут блокировать основной поток или создавать десятки запросов. Сторонний скрипт находится вне контроля сайта, поэтому его нужно загружать отложенно и проверять поведение при недоступности.
Большой JavaScript-бандл также замедляет слабые мобильные устройства, даже если сеть быстрая. Разделяйте код по маршрутам и не отправляйте пользователю административные функции.
Проверяйте реальные страницы
Главная часто оптимизирована лучше каталога и кабинета. Составьте небольшой набор:
- главная;
- типовая внутренняя страница;
- тяжелая страница;
- критичный сценарий;
- авторизованный экран;
- API.
Контроль должен идти из нужной географии и в разные периоды. Мониторинг сайта и API помогает увидеть тренд, а не единичный замер.
Приоритет исправлений
- Ошибки и таймауты.
- Серверные задержки критичных страниц.
- Тяжелые запросы базы.
- Блокирующие ресурсы первого экрана.
- Крупные изображения и скрипты.
- Сторонние зависимости.
- Тонкая оптимизация после повторного измерения.
После каждого изменения повторяют тот же сценарий. Иначе улучшение итогового балла может не изменить реальный опыт.
Для системной работы подходит поддержка и обслуживание сайта, где скорость проверяется вместе с формами, обновлениями и стабильностью.
Частые вопросы
Поможет ли перенос на VPS?
Только если текущая инфраструктура действительно ограничивает ресурсы или имеет высокую задержку. Медленный запрос базы или тяжелый frontend переедет вместе с сайтом.
Почему PageSpeed каждый раз показывает разный результат?
Влияют сеть, нагрузка сервера, состояние кэша и сторонние сервисы. Смотрите диапазон и лабораторные причины, а решение подтверждайте реальными замерами.
Нужно ли удалять все внешние скрипты?
Нет. Оцените пользу каждого, загружайте некритичные после основного контента и следите за их ошибками. Удаляют дубли и виджеты без измеримой ценности.
Как понять, что оптимизация закончена?
Когда критичные сценарии укладываются в согласованные пороги при обычной и ожидаемой пиковой нагрузке, а мониторинг не показывает деградацию. Абсолютно мгновенного сайта не существует.
