Первая входная задержка (FID)

Поддержка браузера

  • Хром: 76.
  • Край: 79.
  • Фаерфокс: 89.
  • Сафари: не поддерживается.

Источник

Все мы знаем, как важно произвести хорошее первое впечатление. Это важно при знакомстве с новыми людьми, а также при приобретении опыта в Интернете.

В Интернете хорошее первое впечатление может сыграть решающую роль в том, станет ли кто-то лояльным пользователем или уйдет и никогда не вернется. Вопрос в том, что производит хорошее впечатление и как измерить, какое впечатление вы, скорее всего, произведете на своих пользователей?

В Интернете первое впечатление может принимать самые разные формы: у нас есть первое впечатление о дизайне и визуальной привлекательности сайта, а также первое впечатление о его скорости и отзывчивости.

Хотя трудно измерить, насколько пользователям нравится дизайн сайта с помощью веб-API, измерить его скорость и отзывчивость невозможно!

Первое впечатление пользователей о том, насколько быстро загружается ваш сайт, можно измерить с помощью First Contentful Paint (FCP) . Но то, насколько быстро ваш сайт может отображать пиксели на экране, — это лишь часть истории. Не менее важно то, насколько отзывчив ваш сайт, когда пользователи пытаются взаимодействовать с этими пикселями!

Метрика First Input Delay (FID) помогает измерить первое впечатление пользователя об интерактивности и отзывчивости вашего сайта.

Что такое ФИД?

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

Что такое хороший показатель FID?

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

Хорошие значения FID составляют 2,5 секунды или меньше, плохие значения превышают 4,0 секунды, а все, что находится между ними, требует улучшения.

ФИД в деталях

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

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

Рассмотрим следующую временную шкалу типичной загрузки веб-страницы:

Пример трассировки загрузки страницы

На приведенной выше визуализации показана страница, которая отправляет пару сетевых запросов на ресурсы (скорее всего, файлы CSS и JS) и — после завершения загрузки этих ресурсов — они обрабатываются в основном потоке.

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

Длительные задержки первого ввода обычно возникают между первой отрисовкой содержимого (FCP) и временем взаимодействия (TTI), поскольку страница отобразила часть своего содержимого, но еще не является надежно интерактивной. Чтобы проиллюстрировать, как это может произойти, на временную шкалу добавлены FCP и TTI:

Пример трассировки загрузки страницы с FCP и TTI

Возможно, вы заметили, что между FCP и TTI проходит довольно много времени (включая три длительные задачи ), если пользователь попытается взаимодействовать со страницей в течение этого времени (например, нажав на ссылку), произойдет задержка. между моментом получения клика и моментом, когда основной поток может ответить.

Представьте, что произойдет, если пользователь попытается взаимодействовать со страницей в начале самой длинной задачи:

Пример трассировки загрузки страницы с FCP, TTI и FID

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

Что делать, если у взаимодействия нет прослушивателя событий?

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

Например, всем следующим HTML-элементам необходимо дождаться завершения выполняемых задач в основном потоке, прежде чем реагировать на действия пользователя:

  • Текстовые поля, флажки и переключатели ( <input> , <textarea> )
  • Выпадающие списки выбора ( <select> )
  • ссылки ( <a> )

Почему учитывается только первый вход?

Хотя задержка любого ввода может привести к ухудшению пользовательского опыта, мы в первую очередь рекомендуем измерять задержку первого ввода по нескольким причинам:

  • Первая задержка ввода будет первым впечатлением пользователя об отзывчивости вашего сайта, а первые впечатления имеют решающее значение для формирования общего впечатления о качестве и надежности сайта.
  • Самые большие проблемы с интерактивностью, которые мы наблюдаем сегодня в Интернете, возникают во время загрузки страницы. Поэтому мы считаем, что первоначальное сосредоточение внимания на улучшении первого взаимодействия с пользователем сайта окажет наибольшее влияние на улучшение общей интерактивности сети.
  • Рекомендуемые решения по устранению высоких задержек при первом вводе на сайтах (разделение кода, предварительная загрузка меньшего количества JavaScript и т. д.) не обязательно совпадают с решениями по устранению медленных задержек при вводе после загрузки страницы. Разделив эти показатели, мы сможем предоставить веб-разработчикам более конкретные рекомендации по производительности.

Что считается первым вводом?

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

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

Другими словами, FID фокусируется на R (отзывчивости) в модели производительности RAIL , тогда как прокрутка и масштабирование больше связаны с A (анимация), и их производительность следует оценивать отдельно.

Что делать, если пользователь никогда не взаимодействует с вашим сайтом?

Не все пользователи будут взаимодействовать с вашим сайтом каждый раз, когда они его посещают. И не все взаимодействия имеют отношение к FID (как упоминалось в предыдущем разделе). Кроме того, первые взаимодействия некоторых пользователей будут происходить в неудачное время (когда основной поток занят в течение длительного периода времени), а первые взаимодействия некоторых пользователей будут в хорошие времена (когда основной поток полностью простаивает).

Это означает, что у некоторых пользователей значения FID отсутствуют, у некоторых пользователей значения FID низкие, а у некоторых пользователей, вероятно, значения FID высокие.

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

Зачем учитывать только входную задержку?

Как упоминалось выше, FID измеряет только «задержку» обработки событий. Он не измеряет ни общую продолжительность обработки событий, ни время, необходимое браузеру для обновления пользовательского интерфейса после запуска обработчиков событий.

Несмотря на то, что это время важно для пользователя и влияет на взаимодействие с пользователем, оно не включено в эту метрику, поскольку это может побудить разработчиков добавлять обходные пути, которые на самом деле ухудшают работу, то есть они могут обернуть логику своего обработчика событий в асинхронный обратный вызов (через setTimeout() или requestAnimationFrame() ), чтобы отделить его от задачи, связанной с событием. Результатом будет улучшение показателя метрики, но более медленный ответ по восприятию пользователя.

Однако, хотя FID измеряет только «задержку» задержки события, разработчики, которые хотят отслеживать большую часть жизненного цикла события, могут сделать это с помощью API синхронизации событий . Более подробную информацию можно найти в руководстве по специальным метрикам .

Как измерить ПИД

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

Полевые инструменты

Измерение FID в JavaScript

Чтобы измерить FID в JavaScript, вы можете использовать Event Timing API . В следующем примере показано, как создать PerformanceObserver , который прослушивает записи first-input и записывает их в консоль:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

В приведенном выше примере значение задержки first-input записи измеряется путем определения разницы между временными метками startTime и processingStart записи. В большинстве случаев это будет значение FID; однако не все записи first-input действительны для измерения FID.

В следующем разделе перечислены различия между тем, что сообщает API, и тем, как рассчитывается метрика.

Различия между метрикой и API

  • API будет отправлять записи first-input для страниц, загруженных на фоновой вкладке, но эти страницы следует игнорировать при вычислении FID.
  • API также будет отправлять записи first-input если страница находилась в фоновом режиме до того, как произошел первый ввод, но эти страницы также следует игнорировать при вычислении FID (входные данные учитываются только в том случае, если страница все время находилась на переднем плане).
  • API не сообщает о записях first-input когда страница восстанавливается из обратного/прямого кэша , но в этих случаях следует измерять FID, поскольку пользователи воспринимают их как отдельные посещения страниц.
  • API не сообщает о входных данных, которые происходят внутри iframe, но это делает метрика, поскольку они являются частью взаимодействия пользователя со страницей. Это может проявляться как разница между CrUX и RUM . Чтобы правильно измерить FID, вам следует их учитывать. Подкадры могут использовать API для передачи своих first-input записей родительскому кадру для агрегирования.

Вместо того, чтобы запоминать все эти тонкие различия, разработчики могут использовать библиотеку JavaScript web-vitals для измерения FID, которая обрабатывает эти различия за вас (где это возможно — обратите внимание, что проблема iframe не рассматривается):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Вы можете обратиться к исходному коду onFID() для получения полного примера того, как измерить FID в JavaScript.

Анализ и составление отчетов по данным FID

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

Несмотря на то, что для всех пороговых значений Core Web Vitals выбран 75-й процентиль , в частности, для FID мы по-прежнему настоятельно рекомендуем смотреть на 95-99-й процентиль, поскольку они будут соответствовать особенно плохому первому опыту взаимодействия пользователей с вашим сайтом. И он покажет вам области, которые нуждаются в наибольшем улучшении.

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

Как улучшить ФИД

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

Журнал изменений

Иногда ошибки обнаруживаются в API, используемых для измерения метрик, а иногда и в определениях самих метрик. В результате иногда приходится вносить изменения, и эти изменения могут проявляться в виде улучшений или регрессов в ваших внутренних отчетах и ​​информационных панелях.

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

Если у вас есть отзывы об этих показателях, вы можете оставить их в группе Google web-vitals-feedback .

,

Поддержка браузера

  • Хром: 76.
  • Край: 79.
  • Фаерфокс: 89.
  • Сафари: не поддерживается.

Источник

Все мы знаем, как важно произвести хорошее первое впечатление. Это важно при знакомстве с новыми людьми, а также при приобретении опыта в Интернете.

В Интернете хорошее первое впечатление может сыграть решающую роль в том, станет ли кто-то лояльным пользователем или уйдет и никогда не вернется. Вопрос в том, что производит хорошее впечатление и как измерить, какое впечатление вы, скорее всего, произведете на своих пользователей?

В Интернете первое впечатление может принимать самые разные формы: у нас есть первое впечатление о дизайне и визуальной привлекательности сайта, а также первое впечатление о его скорости и отзывчивости.

Хотя трудно измерить, насколько пользователям нравится дизайн сайта с помощью веб-API, измерить его скорость и отзывчивость невозможно!

Первое впечатление пользователей о том, насколько быстро загружается ваш сайт, можно измерить с помощью First Contentful Paint (FCP) . Но то, насколько быстро ваш сайт может отображать пиксели на экране, — это лишь часть истории. Не менее важно то, насколько отзывчив ваш сайт, когда пользователи пытаются взаимодействовать с этими пикселями!

Метрика First Input Delay (FID) помогает измерить первое впечатление пользователя об интерактивности и отзывчивости вашего сайта.

Что такое ФИД?

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

Что такое хороший показатель FID?

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

Хорошие значения FID составляют 2,5 секунды или меньше, плохие значения превышают 4,0 секунды, а все, что находится между ними, требует улучшения.

ФИД в деталях

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

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

Рассмотрим следующую временную шкалу типичной загрузки веб-страницы:

Пример трассировки загрузки страницы

На приведенной выше визуализации показана страница, которая отправляет пару сетевых запросов на ресурсы (скорее всего, файлы CSS и JS) и — после завершения загрузки этих ресурсов — они обрабатываются в основном потоке.

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

Длительные задержки первого ввода обычно возникают между первой отрисовкой содержимого (FCP) и временем взаимодействия (TTI), поскольку страница отобразила часть своего содержимого, но еще не является надежно интерактивной. Чтобы проиллюстрировать, как это может произойти, на временную шкалу добавлены FCP и TTI:

Пример трассировки загрузки страницы с FCP и TTI

Возможно, вы заметили, что между FCP и TTI проходит довольно много времени (включая три длительные задачи ), если пользователь попытается взаимодействовать со страницей в течение этого времени (например, нажав на ссылку), произойдет задержка. между моментом получения клика и моментом, когда основной поток может ответить.

Представьте, что произойдет, если пользователь попытается взаимодействовать со страницей в начале самой длинной задачи:

Пример трассировки загрузки страницы с FCP, TTI и FID

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

Что делать, если у взаимодействия нет прослушивателя событий?

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

Например, всем следующим HTML-элементам необходимо дождаться завершения выполняемых задач в основном потоке, прежде чем реагировать на действия пользователя:

  • Текстовые поля, флажки и переключатели ( <input> , <textarea> )
  • Выпадающие списки выбора ( <select> )
  • ссылки ( <a> )

Почему учитывается только первый вход?

Хотя задержка любого ввода может привести к ухудшению пользовательского опыта, мы в первую очередь рекомендуем измерять задержку первого ввода по нескольким причинам:

  • Первая задержка ввода будет первым впечатлением пользователя об отзывчивости вашего сайта, а первые впечатления имеют решающее значение для формирования общего впечатления о качестве и надежности сайта.
  • Самые большие проблемы с интерактивностью, которые мы наблюдаем сегодня в Интернете, возникают во время загрузки страницы. Поэтому мы считаем, что первоначальное сосредоточение внимания на улучшении первого взаимодействия с пользователем на сайте окажет наибольшее влияние на улучшение общей интерактивности сети.
  • Рекомендуемые решения по устранению высоких задержек при первом вводе на сайтах (разделение кода, предварительная загрузка меньшего количества JavaScript и т. д.) не обязательно совпадают с решениями по устранению медленных задержек при вводе после загрузки страницы. Разделив эти показатели, мы сможем предоставить веб-разработчикам более конкретные рекомендации по производительности.

Что считается первым вводом?

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

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

Другими словами, FID фокусируется на R (отзывчивости) в модели производительности RAIL , тогда как прокрутка и масштабирование больше связаны с A (анимация), и их производительность следует оценивать отдельно.

Что делать, если пользователь никогда не взаимодействует с вашим сайтом?

Не все пользователи будут взаимодействовать с вашим сайтом каждый раз, когда они его посещают. И не все взаимодействия имеют отношение к FID (как упоминалось в предыдущем разделе). Кроме того, первые взаимодействия некоторых пользователей будут происходить в неудачное время (когда основной поток занят в течение длительного периода времени), а первые взаимодействия некоторых пользователей будут в хорошие времена (когда основной поток полностью простаивает).

Это означает, что у некоторых пользователей значения FID отсутствуют, у некоторых пользователей значения FID низкие, а у некоторых пользователей, вероятно, значения FID высокие.

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

Зачем учитывать только входную задержку?

Как упоминалось выше, FID измеряет только «задержку» обработки событий. Он не измеряет ни общую продолжительность обработки событий, ни время, необходимое браузеру для обновления пользовательского интерфейса после запуска обработчиков событий.

Несмотря на то, что это время важно для пользователя и влияет на взаимодействие с пользователем, оно не включено в эту метрику, поскольку это может побудить разработчиков добавлять обходные пути, которые на самом деле ухудшают работу, то есть они могут обернуть логику своего обработчика событий в асинхронный обратный вызов (через setTimeout() или requestAnimationFrame() ), чтобы отделить его от задачи, связанной с событием. Результатом будет улучшение показателя метрики, но более медленный ответ по восприятию пользователя.

Однако, хотя FID измеряет только «задержку» задержки события, разработчики, которые хотят отслеживать большую часть жизненного цикла события, могут сделать это с помощью API синхронизации событий . Более подробную информацию можно найти в руководстве по специальным метрикам .

Как измерить ПИД

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

Полевые инструменты

Измерение FID в JavaScript

Чтобы измерить FID в JavaScript, вы можете использовать Event Timing API . В следующем примере показано, как создать PerformanceObserver , который прослушивает записи first-input и записывает их в консоль:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

В приведенном выше примере значение задержки first-input записи измеряется путем определения разницы между временными метками startTime и processingStart записи. В большинстве случаев это будет значение FID; однако не все записи first-input действительны для измерения FID.

В следующем разделе перечислены различия между тем, что сообщает API, и тем, как рассчитывается метрика.

Различия между метрикой и API

  • API будет отправлять записи first-input для страниц, загруженных на фоновой вкладке, но эти страницы следует игнорировать при вычислении FID.
  • API также будет отправлять записи first-input если страница находилась в фоновом режиме до того, как произошел первый ввод, но эти страницы также следует игнорировать при вычислении FID (входные данные учитываются только в том случае, если страница все время находилась на переднем плане).
  • API не сообщает о записях first-input когда страница восстанавливается из обратного/прямого кэша , но в этих случаях следует измерять FID, поскольку пользователи воспринимают их как отдельные посещения страниц.
  • API не сообщает о входных данных, которые происходят внутри iframe, но это делает метрика, поскольку они являются частью взаимодействия пользователя со страницей. Это может проявляться как разница между CrUX и RUM . Чтобы правильно измерить FID, вам следует их учитывать. Подкадры могут использовать API для передачи своих first-input записей родительскому кадру для агрегирования.

Вместо того, чтобы запоминать все эти тонкие различия, разработчики могут использовать библиотеку JavaScript web-vitals для измерения FID, которая обрабатывает эти различия за вас (где это возможно — обратите внимание, что проблема iframe не рассматривается):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Вы можете обратиться к исходному коду onFID() для получения полного примера того, как измерить FID в JavaScript.

Анализ и составление отчетов по данным FID

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

Несмотря на то, что для всех пороговых значений Core Web Vitals выбран 75-й процентиль , в частности, для FID мы по-прежнему настоятельно рекомендуем смотреть на 95-99-й процентиль, поскольку они будут соответствовать особенно плохому первому опыту взаимодействия пользователей с вашим сайтом. И он покажет вам области, которые нуждаются в наибольшем улучшении.

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

Как улучшить ФИД

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

Журнал изменений

Иногда ошибки обнаруживаются в API, используемых для измерения метрик, а иногда и в определениях самих метрик. В результате иногда приходится вносить изменения, и эти изменения могут проявляться в виде улучшений или регрессов в ваших внутренних отчетах и ​​информационных панелях.

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

Если у вас есть отзывы об этих показателях, вы можете оставить их в группе Google web-vitals-feedback .

,

Поддержка браузера

  • Хром: 76.
  • Край: 79.
  • Фаерфокс: 89.
  • Сафари: не поддерживается.

Источник

Все мы знаем, как важно произвести хорошее первое впечатление. Это важно при знакомстве с новыми людьми, а также при приобретении опыта в Интернете.

В Интернете хорошее первое впечатление может сыграть решающую роль в том, станет ли кто-то лояльным пользователем или уйдет и никогда не вернется. Вопрос в том, что производит хорошее впечатление и как измерить, какое впечатление вы, скорее всего, произведете на своих пользователей?

В Интернете первое впечатление может принимать самые разные формы: у нас есть первое впечатление о дизайне и визуальной привлекательности сайта, а также первое впечатление о его скорости и отзывчивости.

Хотя трудно измерить, насколько пользователям нравится дизайн сайта с помощью веб-API, измерить его скорость и отзывчивость невозможно!

Первое впечатление пользователей о том, насколько быстро загружается ваш сайт, можно измерить с помощью First Contentful Paint (FCP) . Но то, насколько быстро ваш сайт может отображать пиксели на экране, — это лишь часть истории. Не менее важно то, насколько отзывчив ваш сайт, когда пользователи пытаются взаимодействовать с этими пикселями!

Показатель первой задержки ввода (FID) помогает измерить первое впечатление вашего пользователя об интерактивности и отзывчивости вашего сайта.

Что такое ФИД?

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

Что такое хороший показатель FID?

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

Хорошие значения FID составляют 2,5 секунды или меньше, плохие значения превышают 4,0 секунды, а все, что находится между ними, требует улучшения.

ФИД в деталях

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

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

Рассмотрим следующую временную шкалу типичной загрузки веб-страницы:

Пример трассировки загрузки страницы

Приведенная выше визуализация показывает страницу, которая делает пару сетевых запросов на ресурсы (скорее всего, файлы CSS и JS), и - после того, как эти ресурсы закончат загрузку - они обрабатываются в главном потоке.

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

Длинные первые входные задержки обычно происходят между первой удовлетворенной краской (FCP) и временем интерактивного (TTI), потому что страница сделала часть своего содержания, но еще не достоверно интерактивна. Чтобы проиллюстрировать, как это может произойти, FCP и TTI были добавлены в график:

Пример страницы трассировки с FCP и TTI

Возможно, вы заметили, что между FCP и TTI есть достаточное количество времени (включая три длинных задачи ), если пользователь пытается взаимодействовать с страницей в течение этого времени (например, нажав на ссылку), будет задержка. Между тем, когда клик получен и когда основной поток может отвечать.

Подумайте, что произойдет, если пользователь попытается взаимодействовать со страницей в начале самой длинной задачи:

Пример страницы трассировки с FCP, TTI и FID

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

Что если у взаимодействия нет слушателя событий?

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

Например, все следующие элементы HTML должны ждать задач в основном потоке, чтобы выполнить, прежде чем ответить на взаимодействие с пользователями:

  • Текстовые поля, флажки и радиопроизводительные кнопки ( <input> , <textarea> )
  • Выберите «Распада ( <select> )
  • Ссылки ( <a> )

Зачем рассматривать только первый вход?

Хотя задержка с любого ввода может привести к плохому пользовательскому опыту, мы в первую очередь рекомендуем измерить первую задержку ввода по нескольким причинам:

  • Первая задержка ввода станет первым впечатлением от реагирования вашего сайта, и первые впечатления имеют решающее значение для формирования нашего общего впечатления от качества и надежности сайта.
  • Самые большие проблемы с интерактивностью, которые мы видим в Интернете сегодня, возникают во время загрузки страницы. Поэтому мы считаем, что первоначально сосредоточение внимания на улучшении первого взаимодействия с пользователем сайта окажет наибольшее влияние на улучшение общей интерактивности Интернета.
  • Рекомендуемые решения для того, как сайты должны устанавливать высокие задержки в первом вводе (разделение кода, загрузка меньшего количества JavaScript и т. Д.) Не обязательно являются одинаковыми решениями для установления замедленных задержек ввода после загрузки страницы. Разделив эти метрики, мы сможем предоставить более конкретные рекомендации по производительности веб -разработчикам.

Что считается первым входом?

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

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

Иными словами, FID фокусируется на R (отзывчивости) в модели производительности железной дороги , тогда как прокрутка и масштабирование в большей степени связаны с (анимацией), и их качества производительности должны оцениваться отдельно.

Что, если пользователь никогда не взаимодействует с вашим сайтом?

Не все пользователи будут взаимодействовать с вашим сайтом каждый раз, когда они посещают. И не все взаимодействия имеют отношение к FID (как упомянуто в предыдущем разделе). Кроме того, первые взаимодействия некоторых пользователей будут в плохом времени (когда основной поток занят в течение длительного периода времени), а первые взаимодействия некоторых пользователей будут в хорошее время (когда основной поток полностью простаивает).

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

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

Зачем только рассматривать задержку ввода?

Как упоминалось выше, FID только измеряет «задержку» при обработке событий. Он не измеряет саму общую продолжительность обработки событий, ни время, необходимое для браузера для обновления пользовательского интерфейса после запуска обработчиков событий.

Несмотря на то, что это время важно для пользователя и действительно влияет на опыт, он не включен в эту метрику, потому что это может стимулировать разработчиков добавить обходные пути, которые фактически усугубляют опыт, то есть они могли бы обернуть логику обработчика событий в асинхронный Callback (через setTimeout() или requestAnimationFrame() ), чтобы отделить его от задачи, связанной с событием. Результатом будет улучшение показателя метрического показателя, но более медленный ответ, как воспринимается пользователем.

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

Как измерить FID

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

Полевые инструменты

Измерить FID в JavaScript

Чтобы измерить FID в JavaScript, вы можете использовать API времени события . В следующем примере показано, как создать PerformanceObserver , который прослушивает записи first-input и регистрирует их в консоли:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

В приведенном выше примере значение задержки first-input измеряется путем принятия дельты между startTime метками начала и processingStart . В большинстве случаев это будет значение FID; Однако не все записи first-input действительны для измерения FID.

В следующем разделе перечислены различия между тем, что сообщает API, и тем, как рассчитывается метрика.

Различия между метрикой и API

  • API будет отправлять записи first-input для страниц, загруженных на фоновой вкладке, но эти страницы следует игнорировать при расчете FID.
  • API также будет отправлять записи first-input , если страница была фонена до первого входа, но эти страницы также следует игнорировать при расчете FID (входы рассматриваются только в том случае, если страница была на переднем плане все время).
  • API не сообщает о записях first-input когда страница восстановлена ​​из кеша заднего/вперед , но FID следует измерять в этих случаях, поскольку пользователи испытывают их в качестве отдельных посещений страницы.
  • API не сообщает входные данные, которые встречаются в IFRAMES, но метрика делает, поскольку они являются частью пользовательского опыта страницы. Это может показать разницу между сутью и ромом . Чтобы правильно измерить FID, вы должны рассмотреть их. Подрамы могут использовать API, чтобы сообщить о своих записях first-input в родительский кадр для агрегации.

Вместо того, чтобы запоминать все эти тонкие различия, разработчики могут использовать библиотеку JavaScript web-vitals для измерения FID, которая обрабатывает эти различия для вас (где это возможно,-примечание проблемы IFRAME не покрывается):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Вы можете обратиться к исходному коду для onFID() для полного примера того, как измерить FID в JavaScript.

Анализ и отчетность по данным FID

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

Несмотря на то, что выбор процентиля для всех основных пороговых значений Web Vitals составляет 75 -й, для FID, в частности, мы все еще настоятельно рекомендуем взглянуть на 95–99 -й процентили, так как они будут соответствовать особенно плохим первым опыту, которые пользователи испытывают с вашим сайтом. И это покажет вам области, которые требуют наибольшего улучшения.

Это верно, даже если вы сегментируете свои отчеты по категории устройств или типу. Например, если вы запускаете отдельные отчеты для рабочего стола и мобильных устройств, то значение FID вас больше всего заботится на рабочем столе, которое должно быть 95–99 -й процентиль пользователей рабочего стола, и значение FID, которое вам больше всего волнует на мобильных мобильных пользователей.

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

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

Изменение

Иногда ошибки обнаруживаются в API, используемых для измерения метрик, а иногда и в определениях самих метрик. В результате иногда должны быть внесены изменения, и эти изменения могут проявляться в виде улучшений или регрессий в ваших внутренних отчетах и ​​панелях.

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

Если у вас есть отзывы о этих метриках, вы можете предоставить его в Google Google Google Google Web-Vitals .