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

В документации для скорости страницы Google есть раздел об использовании эффективных селекторов CSS . В нем упоминается, как селектор-потомок неэффективен, потому что, как только правый правый селектор был сопоставлен, «браузер должен [также] пересекать дерево DOM, оценивая каждый элемент предка, пока не найдет совпадение или не достигнет корневого элемента». Mozilla даже говорит, что «селектор потомков - самый дорогой селектор в CSS». Так div.photo-column{...}было бы предпочтительнее div.result-row div.photo-column{...}.

В нем также упоминается, что вам следует удалять избыточные квалификаторы, такие как «селекторы классов, которые квалифицируются с помощью селекторов тегов (когда класс используется только для одного тега, что является хорошей практикой дизайна в любом случае)». Это имеет смысл, потому что если у вас div.photo-column{...}вместо .photo-column{...}браузера есть два чека, один для проверки класса = «фото-столбец», и если это правда, нужно проверить, является ли элемент div, а не просто проверять класс, если это все, что вы укажете.

Это должно влиять только на размер файла и, следовательно, на время загрузки.

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

в развитие

div.result-row{...}
div.result-row div.photo-column{...}
div.result-row div.main-column{...}
div.result-row div.main-column div.text-row{}
div.result-row div.main-column div.date-row{}
div.result-row div.action-column{...}

жить

.result-row{...}.photo-column{...}.main-column{...}.text-row{}.date-row{}.action-column{...}

РЕДАКТИРОВАТЬ

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

Однако это все равно не влияет на прокрутку.

Прочтите:

http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/ http://code.google.com/speed/page-speed/docs/rendering.html# UseEfficientCSSSelectors https://developer.mozilla.org/en/Writing_Efficient_CSS

CSS не приведет к вялой прокрутке. Что может быть, однако, фиксированным фоном (через background-attachment: fixed). По моему опыту, я заметил, что они склонны замедлять работу браузера при прокрутке, так что это наиболее вероятно. Если вы не используете какие-либо из них, просто проверьте, не используете ли вы огромные фоновые изображения.

Быть осторожен. Удаление и добавление возможностей для ваших селекторов изменяет приоритет правил и может привести к неожиданным результатам на выходе вашей продукции.

Минимизация переоценена. Современные, хорошо настроенные веб-серверы отправят gzip'ed CSS, который очень эффективно разрушит пробелы и повторяющиеся слова. Повышение производительности нескольких K за CSS-файл не воспринимается людьми, использующими что-либо быстрее, чем модем 56k. В отличие от одного изображения в формате JPEG 100 ? 100 px, можно легко использовать большую пропускную способность, чем ваши файлы CSS и JS.

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

Что касается того, как это влияет на скорость рендеринга, я не знаю, однако я подозреваю, что это зависит от реализации (зависит от браузера).

Удаление имен тегов не собирается ничего делать, кроме сохранения нескольких байтов из размера файла. Я считаю, что нотация elm.className более понятна, чем просто бросать в нее только селектора классов. Не говоря уже о том, что удаление тегов изменит уровень специфичности этого правила. Для сложных (или плохо написанных) макетов CSS это может иметь некоторые очень необычные последствия. Повышение производительности будет ограничено несколькими дополнительными символами, которые синтаксический анализатор CSS не должен читать, что будет незаметным.