FID против INP: что важно для SEO

Коротко: С 12 марта 2024 года метрика FID официально заменена на INP в составе Core Web Vitals. В отличие от FID, который фиксировал только первую реакцию пользователя, INP оценивает отзывчивость всей страницы, учитывая время отклика на все взаимодействия (клики, тапы, нажатия клавиш) за весь визит. Для SEO критически важно оптимизировать именно INP, так как Google использует её для оценки пользовательского опыта и ранжирования.

Кстати, в AmSales мы делаем разработку сайтов под ключ и ИИ-интеграцию и анализ звонков под ключ. Если нужна помощь - напишите нам.

Почему FID больше не актуален для SEO

Если вы до сих пор заходите в Search Console в надежде увидеть там показатели First Input Delay (FID), вы обнаружите пустоту. С 12 марта 2024 года Google официально исключил FID из набора метрик Core Web Vitals. Это не просто косметическое изменение или переименование. Это фундаментальный сдвиг в том, как поисковая система понимает, насколько "живым" и отзывчивым кажется ваш сайт человеку.

Проблема FID заключалась в его ограниченности. Эта метрика измеряла только задержку первого взаимодействия пользователя с сайтом. Например, если пользователь зашел на страницу, прокрутил её, прочитал статью, а потом решил кликнуть на кнопку "Купить" и столкнулся с тормозами - FID это бы не зафиксировал. Для системы всё выглядело бы идеально, ведь первое взаимодействие (возможно, просто клик по меню) прошло быстро. Но реальный пользователь почувствовал раздражение, потому что сайт "затупил" в самый ответственный момент.

Такой подход создавал огромную слепую зону для разработчиков и SEO-специалистов. Можно было иметь отличные показатели FID, но при этом иметь абсолютно "неповоротливый" интерфейс, который бесил людей при попытке совершить целевое действие. Google понял, что FID не дает полной картины пользовательского опыта, и принял решение внедрить более комплексный инструмент.

Сегодня FID считается исторической метрикой. Ориентироваться на неё в 2026 году - значит тратить бюджет на оптимизацию того, что больше не влияет на позиции. Если ваши отчеты в Google Search Console показывают проблемы с отзывчивостью, это не "старый добрый FID", это новый стандарт, требующий иного подхода к диагностике.

Что такое INP и как она работает

INP, или Interaction to Next Paint, - это метрика, которая пришла на смену FID и стала полноценным индикатором качества взаимодействия. Если FID смотрел на "входную дверь" сайта, то INP следит за всем процессом пребывания пользователя внутри. Она измеряет время от момента действия (клик, тап или нажатие клавиши) до момента, когда браузер отрисовывает следующий визуальный кадр, подтверждающий, что действие принято.

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

Важно понимать, что INP учитывает не только время выполнения кода, но и время отрисовки (paint). Это критично для современных Single Page Applications (SPA) и тяжелых интерфейсов. Пользователь видит результат не тогда, когда JavaScript закончил вычисления, а когда на экране реально изменилось состояние (появилось лоадер-сообщение, открылось модальное окно или изменился цвет кнопки). Именно этот переход к визуальному подтверждению и делает INP такой мощной метрикой.

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

Разница в механике замера

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

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

Главное отличие FID от INP заключается в охвате событий. FID был крайне узким инструментом. Он замерял только задержку до первого взаимодействия. Это создавало иллюзию высокой производительности там, где её не было. INP же работает по принципу "худшего сценария" (worst-case scenario) в рамках всего визита. Это делает метрику более репрезентативной для оценки реального пользовательского опыта.

Второе различие - это тип измеряемого события. FID фокусировался на задержке в основном потоке (main thread delay). INP же включает в себя полный цикл: от ввода пользователя до визуального обновления кадра. Это значит, что INP учитывает работу браузера по пересчету стилей, компоновке (layout) и собственно отрисовке (paint). Это более комплексный показатель, который объединяет в себе и производительность кода, и эффективность рендеринга.

Третье отличие касается влияния на бизнес-показатели. FID часто не коррелировал с показателями конверсии, потому что пользователи могли совершать целевые действия (например, заполнение формы или добавление в корзину) спустя несколько секунд после загрузки страницы. FID считал это "прошедшим этапом". INP же бьет точно в цель: если кнопка "Оплатить" тормозит, INP это зафиксирует, и вы увидите прямую связь между плохой метрикой и падением продаж.

Пороги значений INP для оценки сайта

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

Первая категория - "Good" (Хорошо). Здесь порог составляет 200 мс или меньше. Если среднее значение худшего взаимодействия на вашем сайте не превышает 200 мс, вы в зеленой зоне. Это означает, что интерфейс ощущается мгновенным, а пользователь не замечает задержек между своими действиями и реакцией сайта. Для коммерческих проектов, где важна скорость принятия решения, это целевой показатель.

Вторая категория - "Needs Improvement" (Требует улучшения). Этот диапазон лежит между 200 мс и 500 мс. Это "желтая зона". Сайт работает, но пользователи могут замечать микро-задержки. Это не критично для выживания бизнеса, но такие показатели могут мешать вам конкурировать в выдаче с более быстрыми игроками. Часто такая ситуация наблюдается на сайтах с тяжелым JavaScript или обилием сторонних виджетов (чаты, счетчики, рекламные скрипты).

Третья категория - "Poor" (Плохо). Все, что превышает 500 мс, отправляет ваш сайт в красную зону. Это критический уровень. Пользователь нажимает на кнопку, и в течение полусекунды ничего не происходит. В современном мире мобильного интернета и быстрых смартфонов это воспринимается как "сайт завис". Такие показатели негативно влияют на поведенческие факторы и могут привести к существенному пессимированию в поисковой выдаче.

Влияние отзывчивости страницы на позиции в поиске

Многие SEO-специалисты ошибочно полагают, что Core Web Vitals - это просто "техническая прихоть" Google. На самом деле, отзывчивость страницы (Responsiveness) напрямую связана с пользовательским опытом (User Experience), а Google стремится показывать пользователям максимально удобные сайты. Влияние INP на ранжирование проявляется через несколько механизмов.

Во-первых, это прямые факторы ранжирования. Google официально подтвердил, что показатели Core Web Vitals являются сигналом качества. Если у двух сайтов одинаковый контент и одинаковая ссылочная масса, но один из них имеет отличный INP, а другой - "плохой", преимущество будет у первого. Это не значит, что быстрый сайт автоматически станет первым, но он получит необходимый "буст" для конкуренции.

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

В-третьих, отзывчивость критична для мобильного поиска. Большинство взаимодействий сегодня происходит на тачскринах. Если при нажатии на меню или фильтр телефон "задумывается", это вызывает раздражение сильнее, чем на десктопе. Поскольку Google использует Mobile-First Indexing, плохой INP на мобильной версии сайта может обрушить позиции всего домена целиком, независимо от того, как быстро работает десктопная версия.

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

Оптимизация INP - это не просто "сжать картинки". Это глубокая работа с тем, как ваш сайт обрабатывает события. Чтобы понять, как улучшить INP для SEO, нужно разбить работу на несколько уровней: от устранения блокирующих скриптов до оптимизации логики выполнения кода. Здесь важен системный подход, а не точечные правки.

Первым делом необходимо разобраться с Main Thread (основным потоком). В JavaScript всё выполняется в одном потоке. Если в этот момент выполняется тяжелая задача (например, расчет сложной скидки в корзине или обработка огромного массива данных), браузер не может обработать клик пользователя. Решение - использование Web Workers для выноса тяжелых вычислений в фоновый поток или разбиение длинных задач на более мелкие части с помощью функции requestIdleCallback.

Второй важный аспект - минимизация работы с DOM. Чем больше элементов на странице и чем сложнее структура дерева, тем дольше браузер выполняет операции Layout и Paint. Если при клике на кнопку вы перерисовываете половину страницы, INP взлетит. Старайтесь обновлять только те части интерфейса, которые действительно изменились. Использование виртуализации списков (Virtual Scrolling) в длинных каталогах - обязательный стандарт для современных e-commerce проектов.

Третий уровень - оптимизация сторонних скриптов. Рекламные пиксели, чаты поддержки, аналитика и виджеты социальных сетей часто являются главными виновниками плохого INP. Они загружаются и начинают выполнять тяжелые задачи в тот момент, когда пользователь пытается взаимодействовать с вашим сайтом. Используйте атрибуты async и defer, откладывайте загрузку второстепенных скриптов до момента полной интерактивности страницы или используйте стратегии частичной загрузки.

1. Проведите аудит через Chrome DevTools (вкладка Performance), чтобы найти "длинные задачи" (Long Tasks), которые блокируют поток более чем на 50 мс.
2. Оптимизируйте обработчики событий: не делайте тяжелых вычислений прямо внутри функции onClick.
3. Сократите количество пересчетов макета (Layout Thrashing), избегая частого чтения и записи свойств элементов (например, offsetHeight и style.width) в одном цикле.
4. Внедрите дебаунсинг (debouncing) и троттлинг (throttling) для событий, которые срабатывают часто, например, при скролле или изменении размера окна.
5. Используйте современные фреймворки с эффективным механизмом обновления DOM, но следите за тем, чтобы они не создавали избыточную нагрузку.

Типичные ошибки при анализе Core Web Vitals

Самая частая ошибка - это попытка оптимизировать INP только на основе лабораторных данных (Lighthouse). Lighthouse дает "синтетический" отчет. Он запускает тест в идеальных условиях, на чистом устройстве и стабильном интернете. Но INP - это метрика, основанная на реальных данных пользователей (CrUX - Chrome User Experience Report). Реальный пользователь может сидеть с дешевым смартфоном через нестабильный 4G, и ваши "идеальные" 150 мс в Lighthouse превратятся в 800 мс в реальности.

Вторая ошибка - игнорирование контекста взаимодействия. Часто разработчики пытаются оптимизировать клик по кнопке, в то время как проблема кроется в обработчике скролла или в том, что при нажатии на кнопку запускается тяжелый скрипт аналитики. Нужно смотреть не на "скорость сайта" вообще, а на конкретные цепочки событий, которые вызывают задержку. Без профилирования в DevTools вы будете стрелять в молоко.

Третья ошибка - фокус на FID, когда проект уже перешел на новые стандарты. Мы до сих пор встречаем в агентствах отчеты, где оптимизация ведется под FID. Это не только бесполезно, но и опасно: вы можете вылизать первый клик до идеала, но полностью провалить общую отзывчивость, и в итоге получить плохой статус Core Web Vitals в Search Console. Всегда проверяйте, что именно вы оптимизируете сегодня.

Наконец, четвертая ошибка - попытка решить проблему INP только через ускорение загрузки (LCP). Быстрая загрузка не гарантирует быструю интерактивность. Сайт может появиться на экране за 1 секунду, но если его JavaScript-бандл весит 5 МБ и занимает 4 секунды на парсинг, пользователь будет смотреть на "замерзшую" страницу. Не путайте скорость отрисовки первого контента со скоростью реакции интерфейса.

Чек-лист по проверке скорости взаимодействия

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

• Проверьте текущий статус INP в Google Search Console (раздел Core Web Vitals). Если там "Poor" или "Needs Improvement" - это ваш приоритет №1.
• Запустите Chrome DevTools -> Performance и запишите сессию, имитирующую реальное использование сайта (клики по меню, фильтрам, кнопкам покупки).
• Найдите в таймлайне "Long Tasks" (красные полоски в области Main). Проверьте, какие именно функции или скрипты их вызывают.
• Проанализируйте сторонние скрипты. Используйте инструменты типа WebPageTest, чтобы увидеть, как сторонние виджеты влияют на доступность основного потока.
• Проверьте мобильную версию. Убедитесь, что задержки не возрастают в разы при симуляции медленного процессора и сети.
• Убедитесь, что все интерактивные элементы имеют визуальный отклик (например, изменение состояния кнопки) немедленно, даже если основная задача выполняется чуть дольше.

Что запомнить:

• FID мертва: с 2024 года в Core Web Vitals правит INP.
• INP оценивает худшее взаимодействие за весь визит, а не только первое.
• Цель для "Good" - менее 200 мс. Все, что выше 500 мс - критический риск для SEO.
• Оптимизация требует работы с Main Thread и минимизации нагрузки на DOM, а не просто сжатия картинок.
• Всегда ориентируйтесь на реальные данные пользователей (CrUX), а не только на лабораторные тесты Lighthouse.