Почему сайт загружается медленно

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

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

1. Сначала отделите ощущение от измерения

Откройте страницу в PageSpeed Insights и проверьте отдельно мобильный и настольный режим. Инструмент показывает лабораторную диагностику Lighthouse, а при наличии достаточных данных — агрегированный опыт реальных пользователей из Chrome UX Report. Эти наборы данных отвечают на разные вопросы, поэтому их расхождение не означает ошибку.

Для реального опыта Google использует три Core Web Vitals: LCP оценивает загрузку основного содержимого, INP — отзывчивость после взаимодействия, CLS — визуальную стабильность. В официальной документации Google хорошими ориентирами названы LCP не более 2,5 секунды, INP менее 200 мс и CLS менее 0,1. Оценка проводится по 75-му процентилю посещений, а не по самому удачному запуску теста.

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

2. Проверьте ответ сервера и серверную обработку

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

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

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

3. Найдите самый тяжёлый элемент первого экрана

На многих страницах LCP-элементом становится главное изображение, крупный текстовый блок или баннер первого экрана. В DevTools или Lighthouse определите конкретный элемент, а затем проверьте, когда браузер узнаёт о нём и сколько времени занимает загрузка.

Для изображения используйте реальный размер, современный формат и разумное сжатие. Не заставляйте телефон скачивать фотографию в несколько раз шире экрана. При этом главное изображение первого экрана не следует лениво загружать: рекомендации web.dev по LCP советуют сделать LCP-ресурс доступным в исходном HTML и запускать его загрузку как можно раньше.

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

4. Посчитайте изображения, шрифты, стили и скрипты

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

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

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

5. Проверьте сторонние сервисы и действия пользователя

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

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

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

6. Найдите скачки макета и поздно появляющиеся блоки

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

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

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

7. Проверьте кэш, CDN и повторное посещение

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

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

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

Порядок проверки без хаотичных оптимизаций

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

выберите одну важную страницу и сценарий;
сохраните исходные лабораторные и полевые показатели;
проверьте время ответа HTML;
определите LCP-элемент и блокирующие ресурсы;
оцените изображения, шрифты и сторонние скрипты;
проверьте INP и CLS на реальном устройстве;
внесите одно изменение и повторите измерение.

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

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