Оптимизация CSS

13.10.2011

Оптимизация CSS

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

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

Как браузеры читают таблицы стилей?

Они читают их справа налево. Мы наоборот(я не беру арабов, им удобнее ). Рассмотрим подробнее:

div.nav > ul li a[title]

Увидев этот селектор, браузер первым делом разбирает a[title], потом переходит левее к li, затем ul и, наконец, div.nav. Самый правый селектор, в данном случае это a[title] — называют ключевым селектором и по нему определяют эффективность всей конструкции в целом. Как видим, браузеру нужно потратить некоторое время, чтобы докопаться до истины. Пусть оно незначительное, но если таких строк много — все заканчивается печально.

Меньшее количество правил для проверки — ключ к увеличению производительности.

Dave Hyatt. Разработчик браузера Safari

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

Оптимизация CSS. Какие селекторы наиболее эффективны?

Ниже список селекторов, по убыванию эффективности.

  • id (#nav)
  • class (.nav)
  • теги (h1, p, li, ul)
  • смежные одноранговые (h1+p)
  • дочерние (ul>li)
  • потомки (li a)
  • универсальный селектор (*)
  • атрибут (a [rel=»external»])
  • псевдо-классы и псевдо-элементы

Казалось бы, используем везде id и не знаем проблем, но не все так просто (хотя многие начинающие именно так и делают) Основная проблема  — необходима уникальность каждого id, отсюда неоправданно большой файл стилей, ведь нужно каждый элемент описывать отдельно.
С другой стороны — псевдо-классы очень удобная штука, но и самая неэффективная.


div #block //эффективно
#block div //НЕ эффективно


//хорошо
#block
.block
//плохо
p#block
p.block

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

Firefox logo

Несколько советов от разработчиков Firefox по оптимизации CSS

  • избегайте универсальных селекторов
  • не используйте идентификаторы вместе с тегами и классами
  • не используйте классы вместе с тегами
  • избегайте селекторов-потомков
  • теги не должны содержать дочерних селекторов
  • наследование селекторов — это хорошо
  • используйте области действия селекторов

В блоге разработчиков Mozilla статья недоступна на момент написания статьи, ей уже около 10 лет. Но, с тех пор принципы написания не поменялись и статья имеет ценность и сейчас.
Что получается в итоге, надо ли бежать сломя голову и оптимизировать свои таблицы стилей? Вот тут по желанию, речь идет о миллисекундах ускорения. Возможно, вы даже не увидите прироста на своих проектах. Более того, есть некий баланс между написанием кода для машин (браузеров в данном случае) и читаемостью. Его тоже нужно учитывать, иначе можно выполнить такую оптимизацию CSS, что потом чёрт ногу сломит.
Если тема заинтересовала, рекомендую почитать — Правила написания хорошего кода CSS и техническая оптимизация.

Удачного дня

,

Комментариев: 9

  1. GerinG

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

    Ответить
  2. Андрей

    Такой вопрос:
    Если мы сократим код цвета (например, указываем не #ffffff, а #fff), не нарушит ли это кроссбраузерность сайта?

    Ответить
  3. Suvitruf

    По-моему читабельность важнее…пусть даже пара миллисекунд теряется. Мы же не производственные контроллеры пишем)

    Ответить
    • Виктор Милашечкин

      Важнее сделать так, чтобы и читалось хорошо и работало максимально быстро. Я старые таблицы не переделываю, нет времени на подобные вещи. А новые стараюсь писать максимально эффективно.

      Ответить
    • Виктор Милашечкин

      Раньше я использовал. Теперь предпочитаю делать руками, пусть дольше, но зато контролирую процесс. Хотя, иногда надо быстренько сжать файлик, тогда да.

      Ответить