Как найти причину медленной загрузки сайта

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

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

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

Что именно вы называете медленной загрузкой

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

Опишите конкретный сценарий: URL, устройство, сеть, состояние входа, время и действие. Уточните, повторяется ли проблема постоянно или только во время импорта, резервного копирования либо рекламной кампании.

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

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

Пять этапов, которые стоит разделять

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

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

Шаг 1. Посмотрите Network в браузере

Откройте DevTools, вкладку Network, перезагрузите страницу и найдите запрос HTML-документа. Посмотрите его Timing, размер и цепочку редиректов. Затем отсортируйте остальные ресурсы по длительности и размеру.

Отдельно проверьте первый просмотр без кеша и повторный с кешем. Если отключили кеш в DevTools, зафиксируйте это в отчёте. Не сравнивайте такой результат с обычным повторным открытием страницы и не делайте вывод, что одна версия «вдвое быстрее».

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

Возможности панели описаны в справочнике Chrome DevTools Network. Для практики полезнее сохранить небольшой набор наблюдений, чем прикладывать снимок сотни строк без объяснения.

Шаг 2. Измерьте запрос через curl

Для одного HTML-запроса можно посмотреть суммарные времена этапов:

curl -sS -o /dev/null \
  -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nFirst byte: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \
  https://example.com/

Значения в секундах являются отметками от начала операции, а не независимыми длительностями. Например, время TLS включает предшествующие этапы. Для оценки отдельного участка нужно учитывать разность соответствующих отметок.

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

Curl не выполняет JavaScript и не измеряет готовность интерфейса. Быстрый HTML-запрос при медленной странице в браузере указывает на необходимость изучить ресурсы и клиентскую работу, а не объявлять сайт исправным.

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

TTFB, LCP, INP и CLS

TTFB описывает ожидание первого байта ответа, но включает влияние сети и подготовки соединения. Он не равен чистому времени выполнения PHP или SQL-запроса.

LCP относится к появлению основного крупного содержимого, INP — к отзывчивости взаимодействий, CLS — к визуальной стабильности. Это разные свойства страницы. Уменьшение размера картинки может помочь одному сценарию, но не исправить тяжёлый обработчик кнопки.

Актуальное описание Core Web Vitals опубликовано на web.dev. Важно различать лабораторное измерение и реальные пользовательские данные. У нового или малопосещаемого сайта может не быть достаточной полевой выборки, и это не означает автоматическую плохую оценку.

Не превращайте один балл Lighthouse в единственную цель. Проверяйте сценарии посетителя: увидеть текст, открыть меню, отправить форму, положить товар в корзину. Хорошая цифра без исправной формы не делает сайт удобным.

Если долго приходит HTML

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

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

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

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

База данных: ищите запрос, а не магический параметр

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

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

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

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

Внешние API и синхронные интеграции

Страница может ждать ответ геосервиса, CRM, курса валют или другого внешнего API. Если такой запрос выполняется перед формированием HTML, задержка внешнего сервиса становится задержкой вашего сайта.

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

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

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

Если HTML быстрый, а картинки появляются поздно

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

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

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

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

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

Видео и документы

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

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

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

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

JavaScript, шрифты и сторонние скрипты

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

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

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

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

Кеш: что он ускоряет и где опасен

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

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

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

Для проверки сравните некешированный и повторный запросы. Если выигрыш появляется только после первого посещения, оцените, насколько это соответствует реальному трафику проекта. Не выдавайте прогретый кеш за универсальную скорость всех сценариев.

Редиректы, HTTPS и сеть

Лишняя цепочка http → www → https → адрес без www добавляет обращения перед загрузкой страницы. Настройте короткий путь к основному HTTPS-адресу, сохраняя нужную страницу.

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

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

Настройки домена и сертификата рассмотрены в статьях о подключении домена и установке SSL.

Когда нужен более мощный тариф

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

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

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

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

Практический порядок одного расследования

Допустим, карточка товара открывается заметно медленнее статьи. Сначала зафиксируйте Network: долго ли ждётся HTML или задержка начинается после него. Затем повторите несколько запросов с одинаковым состоянием входа.

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

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

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

Пример: медленно открывается только административная панель

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

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

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

Если медленен список записей, изучите число SQL-запросов и сортировку. Иногда каждая строка вызывает дополнительные обращения к базе. Оптимизация конкретной выборки полезнее увеличения памяти всего сервера.

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

Пример: сайт тормозит только ночью

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

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

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

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

Как сравнивать старую и новую площадку

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

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

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

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

Как составить короткий отчёт об ускорении

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

Например: «Изображение первого экрана отдавалось в исходном большом размере; добавлен подходящий вариант и исправлен выбор размера; повторная проверка выполнена на той же странице и мобильном профиле». Такой отчёт объясняет пользу без необоснованного обещания ускорить весь сайт в несколько раз.

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

Как не потерять качество ради скорости

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

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

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

Частые вопросы

Какой показатель самый важный?

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

Почему у меня быстро, а у посетителей медленно?

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

Нужно ли сразу ставить CDN?

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

Можно ли оптимизировать прямо на рабочем сайте?

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

Когда считать проблему исправленной?

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

Контрольный список диагностики

• Описаны URL, устройство, сеть и конкретный медленный сценарий.

• Разделены сеть, ожидание HTML, ресурсы и работа браузера.

• Сохранены несколько исходных измерений с понятным режимом кеша.

• Проверены журналы, база и внешние интеграции.

• Оценены изображения, видео, шрифты и JavaScript.

• Изменения выполняются по одному и проверяются повторно.

• Новые ресурсы выбираются по найденному ограничению.

• После оптимизации пройдены формы и ключевые операции.

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