First input delay fid что это
First Input Delay (FID)
First Input Delay (FID) — важная, ориентированная на пользователя метрика для измерения реакции на нагрузку. Она количественно оценивает опыт пользователей при попытке взаимодействия с неотвечающими страницами — низкий FID помогает гарантировать, что страницу можно использовать.
Все мы знаем, как важно произвести хорошее первое впечатление. Это важно не только при знакомстве с новыми людьми, но и при построении web-сайта в Интернете.
В Интернете хорошее первое впечатление имеет важное значение, станет ли посетитель сайта лояльным пользователем или уйдет и больше не вернется. Вопрос в том, что производит хорошее впечатление и как вы оцениваете, какое впечатление ваш сайт производит на пользователей?
В Интернете первое впечатление может принимать самые разные формы: от дизайна и визуальной привлекательности сайта, от его скорости и отзывчивости.
Хотя сложно измерить, насколько пользователям нравится дизайн сайта или web-API, но можно легко измерить его скорость и отзывчивость!
Первое впечатление пользователей о том, как быстро загружается ваш сайт, можно измерить с помощью First Contentful Paint (FCP). Но то, как быстро ваш сайт может рисовать пиксели на экране — это только часть истории. Не менее важно, насколько быстро реагирует ваш сайт, когда пользователи пытаются взаимодействовать с этими пикселями!
Показатель First Input Delay (FID) помогает измерить первое впечатление пользователя об интерактивности и быстродействии вашего сайта.
Что такое FID?
FID измеряет время от момента, когда пользователь впервые взаимодействует со страницей (то есть, когда он кликает по ссылке, нажимает кнопку или использует настраиваемый элемент управления на основе JavaScript), до момента, когда браузер действительно может начать перехват и обработку событий в ответ на это взаимодействие.
Какой показатель FID хороший?
Чтобы обеспечить удобство работы пользователей, сайты должны стремиться к тому, чтобы задержка первого ввода составляла 100 миллисекунд или меньше. Чтобы убедиться, что вы достигли этой цели для большинства пользователей, хорошим порогом для измерения является 75-й перцентиль загрузки страниц, сегментированный по мобильным и настольным устройствам.
Подробнее о FID
Как разработчики, которые пишут код, реагирующий на события, мы часто предполагаем, что наш код будет запущен немедленно — как только событие произойдет. Но, как пользователи, часто сталкиваемся с обратным: мы загружаем веб-страницу на свой телефон, пытаемся взаимодействовать с ней и разочаровываемся, когда ничего не происходит в ответ.
Как правило, задержка ввода возникает из-за того, что основной поток браузера занят чем-то другим, поэтому он (пока) не может отвечать пользователю. Одна из распространенных причин, по которой это может произойти, заключается в том, что браузер занят синтаксическим анализом и выполнением большого JavaScript-файла, загруженного вашим приложением. При этом он ещё не может запускать прослушивателей событий, потому что загружаемый JavaScript может заставить его сделать что-то ещё.
FID измеряет только «задержку» обработки событий. Он не измеряет ни время обработки событий, ни время, необходимое браузеру для обновления пользовательского интерфейса после запуска обработчиков событий. Хотя это время действительно влияет на взаимодействие с пользователем, включение его как части FID будет стимулировать разработчиков реагировать на события асинхронно, что улучшит метрику, но, вероятно, ухудшит восприятие. Для получения дополнительных сведений, почему учитывается только задержка на входе см. ниже.
Рассмотрим временную шкалу загрузки типичной веб-страницы:
Эта визуализация показывает страницу, которая выполняет несколько сетевых запросов за ресурсами (скорее всего, файлы CSS и JS) и, после завершения загрузки этих ресурсов, они обрабатываются в основном потоке.
Это приводит к периодам, когда основной поток какое-то время занят. Эти задачи обозначены блоками бежевого цвета.
Длительные задержки первого ввода обычно возникают между первой отрисовкой содержимого First Contentful Paint (FCP) и временем до начала взаимодействия Time to Interactive (TTI), потому что страница визуализировала часть своего содержимого, но еще не является надежно интерактивной. Чтобы проиллюстрировать, как это может происходить, на временную шкалу были добавлены FCP и TTI:
Возможно, вы заметили, что между FCP и TTI проходит довольно много времени (в том числе — три длинные задачи). Если пользователь пытается взаимодействовать со страницей в течение этого времени (например, кликнуть по ссылке), будет задержка между тем, когда получен клик и когда основной поток сможет ответить.
Подумайте, что произойдет, если пользователь попытается взаимодействовать со страницей в начале самой длинной задачи:
Поскольку ввод здесь происходит, когда браузер находится в процессе выполнения задачи, ему придётся дождаться завершения задачи, прежде чем он сможет отреагировать на ввод. Время ожидания — это значение FID для этого пользователя на этой странице.
В этом примере пользователь случайно повзаимодействовал со страницей в начале периода наибольшей нагрузки основного потока. Если бы он начал взаимодействовать со страницей мгновением раньше (во время периода простоя), браузер смог бы ответить сразу. Эта разница во входной задержке подчеркивает важность рассмотрения распределения значений FID при составлении отчетов по метрике. Вы можете узнать больше об этом в разделе ниже, посвященном анализу и составлению отчетов по данным FID.
Что делать, если у взаимодействия нет прослушивателя событий?
FID измеряет разницу между моментом получения события ввода и следующим бездействием основного потока. Это означает, что FID измеряется даже в тех случаях, когда прослушиватель событий не был зарегистрирован. Причина в том, что для многих взаимодействий с пользователем не требуется прослушиватель событий, но для их запуска требуется, чтобы основной поток находился в режиме ожидания.
Например, все HTML-элементы в списке ниже должны ждать завершения выполняемых задач в основном потоке, прежде чем отвечать на действия пользователя:
Почему рассматривается только первый ввод?
Хотя задержка от любого ввода может привести к плохому взаимодействию с пользователем, измерять задержку первого ввода в первую очередь рекомендуется по нескольким причинам:
Что считается первым вводом?
FID — это показатель, который измеряет скорость отклика страницы во время загрузки. Таким образом, он фокусируется только на событиях ввода от дискретных действий, таких как клики, касания и нажатия клавиш.
Другие взаимодействия, такие как прокрутка и масштабирование, являются непрерывными действиями и имеют совершенно другие ограничения производительности (кроме того, браузеры часто могут скрывать свою задержку, выполняя их в отдельном потоке).
Другими словами, FID фокусируется на R (responsiveness — отзывчивость) в модели производительности RAIL, тогда как прокрутка и масштабирование больше связаны с A (animation — анимация) и их характеристики производительности следует оценивать раздельно.
Что делать, если пользователь никогда не взаимодействует с вашим сайтом?
Не все пользователи будут взаимодействовать с вашим сайтом при каждом посещении. И не все взаимодействия имеют отношение к FID (как упоминалось в предыдущем разделе). Кроме того, первые взаимодействия некоторых пользователей будут происходить в неудобное время (когда основной поток занят в течение длительного периода времени), а первые взаимодействия некоторых пользователей будут в удобное время (когда основной поток полностью простаивает).
Это означает, что у некоторых пользователей не будет значений FID, у некоторых пользователей будут низкие значения FID, а у некоторых пользователей, вероятно, будут высокие значения FID.
То, как вы отслеживаете, составляете отчеты и анализируете FID, вероятно, будет немного отличаться от других показателей, к которым вы, возможно, привыкли. В следующем разделе объясняется, как это лучше всего сделать.
Почему нужно учитывать только задержку при вводе?
Как уже упоминалось выше, FID измеряет только задержку обработки событий. Он не измеряет ни время обработки событий, ни время, необходимое браузеру для обновления пользовательского интерфейса после запуска обработчиков событий.
Несмотря на то, что это время важно для пользователя и влияет на взаимодействие с пользователем, оно не включается в эту метрику, потому что это может побудить разработчиков добавить обходные пути, которые фактически ухудшат работу. Например, они могут заключить свою логику обработчика событий в асинхронный обратный вызов (через setTimeout() или requestAnimationFrame() ), чтобы отделить его от задачи, связанной с событием. Результатом будет улучшение показателя метрики, но более медленная реакция, которую будет ощущать пользователь.
Однако, хотя FID измеряет только часть задержки события, разработчики, которые хотят отслеживать больше из жизненного цикла события, могут сделать это с помощью Event Timing API. См. руководство по пользовательским метрикам для получения более подробной информации.
Как измерять FID
FID — это показатель, который можно измерить только в полевых условиях, так как он требует, чтобы реальный пользователь взаимодействовал с вашей страницей. FID требует наличия реального пользователя и поэтому не может быть измерен в лабораторных условиях. Однако показатель общего времени блокировки (TBT) поддается лабораторным измерениям, хорошо коррелирует с FID в полевых условиях, а также фиксирует проблемы, влияющие на интерактивность. Оптимизация, улучшающая TBT в лабораторных условиях, также должна улучшить FID для ваших пользователей.
Вы можете измерить FID с помощью следующих инструментов.
Полевые инструменты
Измерение FID с помощью JavaScript
Предупреждение: этот код показывает только, как регистрировать first-input записи в консоль и вычислять их задержку. Однако измерение FID в JavaScript немного сложнее. Подробности ниже:
В приведенном выше примере значение задержки first-input записи измеряется путем получения разницы между отметками времени startTime и processingStart записи. В большинстве случаев это будет значение FID. Однако не все first-input записи действительны для измерения FID.
В следующем разделе перечислены различия между тем, что сообщает API и тем, как рассчитывается метрика.
Различия между метрикой и API
Вместо того, чтобы запоминать все эти тонкости и различия, разработчики могут использовать JavaScript-библиотеку web-vitals для измерения FID, которая обрабатывает эти различия за вас (где это возможно):
Вы можете обратиться к исходному коду getFID() для получения полного примера того, как измерить FID в JavaScript. В некоторых случаях (например, в iframe с cross origin) невозможно измерить FID c помощью JavaScript.
Анализ и отчетность по данным FID
Из-за ожидаемой дисперсии значений FID очень важно, чтобы при составлении отчета по FID вы смотрели на распределение значений и сосредотачивались на более высоких.
Хотя выбор перцентиля для всех пороговых значений Core Web Vitals является 75-м, для FID настоятельно рекомендуется смотреть на 95–99-й перцентили, поскольку они будут соответствовать особенно плохим первым впечатлениям пользователей от вашего сайта. И он покажет вам области, которые больше всего нуждаются в улучшении.
Это верно, даже если вы сегментируете отчеты по категории или типу устройств. Например, если вы запускаете отдельные отчеты для настольных компьютеров и мобильных устройств, значение FID, которое вас больше всего интересует на настольных компьютерах, должно быть 95–99 перцентилем пользователей настольных компьютеров. А значение FID, которое вас больше всего волнует на мобильных устройствах, должно быть 95–99 перцентилем. мобильных пользователей.
Как улучшить FID
Чтобы узнать, как улучшить FID для конкретного сайта, вы можете запустить аудит производительности Lighthouse и обратить внимание на любые конкретные возможности, предлагаемые аудитом.
Хотя FID является полевым показателем (а Lighthouse — инструментом лабораторных показателей), рекомендации по улучшению FID такие же, как и для улучшения лабораторного показателя Total Blocking Time (TBT).
Подробное описание того, как улучшить FID, см. в разделе Оптимизация FID. Дополнительные рекомендации по отдельным методам работы, которые также могут улучшить FID, см.
Как оптимизировать FID — еще один показатель Core Web Vitals 🚀
В статье:
С июня 2021 года Google разворачивает обновление Page Experience, которое анализирует, насколько страница удобна пользователям. В обновление входит Core Web Vitals — набор количественных показателей, касающихся быстрой и комфортной загрузки страницы.
Важна не только скорость загрузки страницы, но и то, как проходят этапы ее загрузки. В CWV входят показатели:
стабильности макета во время загрузки элементов — CLS. Подробнее в статье о CLS.
скорости рендеринга самого большого видимого элемента на странице — LCP. Подробнее в статье о LCP.
скорости реакции страницы на первое действие пользователя — FID.
Его мы и разберем в материале.
Что такое показатель FID в SEO
FID, First Input Delay — это метрика Core Web Vitals, обозначающая задержку реакции страницы на первое действие пользователя после загрузки. Он измеряет только задержку обработки событий, но не время, затраченное на саму обработку.
Скорость реакции страницы на первый клик или скролл пользователя влияет на его первое впечатление о скорости сайта. Если нужный пользователю раздел уже появился в меню, но браузер долго реагирует на клик, пользователь может решить, что сайт тормозит.
Для пользователя, который видит сайт в первый раз, время до первой реакции может быть не так важно, потому что он еще сам не сориентировался на сайте, ему нужно время разобраться, куда кликать. Но для частых посетителей, которые уже знают, какой раздел им нужен, задержки могут быть критичны.
Какой показатель FID считается нормой
Чем меньше времени прошло с момента, когда пользователь совершает первое действие на странице, до момента, когда браузер на него реагирует, тем лучше. Оптимальным считается FID до 100 миллисекунд.
Как оптимизировать FID для Core Web Vitals
Основная причина плохого FID — сложности с выполнением большого файла JavaScript. Пока браузер выполняет JavaScript в основном потоке, он не может реагировать на действия пользователя.
Оптимизация анализа, компиляции и выполнения JavaScript на странице напрямую сокращает FID. Чем меньше кода JavaScript нужно выполнять браузеру, тем быстрее он справится и сможет реагировать на действия пользователя.
Разберем, что делать, чтобы оптимизировать First Input Delay страницы.
Сократить время выполнения JavaScript
По умолчанию весь JavaScript блокирует рендеринг. Когда браузер встречает тег скрипта, который ссылается на внешний файл JavaScript, ему приходится прерываться на обработку этого JavaScript: загрузить, проанализировать, скомпилировать и выполнить.
Чтобы минимизировать эту задержку, нужно расставить приоритеты: в первую очередь загружать то, что сейчас нужно пользователю. Это универсальный совет для оптимизации всех параметров из набора Core Web Vitals.
В служебной секции head должны быть только критичные скрипты, нужные для работы страницы. Стремитесь минимизировать объем данных, которые необходимо обрабатывать на стороне клиента.
JavaScript, которые не используются на странице, можно посмотреть в Chrome DevTools на вкладке «Coverage». Chrome DevTools можно открыть горячими клавишами Ctrl + Shift + I в браузере Google Chrome.
Просмотр JS на странице
Либо в бесплатном инструменте для проверки скорости загрузки. Он даст советы по оптимизации загрузки страницы, в том числе отобразит список неиспользуемого JavaScript и посчитает экономию от его удаления.
Совет из проверки скорости от PR-CY
Для уменьшения времени обработки JavaScript, нужно разбить его на части и использовать асинхронную загрузку.
Разбить длинные задачи на части
Выполнение фрагмента кода, которое блокирует основной поток работы браузера на 50 мс или более, относится к длинным задачам. Их можно разделить на мелкие части и загружать асинхронно, чтобы нужные функции подгружались только перед их использованием, а ненужные вовсе не подгружались.
Получать модуль по запросу можно с помощью синтаксиса динамического импорта JavaScript. Он гарантирует, что код, не используемый для начальной загрузки страницы, будет извлекаться только при необходимости.
Большинство новых браузеров его поддерживают:
По данным caniuse.com
Это сведет к минимуму объем скрипта, который необходимо анализировать и компилировать, а значит страница будет быстрее загружаться и реагировать на пользователя.
Отложить неиспользуемый JavaScript
Любой некритический JavaScript, включая сторонние скрипты, можно отложить с помощью async или defer.
Материал про асинхронную загрузку JS, CSS и другие способы оптимизации кода верхней части страницы.
Следить за размером подгружаемых библиотек JavaScript
Чем больше кода JS браузер должен обработать, тем дольше основной поток отрисовки будет заблокирован и тем больше будет задержка FID.
Пересмотрите список библиотек, которые стоят в приоритете. К примеру, популярную библиотеку JqueryUI — jquery (90kb) часто ставят в приоритет, хотя это не требуется, если она нужна для обработки какого-то одного события. Иногда ее можно вовсе не использовать, если чистый JS-код составляет всего пару строк.
Оптимизировать выполнение сторонних скриптов
Сторонние теги и средства аналитики могут загружать сеть и тормозить основной поток работы браузера. Расставляйте приоритеты по точно такому же принципу: загружайте сторонний код в тот момент, когда он он понадобится для функционирования страницы.
Счетчики аналитики, сквозная аналитика, скрипты коллтрекинга не должны мешать пользователям быстро получать доступ к странице. Посмотрите, как загружается сторонний код, и настройте отложенную загрузку по запросу. Например, не загружайте сразу элементы из нижней части страницы, пока пользователь не проскроллит страницу до них.
Если скрипты будут находиться на вашем сервере, они будут загружаться быстрее, для этого существуют self-hosted системы. В этом случае данные тоже будут храниться на ваших серверах.
Если вы используете аналитику поверхностно, не смотрите тепловые карты, не ставите виртуальные цели, то может быть достаточно серверных инструментов аналитики. В таком случае скрипты на сайт ставить не нужно. Есть, к примеру, goAccess, awstats, analog, webalizer. Они берут данные из журналов веб-сервера.
Использовать web-workers
С помощью web-workers или веб-воркеров можно написать скрипт для запуска JavaScript в отдельном фоновом потоке. Таким образом обработка JS-кода не будет задерживать основной поток работы браузера и увеличивать FID. Так можно загружать и другие ресурсы, к примеру, медиа-контент.
Как проверить скорость загрузки сайта и измерить FID
Показатель FID не может быть смоделирован, для измерения задержки ответа требуется реальное взаимодействие с пользователем. Вместо этого можно ориентироваться на общее время блокировки TBT — Total Blocking Time. Эти показатели измеряют разные вещи, но улучшение TBT обычно соответствует FID.
Посмотреть показатели сайта можно в отчете Core Web Vitals в Search Console.
Значение FID отображается в PageSpeed Insights, но в подробном аудите тоже нужно ориентироваться на TBT.
Результаты проверки страницы
У PR-CY есть инструмент для измерения скорости сайта онлайн, он использует API Google. Инструмент покажет, как ведет себя сайт на разных стадиях загрузки, проанализирует, насколько хороши показатели Core Web Vitals, и подскажет, что можно улучшить.
Фрагмент результатов с рекомендациями
А если кроме скорости вы хотите следить и за другими показателями, попробуйте Анализ сайта. Этот сервис проведет онлайн-аудит SEO-показателей, технических характеристик, мобилопригодности и других параметров, найдет ошибки на внутренних страницах и покажет график позиций в ПС.
Фрагмент анализа в сервисе
Подробные результаты отображаются на платных тарифах сервиса, но вы можете неделю попробовать всё бесплатно.
В комментариях расскажите, что еще стоило бы разобрать в блоге об ускорении сайта или о чем-то другом из сферы оптимизации.
Оптимизация первой задержки ввода
Как быстрее реагировать на взаимодействие с пользователем.
«Я нажал, но ничего не произошло! Почему я не могу взаимодействовать с этой страницей?» 😢
Чтобы помочь предсказать FID в lab, рекомендуется общее время блокировки (TBT). Они измеряют разные вещи, но улучшения в TBT обычно соответствуют улучшениям в FID.
Основной причиной плохого FID является тяжелое выполнение JavaScript. Оптимизация анализа, компиляции и выполнения JavaScript на вашей веб-странице напрямую сократит FID.
Тяжелое выполнение JavaScript
Браузер не может отвечать на большинство пользовательских вводимых данных, пока он выполняет JavaScript в основном потоке. Другими словами, браузер не может реагировать на взаимодействие с пользователем, пока основной поток занят. Чтобы улучшить это нужно:
Сократить время выполнения JavaScript
Ограничение количества JavaScript на вашей странице уменьшает количество времени, которое браузер должен потратить на синтаксический анализ, компиляцию и выполнение кода JavaScript. Это увеличивает скорость, с которой браузер может начать реагировать на любые действия пользователя.
Чтобы уменьшить количество JavaScript, выполняемого на вашей странице нужно:
Помимо минимизации JavaScript, разбитие долго выполняющегося кода на более мелкие задачи, может позволить браузеру быстрее запускать обработчики ввода, что может улучшить FID.
Сократить и сжать файлы JavaScript
JavaScript может содержать символы, которые не нужны для браузеров, но облегчают чтение во время разработки. Это включает в себя интервалы, отступы, комментарии и длинные имена переменных.
Terser поддерживает синтаксис ES6+ и может использоваться для минимизации современных файлов JavaScript без необходимости их транспилирования. Если вы используете связку модулей и хотите включить Terser в свою цепочку инструментов:
В дополнение к минимизации, сжимайте ваши ресурсы JavaScript, чтобы минимизировать размер их доставки. Если возможно, используйте Brotli, который обеспечивает лучшие результаты сжатия, чем Gzip, и может использоваться практически во всех новых браузерах.
Отложить неиспользованный JavaScript
По умолчанию весь JavaScript блокирует рендеринг. Когда браузер обнаруживает тег сценария, который ссылается на внешний файл JavaScript, он должен приостановить выполнение своих действий и загрузить, проанализировать, скомпилировать и выполнить этот JavaScript. Поэтому вам следует загружать только тот код, который необходим для страницы или отвечает на ввод пользователя.
На вкладке Coverage в Chrome DevTools можно указать, сколько JavaScript не используется на вашей веб-странице.
Чтобы сократить неиспользуемый JavaScript необходимо:
Динамический импорт JavaScript для определенных взаимодействий пользователя (таких как изменение маршрута или отображение модального режима) обеспечит выбор кода, не используемого для начальной загрузки страницы, только при необходимости.
Помимо общей поддержки браузера, динамический синтаксис импорта может использоваться во многих различных системах сборки.
Помимо разделения кода, всегда используйте async или defer для сценариев, которые не нужны для критического пути или содержимого, превышающего сложность.
Минимизируйте неиспользуемые полифилы
Если вы создаете свой код с использованием современного синтаксиса JavaScript и ссылаетесь на API-интерфейсы современных браузеров, вам потребуется перенести его и включить полифиллы, чтобы он работал в старых браузерах.
Одной из основных проблем производительности, связанной с включением на ваш сайт полифилов и переносимого кода, является то, что более новым браузерам не нужно загружать их, если они им не нужны. Чтобы сократить размер JavaScript вашего приложения, максимально сведите к минимуму неиспользуемые полифилы и ограничьте их использование средами, где они необходимы.
Для оптимизации использования полифилла на вашем сайте:
Многие новые функции ECMAScript, скомпилированные с помощью Babel, уже поддерживаются в средах, поддерживающих модули JavaScript. Таким образом, делая это, вы упрощаете процесс проверки того, что только транспилированный код используется для браузеров, которые действительно нуждаются в нем.
Разбейте длинные задачи
Если вы уже пытались уменьшить объем JavaScript, который загружается на одной странице, может быть полезно разбить долго выполняющийся код на более мелкие асинхронные задачи.
Разделение длинных задач может уменьшить задержку ввода на вашем сайте.
FID должен заметно улучшиться, поскольку вы принимаете лучшие практики, такие как разделение кода и разбитие ваших длинных задач. Хотя TBT не является полевой метрикой, он полезен для проверки прогресса и в конечном счете улучшения как времени до интерактивного (TTI), так и FID.
Оптимизация страницы для взаимодействия готовности
Существует ряд распространенных причин плохой оценки FID и TBT в веб-приложениях, которые сильно зависят от JavaScript:
Выполнение сценария первого лица может задержать готовность к взаимодействию #
Ниже приведены оценки TBT до и после оптимизации загрузки сценариев первой стороной для приложения. Перемещая дорогостоящую загрузку скрипта (и выполнение) для несущественного компонента критического пути, пользователи могли взаимодействовать со страницей гораздо раньше.
Выборка данных может влиять на многие аспекты готовности взаимодействия
Выборка данных может влиять на многие аспекты готовности взаимодействия
Использование веб-работника
Блокированный основной поток является одной из основных причин задержки ввода. Веб-работники позволяют запускать JavaScript в фоновом потоке. Перемещение операций, не связанных с пользовательским интерфейсом, в отдельный рабочий поток может сократить время блокировки основного потока и следовательно, улучшить FID.
Рассмотрите возможность использования следующих библиотек, чтобы упростить использование веб-работников на вашем сайте:
Инструменты разработчика
Доступен ряд инструментов для измерения и отладки FID:
Lighthouse 6.0 не включает поддержку FID, так как это метрика поля. Тем не менее, общее время блокировки (TBT) может использоваться в качестве прокси. Оптимизации, которые улучшают TBT, также должны улучшить FID на местах.
Chrome User Experience Report предоставляет реальные значения LCP, агрегированные на уровне источника.