Расчётная задержка ввода

Статистически доказано, что если скорость загрузки страницы длится 3 секунды — то 50% пользователей с неё уйдут тут же. С каждой дополнительной секундой отваливаться будет 12%. в результате, мы имеем негативный пользовательский опыт. Он влияет и на поисковые системы, которые фиксируют каждый отказ. Из них, в том числе, складывается позиция сайта при ранжировании. И если речь идёт о продающих сайтах, а таких в сети подавляющее большинство, то это более чем критично. Терять деньги не нравится никому.

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

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

Что такое расчётная задержка ввода и её оптимальные показатели

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

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

RAIL разбивает взаимодействие пользователя на ключевые действия:

•  Запрос

•  Анимация

•  Ожидание

•  Загрузка

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

Модель производительности RAIL рекомендует приложениям реагировать на ввод пользователя в течение 100 миллисекунд. В это же время, целевой показатель Lighthouse определяет оптимальным временную дистанцию в два раза меньше — всего 50 миллисекунд. Это связано с тем, что в дополнение к обработке ввода, браузером выполняется и другая работа. При этом, она также отнимает время, которое требуется для того, чтобы пользователь получил ответ. Стоит учитывать, что человеком этот период ожидания не разделяется на этапы и составляет единое целое. Соответственно, если приложение осуществляет ввод в пределе рекомендованных 50 миллисекунд в режиме простоя, то освободившееся время оно тратит на другие необходимые этапы, которые также требуется осуществить. И у него остаётся только 50 миллисекунд на то, чтобы фактически обработать ввод. Если процессы будут происходить медленнее, то для пользователя это будет ощутимо и он воспримет такую страницу как медленную.

Обратите внимание! При проведении данного аудита посредством Lighthouse стоит учитывать, что он не является полноценным измерителем задержки ввода. С его помощью невозможно выявить сколько действительно времени требуется приложению, чтобы ответить на ввод пользователя. Иными словами, аудит не видит когда для пользователя ответ отобразится визуально. Чтобы это выяснить, эффективно воспользоваться инструментом Chrome DevTools. При этом, измерения должны проводиться с различных типов устройств, разных серверов, а главное — многократно и в абсолютно разное время. Все эти факторы оказывают влияние на скорость задержки ввода. Только используя сложное тестирование и сопоставив данные, можно получить корректные результаты с которыми предстоит работать в дальнейшем.

Какие настройки необходимо выполнить

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

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

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

Исходя из этого, каждый длительность каждого кадра составляет чуть более 16 мс. И при этом, браузеру нужно успеть выполнить в это время другие действия. Таким образом, требуется добиться результата при котором вся выполняемая работа будет умещаться в не более чем в 10 миллисекунд. Если не уложиться в эти рамки, частота кадров будет меньше, а контент начнет дергаться на экране. Пользователи называют данный процесс «подвисанием» и не охотно взаимодействуют с подобными сайтами.

Проработать необходимо сразу несколько основных компонентов:

•  JavaScript

•  Вычисление стилей

•  Расчёт макетов

•  Прорисовку

•  Компоновку

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