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

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

Paul Lewis

Sam Thorogood

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

• Позаботьтесь о том, чтобы ваша анимация не вызывала проблем с производительностью; убедитесь, что вы знаете, какое влияние оказывает анимация данного свойства CSS.
• Анимационные свойства, которые изменяют геометрию страницы (макета) или вызывают раскраску, стоят особенно дорого.
• Там, где это возможно, придерживайтесь изменения трансформаций и непрозрачности.
• Используйте will-change , чтобы убедиться, что браузер знает, что вы планируете анимировать.

Анимация свойств не бесплатна, и некоторые свойства анимировать дешевле, чем другие. Например, анимация width и height элемента меняет его геометрию и может привести к перемещению или изменению размера других элементов на странице. Этот процесс называется макетом (или перекомпоновкой в ​​браузерах на базе Gecko, таких как Firefox) и может быть дорогостоящим, если на вашей странице много элементов. Всякий раз, когда запускается макет, страницу или ее часть обычно необходимо отрисовать, что обычно обходится даже дороже, чем сама операция макета.

По возможности следует избегать анимации свойств, которые запускают макет или рисование. Для большинства современных браузеров это означает ограничение анимации opacity или transform , оба из которых браузер может оптимизировать; не имеет значения, обрабатывается ли анимация JavaScript или CSS.

Прочтите полное руководство по созданию высокопроизводительной анимации .

Использование свойства will-change

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

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

.box {
  will-change: transform, opacity;
}

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

CSS и производительность JavaScript

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

• Анимации на основе CSS и веб-анимации, если они поддерживаются изначально, обычно обрабатываются в потоке, известном как «поток композитора». Это отличается от «основного потока» браузера, где выполняются стилизация, макет, рисование и JavaScript. Это означает, что если браузер выполняет какие-то ресурсоемкие задачи в основном потоке, эти анимации могут продолжать работать без прерывания.

• Другие изменения в преобразованиях и непрозрачности во многих случаях также могут обрабатываться потоком наборщика.

• Если какая-либо анимация запускает рисование, макет или и то, и другое, для выполнения работы потребуется «основной поток». Это справедливо как для анимации на основе CSS, так и для анимации JavaScript, а затраты на макетирование или рисование, скорее всего, затмят любую работу, связанную с выполнением CSS или JavaScript, что сделает вопрос спорным.