Большинство ответов здесь сосредоточены на производительности селектора, как будто это единственное, что имеет значение. Я постараюсь рассказать о некоторых мелочах, связанных со спрайтами (спойлер: это не всегда хорошая идея), о производительности используемых значений css и отрисовке некоторых свойств.
Прежде чем я перейду к ответу, позвольте мне пояснить ИМО: лично я категорически не согласен с заявленной потребностью в «доказательных данных». Это просто делает заявление о производительности кажущимся заслуживающим доверия, в то время как на самом деле область движков рендеринга достаточно разнородна, чтобы сделать любой такой статистический вывод неточным для измерения и непрактичным для принятия или мониторинга.
Поскольку первоначальные результаты быстро устаревают, я бы предпочел, чтобы разработчики внешнего интерфейса понимали основополагающие принципы и их относительную ценность по сравнению с критериями удобства сопровождения/читабельности — в конце концов, преждевременная оптимизация — корень всех зол ;)
Начнем с производительности селектора:
Неглубокие, желательно одноуровневые, определенные селекторы обрабатываются быстрее. В отчетах отсутствуют явные показатели производительности. исходный ответ, но ключевой момент остается: во время выполнения HTML-документ анализируется в дерево DOM, содержащее N элементов со средней глубиной D, а затем применяется в общей сложности S правил CSS. Чтобы снизить вычислительную сложность O(N*D*S), вы должны
Используйте крайние правые клавиши, соответствующие как можно меньшему количеству элементов — селекторы сопоставляются справа налево^ для соответствия отдельным правилам, поэтому, если крайний правый ключ не соответствует определенному элементу, нет необходимости в дальнейшей обработке селектора, и он отбрасывается.
Принято считать, что селектора * следует избегать, но этот момент следует проработать дальше. На самом деле «нормальный» сброс CSS соответствует большинству элементов — когда эта SO-страница профилирована, сброс отвечает примерно за 1/3 всего времени сопоставления селекторов, поэтому вы можете предпочесть normalize.css (тем не менее, это всего лишь 3,5 мс — точка против преждевременной оптимизации стоит крепко)
Избегайте селекторов потомков, так как они требуют повторения до ~D элементов. В основном это влияет на подтверждения несоответствия — например, для положительного совпадения .container .content может потребоваться только один шаг для элементов в отношениях родитель-потомок, но дерево DOM необходимо будет пройти до html, прежде чем можно будет подтвердить отрицательное совпадение.
Сведите к минимуму количество элементов DOM, так как их стили применяются по отдельности (следует отметить, что это компенсируется логикой браузера, такой как кэширование ссылок и переработка стилей из идентичных элементов — например, при стилизации идентичных одноуровневых элементов )
Удалить неиспользуемые правила с момента браузеру приходится оценивать их применимость для каждого отображаемого элемента. Достаточно сказать - самое быстрое правило - это то, которого нет :)
Это приведет к измеримым (но, в зависимости от страницы, не обязательно ощутимым) улучшениям с точки зрения производительности механизма рендеринга, однако всегда есть дополнительные факторы, такие как накладные расходы трафика, синтаксический анализ DOM и т. д.
Далее производительность свойств CSS3:
CSS3 принес нам (среди прочего) закругленные углы, фоновые градиенты и вариации теней — а вместе с ними и кучу проблем. Подумайте об этом, по определению предварительно обработанное изображение работает лучше, чем набор правил CSS3, который должен быть отрисован первым. Из вебкит-вики:
Градиенты, тени и другие украшения в CSS следует использовать только в случае необходимости (например, когда форма является динамической в зависимости от содержимого) — в противном случае статические изображения всегда работают быстрее.
Если этого недостаточно, градиенты и т. д., возможно, придется пересчитывать при каждом событии перерисовки/перекомпоновки (подробнее ниже). Имейте это в виду, пока большинство пользователей не смогут просматривать страницу с большим количеством css3 без заметного отставание
Далее производительность спрайта:
Избегайте высоких и широких спрайтов, даже если их трафик относительно невелик. Обычно забывают, что движок рендеринга не может работать с gif/jpg/png, а во время выполнения все графические ресурсы обрабатываются как несжатые растровые изображения. По крайней мере, это легко вычислить: ширину этого спрайта умноженная на высоту, умноженная на четыре байта на пиксель (RGBA), равна 238*1073*4≅1MB. Используйте его для нескольких элементов на разных одновременно открытых вкладках, и это быстро принесет значительную пользу.
Довольно крайний случай, когда был обнаружен на сайте mozilla webdev., но это вовсе не неожиданно, когда используются такие сомнительные методы, как диагональные спрайты используются.
В качестве альтернативы можно рассмотреть отдельные изображения в кодировке base64, встроенные непосредственно в CSS.
Далее перекомпоновываем и перерисовываем:
Это заблуждение, что перекомпоновка может быть запущена только с помощью JS DOM. манипулирование — на самом деле, любое применение стиля, влияющего на макет, вызовет его воздействие на целевой элемент, его дочерние элементы и элементы, следующие за ним и т. д. Единственный способ предотвратить ненужные итерации — это попытаться избегайте зависимостей рендеринга. Прямым примером этого может быть отрисовка таблиц:
Таблицы часто требуют нескольких проходов, прежде чем макет будет полностью установлен, потому что это один из редких случаев, когда элементы могут влиять на отображение других элементов, которые появились перед ними в модели DOM. Представьте себе ячейку в конце таблицы с очень широким содержимым, которое приводит к полному изменению размера столбца. Вот почему таблицы не отображаются постепенно во всех браузерах.
Я внесу правки, если вспомню что-то важное, что было упущено. Некоторые ссылки, чтобы закончить с:
http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/
http://jacwright.com/476/runtime-performance-with-css3-vs-images/
https://developers.google.com/speed/docs/best-practices/payload
https://trac.webkit.org/wiki/QtWebKitGraphics
https://blog.mozilla.org/webdev/2009/06/22/use-sprites-wisely/
http://dev.opera.com/articles/view/efficient-javascript/< /а>
person
Oleg
schedule
15.09.2012
fixedпозиции CSS. - person Michał Górny schedule 05.09.2012position: fixed— это пример, когда CSS просто нельзя использовать повторно. Не то чтобы я призываю делать что-то подобное. - person Michał Górny schedule 05.09.2012bodyи больше ничего, любой селектор, который вы на нее набросите, не должен вызывать сбоев или даже зависания браузера. - person BoltClock schedule 05.09.2012