Все мы знаем, как важно произвести хорошее первое впечатление. Это важно при знакомстве с новыми людьми, а также при приобретении опыта в Интернете.
В Интернете хорошее первое впечатление может сыграть решающую роль в том, станет ли кто-то лояльным пользователем или уйдет и никогда не вернется. Вопрос в том, что производит хорошее впечатление и как измерить, какое впечатление вы, скорее всего, произведете на своих пользователей?
В Интернете первое впечатление может принимать самые разные формы: у нас есть первое впечатление о дизайне и визуальной привлекательности сайта, а также первое впечатление о его скорости и отзывчивости.
Хотя трудно измерить, насколько пользователям нравится дизайн сайта с помощью веб-API, измерить его скорость и отзывчивость невозможно!
Первое впечатление пользователей о том, насколько быстро загружается ваш сайт, можно измерить с помощью First Contentful Paint (FCP) . Но то, насколько быстро ваш сайт может отображать пиксели на экране, — это лишь часть истории. Не менее важно то, насколько отзывчив ваш сайт, когда пользователи пытаются взаимодействовать с этими пикселями!
Метрика First Input Delay (FID) помогает измерить первое впечатление пользователя об интерактивности и отзывчивости вашего сайта.
Что такое ФИД?
FID измеряет время с момента, когда пользователь впервые взаимодействует со страницей (то есть, когда он нажимает ссылку, нажимает кнопку или использует собственный элемент управления на основе JavaScript) до момента, когда браузер фактически может начать обработку. обработчики событий в ответ на это взаимодействие.
Что такое хороший показатель FID?
Чтобы обеспечить удобство взаимодействия с пользователем, сайты должны стремиться к тому, чтобы задержка первого ввода составляла 100 миллисекунд или меньше. Чтобы гарантировать достижение этой цели для большинства ваших пользователей, хорошим порогом для измерения является 75-й процентиль загрузки страниц, сегментированный по мобильным и настольным устройствам.
ФИД в деталях
Как разработчики, пишущие код, реагирующий на события, мы часто предполагаем, что наш код будет запущен немедленно — как только событие произойдет. Но, как пользователи, мы все часто сталкивались с противоположным явлением: мы загружали веб-страницу на свой телефон, пытались с ней взаимодействовать, а затем расстраивались, когда ничего не происходило.
В общем, задержка ввода (также известная как задержка ввода) происходит потому, что основной поток браузера занят чем-то другим, поэтому он не может (пока) ответить пользователю. Одна из распространенных причин, по которой это может произойти, заключается в том, что браузер занят анализом и выполнением большого файла JavaScript, загруженного вашим приложением. Пока он это делает, он не может запускать какие-либо прослушиватели событий, поскольку загружаемый им JavaScript может приказать ему сделать что-то еще.
Рассмотрим следующую временную шкалу типичной загрузки веб-страницы:
На приведенной выше визуализации показана страница, которая отправляет пару сетевых запросов на ресурсы (скорее всего, файлы CSS и JS) и — после завершения загрузки этих ресурсов — они обрабатываются в основном потоке.
Это приводит к тому, что основной поток на мгновение оказывается занят, на что указывают блоки задач бежевого цвета.
Длительные задержки первого ввода обычно возникают между первой отрисовкой содержимого (FCP) и временем взаимодействия (TTI) , поскольку страница отобразила часть своего содержимого, но еще не является надежно интерактивной. Чтобы проиллюстрировать, как это может произойти, на временную шкалу добавлены FCP и TTI:
Возможно, вы заметили, что между FCP и TTI проходит довольно много времени (включая три длительные задачи ), если пользователь попытается взаимодействовать со страницей в течение этого времени (например, нажав на ссылку), произойдет задержка. между моментом получения клика и моментом, когда основной поток может ответить.
Представьте, что произойдет, если пользователь попытается взаимодействовать со страницей в начале самой длинной задачи:
Поскольку ввод происходит в то время, когда браузер выполняет задачу, ему приходится ждать завершения задачи, прежде чем он сможет ответить на ввод. Время ожидания — это значение 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 с помощью следующих инструментов.
Полевые инструменты
- Отчет об опыте использования Chrome
- Статистика PageSpeed
- Search Console (отчет «Основные веб-показатели»)
- JavaScript-библиотека
web-vitals
Измерение 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 .