Вы нажимаете кнопку «Добавить в корзину», а сайт замирает на полсекунды и только потом реагирует. Открываете меню, и оно дёргается. Печатаете в поле поиска, а буквы появляются с заметным опозданием. Всё это интерфейс, который тормозит, и у этой задержки теперь есть точное имя и точная цифра.
Метрику зовут INP (Interaction to Next Paint, дословно «от взаимодействия до следующей отрисовки»). Она измеряет, сколько времени проходит от вашего клика, тапа или нажатия клавиши до момента, когда экран отзовётся хоть каким-то видимым изменением. В марте 2024 года Google сделал INP официальной метрикой Core Web Vitals и заменил ею старую FID. С тех пор медленный отклик напрямую бьёт по позициям в поиске.
В этой статье разберём INP по-человечески: что он измеряет, чем отличается от FID, какое значение считается нормой, из чего складывается задержка и, главное, как её сократить. Будет таблица «причина лагов → решение» и отдельный блок для тех, у кого сайт на WordPress или конструкторе.
INP — одна из метрик отзывчивости в наборе Core Web Vitals, и заменила она именно FID. Что такое сами Core Web Vitals, как их измерять и как устроены остальные метрики, мы подробно разобрали в большом материале «Как ускорить сайт и улучшить Core Web Vitals». Если вы только знакомитесь с темой скорости, начните с него. Здесь же фокус только на INP.
Статья пригодится владельцам сайтов, фронтенд-разработчикам, SEO-специалистам и всем, кто видит в отчёте PageSpeed красный INP и не понимает, что с ним делать. Глубоко лезть в код не придётся: большую часть проблем закрывают понятные действия.
А если хочется освоить фронтенд системно и научиться чинить такие вещи руками, у нас есть подборка курсов по фронтенд-разработке, от коротких интенсивов до годовых программ. Технический аудит, в который входит и проверка скорости, мы отдельно расписали в инструкции «Как провести технический аудит сайта».
КурсыСравнение 84 курсов по frontend-разработкеЦены, школы, длительность, рассрочка
INP простыми словами: что он измеряет
Представьте, что сайт — это собеседник. Вы задали вопрос (кликнули), и важно, как быстро он хотя бы кивнёт в ответ. INP измеряет именно эту скорость кивка: сколько миллисекунд проходит между вашим действием и первым видимым откликом страницы.
Под взаимодействием тут понимают три вещи: клик мышью, тап по экрану на телефоне и нажатие клавиши. Прокрутка и наведение курсора не считаются: браузер обрабатывает их иначе, и в INP они не попадают.
Ключевое слово — «видимый отклик». Сайту не обязательно сразу показать конечный результат. Достаточно любой реакции: кнопка нажалась, появился спиннер загрузки, поле подсветилось, выпало меню. Если же между кликом и хоть каким-то изменением на экране проходит полсекунды и больше, человек физически чувствует, что сайт «залип».
Главная мысль. INP — это не про то, как быстро грузится страница. Это про то, как живо она отвечает на действия уже после загрузки, пока человек ей пользуется.
И в этом вся суть метрики. Сайт может открыться за секунду и получить отличную оценку за загрузку, но если каждый клик потом отзывается с задержкой, пользоваться им неприятно. INP ловит ровно этот разрыв между «быстро открылся» и «приятно работает».
INP против FID: что изменилось в 2026
До марта 2024 года за отзывчивость в Core Web Vitals отвечала метрика FID (First Input Delay, «задержка первого взаимодействия»). Она измеряла только одно: сколько браузер тянул с обработкой самого первого клика или нажатия на странице. И на этом всё.
Проблема FID была в её близорукости. Она смотрела лишь на первое касание и только на его начальную задержку, не учитывая, сколько времени заняла сама обработка и отрисовка ответа. Сайт мог получить идеальный FID, а потом тормозить на каждом следующем действии, и метрика этого просто не видела.
INP исправляет обе слабости разом. Во-первых, она наблюдает за всеми взаимодействиями за визит, а не за первым. Во-вторых, считает полное время: от задержки до начала обработки, через саму обработку, до отрисовки следующего кадра. Итоговое значение — это самое медленное взаимодействие за сессию (с поправкой на единичные выбросы).
| Параметр | FID (устарела) | INP (с марта 2024) |
|---|---|---|
| Что измеряет | Задержку только первого клика | Все клики, тапы, нажатия за визит |
| Что входит в замер | Только начальная задержка ввода | Задержка + обработка + отрисовка |
| Насколько отражает реальность | Поверхностно, по одному касанию | Полно, по всей сессии |
| Хороший показатель | До 100 мс | До 200 мс |
На практике это значит одно: обмануть INP сложнее. Раньше можно было оптимизировать первый клик и закрыть метрику. Теперь придётся следить за отзывчивостью всего интерфейса, потому что в зачёт идёт худший момент за всё время на странице.
Какой INP считается хорошим
Google делит значения на три зоны, и пороги стоит запомнить, потому что именно по ним PageSpeed красит метрику в зелёный, жёлтый или красный.
- До 200 мс — хорошо. Интерфейс отзывается так быстро, что человек не замечает задержки.
- От 201 до 500 мс — нужно улучшить. Задержка уже ощущается, особенно на слабых телефонах.
- Больше 500 мс — плохо. Сайт явно «думает» перед ответом, и это раздражает.
Есть важный нюанс, из-за которого многие путаются в отчётах. INP в Search Console и PageSpeed считается по реальным пользователям и берётся как 75-й перцентиль. Простыми словами: метрика смотрит на скорость у 75% ваших посетителей и отсекает четверть самых быстрых. Так Google гарантирует, что хорошую оценку получают сайты, отзывчивые для большинства, а не только для владельца с мощным ноутбуком.
Частый вопрос. Почему на моём компьютере всё летает, а PageSpeed показывает плохой INP? Потому что метрика усредняет реальных людей, включая тех, кто сидит со старого телефона на медленном интернете. Проверять отзывчивость надо именно с прицелом на них.
Из чего складывается задержка отклика
Чтобы чинить INP осмысленно, надо понимать, что задержка — это цепочка из трёх этапов. Браузер проходит их по порядку каждый раз, когда вы что-то нажимаете.
Этап 1 — задержка ввода (input delay). Это время от вашего клика до момента, когда браузер вообще начинает его обрабатывать. Часто браузер в эту секунду занят чем-то другим: дочитывает скрипт, считает аналитику, перерисовывает баннер. Пока он не освободится, ваш клик ждёт в очереди.
Этап 2 — обработка (processing duration). Это время, за которое отрабатывает код-реакция на ваше действие. Например, вы нажали «Купить», и скрипт пересчитывает корзину, шлёт запрос на сервер, обновляет цифры. Чем тяжелее этот код, тем дольше этап.
Этап 3 — задержка отрисовки (presentation delay). Это время, за которое браузер наконец рисует новый кадр с результатом. Если страница перегружена элементами или код заставляет её пересчитывать раскладку, отрисовка тоже затягивается.
Почти всегда тормозит цепочка целиком из-за одной причины: перегруженного основного потока. Основной поток (main thread) — это единственная «дорожка», по которой браузер выполняет JavaScript, считает стили и рисует страницу. JavaScript (язык, на котором написана вся интерактивность сайта) и отрисовка делят одну дорожку, и пока по ней едет тяжёлый скрипт, ваш клик стоит на обочине.
Почему интерфейс тормозит: главные причины
Источник плохого INP почти всегда один: слишком много работы на основном потоке в неподходящий момент. Но проявляется это по-разному. Вот частые виновники.
Тяжёлый JavaScript и длинные задачи. Длинная задача (long task) — это любой кусок кода, который занимает основной поток дольше 50 мс без перерыва. Пока он работает, браузер не может отреагировать ни на один клик. Один такой кусок на 300 мс уже даёт провал по INP.
Сторонние скрипты. Чаты поддержки, виджеты соцсетей, системы аналитики, рекламные блоки. Всё это чужой код, который грузится на вашу страницу и претендует на тот же основной поток. Часто именно сторонние скрипты, а не ваш собственный код, съедают отзывчивость.
Гидрация на сайтах с фреймворками. Гидрация (hydration) — это процесс, когда сайт на React, Vue или подобном фреймворке «оживляет» уже отрисованную страницу: навешивает на кнопки обработчики, подключает логику. Пока гидрация не закончилась, кнопки выглядят рабочими, но на клики не реагируют. Это классическая ловушка плохого INP в первые секунды.
Большой и сложный DOM. DOM — это дерево всех элементов страницы, с которым работает браузер. Если на странице десятки тысяч элементов, каждый пересчёт раскладки становится дорогим, и отрисовка ответа на клик затягивается.
Совет от практиков. Прежде чем оптимизировать свой код, откройте список сторонних скриптов. На реальных сайтах чаще всего именно чужие виджеты и рекламные сетки виноваты в лагах, а не строки, которые написали вы.
Как поймать медленные взаимодействия
Чинить вслепую бесполезно. Сначала надо найти, какое именно действие тормозит. Есть два типа данных, и важно их не путать.
Полевые данные (поле) — это INP реальных посетителей, который собирает Chrome и показывает в Search Console и PageSpeed Insights. Это правда о том, как сайт ведёт себя у живых людей. Минус в том, что данные обобщённые, конкретную кнопку-виновника они не назовут.
Лабораторные данные (лаборатория) — это замер в искусственных условиях у вас на компьютере через инструменты разработчика. Тут можно поймать конкретное медленное взаимодействие, но цифры будут зависеть от вашего железа.
Связка простая: полем находите факт проблемы, лабораторией ищете её причину. Вот рабочие инструменты:
- Web Vitals extension — бесплатное расширение Chrome от Google. Показывает INP прямо во время того, как вы кликаете по своему сайту, и подсвечивает самое медленное взаимодействие.
- Панель Performance в DevTools. DevTools (инструменты разработчика, открываются клавишей F12) умеют записать сессию и разложить её по этапам. Красные треугольники на дорожке основного потока — это и есть длинные задачи, которые блокируют отклик.
- PageSpeed Insights. Берёт полевые данные из отчёта реальных пользователей Chrome (CrUX) и сразу подсказывает, в зелёной зоне ваш INP или нет.
Отдельно стоит знать про TBT (Total Blocking Time, «общее время блокировки»). Это лабораторная метрика: она суммирует, сколько в общей сложности основной поток был занят длинными задачами при загрузке. Сам по себе TBT не равен INP, но сильно с ним связан. Если у вас высокий TBT в Lighthouse, почти наверняка будет страдать и INP. Поэтому TBT удобен как ранний сигнал: его можно мерить в лаборатории, где поймать живой INP сложнее.
Таблица «причина лагов → решение»
Чтобы не держать всё в голове, собрали главные причины плохого INP и то, что с каждой делать. Это карта для тех, кто уже нашёл проблему и хочет понять направление.
| Причина задержки | Что происходит | Решение |
|---|---|---|
| Длинные задачи в JS | Код занимает поток дольше 50 мс, клик ждёт | Разбить задачу на части, отдавать поток браузеру |
| Тяжёлые обработчики событий | На клик навешено слишком много работы сразу | Откладывать неважное, реагировать сначала видимым откликом |
| Сторонние скрипты | Чаты, аналитика, реклама грузят поток | Отложить загрузку, убрать лишнее, ставить асинхронно |
| Частые события (ввод, скролл-логика) | Код срабатывает на каждый чих | Применить debounce или throttle |
| Тяжёлые вычисления | Сложная обработка данных в браузере | Вынести в Web Worker (отдельный поток) |
| Большой DOM | Десятки тысяч элементов, дорогая отрисовка | Упростить разметку, скрывать невидимое через content-visibility |
| Долгая гидрация | Кнопки не реагируют, пока фреймворк не «ожил» | Уменьшить объём JS, грузить интерактивность частями |
Как улучшить INP: конкретные приёмы
Теперь к делу: что сокращает задержку. Идём от самого эффективного к точечному.
Разбивайте длинные задачи и отдавайте поток браузеру. Главный приём. Вместо одного куска кода на 300 мс разбейте его на несколько коротких и в паузах возвращайте управление браузеру, чтобы он успел отреагировать на клик. В коде это делают через setTimeout или современный scheduler.yield(). Идея простая: пусть браузер сначала покажет человеку отклик, а тяжёлую обработку доделает следом.
Сначала покажите реакцию, потом считайте. Если на клик навешена долгая работа, разделите её. На само нажатие дайте мгновенный видимый отклик (подсветка, спиннер), а пересчёты и запросы запустите уже после отрисовки. Человеку важно увидеть, что его действие принято, а не ждать конечного результата без всякой реакции на экране.
Притормаживайте частые события. Когда код срабатывает на каждое нажатие клавиши или движение, поток захлёбывается. Тут помогают два приёма: debounce (запустить код один раз после того, как человек закончил, например, печатать) и throttle (ограничить частоту срабатываний, скажем, не чаще раза в 200 мс).
Выносите тяжёлые вычисления в Web Worker. Web Worker — это отдельная фоновая дорожка, на которой код считается параллельно и не трогает основной поток. Если у вас сложная обработка данных, фильтры, расчёты, перенесите их туда, и интерфейс перестанет замирать на время вычислений.
Разберитесь со сторонними скриптами. Пройдитесь по списку чужого кода на странице. Что-то можно убрать совсем, что-то перевести на асинхронную загрузку или поставить с задержкой, чтобы оно не лезло на поток в первые секунды, когда человек активно кликает.
Уменьшайте лишний JavaScript и DOM. Чем меньше кода браузер выполняет и чем проще дерево элементов, тем больше у него свободного потока на отклик. Свойство content-visibility позволяет не отрисовывать то, что сейчас за пределами экрана, и заметно облегчает работу с длинными страницами.
Эти приёмы лежат на стороне фронтенда, и часть из них пересекается с оптимизацией других метрик. Если параллельно у вас красные LCP или CLS, имеет смысл чинить их вместе, потому что корни часто общие. А если медленно отвечает сам сервер, начните с времени до первого байта (TTFB), потому что задержка ввода частично растёт именно оттуда.
INP на WordPress и конструкторах
Хорошая новость для тех, кто не пишет код: на WordPress, Тильде и подобных платформах большую часть проблем с INP создают навешанные плагины и виджеты, а сам сайт обычно собран нормально. А значит, и чинятся такие лаги без программирования.
КурсыСравнение 21 курса по WordPressЦены, школы, длительность, рассрочка
Что проверить в первую очередь:
- Ревизия плагинов. Каждый активный плагин тянет свой JavaScript. Отключите то, чем не пользуетесь, и замерьте INP до и после.
- Тяжёлые конструкторы страниц. Визуальные билдеры вроде Elementor генерируют много кода и раздувают DOM. Если страницу можно собрать проще, INP скажет спасибо.
- Чаты, попапы, счётчики. Это те самые сторонние скрипты. В настройках многих из них есть опция отложенной загрузки — включите её.
- Плагины кеширования и оптимизации. Инструменты вроде кеш-плагинов умеют откладывать и объединять JavaScript, снимая нагрузку с основного потока. Это самый доступный рычаг без правки кода.
Полная картина по техническому состоянию сайта, включая скорость и плагины, собирается за один проход. Как это сделать самостоятельно, мы расписали в инструкции по техническому аудиту.
Где научиться оптимизировать фронтенд
Чинить INP, разбивать длинные задачи и работать с основным потоком — это навыки фронтенд-разработчика. Если хочется понять, как устроена производительность браузера на уровне принципов, проще один раз пройти системный курс, чем латать дыры по разрозненным статьям. Мы собрали и сравнили программы по нескольким параметрам, чтобы не пришлось изучать каждую вручную.
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Веб-вёрстка Перейти на сайт курса |  Skillbox | 145 881 ₽ | 2818 ₽/мес. | 3 месяца | Обзор курса |
| Frontend-разработчик с нуля Перейти на сайт курса |  Нетология | 120 700 ₽ | 5385 ₽/мес. | 10 месяцев | Обзор курса |
| Frontend-разработчик Мастер Перейти на сайт курса |  GeekBrains | 264 780 ₽ | 7355 ₽/мес. | 24 месяца | Обзор курса |
| Профессия «Frontend-разработчик с нуля до PRO» Перейти на сайт курса | Skillbox | 137 500 ₽ | 4911 ₽/мес. | 10 месяцев | Обзор курса |
| Профессия: Frontend-разработчик Перейти на сайт курса |  ProductStar | 89 088 ₽ | 36 ₽/мес. | 8 месяцев | Обзор курса |
| Онлайн-курс Frontend-разработчик Перейти на сайт курса |  Бруноям | 63 900 ₽ | 5325 ₽/мес. | 8 месяцев | Обзор курса |
| Факультет frontend-разработки Перейти на сайт курса | GeekBrains | 179 600 ₽ | 4989 ₽/мес. | 12 месяцев | Обзор курса |
| Фронтенд-разработчик Перейти на сайт курса |  Синергия | 97 356 ₽ | 4057 ₽/мес. | 6 месяцев | Обзор курса |
| Мидл фронтенд-разработчик Перейти на сайт курса |  Практикум | 116 000 ₽ | 18 500 ₽/мес. | 5 месяцев | Обзор курса |
| Интенсив: фронтенд-разработка с ИИ Перейти на сайт курса |  Компьютерная академия TOP | Бесплатно | 4560 ₽/мес. | 3 месяца | Обзор курса |
Больше программ — в полном каталоге курсов по Frontend-разработке
После курса техники из этой статьи перестанут быть набором незнакомых слов и станут рабочими инструментами. А пока начните с диагностики через Web Vitals extension и PageSpeed, найдите самое медленное взаимодействие и примените к нему первый приём из таблицы. Один разбитый длинный скрипт часто вытаскивает INP из красной зоны.
![Обложка: Как уменьшить TTFB (время до первого байта) в [current year]](https://selcdn.checkroi.ru/wp-content/uploads/og-images/og-cover-77892-1781094414.webp "Статья: Как уменьшить TTFB (время до первого байта) в 2026")
![Обложка: Как ускорить сайт и улучшить Core Web Vitals в [current year]](https://selcdn.checkroi.ru/wp-content/uploads/og-images/og-cover-77863-1781090788.webp "Статья: Как ускорить сайт и улучшить Core Web Vitals в 2026")
