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

Мы все знаем, как важно произвести хорошее первое впечатление – как при знакомстве с новыми людьми, так и в интернете. В Интернете хорошее первое впечатление может стать прямой зависимостью, станет пользователь лояльным, либо он закроет наш сайт и никогда не вернется. От чего зависит хорошее впечатление, как происходит его оценка и какое впечатление вы, вероятно, производите на своих пользователей?

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

Измерять, насколько пользователям нравится дизайн сайта сложно с помощью веб-API, но измерить скорость загрузки и реагирования – нет.

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

Чтобы измерить первое впечатление вашего пользователя об интерактивности и отзывчивости вашего сайта, Google ввёл новую метрику под названием «Первая задержка ввода» (FID).

Какова первая задержка ввода?

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

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

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

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

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

Теперь давайте добавим две другие метрики: First Contentful Paint (FCP), о которой я упоминал выше, и Time to Interactive (TTI), которую вы, вероятно, видели в таких инструментах, как Lighthouse или WebPageTest:

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

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

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

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

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

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

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

Время до интерактивности (TTI) – это показатель, который измеряет, сколько времени занимает загрузка вашего приложения и оно становится способным быстро реагировать на взаимодействия с пользователем, а First Input Delay (FID) – это показатель, который измеряет задержку, с которой сталкиваются пользователи, когда они взаимодействуют со страницей, пока она еще не интерактивна.

Так зачем нам две метрики, которые измеряют похожие вещи? Ответ в том, что обе метрики важны, но они важны в разных контекстах.

TTI - это показатель, который можно измерить без присутствия пользователей, что означает, что он идеально подходит для лабораторных сред, таких как Lighthouse или WebPageTest. К сожалению, лабораторные показатели по самой своей природе не могут измерить реальную боль пользователя.

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

По этим причинам Google рекомендует обе метрики, желательно измерять TTI в лаборатории и измерять FID в «дикой природе» с помощью своего аналитического инструмента.

Фактически, Google планирует сделать то же самое с инструментами повышения производительности. Лабораторные инструменты, такие как Lighthouse и WebPageTest, уже сообщают о TTI, и Google изучает возможность добавления FID к инструментам мониторинга реальных пользователей (RUM), таким как Chrome User Experience Report (CrUX).

Кроме того, несмотря на то, что это разные метрики, исследование Google показало, что они хорошо коррелируют друг с другом, а это означает, что любая работа, которую вы делаете для улучшения вашего TTI, вероятно, также улучшит вашу FID.

Примечание: хотя TTI и FID хорошо коррелируют, могут быть случаи, когда сайт с хорошими показателями TTI может иметь плохие оценки FID (и наоборот). Например, сайт может иметь очень высокий TTI, но если большинство пользователей не пытаются взаимодействовать с сайтом до тех пор, пока он не будет полностью загружен, эти пользователи не будут испытывать боль от высокого TTI. С другой стороны, у сайта может быть относительно низкий показатель TTI, но если сайт выглядит очень интерактивно, пользователи могут попытаться взаимодействовать с ним и обнаружить, что ничего не происходит. Вот почему Google рекомендует оптимизировать оба показателя (а также использовать инструменты лаборатории и RUM).

Почему только первый ввод?

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

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

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

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

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

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

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

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

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

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

Отслеживание FID в JavaScript

FID может быть измерен в JavaScript во всех браузерах сегодня. Чтобы упростить процесс, Google создали библиотеку JavaScript, которая отслеживает и рассчитывает ее для вас: GoogleChromeLabs / first-input-delay.

Обратитесь к README библиотеки для полного использования и инструкции по установке, но суть в том, что вы:

• Включите минифицированный фрагмент кода в <head> вашего документа, который добавляет соответствующие прослушиватели событий (этот код должен быть добавлен как можно раньше, иначе вы можете пропустить события).
• В своем коде приложения зарегистрируйте обратный вызов, который будет вызываться со значением FID (а также с самим событием), как только будет обнаружен первый соответствующий ввод.

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

// Объект perfMetrics создается кодом, который находится в <head>.
perfMetrics.onFirstInputDelay(function(delay, evt) {
  ga('send', 'event', {
    eventCategory: 'Perf Metrics',
    eventAction: 'first-input-delay',
    eventLabel: evt.type,
    // Значения события должны быть целочисленными.
    eventValue: Math.round(delay),
    // Исключить это событие из расчета показателя отказов.
    nonInteraction: true,
  });
});

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

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

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

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

Например, в Google Analytics можно создавать отчеты по конкретным квантилям, но это требует немного дополнительной работы. В Статье «Настройка Google Analytics, которую я использую на каждом создаваемом сайте», есть раздел по настройке измерений на уровне попаданий. Когда вы делаете это, вы открываете для себя возможность фильтровать и сегментировать по отдельным значениям событий, а также создавать распределения, чтобы вы могли рассчитать 99%. Если вы хотите отслеживать FID с помощью Google Analytics, определенно рекомендуется этот подход.

Кто должен отслеживать FID?

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

JavaScript-приложения на стороне сервера (SSR)

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

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

Чтобы было ясно, абсолютно возможно создать приложение на стороне сервера, которое также быстро становится интерактивным. SSR сама по себе неплохая картина; проблема возникает, когда разработчики оптимизируют процесс быстрого рисования, а затем игнорируют интерактивность. Именно здесь отслеживание FID может быть особенно привлекательным!

Сайты с большим количеством сторонних фреймов (iframes)

Сторонние объявления и социальные виджеты имеют историю, в которой они не особо внимательны к своим страницам. Они склонны выполнять дорогостоящие операции DOM в главном потоке главной страницы, не обращая внимания на то, как это повлияет на пользователя.

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

Перспективы

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

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

Оригинал статьи (англ.): https://developers.google.com/web/updates/2018/05/first-input-delay