Производительность — это актуальная тема для разработки внешнего интерфейса. С (новыми?) Технологиями, такими как css3 и html5, требующими гораздо большего от нашего оборудования, с веб-сайтами, растущими до 1 МБ + на страницу, и с мобильными модными моделями, использующими шумиху, производительность становится ключевым фактором успеха наших веб-сайтов. Слева и справа вы можете прочитать о методах оптимизации и способах улучшить время загрузки и отклика, и это здорово. Но …
Там есть стоимость
Не так давно Йенс Мейерт поделился постом G + по техническому долгу. Сама статья не является бесплатной, но пара цитат, которые Йенс поднял из статьи, говорят сами за себя. На самом деле не существует такой вещи, как удовлетворение потребностей всех и каждого, всегда есть цена, которую нужно платить, и то же самое касается производительности.
Что меня больше всего раздражает при чтении статей о методах повышения производительности, так это то, что они никогда не обсуждают долг (/ стоимость) производительности. В большинстве случаев вы слышите некоторые критические шумы о том, чтобы не переусердствовать, просто потому, что затраченное время не связано с полученным приростом производительности. То, что многие люди, кажется, не осознают (или не будут говорить), это то, что производительность часто сопряжена с очень реальными и ощутимыми затратами: она съедает затраты на техническое обслуживание.
Можно привести быстрый аргумент, что веб-сайты ориентированы на пользователя, ссылаясь на идеал, что вы должны оптимизировать сайт для его пользователей, а не для его разработчиков. Хотя этот идеал вполне обоснован, реальность не так ясна. При создании сайта обычно есть два существенных ограничения: время и деньги. Чтобы оптимизировать качество сайта, важно сделать обслуживание максимально простым. Возможность быстро что-то менять с течением времени становится все более и более важной, особенно если вы не будете заново разрабатывать свой сайт каждый год. Сложное обслуживание приведет к тому, что неуправляемые сайты будут повсеместно падать, как только в них будут внесены изменения.
Чтобы проиллюстрировать, что именно я имею в виду, я рассмотрю два распространенных и популярных метода оптимизации. В следующей статье я буду обсуждать вырезание тегов, в этой статье я сосредоточусь на переписывании селекторов CSS для повышения производительности.
Переписывание CSS-селекторов
Действительно очень популярная техника. Просто взглянув на ленту новостей Smashing Magazine за последние два дня, я смог получить два ( csswizardry , boagworld ) отдельных поста о производительности селектора. Оба говорят о том, как переписать ваши селекторы, чтобы повысить производительность CSS.
Общая идея заключается в использовании коротких и очень специфических селекторов. Идентификаторы перевешивают классы и классы перевешивают селекторы тега. Начиная справа от селектора, это дает представление о том, сколько весят селекторы на вашем сайте (посмотрите статью boagworld, чтобы узнать, какие инструменты делают эти данные более доступными). Похвальная цель и определенно важные знания для фронт-энда разработчиков, но давайте проясним, что они на самом деле говорят.
Качество CSS-селекторов
Селектор css используется для нацеливания на конкретный фрагмент HTML-кода и применения к нему стилей (я знаю, что вы также можете стилизовать определенные состояния, но это помимо сути статьи). Это должно быть общеизвестно. Хотя на самом деле есть только один способ сделать это правильно. Селектор полностью отображает список контекстов, в которых должна совпадать конечная часть селектора, не больше, не меньше.
ul li {color:#666;}
.breadcrumb ul li {color:#000;}
Приведенный выше пример должен быть понятен всем. Первая строка устанавливает цвет элементов li в пределах ul на серый, вторая строка перезаписывает это утверждение для элементов li, появляющихся внутри хлебных крошек, делая их полностью черными.
Есть два основных способа переписать ваши правила CSS. Вы можете изменить html, чтобы добавить дополнительные классы (например, .breadcrumbListItem), чтобы сократить селекторы, или вы можете удалить части селектора, которые не будут влиять на результирующие стили вашего сайта. Как человек, который пойдет на все, чтобы не допустить внешних влияний в мой HTML, я даже не собираюсь обсуждать первый вариант. Это просто не сделано. Второй вариант имеет свой собственный набор ограничений.
Когда вы удаляете «ненужные» части селектора, это может означать одно из двух: либо вы можете удалить их, что означает, что ваш селектор был плохо написан в первый раз, либо вы можете удалить их, потому что текущие спецификации проекта этого не делают. требовать, чтобы эти части были там. Если вам разрешено удалять их, вы на самом деле исправляете ошибки, и это хорошо, но если вы удаляете другие виды селекторных частиц, вы активно снижаете качество своего css-селектора.
/* original selector
*/ .news header h1 {...}
/* reworked selector
*/ .news h1 {...}
Рассмотрим код выше. Поскольку в текущих спецификациях проекта допускается только один заголовок внутри блока .news, часть заголовка может быть удалена из селектора. Но что происходит, когда где-то в конце (а это может произойти до первого запуска сайта) спецификации меняются? Что если вдруг в разделе содержимого вашего блока .news появятся дополнительные заголовки? Заголовки, которые не имеют общих стилей с основным заголовком, вложенным в заголовок?
.news .content h1 {...}
Вы можете быть уверены, что никто не вернется к переработке первого селектора и не вернет часть заголовка туда, где он был, люди просто добавят указанное выше правило и отменит все необходимые стили. Здесь произошло то, что вы только что создали очень простой блок уродливых, плохо обслуживаемых css, недостойных того, кто называет себя профессионалом front-end.
Вывод
Хороший селектор CSS старается помнить о будущих изменениях. Он определяет, какие стили должны попадать в конкретный набор контекстов. Каждый элемент в селекторе должен быть там по причине и не должен быть удален. Иногда удаление части не повлияет на CSS на вашем текущем сайте, но имейте в виду наиболее очевидные изменения в требованиях. Это требует определенного уровня опыта, но вы быстро наверстаете упущенное после выполнения нескольких реальных проектов. Клиенты любят обменивать определенные коробки, вытаскивая их из контекста и размещая их там, где вы никогда не ожидали их появления. Создание такого рода изменений настолько безболезненно, насколько это возможно, вполне может оказаться более важным, чем сокращение этих нескольких миллисекунд времени рендеринга.
Прежде всего, ваши селекторы CSS должны быть правильными . Заявление о том, что они должны быть короткими или удобными для исполнения, и если оставить все как есть, обманывает людей, заставляя их верить, что они сделают такие сайты лучше. Это не значит, что вы не можете оптимизировать, но только если вы полностью не знаете о стоимости и последствиях этих оптимизаций.
Важно, чтобы вы знали правила и лучшие практики, чтобы их нарушать.