Компрессор HTML

Зачем вообще минифицировать HTML

HTML, который вы пишете для людей, полон того, что браузерам не нужно: отступы, переносы строк между тегами, комментарии разработчика и порой пустой атрибут. Ничто из этого не влияет на то, как отображается страница, но всё это добавляет байты. Умножьте эти байты на каждого посетителя и каждую загрузку страницы, и потери превратятся в реальный трафик и реальное время ожидания. Минификация убирает косметические символы, чтобы разметка, путешествующая по сети, была настолько маленькой, насколько нужно браузеру, и не больше.

Меньший HTML означает более быстрый первый байт осмысленного содержимого, более низкие расходы на трафик хостинга и CDN и лучший опыт на медленных или лимитированных мобильных соединениях. На высоконагруженных сайтах экономия накапливается, а поскольку HTML — это самый первый ресурс, который скачивает браузер, его уменьшение помогает странице начать отрисовку раньше.

Что убирает компрессор

Каждый параметр нацелен на конкретный источник «жира». «Удалить HTML-комментарии» убирает заметки разработчика и закомментированный код, которые посетители никогда не видят. «Удалить лишние пробелы» схлопывает последовательности пробелов, табуляций и переносов строк между тегами, существующие лишь ради читаемости. «Удалить пустые атрибуты» убирает атрибуты без значения, а «Удалить необязательные HTML-теги» опускает закрывающие теги, которые спецификация HTML разрешает не писать, например конечные теги элементов списка в некоторых контекстах.

«Сократить логические атрибуты» — небольшой, но аккуратный выигрыш: атрибутам вроде disabled или checked в HTML не нужно значение, поэтому развёрнутая запись вида disabled со значением «disabled» сокращается до одного лишь имени атрибута. Вместе эти проходы убирают символы, которые никак не влияют на отрисовку, — именно поэтому стандартная минификация безопасна для корректно сформированных страниц.

Разобранный пример

Представьте фрагмент с отступом в четыре пробела, HTML-комментарием над элементом div и флажком input, записанным с checked со значением «checked». После сжатия отступ и перенос строки схлопываются, так что теги встают вплотную, комментарий исчезает полностью, а флажок превращается просто в input с «голым» атрибутом checked. Страница выглядит и ведёт себя в браузере точно так же, но число байтов падает, а панель статистики сообщает исходный размер, сжатый размер и процент экономии, чтобы вы видели выигрыш именно для вашего файла.

Что безопасно убирать, а что рискованно

Граница, которую нужно уважать, — это пробелы, от которых страница действительно зависит. Внутри элементов pre и textarea значим каждый пробел и перенос строки: он отображается дословно, поэтому его схлопывание заметно изменило бы вывод. Та же осторожность относится к элементам, чей CSS устанавливает white-space для сохранения форматирования. Комментарии обычно безопасно удалять, но некоторые из них несущие, например устаревшие условные комментарии Internet Explorer или комментарии, которые система шаблонов или фреймворк читает как маркеры; их удаление может сломать поведение.

Параметры минификации CSS и JavaScript помечены как экспериментальные не зря. Минификация встроенного CSS в тегах и атрибутах style или JavaScript в тегах script подразумевает переписывание кода, а не просто обрезку пробелов разметки, и тут существуют крайние случаи. Всегда тестируйте страницу после их включения, особенно если ваши скрипты зависят от конкретного форматирования, директив в комментариях или хрупкой работы со строками.

Как минификация связана с gzip

Серверы почти всегда отправляют HTML, сжатый с помощью gzip или Brotli, и иногда люди полагают, что это делает минификацию бессмысленной. Это не так. Gzip отлично сжимает повторяющийся текст, поэтому относительный процент, который он экономит поверх минифицированного HTML, меньше, чем на сыром HTML, но эти два приёма складываются: «минифицированный, затем сжатый gzip» всё равно меньше, чем «красиво отформатированный, затем сжатый gzip». Минификация также уменьшает байты, которые браузер должен разобрать после распаковки, и сокращает размер, хранимый в кэшах.

Считайте их взаимодополняющими слоями. Минификация убирает содержимое, которое браузеру не нужно; затем gzip и Brotli сжимают то, что осталось, для передачи. Использование обоих даёт наименьший объём от начала до конца.

Где минификация вписывается в конвейер сборки

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

Он также удобен для осмотра и обучения: вставьте страницу, запустите и прочтите процент сокращения, чтобы оценить, сколько «жира» несёт ваша разметка, — это может выявить привычки вроде чрезмерных комментариев или глубоко вложенных шаблонов, которые стоит исправить в самом исходнике.

Распространённые ошибки, которых стоит избегать

Самая разрушительная ошибка — минифицировать содержимое, зависящее от пробелов, а потом обнаружить, что текст внутри блока pre или примера кода потерял форматирование; оставляйте такие места нетронутыми или тщательно их проверяйте. Другая — убрать условные или директивные комментарии, на которые что-то опирается ниже по конвейеру. Более тонкая ловушка — править минифицированный файл напрямую: как только пробелы исчезли, код трудно поддерживать, поэтому всегда держите ваш читаемый исходник как источник истины и относитесь к минифицированной версии как к генерируемому артефакту. И всякий раз, когда вы включаете экспериментальные проходы CSS или JS, тестируйте «живую» страницу перед публикацией.