Скорость загрузки давно перестала быть только заботой разработчиков. От неё зависит, дождётся ли посетитель содержимого, сможет ли он без раздражения пользоваться фильтрами и формами и вернётся ли в поиск, чтобы выбрать другой сайт. Поисковики учитывают удобство страниц, а Google ещё и формализовал его в виде набора метрик — Core Web Vitals.
В этом уроке разберём, что измеряют эти метрики, какие значения считаются хорошими, откуда брать данные и с чего начинать ускорение. Особенности мобильной версии, которые тесно связаны со скоростью, вынесены в урок «Мобильная версия и адаптивность».
Три метрики Core Web Vitals
Core Web Vitals описывают три стороны впечатления от страницы: как быстро появляется главное, как быстро страница реагирует на действия и не прыгает ли вёрстка.
- LCP (Largest Contentful Paint) — время, за которое отрисовывается самый крупный видимый элемент первого экрана: главное изображение, баннер или большой блок текста. Это приближение к моменту, когда посетитель видит, что страница загрузилась.
- INP (Interaction to Next Paint) — задержка между действием пользователя (нажатием, касанием, вводом с клавиатуры) и следующим обновлением экрана. Метрика учитывает взаимодействия за весь визит и отражает самые медленные из них. INP заменил прежнюю метрику FID, которая измеряла только первое взаимодействие.
- CLS (Cumulative Layout Shift) — суммарная величина неожиданных сдвигов вёрстки: когда текст уезжает вниз из-за подгрузившейся картинки или баннера, а кнопка смещается в момент нажатия.
| Метрика | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|
| LCP | до 2,5 с | от 2,5 до 4 с | больше 4 с |
| INP | до 200 мс | от 200 до 500 мс | больше 500 мс |
| CLS | до 0,1 | от 0,1 до 0,25 | больше 0,25 |
Страница считается удовлетворяющей требованиям, если хорошие значения достигаются как минимум у 75 % визитов — то есть оценивается 75-й перцентиль. Это сделано, чтобы учитывать не только пользователей с быстрым интернетом и мощными телефонами, но и заметную часть аудитории в худших условиях.
Полевые и лабораторные данные
Есть два принципиально разных способа измерить скорость, и путаница между ними — частая причина неверных выводов.
Полевые данные
Это измерения у реальных посетителей, которые браузер Chrome собирает и передаёт в общий отчёт об опыте пользователей. Именно на полевые данные Google опирается, когда оценивает страницы. Их показывают PageSpeed Insights в верхнем блоке отчёта и отчёт Core Web Vitals в Search Console, где страницы сгруппированы по похожим шаблонам. Ограничение одно: данных должно быть достаточно, поэтому у небольших сайтов и редко посещаемых страниц полевой статистики может не быть вовсе.
Лабораторные данные
Это разовый тест в контролируемых условиях — например, в Lighthouse или в нижней части отчёта PageSpeed Insights. Тест эмулирует определённое устройство и скорость сети и выдаёт подробную диагностику: какие ресурсы блокируют отрисовку, какие изображения слишком тяжёлые, какие скрипты долго выполняются. Лабораторный балл удобен для поиска причин и проверки исправлений, но не равен тому, что видят ваши посетители. Кроме того, INP в лаборатории напрямую не измеряется — вместо него тест показывает косвенные метрики загрузки главного потока.
Правильная последовательность такая: по полевым данным найти шаблоны страниц с проблемами, в лабораторном тесте разобраться в причинах, исправить и снова смотреть на полевые данные — они обновляются с задержкой, поскольку собираются за скользящий период.
Что замедляет сайт и как это исправить
Если плохой LCP
- Тяжёлые изображения. Главная картинка первого экрана весит мегабайты. Сжимайте изображения, используйте современные форматы WebP и AVIF, отдавайте размер под экран устройства. Подробнее об изображениях — в уроке «Картинки и видео в поиске».
- Ленивая загрузка не там. Атрибут
loading="lazy"полезен для картинок ниже первого экрана, но на главном изображении он откладывает его загрузку. Главному изображению, наоборот, можно задать высокий приоритет. - Медленный ответ сервера. Если сервер долго формирует страницу, всё остальное начинается позже. Помогают кеширование страниц, оптимизация запросов к базе данных, CDN для статических файлов.
- Блокирующие ресурсы. Стили и скрипты в начале страницы, без которых браузер не начинает отрисовку. Критичные стили встраивают, остальное загружают отложенно.
Если плохой INP
- Слишком много JavaScript. Виджеты чатов, счётчики, рекламные и маркетинговые скрипты, тяжёлые фреймворки занимают главный поток браузера, и он не успевает реагировать на нажатия. Проведите ревизию сторонних скриптов и удалите ненужные.
- Длинные задачи. Обработчики, которые выполняются сотни миллисекунд, — например, пересчёт фильтров каталога. Их разбивают на части или переносят тяжёлые вычисления в фон.
- Большой и сложный DOM. Страница с тысячами элементов медленно перерисовывается после каждого действия.
Если плохой CLS
- Изображения и видео без размеров. Указывайте ширину и высоту или пропорции, чтобы браузер заранее резервировал место.
- Баннеры и встраиваемые блоки, которые появляются над содержимым после загрузки. Резервируйте под них место заранее.
- Веб-шрифты. Когда шрифт подгружается, текст может менять размер. Помогают предзагрузка шрифтов и подбор запасного шрифта с похожими метриками.
Насколько скорость влияет на позиции
Важно не переоценивать роль Core Web Vitals в ранжировании. Google относит их к сигналам удобства страниц, и они работают скорее как дополнительный фактор: при сопоставимой релевантности быстрая страница получает преимущество, но медленная страница с лучшим ответом на запрос всё равно может оказаться выше быстрой и бесполезной. Яндекс не публикует аналогичного набора метрик, но удобство и скорость сайта отражаются на поведении пользователей, которое для него особенно значимо. Как в целом устроены факторы ранжирования, рассказано в уроке «Факторы ранжирования: что известно и что мифы».
Гораздо заметнее скорость влияет на бизнес-показатели: на долю посетителей, которые дожидаются загрузки, на глубину просмотра, на конверсию в заявку и покупку. Поэтому ускорение сайта оправдано даже тогда, когда позиции уже высокие. Удобно оценивать эффект именно так: сравнивать конверсию и долю отказов на шаблонах до и после ускорения, а не ждать изменения позиций.
Совет. Не гонитесь за круглыми 100 баллами в лабораторном тесте. Цель — зелёная зона полевых метрик для основных шаблонов: главной, категорий, карточек и статей. Дальнейшая полировка редко окупается.
Как организовать работу над скоростью
Ускорение — разовая работа по приоритетам и контроль раз в квартал; постоянным процессом оно становится, только если сайт большой и меняется разработкой каждую неделю. Начните с отчёта Core Web Vitals в Search Console: он покажет группы похожих страниц с проблемами и подскажет, какой шаблон чинить первым. Для каждого шаблона составьте короткий список причин по лабораторному тесту и оцените трудоёмкость исправлений вместе с разработчиками. Приоритет — исправления, которые затрагивают много страниц сразу: шаблон карточки товара важнее отдельной лендинговой страницы.
Отдельное правило — контроль новых функций. Каждый новый виджет, счётчик или рекламный скрипт добавляет вес и нагрузку. Договоритесь в команде, что подключение стороннего кода проходит проверку на влияние на скорость, а раз в квартал проводится ревизия: всё ли подключённое ещё используется.
Типичные находки на разных сайтах
Причины медленной работы повторяются от проекта к проекту, и по типу сайта обычно можно заранее предположить, где искать.
- Интернет-магазины. Тяжёлые фотографии товаров в листингах, слайдеры на первом экране, скрипты рекомендаций, чатов и сервисов отзывов, медленные фильтры, которые пересчитывают каталог на каждое нажатие. Карточки товаров часто страдают от сдвигов вёрстки из-за блоков цены и наличия, которые подгружаются отдельно.
- Медиа и блоги. Рекламные блоки, которые подгружаются после текста и сдвигают его вниз, встраиваемые видео и посты из соцсетей, множество счётчиков. Здесь главная метрика для работы — CLS: резервирование мест под рекламу и встраиваемые элементы часто даёт больше, чем любая оптимизация кода.
- Корпоративные сайты и лендинги. Видео на фоне первого экрана, тяжёлые анимации, несколько вариантов веб-шрифтов, библиотеки, подключённые ради одной функции. Такие сайты часто собраны на конструкторах, где возможности оптимизации ограничены, и тогда приходится отказываться от лишних эффектов.
Отдельно стоит проверить сервер. Время ответа сервера на запрос страницы — первая составляющая любой задержки: пока сервер формирует HTML, браузер ничего не может отрисовать. Если оно стабильно велико, оптимизация изображений и скриптов даст лишь частичный эффект. В таком случае помогают кеширование готовых страниц, обновление версии платформы и модулей, перенос на более производительный хостинг и CDN для статических файлов. Статистика обхода в панелях вебмастеров тоже показывает время ответа сервера роботу — её рост часто совпадает с жалобами посетителей на медленную работу сайта.
Что сделать после урока
- Откройте отчёт Core Web Vitals в Search Console и выпишите группы страниц в жёлтой и красной зонах.
- Проверьте главную, категорию, карточку и статью в PageSpeed Insights и для каждой отметьте метрику, которая хуже всего.
- Найдите главное изображение первого экрана на ключевых шаблонах: сжато ли оно, в каком формате, не стоит ли на нём ленивая загрузка.
- Составьте список сторонних скриптов на сайте и отметьте те, которые можно удалить или загружать отложенно.
- Проверьте, у всех ли изображений и встраиваемых блоков заданы размеры.
- Отметьте в аналитике дату исправлений, чтобы через месяц сравнить конверсию и долю отказов на ускоренных шаблонах.