Что делается
Три операции по порядку: удаление HTML-комментариев, сведение цепочек пробелов к одному и удаление пробелов между соседними тегами. Всё остальное не трогается.
Что защищено
<pre>и<textarea>— пробелы там являются видимым содержимым<script>и<style>— другой язык со своими правилами<!--[if ...]>— условные комментарии являются директивами, а не заметками
Где экономия реальна
Для страницы, отдаваемой с gzip или brotli, после сжатия останутся единицы процентов. Делать это стоит там, где сжатия нет:
- HTML-письма, где клиент часто получает исходную нагрузку
- Инлайновый SVG или шаблонная строка внутри JavaScript
- Разметка, лежащая в колонке базы или в поле JSON
- Всё, где есть жёсткий лимит размера
В остальных случаях — в сборку, а исходники оставить читаемыми.
Вопросы
Есть ли смысл минифицировать HTML, если есть gzip?+
Для большинства сайтов — небольшой. Сжатие и так хорошо справляется с повторяющимися пробелами, дополнительная экономия обычно в пределах нескольких процентов. Смысл появляется там, где сжатия нет или размер невелик: шаблон письма, инлайновый SVG, фрагмент внутри JSON.
Что не удаляется?+
Всё внутри pre, textarea, script и style, а также условные комментарии. Первые два — потому что там пробелы являются видимым содержимым, вторые два — потому что внутри другой язык, а условные комментарии — потому что это инструкции, а не заметки.
Может ли это сломать страницу?+
Схлопывание пробелов между строчными элементами способно убрать отрисовываемый пробел. Этот минификатор сводит цепочки пробелов к одному, а не удаляет их между текстом, поэтому видимый зазор сохраняется, — но страницу с плотной строчной вёрсткой стоит проверить перед выкладкой.
Стоит ли минифицировать вручную?+
Нет. Это инструмент для разовых фрагментов и для того, чтобы увидеть реальную разницу. В настоящем проекте этим должна заниматься сборка, чтобы исходники в репозитории оставались читаемыми.