FID (First Input Delay): что это такое и почему метрику заменили на INP

FID, или First Input Delay, — это метрика пользовательского опыта, которая измеряла задержку между первым взаимодействием пользователя со страницей и моментом, когда браузер смог начать обработку этого взаимодействия.

Простыми словами, FID показывал, насколько быстро сайт реагирует на первый клик, тап или нажатие клавиши после загрузки страницы. Если пользователь нажал на кнопку, а браузер в этот момент был занят выполнением тяжёлого JavaScript, реакция задерживалась. Эта задержка и называлась First Input Delay.

Сейчас FID считается устаревшей метрикой. Google заменил её на INP, или Interaction to Next Paint, потому что INP оценивает отзывчивость страницы шире: не только первое взаимодействие, а взаимодействия пользователя на протяжении всей сессии.

Автор экспертного мнения

Владислав Куконин

SEO-специалист, контент-стратег в Digital-агентстве Saygona

Опыт: 13+ лет в SEO и поисковом продвижении

Что такое FID простыми словами

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

Например, страница уже отображается, пользователь нажимает на кнопку «Оставить заявку», но в этот момент браузер выполняет большой JavaScript-файл. Кнопка визуально есть, но обработчик клика начнёт работать только после освобождения основного потока. Задержка между кликом и началом обработки события — это и есть FID.

Расшифровка FID

Слово First означает, что метрика учитывала только первое взаимодействие пользователя со страницей. Input — это ввод или действие: клик, тап, нажатие клавиши. Delay — задержка между действием пользователя и началом обработки этого действия браузером.

Текущий статус FID

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

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

Почему FID был важен

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

• Влиял на UX. Чем выше задержка, тем сильнее ощущение, что сайт «тормозит».
• Помогал находить проблемы JavaScript. Высокий FID часто указывал на перегруженный основной поток.
• Был частью Core Web Vitals. До замены на INP метрика использовалась в наборе основных веб-показателей Google.
• Связывался с SEO-аудитом. Плохая отзывчивость могла ухудшать пользовательский опыт и техническое качество сайта.
• Показывал проблему первого взаимодействия. Особенно на мобильных устройствах и слабых процессорах.

Как считался FID

FID измерял не всё время выполнения действия, а только задержку до начала его обработки. Это принципиально важно: метрика не показывала, сколько времени заняла вся реакция интерфейса, отправка формы или изменение экрана. Она фиксировала только ожидание перед запуском обработчика события.

Упрощённая схема:

1. пользователь открывает страницу;
2. страница начинает загружать HTML, CSS и JavaScript;
3. пользователь впервые взаимодействует со страницей: кликает, тапает или нажимает клавишу;
4. браузер в этот момент может быть занят выполнением другой задачи;
5. действие пользователя ожидает освобождения основного потока;
6. браузер начинает обработку события;
7. разница между действием пользователя и началом обработки события считается FID.

Три фазы взаимодействия. Любое взаимодействие пользователя со страницей можно разложить на три части: Input Delay — задержка до начала обработки события; Processing Time — выполнение обработчиков события; Presentation Delay — время до визуального обновления интерфейса. FID измерял только первую фазу — задержку ввода. INP оценивает взаимодействие шире: от действия пользователя до следующей отрисовки, поэтому лучше показывает реальное ощущение отзывчивости.

Пример FID

Представим, что пользователь зашёл на страницу интернет-магазина и через 1 секунду нажал кнопку «Купить». Но в этот момент браузер ещё выполняет большой JavaScript-файл, который занимает основной поток на 250 мс.

Пользователь нажал кнопку: 1000 мс Браузер начал обработку клика: 1250 мс FID = 1250 мс - 1000 мс = 250 мс

В этом примере FID равен 250 мс. Пользователь мог почувствовать небольшую задержку: он нажал кнопку, но сайт отреагировал не сразу.

Что считалось хорошим FID

Для оценки FID использовались пороговые значения Google. Они помогали понять, насколько быстро страница реагирует на первое взаимодействие.

Для сравнения, у INP другие пороги: до 200 мс — хорошо, от 200 до 500 мс — требует улучшения, более 500 мс — плохо. Пороги INP выше, но это не значит, что требования стали мягче: INP измеряет более полную картину, включая время обработки и отрисовки, а не только задержку ввода.

Значения FID полезны для понимания старых отчётов. Но для актуального аудита отзывчивости сейчас нужно ориентироваться на INP.

Какие действия учитывал FID

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

• клик по кнопке;
• клик по ссылке;
• тап по интерактивному элементу на смартфоне;
• нажатие клавиши;
• взаимодействие с полем формы;
• использование JavaScript-компонента, например выпадающего меню.

Что FID не измерял

У FID были ограничения. Именно из-за них метрику заменили на INP. FID не показывал полную картину отзывчивости страницы.

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

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

Почему FID заменили на INP

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

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

FID и INP: в чём разница

Пример: почему FID может быть хорошим, а INP плохим. Пользователь заходит на сайт интернет-магазина. Первый клик по баннеру происходит через 2 секунды после загрузки, когда основной поток свободен. FID равен 20 мс — это отличный результат. Затем пользователь открывает фильтр товаров, но в этот момент выполняется тяжёлый скрипт аналитики, и задержка до визуального результата составляет 400 мс. Потом пользователь добавляет товар в корзину, а в этот момент загружается виджет чата, и задержка составляет 350 мс. По итогам такой сессии INP может быть плохим, хотя FID был идеальным. Именно эту слепую зону FID и устраняет INP.

Если FID можно было считать метрикой первого впечатления, то INP — это метрика стабильной отзывчивости интерфейса. Поэтому при современном аудите нужно проверять именно INP.

FID и TBT: в чём разница

FID часто сравнивали с TBT, или Total Blocking Time. Эти метрики связаны с занятостью основного потока, но измеряются по-разному.

FID нельзя было полноценно измерить в лаборатории, потому что для него нужен реальный пользователь и реальное первое взаимодействие. Поэтому в Lighthouse вместо FID часто использовали TBT как диагностическую метрику: если TBT высокий, есть риск проблем с FID или INP.

FID, LCP и CLS: чем отличаются

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

Связь FID и FCP

Между FCP и FID есть косвенная связь. Если первый контент появляется быстро, пользователь может раньше попытаться взаимодействовать со страницей. Но если в этот момент основной поток ещё занят JavaScript или гидратацией интерфейса, возникнет задержка первого ввода. Поэтому важно, чтобы визуальная готовность страницы не сильно опережала её интерактивность: пользователь должен не только видеть кнопку, но и иметь возможность сразу с ней взаимодействовать.

Основная причина высокого FID

Главная причина высокого FID — занятый основной поток браузера. Основной поток отвечает за выполнение JavaScript, обработку событий, расчёт стилей, построение макета и отрисовку интерфейса. Если он перегружен, браузер не может быстро обработать действие пользователя.

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

Что ухудшало FID

• Большой JavaScript-бандл. Чем больше JS нужно выполнить при загрузке, тем выше риск блокировки основного потока.
• Длинные задачи. Операции дольше 50 мс могут мешать браузеру быстро реагировать на действия пользователя.
• Сторонние скрипты. Виджеты чатов, рекламные пиксели, трекеры и тяжёлая аналитика могут блокировать поток.
• Синхронные операции. Синхронные запросы и тяжёлые вычисления мешают обработке событий.
• Сложные манипуляции с DOM. Массовые изменения элементов могут вызывать перерасчёты стилей и макета.
• Тяжёлые фреймворки. Большие клиентские приложения могут долго гидратироваться и блокировать взаимодействия.
• Неприоритетная загрузка ресурсов. Некритичные скрипты могут загружаться слишком рано и мешать первому взаимодействию.
• Слабые устройства. На старых смартфонах и медленных процессорах те же задачи выполняются дольше.

Почему важны задачи длиннее 50 мс

Long Tasks — это задачи в основном потоке, которые выполняются дольше 50 мс. Пока такая задача выполняется, браузер хуже реагирует на действия пользователя. Total Blocking Time считает время таких задач сверх 50 мс и помогает диагностировать риск плохой отзывчивости. Поэтому при оптимизации FID и INP важно не только уменьшать общий размер JavaScript, но и разбивать длинные операции на более короткие.

Основной поток браузера и FID

Чтобы понять FID, важно понимать роль основного потока. Браузер выполняет множество задач последовательно. Если в очереди находится тяжёлая задача, например выполнение большого JavaScript-файла, новое событие пользователя ждёт.

• Пример:

  HTML

  1. Браузер выполняет тяжёлый JavaScript — 400 мс 2. Пользователь кликает на 100-й миллисекунде 3. Клик ждёт завершения задачи 4. Браузер начинает обработку клика на 400-й миллисекунде FID = 300 мс

Пользователь в этот момент видит страницу, но ощущает задержку реакции. Поэтому видимая загрузка и интерактивность — не одно и то же.

FID и JavaScript

JavaScript чаще всего был главным источником проблем с FID. Современные сайты могут загружать большие бандлы, фреймворки, библиотеки, виджеты, аналитику, рекламные скрипты и клиентскую логику. Всё это конкурирует за основной поток.

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

Гидратация и отзывчивость интерфейса. На сайтах с React, Vue и другими JavaScript-фреймворками HTML может появиться на экране раньше, чем интерфейс станет полностью интерактивным. Процесс подключения JavaScript-логики к уже отрисованной разметке называется гидратацией. Если гидратация тяжёлая, пользователь видит кнопку или меню, но взаимодействие с ними задерживается. Progressive Hydration и Islands Architecture помогают загружать интерактивность частями, а не блокировать всю страницу сразу.

Как улучшить FID

Несмотря на то что FID заменён на INP, многие способы оптимизации остаются актуальными. Они помогают уменьшить блокировку основного потока и улучшить отзывчивость интерфейса.

• Сократить JavaScript. Удалите неиспользуемый код, лишние библиотеки и тяжёлые зависимости.
• Разделить код на части. Используйте code splitting, чтобы загружать только нужный код для текущей страницы.
• Откладывать некритичные скрипты. Используйте defer, async и ленивую загрузку там, где это безопасно.
• Разбивать длинные задачи. Делите тяжёлые операции на короткие части, чтобы браузер мог обрабатывать события между ними.
• Использовать Web Workers. Переносите тяжёлые вычисления в отдельный поток, если они не требуют прямой работы с DOM.
• Оптимизировать сторонние скрипты. Уберите лишние пиксели, виджеты и трекеры, а остальные загружайте с контролем приоритета.
• Сократить работу с DOM. Избегайте массовых синхронных изменений, которые вызывают перерасчёт стилей и макета.
• Проверять мобильные устройства. Оптимизация должна работать не только на мощном компьютере разработчика.

Defer и async для улучшения отзывчивости

Атрибуты defer и async помогают управлять загрузкой JavaScript. Они не являются универсальным решением, но могут снизить риск блокировки страницы при загрузке.

<script src="/js/main.js" defer></script>

Скрипт с defer загружается параллельно с HTML и выполняется после разбора документа. Это часто подходит для основных скриптов сайта, которым нужен готовый DOM.

<script src="/js/analytics.js" async></script>

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

Code splitting и FID

Code splitting — это разделение JavaScript на отдельные части. Вместо того чтобы загружать весь код сайта сразу, браузер получает только тот код, который нужен для текущей страницы или конкретного действия.

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

Web Workers и FID

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

Но Web Workers не могут напрямую работать с DOM. Поэтому их используют для вычислений, а результат затем передают обратно в основной поток.

Сторонние скрипты и FID

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

При аудите нужно проверить:

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

FID при техническом SEO-аудите

В старых технических SEO-аудитах FID проверяли как часть Core Web Vitals. Сейчас в актуальном аудите вместо FID нужно анализировать INP, но причины проблем часто те же: перегрузка основного потока, тяжёлый JavaScript, длинные задачи и неэффективная работа интерфейса.

При аудите отзывчивости проверяют:

• значение INP в PageSpeed Insights и Search Console;
• архивные или старые данные FID, если они есть в отчётах;
• Total Blocking Time в Lighthouse;
• длинные задачи в Performance-профиле браузера;
• размер и время выполнения JavaScript;
• количество сторонних скриптов;
• гидратацию страниц на React, Vue, Nuxt, Next.js и других JavaScript-фреймворках;
• работу форм, меню, фильтров, корзины и интерактивных элементов;
• отзывчивость на мобильных устройствах;
• разницу между лабораторными и полевыми данными.

Где измерять FID

FID был полевой метрикой, то есть требовал данных реальных пользователей. Его нельзя было корректно измерить в обычном лабораторном тесте без настоящего первого взаимодействия.

Исторически FID можно было встретить в:

• Chrome User Experience Report;
• PageSpeed Insights;
• Google Search Console в отчётах Core Web Vitals;
• RUM-системах, если они собирали данные о первом взаимодействии;
• библиотеках измерения Web Vitals.

Сейчас для актуальной диагностики отзывчивости нужно смотреть INP. В лабораторной диагностике дополнительно полезны Lighthouse, Total Blocking Time, DevTools Performance и анализ Long Tasks.

Полевые и лабораторные данные

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

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

Мобильные и десктопные данные FID. В CrUX и PageSpeed Insights данные по отзывчивости можно анализировать отдельно для мобильных и десктопных пользователей. На мобильных устройствах проблемы часто заметнее: процессоры слабее, условия сети хуже, а JavaScript выполняется дольше. Поэтому при анализе старых отчётов FID и актуальных отчётов INP важно отдельно смотреть mobile-сегмент, а не ориентироваться только на среднее значение по сайту.

Почему FID мог быть хорошим, а сайт всё равно тормозил

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

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

FID и мобильные устройства

На мобильных устройствах проблемы FID проявлялись сильнее. Один и тот же JavaScript-код может выполняться быстро на мощном ноутбуке и заметно медленнее на бюджетном смартфоне.

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

FID и пользовательский опыт

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

Это может влиять на:

• отказы;
• конверсию;
• глубину просмотра;
• доверие к сайту;
• количество отправленных форм;
• добавления товаров в корзину;
• качество мобильного опыта.

FID и SEO

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

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

FID и ИИ-поиск

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

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

Ошибки при работе с FID

• считать FID актуальной Core Web Vital-метрикой после замены на INP;
• оптимизировать только первый клик и не проверять дальнейшие взаимодействия;
• смотреть только Lighthouse без анализа реальных пользователей;
• игнорировать мобильные устройства и слабые процессоры;
• оставлять тяжёлый JavaScript на первом экране;
• загружать все сторонние скрипты сразу;
• не анализировать длинные задачи в основном потоке;
• не проверять формы, меню, фильтры, корзину и другие интерактивные элементы;
• считать, что минификация сама по себе решит проблему отзывчивости;
• не отличать FID от INP, TBT и LCP.

Как анализировать отзывчивость сайта сейчас

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

• INP. Основная актуальная метрика отзывчивости в Core Web Vitals.
• TBT. Лабораторный показатель блокировки основного потока.
• Long Tasks. Длинные задачи, которые мешают обработке пользовательских событий.
• Performance в DevTools. Профилирование JavaScript, событий, рендера и макета.
• PageSpeed Insights. Проверка полевых и лабораторных данных.
• Search Console. Отчёты Core Web Vitals по группам URL.
• RUM. Реальный мониторинг пользователей, если на сайте настроена такая аналитика.

Чек-лист оптимизации FID и INP

• Проверьте INP в PageSpeed Insights и Search Console.
• Проанализируйте Total Blocking Time в Lighthouse.
• Найдите длинные задачи в DevTools Performance.
• Сократите объём JavaScript на первом экране.
• Удалите неиспользуемый JS и CSS.
• Разделите код на чанки через code splitting.
• Отложите некритичные скрипты.
• Проверьте сторонние виджеты, пиксели и чаты.
• Разбейте тяжёлые операции на короткие задачи.
• Используйте Web Workers для тяжёлых вычислений.
• Оптимизируйте гидратацию страниц на React, Vue, Nuxt, Next.js и других JavaScript-фреймворках.
• Проверьте работу форм, меню, фильтров и корзины.
• Тестируйте сайт на мобильных устройствах.
• Сравнивайте лабораторные и полевые данные.
• Ориентируйтесь на INP как на актуальную метрику отзывчивости.

Автор экспертного мнения

Владислав Жерко

SEO-специалист, контент-стратег в Digital-агентстве Saygona

Опыт: 7+ лет в SEO и поисковом продвижении

Комментарий эксперта

FID полезен как историческая метрика, потому что он хорошо объясняет базовую проблему отзывчивости: пользователь уже взаимодействует со страницей, а браузер ещё занят выполнением JavaScript. Но в современном аудите нельзя ограничиваться FID. Нужно смотреть INP, длинные задачи, TBT, сторонние скрипты и реальные сценарии: открытие меню, фильтры, формы, корзину, калькуляторы. Хорошая отзывчивость — это не только быстрый первый клик, а стабильная реакция интерфейса на протяжении всей сессии.