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

INP (Interaction to Next Paint) измеряет, как быстро страница видимо реагирует, когда посетитель кликает, касается экрана или нажимает клавишу. Если от касания до следующего кадра на экране проходит больше 200 мс, сайт кажется медленным, даже если загрузился за две секунды. С 12 марта 2024 года INP входит в три показателя Core Web Vitals и заменил FID. Google оценивает скорость страницы по данным реальных пользователей Chrome за последние 28 дней: результат хороший, если у 75 % посещений LCP не больше 2,5 с, INP не больше 200 мс и CLS не больше 0,1. По данным HTTP Archive Web Almanac 2025, на телефонах хорошего INP нет у 23 % сайтов, а все три показателя проходят только 48 %. Ниже: что чаще всего портит INP на сайтах WordPress и в интернет-магазинах, проверка, которую можно сделать самостоятельно, и пример с фильтром категорий на телефоне.

Что такое INP и почему он заменил FID

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

Границы три: до 200 мс хорошо, 200-500 мс требует улучшения, больше 500 мс плохо. Оценивается 75-й процентиль: если больше чем у четверти посещений реакция медленнее 200 мс, страница проверку не проходит. На телефонах это случается намного чаще, чем на компьютерах. В Web Almanac 2025 хороший INP на десктопе у 97 % сайтов, на мобильных у 77 %.

Из чего состоит одно взаимодействие

Время от касания до следующего кадра делится на три части, и у каждой свои типичные виновники:

• Задержка ввода. Браузер ещё не может начать обработку касания, потому что занят другой работой, например выполняет скрипт аналитики.
• Обработка. Выполняется код самого события, например скрипт фильтра пересчитывает список товаров.
• Задержка отображения. Код закончил работу, но браузеру ещё нужно пересчитать раскладку и отрисовать новый кадр. Чем больше элементов на странице, тем дольше.

Вся эта работа идёт в одном главном потоке (main thread). Задачу дольше 50 мс называют длинной, и пока она выполняется, браузер на касание не реагирует. Поэтому INP чаще всего портят несколько скриптов средней тяжести, которые хотят работать именно тогда, когда человек касается экрана.

Что чаще всего тормозит сайты WordPress и интернет-магазины

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

• Мега-меню. Меню с сотнями ссылок есть в коде каждой страницы, даже если его никто не открывает. При открытии на телефоне браузеру приходится перерисовывать большое дерево элементов, часто ещё и с анимацией.
• Слайдеры. Карусель на главной, которая сама перелистывается каждые несколько секунд, запускает скрипт и перерисовывает страницу как раз тогда, когда человек пытается что-то нажать.
• Окна cookie. Кнопка “Принять” часто одной длинной задачей включает все теги аналитики и рекламы. Почти для каждого посетителя это первое взаимодействие на странице.
• Виджеты чата. Каждый чат загружает свой скрипт, стили и часто iframe. Если на странице их два, например Messenger и отдельный чат поддержки, они борются за один и тот же главный поток.
• Конструкторы страниц. Elementor, WPBakery, Divi и похожие инструменты оборачивают каждую секцию, колонку и виджет в несколько дополнительных элементов, и на странице набираются тысячи элементов. Многие новые сайты к тому же собраны на одном шаблоне с анимацией в каждом блоке, об этом подробнее в статье ИИ-слоп: почему новые сайты выглядят одинаково.
• Теги аналитики и рекламы. Google tag, Meta Pixel, TikTok, Hotjar и ещё пара инструментов через Google Tag Manager. Часть из них слушает каждый клик и выполняет свой код в той же задаче, в которой странице нужно ответить человеку.
• Фильтры категорий. В интернет-магазине это обычно главный источник плохого INP. Когда покупатель отмечает чекбокс, плагин фильтра сразу пересчитывает форму, накрывает сетку товаров слоем и после ответа перерисовывает сотни карточек. Если сама галочка появляется только после этого, человек нажимает ещё раз, и фильтр выключается.

Влияет ли INP на позиции в Google

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

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

Как проверить INP самостоятельно

Нужен Chrome на компьютере и доступ к Google Search Console. Проверяйте важные страницы, а в интернет-магазине прежде всего категории и карточки товаров.

1. Search Console (5 мин). Откройте раздел “Удобство”, затем Core Web Vitals, и выберите мобильные устройства. Если там есть проблема INP больше 200 мс, откройте её. Search Console группирует похожие страницы, и в примерах видно, какие шаблоны (категории, товары, статьи) хуже всего. Данные за последние 28 дней.
2. PageSpeed Insights (5 мин). Введите адрес страницы категории. Верхняя часть отчёта показывает полевые данные реальных пользователей Chrome за 28 дней, и INP есть только там. Нижняя часть отчёта показывает лабораторный тест Lighthouse: в нём INP нет, вместо него Total Blocking Time (TBT). Лабораторная оценка 90 и полевой INP 400 мс у одной страницы встречаются часто, потому что тест страницу только загружает и ничего не нажимает. Если полевых данных нет, у страницы слишком мало посетителей, и остаётся следующий шаг.
3. Chrome DevTools (15 мин). Откройте страницу, нажмите F12 и вкладку Performance. В режиме Live metrics установите CPU throttling на 4x slowdown, чтобы компьютер работал примерно как средний телефон. Затем делайте то, что делает покупатель: откройте меню, нажмите “Принять” в окне cookie, отметьте фильтр, добавьте товар в корзину. В списке Interactions для каждого действия виден INP и его три части. Запишите всё, что больше 200 мс.
4. Поиск виновника (15 мин). Нажмите запись, повторите самое медленное действие и остановите запись. На дорожке Main длинные задачи отмечены красным уголком. Кликните по нему и на вкладке Bottom-up посмотрите, код какого файла занял время: темы, плагина или внешнего домена, например googletagmanager.com, connect.facebook.net или сервиса чата.
5. Тест без стороннего скрипта (10 мин). На вкладке Network правой кнопкой по подозрительному запросу выберите Block request domain, перезагрузите страницу и повторите шаг 3. Если INP опускается ниже 200 мс, вы знаете, с чего начать, ещё до правок в теме.
6. Проверка после исправлений. В Search Console запустите проверку исправления для проблемы INP. Она наблюдает за страницами 28 дней, и только потом статус меняется. В DevTools результат виден сразу.

Пример: интернет-магазин стройматериалов в Лиепае

Допустим, у продавца стройматериалов в Лиепае есть магазин на WooCommerce с 4200 товарами. Больше половины посещений идёт с телефона, часто прямо со стройки: мастер ищет саморезы или герметик, открывает категорию и фильтрует по размеру. Лабораторный тест PageSpeed Insights даёт главной странице на телефоне 86 баллов, LCP 2,1 с. Но Search Console показывает проблему INP на 380 страницах категорий, а полевые данные дают INP 450 мс на 75-м процентиле.

DevTools с замедлением 4x показывает, что касание фильтра “Размер” занимает около 600 мс. Из них 180 мс приходится на задержку ввода, потому что в этот момент работают Tag Manager и два виджета чата, 240 мс на обработку фильтра и 180 мс на отображение, потому что на странице категории 4100 элементов DOM. 1300 из них занимает мега-меню со всеми 26 категориями и подкатегориями, которое загружается на каждой странице.

Исправления заняли около 14 рабочих часов:

• убран один из двух виджетов чата: Messenger остался, отдельный чат поддержки, в котором было три разговора в месяц, отключён;
• теги аналитики и рекламы в Tag Manager загружаются после загрузки страницы, а Hotjar включают только на две недели, когда сайт действительно изучают;
• JavaScript темы и плагинов, который не нужен для первого экрана, загружается с defer, а скрипт слайдера убран со страниц категорий;
• подкатегории мега-меню загружаются только при открытии меню, а из карточек товаров убраны лишние обёртки: DOM сократился с 4100 до 1700 элементов;
• код фильтра разделён: галочка и небольшой индикатор загрузки появляются сразу, затем код отдаёт управление браузеру (scheduler.yield, в Safari через setTimeout), и только потом отправляет запрос и перерисовывает товары.

Результат: в DevTools с тем же замедлением касание фильтра занимает 140 мс. Через 28 дней полевые данные показывают INP 170 мс, и Search Console относит страницы категорий к хорошим. Лабораторная оценка главной изменилась мало, с 86 до 91, потому что загрузка и так была быстрой. В аналитике число мобильных сессий, в которых используют фильтр, выросло на 18 %, потому что людям больше не нужно нажимать дважды.

Что исправлять в первую очередь

В таком порядке обычно получается больше всего результата при наименьшей работе:

1. Уберите то, чем никто не пользуется. Второй виджет чата, старый Pixel, Hotjar, который записывал год назад, слайдер, который никто не листает. Каждый убранный скрипт сразу уменьшает задержку ввода для всех взаимодействий.
2. Отложите остальное. Тегам аналитики и рекламы не нужно загружаться раньше контента страницы. Скриптам, которые не нужны для первого экрана, поставьте defer или загружайте их после первого взаимодействия.
3. Показывайте реакцию сразу. Код события сначала показывает визуальный ответ: отмеченный чекбокс, открытое меню, кнопку в состоянии загрузки. Тяжёлая работа идёт после этого.
4. Разбейте длинные задачи. Между шагами отдавайте управление браузеру через scheduler.yield(). Chrome и Edge поддерживают его с версии 129, Firefox с версии 142, Safari пока нет, поэтому нужен запасной вариант с setTimeout.
5. Уменьшите DOM. Содержимое мега-меню загружайте при открытии, для дальних секций длинных страниц используйте CSS content-visibility, а блоки конструктора на самых посещаемых страницах замените более простым шаблоном.

По нашему опыту, ещё один плагин оптимизации, который добавляет собственный скрипт, улучшает INP редко. Отложенная загрузка скриптов в LiteSpeed Cache или WP Rocket может помочь, но после неё проверьте окно cookie, корзину и фильтры, потому что ломаются чаще всего именно они.

Что сделать на этой неделе

• В Search Console откройте Core Web Vitals для мобильных и запишите группы страниц с проблемой INP.
• В PageSpeed Insights проверьте страницу категории или товара и сравните полевой INP с лабораторным TBT.
• В DevTools с замедлением CPU 4x попробуйте меню, окно cookie, фильтр и корзину.
• Составьте список всех сторонних скриптов (чат, аналитика, рекламные теги) и уберите неиспользуемые.
• Проверьте, показывают ли фильтр и кнопки реакцию сразу после касания.
• После исправлений запустите проверку в Search Console и через 28 дней сравните INP.

Часто задаваемые вопросы

Проверка INP в аудите сайта

В аудите сайта мы проверяем INP для каждого шаблона страниц: главной, категории, товара, корзины и оформления заказа. Сначала смотрим данные реальных пользователей в Search Console, затем в Chrome DevTools с замедлением как на телефоне находим конкретные скрипты и элементы, которые тормозят. За 5 рабочих дней вы получаете отчёт, план действий и смету с часами на каждое исправление. Если сайт можно исправить, мы это и советуем; переделку предлагаем, только когда проблема в самой теме или конструкторе. Подробнее на страницах Редизайн и аудит сайта и Разработка интернет-магазина. Заполните форму и добавьте адрес страницы категории или позвоните +371 25 640 062.

Источники

• web.dev: Interaction to Next Paint (INP)
• web.dev: Interaction to Next Paint becomes a Core Web Vital on March 12 (12.03.2024)
• web.dev: Optimize Interaction to Next Paint
• web.dev: Optimize long tasks
• HTTP Archive Web Almanac 2025: Performance (15.01.2026)
• Google Search Central: Core Web Vitals и результаты поиска Google
• Google Search Central: удобство страниц в результатах поиска Google
• Справка Search Console: отчёт Core Web Vitals
• PageSpeed Insights: полевые и лабораторные данные
• Chrome DevTools: панель Performance