Представляем RAIL: ориентированная на пользователя модель производительности

0 ∞

Немногие из нас располагают временем, которое можно уделить оптимизации. Поэтому нужны критерии, которые помогут решить, что важно оптимизировать.

Команда Chrome придумала модель, которая делает интересы пользователей главными в вопросах производительности. Мы называем это моделью RAIL.

  • RAIL - это модель разбивки опыта пользователя на ключевые действия (например, нажатие, перетаскивание, прокрутка, загрузка).
  • Она устанавливает целевые показатели производительности для этих действий (например, время до первого отображения менее 100 миллисекунд).
  • RAIL предоставляет структуру производительности, поэтому дизайнеры и разработчики могут ориентироваться на нее.

Прежде чем подробно рассмотреть RAIL отступим на шаг назад и посмотрим, с чего все начинается.

Содержание

"Медленный"

DOM становится медленным? Как насчет загрузки <script> в <head>? JavaScript анимации медленнее, чем CSS? Длительность операции в 20 миллисекунд слишком велика? Как насчет 0,5 секунды?

Что на самом деле означает «медленный»?

Сложно объективно сказать, что такое медленное или быстрое. Например, для кода, выполняющегося во время простоя, обработки нажатия или в игровом цикле, предъявляются разные требования к производительности.
Мы создаем код, как и все аспекты UX, для наших пользователей. Номер один в ТОП-10 принципов, которыми руководствуется Google - «Центр внимания на пользователе, а все остальное отталкивается от этого».

Поэтому мы должны спросить: «Что чувствует пользователь, когда он взаимодействует с функционалом, который мы создаем?»

Поместим пользователя в центр производительности

Существуют академические исследования HCI по этой теме. На их основе можно сделать выводы, что:

  • 100 миллисекунд. Реагируйте на действие пользователя в течение этого временного, и он будет чувствовать, что результат мгновенный. Если дольше, то эта связь между действием и реакцией прерывается.
  • 1 секунда. За это время все события воспринимаются как непрерывная последовательность. Если выйти за этот предел, пользователь теряет сосредоточенность на задаче, которую он выполнял.
  • 16 миллисекунд. Учитывая экран, который обновляется 60 раз в секунду, это оптимальное время для построения одного кадра.

Теперь нужно сопоставить эти значения с реальностью. Рассмотрим типичное взаимодействие пользователя с веб-страницей.

Во время сеанса происходит несколько взаимодействий:

  • ожидание загрузки страницы;
  • наблюдение за анимацией;
  • прокрутка страницы;
  • нажатие иконки;
  • наблюдение за переходом на новую страницу;
  • ожидание загрузки страницы;
  • наблюдение за анимацией;
  • прокрутка страницы.
Представляем инструмент для анализа изображений Website Speed Test

Разбивка этих действий даст нам это:

Разбивка этих действий даст нам это:

Каждый из блоков разного цвета обозначает тип действия. Всего их четыре. И в названии RAIL тоже четыре буквы. Любопытно.

Мы можем разбить взаимодействие пользователей на четыре отдельные области. В Google мы называем эти области RAIL. Каждая из них имеет свои целевые показатели производительности, которые основаны на порогах человеческого восприятия.

Разбивка этих действий даст нам это: - 2

Модель производительности RAIL

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

Модель производительности RAIL

Подробно рассмотрим каждую из этих областей.

1. Отклик

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

Отклик определяется задержкой ввода: интервалом между прикосновением пальца к экрану пользовательского устройства и отображением пикселей на этом экране.

Основное взаимодействие отклика:

  • Нажатие - когда пользователь кликает или нажимает на кнопку, иконку (например, чтобы открыть экранную навигацию).

Чтобы оперативно реагировать, нужно:

  • Обеспечить обратную связь менее чем через 100 миллисекунд после первоначального ввода.
  • В идеале обратная связь должна представлять собой желаемое состояние. Но если на него требуется много времени, тогда должен выводиться индикатор загрузки или графическое отображение активного состояния. Главное - уведомить пользователя о том, что запрошенное им действие происходит.
Чек-лист мероприятий по улучшению производительности сайта

2. Анимация

Это основа современных веб-приложений, от прокрутки до просмотра переходов. Нужно разумно подходить к тому, что мы делаем в этот период времени. Пользователь часто будет взаимодействовать напрямую и заметит, если изменится частота кадров. Тем не менее, пользователь ожидает очень плавной обратной связи.

Анимация бывает:

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

Каждый кадр анимации должен быть завершен менее чем за 16 миллисекунд, тем самым обеспечивая частоту кадров 60 кадров / с (1 секунда ÷ 60 = 16,6 миллисекунды).

3. Простой

Создание программ, которые имеют хорошее время отклика и эффективную анимацию, часто требует отсрочки в выполнении задач приложением. Процессы, которые должны быть завершены, вероятно, не должны выполняться в критический временной интервал, как и во время «отклика» или «загрузки». Загрузка функции комментариев, инициализация компонентов, поиск и сортировка данных, а также передача аналитической информации - это неосновные элементы, которые нужно выполнять, когда браузер простаивает.

Чтобы разумно использовать время простоя, задачи должны быть сгруппированы в блоки по 50 миллисекунд. Если пользователь начнет взаимодействие во время выполнения этих задач, то нужно обеспечить ответ не позже чем, чем через 100 миллисекунд. А также не застрять, ожидая, когда завершится двухсекундная операция рендеринга.

4. Загрузка

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

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

Целевые показатели производительности

Производительность – это искусство избежать работы. А когда она неизбежна, сделать работу как можно более эффективной.

Рассмотрев этапы взаимодействия RAIL, подытожим цели:

ОткликАнимацияПростойЗагрузка страницы
От нажатия до отображения - меньше 100 миллисекунд.Каждый кадр должен завершаться менее, чем за 16 миллисекунд.Используйте время простоя для планирования неосновных задач.Достижение цели "отклик" во время полной загрузки.
От перетаскивания до отображения - меньше 16 миллисекунд.Разбейте эти задачи на фрагменты по 50 миллисекунд.Получение первого значимого отображения до 1000 миллисекунд.
HTTP/2: предыстория, преимущества производительности и реализации

Примечания по измерению

Вот несколько полезных советов по измерению производительности:

  • Замеры показателей на MacBook Pro или другом подобном устройстве не дадут актуальных данных. Обычные телефоны могут быть в десять раз медленнее, чем компьютеры!
  • Nexus 4 - это хорошее устройство среднего класса, которое можно использовать.
  • Для дросселирования сети рекомендуется «стандартный 3G».
  • Изучите аналитику, чтобы узнать, как работают ваши пользователи. Затем можно имитировать опыт 90-процентной выборки для тестирования.

Как насчет заряда батареи и памяти

Достигнув перечисленных выше целей, но израсходовав всю доступную память пользовательского устройства и 90% заряда батареи, вы не будете соответствовать концепции ориентации на пользователя.

Мы еще не знаем, как замерить эти показатели, но в один прекрасный день в RAIL могут добавиться буквы B (батарея) и M (память), превратив его в BLAIMR, PRIMAL или что-то еще.

Влияние бизнеса на RAIL

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

К счастью, многие крупные компании предоставляют цифры, на которые можно ориентироваться:

  • Google: на 2% медленнее = на 2% меньше поисковых запросов на пользователя.
  • Yahoo: на 400 миллисекунд быстрее = на 9% больше трафика
  • AOL: более быстрые страницы = больше просмотров страниц
  • Amazon: на 100 миллисекунд быстрее = на 1% больше доход.
  • Aberdeen Group: на 1 секунду медленнее = на 11% меньше просмотров страниц, на 7% ниже конверсия.
  • Google использует скорость сайта в качестве фактора ранжирования.

Заключение

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

Ресурсы

Если вы хотите получить дополнительную информацию по RAIL, ознакомьтесь с этими материалами:

Доклады по RAIL

Руководства и документация

  • «Оптимизация производительности», Web Fundamentals, Google Developers.
  • «Оптимизация рендеринга в браузере» (курс), Udacity.
  • «Профиль» (производительность), Google Web Tools, Google Developers.
  • «Модель производительности RAIL», Web Fundamentals, Google Developers.

Академические исследования по воспринимаемой производительности

  • 1968: «Время отклика в транзакциях взаимодействия человек-компьютер» (PDF), Роберт Б. Миллер, Компьютерная конференция Fall Joint 1968.
  • 1991: «Время отклика: 3 важных предела», Якоб Нильсен, Nielsen Norman Group.
  • 2004: «Исследование на тему допустимого времени ожидания: Как долго будут ждать веб-пользователи?» (PDF), Фиона Фуй-Хун Нах, Behaviour and Information Technology, 2004.
  • 2005: «Взаимодействие в 4-секундных всплесках: Фрагментированная природа ресурсов внимания в мобильной HCI» (PDF), Антти Оульсвирта, Сакари Тамминен, Вирпи Рото и Яана Куорелахти, Interruptions in Human Computer Interaction.
  • 2006: «Количественный интерактивный пользовательский опыт для тонких клиентов» (PDF), Нирадж Толя, Дэвид Г. Андерсен и М. Сатьянараяна, The Internet Suspend/Resume Project, Carnegie Mellon.
  • 2012: «Характеризация использования Интернета на смартфонах» (PDF), Чад К. Тосселл, Филипп Кортум, Ахмад Рахмати, Клейтон Шепард, Линь Чжун, Конференция по человеческим факторам в вычислительных системах.
  • 2011: «Эксперименты с тактильной задержкой ответа в сенсорном взаимодействии: Два подхода» (PDF), Топи Кааресоя, Ева Хогган, Эмилия Анттила, Human-Computer Interaction: INTERACT 2011.