+7 (495) 801-60-42

PageSpeed Insights: как читать отчёт и ускорить сайт на практике

В этой статье разберём, pagespeed insights как пользоваться, как читать отчёт без догадок и на какие правки тратить время в первую очередь. Покажем, как метрики LCP, INP и CLS связаны с кодом, сервером и фронтендом, и дадим практические чек-листы для ускорения.

Зачем вообще смотреть PSI и что он показывает

PageSpeed Insights (PSI) объединяет данные полевых метрик (Chrome UX Report, если доступно) и лабораторный прогон Lighthouse. Это не «оценка дизайна», а набор сигналов о реальном опыте пользователей. Ключевые блоки отчёта:

  • Поле: Core Web Vitals (LCP, INP, CLS) по реальным сессиям, распределения и пороги.
  • Лаборатория: имитация загрузки на throttling-профиле — FCP, LCP, INP (Lab), TBT как прокси для блокировок главного потока.
  • Диагностика: конкретные причины замедления — блокирующие ресурсы, крупные пэйлоады, неиспользуемый JS/CSS, изображения без современного формата и т. п.
  • Возможности: приоритетные рекомендации с ориентировочной экономией времени.

Важно: лабораторные цифры — сценарий «хуже среднего». Смотрите и поле, и лабу. Изменения кода проверяйте повторными прогонами и реальными метриками в аналитике.

Core Web Vitals: как читать LCP, INP и CLS

  • LCP (Largest Contentful Paint): когда появляется крупнейший видимый блок контента (часто hero-изображение или заголовок). Медленный LCP = тяжёлые картинки, рендер-блокирующие ресурсы, медленный TTFB.
  • INP (Interaction to Next Paint): время реакции интерфейса на клик/тап/ввод. Плохой INP = тяжёлые обработчики событий, долгие таски в main thread, синхронные запросы.
  • CLS (Cumulative Layout Shift): суммарные смещения макета. Большой CLS = отсутствие размеров у медиа, поздние вставки баннеров/шрифтов, отложенные стили.

Пороги: LCP ≤ 2.5 c, INP ≤ 200 мс, CLS ≤ 0.1 для 75-го перцентиля полевых данных.

PageSpeed Insights: как пользоваться и что мерить

1) Запустите анализ для Desktop и Mobile — мобильный результат критичнее: слабее CPU/сеть, и от него зависит качество мобильного UX и конверсии.

2) Сверьте полевые CWV и лабораторные значения. Если поле «Недостаточно данных» — ориентируйтесь на лабораторию, но включайте собственную телеметрию (RUM).

3) Пройдитесь по «Возможностям» и «Диагностике»: это дорожная карта исправлений.

4) Сфокусируйтесь на метриках по убыванию влияния на пользователей: LCP → INP → CLS → TBT/JS-профиль.

5) После правок прогоните повторно и подтвердите улучшения в реальных метриках (Яндекс.Метрика, RUM, логирование Web Vitals в аналитике).

Быстрые выигрыши: изображения, форматы и lazy-load

Изображения часто дают 40–70% веса страницы. Что делать:

  • Ленивая загрузка изображений: используйте loading="lazy" для внеэкрана; hero и LCP-контент — без lazy, загружайте рано (preload) и в нужном размере.
  • WebP AVIF внедрение: конвертируйте медиа в WebP/AVIF с резервом JPEG/PNG через Content Negotiation или <picture>. AVIF обычно даёт лучший сжатие, WebP — шире поддержка; тестируйте визуальные артефакты.
  • Размеры и плотность: всегда указывайте width/height или aspect-ratio для нулевого CLS; генерируйте responsive-сетки srcset/sizes.
  • Сжатие и CDN: modern compression (q≈75–85 для JPEG/WebP), CDN с WebP/AVIF on-the-fly и кешем ближе к пользователю.

Очистка рендера, критический CSS и оптимизация JS/CSS

Рендер-блокирующие ресурсы — главные враги раннего контента и LCP.

  • Очистка рендера критический css: инлайн-критический CSS (Above-The-Fold) и отложенная загрузка остального с media="print" → onload или rel="preload" as="style" с последующим rel="stylesheet". Не переусердствуйте: следите за объёмом инлайна.
  • Оптимизация js и css: удаляйте неиспользуемый код (tree-shaking, code-splitting, purgeCSS), объединяйте мелкие чанки там, где это уменьшает чардж соединений, минимизируйте и используйте HTTP/2+.
  • Defer/async: для скриптов без блокирующих зависимостей — defer/async; критические inline-скрипты — минимальны и коротки.
  • Тяжёлые библиотеки: проверьте, действительно ли нужны moment.js, lodash целиком, целые UI-фреймворки. Заменяйте на лёгкие аналоги или импортируйте только используемое.
  • Шрифты: preload для критических, font-display: swap/fallback, ограничьте набор начертаний, используйте woff2 и локальные источники.

Сервер и сеть: TTFB, кеширование и preconnect/preload

Быстрый сервер — фундамент хорошего LCP.

  • Кеширование браузера: настройте Cache-Control и ETag. Для неизменяемых ассетов — Cache-Control: public, max-age=31536000, immutable; для HTML — короткий TTL и валидаторы.
  • Сжатие: включите brotli/gzip для текста; проверьте сжатие на CDN/edge.
  • Preload preconnect практики: preconnect к критическим доменам (CDN, шрифты), preload для LCP-изображения, ключевых шрифтов и Above-The-Fold CSS. Избегайте избыточного preconnect — каждое соединение стоит RTT.
  • HTTP/2 и HTTP/3: включите ALPN, 0-RTT для QUIC; проверьте приоритеты загрузки.
  • TTFB: оптимизируйте бэкенд (кеш на уровне приложения, SSR-кэш, базу), сократите редиректы.

INP на практике: отзывчивость интерфейса

  • Разбивайте долгие задачи: используйте requestIdleCallback, setTimeout(0), web workers для тяжёлых вычислений.
  • Снижение TBT: уберите синхронные XHR, большие инициализации при загрузке; лениво монтируйте виджеты и трекеры.
  • События: делегируйте обработчики, избегайте тяжёлых синхронных вычислений в onClick/onInput, используйте passive listeners для скролла.
  • Виртуализация списков: рендерите только видимые элементы; пагинация вместо бесконечных DOM-вставок.

CLS: как исключить скачки макета

  • Фиксируйте размеры: width/height или aspect-ratio для изображений/видео/iframes.
  • Зарезервируйте место под динамические блоки: баннеры, виджеты, формы.
  • Шрифты: font-display: swap и прогнозируемые fallback’и с близкой метрикой.
  • Поздние вставки: избегайте инъекций DOM до первого интерактива; если нужно — делайте под ними «скелетон» с фиксированной высотой.

Ускорение мобильной версии сайта: тонкие настройки

  • Критический путь короче: меньше блокирующих стилей и скриптов, меньше сторонних виджетов.
  • Изображения: агрессивнее резать размеры и качество для мобильных в srcset.
  • Тач-оптимизация: события без лагов, быстрые переходы, минимизация перерисовок при скролле.
  • Экономия трафика: Feature detection и условная загрузка тяжёлых модулей только на нужных страницах.

Как улучшить PageSpeed: рабочий процесс

  • Бейте задачи на итерации: сначала LCP (критические ассеты, сервер, LCP-изображение), затем INP (JS-профиль), затем CLS (разметка). Каждая итерация — проверка в PSI + полевых метриках.
  • RUM: подключите сбор Web Vitals в аналитику; соотносите изменения с конверсией. Подробнее о проверке гипотез — в статье
    .
  • Продуктовый приоритет: ускоряйте страницы, дающие больше трафика/выручки.

Инструменты и стек: чем измерять помимо PSI

  • Lighthouse (в DevTools/CI) — лабораторные прогоны с профилированием.
  • WebPageTest — плейлисты, визуальные сравнения, контроль точек доступа и сетей.
  • RUM/аналитика — Яндекс.Метрика, собственный beacons-сбор Web Vitals. Базовые шаги для настройки — в статье
    .
  • CDN/Edge-инструменты — логи, кеш-хиты, приоритеты HTTP/2/3.

Кейсы внедрения на практике: типовые сценарии правок

  • Сценарий 1: медленный LCP из-за hero.jpg 600–900 КБ. Решение: генерация AVIF/WebP, responsive srcset, preload LCP-ресурса, правильные размеры — минус сотни миллисекунд.
  • Сценарий 2: высокий INP из-за тяжёлого UI-фреймворка и монолитного бандла. Решение: code-splitting по маршрутам, динамический импорт виджетов ниже фолда, вынос вычислений в Web Worker.
  • Сценарий 3: CLS из-за баннера и шрифтов. Решение: резерв блоков, aspect-ratio для медиа, font-display: swap, предзагрузка woff2.

Чек-лист ускорения (поставьте галочки перед деплоем)

  • Критический CSS инлайн, остальной — отложенно; нет лишних блокировок рендера
  • LCP-изображение оптимизировано, имеет preload и точный размер
  • Ленивая загрузка изображений вне экрана включена корректно
  • Внедрены WebP/AVIF с fallbacks, корректный srcset/sizes
  • JS разбит на чанки, неиспользуемый код удалён, скрипты с defer/async
  • Убраны/отложены тяжёлые сторонние скрипты и виджеты
  • Cache-Control настроен, статика с длинным TTL, HTML — короткий TTL
  • Brotli/gzip включены, HTTP/2/HTTP/3 работают, приоритеты проверены
  • Preconnect к CDN/шрифтам и preload для ключевых ассетов без избыточности
  • Шрифты: woff2, ограничены начертания, font-display: swap
  • CLS-триггеры устранены: размеры для медиа/iframes, резерв под динамические блоки
  • INP улучшен: нет долгих тасков, события оптимизированы, есть виртуализация списков
  • RUM-сбор Web Vitals включён, метрики валидируются после релиза

Вывод: что делать дальше

Начните с чтения отчёта PSI и определения приоритетов по LCP → INP → CLS, затем применяйте практики из чек-листа и подтверждайте результат реальными метриками. Если нужна команда, которая быстро развернёт пайплайн оптимизации — подключайтесь: мы поможем на уровне фронтенда, сервера и аналитики. Посмотрите услуги агентства: Разработка веб-приложений и SEO и продвижение. Это ускорит внедрение правок и даст предсказуемый процесс улучшений без лишних итераций.

---

Примечание: оценка производительности сайта — непрерывный процесс. Возвращайтесь к PSI и RUM после каждого релиза и отслеживайте динамику по ключевым страницам.

Другие полезные статьи

Делимся экспертизой, разбираем кейсы и рассказываем, как превращать идеи в работающие digital-продукты