Должен ли я сделать мой CSS легче для чтения или оптимизировать скорость

Question

Поскольку я работал над небольшим веб-сайтом, я решил использовать расширение PageSpeed, чтобы проверить, было ли их улучшение, которое я мог бы сделать, чтобы сайт загружался быстрее. Однако я был весьма удивлен, когда мне сказали, что мое использование селектора CSS было «неэффективным». Мне всегда говорили, что вам следует свести к минимуму использование атрибута класса в HTML, но если я правильно понимаю, что говорит мне PageSpeed, браузер гораздо эффективнее будет сопоставлять имя класса. Это имеет смысл для меня, но это также означает, что мне нужно добавить больше классов CSS в мой HTML. Это затрудняет чтение моего файла .css.

Обычно я отмечаю свой CSS следующим образом:

#mainContent p.productDescription em.priceTag { ... }

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

.priceTag { ... }

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

.paragraphPriceTag { ... }
.listPriceTag { ... }

Что действительно раздражает меня, так как я, кажется, дублирую семантику HTML в моих классах. А это значит, что я не могу поместить общий стиль в неквалифицированную

.priceTag { ... }

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

Я считаю, что усложнение чтения кода ради скорости никогда не считалось очень хорошей практикой. Конечно, кроме случаев, когда это критично. Вот почему люди используют PHP / Ruby / C # и т. Д. Вместо C / Assembly для кодирования своего сайта. Проще написать и отладить. Поэтому мне было интересно, стоит ли мне придерживаться нескольких классов CSS и сложных селекторов или мне следует пойти по пути оптимизации и убрать свои модные селекторы CSS ради скорости?

Производит ли PageSpeed ​​верхнюю рекомендацию? Будет ли это иметь значение для большинства современных компьютеров?

Answer 1

Должен ли я сделать мой CSS легче для чтения или оптимизировать скорость?

Вы должны сделать оба.

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

Так что вы должны работать с хорошими читаемыми блоками, а опубликованный файл должен быть крошечным.

По конкретным селекторам

#mainContent p.productDescription em.priceTag { ... }

Добавляет ценность, только если у вас есть

p.productDescription em.priceTag { ... }

Или

em.priceTag { ... }

В других местах, на которые вы не хотите влиять - например, если у вас был «#secondaryContent p.productDescription em.priceTag», к которому вы не хотели применять стиль.

Так что если вы хотите использовать

em.priceTag

И применив правило ко всем, вы фактически не увидите проблем с производительностью (разница будет примерно такой же, как разница размера файла, которую вы сохраните, если у правила будет меньше символов).

ОДНАКО ... не загрязняйте ваш HTML тоннами атрибутов class = "" только потому, что вы не хотите писать правильное правило.

Answer 2

Определите свои приоритеты.

1. читаемость
2. Эффективность
3. Скорость

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

Сначала подумайте о ремонтопригодности.

Между прочим, использование #id является хорошей практикой как для читабельности, так и для скорости, поскольку для его поиска не требуется проходить через весь DOM. То же самое относится и к вам.

Answer 3

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

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