Почему сайт тормозит и что исправить

«Сайт долго грузится» может означать несколько разных проблем. Иногда экран остаётся пустым, иногда текст уже появился, но кнопки не реагируют, а иногда всё работает быстро, пока не открываешь блог или каталог. Исправления начинаются с уточнения симптома. Иначе можно сжать все картинки и почти не повлиять на задержку, которая возникает на сервере.

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

Проверяйте не только главную

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

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

Читайте PageSpeed без погони за сотней

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

Google: как устроен отчёт PageSpeed Insights

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

web.dev: определения и пороги Core Web Vitals

Сначала найдите, где начинается ожидание

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

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

Изображения: подходящий размер и правильный момент загрузки

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

Главную иллюстрацию первого экрана не стоит откладывать тем же способом, что изображения внизу страницы. Браузер должен обнаружить её достаточно рано. Для изображений заранее резервируйте место, чтобы текст и кнопки не смещались после загрузки. Подробный разбор цепочки задержек LCP есть в руководстве web.dev.

web.dev: поиск причин и оптимизация LCP

Скрипты и кэш: ускорять без потери функций

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

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

Как принять результат доработки

• Сравните те же URL на том же типе устройства и соединения.
• Повторите несколько замеров, а не выбирайте один самый удачный.
• Проверьте меню, формы, фильтры и изображения после изменений.
• Убедитесь, что новые публикации и изменения из CMS появляются на сайте.
• Зафиксируйте, что именно исправлено: ожидание сервера, вес ресурса или задержка реакции интерфейса.

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

Обложка: иллюстрация, созданная с помощью ИИ специально для SOZDAM.SITE. Это визуальная метафора, а не скриншот клиентского проекта.