EN
Виталя Харисов
Виталя Харисов
10 августа 2009
Read-only

Браузеры рассматривают селекторы cправа налево. Например, при нахождении элемента <a> в дереве документа будут выбраны все селекторы с a или * на конце и будет осуществлён просмотр вверх по дереву в поисках элементов входящих в селектор до тех пор пока не будут найдены подходящие элементы, не станет понятно, что селектор не применим или не будет достигнут конец документа.

Т.е. в случае селекторов .b-services li a и .b-user a (Tag Rules) оба они будут испробованы для каждой ссылки на странице.

Источники, подтверждающие это:

  1. Writing Efficient CSS for use in the Mozilla UI
  2. Faster HTML and CSS: Layout Engine Internals for Web Developers


Наглядный пример: 30 тысяч div'ов на странице, селекторы заканчиваются на .text (рефлоу 5 секунд) и на div (рефлоу 37 секунд, осторожно! браузер замерзает, а потом оттаивает).

Чем больше Tag Rules на странице, тем медленнее страница отрисовывается. Для того, чтобы вёрстка была масштабируемой, чтобы на одних и тех же подходах можно было сделать и «Home Page для кота» и почту Яндекса надо найти универсальное решение, которое подходит на все случаи жизни.

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

Открытым вопросом пока остаётся влияют ли на скорость применения селекторов наличие селекторов которые ничего не матчат, надо написать тесты.




Другие проблемы вёрстки и их решения в следующих выпусках нашего журнала. Оставайтесь на проводе.

#alexeyten
10 августа 2009
Остаётся открытым вопрос необходимости и осмысленности фреймворка одинаково подходящего и для «Home Page для кота» и для почты Яндекса. Кажется, что фреймворк подходящий для почты любого хомяка разорвёт на куски.
#new-direct-ui
10 августа 2009
> Открытым вопросом пока остаётся влияют ли на скорость применения селекторов наличие селекторов которые ничего не матчат, надо написать тесты. Судя по тому, что в Google Page Speed явным образом присутствует рекомендация не включать в страницу неиспользуемые правила - таки да, влияет. Другой вопрос, актуально ли это правило для всех имплементаций. Ведь в принципе в браузерных движках возможны оптимизации такого рода - OK, селекторы надо парсить справа налево, чтобы сфейлиться как можно раньше; с другой стороны, если селектор неэффективен (#id .class .class element) давайте перед тем, как матчить справа налево, поматчим самый эффективный селектор - если сматчим, продолжим as usual.
#dreamwind1984
16 августа 2009
WebKit вообще интересно к селекторам подходит. Надеюсь, получить ответ на свое письмо. 

И также стоит уточнить: по-видимому, не имеет значения, тег у нас в конце стоит или класс. Имеет значение только число этих тегов или классов на странице (число элементов, на которые правила накидываем). Таким образом правило "не используем тегов" будет не совсем верным: мы можем использовать редкие теги только для специфических случаев, тогда они будут отрабатывать так же, как классы, а "хлама" в HTML будет меньше.

Проблема "универсальных" селекторов остается, но при большом количестве CSS-правил она нивелируется (глобальный reset на скорость никак не повлияет с учетом того количества дефолтных CSS-правил, что браузеры сами на страницу накидывают).
#petrouv
24 августа 2009
Влияет ли на скорость рендеринга длина имени класса?
Или длина имени влияет только на общий объем страницы?
Общий объем страницы насколько я понимаю влияет только на то, сколько браузер будет загружать ее в память и на объем занятой памяти?
Если есть две страницы с одинаковым DOM деревом, но из-за разных длин имен классов размер html файла разный, значительна ли будет разница в производительности?
#vomixamxam
26 августа 2009
Такое решение, на мой взгляд, это использование абсолютно-независимых блоков для вёрстки всех-всех блоков на странице

Вы неискажающие блоки обратно переименовали?

А, вообще, мне эта идея очень нравится ещё и потому, что она решает серьёзную проблему в новом ULL (которая появилась в контексте отказа от собственной семантической разметки в пользу YACF-разметки).

#almazmusic
14 марта 2010
По-моему это не совсем рационально, т.к. общий размер файла стилей (я так понимаю мы всё же больше о Яндексе, чем о блоге кота говорим) выростет в любом случае. По мимо этого почему уж тогда не отказаться от модульности вида .b-icon.i-bullet-1>i сразу к .b-i-bullet-1>i, ведь опять же, если иконок будет 30 тыс., то рендер с доп.классом (в конкретном случае якобы равносилен глобал ресету) тоже будет дольше, чем "напрямую". Но от этого размер файла выростет просто нереально правда, зато Вы получите ещё несколько процентов.

На счёт ускорения рендера в других браузерах в 2-5 раз - это, насколько я понимаю, 200-500%, а Вы вроде бы говорили о 5-7%. Как-то не логично в общем.

Опять же, не знаю насколько большим должен быть проект, чтобы идти на такое. А проекты в 20-50 страниц верстки, имхо, такого геморроя не стоят.
#vitaly
15 марта 2010
По-моему это не совсем рационально, т.к. общий размер файла стилей (я так понимаю мы всё же больше о Яндексе, чем о блоге кота говорим) выростет в любом случае.
Не верно. Перейдя к АНБ мы можем обфусцировать классы и можем делать ещё кое-какие оптимизации, которых до этого не могли делать. Т.ч. размер файла вполне может быть меньше, чем в классическом подходе. Ну или не катастрофически больше.
По мимо этого почему уж тогда не отказаться от модульности вида .b-icon.i-bullet-1>i сразу к .b-i-bullet-1>i, ведь опять же, если иконок будет 30 тыс., то рендер с доп.классом (в конкретном случае якобы равносилен глобал ресету) тоже будет дольше, чем "напрямую". Но от этого размер файла выростет просто нереально правда, зато Вы получите ещё несколько процентов.
Ничего не понял.
На счёт ускорения рендера в других браузерах в 2-5 раз - это, насколько я понимаю, 200-500%, а Вы вроде бы говорили о 5-7%. Как-то не логично в общем.
5-7% съедает global reset. Ускорение в 2-5 раз удалось получить отказавшись от имён элементов в селекторах, отказавшись от каскада.
Опять же, не знаю насколько большим должен быть проект, чтобы идти на такое. А проекты в 20-50 страниц верстки, имхо, такого геморроя не стоят.
В чём именно вы видите гемморой? Писать АНБ проще и более надёжнее.
#almazmusic
15 марта 2010
 
В чём именно вы видите гемморой?
 Ну лично мне почему-то кажется, что временные затраты увеличатся, если без каскадирования повторять одни и теже локальные ресеты практически на каждом селекторе. Да и писать куче блоков множество одного и того же сброса это и плюс ко времени и плюс к размеру. Либо я просто не понял чего-то.
#Wolfsbay
15 марта 2010
Кстати, никогда не замечал тормозов рендера (если на странице нет кучи jQuery-скриптов), может они есть на пентиум-2.
#vitaly
15 марта 2010
Откуда на каждом селекторе? Посчитайте сколько у вас ul/li/hN и сколько у вас div/span в документе. Потом посмотрите в Firebug'е сколько раз вы перекрываете то, что сбросили до этого ресетом.
#vitaly
15 марта 2010
Ну а мы заметили, когда начали делать действительно интерактивное приложение.
#almazmusic
15 марта 2010
Ладно, я просто не знаю как объяснить, но раз всё нормально, то видимо я всё-таки чего-то недопонял.
#
26 июля 2014

 

на div (рефлоу 37 секунд, осторожно! браузер замерзает, а потом оттаивает).

231 ms. Привет из 2014