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

Мне было интересно, что делают эксперты, когда дело доходит до написания кода CSS. Разве плохо использовать стиль tagname.className? Вызывает ли наследование заметную потерю производительности? Влияет ли это только на браузер при загрузке страницы или также после? Например: пользователь прокручивает страницу дальше, будет ли плохой CSS причиной для медленной прокрутки при просмотре страницы с большим количеством строк результатов?

Примеры 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{...}

против

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

Моя страница выводит много пользовательских сообщений, подобных этой ...

<div class="result-row clearfix">
    <div class="photo-column">
        <img src="..." />
    </div>
    <div class="main-column">
        <div class="text-row">
            User's text
        </div>
        <div class="date-row">
            Today
        </div>
    </div>
    <div class="action-column">
        <a href="#">...</a>
        <a href="#">...</a>
    </div>
</div>
 Seth16 июн. 2009 г., 06:31
Спасибо за понимание, ребята.

Ответы на вопрос(8)

перемещается по странице, CSS уже сделал свою работу.

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

Хороший способ добиться этого - пока вы разрабатываете, сделайте 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

 Sasha Chedygov16 июн. 2009 г., 05:52
На самом деле не отвечает на его вопрос (медленная прокрутка).
 Andy Ford16 июн. 2009 г., 18:03
Пожалуйста, прочитайте ответ PW
 iceangel8916 июн. 2009 г., 06:02
какой-нибудь хороший инструмент для этого? минификация? Я думаю, что инструмент по-прежнему не удалит ненужные теги селекторов, хотя
 Galen16 июн. 2009 г., 06:13
@musicfrea - конечно, проверьте мое первое предложение
 Galen16 июн. 2009 г., 06:18
@ iceangel89 - да, минифайеры не будут редактировать теги, просто удалите пробелы и, возможно, лишние конечные точки с запятой.

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

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

 Mike16 окт. 2010 г., 14:32
причина в том, что borwser должен повторно выполнить рендеринг на everyscroll, в противном случае он рендерит только невидимую часть страницы, оставляя видимую на том, что есть

что ответ Галена на 100% правильный. Есть пара хороших статей с тестами с другим выводом "Влияние на производительность CSS селекторов«Однако в большинстве реальных случаев вы не заметите никакой разницы, и поэтому возможная выгода не стоит усилий.

однако я не верю, что это повлияет на прокрутку после рендеринга. В вашем примере, по крайней мере, избегайте селекторов на 3 уровня. Селекторы css с одним уровнем будут быстрее, чем двухуровневые. Размещение типа тега должно ускорить процесс выбора, потому что вместо сопоставления * .class в вашем документе DOM, оно должно совпадать только с div.class, фильтруя тип узлов dom, на которые вы обращаете внимание в классе.

Решение Вопроса

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

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

 Seth17 июн. 2009 г., 00:50
Эти ссылки были полезны. Спасибо брат.

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

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

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

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

Ваш ответ на вопрос