как почистить код сайта
Свой сайт — это просто! Пособие для чайников
От азов к вершинам мастерства. Авторский проект Ольги Морозовой
Удаляем лишний HTML-код в программах FrontPage и Dreamweaver
Посещая сайты в Интернете, вы наверняка замечали, что скорость загрузки у различных страниц и сайтов разная. Одни загружаются быстрее, другие медленнее. Если нужная информация загружается быстро, это всегда радует и формирует положительное отношение ко всем сайту в целом. Но если скорость загрузки невелика, вполне вероятно, что в следующий раз вы поищете нужную вам информацию в другом месте. Не так ли?
Именно поэтому создателю сайта не следует оставлять без внимания такой вопрос, как скорость загрузки сайта.
Что, вообще, влияет на скорость загрузки страницы? Немаловажную роль здесь, конечно же, играет скорость подключения к Интернету. Но на этот фактор создатель сайта, увы, повлиять не в состоянии. Можно лишь учесть, что, хотя в последнее время скорость доступа в Интернет благодаря выделенным каналам и более качественным показателям модемов существенно возросла, остается немало пользователей, у которых скорость подключения к Интернету осталась по-прежнему невысокой.
Помимо этого, на скорость загрузки страницы также влияет хостинг, на котором размещен сайт. Например, на большинстве бесплатных хостингов количество пользователей достаточно велико, что существенно замедляет загрузку сайта.
На платных хостингах загрузка сайта происходит быстрее. Однако многие платные хостинги загружены не меньше, чем бесплатные, поэтому проблемы со скоростью загрузки встречаются и там. Так что не забывайте, что выбор хостинга, помимо всего прочего, влияет также и на скорость доступа к сайту.
Скорость загрузки страницы зависит от размера страницы в килобайтах. Чем меньше размер страницы, тем быстрее она загружается. А так как мы знаем, что обычная Интернет-страница целиком и полностью состоит из HTML-кода, то скорость загрузки страницы будет зависеть именно от этого. То есть от размера HTML-кода.
Конечно, помимо текстовой информации на страницах могут встречаться и различные графические объекты. И для того чтобы загрузить все рисунки, имеющиеся на странице, требуется дополнительное время, и оно будет зависеть уже от размера файлов открываемых рисунков.
Визуальные редакторы, такие как FrontPage и Dreamweaver существенно облегчают создание сайта. Но вместе с этим, как мы выяснили, они часто добавляют «отсебятину». Обычно это лишние HTML-теги, которые не обязательно или просто не нужно использовать на странице.
Однако с точки зрения программ все правильно и даже логично. Вы нажимаете на кнопочки, программа пишет соответствующий код. Так что на создание лишних HTML-тегов влияет и «человеческий фактор». Но обо всем этом я уже писала. Кстати, по поводу логики программ дополнение от читателя Василия aka Дяди Васи.
…когда вы писали слово HTML, вы поменяли раскладку клавиатуры. И FrontPage почему-то решил, что это нужно обязательно отметить. В HTML-коде видим следующее:
А ведь в действиях FrontPage в этом случае прослеживается ненулевая логика. Дело в том, что HTML-документы предназначены не только для людей, умеющих читать! 🙂 Некоторые браузеры уже сейчас имеют средства голосового вывода информации. То есть компьютер «читает вслух» веб-страницу, а пользователь слушает. Нетрудно догадаться, что для правильного «произношения» нужно знать язык, на котором написано произносимое. (Заметим в скобках: именно язык, то есть раскладку клавиатуры, а не кодировку; это разные вещи).
В описанном выше случае компьютер не знает заранее, для чего предназначен документ: для чтения с экрана, для прослушивания или ещё для чего-то. (Из экзотики: специально для слепых людей были разработаны устройства тактильного вывода информации, использующие рельефный шрифт Луи Брайля; в стандарте CSS для этих устройств определён специальный Media type: BRAILLE). «Умная» программа из двух зол выбрала меньшее: пусть документ будет больше по размеру, но зато он будет максимально совместим со всем и вся. И добавила:
Значительная часть «артефактов визуального редактирования» появляется именно по этой причине: машина «подстраховывает» человека на все случаи жизни.
Конечно, хорошо, когда сайт такой функциональный и узнать размещенную на нем информацию могут люди с разными возможностями.
Но каждый знак в HTML-коде — это один бит. А 1024 байта — это один килобайт. Считается, что размер страницы, которая будет оптимально быстро загружаться у пользователей с разными скоростями подключения к Интернету не превышает 30 килобайт. Вот и считайте теперь :). Кстати, анекдот в тему:
Чем отличается законченный программист от простого пользователя? Пользователь думает, что в килобайте 1000 байт, а программист — что в километре 1024 метра.
С визуальными редакторами мы разобрались. Да, они добавляют лишние HTML-теги, которые увеличивают размер страницы и, следовательно, уменьшают скорость ее загрузки. Но одновременно они предоставляют средства, которые помогут эти лишние теги убрать. Сейчас я вам об этих средствах и расскажу.
«Чистка» лишних HTML-тегов во FrontPage
Откройте во FrontPage страницу, которую собираетесь редактировать. Если вы хотите удалить лишние теги сразу на нескольких страницах, то откройте и их тоже. FrontPage позволяет убрать «лишнее» со всех страниц сразу.
Затем выберите вкладку Код (HTML). Вот он, тот самый код, из которого мы сейчас уберем все, чему здесь быть совсем не обязательно. В командной строке выберите Сервис | Оптимизировать HTML. Откроется следующее окно:
Расставьте флажки там, где считаете нужным. Например, если вам не нужно удалять теги Generator и ProgID и вы решили оставить их для красоты (т.е. для информативности), не ставьте там флажок.
После этого HTML-код уже должен существенно сократиться. Например, за счет того, что все пробелы перед тегами удалятся. Теперь можно удалить другие лишние теги, которые не были затронуты этой оптимизацией.
Как видите, в окне на рисунке выше помимо вкладок Поиск и Замена есть еще вкладка Теги HTML. Вот так она выглядит:
Здесь теги HTML редактировать значительно удобнее. С ними можно сделать много — заменить, задать значение атрибута или просто удалить. Если вам не нужны теги на странице ни в каком виде, то, понятное дело, нужно выбрать именно удаление тега.
«Чистка» лишних HTML-тегов в Dreamweaver
В программе Dreamweaver технология «чистки» кода схожа с технологией во FrontPage. Но некоторые отличия все же имеются, поэтому считаю не лишним описать и ее тоже.
Для удаления тегов из Word’а здесь имеется гораздо больше возможностей. В командной строке выбираем Команды (Commands) | Очистить Word HTML (Clean up Word HTML).
Те, кто мучился с удалением тегов Word вручную, оценят эту функцию по достоинству :). Но Dreamweaver умеет не только теги Word’a удалять, но и любые другие: Команды (Commands) | Очистить HTML (Clean up HTML).
Можно одним махом убрать пустые, лишние теги (которые «ни к селу ни к городу»), комментарии (которые, хоть и полезны, но все равно — один символ это один байт!). Ну и, конечно же, теги, которые вы укажете сами, в данном случае span.
Используя возможности визуальных редакторов, вы вполне можете сделать ваш HTML «кристально чистым». Причем особых усилий прилагать и не нужно. Расставил флажки, нажал на кнопку и пожалуйста!
Однако, даже вычистив свой HTML-код «до блеска», не всегда можно с уверенностью сказать, что ваш сайт будет загружаться за милисекунды. Немаловажную роль играют технологии, которые вы используете при создании сайта. Например, вы создали сайт, макетом которого является таблица. Это очень удобный вариант, особенно на начальном этапе. Но таблицы имеют некоторые свои особенности, которые могут замедлить загрузку страницы. О них читайте в статье «Как ускорить загрузку таблиц на сайте?«.
Как очистить сайт от разного хлама за 10 минут
Как очистить сайт от разного хлама
Добрый день, друзья! Все люди, у кого есть собственный сайт, давно заметили, что с течением времени их ресурс загружается все медленнее. Это происходит по разным причинам, я уже не раз упоминал о них.
Убираем лишние плагины
Это может быть слишком много плагинов. Я советую по возможности заменять различные плагины кодами. В интернете по поводу кодов написано довольно много информации. Мы еще вернемся к данному вопросу. Я скажу лишь кратко, что заменить код плагином довольно просто.
В большинстве случаев код вставляется в файл функций, тела статьи, стилей, комментариев и прочее. Я скажу честно, по данному вопросу статьи писать не собирался, но по просьбе читателей, планирую выпустить ряд статей по данному вопросу. На данный момент, у меня активно всего 11 плагинов, но это не предел. Я собираюсь отключить ещё как минимум четыре. Я сам заметил, сайт стал загружаться намного быстрее.
Как проверить сайт на время загрузки, я упоминал в своей статье, время загрузки сайта. Также есть еще другой ресурс, [urlspan]http://tools.pingdom.com/fpt/[/urlspan], который позволяет не только узнать время загрузки определенной страницы, но и показать, с какой скоростью грузятся различные части страницы (различные плагины, коды и прочее).
Хочу добавить, во время внесения изменений, перед тем, как очистить сайт, не забывайте сохранять данные, т.е. проводить бэкап. Могу привести простой пример, во время написания данной статьи, я заметил, что на моём сайте не загружаются разделы постов. Я начал разбираться, просмотрел все изменения, которые я проводил в течение последних суток.
Начал удалять и возвращать установленные вчера скрипты, и когда я удалил скрипт, отвечающий за отключения индексации разделов, разделы стали работать в обычном режиме. Я этот скрипт установил вчера, но из-за особенностей моей темы, он так себя повел.
Если бы я не вспомнил, какие именно я внес изменения, мне пришлось бы выполнить восстановление данных. А чтобы их восстановить, их необходимо вначале сохранить. Поэтому не стоит лениться, а нужно проводить бэкап данных хотя бы раза два в неделю. Перед внесением изменений в файловую систему, бекап просто необходим, иначе могут возникнуть большие проблемы!
Как очистить сайт путем выключения ревизий
Ревизии – это копии ваших статей. К примеру, вы начали писать какой-либо текст, опубликовали статью, через определенный промежуток времени внесли в данную статью какие-то улучшения. Тое есть немного изменили её. Во время подобных изменений и происходит ревизия, т.е. создаётся копия статьи.
Можете себе представить, сколько подобных копий возникнет за полгода, год? Данные копии вереницей станут тянуться за сайтом. Вот их то и следует удалить. Для этого нам потребуется открыть папочку wp-config.php. Это корневая папка. Тое есть она находится в корневом каталоге.
На моём ресурсе папочка называется publik_html. У вас или аналогично, или как-нибудь похоже. Скачать её удобно с помощью FileZilla. Затем откроем её текстовым редактором (notapad++) и вставим пару строк:
define(‘WP_POST_REVISIONS’, false);
define(‘EMPTY_TRASH_DAYS’, 1);
Благодаря первой строчки, мы отключим ревизию наших статей. Вторая строчка отключит корзину. Точнее я поставил 1, это время хранения постов в корзинке, измеряется в сутках. Можно конечно добавить 0. Но в этом случае есть возможность случайно удалить статью полностью. Тогда придется восстанавливать, если вы своевременно провели бэкап.
Очищаем базу данных нашего сайта
Как очистить сайт более детально? Можно почистить базу данных. Но в этом случае бэкап перед процедурой обязателен! Рисковать в этом деле не стоит.
Во время существования блога мы постоянно добавляем или удаляем плагины, коды и прочее. Во время подобных удалений следы от расширений остаются. Поэтому их также нужно убрать. Иначе вес базы может достичь 30 Мб и более! Что, как вы понимаете, увеличит время его загрузки!
Чтобы войти в базу, необходимо войти в свою админку на хостинге. Далее выбираете вашу базу, вводите пароль и входите. Затем, создадим копию базы. Для этого нажмем на «Экспорт», выделим всё и жмем Ок. Наша база скопируется на комп. Далее, необходимо её сохранить. Если вы удалите не нужное, базу можно восстановить, нажав на «Импорт», только перед этим не забудьте удалить базу с хостинга.
Чтобы начать чистку, войдем в меню «Структура». Теперь нам необходимо убрать таблицы удаленных плагинов и прочее. Во время установки вордпресса, у нас образуются таблицы:
Не вздумайте их удалить! Иначе придется делать восстановление! Во время установки плагинов создаются различные таблицы. К примеру, произвел установку плагина по поиску битых ссылок Broken link checker. У меня появились следующие таблички:
Их тоже не трогайте, данный плагин я показал для примера. Хотя он у меня не активный, его необходимо частенько применять для поиска битых ссылок. Просмотрите удаленные расширения и удалите их оставшиеся таблицы.
Для этого, ставьте галочку рядом с нужным плагином и жмите на значок удалить:
Затем, после удаления таблиц нужно, проведем чистку ревизий, т.к. мы их отключили, но данные в них остались. Перед процедурой обратите, сколько весит таблица wp-post. Очистив ревизии, заново проверьте, на сколько уменьшилась табличка.
Для очистки ревизий войдем в меню «SQL» и внесем строчку:
DELETE FROM wp_posts WHERE post_type = «revision»
Осталось нажать Ок. Затем вы увидите к примеру:
Как видно из скриншота, у меня удалилось 211 строчек. При этом, я провел подобную ревизию 20 дней назад. Затем мы эту табличку оптимизируем, вставив в меню «SQL» строчку:
OPTIMIZE TABLE wp_posts
Затем проведем удаление пинкбэков:
DELETE FROM wp_comments WHERE comment_type = ‘pingback’
Если не знаете, что это, то вкратце объясню: когда кто-то ставит на ваш ресурс ссылочку, вордпресс к вам в комментарии отсылает как бы обратную ссылку – pingback.
Как очистить сайт с помощью плагина
Это довольно простой и удобный метод. Для этого нам потребуется плагин, называющийся optimize DB. Его достаточно активировать, в том же разделе «Плагины» нажать на optimize, перейдем в его страничку и нажмем «Оптимизировать сейчас». Ваш ресурс будет оптимизирован. После этого не забудьте его деактивировать, для уменьшения нагрузки на сайт.
Также, если вы решили провести комплексную очистку сайта от хлама, вам желательно проконсультироваться у специалиста. Но специалиста найти сейчас не так просто. Да и обойдется вам это в «Копеечку». Поэтому, проще изучить данный материал по видеокурсу.
По поводу курсов, я бы предложил курс, который я сам прошел. Мне понравился материал Александра Борисова «[urlspan]Кибер-Блоггер[/urlspan]» В данном курсе Александр понятным языком рассказывает, как именно необходимо проводить очистку, какие применять методы, какие должны быть фото, ссылки и прочее.
[urlspan][/urlspan]
Я применил его метод и получил результат, у меня исчезли многие дубли страниц, пропали остатки удаленных плагинов, неработающие ссылки и прочее. На самом деле все это очень замедляет блог. Даже не то слово, за дубли страниц вас могут забанить поисковики!
Например, раньше Яндекс показывал проиндексированных постов на http://info-kibersant.ru/ 1220, хотя их реально было около 250, сейчас яндекс показывает 480, а Гугл 520, что намного ближе к реальности! Хотя на моём блоге их ещё мало, на многих число дублей достигает сотен тысяч! И это не выдумка! Данные сайты находятся не далеко от бана! Поэтому, сайт необходимо очищать!
Приведу слова Борисова про раздел «Очистка» в его курсе:
Подробнее информацию о курсе вы найдете на сайте Александра.
Я надеюсь, теперь вам ясно, как очистить сайт? Я привел только часть методов, хотя их на самом деле намного больше. Но и данных методов достаточно для очистки большего количества хлама с сайта. Желаю успехов!
Чистим код страницы сайта на WordPress «по самые не балуйся»
По-умолчанию WordPress пихает в код страницы сайта кучу кода, который не всегда нужен, а иногда создает проблемы с индексацией страниц.
По поводу проблем я уже писал раньше в этой статье.
Ниже код с пояснениями, который размещаю на всех созданных для клиентов сайтах (в том числе на своих личных). Вставляем код в functions.php:
Привет. Я автор этого блога и ридера вебмастеров/SEO-специалистов WMSN.ru
Можешь оставить свой вопрос в комментариях к статье или предложить идею для новой статьи. Не стесняйся.
Шикарно)) Что ожидать после вставки? Сайт быстрее грузиться заметно будет?
Если только на пару миллисекунд)
Вроде бы в статье нет слов про скорость))
Спасибо за подробное описание. Профит я так понимаю будет в более чистом коде? Есть ли смысл в text to html ratio?
Проблемы с wp-json это проблема с неправильно составленным robots. У меня Яндекс успешно НЕинедксирует подобные страницы.
Сапсибо большое. Расширил аналогичный файл у себя.
Просто отлично! Спасибо! Обязательно воспользуюсь!
Скажите, а для сайта на кириллице (домен) с возрастом 3 года, можно вносить изменения? ПС нормально отнесется? Ничего нигде не понизит? Спасибо.
Здесь правки движка WP, а не домена) Все ок.
Заюзал, сократился код от 15 до 30 срок на разных сайтах. Спс.
Благодарю за полезные инструменты! Код оптимизируется от лишнего «мусора».
Спасибо!
Я еще добавляю для плагина Yoast SEO:
// Remove Canonical Link Added By Yoast WordPress SEO Plugin
function at_remove_dup_canonical_link() <
return false;
>
add_filter( ‘wpseo_canonical’, ‘at_remove_dup_canonical_link’ );
Если в шаблоне есть сразу код какнонических ссылок, то да, из yoast можно убрать.
Иначе не стоит, т.к. канонические ссылки важно для SEO
Артиклес сапе выдает ошибки, если что-то каноническое, приходится на некоторых сайтах отключать 🙂
Возможно мой вопрос покажется глупым, но я не совсем понимаю куда этот код нужно вставлять? Мне нужно в консоле сайта зайти внешний вид → редактор, найти файл functions.php и в самый конец этого файла вставить ваш код? И еще, прежде чем его вставлять ваши пояснения удалять или можно ставить прямо с ними?
Еще раз простите, я новичок! 🙁
8 сетевых ресурсов для удаления вредоносного кода и устранения последствий взлома сайта
Как удалить зараженный сайт из черных списков и очистить его от вредоносного кода?
Взломать или заразить сайт вредоносным кодом могут по многим причинам. Злоумышленники, как правило, используют следующие приемы:
Если вы не уверены, содержит ваш сайт уязвимости или нет, проверьте его с помощью следующих инструментов:
Знаю, взлом сайта может выбить из колеи, но не переживайте, вы не одиноки, а с помощью следующих специалистов вы сможете восстановить вашу деятельность.
Инструменты для удаления вредоносных программ и кода:
1. SUCURI
SUCURI — это один из самых популярных сервисов для обеспечения безопасности сайта. Он помогает устранить такие последствия взлома как:
С помощью SUCURI вы не просто сможете разово устранить все проблемы, но и защитить ваш сайт и предупредить взлом в будущем.
2. Wordfence
Wordfence предназначен для быстрого восстановления сайта на WordPress или Joomla. Знаете ли вы, что расширение Wordfence для WordPress уже установлено более миллионом пользователей?
С Wordfence вы получаете следующее:
3. SiteGuarding
Если вам требуется удалить вредоносный код с WordPress или Joomla в экстренном порядке, то SiteGuarding с этим справляется за 1-3 часа.
На SiteGuarding предусмотрено несколько вариантов удаления вредоносного кода. Можно выбрать то, что подходит именно вам.
В стоимость входит следующее:
4. 6SCAN
Услуги по удалению вредоносного кода входят в пакет защиты сайта «Профессионал». В рамках этого пакета услуг 6SCAN удалит вредоносный код и добавят нужные вам настройки мониторинга и безопасности.
5. StopTheHacker
StopTheHacker оказывает все услуги по защите сайта, в том числе и по очистке сайта от вредоносного кода. Вы можете либо самостоятельно очистить сайт, либо активировать автоматическую очистку StopTheHacker.
Вместе с очисткой вы получите:
6. Web Malware Removal
Web Malware Removal поможет вам удалить вредоносный скрипт, бэкдоры, попадание в черный список Google и защитит вас от будущих атак.
Вы получите и бесплатную проверку сайта на год и защиту от атак SQLi, XSS или брутфорса.
7. SiteLock
SiteLock — бренд, которому многие доверяют безопасность сайта, оказывающий в том числе и услуги удаления вредоносного кода. Сервис называется SiteLock911.
Механизм работы SiteLock911 отличается от других. Сначала программа скачивает файлы сайта, затем проверяет код, удаляет вредоносный скрипт и загружает исправленные файлы на сервер.
Все пакеты SiteLock предусматривают удаление вредоносного кода, а также следующие услуги:
8. Virusdie
Virusdie — сервис с говорящим названием. Он непрерывно проверяет сайт на наличие вредоносного кода и автоматически удаляет его после того, как находит.
Virusdie также защищает сайт от XSS, SQLi, DDoS-атак, помогает с резервным копированием и восстановлением данных и т.д.
Я бы хотел упомянуть еще два инструмента для защиты от DDoS-атак:
Как вы избавляетесь от неиспользуемого CSS-кода? Часть 1
Автор статьи, первую часть перевода которой мы сегодня публикуем, хотел бы, чтобы читатели заранее знали о том, что избавление от ненужного CSS — это трудная задача. Если вы это читаете в надежде найти некий инструмент, запустив который, вы сможете узнать о том, какой именно CSS-код можно безбоязненно удалить из вашего проекта, то… Есть подобные инструменты, но их нужно использовать крайне осторожно, так как ни один из них не способен дать достойный ответ на вопрос о неиспользуемом CSS.
Несложно понять, что любому веб-разработчику хотелось бы взять некую утилиту, запустить её, и удалить тот ненужный CSS, о котором она сообщит. Пара минут — и сайт ускорен. Но не всё так просто. Автор этого материала полагает, что к подобным инструмента стоит относиться со здоровым скептицизмом. Ни один из них не лжёт разработчику. Эти инструменты обычно просто не обладают достаточным объёмом информации, позволяющим им выдать результаты, которым можно безоговорочно доверять. Но это не означает, что такими инструментами невозможно пользоваться. Не значит это и того, что от неиспользуемого CSS никак нельзя избавиться. Обсудим это.
Зачем избавляться от неиспользуемого CSS?
Я полагаю, что главную причину, по которой кому-то может понадобиться избавиться от неиспользуемого CSS, можно описать с помощью следующего примера. Предположим, вы пользуетесь CSS-фреймворком (вроде Bootstrap), и в ваш проект попадает весь CSS-код этого фреймворка. А реально в проекте применяется лишь небольшая часть такого кода. Как избавиться от всего ненужного?
Я могу проникнуться чувствами того, кто оказался в подобной ситуации. CSS-фреймворки часто не дают разработчикам простых способов выбора именно тех возможностей, которые применяются в конкретных проектах. При этом доведение исходного кода фреймворка до состояния, идеально соответствующего некоему проекту, может потребовать от команды такого уровня опыта, которого у неё может и не быть. Подобная ситуация уже сама по себе может стать причиной поиска фреймворка.
Предположим, вы загружаете 100 Кб CSS. Я бы сказал, что это много. (В тот момент, когда я это пишу, на сайте css-tricks.com используется около 23 Кб CSS. Здесь имеется довольно много страниц и шаблонов. При этом я ничего особого не делал для того, чтобы уменьшить размер CSS.) Тут у вас возникает подозрение, что некую часть из этого объёма кода вы не используете. А, может быть, вы находите некие доказательства этого. Я тут вижу причину бить тревогу. Если у вас имеется JPG-файл объёмом в 100 Кб, который можно сжать до 20 Кб, обработав его неким инструментом, то это замечательно, и это стоит сделать. Но если нечто подобное сделать с CSS, то подобное гораздо важнее. Дело в том, что CSS загружается в начале загрузки страницы и является ресурсом, блокирующим рендеринг. JPG-файлы такими ресурсами не являются.
Анализ ситуации с помощью инструментов разработчика Chrome
Инструменты разработчика Chrome, вкладка Coverage
Мне неприятно это говорить, но анализ сайта с помощью вкладки Coverage оказался практически бессмысленным занятием. То, что я увидел, эти 70.7%, представляет собой ужасную картину, которая играет на моих сомнениях, но ничего конкретного этот анализ мне не даёт, в результате мне остаётся лишь беспокоиться о том, что на моём сайте что-то не так.
Возможно, подобный анализ сайта и будет тем самым механизмом, который наведёт вас на мысль о том, что вам нужно найти и удалить CSS-код, который загружается, но в вашем проекте не используется.
Моя первостепенная проблема
В деле поиска и удаления неиспользуемого CSS-кода меня больше всего беспокоит следующее. Предположим, некто смотрит на результаты анализа и видит неиспользуемые фрагменты CSS.
Неиспользуемые фрагменты CSS
Он думает: «Отлично, удаляю всё лишнее!». Лишнее удаляется, а потом оказывается, что было оно вовсе не лишним, и что его удаление привело к большим проблемам со стилизацией на всём сайте. Вот в чём тут дело: можно быть полностью уверенным в том, что некий CSS-селектор не используется, только если провести изыскания по следующему плану:
Нечто подобное — это слишком сложно для автоматических средств анализа CSS. Они не в состоянии идеально выполнить подобные проверки, особенно если учитывать анализ сайта в ситуации неопределённости. Речь идёт, например, об исследовании проектов в различных браузерных контекстах (разные размеры экранов, разные возможности браузеров, разные браузеры), и об учёте влияния на сайт сторонних библиотек.
А сейчас я хочу показать пример того, как все те проблемы, о которых я только что рассказал, выглядят на практике.
PurifyCSS Online
Я решил попробовать оптимизировать css-tricks.com с помощью ресурса PurifyCSS Online. Ему можно передавать ссылки, а он тут же выдаёт готовый к использованию CSS. Я «скормил» этому сайту css-tricks.com и в моём распоряжении оказался новый CSS-код. Вот что получилось после того, как я этим кодом воспользовался.
Слева — обычный вид css-tricks.com. Справа — результат применения нового, «очищенного» CSS. В этом новом коде недоставало много такого, что нужно для различных страниц сайта
Вероятно, я уже рассказал достаточно для того, чтобы вы поняли, что я не случайно так мало доверяю подобным инструментам.
Очистка CSS с помощью PurifyCSS как часть процесса сборки проекта
PurifyCSS, вероятно, чаще используется в роли инструмента, применяемого при сборке проекта, чем в роли онлайн-средства для очистки CSS. В документации проекта есть инструкции по его использованию при применении Grunt, Gulp и webpack. Вот, например, обработка файлов по шаблонам:
Такой подход позволяет добиться гораздо большей точности. Материалы сайта, передаваемые на анализ, могут представлять собой список, в который входит каждый шаблон, каждый фрагмент, используемый для построения страниц, каждый JavaScript-файл. Может оказаться так, что подобный список ресурсов непросто поддерживать, но это позволяет учесть всё, что можно учесть. Это, правда, не относится к содержимому страниц, лежащему в неких хранилищах (вроде блог-постов, которые хранятся в базе данных), и к стороннему JavaScript-коду, но, возможно, это в некоторых случаях и неважно, или, может быть, разработчик способен будет как-то учесть CSS-нужды подобных ресурсов.
В документации к конкуренту PurifyCSS PurgeCSS есть предупреждение, касающееся способа обработки ресурсов, используемого PurifyCSS. А именно, речь идёт о том, что PurifyCSS может работать с ресурсами любых типов, а не только с HTML и JavaScript. PurifyCSS в ходе работы анализирует все слова в файлах и сравнивает их с селекторами в CSS-коде. Каждое слово рассматривается как селектор. То есть — множество селекторов может быть ошибочно признано используемыми на сайте. Например, в текстовом наполнении файла, в обычном предложении, может присутствовать слово, соответствующее некоему CSS-селектору.
Об этой особенности PurifyCSS стоит помнить. Этот инструмент ищет CSS-селекторы в материалах сайта, применяя предельно простой алгоритм. Это, с одной стороны, толковая идея, а с другой — это довольно-таки опасно.
Сервис UnusedCSS
Ручная настройка некоего инструмента, проводимая так, чтобы этот инструмент проанализировал бы каждую страницу, чтобы он рассмотрел её со всех возможных точек зрения, это, конечно, скучная рутина. При этом такая работа должна проводиться на ежедневной основе, так как анализируемые сведения о сайте должны пополняться новыми данными по мере развития проекта. Существует один онлайн-сервис, который называется UnusedCSS. Он самостоятельно обходит страницы сайта, избавляя разработчика от массы однообразной работы. Этому сервису достаточно передать единственную ссылку на сайт.
Я оформил платную подписку на этот сервис и проанализировал с его помощью css-tricks.com. Надо признать, что после того, как я взглянул на результаты, у меня возникло такое ощущение, что выглядят они гораздо точнее, чем то, что мне доводилось видеть раньше.
Анализ css-tricks.com с помощью UnusedCSS. В отчёте говорится о том, что на сайте используется 93% от загружаемого CSS-кода. Мне это кажется близким к истине, так как я вручную написал весь CSS-код для этого сайта
Сервис, кроме того, позволяет загрузить файл с очищенным CSS-кодом и предлагает возможности по управлению содержимым этого файла. Например, это включение и отключение селекторов, которые разработчику хотелось бы или не хотелось бы добавлять в CSS-код. Предположим, разработчик видит имя класса, которое, по мнению UnusedCSS, на сайте не нужно, но разработчик совершенно точно знает о том, что без этого имени класса он обойтись не может. В результате ошибочно признанный ненужным код можно отметить как нужный. Среди других возможностей UnusedCSS можно отметить работу с префиксами и удаление дублирующихся селекторов.
Мне очень понравилось то, что UnusedCSS дал мне гораздо более точные результаты, чем другие инструменты. Однако в данных, выдаваемых этим сервисом, слишком много «шума», и я, к тому же, пока не знаю о том, как включить UnusedCSS в регулярно повторяющийся процесс сборки проекта и вывода его новых версий в продакшн.
Уважаемые читатели! Сталкивались ли вы с проблемой наличия неиспользуемого CSS-кода в своих проектах?