Скорость: Core Web Vitals и бюджет

Core Web Vitals — три показателя скорости страницы: LCP (показ главного), INP (отклик) и CLS (сдвиги макета). Бюджет задаёт пределы заранее.

Зачем вообще скорость

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

В начале курса мы поставили себе планку: главный контент учебного сайта показывается меньше чем за 2,5 секунды на среднем телефоне в сети 4G. Эта цифра не придумана для курса: так выглядит порог «хорошо» у Core Web Vitals, наборов показателей, которые Google опубликовал для оценки живого опыта страницы, и их используют все: от поисковиков до разработчиков. О поисковых последствиях мы говорили в части про SEO; здесь про то, как это измерить и починить.

Три показателя

Core Web Vitals сегодня это три числа. Каждое отвечает на вопрос человека:

• LCP (Largest Contentful Paint, «самое большое содержимое показано»). Вопрос: я уже вижу главное? Это время, за которое на экране появился самый большой элемент первого экрана: обычно главная картинка или крупный заголовок с абзацем. Хорошо: до 2,5 с; плохо: больше 4 с.
• INP (Interaction to Next Paint, «от действия до следующей отрисовки»). Вопрос: страница меня слышит? Человек нажал, и это время до того, как экран ответил. Берётся самое медленное из значимых действий за визит. Хорошо: до 200 мс; плохо: больше 500 мс. Этот показатель с 2024 года заменил прежний FID.
• CLS (Cumulative Layout Shift, «накопленный сдвиг макета»). Вопрос: страница стоит на месте? Это сумма неожиданных сдвигов: баннер вставился сверху, картинка прогрузилась и распёрла текст. Хорошо: до 0,1; плохо: больше 0,25. У CLS нет единиц: это доля экрана, помноженная на то, насколько она сдвинулась.

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

Проверьте себя: какой показатель отвечает на вопрос «страница стоит на месте?»

CLS, накопленный сдвиг макета. LCP говорит, когда видно главное, INP говорит, как быстро страница отвечает.

Лабораторные и живые данные

Скорость измеряют двумя способами, и числа у них разные.

Лабораторный замер это один прогон в заданных условиях. Так работает Lighthouse (он встроен в инструменты разработчика Chrome и работает в PageSpeed Insights): он имитирует медленный телефон и сеть примерно в 1,6 Мбит/с с задержкой около 150 мс. Плюс: можно воспроизвести и искать причину, меняя по одной вещи. Минус: это один прогон и одна выдуманная сеть.

Живые данные это измерения у настоящих посетителей. У Chrome есть отчёт по реальным пользователям, который показывает PageSpeed Insights для сайтов, у которых достаточно посетителей. Что-то подобное есть и в счётчиках посещений: в них бывают отчёты о времени загрузки страниц у реальных посетителей. Плюс: это правда о людях. Минус: данные появляются через недели, и они не говорят, из-за чего плохо.

Рабочая связка: найти проблему по живым данным, найти причину в лаборатории, исправить и подтвердить живыми данными через время. А для маленького сайта без трафика лаборатории достаточно: исправлять нужное, не мучаясь вопросом, как у людей.

Главный элемент (LCP): что это и как ускорить

Откройте в PageSpeed Insights любую страницу и найдите в отчёте строку «Largest Contentful Paint element»: она назовёт тот самый элемент. Чаще это картинка в первом экране. У времени LCP четыре части: ответ сервера, задержка начала загрузки главного ресурса, сама загрузка и задержка показа. Лечат каждую:

1. Ответ сервера: CDN, кэш, быстрый хостинг (мы разбирали в части про инфраструктуру).
2. Задержка начала: не прятать главную картинку за скриптом или стилем; не ставить на неё loading="lazy"; дать браузеру намёк fetchpriority="high", что именно её качать первой.
3. Загрузка: сжать картинку, использовать современные форматы (WebP, AVIF), отдавать подходящий размер через srcset и sizes: зачем телефону картинка шириной 3000 точек.
4. Показ: не блокировать отрисовку лишними стилями и скриптами в head, defer для скриптов, шрифты со font-display: swap, чтобы текст появлялся сразу запасным шрифтом.

Правило из урока о картинках остаётся в силе: lazy только для картинок ниже первого экрана, тогда они не отнимают сеть у главного.

Проверьте себя: почему loading="lazy" вреден для главной картинки?

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

Прыжки макета (CLS)

Откуда берутся прыжки, вы знаете из урока об отрисовке: браузер не знал, сколько места занимает то, что ещё грузится. Лечение: сказать заранее.

• Размеры картинок. Атрибуты width и height в разметке: браузер резервирует место по соотношению сторон, даже когда картинка ещё не пришла. Можно и aspect-ratio в CSS.
• Место под вставки: баннер cookie, чат, реклама, видео. Дайте контейнеру высоту, а не вставляйте содержимое над уже показанным.
• Шрифты: пока загружается шрифт, браузер показывает запасной, а потом подменяет, и строки могут перераспределиться. Помогает свой шрифт, подобранный запасной шрифт и подмножество нужных знаков.
• Анимации с transform и opacity, а не с изменением top, width и height.

Отклик (INP)

Страница отвечает на нажатие, когда главный поток браузера свободен. Если в этот момент он занят тяжёлым скриптом, нажатие ждёт. Типичные виновники: сторонние виджеты: чаты, счётчики, ленты соцсетей, карты, которые тянут сотни килобайт кода. Что можно сделать:

• убрать то, чем не пользуются, и не подключать «на всякий случай»;
• загружать чат и карты после первого касания или по кнопке, а не вместе со страницей;
• подключать скрипты с defer, разбивать длинные задачи и держать обработчики событий короткими;
• помнить о прогрессивном улучшении (часть про JavaScript): страница, которая работает без скрипта, ещё и не зависит от того, успел ли он загрузиться.

Бюджет производительности

Скорость портится постепенно: добавили счётчик, потом чат, потом красивый слайдер, и каждый шаг «почти не заметен». Бюджет производительности это предел, назначенный заранее, который не обсуждается в момент соблазна: «страница не тяжелее 500 КБ, запросов не больше 15, главное видно за 2,5 секунды на медленной сети». Тогда новая вещь не просто «добавляется», а должна вытеснить что-то или обосновать, почему бюджет нужно поднять.

Как назначить число. Если считать грубо, то на медленной сети около 200 КБ в секунду; значит, всё, без чего главное не показывается (HTML, стили, главная картинка), должно уложиться примерно в 200 или 300 КБ, чтобы показать его за пару секунд. Бюджет всей страницы больше, потому что остальное грузится уже после первого экрана. Цифры вашего бюджета зависят от аудитории: для сайта в метро и по мобильной сети строже, для внутреннего сервиса на офисной сети мягче.

Бюджет это ещё и проверка. Lighthouse CI запускает замер при каждой выкладке и падает, если страница вышла за предел; именно так проверяется и этот учебник (в начале курса мы назвали предел: первый маршрут меньше 150 КБ JavaScript в сжатом виде). Для маленького проекта достаточно записать число и раз в месяц открывать PageSpeed Insights.

Поиграйте со схемой: включайте исправления и смотрите, какое из них что двигает. Обратите внимание, что чужой чат самое тяжёлое на странице: даже отложенный, он весит 250 КБ, и вес всей страницы без работы с ним не снизить.

Это модель одной посадочной страницы на медленном мобильном интернете (200 КБ/с). Включайте исправления по одному и смотрите, какое сдвигает какой показатель. Числа учебные: настоящие дают Lighthouse и реальные посещения.

• Сжать главную картинку и выдать мобильный размер (srcset, WebP/AVIF)
  Было 900 КБ, станет около 110 КБ.
• Не откладывать главную картинку: убрать loading="lazy", добавить fetchpriority="high"
  Браузер начинает качать её сразу, а не после раскладки.
• Задать width и height всем картинкам и место под блоки
  Браузер резервирует место, текст не прыгает.
• Подключить скрипт с defer
  Скрипт не блокирует показ страницы.
• Убрать из скрипта лишнее (было 300 КБ, станет 90 КБ)
  Меньше кода выполнять, быстрее отклик.
• Загружать чат-виджет после первого касания, а не вместе со страницей
  Сторонний код не мешает первому экрану и отклику.
• Шрифт: font-display: swap и только нужные начертания и письменности
  Текст виден сразу, шрифт подгружается позже.

LCP: когда виден главный элемент 8,1 с ✕ плохо хорошо до 2,5 с, плохо после 4 с

INP: как быстро страница отвечает 510 мс ✕ плохо хорошо до 200 мс, плохо после 500 мс

CLS: насколько прыгает макет 0,34 ✕ плохо хорошо до 0,1, плохо после 0,25

HTML 20 КБ

CSS 40 КБ

Главная картинка 900 КБ

Шрифт 55 КБ

Скрипт сайта 300 КБ

Чат-виджет (чужой) (после первого экрана) 250 КБ

Счётчик (после первого экрана) 60 КБ

Остальные картинки (после первого экрана) 120 КБ

Бюджет по весу, КБ Бюджет по запросам

Вес страницы 1745 КБ при бюджете 800 КБ: выше на 945 КБ. Запросов 10 при бюджете 15: в рамках. Включено исправлений: 0 из 7.

Текстовая альтернатива: без исправлений страница грузит около 900 КБ главной картинки с отложенной загрузкой, большой скрипт и чужой чат вместе с первым экраном: LCP около 8 с, INP около 500 мс, CLS около 0,3. Сжатая картинка с высоким приоритетом, размеры картинок, defer, лёгкий скрипт, чат после касания и шрифт со swap приводят все три показателя в зелёную зону.

Практика

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

Проверка читает разметку и текст. Настоящее время загрузки она показать не может, поэтому вернитесь к странице после урока: откройте её на телефоне и в PageSpeed Insights и сравните с бюджетом.

Если вы собираете сайт в конструкторе (Tilda, WordPress с темой), у вас нет доступа к разметке, но есть настройки: включите сжатие и современные форматы картинок, отложенную загрузку для картинок ниже первого экрана и минимум плагинов и виджетов.

Что было не так раньше

В 2010-х «быстрый сайт» значило сайт без тяжёлого Flash. Скорость мерили секундомером и ощущением, а гигантские фоновые картинки и десяток подключаемых библиотек считались нормой, потому что у разработчика был быстрый ноутбук и проводной интернет. Сейчас большинство людей приходит с телефона, и Core Web Vitals дали общий язык: три числа, три порога, один инструмент. Они ещё меняются: INP заменил FID в 2024 году, и пороги тоже бывают пересмотрены. Проверяйте актуальные значения на web.dev.