RAIL – это ориентированная на пользователя модель производительности, которая позволяет структурировать подход к оценке производительности. Модель разбивает действия пользователя на ключевые (например, нажатие, прокрутка, загрузка) и помогает определить цели по эффективности для каждого из них.
RAIL – это аббревиатура, которая обозначает четыре аспекта жизненного цикла веб-приложения: ответ (Response), анимация (Animation), бездействие (Idle) и загрузка (Load). Пользователи по-разному оценивают производительность в каждом из этих контекстов, поэтому цели по производительности определяются на основе контекста и UX-исследований того, как пользователи воспринимают задержки.
Пользователь в центре внимания
Пользователи должны быть в центре внимания при работе над производительностью. В таблице ниже описаны ключевые показатели того, как пользователи воспринимают задержки в работе:
Восприятие пользователем задержек в работе| 0–16 мс | Пользователи очень хорошо замечают движение и не любят, когда анимация не плавная. Анимация воспринимается как плавная, если за секунду отрисовывается 60 новых кадров. Это 16 мс на кадр, включая время, необходимое браузеру для отрисовки нового кадра на экране. Таким образом, у приложения есть около 10 мс на создание кадра. |
| 0–100 мс | Если ответ на действия пользователя происходит в течение этого времени, у него возникает ощущение, что результат появляется мгновенно. Если задержка будет больше, связь между действием и реакцией будет потеряна. |
| 100–1000 мс | В этом окне все кажется частью естественного и непрерывного выполнения задач. Для большинства пользователей загрузка страниц или изменение представлений – это задача. |
| 1000 мс и более | Если задержка превышает 1000 миллисекунд (1 секунду), пользователи теряют концентрацию на выполняемой задаче. |
| 10 000 мс или больше | Если задержка превышает 10 000 миллисекунд (10 секунд), пользователи начинают раздражаться и, скорее всего, откажутся от выполнения задачи. Они могут вернуться позже, а могут и не вернуться. |
Цели и рекомендации
В контексте RAIL термины цели и рекомендации имеют определенные значения:
Цели. Ключевые показатели эффективности, связанные с удобством для пользователей. Например, отрисовка по нажатию должна занимать менее 100 миллисекунд. Поскольку человеческое восприятие относительно постоянно, эти цели вряд ли изменятся в ближайшее время.
Guidelines. Рекомендации, которые помогут вам достичь целей. Они могут зависеть от текущего оборудования и условий сетевого подключения и поэтому со временем меняться.
Отклик: обработка событий менее чем за 50 мс
Цель. Завершать переход, инициированный пользователем, в течение 100 мс, чтобы у пользователя возникало ощущение мгновенного отклика.
Рекомендации
Чтобы обеспечить видимый ответ в течение 100 мс, обрабатывайте события пользовательского ввода в течение 50 мс. Это относится к большинству входных данных, таких как нажатие кнопок, переключение элементов управления формой или запуск анимации. Это не относится к перетаскиванию и прокрутке.
Хотя это может показаться нелогичным, не всегда правильно реагировать на ввод пользователя немедленно. Вы можете использовать это окно в 100 мс для выполнения других ресурсоемких задач, но будьте осторожны, чтобы не заблокировать пользователя. Если возможно, выполняйте работу в фоновом режиме.
Если действие занимает больше 50 мс, всегда предоставляйте обратную связь.
50 или 100 мс?
Цель – реагировать на действия пользователя менее чем за 100 мс. Почему же бюджет составляет всего 50 мс? Это связано с тем, что помимо обработки ввода обычно выполняется и другая работа, которая занимает часть времени, доступного для приемлемого ответа на ввод. Если приложение выполняет работу рекомендуемыми фрагментами по 50 мс во время простоя, это означает, что ввод может быть поставлен в очередь на срок до 50 мс, если он происходит во время одного из этих фрагментов работы. С учетом этого можно предположить, что на обработку ввода остается только 50 мс. Этот эффект визуализирован на диаграмме ниже, которая показывает, как входные данные, полученные во время простоя, ставятся в очередь, сокращая доступное время обработки:
Анимация: создание кадра за 10 мс
Цели
Каждый кадр анимации должен создаваться не более чем за 10 мс. Технически максимальный бюджет для каждого кадра составляет 16 мс (1000 мс / 60 кадров в секунду ≈ 16 мс), но браузерам требуется около 6 мс для рендеринга каждого кадра, отсюда и рекомендация 10 мс на кадр.
Стремитесь к визуальной плавности. Пользователи замечают, когда частота кадров меняется.
Рекомендации
В критических точках, таких как анимация, ключ в том, чтобы ничего не делать там, где вы может, и абсолютный минимум там, где вы не можете. По возможности используйте время отклика в 100 мс для предварительного расчета ресурсоемких задач, чтобы повысить вероятность достижения частоты 60 кадров/с.
Ознакомьтесь с различными стратегиями оптимизации анимации в статье Эффективность отрисовки.
- Визуальные анимации, такие как появление и исчезновение, промежуточные кадры и индикаторы загрузки.
- Прокручиваю. Это относится и к случаям, когда пользователь начинает прокрутку, а затем отпускает экран, и страница продолжает прокручиваться.
- Перетаскивание. Анимация часто следует за действиями пользователя, такими как панорамирование карты или масштабирование щипком.
Бездействие: максимально увеличить время бездействия
Цель. Максимально увеличить время бездействия, чтобы повысить вероятность того, что страница отреагирует на действия пользователя в течение 50 мс.
Рекомендации
Используйте время простоя для выполнения отложенной работы. Например, при первоначальной загрузке страницы загружайте как можно меньше данных, а затем используйте время простоя для загрузки остальных.
Выполняйте работу во время бездействия за 50 мс или меньше. Если это займет больше времени, приложение может не успеть ответить на действия пользователя в течение 50 мс.
Если пользователь взаимодействует со страницей во время выполнения фоновых задач, его действия должны иметь наивысший приоритет и прерывать фоновые задачи.
Загрузка: контент должен загружаться и становиться интерактивным менее чем за 5 секунд
Если страницы загружаются медленно, внимание пользователя рассеивается, и он может решить, что сайт не работает. На быстро загружающихся сайтах средняя продолжительность сеанса выше, показатель отказов ниже, а видимость объявлений выше.
Цели
Оптимизируйте скорость загрузки с учетом возможностей устройств и сетей, которыми пользуются ваши посетители. В настоящее время хорошим показателем для первой загрузки считается интерактивность страницы в течение 5 секунд или менее на мобильных устройствах среднего уровня с медленным подключением 3G.
Для последующих загрузок хорошим показателем считается время менее двух секунд.
Инструкции
Протестируйте скорость загрузки на мобильных устройствах и сетевых подключениях, которые чаще всего используют ваши посетители. Чтобы узнать, какие типы подключения используют ваши посетители, воспользуйтесь Chrome User Experience Report. Если у вас нет таких данных, то, согласно отчету The Mobile Economy 2019, в качестве базового варианта можно использовать телефон Android среднего уровня, например Moto G4, и медленную сеть 3G (время задержки – 400 мс, скорость передачи данных – 400 кбит/с). Такая комбинация доступна в WebPageTest.
Помните, что даже если на устройстве пользователя указано, что оно подключено к сети 2G, 3G или 4G, на самом деле эффективная скорость подключения часто значительно ниже из-за потери пакетов и колебаний в сети.
Чтобы у пользователя возникло ощущение, что страница загрузилась полностью, не обязательно загружать все элементы за пять секунд. Попробуйте использовать отложенную загрузку изображений, разделение кода пакетов JavaScript и другие методы оптимизации, описанные на сайте web.dev.
Инструменты для измерения RAIL
Существует несколько инструментов, которые помогут вам автоматизировать измерения RAIL. Выбор зависит от того, какая информация вам нужна и какой рабочий процесс вы предпочитаете.
Инструменты разработчика в Chrome
Инструменты разработчика Chrome позволяют подробно анализировать все, что происходит во время загрузки страницы или работы. Чтобы ознакомиться с интерфейсом панели Производительность, прочитайте статью Как начать анализ производительности во время выполнения.
Особенно полезны следующие функции:
Ограничьте производительность ЦП, чтобы имитировать менее мощное устройство.
Ограничьте пропускную способность сети, чтобы имитировать медленное подключение.
Просмотр действий в основном потоке позволяет увидеть все события, которые произошли в основном потоке во время записи.
Посмотрите действия основного потока в таблице, чтобы отсортировать их по времени выполнения.
Анализируйте количество кадров в секунду (FPS), чтобы понять, насколько плавно воспроизводится анимация.
Отслеживайте загрузку ЦП, размер кучи JS, узлы DOM, макеты в секунду и другие показатели в реальном времени с помощью Performance Monitor.
Визуализируйте сетевые запросы, которые произошли во время записи, с помощью раздела Сеть.
Делайте скриншоты во время записи, чтобы точно воспроизвести, как выглядела страница во время загрузки страницы, анимации и т. д.
Просмотр взаимодействий позволяет быстро определить, что произошло на странице после того, как пользователь с ней взаимодействовал.
Выявляйте проблемы производительности прокрутки в реальном времени, выделяя страницу каждый раз, когда срабатывает потенциально проблемный прослушиватель.
Просматривайте события отрисовки в реальном времени, чтобы выявлять ресурсоемкие события, которые могут снижать производительность анимации.
Lighthouse
Lighthouse доступен в инструментах разработчика Chrome, в PageSpeed Insights, в виде расширения Chrome, модуля Node.js и в WebPageTest. Вы указываете URL, а инструмент имитирует устройство среднего уровня с медленным подключением 3G, выполняет ряд проверок страницы и предоставляет отчет о скорости загрузки, а также рекомендации по ее увеличению.
Обратите внимание на следующие аспекты:
Ответ
Максимальная потенциальная задержка после первого ввода. Оценка времени, которое потребуется приложению, чтобы ответить на действия пользователя, на основе времени простоя основного потока.
Не использует пассивные прослушиватели для повышения производительности прокрутки.
Общее время блокировки. Общее время, в течение которого страница не реагирует на действия пользователя, например клики мышью, нажатия на экран или клавиши.
Время загрузки для взаимодействия. Показывает, когда пользователь может взаимодействовать со всеми элементами страницы.
Загрузка
Не регистрирует сервис-воркер, который управляет страницей и start_url. Сервис-воркер может кешировать часто используемые ресурсы на устройстве пользователя, сокращая время, затрачиваемое на получение ресурсов по сети.
Отложите загрузку скрытых изображений. Отложите загрузку изображений вне экрана до тех пор, пока они не понадобятся.
Задайте правильные размеры изображений. Не показывайте изображения, которые значительно больше, чем размер, отображаемый в области просмотра на мобильном устройстве.
Уменьшите размер дерева DOM. Чтобы сократить расход трафика, передавайте только те узлы DOM, которые необходимы для отрисовки страницы.
WebPageTest
WebPageTest – это инструмент для оценки эффективности сайтов, который использует реальные браузеры для доступа к веб-страницам и сбора показателей времени. Введите URL на странице webpagetest.org/easy, чтобы получить подробный отчет о скорости загрузки страницы на реальном устройстве Moto G4 с медленным подключением 3G. Вы также можете настроить его так, чтобы он включал аудит Lighthouse.
Сводка
Модель RAIL позволяет взглянуть на взаимодействие пользователя с сайтом как на путь, состоящий из отдельных взаимодействий. Узнайте, как пользователи воспринимают ваш сайт, чтобы задать цели по эффективности, которые больше всего влияют на удобство работы.
Пользователь в центре внимания
Реагируйте на действия пользователя менее чем за 100 мс.
При анимации или прокрутке кадр должен создаваться менее чем за 10 мс.
Максимально увеличьте время бездействия основного потока.
Загрузка интерактивного контента менее чем за 5000 мс.