Что случилось с правилом «Использовать эффективные CSS-селектора»?

Была рекомендация Google PageSpeed, которая попросила веб-разработчиков использовать эффективные селектора CSS :

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

Детали

Когда браузер анализирует HTML, он создает внутреннее дерево документов, представляющее все элементы, которые будут отображаться. Затем он сопоставляет элементы со стилями, указанными в разных таблицах стилей, в соответствии со стандартными каскадами CSS, наследованием и правилами упорядочения. В реализации Mozilla (и, возможно, и других) для каждого элемента механизм CSS ищет по правилам стиля, чтобы найти совпадение. Двигатель оценивает каждое правило справа налево, начиная с самого правого селектора (называемого «ключом») и перемещаясь через каждый селектор, пока не найдет совпадение или не сбросит правило. («Селектор» – это элемент документа, к которому должно применяться правило).

Согласно этой системе, чем меньше правил, тем лучше двигатель должен оценивать. […]. После этого для страниц, содержащих большое количество элементов и / или большого количества правил CSS, оптимизация определений самих правил также может повысить производительность. Ключом к оптимизации правил является определение правил, которые являются настолько конкретными, насколько это возможно, и избегают ненужного избыточности, чтобы позволить движку стиля быстро находить совпадения, не применяя при этом правила оценки времени, которые не применяются.

Эта рекомендация была удалена из текущих правил скорости страницы . Теперь мне интересно, почему это правило было удалено. Улучшили ли браузеры соответствующие правила CSS? И эта рекомендация действительна?

В феврале 2011 года основной разработчик Webkit Антти Койвисто сделал несколько улучшений производительности селектора CSS в Webkit.

Антти Койвисто преподавал CSS Style Selector, чтобы пропустить селектор и более быструю сортировку, что привело к некоторым незначительным улучшениям, после чего он приземлился еще на два более удивительных патча: один, который позволяет фильтровать идентификатор предка для построения дерева, уменьшая время на совпадение стиля по сравнению с типичная загрузка страницы и быстрый путь для простых селекторов, которые ускоряют сопоставление еще 50% на некоторых веб-сайтах.

Производительность селектора CSS изменилась! (К лучшему) Николь Салливан более подробно рассматривает эти улучшения. В итоге –

Согласно Antti, прямые и косвенные смежные комбинаторы все еще могут быть медленными, однако фильтры предков и hashи правил могут снизить влияние, поскольку эти селекторы будут редко встречаться. Он также говорит, что для webkit по-прежнему существует много возможностей для оптимизации псевдо-classов и элементов, но независимо от того, что они намного быстрее, чем пытаться сделать то же самое с манипуляциями JavaScript и DOM. На самом деле, хотя есть еще возможности для улучшения, он говорит:

«Используемый в модерации почти все будет прекрасно работать с точки зрения соответствия стиля».

В то время как браузеры намного быстрее подходят для селекторов CSS, стоит повторить, что селектора CSS все равно должны быть оптимизированы (например, как можно более «плоские»), чтобы уменьшить размер файлов и избежать проблем с конкретностью.

Вот основательная статья (датированная в начале 2014 года)

Я цитирую Benjamin Poulain , инженера WebKit, который много рассказал о тесте производительности селекторов CSS:

~ 10% времени тратится на растеризатор. ~ 21% времени тратится на первый макет. ~ 48% времени затрачено на парсер и создание дерева DOM ~ 8% тратится на разрешение стиля ~ 5% тратится на сбор стилей – это то, что мы должны тестировать и что должно занимать большую часть времени. (Оставшееся время распространяется на многие многие функции)

И он продолжает:

«Я полностью согласен, что бесполезно оптимизировать селектора, но по совершенно другим причинам:

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

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

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

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

Например, существуют подходы, например BEM , которые позволяют максимально упростить CSS, чтобы минимизировать зависимость иерархии DOM и отделить веб-компоненты, чтобы они могли «перемещаться» по DOM и работать независимо.

Может быть, потому, что теперь выполнение CSS для CMS или фреймворков более распространено, и трудно избежать использования общих селекторов CSS. Это позволяет ограничить сложность таблицы стилей.

Кроме того, современные браузеры очень быстро работают с CSS. Даже с огромными таблицами стилей в IE9, не было похоже, что рендеринг был медленным. (Должен признаться, я тестировал на хорошем компьютере. Может быть, есть тесты).

В любом случае, я думаю, вы должны написать очень неэффективный CSS, чтобы замедлить Chrome или Firefox …

Есть 2-летняя должность в производительности @ Какие CSS-селектора или правила могут существенно повлиять на внешний интерфейс / рендеринг в реальном мире?

Мне нравится его однострочный вывод: все, что в пределах «да, этот CSS имеет смысл», в порядке.