Быстродействие сайта — не просто показатель в отчёте, а часть реального опыта пользователя. Страница может открываться быстро на офисном компьютере, но тормозить на бюджетном смартфоне из-за тяжёлого JavaScript, картинок, рекламных вставок или сетевой задержки. Хорошая оптимизация начинается с измерения конкретного сценария, а не с обещания достичь 100 баллов PageSpeed любой ценой.
Первичная диагностика: что и где измерять
Соберите список типовых страниц: главная, услуга, категория, карточка товара, статья, поиск, форма и личный кабинет. Для каждого шаблона зафиксируйте устройство, скорость подключения, регион тестирования, состояние кэша, наличие авторизации и сторонних скриптов. Измеряйте не только первый экран, но и взаимодействия пользователя после загрузки.
В PageSpeed Insights сначала смотрите реальные полевые данные, если они доступны, затем лабораторные причины. Используйте WebPageTest/DevTools или собственный RUM для детализации. Фиксируйте дату и версию: иначе сравнение двух скриншотов может отражать разные условия, а не эффект разработки.
Какие метрики важны
| Метрика | Что измеряет | Частый источник проблемы |
|---|---|---|
| TTFB | Задержку первого байта от сервера | Сервер, сеть, кэш, защита |
| LCP | Отрисовку основного содержимого | Критическое изображение, CSS, ответ сервера |
| INP | Отзывчивость взаимодействий | Долгие JS-задачи, сложный DOM |
| CLS | Неожиданные смещения макета | Изображения без размеров, динамические вставки |
| Размер страницы / запросы | Объём переданных данных и загрузок | Видео, шрифты, third-party |
TTFB и размер страницы полезны как причины и ограничения, но не определяют Core Web Vitals сами по себе. Запросов меньше — не всегда быстрее: отдельные ресурсы могут хорошо кэшироваться и грузиться параллельно.
Изображения: чаще всего простой выигрыш
Экспортируйте оригиналы с подходящим качеством, используйте современные форматы при поддержке браузеров, адаптивные srcset и sizes. Не отдавайте изображение 2400 пикселей на контейнер шириной 400 пикселей без необходимости. Для фотографий проверьте визуальные артефакты, особенно на товарах: потеря качества может ухудшить конверсию.
Первому крупному изображению обычно нужен приоритет загрузки, а картинкам ниже экрана — разумный lazy loading. Добавляйте width/height или aspect-ratio, чтобы браузер резервировал пространство до загрузки. Alt пишут для доступности и смысла, а не ради производительности.
CSS, JavaScript и критический путь
Сначала определите, какие стили необходимы для первого экрана, а какие можно загрузить позже. Удаляйте действительно неиспользуемый CSS, но не ломайте редкие состояния интерфейса, например мобильное меню и форму после валидационной ошибки. Разделяйте JS-код по задачам, переносите тяжёлые операции из главного потока и проверяйте эффект на INP.
Не склеивайте все JS-файлы и CSS-файлы автоматически. При HTTP/2 и HTTP/3, современных механизмах кэширования и модульной сборке это может ухудшить поддержку и повторную загрузку. Старые рекомендации GTmetrix «обязательно объединять внешние CSS и JavaScript» следует оценивать в контексте текущего стека.
Шрифты и сторонние сервисы
Проверьте набор начертаний, фактические глифы, способ загрузки веб-шрифтов, font-display и влияние на CLS. Сторонние виджеты, чаты, карты, пиксели рекламы и аналитики загрузите по обоснованной политике, учитывая согласия пользователя и бизнес-цели. Не убирайте счётчик конверсий ради красивого лабораторного балла без согласования с владельцем проекта.
Особенно внимательно относитесь к встраиваемым видео, iframe и рекламным блокам: они могут загрузить много сторонних запросов. При необходимости используйте плакаты и отложенную инициализацию до действия пользователя, если это не ухудшает доступность важных функций.
Сервер, кеширование, CDN и география
Изучите распределение TTFB по регионам и типам запросов. Страницы с персональными данными, корзина и авторизация не должны бездумно кэшироваться публичным CDN. Для статических файлов полезны корректные Cache-Control, сжатие и адресуемые версии файлов. Для динамических страниц анализируйте SQL, CMS-сниппеты, сторонние API и генерацию HTML.
Антибот-проверки и сетевые защиты нельзя диагностировать только одним браузером: если они дают пользователю заглушку, а подтверждённому поисковику ошибочный ответ, ускорение кэша не решит проблему индексации.
План работ на одну итерацию
- Сформировать список URL по типам шаблонов и приоритетным конверсиям.
- Снять исходные показатели field/lab и ответ сервера.
- Выбрать одну измеряемую гипотезу: уменьшить LCP, улучшить INP или сократить TTFB.
- Внести изменение в тестовой среде и проверить важные пользовательские сценарии.
- Повторить измерения в сопоставимых условиях.
- Развернуть с возможностью отката; наблюдать реальные данные несколько недель.
- Оценить не только скорость, но и ошибки формы, конверсии, отказоустойчивость и доступность.
Чего не делать
Не покупать «ускорение до 100» без аудита, не удалять функциональность без бизнес-решения, не переносить все скрипты в defer/async механически, не запускать тяжёлую оптимизацию по одному результату PSI, не менять CDN и CMS одновременно без бэкапа. Если после изменения Lighthouse стал лучше, а заявки перестали отправляться, результат нельзя считать успешным.
Следующие шаги
Подробно разобраны PageSpeed Insights и Core Web Vitals, alt и загрузка изображений, мобильная индексация. Первоисточник: web.dev — Web Vitals.
Обновлено: 11.10.2026