Вы только что присоединились к существующему проекту для замены уходящего разработчика. А может просто занялись своим старым проектом спустя несколько лет. Вы ощущаете ужас и отвращение при взгляде на код. Вы можете сделать только одно: расчистить весь этот бардак. Вы уже сталкивались с чем-то подобным? Почти наверняка, рано или поздно с этим сталкиваются все.
Вы знаете, что очистка кода CSS это объемная задача. Нужно сделать многое за ограниченное время - особенно, когда клиенты/начальники/коллеги настойчиво советуют не трогать то, что работает. Вы даже не знаете с чего начать.
Линтинг это наше все
В этом разделе я буду исходить из того, что вы используете Sass . И не только потому, что это разумное предположение в нынешних условиях, но также по причине того, что неправильное использование Sass часто является причиной загрязнения кодовой базы. Хотя эта статья будет полезна и тем, кто не пользуется препроцессорами, поэтому вам стоит дочитать ее до конца.
Первое, что я привык делать, когда мне надо разобраться с кодовой базой это линтинг . Линтинг это процесс выполнения программы, осуществляющей поиск потенциальных ошибок и плохих практик. Я верю, что делая код чистым мы делаем первый шаг к хорошему коду. С этимологией слова линтинг можно ознакомится в этом треде в StackOverflow .
В Sass есть написанный на Ruby линтер, называемый SCSS-lint . Вы можете настроить его самостоятельно или скачать конфигурацию, рекомендованную Sass-Guidelines , чтобы начать прямо сейчас. Также в Node.js есть sass-lint , они не на 100% совместимы и могут работать по-разному.
Попробуйте запустить SCSS-Lint в своем каталоге с файлами Sass для выявления ошибок. Очень высоки шансы на то, что на вас вывалится тонна ошибок. Обычно после этого хочется прекратить эксперименты по очистке кода. Наберитесь терпения. Сейчас вы можете попытаться сделать конфигурацию менее строгой в отношении правил, не очень важных для вас (типа формата задания цвета) или взять быка за рога и использовать всю мощь линтинга.
Исправление найденных ошибок
Пришло время исправить, то, что нужно исправить. Это можно сделать двумя способами. Первый - это проверить по очереди все файлы и исправить все ошибки и недочеты типа неудачного именования переменных, излишней вложенности селекторов и плохо отформатированного кода. Второй (предпочитаемый мною) - это использование поиска и замены. Не знаю, как вы, но я обожаю регулярные выражения и мне всегда нравится использовать их в работе.
Предположим, вы хотите добавить отсутствующий ноль во всех числах с плавающей запятой (то есть от 0 до 1), ошибки такого типа выявляются с помощью правила LeadingZero в SCSS-lint. Для этого надо использовать для поиска регулярное выражение \s+\.(\d+) (все цифры, следующие за пробелом с точкой), а для замены \ 0.$1 (пробел, ноль, точка и найденное число). А если вы озаботились правилом линтера BorderZero , то вы можете заменить в вашем редакторе с помощью поиска/ замены все правила border: none на border: 0 . Проще простого!
Я недавно создал на GitHub репозиторий scss-lint-regex , чтобы собрать все регулярные выражения для линтинга в одном месте. Обязательно взгляните на него, если у вас проблемы с линтингом в большом проекте. И будьте аккуратны с поиском/заменой, временами он приводит к неожиданным побочным эффектам. После каждой замены выполняйте git diff , чтобы выявить, что изменилось, это гарантирует, что вы не добавите багов в свой код.
После того, как вы закончите с редактированием поиском/заменой, вам не удастся избежать ручного редактирования, в тех местах, которые надо облагородить (неправильные отступы, отсутствие или избыток пустых строк, пропущенные пробелы и т.п.). Это занимает много времени, но это здорово поможет вам на следующем этапе, поэтому важно сделать это до перехода к нему.
Примечание переводчика
Некоторые из этих вещей можно сделать с помощью плагинов SassBeautify в текстовых редакторах, например, sublime или atom .
Пересмотр структуры проекта
Вот что меня действительно часто тревожит, когда я присоединяюсь к существующему проекту, так это отсутствие надлежащей архитектуры проекта. Возможно, в самом начале работы и был какой-то проект, но со временем вещи выходят из под контроля и первоначальный замысел теряется. Но это все равно невероятно важно.
Не столь значим выбор методологии проекта, главное, чтобы она у вас была и не вызывала у вас дискомфорт. Это может быть SMACSS , 7-1 или ITCSS - выбор за вами. Попытайтесь реструктурировать свой код в соответствии с выбранной методикой. Я, как правило, использую паттерн 7-1, который мы разработали в Sass Guidelines, поэтому я дам вам несколько советов, которые помогут, если вы выбрали этот путь.
Затем перейдем к каталогу abstracts . Все переменные, миксины, функции и плейсхолдеры должны находиться здесь. Вы вольны упорядочивать их как пожелаете, пока вы не разберетесь со всеми переменными и миксинами в вашей кодовой базе. Я на этой стадии также выявляю необязательные переменные (и миксины), ведь часто приходиться сталкиваться с переменными, используемыми один или два раза.
После того как вы разобрались с этим, вам придется принять решение, какой из двух следующих шагов сделать раньше. Вы можете попытаться обеспечить, чтобы все содержимое каталога base составляли действительно основные стили, а не стили компонентов. Или проверить, что в каталоге layout находится все, что относится к раскладке страниц и что этот код правильно документирован.
И, наконец, в завершение вам надо заняться компоновкой каталога components и обычно это колоссальная задача. Я советую делать компоненты как можно меньшего размера и ориентироваться на их многократное использование. Не имеет значения, если вы увеличите их количество - главное, чтобы они не зависели от контекста и были простыми для чтения, понимания и обновления.
В качестве примера правильного и небольшого компонента могу привести следующий:
Quote { padding: 10px; } .quote__attribution { font-size: 80%; } .quote > :first-child { margin-top: 0; } .quote > :last-child { margin-bottom: 0; }
Старайтесь мыслить модулями. Меньше. Проще. Независимее.
Удаление лишнего
Я считаю, что самая большая разница между плохим и хорошим CSS это количество кода. CSS очень легко разрастается. Кто-то может делать почти каждую раскладку методом проб и ошибок. Способность делать что-либо, используя минимум CSS требует работы, а сохранение минималистичного подхода является настоящим вызовом.
Прошло уже 3 года, но этот твит Николаса Галахера остается моим любимым вопросом о CSS:
Устаревание это настоящая чума CSS. При написании стилей мы часто ходим туда и обратно, пробуя новые правила - в итоге мы, как правило, оставляем несколько совершенно ненужных деклараций. Например, overflow: hidden , потерявший необходимость или font-size , не изменяющий размер шрифта. Оставляя их, мы увеличиваем технический долг . В этом нет ничего хорошего.
При написании CSS я привык открывать инструменты разработчика в браузера и поочередно отключать каждую декларацию CSS перед отправкой готового кода, чтобы проверить, на что они влияют. Если они не на что не влияют, то я в первую очередь спрашиваю себя: “Зачем они здесь?”. Если они оказываются бесполезными, я удаляю их. С такой простой методикой как эта, я гарантирую отправку в репозиторий только полезного кода без мусора.
Очистка кодовой базы CSS это та же техника. Определите компонент, который вы хотите очистить, откройте инструменты разработчика и попытайтесь найти бесполезные декларации. Иногда для удаления кода CSS, нам надо передвинуть эти стили вверх по дереву, чтобы воспользоваться возможностями каскада. Рассмотрим это на следующем лаконичном примере:
Parent { /* ...stuff here... */ } .child-A { color: red; } .child-B { color: red; }
Очевидным способом оптимизации является перемещение декларации color: red в родительский селектор, после чего каскадирование сделает за нас остальное. Конечно, реальные примеры обычно более сложны, но и этот пример показывает о том, что не стоит забывать возможности „C“ в аббревиатуре CSS .
CSS умный и вы должны быть не хуже
Также очень часто встречается нехватка понимания значений inherit , initial и currentcolor . Предположим, вы хотите, чтобы ссылки были того же цвета, что и основной текст (они уже достаточно выделены подчеркиванием). Вот как не надо это делать:
A { color: black; /* Nope */ }
Причина того, что это решение является неудачным, очевидна: если вы измените цвет body , цвет ссылки будет рассинхронизирован с ним. Если вы думаете об использовании переменной, то это лишь сделает все излишне сложным. И, наконец, если ссылка будет размещена внутри элемента с собственным стилем (например, в цитате), она не будет совпадать с ним по цвету.
В CSS есть встроенный способ решения этой проблемы, это значение inherit:
A { color: inherit; /* Yay! */ }
Точно также при возвращении свойству дефолтного значения будет плохой идеей задание фиксированного значения. В CSS для таких случаев есть значение initial . Обычно оно не имеет отличий от задания фиксированных значений, но есть случаи, когда действительно играет свою роль, например, при определении направления текста в свойстве text-align . При сбросе text-align , значение left может испортить текст на RTL-языках (направленных справа налево), выходом будет именно initial (еще лучше start , но это значение не поддерживается в IE9)/.
Последнее в списке, но не последнее по важности значение это currentcolor , очень многие разработчики о нем не знают. Если вы относитесь к их числу, не переживайте, просто спросите у себя: “Если вы не задавали цвет границы элементы, то почему он автоматически совпадает с цветом шрифта элемента?”. Да, это происходит потому, что по умолчанию свойству border-color задано значение currentcolor (спецификация). Согласитесь, все очевидно из названия.
На мой взгляд, если вы хотите использовать цвет шрифта элемента, надо использовать currentcolor вместо фиксированного значения или переменной Sass.
Element { color: deeppink; border: 1px solid; /* Color is implicit with `currentcolor` */ } .element svg { fill: currentcolor; /* Fill color will be same as text */ }
Это все базовые возможности CSS. Они делают CSS таким как есть. И эти возможности используются на удивление редко. Поэтому, если вы решили улучшить код компонента, не стоит пренебрегать ими.
Ваш Git должен быть в порядке
Рефакторинг кодовой базы CSS это большая по объему работа. Вам придется обновлять десятки файлов. И вполне вероятно, что вы что-нибудь сломаете в процессе. Давайте будем честны - все делают ошибки и было бы нереально круто, если вам удастся завершить такую работу без какой-нибудь маленькой оплошности.
Поэтому я настойчиво рекомендую вам старательно работать с системой контроля версий (логично предположить, что в этой роли выступает Git). Это значит, что все коммиты делают одну единственную вещь - обеспечивать возвращение на шаг назад от кода с багом без мучений с конфликтами.
Я знаю, что многим людям Git кажется сложным и тяжелым для восприятия, а способы легко освоить его находятся за пределами этой статьи. Поверьте мне: история вашего Git должна быть похожей на поэму, если вы не хотите, чтобы у вас выкипел мозг.
Заключение
Итак, кратко сформулирую основные тезисы статьи для тех кому лень читать весь текст:
Очистка проекта CSS/Sass сложна потому, что трудно сразу оценить все последствия изменения или удаления строки CSS. Это все в основном из-за плохой тестируемости CSS. Поэтому вам надо быть внимательными.
Начните с линтинга и ваш код станет симпатичнее. Сделайте это потому, что это облегчит вашу жизнь в будущем. Это также хороший способ обзора состояния вашего кода без особого риска (исправление синтаксической грязи не должно стать причиной каких-то проблем).
Затем структурируйте свой проект в соответствии с выбранной вами методологией. Не важно какую вы выберете, важно, чтобы вы ей следовали. Если в вашем проекте не слишком много компонентов, то структурирование будет хорошим началом. Найдите многократно используемые фрагменты интерфейса и перенесите их стили в отдельные файлы. Не стесняйтесь писать документацию, таким образом процесс пойдет проще и вы почувствуете как двигаетесь вперед.
После того, как вы очистили проект и разложили все компоненты по полочкам, пришло время улучшить CSS. Сначала проверьте, что вы можете удалить, ведь мы всегда пишем слишком много кода. Затем попробуйте оптимизировать его так, чтобы он меньше повторялся. Не перестарайтесь! Ваша задача состоит в том, чтобы уменьшить сложность, а не увеличить. Не забывайте комментировать все, что будет неочевидным для первого взгляда.
И, наконец, ваши коммиты должны быть регулярными и логичными. Объединяйте изменения в небольшие коммиты, каждый из которых делает одну простую вещь - так вам будет проще откатить изменения, если вы что-то сделаете не так.
Последнее, но не менее важное - не забудьте отпраздновать, когда все закончится. Удачи!
Преимущество чистого и организованного CSS очевидны. Сайт у которого безупречный CSS будет загружаться быстрее и будет более заметнее в результатах поиска. Для веб-разработчиков чистый код CSS служит ярким свидетельством профессионализма и для будущих заказчиков.
Но, очистка от мусора разметки CSS в бесчисленных повторах проектирования и изменения могут быть кропотливым, трудоемким процессом выполняя его в ручную. К счастью, есть некоторые замечательные и полезные инструменты, которые помогут вам автоматизировать некоторые наиболее актуальные аспекты CSS. На этой странице ссылки на инструменты очистки CSS, лично Я, проверял CSS разметку сайта на всех инструментах ниже, советую и Вам сделать так же.
Инструменты очистки CSS
ProCSSor для улучшения ваших CSSProCSSor является простым, без излишеств средство для мгновенных улучшений ваших CSS. Доступен через OS X, iOS, или любой браузер, инструмент использует CSS файл, вставленный фрагмент или URL-адрес, и сразу же исправляет, и покажет будущей код вашего CSS.
CSS Lint
Инструмент проверки CSS c объяснением измененийCSS Lint предлагает рекомендации, в отличии от других инструментов очистки CSS. Большинство из них даже не говорят о изменениях в CSS, но CSS Lint, даёт краткое объяснение для каждого из рекомендуемого изменения. Он имеет целый ряд функций, которые сосредоточены на ошибки, совместимость, производительность, устранить дублирование и доступности, которые могут быть включены или отключены.
Dirty Markup
Инструмент Dirty Markup сочетает в себе нескольких различных технологийDirty Markup имеет уникальный подход к оптимизации кода; он работает когда поле заполнено кодом и сочетает в себе нескольких различных технологий HTML Tidy , JavaScript , Ace Редактор , и делает комплексную очистку кода. Это работает точно так же как и CSS, как JavaScript или стандартный HTML.
CleanCSS
Инструмент CleanCSS выполняет оптимизацию CSSCleanCSS работает с URL-адресом или вставленным фрагментом кода и предлагает разнообразное выполнение оптимизации CSS. Вы можете выбрать между пятью различными настройками сжатия, которые предлагают компромиссные варианты между читабельностью и размером файла.
Code Beautifier
Code Beautifier простой CSS cleanup toolCode Beautifier простой CSS cleanup tool (инструмент очистки CSS) без лишних особенностей. Он обрабатывает код по URL-адресу или вставку кода, и тщательно очищает их, основываясь на практическом разнообразии вариантов. Если вам нужно быстро очистить CSS при этом не потеряться в море возможностей очистки кода, это может быть ваш идеальный CSS cleanup tool.
Spritemapper
Spritemapper генерирует спрайты, объединяет несколько изображений в таблицу стилей CSSНи один из других упомянутых инструментов не оптимизировал изображения, что так же полезно, как и оптимизация кода как такового. Spritemapper генерирует спрайты, объединяет несколько изображений в таблицу стилей CSS c правильным позиционированием. В результате более быстрый сайт, меньше количество запросов HTTP, и более обтекаемый стиль CSS.
Topcoat
Topcoat не традиционный инструмент очистки CSSTopcoat не традиционный инструмент очистки CSS; это, по сути, набор для развития CSS, подход кураторства чистого CSS. Если у Вас хорошо написанный CSS, вы, вероятно, никогда не будите нуждаться в том, чтобы очистить код CSS.
Инструмент CSSTidy работает на Windows, Mac, или платформ Linux.CSSTidy похож на многие инструменты очистки CSS, но этот предлагает некоторые уникальные атрибуты. CSSTidy может быть вызван с помощью командной строки или PHP, и он работает на Windows, Mac, или платформ Linux. CSSTidy-cleanup tool может отлично вписываются в существующий рабочий процесс и сохранить ваш CSS чистым автономно. W3C Valdiator инструмент проверки валидности кода CSS
W3C Valdiator не предлагает средства для очистки, сжатия и оптимизации кода, его безусловно нужно рассматривать в случаях, когда код CSS действительно некорректный. Вышеупомянутые инструменты имеют свои средства, этот сделан Консорциум W3C который создаёт стандарты.
Рано или поздно, каждый front-end (верстальщик) сталкивается с задачей, когда нужно проверить весь сайт на наличие неиспользуемых правил CSS. Первым делом на ум приходит погуглить и найти какой-то сервис или программку, которая сделает всю грязную работу за нас.
Короче попотел, и нашел такие решения:
- платный сервис unused-css.com
- DustMe Selectors — расширение FireBug для Mozilla
- CSS Usage — расширение FireBug для Mozilla
По поводу платного сервиса, Вы зайдете на сайт, введете адрес сайта для проверки и нажмете ОК. Вам напишут что результат придет на почту, в итоге через сутки придет письмо, что уже есть результат и его можно скачать по ссылке (переходите и Вам предложат внести оплату, чтобы скачать результат проверки). Но мы не ищем легких платных путей, да и хочется все уметь делать своими руками, поэтому оставим платный результат кому-то другому.
Итак начнем с того какое программное обеспечение нам понадобится. Первым делом нам понадобится Mozilla Firefox. После того как Firefox установлен, внедряем в него дополнение FireBug .
Dust Me Selectors
Дополнения Dust Me Selectors в официальном каталоге дополнений к браузеру нет, установить его можно перейдя по ссылке и нажав кнопку Install Now (естественно открывать ссылку нужно FireFox’ом). Дополнение установили, перезагрузили браузер и в правом нижнем углу у нас появится розовый значок метлы.
После того как расширение просканирует страницу откроется окошко с тремя вкладками Unused selectors (неиспользуемые правила), Used selectors (правила которые используюся) и Spider log (паук — сканирование сайта). Внизу две кнопки: сохранить документ и очистить результат сканирования.
Теперь немного подробнее о Spider log. Требуется ввести адрес сайта или адрес карты сайта и нажать кнопочку GO! По идее все понятно и все должно работать, но как ни хотел я результата, результата не получилось, точнее получалось просканировать пару страниц и дополнение висло, что очень печалило, одним словом неудача какая-то. Автор утверждает, что для работы дополнения нужна Mozilla версии 1.5 и выше (это тоже развод [хихи] я ее устанавливал, да все работает, но все равно не так как нужно). В принципе это единственный минус и самый значительный, потому что нужно было весь сайт проверить, а проверяется достаточно долго (пол дня убил в этот хлам). Самое положительное это то, что если ввести название сайта, то дополнение построит карту сайта, а она нам пригодится для следующего дополнения CSS Usage , так что обязательно сохраните карту сайта.
В принципе если Вам нужно проверить одну страничку то это расширение Вам отлично поможет, отмечу еще такой минус, что при любом открытии дополнения все время сканируется страничка, короче управление расширением не сильно удобное, поэтому я на него забил.
CSS Usage
Дополнение CSS Usage в официальном каталоге можно найти по ссылке . До недавнего времени, чтобы расширение работало, приходилось устанавливать версию Firefox 3.6.25, а на момент написания статьи Автор, как бы проснулся или очухался и обновил дополнение, поэтому можно ставить на последнюю версию Mozill’ы. После того как Вы установите это дополнение и перезагрузите браузер, смело заходите на сайт который хотите проверить и как только страничка загрузится, смело нажимайте кнопочку F12 (откроется окошко FireBug’а) и там Вы увидите вкладку CSS Usage:
Чтобы проверить страницу на наличие неиспользуемых правил нужно нажать кнопочку Scan (сканирование занимает секунд 30, а то и меньше). На первый взгляд кажется что это расширение сканирует только одну страницу, что же делать с остальными страницами спросите Вы. А помните мы сохраняли карту сайта с помощью расширения Dust Me Selectors, правда если на проверяемом сайте есть html карта сайта, то использовать лучше ее, если же ее нет то создайте новую страничку сайта и вставьте карту сайта с расширения Dust Me Selectors (если нет возможности создать новую страницу то об этом ниже).
Сейчас я опишу последовательность действий для сканирования:
- открываем html карту сайта
- нажимаем F12 — открывается FireBug
- переходим на вкладку CSS Usage
- нажимаем кнопку AutoScan
- обновляем страницу (нажимаем F5)
В результате получили первую просканированную страницу. Можно сохранить полученный результат, а можно дальше продолжить сканирование. Предлагаю Вам продолжить. Продолжить сканирование легко, нам уже ничего не надо выбирать (так как мы выбрали автосканирование страниц), а просто перейти по первой ссылке в карте сайта (открывать ссылку в новом окне не нужно, надо чтобы все действия происходило в одном окне).
В самом начале просканированной страницы указываются следующие обозначения:
- Line — строка правила
- CSS Selector — CSS правило
- Seen — используемое CSS правило (светло-зеленым цветом)
- Seen before — правила CSS которые использовались ранее (темно-зеленым цветом)
- Unseen — неиспользуемые CSS правила (красным цветом)
- :hover — CSS правила для элементов, которые получили фокус (серым цветом)
- (2 scans) — показывается количество сканирований (если Вы просканировали тока одну страницу то соответственно будет цифра 1)
- export cleaned css — сохранить результат сканирования
Можете дальше продолжить сканирование, правда придется возвращаться к карте сайта (первый минус). Спешить прокликивать не нужно, важно чтобы страница загрузилась полностью, работу автосканирования Вы будете видеть (то есть результат сканирования будет отображаться в окне FireBug’а).
Расширение проверяет все подключаемые файлы стилей. Если правил CSS на сайте очень много, придется прокрутить колесико, чтобы увидеть результат сканирования:
Такой результат выводится после каждого файла стилей, если их больше одного.
Когда все страницы будут просканированы кликните на ссылку export cleaned css , результат откроется в новой вкладке, выделите все и сохраните в файл с раширением.css , перед каждым неиспользуемым правилом будет указан тег UNUSED:
Второй минус такого метода сканирования это то, что данное расширение не сканирует всплывающие (модальные) окошка сайта, очень жаль, так что придется скопировать правила CSS для модальных окошек.
Несмотря на два минуса, на мой взгляд это самый крутой метод проверки файла стилей на наличие неиспользуемых правил CSS , которое на сегодняшний день существует.
Я его применял для оптимизации двух файлов стилей общим весом в 360Кб — 18000 строк, я был в шоке когда это увидел. После всех махинаций с помощью этого метода получился один файл стилей — 90Кб и 1100 строк, результатом остались все довольны, и я тоже. Правда решение искалось долго, в следующий раз все будет на много быстрее, что очень радует.
Чуть не забыл. Что делать если создать страницу с картой сайта не представляется возможным? В этом случае в адрессную строку Вам придется вставлять каждую ссылу с карты сайта ручками и все будет отлично срабатывать.
И кстати если Вы выбрали систему управления сайтом WordPress, то в этой статье вы можете узнать как для него сделать карту сайта.
Еще отмечу, что платный сервис присылает результат сканирования в течение 24 часов, а если на Вашем сайте (ресурсе) 10 или 20 шаблонов страниц, то Ваша проверка займет на много меньше времени, чем Вы потратите чтобы дождаться от них результата. Но, если на сайте огромное количество страниц и для них используются разные шаблоны, конечно целесообразно заплатить какието 25$ за такую услугу.
Надеюсь Вам окажется полезным такой метод проверки Вашего файла стилей.
От автора: рассуждать о монолитных стилях довольно сложно, так как, обычно, CSS файлы часто раздуваются. Удаление неиспользуемых стилей CSS должно перевести ситуацию в управляемое русло. Прежде чем мы начнем искать неиспользуемые стили, стоит отметить, что существует множество других стратегий написания обслуживаемых стилей. Наши стили можно разделить на логические части (макет страницы, кнопки, сетки, виджеты и т.д.) и использовать понятную систему именования (например, БЭМ). Как правило, разработчики делают это еще до того, как ищут неиспользуемые правила. Я думаю, это правильно, ведь стили имеют долгосрочное воздействие.
Еще одна причина, по которой не так часто урезают правила – просто неудобно искать и удалять неиспользуемые стили в чем-либо, что больше маленького веб-проекта. Если контент не статичен, как понять, какие правила используются и где?
Инструмент разработчика Chrome
Оказывается, в инструментах разработчика Chrome уже есть встроенная функция. Я испытал ее на сайте, на котором, как я знал, было много стилей, которые можно удалить. Ощущения были смешанные. Порог входа очень низкий, особенно для разработчиков, которые уже работали с панелью разработчика Chrome. Устанавливать ничего не нужно, это приятно.
Что нужно сделать для проверки стилей на сайте:
Откройте интересующий сайт
Откройте панель разработчика
Перейдите на вкладку audits
Выберите опцию Web Page Performance и запустите
В части результатов будет «Remove unused CSS rules». Если этого нет, значит, у вас нет неиспользуемых стилей. Поздравляю! Результат разбит по стилям. Разбивка не просто по файлам, а по блокам style. Реально полезная функция, так как нам нужны только те стили, которые писали мы. По крайней мере, в рамках этой статьи.
Хорошо ли это?
Я не нашел супер простого способа экспортировать результат из Chrome. Можно копировать прямо из блока, но его сначала нужно развернуть. Это делает разбор результатов немного неудобным. Запуск теста в браузере еще дальше отталкивает нас от работы с кодом, что, возможно, приведет к тому, что мы будем забывать тестировать сайт.
Вывод: для начала полезно, но не долгосрочное решение.
UnCSS
Для поиска неиспользуемых стилей можно задействовать инструменты командной строки. UnCSS – интересный экземпляр. Он вытягивает страницу через phantomJS и ловит стили, вставленные через JS. Я очень хотел попробовать этот инструмент, так как он решал мою проблему, ведь панель разработчика Chrome совсем не связана с редактированием кода. С помощью UnCSS результат можно сохранить прямо в файл, идеально.
Установка
У меня не получилось выполнить npm install uncss на Ubuntu. Ничего серьезного, оказалось, я забыл пару зависимостей. Команды для установки недостающих библиотек, которые я запускал:
sudo apt-get update sudo apt-get install build-essential chrpath libssl-dev libxft-dev sudo apt-get install libfreetype6 libfreetype6-dev sudo apt-get install libfontconfig1 libfontconfig1-dev
sudo apt - get update sudo apt - get install build - essential chrpath libssl - dev libxft - dev sudo apt - get install libfreetype6 libfreetype6 - dev sudo apt - get install libfontconfig1 libfontconfig1 - dev |
UnCSS можно интегрировать в процесс билда, но мы сейчас опустим это. Думаю, вставлять его в процесс билда не самая хорошая идея. У Addy Osmani есть по этой теме хорошая статья. В идеале, нам нужно удалять неиспользуемые стили прямо из кода, а не просто фильтровать их под финальный продукт.
Возможно, лучший выход – делать и то и то. Во-первых, запускать его как пребилд шаг для оптимизации кода. Во-вторых, запускать шаг билда для оптимизации стилей, которые вы не контролируете.
Использование командной строки
uncss http://your-site.foo/ > unused-styles.css
uncss http : //your-site.foo/ > unused-styles.css |
Результат разбивается на стили сайта your-site.com и браузер Chrome, но хранятся в одном файле. На моем сайте есть шрифт font-awesome, и все иконки, которые не используются на домашней странице, попали в вывод UnCSS. Сейчас мне это неважно. Их можно спрятать, если запустить команду еще раз и указать ignoreSheets.
Обратите внимание, что ignoreSheets может принимать строку (полный URL стиля, который нужно проигнорировать) или регулярное выражение. С регулярным выражением проще, так как там меньше символов, и оно покрывает возможные изменения в пути к файлу.
IgnoreSheets /.*font-awesome.min.css/
Вот такое сообщение об ошибке выскакивает при таймауте страницы. Таймаут можно увеличить с помощью -t N, где N – количество миллисекунд (не ставьте –t 360, чтобы потом удивляться, почему код не подождал 5 минут).
Вывод: UnCSS удобнее, так как ближе к месту, где я редактирую стили. Выходной файл полезен при исключении ненужных стилей. Я вижу ему применение из-за опции –includeSheets, которая автоматически игнорирует все, что попало под регулярное выражение. Удобно для, например, сайтов в WordPress, где различные плагины могут подтягивать свои стили, но разработчику нужны только стили темы style.css и т.д.
Какой инструмент использовать?
Сначала я выбор отдал UnCSS и удобной командной строке. Однако пока я писал эту статью, я попробовал их на еще паре сайтов и получил менее перспективные результаты. В частности, у меня есть несколько сайтов, созданных пару лет назад, на которых используется фреймворк, где задействованы постоянные комментарии /*!*…*/. Они плохо работают с PostCSS, поэтому и с UnCSS. Я еще не вникал в проблему, но, возможно, более новая версия PostCSS прощает такие комментарии. Тем не менее, прямо сейчас это стало еще одним барьером, и я не могу полностью использовать UnCSS в своей работе.
