Пользователь в центре внимания! Модель RAIL

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

Взаимодействуя с приложением, пользователь чаще всего:
  • ждёт, пока загрузится страница,
  • смотрит на анимацию,
  • скроллит,
  • нажимает на иконку,
  • наблюдает, как загружаются элементы навигации.
Все действия с приложением можно разделить на четыре группы: Response (отклик), Animation (анимация), Idle (ожидание, простой), Load (загрузка). Модель RAIL опирается на эти четыре группы действий и позволяет посмотреть на производительность глазами пользователей.

Время отклика — скорость реакции на ввод 100 миллисекунд и 60fps

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

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

Для анимации это значение еще меньше. Для того чтобы анимация выглядела плавной, вам нужно показать пользователю 60 кадров анимации в секунду. Т. е 16,6 миллисекунд на 1 кадр. Поскольку браузеру нужно время для отрисовки нового кадра, ваш код должен исполнится до того, как достигнет отметки в 16,6 миллисекунды. Скоро на рынок выйдут устройства с частотой 120fps,  уже существуют решения и для оптимизации производительности рендеринга на 120fps. Но пока подавляющее большинство устройств работает с 60fps.

Виталий Фридман советует ориентироваться на самые пессимистичные сценарии в производительности, выжимать максимум из дизайна интерфейса и разумно использовать время простоя (см. idlize и idle-until-urgent).

FID < 100ms, TTI < 5s для 3G соединения и индекс скорости < 3s, бюджет критического размера файла <170 КБ (при сжатии gzip)

Время первой отрисовки и интерактивность (Time to interactive — TTI) не должно превышать 5 с, а для повторных посещений — до 2 с. Достичь этого непросто. Но нужно стремиться к максимально содержательной отрисовке (LCP) за <2,5c, минимизировать общее время блокировки (TBT) и Cumulative Layout Shift — CLS. Об этих показателях мы говорили в прошлом письме.

Не забывайте, что при улучшении производительности стоит ориентироваться на самые пессимистичные сценарии: недорогие устройства и медленное соединение. Например, Moto G4 на Android в медленной сети 3G с эмуляцией RTT 400 мс и скоростью передачи 400 кбит/с. При таких условиях приемлемая задержка первого входа составляет <100−70 мс.

Здесь есть два основных ограничения. С одной стороны — ограничения связанные с  особенностями протокола  TCP. Скорость передачи данных сразу после установки соединения  небольшая. Первые 14 КБ HTML — 10 TCP-пакетов, каждый по 1460 байт, что составляет около 14,25 КБ
С TCP соединениями мы начинаем с небольшого окна перегрузки и удваиваем его на каждом круге. В самом первом круге мы можем поместить 14 КБ. Источник: High Performance Browser Networking, Илья Григорик. (Увеличить)
Примечание: поскольку TCP обычно в значительной степени недоиспользует сетевое соединение, Google разработал TCP Bottleneck Bandwidth и RRT (BBR), алгоритм управления потоком TCP с контролируемой задержкой TCP. Разработанный для современного Интернета, он реагирует на фактические перегрузки, а не потери пакетов, как это делает TCP. Он значительно быстрее, с большей пропускной способностью и меньшей задержкой — алгоритм работает иначе.
С другой стороны, есть аппаратные ограничения на память и ЦП из-за парсинга и выполнения JavaScript (мы поговорим о них подробнее позже). Если вы хотите достичь целей, изложенных в первом абзаце, вы должны учитывать критический бюджет размера файла для JavaScript. И здесь мнения о размере бюджета расходятся. В значительной степени этот показатель зависит от характера вашего проекта. На телефоне среднего класса браузер потратит потратит около 1 секунды на анализ и компиляцию JS-файла размером 170Кб, сжатого с помощью gzip. Если предположить, что 170 КБ превратятся в 700КБ при разархиваровании, то можно и не мечтать о быстром взаимодействии с пользователем на Moto G4/G5 Plus.

Если ваши годовые показатели производительности остаются стабильными, это тревожный звонок! В этом случае вы не обеспечиваете стабильность работы сервиса, вы регрессируете, так как среда продолжает улучшаться (подробности в посте Жиля Дюбука). Например, сайт Википедии в 2020 стал исполнять код на 19% быстрее.
Если вы ориентируетесь на растущие рынки, такие как Юго-Восточная Азия, Африка или Индия, вам придется иметь дело с другим набором ограничений. Адди Османи в своей статье рассказал, как работать с устройствами за 20 $ там, где нет высококачественных сетей и стоимость передачи мобильных данных слишком высока.

В этих случаях Османи предлагает использовать бюджет PRPL-30 (30KB gzipped + minified initial bundle).
Можно выйти за рекомендуемые рамки. Например, установить бюджеты производительности на основе действий основного потока браузера (то есть времени отрисовки до начала рендеринга) или отслеживать нагрузку на внешний процессор. Для контроля за бюджетами используйте инструменты Caliber, SpeedCurve и Bundlesize, их можно интегрировать и в процесс сборки.

Вообще, бюджет производительности не должен быть фиксированным значением. Это нормально, когда данный показатель изменяется, адаптируясь к параметрам сетевого подключения. Но стоит помнить: чем медленнее подключение, тем «дороже» полезная нагрузка (payload), независимо от того, как используются данные.
Чтобы следить за текущим состоянием производительности, настройте панели мониторинга с графиками, отображающими размеры сборки. Для этого используйте панель управления SiteSpeed.io, SpeedCurve и Caliber. Еще больше инструментов можно найти на perf.rocks.
Примечание: Установка таких жестких бюджетов может показаться странной во времена широко распространенного HTTP/2, предстоящих 5G и HTTP/3, быстро развивающихся мобильных телефонов и процветающих SPA. Но вы не можете повлиять на контекст пользователя: непредсказуемость поведения сетей, проблемы с оборудованием и просто грабительские тарифы на передачу данных в роуминге.