- PVSM.RU - https://www.pvsm.ru -
В последнее время публикуется множество советов по оптимизации производительности сайтов. Фразы вроде «DOM работает слишком медленно» или «всегда используйте CSS-анимацию» годятся в виде броских заголовков, но истинное положение вещей содержит различные нюансы.
Представляем статью авторства Пола Айриша и Пола Льюиса из команды Google Chrome о разработанной ими модели оценки производительности сайта. Ее можно с уверенностью назвать User-Centered Performance.
Возьмем, например, время загрузки страницы, что является наиболее популярной темой сегодня. Проблема в том, что кто-то использует достаточно сложную формулу вычисления индекса скорости [1], кто-то измеряет по body.onload, кто-то по DOMContentLoaded или, возможно, по еще какому-то событию.
Ни у кого из нас нет бесконечного времени, которое мы могли бы посвятить оптимизации производительности сайта, поэтому нужно остановиться на каком-то критерии: что важно для оптимизации, а что нет. И также нам надо договориться о том, что значит слово «производительный сайт» для наших пользователей, потому что мы делаем сайты именно для них.
Множество команд по всему миру работало над концепцией производительности веб-сайтов, включая команду Айри.рф, и мы вместе пришли к такой модели, которая считает пользователя центром всей этой истории с производительностью. Эту модель назвали RAIL = Response + Animation + Idle + Load.
Что же такое RAIL в двух словах:
Перед тем как разобрать модель RAIL в деталях, давайте сделаем еще один промежуточный шаг и разберемся с одним наименее любимым всеми словом: «медленно».
Что значит «медленно»? Поменять что-то в DOM – медленно? Как насчет тэга <script> в секции <head>? Анимация на JavaScript работает медленнее, чем на CSS, правильно? Если операция занимает 20 миллисекунд, это медленно? А если 0,5 секунды? А если 10 секунд?
Хотя разные операции требуют разного времени, чтобы быть выполненными, трудно объективно сказать, насколько это быстро или медленно. Важно обращать внимание на контекст, в котором это происходит.
Например, разные части кода: одна — работающая в то время, когда на экране ничего не происходит, и другая — в момент игрового цикла, когда игрок ожидает определенную реакцию на свои действия, будут иметь разные требования к производительности. Пользователи вашего сайта или приложения будут иметь разные ожидания в отношении производительности для разных контекстов их использования.
Как и в любом аспекте UX, то, как пользователи воспринимают, является самым главным. Первая «заповедь» работы в Google звучит как «интересы пользователя – в первую очередь, и все остальное придет».
Поэтому оценивать «медленно» ли выполняется какое-то действие – бессмысленно. Нужно выяснить «что чувствует пользователь, когда он взаимодействует с чем-то, что мы сделали?»
К счастью, есть достаточно много исследований, как пользователи воспринимают скорость реакции сайтов и приложений, например, вот эта работа Якоба Нильсена [2]. Основываясь на этих результатах, мы сформулировали для себя следующее:
Эти лимиты очень хороши тем, что они задают фундамент, от которого мы можем отталкиваться.
Давайте рассмотрим типичный пример взаимодействия с пользователем:
В этом коротком примере было несколько отдельных видов взаимодействия:
Если мы разметим эти виды взаимодействия на всем временном отрезке нашего видео, мы получим картину примерно такого вида:
Еще на одном видео ниже мы покажем примеры этих типов взаимодействия с пользователем.
Мы можем разбить все виды взаимодействия с пользователем на 4 вида. В Google называют эти виды взаимодействий RAIL, и у каждого такого типа взаимодействия есть свои собственные цели по производительности, которые основаны на ранее упомянутых порогах человеческого восприятия.
RAIL – это аббревиатура от английских слов response (отклик), animation (анимация), idle (ожидание) и load (загрузка). Эти четыре области следует рассматривать для обсуждения оптимизации производительности сайтов и приложений. Если вы будете оптимизировать их с учетом времени реакции, которое ожидают пользователи, они будут счастливы.
Когда пользователь нажимает на кнопку, необходимо «откликнуться» на его действие так быстро, чтобы он не заметил никакого лага. Это относится к любому элементу пользовательского ввода, не важно, нажимает ли пользователь на переключатель в форме или на обычную кнопку. Если пользователь не увидит отклик системы быстро, будь то включение или выключение переключателя или анимация нажатия кнопки, у него будет ощущаться разрыв между действием и реакцией системы. Тогда у него появится ощущение, что система работает с задержкой.
Отклик имеет отношение не только к софтверной части вашего сайта или приложения. Это целиком та задержка, которая возникает между тем, как палец пользователя коснулся стекла смартфона и тем, как на экране отрисовался результат его нажатия.
И здесь важно «посчитать» не только задержку в вашем сайте или приложении, а и в той программно-аппаратной части смартфона, которая отвечает за распознавание нажатий. Было ли у вас когда-либо такое, что вы нажимаете на какую-то кнопку, но задержка так велика, что вы начинаете сомневаться, что устройство вообще «поняло», что вы туда нажали? Вот это именно то ощущение, которое не должно появиться у пользователя.
Кроме того, что оно негативное само по себе, оно еще и вызывает обоснованные сомнения в том, насколько надежно вообще то приложение, с которым он работает, или насколько профессиональная команда сделала сайт. Подобные сомнения у пользователя будут работать против имиджа вашего продукта.
Правильный отклик происходит за менее чем 100 миллисекунд после действия пользователя.
В идеале, отклик должен сразу привести к желаемому новому состоянию. Если это не удается сделать, нужно показывать пользователю индикатор прогресса, чтобы у пользователя не было ощущения, что устройство или приложение просто не отреагировало на нажатие.
Анимация присутствует во всех видах современных приложений. Под анимацией подразумевается, конечно, не «нарисованный кролик идет по экрану», а такие операции как скроллинг, выдвигающееся сбоку меню и другие подобные эффекты, связанные с тем, что содержимое экрана должно непрерывно изменяться на протяжении какого-то времени.
Анимацию можно разделить по видам:
Анимация перетаскивания (drag): когда пользователь использует какие-то функции приложения или сайта, которые подразумевают, что он нажимает на какую-то область на экране и затем «тянет» в сторону в нажатом состоянии. Это может быть масштабирование экрана, может быть «перетаскивание» объектов и так далее.
Чтобы анимация выглядела непрерывной, каждый кадр анимации должен появляться на экране за менее чем 16 миллисекунд, то есть со скоростью 60 FPS. (1 секунда / 60 кадров = 16,6 миллисекунд на кадр).
Внутри каждого приложения происходит множество процессов, но далеко не все они должны работать в такие критические моменты, когда приложение отрабатывает взаимодействие с пользователям типа «отклик» или «анимация».
Инициализация различных компонентов, поиск и сортировка данных, отправка данных в сервис аналитики: все это можно делать в тот момент, когда приложение или браузер находятся в режиме ожидания.
Чтобы использовать время ожидания правильно, нужно группировать задачи, которые выполняются в это время, в блоки не более 50 миллисекунд. Почему так? Потому что если пользователь начнет взаимодействие, то мы хотим успеть сделать отклик за 100 миллисекунд, а не заставить его ждать две секунды, пока приложение что-то делает и не может откликнуться на его действия.
В первую очередь мы хотим как можно быстрее показать пользователю первый экран, на котором, тем не менее, он должен увидеть достаточно полезной для себя информации. Просто показать ему шапку меню и потом ждать появления остальной информации – не годится. Как только первый экран показан пользователю, приложение или сайт должны сохранить способность откликаться на действия пользователя, даже если в фоне происходит дозагрузка остальных частей страницы. Но пользователь не должен даже в этот момент испытывать проблем со скроллингом, нажатиями или анимацией.
Когда мы говорим про «загрузить быстро», мы ставим цель показать первый экран пользователю за 1 секунду, иначе у него возникает ощущение, что процесс «прерывается», он думает, что «это работает медленно», и его внимание может быть отвлечено чем-то другим. Он может переключиться с этого сайта на другую закладку в браузере, и вернется ли он и когда – неизвестно.
Чтобы успеть показать страницу за 1 секунду, необходимо отложить все загрузки некритических элементов на моменты ожидания действий пользователя.
В заключение напомним цели по производительности сайтов и приложений в концепции RAIL.
Отклик | Анимация | Ожидание | Загрузка |
---|---|---|---|
«Мгновенный» отклик на действия пользователя | Ощущение «неразрывной» анимации | Выполнение некритических действий | Поддерживать цели отклика во время загрузки страницы |
Отрисовка взаимодействия за менее чем 100 миллисекунд | Показ каждого кадра за менее чем 16 миллисекунд | Завершать каждое действие за менее чем 50 миллисекунд | Показ первого экрана за 1 секунду |
Несколько слов по поводу измерений:
Также хотелось бы отметить важность ответственного использования батареи устройства и памяти. Выполнить все указанные цели производительности, но оставить при этом пользователя с 10% заряда батареи и полностью занятой памятью – это не «интересы пользователя – в первую очередь»!
Пока мы не разработали четких критериев по заряду батареи и использованию памяти, но, возможно, в будущем мы добавим в аббревиатуру B (для батареи) и M (для памяти), потому что эти моменты нельзя игнорировать.
Важность оптимизации производительности сайта подтверждают ряд хорошо известных кейсов:
И, конечно, помните, что Google использует скорость загрузки как один из факторов ранжирования страниц в поиске [7].
Автор: sunnybear
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/it-standarty/175003
Ссылки в тексте:
[1] сложную формулу вычисления индекса скорости: https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
[2] работа Якоба Нильсена: https://www.nngroup.com/articles/response-times-3-important-limits/
[3] 2% замедления = на 2% меньше использования поиска на пользователя: http://assets.en.oreilly.com/1/event/29/Keynote%20Presentation%202.pdf
[4] на 400 миллисекунд быстрее = на 9% больше трафика: http://www.slideshare.net/stoyan/dont-make-me-wait-or-building-highperformance-web-applications#btnNext
[5] быстрее загрузка = больше просмотренных страниц: http://assets.en.oreilly.com/1/event/29/The%20Secret%20Weapons%20of%20the%20AOL%20Optimization%20Team%20Presentation.pdf
[6] на 100 миллисекунд быстрее = на 1% больше выручки: http://radar.oreilly.com/2008/08/radar-theme-web-ops.html
[7] один из факторов ранжирования страниц в поиске: https://webmasters.googleblog.com/2010/04/using-site-speed-in-web-search-ranking.html
[8] Источник: https://habrahabr.ru/post/308026/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.