Что такое RAIL? Как RAIL помогает в ускорении сайта?

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

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

Рисунок 1 — 4 составляющих модели RAIL

Цели и рекомендации

В контексте RAIL термины цели и руководящие принципы имеют конкретные значения:

• Цели - ключевые показатели эффективности, связанные с пользовательским опытом. Поскольку человеческое восприятие относительно постоянно, эти цели вряд ли скоро изменятся.
• Руководство - рекомендации, которые помогут вам достичь целей. Они могут быть специфическими для текущего оборудования и условий сетевого подключения и, следовательно, могут меняться со временем.

Фокус на пользователя

Сделайте пользователей центром вашей работы. В таблице ниже описаны ключевые показатели того, как пользователи воспринимают задержки производительности:

Пользователи воспринимают задержки производительности по-разному, в зависимости от состояния сети и оборудования. Например, загрузка до 1000 мс возможна на мощном настольном компьютере через быстрое соединение Wi-Fi, поэтому пользователи привыкли к 1000 мс загрузке. Но для мобильных устройств через медленные соединения 3G загрузка в 5000 мс является более реалистичной целью, поэтому мобильные пользователи обычно более терпеливы.

Ответ: обрабатывать события менее чем за 50 мс

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

Руководство:

• Обработайте события пользовательского ввода в течение 50 мс, чтобы обеспечить видимый ответ в течение 100 мс, в противном случае связь между действием и реакцией нарушается. Это относится к большинству входных данных, таких как нажатие кнопок, переключение элементов управления формой, или запуск анимации. Это не касается сенсорных перетаскиваний или свайпов.
• Хотя это может показаться нелогичным, это не всегда правильный ответ, чтобы немедленно ответить на ввод пользователя. Вы можете использовать временную рамку в 100 мс, чтобы сделать другую дорогую работу. Но будьте осторожны, чтобы не затормозить пользователя. Если возможно, делайте работу в фоновом режиме.
• Для действий, которые занимают более 50 мс, всегда оставляйте отзыв.

50 мс или 100 мс?

Цель состоит в том, чтобы реагировать на ввод менее чем за 100 мс, так почему наш лимит времени составляет всего 50 мс? Это связано с тем, что в дополнение к обработке ввода обычно выполняется другая работа, и эта работа занимает часть времени, доступного для приемлемого ответа на ввод. Если приложение выполняет работу за рекомендуемые 50 мс во время простоя, это означает, что ввод может быть поставлен в очередь на срок до 50 мс, если он происходит во время одного из этих кусков работы. Учитывая это, можно предположить, что только оставшиеся 50 мс доступны для фактической обработки ввода. Этот эффект визуализируется на диаграмме ниже, которая показывает, как вход, полученный во время простоя, ставится в очередь, сокращая доступное время обработки:

Рисунок 2 — Как неработающие задачи влияют на лимит ответов на ввод.

Анимация: создать кадр за 10 мс

Цели:

• Создайте каждый кадр в анимации за 10 мс или меньше. Технически, максимальный лимит для каждого кадра составляет 16 мс (1000 мс / 60 кадров в секунду ≈ 16 мс), но браузерам требуется около 6 мс для рендеринга каждого кадра, следовательно, ориентировочное значение составляет 10 мс на кадр.
• Цель визуальной гладкости. Пользователи замечают, когда частота кадров меняется.

Руководство:

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

Бездействие: максимизируем время простоя

Цель: максимально увеличить время простоя, чтобы увеличить вероятность того, что страница откликнется на ввод пользователя в течение 50 мс.

Руководство:

• Используйте простой для завершения отложенной работы. Например, для начальной загрузки страницы загрузите как можно меньше данных, а затем используйте время простоя, чтобы загрузить остальные.
• Выполняйте работу во время простоя за 50 мс или меньше. Если дольше, то вы рискуете вмешаться в способность приложения реагировать на ввод пользователя в течение 50 мс.
• Если пользователь взаимодействует со страницей во время простой работы, пользовательское взаимодействие всегда должно иметь наивысший приоритет и прерывать простую работу.

Загрузка: отображение контента и интерактивность страницы менее, чем за 5 секунд

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

Цели:

• Оптимизация для быстрой загрузки по сравнению с возможностями устройства и сети, которые ваши пользователи используют для доступа к вашему сайту. В настоящее время, хорошей целью для первых загрузок является загрузка страницы и ее интерактивность в течение 5 секунд или менее на мобильных устройствах среднего уровня с медленным подключением 3G. Можете ли вы себе это позволить? Реальные пределы веб-производительности. Но имейте в виду, что эти цели могут меняться со временем.
• Для последующих загрузок, хорошей целью является загрузка страницы менее чем за 2 секунды. Но эта цель также может меняться со временем.

Рисунок 3 — Каждая метрика загрузки представляет отдельную фазу восприятия пользователем процесса загрузки.

Руководство:

• Проверьте производительность загрузки на мобильных устройствах и сетевых подключениях, которые являются общими для ваших пользователей. Если у вашей компании есть информация о том, какие устройства и сетевые подключения используются вашими пользователями, вы можете использовать эту комбинацию и установить собственные целевые показатели производительности загрузки. В противном случае, «Мобильная экономика» предполагает, что хорошей глобальной базовой точкой является Android-телефон среднего уровня, такой как Moto G4, и медленная сеть 3G, определяемая как скорость передачи 400 мс RTT и 400 кбит / с. Эта комбинация доступна на WebPageTest.
• Имейте в виду, что хотя ваше обычное мобильное пользовательское устройство может утверждать, что оно подключено к соединениям 2G, 3G или 4G, в действительности эффективная скорость соединения часто значительно ниже из-за потери пакетов и различий в сети.
• Сосредоточьтесь на оптимизации пути критического рендеринга, чтобы разблокировать рендеринг.
• Вам не нужно загружать все менее чем за 5 секунд, чтобы получить представление о полной загрузке. Включите прогрессивный рендеринг и поработайте в фоновом режиме. Отложите несущественные нагрузки на периоды простоя.
• Факторы, которые влияют на производительность загрузки страницы:
  • Скорость сети и задержка
  • Аппаратное обеспечение (например, более медленные процессоры)
  • Очистка кэша
  • Различия в кешировании L2 / L3
  • Синтаксический Анализ JavaScript

Инструменты для измерения RAIL

Есть несколько инструментов, которые помогут вам автоматизировать измерения RAIL. Какой вы используете, зависит от того, какой тип информации вам нужен, и какой тип рабочего процесса вы предпочитаете:

• Chrome DevTools. Инструменты разработчика, встроенные в Google Chrome. Предоставляет подробный анализ всего, что происходит во время загрузки или запуска вашей страницы.
• Lighthouse. Доступно в Chrome DevTools, как расширение Chrome, как модуль Node.js и в WebPageTest. Вы указываете URL, он имитирует устройство среднего уровня с медленным 3G-соединением, запускает серию аудитов на странице, а затем выдает отчет о производительности нагрузки, а также предложения по улучшению. Также предоставляет аудит для улучшения доступности, упрощения обслуживания страницы, оценивает в качестве прогрессивного веб-приложения и многое другое.
• WebPageTest. Доступно по адресу webpagetest.org/easy. Вы даете ему URL, он загружает страницу на реальном устройстве Moto G4 с медленным 3G-соединением, а затем выдает подробный отчет о загрузке страницы. Вы также можете настроить его для включения аудита Lighthouse.

Разделы ниже более подробно описывают, как использовать каждый инструмент для измерения RAIL.

Chrome DevTools

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

Следующие функции DevTools особенно актуальны:

• Регулируйте свой процессор, чтобы имитировать менее мощное устройство.
• Регулируйте сеть для симуляции медленных соединений.
• Просмотр активности основного потока для просмотра каждого события, которое произошло в основном потоке во время записи.
• Просмотрите основные операции с потоками в таблице, чтобы отсортировать действия по тем, какие больше всего времени.
• Анализируйте кадры в секунду (FPS), чтобы определить, действительно ли ваша анимация работает плавно.
• Мониторинг использования процессора, размера JS, узлов DOM, разметки в секунду и многое другое в режиме реального времени с помощью системного монитора.
• Визуализируйте сетевые запросы, которые произошли во время записи в разделе «Сеть».
• Делайте снимки экрана во время записи, чтобы точно воспроизвести, как выглядела страница при загрузке страницы или при запуске анимации и т.д.
• Просматривайте взаимодействия, чтобы быстро определить, что произошло на странице после того, как пользователь взаимодействовал с ней.
• Найдите проблемы с производительностью прокрутки в режиме реального времени, подсвечивая страницу всякий раз, когда запускается потенциально проблемный слушатель.
• Просматривайте события отображения в режиме реального времени, чтобы определить дорогостоящие события прорисовки, которые могут нанести ущерб производительности вашей анимации.

LightHouse

См. Начало работы, чтобы узнать, как настроить и запустить Lighthouse.

Рисунок 4 — Пример отчёта LightHouse

Следующие проверки особенно актуальны:

• Отклик
  • Предполагаемая задержка ввода. Оценивает, сколько времени потребуется приложению для ответа на ввод пользователя, исходя из времени простоя основного потока.
  • Использует пассивные слушатели событий для улучшения скроллинга.
• Нагрузка
  • Регистрирует сервисного работника. Работник службы может кэшировать общие ресурсы на устройстве пользователя, что сокращает время, затрачиваемое на выборку ресурсов по сети.
  • Загрузка страницы происходит достаточно быстро на 3G.
  • Первое значимое отображение. Измеряет, когда страница выглядит значимо полной.
  • Первый простой процессора. Отмечает первый раз, когда основной поток страницы достаточно спокойный для обработки ввода.
  • Время до интерактивности. Измеряет, когда пользователь может последовательно взаимодействовать со всеми элементами страницы.
  • Индекс скорости восприятия.
  • Сокращение ресурсов, блокирующих отображение.
  • Закадровые изображения. Отложите загрузку закадровых изображений до тех пор, пока они не понадобятся.
  • Правильный размер изображения. Не показывайте изображения, размер которых значительно превышает размер, отображаемый в мобильном экране просмотра.
  • Цепочки критических запросов. Визуализируйте ваш критический путь отображения.
  • Использует HTTP / 2.
  • Оптимизация изображения.
  • Включить сжатие текста.
  • Избегайте огромных сетевых нагрузок.
  • Использует чрезмерный размер DOM. Сократите количество сетевых байтов, отправляя только те узлы DOM, которые необходимы для отображения страницы.

WebPageTest

Введите URL страницы по адресу webpagetest.org/easy, чтобы получить отчет о том, как эта страница загружается на реальном Android-устройстве среднего уровня с медленным 3G-соединением.

Рисунок 5 — Пример отчёта WebPageTest

Перспективы

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

• Фокус на пользователя.
• Ответить на ввод пользователя менее 100 мс.
• Создайте кадр менее чем за 10 мс при анимации или прокрутке.
• Максимизировать время простоя основного потока.
• Загрузка интерактивного контента менее чем за 5000 мс.

Оригинал статьи (англ.): https://developers.google.com/web/fundamentals/performance/rail