Заголовок уже появился, а меню ещё несколько секунд не реагирует? Менять оформление в такой ситуации бесполезно. Браузер может быть занят тяжёлым JavaScript или сторонним виджетом. Прежде чем что-либо исправлять, определите, где возникает задержка: сервер долго отвечает, основное содержимое поздно появляется или страница медленно реагирует на действия.
Измерьте проблему до изменений
Проверьте несколько важных страниц: главную, типичную статью, страницу с формой и, если есть, каталог. У них могут быть разные шаблоны и наборы ресурсов. Не ограничивайтесь быстрым компьютером: на менее мощном телефоне обработка тех же скриптов нередко занимает больше времени.
Начать можно с PageSpeed Insights и панели «Производительность» в инструментах разработчика браузера. Лабораторный тест воспроизводит загрузку в заданных условиях и помогает найти проблемные файлы. Полевые данные, если они доступны, показывают, что происходило у реальных посетителей за определённый период. Результаты могут расходиться из-за различий в устройствах, сети и поведении пользователей.
- TTFB — время до первого байта ответа. Высокое значение может указывать на задержку сервера, приложения или сети, но не позволяет сразу назвать причину.
- LCP — время появления крупнейшего видимого элемента, часто изображения или текстового блока в верхней части страницы.
- INP — показатель отзывчивости при взаимодействиях. На него влияют долгие задачи JavaScript и занятость основного потока браузера.
- CLS — показатель сдвигов элементов при загрузке. Он не измеряет скорость напрямую, но кнопкой, которая внезапно сместилась, пользоваться неудобно.
Запишите исходные показатели, адрес страницы, тип устройства и условия проверки. Одного запуска недостаточно: меняются и состояние сети, и нагрузка на сервер. Сделайте несколько замеров с одинаковыми настройками и ищите повторяющиеся проблемы. Ориентиры для пользовательских показателей — LCP не более 2,5 секунды, INP не более 200 мс и CLS не более 0,1 на 75-м процентиле посещений. Это пороги для диагностики, а не обещание одинаковой скорости для всех.
Начните с изменений, которые почти не затрагивают дизайн
Уменьшите вес изображений
Нет смысла загружать изображение шириной 3000 пикселей для блока шириной 700 пикселей. Найдите крупные файлы в списке сетевых запросов, сравните их размеры с размерами на странице и подготовьте подходящие версии. Для адаптивной вёрстки укажите несколько вариантов через srcset и sizes — тогда телефону не придётся скачивать файл для широкого монитора.
Для фотографий обычно подходят JPEG или WebP; AVIF при наличии поддержки может уменьшить файл ещё сильнее. SVG удобен для простой графики, а PNG — там, где важны его особенности, например точное отображение элементов с прозрачностью. Оценивайте результат на реальном экране: читается ли текст на схеме, не испортились ли границы объектов. Перед автоматической конвертацией сохраните оригиналы, чтобы можно было откатить неудачную замену.
Изображения ниже первого экрана часто можно загружать отложенно с помощью loading="lazy". Но если главная иллюстрация определяет LCP, откладывать её загрузку не нужно: браузер должен обнаружить файл как можно раньше. Задайте размеры изображений или зарезервируйте для них место через CSS, чтобы текст не смещался при загрузке.
Проверьте шрифты
Когда каждое начертание шрифта загружается отдельным файлом, запросов становится больше. Уберите неиспользуемые веса, по возможности используйте современные форматы и проверьте, какие наборы символов нужны сайту. Если в подмножестве нет кириллицы, браузер подставит другой шрифт. Это легко не заметить, поэтому отдельно проверьте русскоязычные заголовки и основной текст.
Правило font-display: swap позволяет сразу показать текст запасным шрифтом, но при замене возможен сдвиг. Подберите запасной шрифт с близкими пропорциями и измерьте CLS. Предварительно загружать стоит только файл, действительно нужный на первом экране: если повысить приоритет всех шрифтов, они начнут конкурировать за сеть с остальными ресурсами.
Уберите задержки в CSS и JavaScript
Большой файл не обязательно хуже множества маленьких. Важнее, когда он загружается, в каком порядке выполняется код и нужен ли он на этой странице. В инструментах разработчика найдите файлы, блокирующие отображение, и задачи, которые надолго занимают основной поток. Разделение кода по страницам часто полезнее, чем простое удаление пробелов из файлов.
Оставьте на первом экране только необходимое
Стили, от которых зависит первый экран, должны быть доступны вовремя. Иначе посетитель увидит пустую или неправильно оформленную страницу. Остальные стили можно загружать так, чтобы они не задерживали первое отображение, но результат придётся проверить: если ошибиться с выбором «критического CSS», элементы заметно перерисуются. Для начала уберите стили старых компонентов и отключите файлы плагинов на страницах, где они не нужны, если система сайта позволяет сделать это без нарушения зависимостей.
Собственным скриптам, которые не должны выполняться во время разбора HTML, часто подходит атрибут defer. Атрибут async годится для независимых скриптов, но не гарантирует порядок выполнения. Не назначайте их наугад: меню, форма или счётчик могут зависеть от другой библиотеки. После каждой правки проверьте сайт на телефоне и в браузере без сохранённого кэша.
Пересмотрите сторонние вставки
Чат, карта, видео, аналитика и реклама загружают скрипты с других серверов. Иногда один короткий фрагмент кода запускает длинную цепочку запросов. Составьте список вставок и посмотрите, на каких страницах они нужны. Карту на странице контактов незачем загружать вместе с каждой статьёй. Видео ниже первого экрана можно сначала показывать обложкой, а загружать при взаимодействии — если посетителю понятно, что перед ним видео.
Не удаляйте нужную аналитику ради высокого балла в тесте. Лучше устранить дублирующиеся подключения и неиспользуемые виджеты. Если сервис позволяет менять способ загрузки, оценивайте не только размер скрипта, но и время его выполнения на мобильном устройстве.
Проверьте сервер, кэш и передачу файлов
Если TTFB стабильно высок на нескольких страницах, сжатие картинок не ускорит первый ответ. Сравните статическую страницу со страницей, которую приложение собирает из базы данных. Если задерживается только вторая, проверьте запросы к базе, плагины, шаблон и серверное кэширование. Если медленно загружается всё, посмотрите на нагрузку сервера и настройки хостинга.
Кэширование готовой HTML-страницы может сократить время генерации ответа, но подходит не везде. Для корзины, личного кабинета и страниц с персональными данными нужны отдельные правила. Перед включением кэша или изменением конфигурации сделайте резервную копию файлов и базы данных, запишите текущие настройки и предусмотрите откат. Затем откройте страницы как обычный посетитель и после входа в учётную запись: чужие данные не должны попадать в кэшируемый ответ.
Для изображений, шрифтов, CSS и JavaScript настройте разумные сроки хранения в браузере. Если при обновлении меняются версии файлов, их можно кэшировать дольше без риска показывать старое оформление после публикации. Проверьте сжатие текстовых ресурсов и доступные возможности HTTP/2 или HTTP/3. Новый протокол сам по себе не исправит тяжёлую страницу — сравните замеры до и после.
CDN может помочь, если посетители находятся далеко от основного сервера или сайт отдаёт много статических файлов. Для небольшой местной аудитории выигрыш бывает скромным. После подключения проверьте обновление файлов, кэширование HTML и работу форм. Устаревшая страница после публикации остаётся проблемой, даже если тест скорости показывает улучшение.
Как вносить изменения без поломок
Чаще всего проблемы возникают не при сжатии файла, а после изменения порядка загрузки ресурсов или правил кэша. Если на работающем сайте есть формы или пользовательские разделы, сначала сделайте резервную копию и, по возможности, испытайте правки на тестовой копии. Не внедряйте сразу несколько оптимизаций: иначе будет трудно понять, какая ускорила страницу, а какая сломала интерфейс.
- Выберите типовую страницу и зафиксируйте её показатели, крупные запросы и ошибки в консоли браузера.
- Внесите одну правку: например, замените слишком большое изображение или отключите виджет там, где он не нужен.
- Очистите соответствующий кэш и несколько раз повторите замеры в тех же условиях.
- Проверьте меню, ссылки, формы и изображения на телефоне и компьютере. Только после этого переходите к следующей правке.
Общая оценка теста — не единственный критерий. Если LCP улучшился, но форма перестала работать, правку нужно пересмотреть. Если балл почти не изменился, хотя крупное изображение стало появляться раньше при обычном соединении, изучите подробности отчёта: теперь главным ограничением может быть другой ресурс. Записывайте, что изменили, на какой странице и какой результат получили.
Что делать при разных симптомах
| Наблюдение | Что проверить в первую очередь |
|---|---|
| Долго видна пустая страница | Время ответа сервера, блокирующие стили, основной HTML и цепочки перенаправлений |
| Текст появился, крупная иллюстрация — гораздо позже | Размер изображения, его приоритет, отложенную загрузку и способ обнаружения браузером |
| Страница видна, но кнопки реагируют с задержкой | Долгие задачи JavaScript, сторонние вставки и обработчики событий |
| На телефоне медленно, на компьютере нормально | Время выполнения скриптов, размеры мобильных изображений и загрузку шрифтов |
| Повторное посещение почти не быстрее первого | Правила кэша статических файлов и их версионирование |
Допустим, LCP на странице статьи приходится на фотографию в начале текста, а в сетевой панели видно, что браузер скачивает оригинал шириной 3000 пикселей. Начните с версии подходящего размера и убедитесь, что на изображении нет loading="lazy". Затем повторите замер и откройте страницу на узком экране: подпись должна оставаться читаемой, а блок под фотографией — не смещаться при загрузке.