Есть ли что-то еще для оптимизации CSS, чем минимизация количества символов?

Question

Я много читал об оптимизации jQuery и о том, как вы можете изменить свои селекторы, чтобы сократить объем обхода DOM, но я мало что слышал об оптимизации CSS вне обычного процесса минимизации.Есть ли способ оптимизировать загрузку / обработку CSS за исключением простого сокращения количества символов и запросов к серверу?

Answer 1

Вы можете определенно оптимизировать ваши селекторы для производительности.Одним из ключевых моментов является то, что парсеры CSS читают селекторы справа налево, тогда как движки селектора javascript (например, jQuery и т. Д.) Читают их слева направо.Хотя в принципе общие принципы одинаковы - вы хотите, чтобы каждая часть селектора соответствовала как можно меньшему количеству элементов, чтобы сократить узлы DOM, которые необходимо искать для определения соответствия.

Это означает, что, как и в javascript, выбор единственного голого идентификатора в CSS - это самый быстрый способ получить доступ к элементу.Выбор всего * или выбор по атрибутам ([href*=foo]) относятся к числу самых медленных.

Порядок чтения создает разницу между оптимизацией селекторов jQuery и селекторов CSS: вы не набираете скорость, начиная судостоверение личностиНапример, если вы напишите:

#mainContent ul li

В jQuery вы начинаете с поиска элемента с идентификатором mainContent, который очень быстр, а затем копаете его дочерние элементы.

В CSSтем не менее, вы начинаете со всех элементов li, затем смотрите, есть ли у них предок ul, а затем проверяете, находятся ли они внутри #mainContent.Гораздо медленнее.

Возможный прирост скорости

Однако вы также должны знать, что CSS-разбор намного, намного быстрее, чем обход DOM из JavaScript - так что даже когда вы это делаетеИмея много сложных, «медленных» селекторов, вы вряд ли увидите огромный выигрыш в производительности, оптимизировав их.Вот хорошая статья об увеличении производительности: http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/ - автор указывает, что он мог бы увеличить время рендеринга примерно на 20 мс, создав огромную, сложную таблицу стилей и документ (6000 элементов DOM и 2000 правил CSS).Поэтому для более «нормальной» страницы ваш выигрыш, вероятно, будет меньше 20 мс - вероятно, не стоит затраченных усилий.

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

Вот еще несколько хороших чтений по этому вопросу:

• http://css -tricks.com / 6386-рендеринг-css /
• http://code.google.com/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors

Answer 2

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

https://developer.mozilla.org/en/Writing_Efficient_CSS

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

Answer 3

Да, вы можете сделать свой CSS лучше с точки зрения эффективности выбора селектора. Делая ваши селекторы настолько конкретными, насколько это возможно, вы уменьшаете усилия, необходимые для рендеринга HTML для поиска подходящих элементов в DOM.

Например, в тех случаях, когда вы знаете, что все диапазоны, которые вы хотите стилизовать, будут прямыми потомками элемента div внутри вашего элемента с id #thing. это было бы быстрее сделать:

#thing > div > span.my-class

чем

#thing span.my-class

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

Answer 4

Слияние таблиц стилей, если у вас есть несколько (не забывайте, чтобы сохранить порядок)

Вы также можете разместить статический контент на другом сервере в качестве своего приложения (http-сервер, оптимизированный для обслуживания статического контента), например Lighttpd