Как лучше писать CSS с производительностью в уме
В сегодняшнем посте мы рассмотрим варианты кода, которые мы можем сделать в CSS для повышения производительности сайта. Но, прежде чем мы углубимся в этот выбор, давайте сначала кратко рассмотрим рабочий процесс рендеринга веб-страницы, чтобы сосредоточиться напроблемные (с точки зрения производительности) области, которые можно решить с помощью CSS.
Вот примерный поток операций, выполняемых браузером после создания дерева DOM:
- Пересчитать стиль (и отрисовать создание дерева). Браузер вычисляет стили, которые будут применены к элементам в дереве DOM. Дерево рендеринга позже создается при отбрасывании узлов (элементов) из дерева DOM, которые не должны быть визуализированы (элементы с
нет дисплей: нет
) и те, которые есть (псевдоэлементы). - Макет (он же Reflow). Используя ранее вычисленный стиль, браузер рассчитывает положение и геометрию каждого элемента на странице..
- перекрашивание. После отображения макета пиксели выводятся на экран..
- Композитные слои. Во время перекраски, живопись может быть выполнена в разных слоях автономно; эти слои затем окончательно объединяются.
Теперь давайте перейдем к тому, что мы можем сделать на первых трех этапах операции для написания более эффективных CSS-кодов..
1. Уменьшить стиль расчета
Как упоминалось ранее, на этапе «Пересчитать стиль» браузер вычисляет стили, которые будут применены к элементам. Для этого браузер сначала обнаруживает все селекторы в CSS, которые указывают на данный узел элемента в дереве DOM. Затем он просматривает все правила стиля в этих селекторах и решает, какие из них должны быть применены к элементу..
Чтобы избежать дорогостоящих расчетов стиля, уменьшить сложные и глубоко вложенные селекторы чтобы браузеру было проще выяснить, к какому элементу относится селектор. Это сокращает время вычислений.
Другие способы трудоустройства включают сокращение количества стилевых правил (где возможно), удаление неиспользуемого CSS и избегая избыточность и переопределения, чтобы браузеру не приходилось повторять один и тот же стиль снова и снова во время расчета стиля.
2. Уменьшить оттоки
Изменения перекомпоновки или компоновки в элементе являются очень «дорогими» процессами, и они могут представлять еще большую проблему, когда элемент, прошедший через изменения компоновки, имеет значительное количество дочерних элементов (поскольку Каскад оплавлений вниз по иерархии).
Перекомпоновки инициируются изменениями макета элемента, такими как изменения геометрических свойств, таких как высота или размер шрифта, добавление или удаление классов для элементов, изменение размера окна, активация : парить
, DOM изменяется с помощью JavaScript и т. Д..
Так же, как в стиле расчета, чтобы уменьшить Reflows, избегать сложных селекторов а также глубокие DOM-деревья (опять же, это для предотвращения чрезмерного каскадирования Reflow).
Если вам нужно изменить стили макета компонента на вашей странице, целевые стили элемента, который находится на самом низком уровне в иерархии элементов что компонент сделан из. Это сделано для того, чтобы изменения макета не вызывали (почти) любые другие рефлоу.
Если вы анимируете элемент, который проходит изменения макета, уберите это из потока страниц от абсолютное позиционирование, поскольку Reflow в абсолютно позиционированных элементах не повлияет на остальные элементы на странице.
Чтобы подвести итог:
- Целевые элементы, которые находятся ниже в дереве DOM при внесении изменений в макет
- Выберите абсолютно позиционированные элементы для анимации с изменением макета
- Избегайте анимации свойств макета, когда это возможно
3. Уменьшить перекрашивание
Перекраска относится к рисованию пикселей на экране и является дорогостоящим процессом, как и Reflow. Перекраска может быть вызвана перекомпоновкой, прокруткой страницы, изменением таких свойств, как цвет, видимость и непрозрачность..
Чтобы избежать частых и огромных перекрашиваний, использовать меньше свойств, которые вызывают дорогостоящие перекраски как тени.
Если вы анимируете свойства элемента, который может инициировать перерисовку прямо или косвенно, это будет большим преимуществом если этот элемент находится в своем собственном слое предотвращение влияния его рисования на остальную часть страницы и запуск аппаратного ускорения. При аппаратном ускорении GPU будет выполнять задачу изменения анимации в слое, сохраняя дополнительную нагрузку на CPU и ускоряя процесс..
В некоторых браузерах, помутнение
(со значением менее 1
) а также преобразование
(значение, отличное от никто
) автоматически переходят на новые слои, а для анимации и переходов применяется аппаратное ускорение. Предпочтение этих свойств для анимации, таким образом, хорошо.
Насильно продвинуть элемент на новый уровень и перейти к аппаратному ускорению для анимации используются две техники:
- добавлять
transform: translate3d (0, 0, 0);
к элементу, обманывая браузер в запуске аппаратного ускорения для анимации и переходов. - добавить
изменится
свойство элемента, которое информирует браузер о свойствах, которые могут измениться в элементе в будущем. ЗаметкаСара Соуидан имеет подробную и очень полезную статью на сайте Dev.Opera..
Чтобы подвести итог:
- Избегайте дорогих стилей, которые вызывают перекраски
- Ищите продвижение слоя и аппаратное ускорение для здоровенных анимаций и переходов.
Принять к сведению
(1) Итак, до сих пор мы не касались уменьшения размера файла CSS. Мы уже упоминали, что сокращение правил стиля (и элементов DOM) значительно повышает производительность из-за сколько браузер должен будет работать Меньше на процесс вычисления стилей. Как следствие этого сокращения кода, написание лучших селекторов и удаление неиспользуемого CSS, размер файла будет автоматически уменьшаться.
(2) Также желательно не вносите слишком много последовательных изменений в стили элемента в JavaScript. Вместо этого добавьте класс к элементу (используя JavaScript), который содержит новые стили для внесения этих изменений - это предотвращает ненужные Reflow.
(3) вам захочется избегать разметки также (принудительные синхронные Reflow), возникающие из-за доступа и изменения свойств Layout элементов с использованием JavaScript. Узнайте больше о том, как это убивает производительность здесь.