From c058fa0fb22dc40ef0225b21a97578cddd0aaffa Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:51:05 +0100 Subject: unslug ru: move --- .../index.html | 174 ++++++++++++++++ files/ru/web/performance/fundamentals/index.html | 224 +++++++++++++++++++++ .../index.html" | 224 --------------------- .../index.html" | 174 ---------------- 4 files changed, 398 insertions(+), 398 deletions(-) create mode 100644 files/ru/web/performance/animation_performance_and_frame_rate/index.html create mode 100644 files/ru/web/performance/fundamentals/index.html delete mode 100644 "files/ru/web/performance/\320\276\321\201\320\275\320\276\320\262\321\213/index.html" delete mode 100644 "files/ru/web/performance/\320\277\321\200\320\276\320\270\320\267\320\262\320\276\320\264\320\270\321\202\320\265\320\273\321\214\320\275\320\276\321\201\321\202\321\214_\320\260\320\275\320\270\320\274\320\260\321\206\320\270\320\270/index.html" (limited to 'files/ru/web/performance') diff --git a/files/ru/web/performance/animation_performance_and_frame_rate/index.html b/files/ru/web/performance/animation_performance_and_frame_rate/index.html new file mode 100644 index 0000000000..8d8054dade --- /dev/null +++ b/files/ru/web/performance/animation_performance_and_frame_rate/index.html @@ -0,0 +1,174 @@ +--- +title: Производительность анимации и частота кадров +slug: Web/Performance/Производительность_анимации +tags: + - CSS animation + - Developer Tools + - Web Performance + - Анимация + - Производительность + - инструменты +translation_of: Web/Performance/Animation_performance_and_frame_rate +--- +

Анимация в Вебе может быть сделана с помощью {{domxref('SVGAnimationElement', 'SVG')}}, {{domxref('window.requestAnimationFrame','JavaScript')}}, включая {{htmlelement('canvas')}} и {{domxref('WebGL_API', 'WebGL')}}, CSS {{cssxref('animation')}}, {{htmlelement('video')}}, анимированных GIF и даже с помощью анимированных PNG и других типов изображений. Производительность CSS анимации может отличаться от одного CSS-свойства к другому, а попытка анимировать некоторые "дорогие" CSS-свойства может привести к зависаниям ({{glossary('jank')}}), даже несмотря на то, что браузер борется за то, чтобы смягчить частоту смены кадров {{glossary('frame rate')}}.

+ +

Для анимированных медиа, таких как видео и GIF, основная проблема производительности - это размер файлов. Скачивание больших по объему файлов не может не повлиять на производительность системы или на то, как эту систему воспринимает пользователь. 

+ +

Анимации, основанные на коде, будь то CSS, SVG, <canvas>, webGL или другие JavaScript анимации, могут нести проблемы производительности сами в себе, даже если файлы этого кода скачиваются быстро. Такие анимации могут потреблять всё время CPU и приводить к зависаниям.

+ +

Несомненно, производительность каждой конкретной системы - очень чувствительная тема. Улучшив клиентскую производительность, вы сможете не только ускорить работу приложения, но даже затронете физический аспект - сможете сэкономить заряд батареи мобильных устройств и / или понизите температуру устройства. Поэтому очень важно владеть инструментами для измерения производительности. Они помогут вам понять всю работу, которую проводит браузер, пока рендерит ваше приложение и поможет избежать и диагностировать проблемы, когда они происходят.
+
+ Пользователи ожидают, что взаимодействие с интерфейсом будет плавным, а интерфейс будет отзывчивым. Анимация помогает улучшить восприятие приложения, сделав его быстрым и отзывчивым; но анимация так же может замедлить его и привести к зависаниям, если она сделана неумело. Отзывчивые интерфейсы должны иметь частоту смены кадров, равную 60 кадров в секунду (fps). В то время, как не всегда возможно поддерживать такую частоту, очень важно поддерживать быструю и устойчивую смену кадров для анимации. 

+ +

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

+ +

Графики frame rate и waterfall из встроенных инструментов браузера дают информацию о том, как браузер выполняет работу по анимации. Используя эти инструменты, вы можете измерить fps приложения и диагностировать узкие места, в которых fps уменьшается.

+ +

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

+ +

Если сравнивать анимацию с помощью JavaScript и CSS, вы увидите, что CSS-анимации проще создать. Более того, CSS-анимации гарантируют лучшую производительность, так как они автоматически делегируют некоторые задачи браузеру. Например, в случае CSS браузер сам решает, когда нужно отрендерить кадр, а когда пропустить кадр, если это необходимо. 

+ +


+ Однако, стоимость изменения разных CSS свойств варьируется. Общепринято, что 60 кадров в секунду - это достаточная частота, чтобы анимация выглядела мягкой и плавной. Несложный подсчет говорит, что при частоте 60 кадров в секунду, браузер имеет лишь 16.7 миллисекунд, чтобы выполнить все скрипты, пересчитать стили, скомпоновать слои и отрисовать новый кадр. Отсюда следует, что медленные скрипты и анимация дорогих CSS свойств может может привести к зависаниям, так как браузер все еще будет пытаться вычислить все 60 кадров.

+ +

Стоит заметить, что 60 кадров в секунду - это стандартная частота обновления экрана. Существуют экраны с гораздо большим FPS. Например, экраны игровых ноутбуков или iPad Pro 2018 имеют частоту смены кадров, равную 120 fps и выше. Для таких устройств производители браузеров ограничивают частоту 60-ю кадрами в секунду, но с помощю некоторых опций этот лимит можно убрать. И в этом случае, на формирование каждого кадра устройство будет отводить лишь 8.6 миллисекунд.

+ +

Этапы рендеринга

+ +

Процесс, используемый браузером для отображения анимации CSS свойств, может быть представлен как последовательность этапов из следующего изображения:

+ +

+ +
    +
  1. Recalculate Style: когда любое CSS свойство для элемента изменяется, браузер должен заново вычислить результирующий набор свойств.
    2. +
  2. Layout: затем браузер использует вычисленные стили для того, чтобы понять позицию и геометрию элементов - как измененного, так и рядом лежащих. Эта операция называется "layout", но иногда её так же называют "reflow".
    3. +
  3. Paint: наконец, браузер должен перерисовать элементы на экране. Но этот этап не обязательно должен быть простым, как на изображении. Страница может быть разделена на слои, каждый из которых перерисовывается независимо, а только после этого они комбинируются в процессе, который называется композицией "Composition".
    4. +
+ +

Процессы, которые браузер использует для отрисовывания изменений на элементе <canvas> отличаются. В случае <canvas>, Layout не присходит. Скорее, страница будет перерисована с помощью JavaScript canvas API. 

+ +

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

+ +

Стоимость CSS свойств

+ +

На всех этапах рендеринга изменение некоторых свойств является более затратным, других - менее:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Тип свойстваСтоимостьПримеры
Свойства, затрагивающие геометрию или позицию элемента, запускают весь процесс заново: новое вычисление стилей, layout и перерисовку. +

left
+ max-width
+ border-width
+ margin-left
+ font-size

+
+

Свойства, не затрагивающие геометрию и позиционирование элементов, но не лежащие в отдельном слое, запускают только вычисление стилей и перерисовку, но не Layout.

+ 		+

color

+
+

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

+ 		transform
+ opacity
+ +
+

На Веб-сайте CSS Triggers хорошо показано, какие CSS свойства вызывают те или иные этапы обновления в разных браузерах.

+
+ +

Пример: margin против transform

+ +

В этом разделе мы увидим, как инструмент Waterfall может указать на разницу между анимацией. ёё margin  и transform.

+ +

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

+ +

Если вы хотите самостоятельно разобраться с этим примером, вы можете найти демо здесь. Демо выглядит так:

+ +

На экране всего два контрола: кнопка "start / stop" для запуска и остановки анимации и радио-кнопки для выбора свойства, с помощью которого происходит анимация:  margin, или transform.

+ +

Так же на странице есть некоторое количество элементов со свойствами  linear-gradient и box-shadow Мы обращаем внимание именно на эти два свойства, так как они относительно дорогие.

+ +

Так же существует видео-версия анализа и оптимизации этой страницы.

+ +

{{EmbedYouTube("Tvu6_j8Qzfk")}}

+ +

Анимация свойства margin

+ +

Оставим включенной опцию "Use margin" и начнём анимацию. В это же время откроем "Performance tool" и нажмем кнопку "записать" (make a recording). Нам понадобится лишь пара секунд записи.

+ +

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

+ +

+ +

На экране показаны три отдельных секции: (a) обзор этапов рендеринга (Waterfall), (b) частота кадров, и (c) детали на временной шкали.

+ +

Обзор этапов рендеринга на временной шкале (Waterfall)

+ +

+ +

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

+ +

Частота кадров (Frame Rate)

+ +

+ +

Эта секция показывает частоту кадров. Средняя частота на примере - 46.67fps. Это ниже, чем желаемые 60fps. Однако, ещё хуже то, что частота кадров нестабильна - есть этапы, где частота кадров снижается до 20 и даже до 10 fps. Маловероятно, что вы увидите здесь плавную анимацию, особенно если добавите какое-то взаимодействие с пользователем.

+ +

Этапы рендеринга в деталях (Waterfall)

+ +

Оставшаяся часть записей показа в секции "Waterfall view". Если вы пролистаете этот список, вы увидите что-то наподобие этого:

+ +

+ +

Это шаги рендеринга (rendering waterfall). Для каждого кадра анимации мы вычисляем стили для каждого элемента, потом вычисляем Layout, а затем перерисовываем все элементы.

+ +

Из таблицы видно, что особый урон производительности наносит перерисовка Paint (зелёные полосы). Например, выделенный этап Paint занял 13.11мс. Учитывая, что весь бюджет рендеринга - 16.7мс, неудивительно, что мы увидели падения fps.

+ +

Вы можете поэкспериментировать с некоторыми свойствами. Например, попробуйте убрать box-shadow с помощью инспектора страницы (Page / Element Inspector), замерьте производительность и посмотрите, как это отразилось на производительности. Затраты на Paint уменьшатся значительно. Но они все ещё есть. Мы ещё вернёмся к этому вопросу позже, когда будем изучать использование transform вместо margin. Вы увидите, что от затрат на этот этап можно избавиться полностью.

+ +

Анимация свойства transform

+ +

Теперь, переключитесь на "Use transform" и запишите новые данные. Это должно выглядеть примерно так:

+ +

+ +

Обзор этапов рендеринга на временной шкале (Waterfall)

+ +

+ +

В сравнении с версией, которая использует margin, мы видим намного меньше зеленого, но намного больше фиолетового цвета. Это говорит о том, что вместо paint мы теперь тратим ресурсы на этапы layout или style recalculation.

+ +

Частота кадров (Frame Rate)

+ +

+ +

В сравнении с версией, которая использует margin, показатели fps здесь выглядят достаточно хорошо. Средняя частота кадров близка к 60fps, а стабильность fps, за исключением падения fps в начале значительно выросла.

+ +

Этапы рендеринга в деталях (Waterfall)

+ +

В этой секции мы видим объяснения тому, что fps значительно улучшился. Мы больше не тратим время на layout и перерисовку элементов. :

+ +

+ +

Здесь, используя transform, мы заметно улучшили производительность приложения. А инструменты разработчика помогли нам это сделать.

diff --git a/files/ru/web/performance/fundamentals/index.html b/files/ru/web/performance/fundamentals/index.html new file mode 100644 index 0000000000..fd97d25650 --- /dev/null +++ b/files/ru/web/performance/fundamentals/index.html @@ -0,0 +1,224 @@ +--- +title: Основы производительности +slug: Web/Performance/Основы +tags: + - Apps + - Firefox + - Gecko + - Guide + - Performance + - Производительность +translation_of: Web/Performance/Fundamentals +--- +
+

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

+
+ +

Что такое производительность?

+ +

Ощущаемая пользователем "производительность" - это единственная производительность, которая имеет значение. Пользователи взаимодействуют с системой с помощью ввода каких-то данных: прикосновений, движения и речи. В ответ, они получают реакцию, основанную на зрительном, тактильном или слуховом аппаратах. Производительность - это качество того, как система реагирует на действия пользователя.

+ +

При прочих равных, код, оптимизированный для каких-то иных целей, кроме ощущаемой пользователем производительности (здесь и дальше UPP, user-perceived performance) всегда проигрывает коду, который оптимизирован для UPP. Упрощенно говоря, пользователи предпочитают отзывчивое и плавное приложение, которое обрабатывает 1,000 транзакций к базе данных в секунду грубому неотзывчивому приложению, которое обрабатывает 100,000,000 запросов в секунду. Конечно, это не означает, что другие метрики становятся ненужным, но первой вашей целью должна быть UPP.

+ +

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

+ +

Отзывчивость

+ +

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

+ +

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

+ +

Отзывчивость важна просто потому, что пользователи теряются и злятся, когда их игнорируют. Ваше приложение игнорирует пользователя каждую секунду, когда оно не отвечает на пользовательский ввод.

+ +

Частота кадров

+ +

Частота кадров - это частота, с которой система перерисовывает пиксели, отображаемые пользователю. Это знакомая концепция: каждый предпочитает, скажем, игры, которые работают в режиме 60 кадров в секунду играм, которые работают с частотой 10 кадров в секунду. Даже если они не смогут объяснить причины этого.

+ +

Частота кадров важна примерно так же, как "качество обслуживания". Дисплеи устройств спроектированы так, чтобы обманывать глаза пользователей, доставляя фотоны света так, чтобы изображение было похожим на реальное. Например, бумага, покрытая напечатанными буквами, отражает фотоны определённым образом. Манипулируя рендерингом, приложения-читалки пытаются отправить фотоны похожим образом, обманывая глаза.

+ +

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

+ +
+

Заметка: люди обычно не могут почувствовать разницу между частотами кадров выше 60Hz. По этой причин большая часть современных электронных дисплеев спроектированы для обновления картинки с такой частотой.  Однако, для некоторых живых существ такая частота кадров будет казаться замедленной. Например, для колибри.

+
+ +

Использование памяти

+ +

Использование памяти - это отдельная ключевая метрика. В отличии от отзывчивости и частоты кадров, пользователи не могут напрямую почувствовать использование памяти, но её использование влияет на "состояние пользователя". Идеальная система будет поддерживать 100% состояния всех приложений всё время: все приложения будут запускаться одновременно, а каждое приложение будет возвращаться к состоянию, которое было в последний раз, когда пользователь с ним взаимодействовал (состояние приложения хранится в компьютерной памяти - поэтому это сравнение его с user state довольно точное).

+ +

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

+ +

Это не означает, что система должна тратить память. Когда система использует больше памяти, чем это необходимо для поддержания состояния приложения - она тратит память. В этом случае, другое приложение (или даже другое состояние), которые могли бы использовать эту память - не могут её использовать. На практике, ни одна система не может поддерживать в памяти все состояния одновременно. Разумное распределение памяти, достаточное для поддержки состояния приложения - это важная проблема, которую мы рассмотрим позже.

+ +

Использование энергии

+ +

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

+ +

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

+ +

Всю оставшуюся часть статьи мы будем обсуждать производительность в свете этих показателей.

+ +

Оптимизация платформы

+ +

В этой секции приводится краткий обзор того, как Firefox/Gecko вкладывается в производительность в целом, не заостряя внимание на конкретных приложениях. Для разработчиков и пользователей это будет вопрос на ответ "Как платформа помогает мне?".

+ +

Web технологии

+ +

Web платформа предоставляет много инструментов, некоторые из которых лучше подходят для конкретных задач, а некоторые - хуже. Логика приложений пишется на JavaScript. Для отображения графики разработчики могут использовать HTML или CSS (т.е. используются высокоуровневные декларативные языки); разработчики также могут использовать низкоуровневые интерфейсы, доступные в {{ htmlelement("canvas") }} (включая WebGL). Где-то между HTML/CSS и Canvas лежит SVG, который предлагает некоторые преимущества обеих систем.

+ +

HTML и CSS значительно увеличивают производительность, иногда снижая частоту кадров и не давая контролировать каждый пиксель при рендере. Текст и изображения перерисовываются автоматически, UI-элементы автоматически получают системную тему, а система предоставляет некоторую "встроенную" поддержку для некоторых случаев, о которых разработчик может и не задумываться изначально. Например, отображение контента при разных разрешениях.

+ +

Элемент Холст (canvas) предоставляет прямой доступ к пиксельному буферу, где разработчик может рисовать.Это даёт разработчику возможность контролировать каждый пиксель во время рендеринга, точно контролировать частоту кадров; но тогда разработчик должен иметь в виду работу с большим количеством разрешений экранов и ориентаций; RTL языками и т.д. Разработчики, работающие напрямую с холстами, используют либо знакомое 2D API, либо API WebGL, достаточно "близкий к железу" и по большей части придерживающийся OpenGL ES 2.0.

+ +
+

Заметка: Firefox OS оптимизирована для работы с приложениями, основанными на Web технологиях: HTML, CSS, JavaScript и т.д. За исключением некоторых базовых служб операционной системы, весь код Firefox OS пришел из Web приложений и движка Gecko. Даже оконный менеджер операционной системы написан на HTML, CSS и JavaScript. В связи с тем, что ядро операционной системы написано  на этих технологиях, было критически важно соблюсти производительность этих технологий. В Firefox OS не может быть какого-то "запасного выхода". И это очень полезно для разработчиков, потому что теперь сторонние приложения могут использовать все преимущества оптимизации операционной системы. Не существует какого-то "магического зелья производительности", доступного только для предустановленных приложений.

+ +

См. Тестирование производительности Firefox OS для подробностей.

+
+ +

Как рендерит Gecko

+ +

Движок Gecko JavaScript поддерживает just-in-time (JIT) компиляцию. Благодаря этому, логика приложения выполняется примерно так же, как это происходит в других приложениях на виртуальных машинах - например, Java Virtual Machines - а в некоторых случаях эффективность этих приложений близка к "нативному коду".

+ +

Инструменты, необходимые для работы с HTML, CSS и Canvas оптимизированы несколькими путями. Например, композиция (этап, известный как Layout) в HTML/CSS и код, отвечающий за графику в Gecko, сделаны таким образом, чтобы уменьшить количество операций ревалидации и перерисовки для общих случаев (например, скроллинг); эти оптимизации включены "по умолчанию", поэтому разработчики пользуются ими бесплатно. Буферы пикселей, отрисованных как для Gecko "автоматически", так и для canvas "вручную", минимизируют количество копий, которые передаются в буфер кадров дисплея. Чтобы достичь этого, Gecko старается избегать создания промежуточных слоев (например, во многих других операционных системах создаются пиксельные фоновые буферы для каждого отдельного приложения), но взамен Gecko использует специальные участки памяти ддя хранения графических буферов. К этой памяти имеет прямой доступ железо, которое ответственно за формирование картинки. Сложные сцены рендерятся с использованием графического адаптера (видеокарты). А простые сцены, для экономии энергии, рендерятся специальным выделенным железом для композиции, в то время, как графический адаптер находится в режиме ожидания или выключен.

+ +

Для продвинутых приложений полностью статичный контент скорее является исключением, чем правилом. Такие приложения используют динамический контент, анимируемый с помощью {{ cssxref("animation") }} и {{ cssxref ("transition") }}. Переходы и анимации особенно важны для приложений: разработчики могут использовать CSS для объявления сложного поведения с помощью простого высокоуровнего синтаксиса. С другой стороны, движок Gecko хорошо оптимизирован для того, чтобы рендерить такую анимацию эффективно. В целом, общепринятые анимации передаются к обработке системному компоновщику, который может отрендерить их в эффективном, энергосберегающем режиме. 

+ +

Производительность запуска приложения так же важна, как и её текущая производительность. Gecko оптимизирован для того, чтобы загружать разнообразный контент эффективно: ведь Gecko впитал в себя опыт всего Web-а! Много лет Web улучшался, а разработчики улучшали его контент. Параллельный парсинг HTML, разумное выстраивание очереди перерисовки и декодирования изображений, умные алгоритмы компоновки и т.д.. Все эти оптимизации, конечно, улучшают и производительность Firefox OS.

+ +
+

Заметка: смотрите Тестирование производительности Firefox OS для дополнительной информации о Firefox OS спецификациях, которые помогают оптимизировать производительность запуска.

+
+ +

Производительность приложений

+ +

Эта секция попытается ответить на вопрос "как сделать приложение быстрее?".

+ +

Скорость загрузки

+ +

Загрузка приложения может быть поделена на три этапа, которые влияют на UPP:

+ + + +

Секрет быстрой загрузки требует двух вещей: UPP (ощущаемая пользователем скорость) - это единственное, что имеет значение; эта скорость зависит от критического пути рендеринга (Critical Rendering Path). Критический путь - это единственный и необходимый код, который должен запускать перечисленные выше события.

+ +

Например, отрисовка первого кадра, который содержит в себе необходимый HTML и CSS включает:

+ +
    +
  1. Браузер должен спарсить HTML
    2. +
  2. DOM должен быть построен для этого HTML
    3. +
  3. Ресурсы (изображения, видео и др.) для этой модели DOM должны быть загружены и декодированы
    4. +
  4. CSS стили должны быть применены к DOM и должен быть сформирован CSSOM
    5. +
  5. Стилизованный компонент должен быть подготовлен к рендеру
    6. +
+ +

В этом списке вы не увидите "загрузить JS файл, который нужен для второстепенного меню", "забрать и декодировать изображения для списка достижений" и т.п. Эта работа не должна выполняться при запуске приложения.

+ +

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

+ +

Web-платформа очень динамична. JavaScript - это динамически типизированный язык, а Web разрешает загружать код, HTML, CSS, изображения и другие ресурсы динамически. Эти функции могут быть использованы для того, чтобы отложить загрузку ресурсов; чтобы сократить критический путь, подвинув загрузку лишнего контента на несколько моментов позже. Такой подход называется "ленивой загрузкой".

+ +

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

+ +
+

Заметка: Для дополнительной информации об ускорении запуска ознакомьтесь с Optimizing startup performance.

+
+ +

Следует также отметить, что ресурсы, закешированные локально, могут быть загружены гораздо быстрее, чем динамические данные, загруженные через мобильную сеть с её задержками или узким каналом. Локальное кеширование и работа в оффлайне могут быть достигнуты с помощью Service Workers. См. Making PWAs work offline with Service workers для подробностей.

+ +

Частота кадров

+ +

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

+ +

При отрисовывании контента в Canvas, разработчик должен сам позаботиться о достижении целей по частоте кадров, ведь он получает полный контроль над всем, что отрисовывается.

+ +

При использовании HTML и CSS разработчику необходимо использовать правильные примитивы. Firefox очень хорошо оптимизирован для скролла любого контента. Обычно это не является проблемой. Но очень часто, разменивая качество и стабильность на скорость, мы идём на ухищрения, которые могут "переоптимизировать" страницу так, что частота кадров будет выше нужной нам. Так как глаз все равно слабо различает FPS больше 60, нет необходимости в таких оптимизациях. Одна из таких оптимизаций - использование статического рендера вместо CSS-градиента. В некоторых случаях это излишне. Чтобы не применять оптимизацию, вы можете воспользоваться CSS media queries, которые позволят использовать подобные решения только для конкретных устройств.

+ +

Множество приложений используют Transitions и Animations для перехода между страницами или панелями. Например, когда пользователь нажимает кнопку "Настройки", чтобы перейти на другой экран; или для вызова поп-апа. Firefox оптимизирован для выполнения переходов и анимаций для сцен, которые:

+ + + +

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

+ +

Использование памяти и энергии

+ +

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

+ +

Современные ЦПУ могут работать в режиме энергосбережения, когда они не задействованы. Приложения, которые постоянно запускают таймеры или продолжают ненужные анимации, мешают процессору перейти в режим энергосбережения. Эффективные приложения не должны так делать.

+ +

Когда приложение переходит в фоновый режим, срабатывает событие  {{event("visibilitychange")}}. Это событие - друг разработчика. Приложения должы слушать его и реагировать на него. Например, в Firefox OS, приложения, которые умеют ограничивать использование ресурсов и экономят память, когда переходят в фоновый режим, с меньшей долей вероятности будут отключены (см. заметку ниже). Это, если посмотреть с другой стороны, означает, что раз приложение не было выгружено - оно будет быстрее загружено.

+ +
+

Заметка: Как было упомянуто выше, Firefox OS пытается сохранить как можно больше приложений, но иногда вынуждена приостанавливать некоторые из них. Обычно это происходит, когда у устройства заканчивается память. Чтобы узнать больше о том, как Firefox OS управляет памятью и избавляется от приложений, когда начинаются проблемы с памятью, читайте Debugging out of memory errors on Firefox OS.

+
+ +

Советы к применению в коде

+ +

Следующие советы помогут вам улучшить один или несколько факторов производительности, которые мы обсуждали ранее.

+ +

Используйте CSS animation и transition

+ +

Вместо использования функции  animate() какой-нибудь библиотеки, которая, вероятно, использует много плохих решений (например ({{domxref("window.setTimeout()")}} или анимирование top / left), используйте CSS анимации. Во многих случаях, вы можете использовать CSS Transitions. Использование этих свойств поможет, так как браузер спроектирован так, чтобы оптимизировать эти эффекты и переносить часть вычислений на GPU, чтобы они работали плавно и с минимальным влиянием на процессор. Другое преимущество - вы можете определить эти анимации в CSS декларативным образом, а не в бизнес-логике приложения.

+ +

CSS анимации дают вам очень точный контроль эффектов, если вы используете keyframes. Более того, вы сможете отслеживать события, которые происходят во время анимации, так как основной поток обработки не блокируется. Вы можете с легкостью запускать анимации с помощью {{cssxref(":hover")}}, {{cssxref(":focus")}} или {{cssxref(":target")}}. Или динамически добавляя или удаляя классы элемента.

+ +

Если вы хотите создавать анимации "на лету" или изменять их с помощью JavaScript, Джеймс Лонг написал простую библиотеку для этого - CSS-animations.js.

+ +

Используйте CSS трансформацию

+ +

Вместо того, чтобы изменять абсолютное позиционирование и возиться с этой математикой вручную, используйте свойство {{cssxref("transform")}}, чтобы изменить позицию, масштаб и некоторые другие аспекты вашего контента. Именно так вы используете аппаратное ускорение. Браузер умеет передавать такие задачи графическому процессору, давая возможность ЦПУ заняться другими важными вещами.

+ +

К тому же, трансформация даёт возможности, которых в ином случае у вас не было бы. Вы не только можете манипулировать элементом в двумерном пространстве, но можете трансформировать его в 3D, изменять его наклон (скашивать, skew), поворачивать и др. Пол Айриш опубликовал статью in-depth analysis of the benefits of translate(), в которой проанализировал работу translate с точки зрения производительности. Используя translate/transform вы используете правильный декларативный инструмент и возлагаете оответственность за его оптимизацию на браузер. Вы так же получаете возможность с легкостью позиционировать элементы. Если вы будете использовать только top и left, вам придется написать некоторый дополнительный код, чтобы предусмотреть некоторые особенности такого позиционирования. И последний бонус - с Transform / Translate вы будете работать примерно так же, как работали бы с элементом canvas.

+ +
+

Заметка: В некоторых случаях (в зависимости от платформы) вам может понадобиться добавить свойство translateZ(0.1), если вы хотите заставить клиента перенести вычисление анимаций на графический адаптер. Как было упомянуто выше, это может улучшить производительность, но увеличит потребление памяти. Какое из зол - меньшее - решать вам. Протестируйте оба варианта и выясните, что лучше подходит для вашего приложеия.

+
+ +

Используйте requestAnimationFrame() вместо setInterval()

+ +

Вызовы {{domxref("window.setInterval()")}} запускают код с учётом предполагаемой частоты кадров. Однако, эта ожидаемая частота и фактическая не всегда совпадают. SetInternal говорит браузеру "нарисуй результаты", даже если браузер не занимается сейчас отрисовкой - такое случается, когда графический адаптер ещё не дошел до следующего цикла обновления экрана. Такое несовпадение таймингов - чрезмерная растрата процессорного времени и даже может приводить к снижению срока службы аккумуляторов пользовательского устройств.

+ +

Вместо этого, вам необходимо использовать {{domxref("window.requestAnimationFrame()")}}. Эта функция ждет, пока клиент не будет готов к формированию следующего кадра анимации и не будет досаждать своими запросами аппаратную часть устройства, если устройство не занимается в данный момент рендерингом. Другое преимущество этого API в том, что такие анимации не будут запускаться, пока ваше приложение не видно на экране (например, если оно выполняется в фоне или занимается другими операциями). Это сохранит батарею и защитит вас от проклятий, которые пользователи будут выкрикивать в небо.

+ +

Делайте события мгновенными

+ +

Как старомодные, заботящиеся о доступности веб-разработчики, мы любим событие нажатия, так как оно также срабатывает и для ввода с клавиатуры. На мобильных устройствах это работает иначе. Вы должны использовать {{event("touchstart")}} и {{event("touchend")}}, а не click. Причина этому - в мобильных устройствах срабатывает задержка в несколько сотен миллисекунд между касанием экрана и запуском обработчика click. Из-за этого приложение может ощущаться медленным. Если вы будете тестировать ваше приложение на предмет работы с касаниями, вы не пожертвуете доступностью. Кроме того, существуют библиотеки, которые ускорят разработку. Например, Financial Times использует библиотеку fastclick для обработки.

+ +

Держите интерфейс простым

+ +

Одна из самых больших проблем, которую мы нашли в HTML5 приложениях, заключается в том, что перенос большого количества DOM элементов делает приложение медленным - особенно, если в этих элементах много градиентов и теней. Упрощайте то, как выглядит ваше приложение и передвигайте проксирующий элемент, когда выполняете Drag And Drop - это сильно ускорит работу.

+ +

Когда, например, у вас есть большой список элементов (скажем, твитов), не перемещайте их все. Вместо этого, держите в вашем DOM-дереве только те элементы, которые видимы и несколько за областью видимости, чтобы при скролле не было заметно моргание. Остальные - прячьте. Сохраняйте данные в JavaScript объектах, вместо хранения данных и доступа к ним в DOM. Думайте об экране, как об устройстве представления необходимых данных, а не всех. Это не означает, что вы не можете использовать HTML, как источник данных; просто читайте его один раз, а затем продвигайтесь на 10 элементов, изменяя содержимое первого и последнего элемента, согласно их позициям в списке, вместо того, чтобы двигать 100 элементов, которые уже невидимы. Подобный трюк сработает и в играх со спрайтами: если они не видны на экране, нет необходимости запрашивать их. Вместо этого переиспользуйте элементы, которые выходят за пределы экрана, в то время как новые входят.

+ +

Общий анализ производительности

+ +

Firefox, Chrome и другие браузеры предоставляют встроенные инструменты, которые могут помочь вам диагностировать медленный рендеринг. В частности, Firefox's Network Monitor покажет точное время, когда произошел каждый сетевой запрос, насколько большим он был и как долго обрабатывался.

+ +

The Firefox network monitor showing get requests, multiple files, and different times taken to load each resource on a graph.

+ +

Если на вашей странице есть JavaScript, который выполняется очень долго, JavaScript profiler  укажет на наиболее медленные строки кода.

+ +

The Firefox JavaScript profiler showing a completed profile 1.

+ +

Встроенный Gecko Profiler - очень полезный инструмент, который позволяет вам получить ещё более подробную информацию о том, какие части кода работают медленно. Это довольно сложный инструмент, но он предоставляет множество деталей.

+ +

A built-in Gecko profiler windows showing a lot of network information.

+ +
+

Заметка: Вы можете использовать эти инструменты и в Android браузере, запустив Firefox и включив remote debugging.

+
+ +

Например, множественные сетевые запросы в мобильной сети занимают больше времени. Рендеринг больших изображений и CSS градиентов может происходить дольше. Простое скачивание больших изображений может занять большее время, даже через быструю сеть, так как аппаратная часть мобильных устройств зачастую слишком медленна, чтобы использовать все возможности быстрых каналов данных. Для получения полезных подсказок о производительности на мобильных устройствах, ознакомьтесь с докладом Максимилиано Фёртмана Mobile Web High Performance.

+ +

Тестовые кейсы и сообщения об ошибках

+ +

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

+ +

Убедитесь, что вы можете воспроизвести проблему, просто сохраняя и загружая статическую копию HTML-страницы (включая изображения/стили/скрипты). Если так - удалите из HTML файла всю личную информацию и обратитесь к за помощью (отправьте отчет в Bugzilla или, например, сохраните файл на своем сервере и поделитесь ссылкой). Вам также понадобится поделиться информацией профилировщика, которую вы собрали с помощью инструментов отладки.

diff --git "a/files/ru/web/performance/\320\276\321\201\320\275\320\276\320\262\321\213/index.html" "b/files/ru/web/performance/\320\276\321\201\320\275\320\276\320\262\321\213/index.html" deleted file mode 100644 index fd97d25650..0000000000 --- "a/files/ru/web/performance/\320\276\321\201\320\275\320\276\320\262\321\213/index.html" +++ /dev/null @@ -1,224 +0,0 @@ ---- -title: Основы производительности -slug: Web/Performance/Основы -tags: - - Apps - - Firefox - - Gecko - - Guide - - Performance - - Производительность -translation_of: Web/Performance/Fundamentals ---- -
-

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

-
- -

Что такое производительность?

- -

Ощущаемая пользователем "производительность" - это единственная производительность, которая имеет значение. Пользователи взаимодействуют с системой с помощью ввода каких-то данных: прикосновений, движения и речи. В ответ, они получают реакцию, основанную на зрительном, тактильном или слуховом аппаратах. Производительность - это качество того, как система реагирует на действия пользователя.

- -

При прочих равных, код, оптимизированный для каких-то иных целей, кроме ощущаемой пользователем производительности (здесь и дальше UPP, user-perceived performance) всегда проигрывает коду, который оптимизирован для UPP. Упрощенно говоря, пользователи предпочитают отзывчивое и плавное приложение, которое обрабатывает 1,000 транзакций к базе данных в секунду грубому неотзывчивому приложению, которое обрабатывает 100,000,000 запросов в секунду. Конечно, это не означает, что другие метрики становятся ненужным, но первой вашей целью должна быть UPP.

- -

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

- -

Отзывчивость

- -

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

- -

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

- -

Отзывчивость важна просто потому, что пользователи теряются и злятся, когда их игнорируют. Ваше приложение игнорирует пользователя каждую секунду, когда оно не отвечает на пользовательский ввод.

- -

Частота кадров

- -

Частота кадров - это частота, с которой система перерисовывает пиксели, отображаемые пользователю. Это знакомая концепция: каждый предпочитает, скажем, игры, которые работают в режиме 60 кадров в секунду играм, которые работают с частотой 10 кадров в секунду. Даже если они не смогут объяснить причины этого.

- -

Частота кадров важна примерно так же, как "качество обслуживания". Дисплеи устройств спроектированы так, чтобы обманывать глаза пользователей, доставляя фотоны света так, чтобы изображение было похожим на реальное. Например, бумага, покрытая напечатанными буквами, отражает фотоны определённым образом. Манипулируя рендерингом, приложения-читалки пытаются отправить фотоны похожим образом, обманывая глаза.

- -

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

- -
-

Заметка: люди обычно не могут почувствовать разницу между частотами кадров выше 60Hz. По этой причин большая часть современных электронных дисплеев спроектированы для обновления картинки с такой частотой.  Однако, для некоторых живых существ такая частота кадров будет казаться замедленной. Например, для колибри.

-
- -

Использование памяти

- -

Использование памяти - это отдельная ключевая метрика. В отличии от отзывчивости и частоты кадров, пользователи не могут напрямую почувствовать использование памяти, но её использование влияет на "состояние пользователя". Идеальная система будет поддерживать 100% состояния всех приложений всё время: все приложения будут запускаться одновременно, а каждое приложение будет возвращаться к состоянию, которое было в последний раз, когда пользователь с ним взаимодействовал (состояние приложения хранится в компьютерной памяти - поэтому это сравнение его с user state довольно точное).

- -

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

- -

Это не означает, что система должна тратить память. Когда система использует больше памяти, чем это необходимо для поддержания состояния приложения - она тратит память. В этом случае, другое приложение (или даже другое состояние), которые могли бы использовать эту память - не могут её использовать. На практике, ни одна система не может поддерживать в памяти все состояния одновременно. Разумное распределение памяти, достаточное для поддержки состояния приложения - это важная проблема, которую мы рассмотрим позже.

- -

Использование энергии

- -

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

- -

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

- -

Всю оставшуюся часть статьи мы будем обсуждать производительность в свете этих показателей.

- -

Оптимизация платформы

- -

В этой секции приводится краткий обзор того, как Firefox/Gecko вкладывается в производительность в целом, не заостряя внимание на конкретных приложениях. Для разработчиков и пользователей это будет вопрос на ответ "Как платформа помогает мне?".

- -

Web технологии

- -

Web платформа предоставляет много инструментов, некоторые из которых лучше подходят для конкретных задач, а некоторые - хуже. Логика приложений пишется на JavaScript. Для отображения графики разработчики могут использовать HTML или CSS (т.е. используются высокоуровневные декларативные языки); разработчики также могут использовать низкоуровневые интерфейсы, доступные в {{ htmlelement("canvas") }} (включая WebGL). Где-то между HTML/CSS и Canvas лежит SVG, который предлагает некоторые преимущества обеих систем.

- -

HTML и CSS значительно увеличивают производительность, иногда снижая частоту кадров и не давая контролировать каждый пиксель при рендере. Текст и изображения перерисовываются автоматически, UI-элементы автоматически получают системную тему, а система предоставляет некоторую "встроенную" поддержку для некоторых случаев, о которых разработчик может и не задумываться изначально. Например, отображение контента при разных разрешениях.

- -

Элемент Холст (canvas) предоставляет прямой доступ к пиксельному буферу, где разработчик может рисовать.Это даёт разработчику возможность контролировать каждый пиксель во время рендеринга, точно контролировать частоту кадров; но тогда разработчик должен иметь в виду работу с большим количеством разрешений экранов и ориентаций; RTL языками и т.д. Разработчики, работающие напрямую с холстами, используют либо знакомое 2D API, либо API WebGL, достаточно "близкий к железу" и по большей части придерживающийся OpenGL ES 2.0.

- -
-

Заметка: Firefox OS оптимизирована для работы с приложениями, основанными на Web технологиях: HTML, CSS, JavaScript и т.д. За исключением некоторых базовых служб операционной системы, весь код Firefox OS пришел из Web приложений и движка Gecko. Даже оконный менеджер операционной системы написан на HTML, CSS и JavaScript. В связи с тем, что ядро операционной системы написано  на этих технологиях, было критически важно соблюсти производительность этих технологий. В Firefox OS не может быть какого-то "запасного выхода". И это очень полезно для разработчиков, потому что теперь сторонние приложения могут использовать все преимущества оптимизации операционной системы. Не существует какого-то "магического зелья производительности", доступного только для предустановленных приложений.

- -

См. Тестирование производительности Firefox OS для подробностей.

-
- -

Как рендерит Gecko

- -

Движок Gecko JavaScript поддерживает just-in-time (JIT) компиляцию. Благодаря этому, логика приложения выполняется примерно так же, как это происходит в других приложениях на виртуальных машинах - например, Java Virtual Machines - а в некоторых случаях эффективность этих приложений близка к "нативному коду".

- -

Инструменты, необходимые для работы с HTML, CSS и Canvas оптимизированы несколькими путями. Например, композиция (этап, известный как Layout) в HTML/CSS и код, отвечающий за графику в Gecko, сделаны таким образом, чтобы уменьшить количество операций ревалидации и перерисовки для общих случаев (например, скроллинг); эти оптимизации включены "по умолчанию", поэтому разработчики пользуются ими бесплатно. Буферы пикселей, отрисованных как для Gecko "автоматически", так и для canvas "вручную", минимизируют количество копий, которые передаются в буфер кадров дисплея. Чтобы достичь этого, Gecko старается избегать создания промежуточных слоев (например, во многих других операционных системах создаются пиксельные фоновые буферы для каждого отдельного приложения), но взамен Gecko использует специальные участки памяти ддя хранения графических буферов. К этой памяти имеет прямой доступ железо, которое ответственно за формирование картинки. Сложные сцены рендерятся с использованием графического адаптера (видеокарты). А простые сцены, для экономии энергии, рендерятся специальным выделенным железом для композиции, в то время, как графический адаптер находится в режиме ожидания или выключен.

- -

Для продвинутых приложений полностью статичный контент скорее является исключением, чем правилом. Такие приложения используют динамический контент, анимируемый с помощью {{ cssxref("animation") }} и {{ cssxref ("transition") }}. Переходы и анимации особенно важны для приложений: разработчики могут использовать CSS для объявления сложного поведения с помощью простого высокоуровнего синтаксиса. С другой стороны, движок Gecko хорошо оптимизирован для того, чтобы рендерить такую анимацию эффективно. В целом, общепринятые анимации передаются к обработке системному компоновщику, который может отрендерить их в эффективном, энергосберегающем режиме. 

- -

Производительность запуска приложения так же важна, как и её текущая производительность. Gecko оптимизирован для того, чтобы загружать разнообразный контент эффективно: ведь Gecko впитал в себя опыт всего Web-а! Много лет Web улучшался, а разработчики улучшали его контент. Параллельный парсинг HTML, разумное выстраивание очереди перерисовки и декодирования изображений, умные алгоритмы компоновки и т.д.. Все эти оптимизации, конечно, улучшают и производительность Firefox OS.

- -
-

Заметка: смотрите Тестирование производительности Firefox OS для дополнительной информации о Firefox OS спецификациях, которые помогают оптимизировать производительность запуска.

-
- -

Производительность приложений

- -

Эта секция попытается ответить на вопрос "как сделать приложение быстрее?".

- -

Скорость загрузки

- -

Загрузка приложения может быть поделена на три этапа, которые влияют на UPP:

- - - -

Секрет быстрой загрузки требует двух вещей: UPP (ощущаемая пользователем скорость) - это единственное, что имеет значение; эта скорость зависит от критического пути рендеринга (Critical Rendering Path). Критический путь - это единственный и необходимый код, который должен запускать перечисленные выше события.

- -

Например, отрисовка первого кадра, который содержит в себе необходимый HTML и CSS включает:

- -
    -
  1. Браузер должен спарсить HTML
    2. -
  2. DOM должен быть построен для этого HTML
    3. -
  3. Ресурсы (изображения, видео и др.) для этой модели DOM должны быть загружены и декодированы
    4. -
  4. CSS стили должны быть применены к DOM и должен быть сформирован CSSOM
    5. -
  5. Стилизованный компонент должен быть подготовлен к рендеру
    6. -
- -

В этом списке вы не увидите "загрузить JS файл, который нужен для второстепенного меню", "забрать и декодировать изображения для списка достижений" и т.п. Эта работа не должна выполняться при запуске приложения.

- -

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

- -

Web-платформа очень динамична. JavaScript - это динамически типизированный язык, а Web разрешает загружать код, HTML, CSS, изображения и другие ресурсы динамически. Эти функции могут быть использованы для того, чтобы отложить загрузку ресурсов; чтобы сократить критический путь, подвинув загрузку лишнего контента на несколько моментов позже. Такой подход называется "ленивой загрузкой".

- -

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

- -
-

Заметка: Для дополнительной информации об ускорении запуска ознакомьтесь с Optimizing startup performance.

-
- -

Следует также отметить, что ресурсы, закешированные локально, могут быть загружены гораздо быстрее, чем динамические данные, загруженные через мобильную сеть с её задержками или узким каналом. Локальное кеширование и работа в оффлайне могут быть достигнуты с помощью Service Workers. См. Making PWAs work offline with Service workers для подробностей.

- -

Частота кадров

- -

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

- -

При отрисовывании контента в Canvas, разработчик должен сам позаботиться о достижении целей по частоте кадров, ведь он получает полный контроль над всем, что отрисовывается.

- -

При использовании HTML и CSS разработчику необходимо использовать правильные примитивы. Firefox очень хорошо оптимизирован для скролла любого контента. Обычно это не является проблемой. Но очень часто, разменивая качество и стабильность на скорость, мы идём на ухищрения, которые могут "переоптимизировать" страницу так, что частота кадров будет выше нужной нам. Так как глаз все равно слабо различает FPS больше 60, нет необходимости в таких оптимизациях. Одна из таких оптимизаций - использование статического рендера вместо CSS-градиента. В некоторых случаях это излишне. Чтобы не применять оптимизацию, вы можете воспользоваться CSS media queries, которые позволят использовать подобные решения только для конкретных устройств.

- -

Множество приложений используют Transitions и Animations для перехода между страницами или панелями. Например, когда пользователь нажимает кнопку "Настройки", чтобы перейти на другой экран; или для вызова поп-апа. Firefox оптимизирован для выполнения переходов и анимаций для сцен, которые:

- - - -

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

- -

Использование памяти и энергии

- -

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

- -

Современные ЦПУ могут работать в режиме энергосбережения, когда они не задействованы. Приложения, которые постоянно запускают таймеры или продолжают ненужные анимации, мешают процессору перейти в режим энергосбережения. Эффективные приложения не должны так делать.

- -

Когда приложение переходит в фоновый режим, срабатывает событие  {{event("visibilitychange")}}. Это событие - друг разработчика. Приложения должы слушать его и реагировать на него. Например, в Firefox OS, приложения, которые умеют ограничивать использование ресурсов и экономят память, когда переходят в фоновый режим, с меньшей долей вероятности будут отключены (см. заметку ниже). Это, если посмотреть с другой стороны, означает, что раз приложение не было выгружено - оно будет быстрее загружено.

- -
-

Заметка: Как было упомянуто выше, Firefox OS пытается сохранить как можно больше приложений, но иногда вынуждена приостанавливать некоторые из них. Обычно это происходит, когда у устройства заканчивается память. Чтобы узнать больше о том, как Firefox OS управляет памятью и избавляется от приложений, когда начинаются проблемы с памятью, читайте Debugging out of memory errors on Firefox OS.

-
- -

Советы к применению в коде

- -

Следующие советы помогут вам улучшить один или несколько факторов производительности, которые мы обсуждали ранее.

- -

Используйте CSS animation и transition

- -

Вместо использования функции  animate() какой-нибудь библиотеки, которая, вероятно, использует много плохих решений (например ({{domxref("window.setTimeout()")}} или анимирование top / left), используйте CSS анимации. Во многих случаях, вы можете использовать CSS Transitions. Использование этих свойств поможет, так как браузер спроектирован так, чтобы оптимизировать эти эффекты и переносить часть вычислений на GPU, чтобы они работали плавно и с минимальным влиянием на процессор. Другое преимущество - вы можете определить эти анимации в CSS декларативным образом, а не в бизнес-логике приложения.

- -

CSS анимации дают вам очень точный контроль эффектов, если вы используете keyframes. Более того, вы сможете отслеживать события, которые происходят во время анимации, так как основной поток обработки не блокируется. Вы можете с легкостью запускать анимации с помощью {{cssxref(":hover")}}, {{cssxref(":focus")}} или {{cssxref(":target")}}. Или динамически добавляя или удаляя классы элемента.

- -

Если вы хотите создавать анимации "на лету" или изменять их с помощью JavaScript, Джеймс Лонг написал простую библиотеку для этого - CSS-animations.js.

- -

Используйте CSS трансформацию

- -

Вместо того, чтобы изменять абсолютное позиционирование и возиться с этой математикой вручную, используйте свойство {{cssxref("transform")}}, чтобы изменить позицию, масштаб и некоторые другие аспекты вашего контента. Именно так вы используете аппаратное ускорение. Браузер умеет передавать такие задачи графическому процессору, давая возможность ЦПУ заняться другими важными вещами.

- -

К тому же, трансформация даёт возможности, которых в ином случае у вас не было бы. Вы не только можете манипулировать элементом в двумерном пространстве, но можете трансформировать его в 3D, изменять его наклон (скашивать, skew), поворачивать и др. Пол Айриш опубликовал статью in-depth analysis of the benefits of translate(), в которой проанализировал работу translate с точки зрения производительности. Используя translate/transform вы используете правильный декларативный инструмент и возлагаете оответственность за его оптимизацию на браузер. Вы так же получаете возможность с легкостью позиционировать элементы. Если вы будете использовать только top и left, вам придется написать некоторый дополнительный код, чтобы предусмотреть некоторые особенности такого позиционирования. И последний бонус - с Transform / Translate вы будете работать примерно так же, как работали бы с элементом canvas.

- -
-

Заметка: В некоторых случаях (в зависимости от платформы) вам может понадобиться добавить свойство translateZ(0.1), если вы хотите заставить клиента перенести вычисление анимаций на графический адаптер. Как было упомянуто выше, это может улучшить производительность, но увеличит потребление памяти. Какое из зол - меньшее - решать вам. Протестируйте оба варианта и выясните, что лучше подходит для вашего приложеия.

-
- -

Используйте requestAnimationFrame() вместо setInterval()

- -

Вызовы {{domxref("window.setInterval()")}} запускают код с учётом предполагаемой частоты кадров. Однако, эта ожидаемая частота и фактическая не всегда совпадают. SetInternal говорит браузеру "нарисуй результаты", даже если браузер не занимается сейчас отрисовкой - такое случается, когда графический адаптер ещё не дошел до следующего цикла обновления экрана. Такое несовпадение таймингов - чрезмерная растрата процессорного времени и даже может приводить к снижению срока службы аккумуляторов пользовательского устройств.

- -

Вместо этого, вам необходимо использовать {{domxref("window.requestAnimationFrame()")}}. Эта функция ждет, пока клиент не будет готов к формированию следующего кадра анимации и не будет досаждать своими запросами аппаратную часть устройства, если устройство не занимается в данный момент рендерингом. Другое преимущество этого API в том, что такие анимации не будут запускаться, пока ваше приложение не видно на экране (например, если оно выполняется в фоне или занимается другими операциями). Это сохранит батарею и защитит вас от проклятий, которые пользователи будут выкрикивать в небо.

- -

Делайте события мгновенными

- -

Как старомодные, заботящиеся о доступности веб-разработчики, мы любим событие нажатия, так как оно также срабатывает и для ввода с клавиатуры. На мобильных устройствах это работает иначе. Вы должны использовать {{event("touchstart")}} и {{event("touchend")}}, а не click. Причина этому - в мобильных устройствах срабатывает задержка в несколько сотен миллисекунд между касанием экрана и запуском обработчика click. Из-за этого приложение может ощущаться медленным. Если вы будете тестировать ваше приложение на предмет работы с касаниями, вы не пожертвуете доступностью. Кроме того, существуют библиотеки, которые ускорят разработку. Например, Financial Times использует библиотеку fastclick для обработки.

- -

Держите интерфейс простым

- -

Одна из самых больших проблем, которую мы нашли в HTML5 приложениях, заключается в том, что перенос большого количества DOM элементов делает приложение медленным - особенно, если в этих элементах много градиентов и теней. Упрощайте то, как выглядит ваше приложение и передвигайте проксирующий элемент, когда выполняете Drag And Drop - это сильно ускорит работу.

- -

Когда, например, у вас есть большой список элементов (скажем, твитов), не перемещайте их все. Вместо этого, держите в вашем DOM-дереве только те элементы, которые видимы и несколько за областью видимости, чтобы при скролле не было заметно моргание. Остальные - прячьте. Сохраняйте данные в JavaScript объектах, вместо хранения данных и доступа к ним в DOM. Думайте об экране, как об устройстве представления необходимых данных, а не всех. Это не означает, что вы не можете использовать HTML, как источник данных; просто читайте его один раз, а затем продвигайтесь на 10 элементов, изменяя содержимое первого и последнего элемента, согласно их позициям в списке, вместо того, чтобы двигать 100 элементов, которые уже невидимы. Подобный трюк сработает и в играх со спрайтами: если они не видны на экране, нет необходимости запрашивать их. Вместо этого переиспользуйте элементы, которые выходят за пределы экрана, в то время как новые входят.

- -

Общий анализ производительности

- -

Firefox, Chrome и другие браузеры предоставляют встроенные инструменты, которые могут помочь вам диагностировать медленный рендеринг. В частности, Firefox's Network Monitor покажет точное время, когда произошел каждый сетевой запрос, насколько большим он был и как долго обрабатывался.

- -

The Firefox network monitor showing get requests, multiple files, and different times taken to load each resource on a graph.

- -

Если на вашей странице есть JavaScript, который выполняется очень долго, JavaScript profiler  укажет на наиболее медленные строки кода.

- -

The Firefox JavaScript profiler showing a completed profile 1.

- -

Встроенный Gecko Profiler - очень полезный инструмент, который позволяет вам получить ещё более подробную информацию о том, какие части кода работают медленно. Это довольно сложный инструмент, но он предоставляет множество деталей.

- -

A built-in Gecko profiler windows showing a lot of network information.

- -
-

Заметка: Вы можете использовать эти инструменты и в Android браузере, запустив Firefox и включив remote debugging.

-
- -

Например, множественные сетевые запросы в мобильной сети занимают больше времени. Рендеринг больших изображений и CSS градиентов может происходить дольше. Простое скачивание больших изображений может занять большее время, даже через быструю сеть, так как аппаратная часть мобильных устройств зачастую слишком медленна, чтобы использовать все возможности быстрых каналов данных. Для получения полезных подсказок о производительности на мобильных устройствах, ознакомьтесь с докладом Максимилиано Фёртмана Mobile Web High Performance.

- -

Тестовые кейсы и сообщения об ошибках

- -

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

- -

Убедитесь, что вы можете воспроизвести проблему, просто сохраняя и загружая статическую копию HTML-страницы (включая изображения/стили/скрипты). Если так - удалите из HTML файла всю личную информацию и обратитесь к за помощью (отправьте отчет в Bugzilla или, например, сохраните файл на своем сервере и поделитесь ссылкой). Вам также понадобится поделиться информацией профилировщика, которую вы собрали с помощью инструментов отладки.

diff --git "a/files/ru/web/performance/\320\277\321\200\320\276\320\270\320\267\320\262\320\276\320\264\320\270\321\202\320\265\320\273\321\214\320\275\320\276\321\201\321\202\321\214_\320\260\320\275\320\270\320\274\320\260\321\206\320\270\320\270/index.html" "b/files/ru/web/performance/\320\277\321\200\320\276\320\270\320\267\320\262\320\276\320\264\320\270\321\202\320\265\320\273\321\214\320\275\320\276\321\201\321\202\321\214_\320\260\320\275\320\270\320\274\320\260\321\206\320\270\320\270/index.html" deleted file mode 100644 index 8d8054dade..0000000000 --- "a/files/ru/web/performance/\320\277\321\200\320\276\320\270\320\267\320\262\320\276\320\264\320\270\321\202\320\265\320\273\321\214\320\275\320\276\321\201\321\202\321\214_\320\260\320\275\320\270\320\274\320\260\321\206\320\270\320\270/index.html" +++ /dev/null @@ -1,174 +0,0 @@ ---- -title: Производительность анимации и частота кадров -slug: Web/Performance/Производительность_анимации -tags: - - CSS animation - - Developer Tools - - Web Performance - - Анимация - - Производительность - - инструменты -translation_of: Web/Performance/Animation_performance_and_frame_rate ---- -

Анимация в Вебе может быть сделана с помощью {{domxref('SVGAnimationElement', 'SVG')}}, {{domxref('window.requestAnimationFrame','JavaScript')}}, включая {{htmlelement('canvas')}} и {{domxref('WebGL_API', 'WebGL')}}, CSS {{cssxref('animation')}}, {{htmlelement('video')}}, анимированных GIF и даже с помощью анимированных PNG и других типов изображений. Производительность CSS анимации может отличаться от одного CSS-свойства к другому, а попытка анимировать некоторые "дорогие" CSS-свойства может привести к зависаниям ({{glossary('jank')}}), даже несмотря на то, что браузер борется за то, чтобы смягчить частоту смены кадров {{glossary('frame rate')}}.

- -

Для анимированных медиа, таких как видео и GIF, основная проблема производительности - это размер файлов. Скачивание больших по объему файлов не может не повлиять на производительность системы или на то, как эту систему воспринимает пользователь. 

- -

Анимации, основанные на коде, будь то CSS, SVG, <canvas>, webGL или другие JavaScript анимации, могут нести проблемы производительности сами в себе, даже если файлы этого кода скачиваются быстро. Такие анимации могут потреблять всё время CPU и приводить к зависаниям.

- -

Несомненно, производительность каждой конкретной системы - очень чувствительная тема. Улучшив клиентскую производительность, вы сможете не только ускорить работу приложения, но даже затронете физический аспект - сможете сэкономить заряд батареи мобильных устройств и / или понизите температуру устройства. Поэтому очень важно владеть инструментами для измерения производительности. Они помогут вам понять всю работу, которую проводит браузер, пока рендерит ваше приложение и поможет избежать и диагностировать проблемы, когда они происходят.
-
- Пользователи ожидают, что взаимодействие с интерфейсом будет плавным, а интерфейс будет отзывчивым. Анимация помогает улучшить восприятие приложения, сделав его быстрым и отзывчивым; но анимация так же может замедлить его и привести к зависаниям, если она сделана неумело. Отзывчивые интерфейсы должны иметь частоту смены кадров, равную 60 кадров в секунду (fps). В то время, как не всегда возможно поддерживать такую частоту, очень важно поддерживать быструю и устойчивую смену кадров для анимации. 

- -

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

- -

Графики frame rate и waterfall из встроенных инструментов браузера дают информацию о том, как браузер выполняет работу по анимации. Используя эти инструменты, вы можете измерить fps приложения и диагностировать узкие места, в которых fps уменьшается.

- -

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

- -

Если сравнивать анимацию с помощью JavaScript и CSS, вы увидите, что CSS-анимации проще создать. Более того, CSS-анимации гарантируют лучшую производительность, так как они автоматически делегируют некоторые задачи браузеру. Например, в случае CSS браузер сам решает, когда нужно отрендерить кадр, а когда пропустить кадр, если это необходимо. 

- -


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

- -

Стоит заметить, что 60 кадров в секунду - это стандартная частота обновления экрана. Существуют экраны с гораздо большим FPS. Например, экраны игровых ноутбуков или iPad Pro 2018 имеют частоту смены кадров, равную 120 fps и выше. Для таких устройств производители браузеров ограничивают частоту 60-ю кадрами в секунду, но с помощю некоторых опций этот лимит можно убрать. И в этом случае, на формирование каждого кадра устройство будет отводить лишь 8.6 миллисекунд.

- -

Этапы рендеринга

- -

Процесс, используемый браузером для отображения анимации CSS свойств, может быть представлен как последовательность этапов из следующего изображения:

- -

- -
    -
  1. Recalculate Style: когда любое CSS свойство для элемента изменяется, браузер должен заново вычислить результирующий набор свойств.
    2. -
  2. Layout: затем браузер использует вычисленные стили для того, чтобы понять позицию и геометрию элементов - как измененного, так и рядом лежащих. Эта операция называется "layout", но иногда её так же называют "reflow".
    3. -
  3. Paint: наконец, браузер должен перерисовать элементы на экране. Но этот этап не обязательно должен быть простым, как на изображении. Страница может быть разделена на слои, каждый из которых перерисовывается независимо, а только после этого они комбинируются в процессе, который называется композицией "Composition".
    4. -
- -

Процессы, которые браузер использует для отрисовывания изменений на элементе <canvas> отличаются. В случае <canvas>, Layout не присходит. Скорее, страница будет перерисована с помощью JavaScript canvas API. 

- -

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

- -

Стоимость CSS свойств

- -

На всех этапах рендеринга изменение некоторых свойств является более затратным, других - менее:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
Тип свойстваСтоимостьПримеры
Свойства, затрагивающие геометрию или позицию элемента, запускают весь процесс заново: новое вычисление стилей, layout и перерисовку. -

left
- max-width
- border-width
- margin-left
- font-size

-
-

Свойства, не затрагивающие геометрию и позиционирование элементов, но не лежащие в отдельном слое, запускают только вычисление стилей и перерисовку, но не Layout.

- 		-

color

-
-

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

- 		transform
- opacity
- -
-

На Веб-сайте CSS Triggers хорошо показано, какие CSS свойства вызывают те или иные этапы обновления в разных браузерах.

-
- -

Пример: margin против transform

- -

В этом разделе мы увидим, как инструмент Waterfall может указать на разницу между анимацией. ёё margin  и transform.

- -

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

- -

Если вы хотите самостоятельно разобраться с этим примером, вы можете найти демо здесь. Демо выглядит так:

- -

На экране всего два контрола: кнопка "start / stop" для запуска и остановки анимации и радио-кнопки для выбора свойства, с помощью которого происходит анимация:  margin, или transform.

- -

Так же на странице есть некоторое количество элементов со свойствами  linear-gradient и box-shadow Мы обращаем внимание именно на эти два свойства, так как они относительно дорогие.

- -

Так же существует видео-версия анализа и оптимизации этой страницы.

- -

{{EmbedYouTube("Tvu6_j8Qzfk")}}

- -

Анимация свойства margin

- -

Оставим включенной опцию "Use margin" и начнём анимацию. В это же время откроем "Performance tool" и нажмем кнопку "записать" (make a recording). Нам понадобится лишь пара секунд записи.

- -

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

- -

- -

На экране показаны три отдельных секции: (a) обзор этапов рендеринга (Waterfall), (b) частота кадров, и (c) детали на временной шкали.

- -

Обзор этапов рендеринга на временной шкале (Waterfall)

- -

- -

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

- -

Частота кадров (Frame Rate)

- -

- -

Эта секция показывает частоту кадров. Средняя частота на примере - 46.67fps. Это ниже, чем желаемые 60fps. Однако, ещё хуже то, что частота кадров нестабильна - есть этапы, где частота кадров снижается до 20 и даже до 10 fps. Маловероятно, что вы увидите здесь плавную анимацию, особенно если добавите какое-то взаимодействие с пользователем.

- -

Этапы рендеринга в деталях (Waterfall)

- -

Оставшаяся часть записей показа в секции "Waterfall view". Если вы пролистаете этот список, вы увидите что-то наподобие этого:

- -

- -

Это шаги рендеринга (rendering waterfall). Для каждого кадра анимации мы вычисляем стили для каждого элемента, потом вычисляем Layout, а затем перерисовываем все элементы.

- -

Из таблицы видно, что особый урон производительности наносит перерисовка Paint (зелёные полосы). Например, выделенный этап Paint занял 13.11мс. Учитывая, что весь бюджет рендеринга - 16.7мс, неудивительно, что мы увидели падения fps.

- -

Вы можете поэкспериментировать с некоторыми свойствами. Например, попробуйте убрать box-shadow с помощью инспектора страницы (Page / Element Inspector), замерьте производительность и посмотрите, как это отразилось на производительности. Затраты на Paint уменьшатся значительно. Но они все ещё есть. Мы ещё вернёмся к этому вопросу позже, когда будем изучать использование transform вместо margin. Вы увидите, что от затрат на этот этап можно избавиться полностью.

- -

Анимация свойства transform

- -

Теперь, переключитесь на "Use transform" и запишите новые данные. Это должно выглядеть примерно так:

- -

- -

Обзор этапов рендеринга на временной шкале (Waterfall)

- -

- -

В сравнении с версией, которая использует margin, мы видим намного меньше зеленого, но намного больше фиолетового цвета. Это говорит о том, что вместо paint мы теперь тратим ресурсы на этапы layout или style recalculation.

- -

Частота кадров (Frame Rate)

- -

- -

В сравнении с версией, которая использует margin, показатели fps здесь выглядят достаточно хорошо. Средняя частота кадров близка к 60fps, а стабильность fps, за исключением падения fps в начале значительно выросла.

- -

Этапы рендеринга в деталях (Waterfall)

- -

В этой секции мы видим объяснения тому, что fps значительно улучшился. Мы больше не тратим время на layout и перерисовку элементов. :

- -

- -

Здесь, используя transform, мы заметно улучшили производительность приложения. А инструменты разработчика помогли нам это сделать.

-- cgit v1.2.3-54-g00ecf