RAIL — это ориентированная на пользователя модель оценки производительности, которая предоставляет структуру для анализа производительности. Модель разбивает пользовательский опыт на ключевые действия (например, касание, прокрутка, загрузка) и помогает определить целевые показатели производительности для каждого из них.
Аббревиатура RAIL обозначает четыре различных аспекта жизненного цикла веб-приложения: отклик, анимация, простой и загрузка. Пользователи предъявляют разные требования к производительности для каждого из этих контекстов, поэтому целевые показатели производительности определяются на основе контекста и UX-исследований того, как пользователи воспринимают задержки .
Сосредоточьтесь на пользователе.
Сделайте пользователей центром ваших усилий по повышению производительности. В таблице ниже описаны ключевые показатели того, как пользователи воспринимают задержки в работе:
| от 0 до 16 мс | Пользователи исключительно хорошо отслеживают движение, и им не нравится, когда анимация не плавная. Они воспринимают анимацию как плавную, если каждую секунду отрисовывается 60 новых кадров. Это 16 мс на кадр, включая время, необходимое браузеру для отображения нового кадра на экране, в результате чего приложению требуется около 10 мс для создания кадра. |
| от 0 до 100 мс | Если реагировать на действия пользователя в течение этого временного интервала, у него создается ощущение немедленного результата. Если же интервал больше, связь между действием и реакцией нарушается. |
| от 100 до 1000 мс | В этом временном окне все выглядит как естественная и непрерывная последовательность задач. Для большинства пользователей веб-сайтов загрузка страниц или смена ракурсов представляют собой отдельную задачу. |
| 1000 мс или более | По истечении 1000 миллисекунд (1 секунды) пользователи теряют концентрацию на выполняемой задаче. |
| 10000 мс или более | По истечении 10000 миллисекунд (10 секунд) пользователи испытывают разочарование и, скорее всего, бросят выполнение задач. Они могут вернуться к ним позже, а могут и не вернуться. |
Цели и руководящие принципы
В контексте железнодорожной отрасли термины «цели» и «руководящие принципы» имеют специфическое значение:
Цели . Ключевые показатели эффективности, связанные с пользовательским опытом. Например, рисование касанием менее чем за 100 миллисекунд. Поскольку человеческое восприятие относительно постоянно, эти цели вряд ли изменятся в ближайшее время.
Рекомендации . Предложения, которые помогут вам достичь целей. Они могут быть специфичны для текущих условий работы оборудования и сетевого подключения и, следовательно, могут меняться со временем.
Ответ: обработка событий менее чем за 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-соединением .
При последующих загрузках хорошей целью является загрузка страницы менее чем за 2 секунды.
Руководящие принципы :
Проверьте производительность вашего сайта на мобильных устройствах и сетевых подключениях, которые наиболее распространены среди ваших пользователей. Вы можете использовать отчет Chrome User Experience Report , чтобы узнать распределение подключений ваших пользователей. Если данные для вашего сайта недоступны, в отчете The Mobile Economy 2019 рекомендуется использовать в качестве базового показателя смартфон среднего класса на базе Android, например, Moto G4, и медленную сеть 3G (определяемую как 400 мс RTT и скорость передачи данных 400 кбит/с). Эта комбинация доступна на WebPageTest .
Следует помнить, что, хотя устройство обычного пользователя мобильной связи может показывать, что оно подключено к сети 2G, 3G или 4G, в действительности эффективная скорость соединения часто значительно ниже из-за потери пакетов и колебаний сети.
Необязательно загружать всё менее чем за 5 секунд, чтобы создать впечатление полной загрузки. Рассмотрите отложенную загрузку изображений , разделение кода на пакеты JavaScript и другие оптимизации, предложенные на web.dev .
Инструменты для измерения рельсов
Существует несколько инструментов, которые помогут автоматизировать измерения на железнодорожных путях. Выбор инструмента зависит от типа необходимой информации и предпочтительного рабочего процесса.
Инструменты разработчика Chrome
Инструменты разработчика Chrome предоставляют подробный анализ всего, что происходит во время загрузки или выполнения страницы. См. раздел «Начало работы с анализом производительности во время выполнения» , чтобы ознакомиться с пользовательским интерфейсом панели «Производительность» .
Следующие функции инструментов разработчика особенно актуальны:
Снизьте производительность процессора , чтобы имитировать работу менее мощного устройства.
Чтобы имитировать более медленные соединения, ограничьте скорость сети .
Чтобы просмотреть все события, произошедшие в основном потоке во время записи, перейдите в раздел «Активность основного потока» .
Просматривайте основные действия в таблице, чтобы отсортировать их по тому, какие из них заняли больше всего времени.
Проанализируйте количество кадров в секунду (FPS) , чтобы оценить, действительно ли ваши анимации работают плавно.
С помощью монитора производительности в режиме реального времени отслеживайте загрузку ЦП, размер кучи JavaScript, количество узлов DOM, количество макетов в секунду и многое другое .
В разделе «Сеть» можно визуализировать сетевые запросы , которые происходили во время записи.
Делайте скриншоты во время записи , чтобы в точности воспроизвести, как выглядела страница во время загрузки, запуска анимации и так далее.
Просматривайте данные о взаимодействиях , чтобы быстро определить, что произошло на странице после того, как пользователь взаимодействовал с ней.
Выявляйте проблемы с производительностью прокрутки в режиме реального времени, выделяя страницу всякий раз, когда срабатывает потенциально проблемный обработчик событий.
Просматривайте события отрисовки в режиме реального времени, чтобы выявлять дорогостоящие события отрисовки, которые могут негативно влиять на производительность ваших анимаций.
Маяк
Lighthouse доступен в инструментах разработчика Chrome, в PageSpeed Insights , в виде расширения Chrome, в виде модуля Node.js и в составе WebPageTest. Вы задаете ему URL-адрес, он имитирует устройство среднего класса с медленным 3G-соединением, проводит ряд проверок страницы, а затем предоставляет отчет о производительности загрузки, а также рекомендации по ее улучшению.
Следующие виды аудита особенно актуальны:
Ответ
Максимальная потенциальная задержка первого ввода . Оценивает, сколько времени потребуется вашему приложению для ответа на ввод пользователя, исходя из времени простоя основного потока.
Не использует пассивные обработчики событий для повышения производительности прокрутки .
Общее время блокировки . Измеряет общее время, в течение которого страница не может реагировать на действия пользователя, такие как щелчки мыши, касания экрана или нажатия клавиш клавиатуры.
Время до интерактивности . Показывает, когда пользователь может постоянно взаимодействовать со всеми элементами страницы.
Нагрузка
Не регистрирует сервис-воркер, управляющий параметрами page и start_url . Сервис-воркер может кэшировать общие ресурсы на устройстве пользователя, сокращая время, затрачиваемое на получение ресурсов по сети.
Загрузка страниц на мобильных устройствах происходит недостаточно быстро .
Отложить загрузку изображений, находящихся за пределами видимой области экрана . Отложить загрузку изображений, находящихся за пределами видимой области экрана, до тех пор, пока они не понадобятся.
Правильно подбирайте размер изображений . Не отображайте изображения, размер которых значительно превышает размер, отображаемый в мобильной области просмотра.
Избегайте последовательного выполнения критически важных запросов .
Избегайте чрезмерного размера DOM . Сократите объем сетевого трафика, отправляя только те узлы DOM, которые необходимы для отрисовки страницы.
WebPageTest
WebPageTest — это инструмент для анализа производительности веб-сайтов, который использует реальные браузеры для доступа к веб-страницам и сбора метрик времени загрузки. Введите URL-адрес на webpagetest.org/easy , чтобы получить подробный отчет о скорости загрузки страницы на реальном устройстве Moto G4 с медленным 3G-соединением. Вы также можете настроить его для включения аудита Lighthouse.
Краткое содержание
RAIL — это подход, позволяющий рассматривать пользовательский опыт на веб-сайте как путь, состоящий из отдельных взаимодействий. Понимание того, как пользователи воспринимают ваш сайт, поможет установить цели по производительности, оказывающие наибольшее влияние на пользовательский опыт.
Сосредоточьтесь на пользователе.
Реагировать на ввод пользователя менее чем за 100 мс.
Создание кадра менее чем за 10 мс при анимации или прокрутке.
Максимально увеличить время простоя основного потока.
Загрузка интерактивного контента менее чем за 5000 мс.