Minifikuj HTML _

Jak działa minifikacja HTML?

Minifikator przetwarza twoje dane wejściowe małą maszyną stanów, która odróżnia regiony zachowywane bez zmian (<pre>, <textarea>, <script>, <style>) od regionów edytowalnych, w których białe znaki i komentarze można bezpiecznie zwinąć.

1. Tokenizacja bloków zachowywanych. Skaner czyta dane wejściowe znak po znaku i przechodzi do stanu zachowywania, gdy natrafi na otwierający tag <pre>, <textarea>, <script> lub <style>. Wszystko wewnątrz tych tagów jest kopiowane bajt po bajcie aż do pasującego tagu zamykającego.
2. Zwijanie edytowalnych białych znaków. W regionach edytowalnych skaner zwija każdy ciąg spacji, tabulatorów i znaków nowej linii do jednej spacji, a następnie przycina wiodące i końcowe białe znaki wokół granic tagów. Widoczny tekst reflow-uje się tak samo, jak renderuje go przeglądarka.
3. Usuwanie komentarzy. Bloki <!-- ... --> są usuwane, gdy przełącznik jest włączony. Komentarze warunkowe IE (<!--[if IE]> ... <![endif]-->) pozostają, gdy przełącznik ich zachowania jest włączony, ponieważ starsze klienty pocztowe nadal je wykorzystują.
4. Zwijanie atrybutów logicznych. Rozwlekłe formy jak checked="checked", disabled="disabled" i required="required" kurczą się do samej nazwy atrybutu. Specyfikacja HTML5 traktuje tę skróconą formę jako semantycznie identyczną, więc renderowane drzewo DOM pozostaje niezmienione.
5. Raportowanie różnic bajtów. Zarówno oryginalny, jak i zminifikowany tekst są mierzone przez new TextEncoder().encode(...).byteLength — to ten sam licznik bajtów UTF-8, który widzi CDN lub serwer HTTP na łączu. Panel metryk pokazuje oryginalny rozmiar, rozmiar zminifikowany, zaoszczędzone bajty i procent oszczędności.

Dlaczego minifikować HTML?

• Szybsze ładowanie stron. Mniejszy HTML dociera do przeglądarki szybciej, a parser kończy pracę wcześniej. W sieciach mobilnych oszczędności bajtów przekładają się bezpośrednio na szybszy First Contentful Paint i lepszy wynik Lighthouse.
• Niższe rachunki za egress CDN. CloudFront, Cloudflare i Fastly naliczają opłaty za gigabajt egress. Redukcja HTML o 20 procent na milionach miesięcznych odsłon kumuluje się w realne oszczędności na fakturze, zanim jeszcze wdroży się optymalizację obrazów czy skryptów.
• Czystsze diffy pull-requestów. Wstępnie zbudowany statyczny HTML zapisany w repozytorium generuje szum, gdy każda zmiana szablonu przereflowuje wcięcia. Zminifikowany HTML w folderze dist tworzy ciasne diffy PR skupione na rzeczywistych zmianach treści zamiast na szumie białych znaków.
• Mniejsze osadzenia i snippety. Szablony e-mailowe, snippety widgetów firm trzecich i HTML przechowywany w konfiguracjach JSON lub YAML — wszystkie korzystają z tych samych oszczędności bajtów. Zminifikowane osadzenia utrzymują wiadomości transakcyjne poniżej limitów rozmiaru ESP i zmniejszają paczki widgetów.

Typowe zastosowania

Minifikacja HTML pojawia się na końcu niemal każdego pipeline budowania strony statycznej lub JAMstack, plus kilka kontekstów runtime, gdzie bajty są ważniejsze niż czytelność kodu źródłowego.

• Kroki budowania stron statycznych: Eleventy, Hugo, Astro i produkcyjne builde Next.js przepuszczają HTML przez minifikator przed zapisem do folderu dist, aby wdrożony bundle był mniejszy od źródła.
• E-maile transakcyjne: ESP (SendGrid, Postmark, Mailgun) limitują rozmiar body HTML, a rozszerzanie inline-CSS szybko ten limit osiąga. Minifikacja body przed wysyłką utrzymuje wiadomość poniżej limitu.
• Osadzone widgety: widgety firm trzecich i snippety czatu dostarczane jako inline HTML korzystają z każdej redukcji bajtów, bo strona hosta pobiera je przy każdej wizycie.

Przykład krok po kroku

Wklej rozwlekły snippet formularza o 500 bajtach z wcięciem dwuspacjowym, trzema łamaniami wierszy między wierszami, blokiem komentarza HTML na górze i <input type="checkbox" checked="checked" />. Po włączeniu wszystkich opcji wynik kurczy się do około 300 bajtów — około 40 procent oszczędności — podczas gdy renderowane drzewo DOM pozostaje bajtowo równe źródłu.

Czy minifikacja może zepsuć mój HTML?

Nie, przy domyślnych przełącznikach. Minifikator zachowuje zawartość tagów <pre>, <textarea>, <script> i <style> dosłownie, pozostawia komentarze warunkowe IE niezmienione, gdy ten przełącznik jest włączony, i zwija tylko białe znaki, które parser HTML5 już klasyfikuje jako nieistotne. Renderowane drzewo DOM jest bajtowo równe źródłu. Agresywne przełączniki (usuń-puste-atrybuty) mogą zmienić zachowanie snippetów, które celowo używają value="" lub alt="", więc przejrzyj wynik, jeśli je włączysz.

Czy narzędzie minifikuje inline CSS i JS?

Nie w tym narzędziu. Zawartość inline <style> i <script> jest zachowywana dosłownie, żeby minifikator nigdy nie złamał reguły CSS ani wyrażenia JS przez zwinięcie białego znaku wewnątrz literału tekstowego lub wyrażenia regularnego. Do minifikacji CSS użyj minifikatora CSS; do JS — minifikatora JS. Minifikator HTML skupia się na samym markupie.

Ile mogę zaoszczędzić?

Typowe oszczędności na pisanym ręcznie HTML wynoszą od 10 do 30 procent, w zależności od tego, jak bardzo źródło korzysta z wcięć, pustych wierszy i rozwlekłych form atrybutów. Wstępnie zbudowany statyczny HTML z frameworków takich jak Next.js często oszczędza 15 do 25 procent, bo framework już przeprowadza pewną optymalizację, ale zostawia czytelne dla człowieka białe znaki. Szablony pełne komentarzy i HTML w stylu e-mailowym z głębokim zagnieżdżeniem mogą osiągnąć 40 procent lub więcej.

Czy zawartość pre jest zachowywana?

Tak. Minifikator jawnie tokenizuje bloki <pre>, <textarea>, <script> i <style> jako regiony zachowywane bez zmian i kopiuje ich zawartość bajt po bajcie do wyjścia. Białe znaki, łamania wierszy i wcięcia wewnątrz tych tagów pozostają nienaruszone, więc przykłady kodu i ASCII art renderują się tak samo po minifikacji.

Przeglądarkowa minifikacja HTML utrzymuje pipeline budowania prostym, a markup małym. Wklej dowolny HTML powyżej, dostosuj przełączniki opcji i skopiuj lub pobierz zminifikowany wynik — bez wysyłania, bez konta, bez biblioteki dostawcy.