Core Web Vitals и метрика INP: как ускорить сайт и улучшить поведенческие факторы

Разобрали все составляющие Core Web Vitals и способы оптимизировать каждый этап загрузки сайта. В материале есть разбор работы с кодом, макетом, шрифтами, изображениями и примеры, как улучшить скорость сайта под требования Google.

Что такое Core Web Vitals от Google

Поисковик анализирует удобство страницы для пользователей. Для этого у него есть Page Experience — набор требований к сайту для оценки пользовательского опыта и качества страницы. В него входит мобилопригодность, наличие HTTPS, отсутствие навязчивых поп-апов, быстрая загрузка. 

Google не просто измеряет скорость, а отдельно оценивает этапы загрузки. Для измерения он использует набор показателей — Core Web Vitals.

В Google Core Web Vitals в 2026 году входят три основных параметра:

• Время отрисовки контента
  LCP, Largest Contentful Paint — время, за которое браузер отрисовывает самый крупный видимый объект в области просмотра.

• Визуальная стабильность
  CLS, Cumulative Layout Shift — оценка сдвигов макета во время загрузки страницы.

• Отзывчивость или интерактивность
  INP, Interaction to Next Paint — метрика, которая оценивает, насколько быстро страница реагирует на действия пользователя на всем протяжении сессии.

Google рекомендует использовать пороговые значения этих трех параметров для оценки удобства пользователей. Если страницы получают оценки выше пороговых значений LCP, INP и CLS, то они проходят оценку Core Web Vitals.

Можно ли считать Core Web Vitals фактором ранжирования? Скорее это сигнал для поисковой системы, но вряд ли сайт упадет в выдаче из-за проблем с каким-то из показателей. Например, на Reddit пользователь спросил, может ли снижение органического трафика быть связано с плохим CLS. Джон Мюллер ответил, что нет.

При этом в 2025 году Google усилил роль производительности в поисковом алгоритме: по данным открытых исследований, сайты, которые стабильно не проходят Core Web Vitals, проигрывают сайтам с быстрыми и устойчивыми страницами по органическому трафику.

FAQ по Core Web Vitals

Нужно ли доводить все Core Web Vitals до идеальных значений?
Важно, чтобы большинство сессий попадали в зеленую зону по LCP, INP и CLS. Максимальные оценки не обязательны, но безопасный запас по метрикам помогает переживать апдейты алгоритмов спокойнее.

Сколько времени занимает улучшение Core Web Vitals?
Простые правки вроде включения кеширования, настройки CDN и минификации можно реализовать за несколько дней, глубокая переработка фронтенда и шаблонов занимает недели.

Как часто пересматривать показатели Core Web Vitals?
Минимум раз в квартал и после любых крупных изменений: редизайна, внедрения новых виджетов, подключения рекламных или аналитических скриптов.

Показатель INP и его роль в ранжировании

INP (Interaction to Next Paint) — взаимодействие со следующей отрисовкой. В марте 2024 года этот показатель окончательно заменил FID, а период перехода завершился осенью 2024 года. Метрика анализирует все задержки, которые происходят от открытия до закрытия страницы, и фиксирует самые долгие взаимодействия.

INP оценивает скорость реагирования с помощью данных из API синхронизации событий. Реагированием считается визуальная обратная связь, то есть когда после определенного действия пользователь увидел какие-либо изменения на странице в браузере. Таким образом он получает отклик на добавление товара в корзину, клик по форме или выбор пункта в меню. Некоторые действия пользователя занимают много времени, поэтому важно показать ему, что сайт не завис, на нем что-то происходит.

Разница между INP и FID в том, что новая метрика измеряет все взаимодействия, тогда как FID учитывает только первое.

Как рассчитывается INP

INP рассчитывается после того, как пользователь покидает страницу, и выбирает взаимодействие с самой большой задержкой. Чем ниже INP, тем лучше.

Взаимодействие — это группа обработчиков событий, которые реагируют на действия пользователя. Какие взаимодействия со страницей учитывает метрика:

• Клик мышью;

• Нажатие на устройство с сенсорным экраном;

• Нажатие клавиши на физической или цифровой клавиатуре, в том числе и прокрутка.

Прокрутка мышью или движение мыши не считаются взаимодействиями.

Взаимодействия состоят из событий. Например, взаимодействие «касание» на устройстве с тачпадом подразумевает три события: pointerup , pointerdown и click. Задержкой будет считаться самая большая продолжительность любого события, которое входит в взаимодействие.

Продолжительность самого события состоит из суммы периодов:

• Задержка ввода — время между первым взаимодействием пользователя со страницей и обработкой события;

• Задержка обработки — общее количество времени на выполнение кода в связанных обработчиках событий;

• Задержка представления — время между завершением выполнения обработчиков событий и моментом представления браузером следующего кадра.

Больше о событиях можно прочитать в справке Google.

Взаимодействие может быть реализовано с помощью JavaScript, CSS, встроенных элементов управления браузера или их комбинации.

INP может меняться в зависимости от интерактивности страницы. Например, если на странице всего менее 50 взаимодействий, INP — это взаимодействие с наибольшей задержкой. Будет учитываться 75-й процентиль всех просмотров страниц, чтобы не учитывать выбросы.

Если страница интерактивная и подразумевает много взаимодействий, есть риск, что в какой-то момент произойдет сбой и она не отреагирует на действия пользователя достаточно быстро. Для таких страниц система будет игнорировать одно самое продолжительное взаимодействие на каждые 50, чтобы оценивать фактическую скорость реагирования, а не исключительные проблемные ситуации.

Какой INP считается хорошим

Порогом для измерения считается 75-й процентиль загрузок страниц, зарегистрированных в полевых условиях, то есть сегментированных по мобильным устройствам и компьютерам. В 2025 году Google ужесточил пороговые значения для Core Web Vitals, в том числе для INP:

• 150 миллисекунд и ниже означает, что у страницы хорошая скорость отклика.

• От 150 до 300 миллисекунд означает, что скорость отклика нужно увеличить.

• Выше 300–350 миллисекунд — страница реагирует медленно, пользователи ощущают задержки.

Почему INP не отображается

Тот факт, что страница загружена, не означает, что пользователь взаимодействовал с ней. Почему это может произойти:

• Пользователь загрузил страницу, но не взаимодействовал с ней.

• Пользователь загрузил страницу, пролистал ее, но ни на что не кликал

• Страницу посетил бот, который не взаимодействовал с ней.

О том, как улучшить INP, читайте в руководстве на web.dev, а также ориентируйтесь на рекомендации PageSpeed Insights и отчетов в Search Console по интерактивности страниц.

FAQ по метрике INP

Чем INP отличается от FID для оценки отзывчивости сайта?
FID учитывал только первое взаимодействие, INP охватывает всю сессию пользователя и фиксирует самые долгие реакции интерфейса, поэтому точнее отражает реальный пользовательский опыт.

Почему в отчетах иногда все еще встречается FID?
Некоторые инструменты сохраняют FID как дополнительный показатель или часть исторических данных, но для Core Web Vitals в 2026 году важен именно INP.

С чего начать, если INP в красной зоне?
Сократите тяжелый JavaScript, уберите блокирующие задачи на основном потоке, оптимизируйте обработчики событий и сторонние скрипты, затем перепроверьте результаты в PageSpeed Insights и DevTools.

Как проверить скорость и этапы загрузки страницы

Есть онлайн-инструменты для проверки. Прогоните сайт через инструмент для проверки скорости от PR-CY: он бесплатно проанализирует загрузку сайта поэтапно, в соответствии с параметрами Google Core Web Vitals. Работает на API Google.

Для каждого пункта есть пояснения и советы, что можно улучшить, с примерным подсчетом экономии скорости при выполнении.

FAQ по проверке скорости сайта

С какого инструмента начать проверку Core Web Vitals и INP?
Можно комбинировать PageSpeed Insights и инструмент проверки скорости от PR-CY, который показывает ключевые показатели LCP, INP и CLS с рекомендациями.

Нужно ли проверять каждую страницу сайта отдельно?
Достаточно начать с типовых шаблонов: главная, листинги, карточки товаров или материалов, лендинги. Остальные страницы с похожей структурой ведут себя схожим образом.

Как часто прогонять сайт через тесты скорости?
После крупных изменений в дизайне и функционале и периодически раз в 1–2 месяца для контроля динамики.

Инструменты от Google для оценки LCP, FID и CLS

Google PageSpeed ​​Insights

Google PageSpeed ​​Insights проводит комплексный анализ производительности страницы, включая показатели Core Web Vitals — первый блок отчета показывает именно их.

Эта оценка входит в отчет о полевых данных. Полевые данные содержатся в отчете об опыте пользователей Chrome — CrUX. Эта информация собирается от реальных пользователей и основана на их взаимодействиях с сайтом. При ранжировании в поиске Google будет использовать именно эти результаты.

Есть два способа получить данные CrUX:

• API отчетов Chrome UX – нужен опыт с JavaScript и JSON.

• BigQuery – понадобится проект Google Cloud и навыки SQL.

Вкладка «Производительность» в Chrome DevTools

Отчет показывает детальную информацию о производительности страницы и диагностировать проблемы.

Как посмотреть отчет:

1. Откройте в Google Chrome сайт, который хотите проверить, и щелкните правой кнопкой мыши в любом месте страницы. Выберите «Проверить» или «Inspect» в меню, чтобы открыть панель Chrome DevTools.

2. На панели DevTools перейдите на вкладку «Производительность» или «Performance».

3. Нажмите кнопку «Запись» в виде кружка, чтобы начать запись профиля производительности страницы;

4. Взаимодействуйте с веб-сайтом, как обычный пользователь — кликайте по элементам страницы, открывайте формы, листайте;

5. Нажмите кнопку «Стоп»;

6. На вкладке «Производительность» будет отображаться подробная временная шкала действий на странице во время сеанса записи.

В результате проверки вы увидите временную шкалу, отображающую ваши действия. Показатели LCP, INP и CLS будут отображены на ней же. Для дополнительной информации каждую метрику можно развернуть.

Отчеты в Google Search Console (GSC)

В разделе «Основные интернет-показатели» есть два отчета по скорости сайта — для компьютеров и для мобильных устройств.

Они покажут количество эффективных и неэффективных страниц. Каждый отчет можно посмотреть подробнее — вы найдете наименование проблемы и список страниц, которые нужно улучшить.

Эти отчеты подходят для поиска типичных проблем на разных URL. Например, если у вас много одинаковых карточек товаров, где самый большой элемент — изображение, метрика LCP будет одинаковой для всех. В этом случае GSC обнаруживает проблемы LCP на всех страницах продуктов.

Если вы улучшили страницы, нажмите «Проверить исправление»:

FAQ по инструментам Google для оценки Core Web Vitals

Чем отличаются лабораторные и полевые данные в отчетах Google?
Лабораторные данные моделируют загрузку страницы в контролируемых условиях, полевые отражают реальные сессии пользователей и именно они участвуют в расчете Core Web Vitals.

Какой отчет важнее для SEO — PageSpeed Insights или GSC?
Отчеты Search Console удобны для мониторинга по всему сайту, а PageSpeed Insights позволяет разбирать конкретные URL и выполнять точечную оптимизацию.

Когда имеет смысл использовать CrUX и BigQuery?
Эти инструменты нужны, если вы строите собственную аналитику по Core Web Vitals и хотите глубже сегментировать аудиторию по странам, устройствам и другим параметрам.

Как оптимизировать показатели Core Web Vitals

Разберем каждый параметр по отдельности.

LCP: как ускорить отрисовку контента

Показатель LCP определяет, когда закончилась загрузка основного содержимого страницы, ее самого крупного элемента. Чем ниже LCP, тем лучше, тем быстрее пользователи смогут изучать контент.

Самым большим элементом могут быть разные части страницы, появляющиеся по мере загрузки. В этом примере таким элементом сначала был заголовок, а потом стала картинка.

Нужно стремиться к тому, чтобы отрисовка самого большого элемента на странице не занимала больше 2,5 секунд от начала загрузки. Это считается оптимальным показателем сайта, на котором удобно работать.

На LCP влияют четыре фактора, их можно оптимизировать:

• ускорить время ответа сервера,

• решить блокировку рендеринга JavaScript и CSS,

• ускорить загрузку ресурсов,

• оптимизировать рендеринг на стороне клиента.

FID и INP: как ускорить время реакции страницы

Исторически показатель FID оценивал, насколько страница задержалась с ответом на первое действие пользователя. Сейчас FID больше не относится к Core Web Vitals, его роль в оценке отзывчивости перешла к INP, но рекомендации по снижению задержек по‑прежнему полезны.

Чем меньше времени тратится на обработку первого и последующих взаимодействий, тем лучше. Для FID ориентировались на показатели до 100 миллисекунд, для INP целевым значением считается до 150 миллисекунд на 75‑м процентиле.

Для ускорения реакций страницы есть несколько решений:

• сократить время выполнения JavaScript,

• разбить длинные задачи на части,

• отложить неиспользуемый JavaScript,

• следить за размером подгружаемых библиотек JavaScript,

• оптимизировать выполнение сторонних скриптов,

• использовать web-workers.

Как выполнить каждый из пунктов, написали в подробной статье про FID.

CLS: как убрать сдвиги макета страницы

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

Сдвиги могут быть нормальными, если они ожидаемы для пользователя и появляются в ответ на его действие. К примеру, если он кликнул на блок в списке и развернулась расшифровка.

CLS измеряет совокупный сдвиг макета из-за неожиданных сдвигов, которые появляются из-за тормозящей загрузки элементов.

Для вычисления нужны два компонента:

• общая область на экране, которую занимает элемент до и после сдвига;

• расстояние, на которое он сдвинулся.

Оптимальный показатель CLS —не больше 0,1 на 75% сессий.

В статье про CLS подробнее разбираем, как это работает и что делать для оптимизации.

Что еще влияет на загрузку страницы: оптимизируем CSS

Стили страницы влияют на скорость отрисовки самого большого видимого элемента и визуальные сдвиги макета.

Например, блокировка рендеринга при обработке CSS тормозит загрузку остальных ресурсов на странице. Чтобы такого не происходило, можно ускорить процесс и разделить CSS на критические и некритические для выполнения.

Для сравнения на верхней строчке загрузка страницы с блокирующими рендеринг CSS, на нижней с разделением CSS:

Кроме критических и некритических CSS можно поработать со стилями изображений, рекламой, скриптами, фреймами и шрифтами.

Все эти возможности разобрали в отдельном материале.

FAQ по оптимизации Core Web Vitals

С какого показателя Core Web Vitals начать оптимизацию?
Чаще всего это LCP, затем INP и CLS. Начните с метрики, которая чаще других показывает плохой статус в отчетах Search Console.

Можно ли улучшить Core Web Vitals только за счет настроек сервера?
Быстрый сервер и CDN помогают, но без работы с фронтендом, JavaScript и версткой сложно добиться стабильно зеленой зоны по всем метрикам.

Как обнаружить проблемы с Core Web Vitals?
Запустите анализ скорости в PR-CY, посмотрите блоки с рекомендациями по LCP, INP и CLS и сначала исправьте пункты с наибольшим потенциалом экономии времени загрузки.

Как уменьшить вес страниц сайта и ускорить загрузку

Как оптимизировать код верхней части страницы

Есть еще способ сделать загрузку быстрее — поработать с кодом верхней части страницы, которую пользователь видит первым делом, как заходит на сайт. Если верхняя часть страницы загружается быстро, пользователь как можно раньше увидит загружающийся контент. А остальное можно подгрузить попозже.

Есть несколько методов:

• удалить лишние символы и скрипты из верхней части кода,

• настроить асинхронную загрузку с jQuery,

• ускорить получение первых байтов (TTFB),

• объединить и сократить JavaScript и CSS,

• настроить загрузку из кэша на стороне пользователя,

• использовать CDN.

О каждом методе с примерами есть в статье.

Как внедрить gzip, brotli, использовать кэширование, минификацию и другие способы сжатия

Картинки, видео и разные интерактивные элементы много весят и тормозят сайт. Можно сжать тяжелые элементы, для это есть алгоритмы, самые популярные сейчас — это gzip и brotli. Brotli сжимает сильнее, чем gzip, у него больше уровней. Но на высоких уровнях его скорость меньше.

Способы ускорить загрузку:

• уменьшить размер HTML,
• использовать сжатие gzip или brotli,
• использовать минификацию, то есть сократить HTML, CSS и JS,
• использовать кэш браузера для ускорения,
• сжать фотографии, иллюстрации и другую графику: подобрать разрешение, уменьшить количество цветов, прописать параметры в CSS и сжать сами файлы.

К примеру, при уменьшении количества цветов качество этой картинки почти не страдает, зато сильно уменьшается вес. Слева направо: 32 бита (16M цветов), 7 бит (128 цветов), 5 бит (32 цвета).

Способы нагружают сервер из-за операций архивирования, но в целом с ними получается быстрее из-за уменьшения размера загружаемых данных.

Все способы разбираем в подробной статье.

FAQ по уменьшению веса страниц

Что сильнее всего влияет на вес страницы и скорость загрузки?
Чаще всего это несжатые изображения, крупные JS‑бандлы, видео и внешние скрипты аналитики или виджетов.

Имеет ли смысл переходить на brotli, если уже включен gzip?
Да, brotli дает лучшее сжатие статических ресурсов, особенно при высоких уровнях, но важно подобрать настройки, чтобы не перегружать сервер.

Как измерить эффект от минификации и сжатия?
Сравните размеры бандлов до и после правок, затем протестируйте ключевые страницы в PageSpeed Insights и в инструменте скорости, чтобы увидеть изменения по LCP и времени загрузки.

Как оптимизировать и сжать картинки

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

Как сжимать картинки и заполнять SEO-атрибуты

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

• количество картинок на странице, размеры, уникальность, тематика;
• правильная оптимизация;
• правильное заполнение SEO-атрибутов изображений.

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

Качество картинок важно, оно должно быть не хуже, чем у конкурентов. Минимум 1080 px по высоте для полного изображения и минимум 640 px в ширину для превью.

Не стоит использовать тег picture для настройки разных форматов картинок для разных устройств. Это увеличит количество узлов в DOM-дереве.

Эти и другие моменты о сжатии картинок, оптимальном формате, размере, содержании, о требованиях к заполнению метатегов и о других важных аспектах есть в большой подробной статье. 

Большая часть советов основана на вебинаре специалиста технического SEO и реверс инжиниринга Деми Мурыча (Demi Murych). Речь не только о сжатии и уменьшении веса, но и о требованиях по размерам, качеству, уникальности и актуальные советы по заполнению метатегов.

Как настроить отложенную загрузку картинок — lazy loading изображений

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

Есть несколько вариантов настройки:

1. Пока пользователь скролит: когда он дойдет до места, где должна быть картинка, она загрузится.
2. Когда пользователь кликнет на элемент: картинка загрузится, если он перейдет по ссылке или щелкнет на превью.
3. В фоновом режиме: контент будет загружаться постепенно, например, когда пользователь открыл документ и оставил его. Обычно применяют для больших чертежей и схем.

Картинки загружаются по мере просмотра:

Выбор варианта зависит от поведения пользователей на сайте.

В статье разбираем, так ли нужна ленивая загрузка, и как ее настроить правильно.

Нужно ли использовать формат изображений WebP

WebP — это формат графических изображений, его разработали в Google в 2010 году. Получилась альтернатива PNG и JPEG, но с меньшим размером при таком же качестве изображения. При этом в WebP можно сохранить прозрачность фона или анимацию.

Формат выгоднее с точки зрения ускорения загрузки сайта, а к 2026 году его поддерживают большинство современных браузеров, поэтому переход на WebP и похожие форматы (например, AVIF) стал стандартным шагом в оптимизации изображений.

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

FAQ по оптимизации изображений

Какой формат изображений выбрать для ускорения сайта?
Для большинства проектов подходят WebP и AVIF, при этом важно тестировать качество и вес на типичных для сайта изображениях.

Нужно ли хранить несколько версий одной картинки?
Да, лучше использовать несколько размеров и форматов через адаптивную разметку, чтобы мобильные устройства не загружали лишние мегабайты.

Как быстро увидеть эффект от оптимизации изображений?
После замены картинок перепроверьте ключевые страницы в PageSpeed Insights и инструменте скорости от PR-CY: вы увидите снижение веса и улучшение LCP.

Как повысить CTR и кликабельность сниппета после ускорения сайта

Скорость и Core Web Vitals помогают удержать пользователей на сайте, но для роста трафика важно, как страница выглядит в выдаче. После технической оптимизации пересмотрите заголовки и описания под ключевые запросы про скорость сайта, Core Web Vitals и INP.

• Добавьте в H1 и подзаголовки релевантные формулировки: «как улучшить Core Web Vitals», «оптимизация INP», «ускорение загрузки сайта для SEO», если они соответствуют содержанию.
• Перепроверьте мета‑описание: покажите, какую задачу читатель решит (например, восстановит трафик после апдейтов Google 2025–2026 годов).
• Используйте структурированные списки и подзаголовки, чтобы поисковые системы могли формировать расширенные сниппеты и быстрые ответы.

Для проектов, которые регулярно дорабатывают скорость и UX, полезно вести историю изменений: фиксировать даты апдейтов, замеры Core Web Vitals и динамику CTR в отчетах Search Console. Так вы поймете, какие правки реально влияют на кликабельность и поведение пользователей.

FAQ по улучшению CTR и видимости статей про скорость сайта

Какие ключевые запросы добавить в текст про Core Web Vitals и INP?
Работают сочетания вроде «как улучшить Core Web Vitals», «оптимизация INP Google», «проверка скорости сайта онлайн», «ускорение загрузки сайта для SEO».

Нужно ли менять заголовок статьи при каждом обновлении?
Достаточно указать в заголовке актуальный год и основную задачу читателя, а дату последнего обновления и новые данные по апдейтам Google отражать в тексте.

Как оценить, повлияли ли изменения заголовков и описаний на CTR?
Сравните CTR по целевым запросам в Search Console за несколько недель до и после правок, учитывая сезонность и другие изменения на сайте.

Этот материал позволит разобраться с оптимизацией страниц, чтобы ускорить загрузку, привести показатели Core Web Vitals и INP в норму и удержать трафик на фоне апдейтов Google. Как вы ускоряете сайт, какие способы используете? Поделитесь в комментариях!