Mag-minify ng HTML _

Paano gumagana ang HTML minification

Ang minifier ay nagta-traverse ng iyong input gamit ang isang maliit na state machine na nagpapaiba ng mga preserve-as-is na rehiyon (<pre>, <textarea>, <script>, <style>) mula sa mga nae-edit na rehiyon kung saan ligtas na i-collapse ang whitespace at mga komento.

1. I-tokenize ang mga preserve block. Binabasa ng scanner ang input character-by-character at lumilipat sa preserve state kapag nakatagpo ng opening na <pre>, <textarea>, <script>, o <style> tag. Ang lahat ng nasa loob ng mga tag na iyon ay pinananatiling byte-for-byte hanggang sa matching na pang-sara.
2. I-collapse ang nae-edit na whitespace. Sa mga nae-edit na rehiyon, niko-collapse ng scanner ang bawat run ng mga espasyo, tab, at newline pababa sa isang espasyo, pagkatapos ay nagta-trim ng leading at trailing na whitespace sa paligid ng mga hangganan ng tag. Ang visible na teksto ay nagre-reflow sa parehong paraan na niri-render ito ng browser.
3. Alisin ang mga komento. Inaalis ang mga <!-- ... --> block kapag naka-on ang toggle. Ang mga IE conditional comment (<!--[if IE]> ... <![endif]-->) ay nakakaligtas kapag naka-on ang preserve-conditional toggle, dahil umaasa pa rin ang mga legacy email client sa mga ito.
4. I-collapse ang mga boolean attribute. Ang mga verbose na form tulad ng checked="checked", disabled="disabled", at required="required" ay nagko-collapse sa pangalan ng attribute na lang. Itinuturing ng HTML5 spec ang bare form bilang semantically na kapareho, kaya ang rendered na DOM ay hindi nababago.
5. I-report ang byte delta. Ang parehong orihinal at minified na teksto ay sinusukat gamit ang new TextEncoder().encode(...).byteLength, ang parehong UTF-8 byte count na nakikita ng CDN o HTTP server sa wire. Ipinapakita ng metric strip ang orihinal na laki, minified na laki, bytes saved, at saved na porsyento.

Bakit mag-minify ng HTML

• Mas mabilis na pag-load ng page. Ang mas maliit na HTML ay mas mabilis na nakakarating sa browser at mas maaga na natatapos ang parser. Sa mga mobile network ang byte savings ay direktang nagsasalin sa mas mabilis na First Contentful Paint at mas magandang Lighthouse performance score.
• Mas mababang CDN egress na bayad. Ang CloudFront, Cloudflare, at Fastly ay nagsi-singil bawat gigabyte ng egress. Ang 20 porsyentong pagbawas sa HTML sa milyun-milyong buwanang view ay nagiging tunay na pagtitipid sa invoice, bago pa man dumating ang anumang image o script optimization.
• Mas malinis na pull-request diff. Ang pre-built na static HTML na naka-commit sa isang repo ay nagiging maingay kapag ang bawat template tweak ay nagre-reflow ng indentation. Ang minified na HTML sa dist folder ay gumagawa ng mas masikip na PR diff na nagtutuon sa tunay na content change sa halip na whitespace na palitan.
• Mas maliliit na embed at snippet. Ang mga email template, third-party widget snippet, at HTML na nakaimbak sa loob ng JSON o YAML na config ay lahat nakikinabang sa parehong byte cut. Ang minified na embed ay nagpapanatili ng mga transactional email na mababa sa mga ESP size cap at nagpapaliit ng mga widget bundle.

Mga karaniwang paggamit

Ang HTML minification ay lumalabas sa dulo ng halos bawat static-site o JAMstack build pipeline, kasama ang ilang runtime na konteksto kung saan mas mahalaga ang mga byte kaysa sa readability ng source.

• Mga static-site build step: ang Eleventy, Hugo, Astro, at Next.js production build ay nagpapatakbo ng HTML sa isang minifier bago sumulat sa dist folder para ang deployed na bundle ay mas maliit kaysa sa source.
• Mga transactional email: ang mga ESP (SendGrid, Postmark, Mailgun) ay may limit sa laki ng HTML body at ang pag-expand ng inline-CSS ay mabilis na nagpapalaki ng bilang. Ang pag-minify ng body bago magpadala ay nagpapanatili ng mensahe na mababa sa limit.
• Mga embedded widget: ang mga third-party widget at chat snippet na ipinadala bilang inline na HTML ay nakikinabang sa bawat byte cut dahil ang host na page ay kailangang i-download ang mga ito sa bawat pagbisita.

Isang halimbawang trabaho

Mag-paste ng verbose na 500-byte na form snippet na may two-space indentation, tatlong line break sa pagitan ng mga row, isang HTML comment block sa itaas, at isang <input type="checkbox" checked="checked" />. Sa lahat ng opsyon na naka-on, ang output ay nag-ko-collapse sa humigit-kumulang 300 bytes — humigit-kumulang 40 porsyentong pagtipid — habang ang rendered na DOM tree ay nananatiling byte-equal sa source.

Masisira ba ng minification ang aking HTML?

Hindi, kapag ginamit kasama ang mga default na toggle. Ang minifier ay pinapanatili ang nilalaman ng <pre>, <textarea>, <script>, at <style> tag nang buo, iniiwanan ang mga IE conditional comment kapag naka-on ang toggle na iyon, at niko-collapse lamang ang whitespace na inuri na ng HTML5 parser bilang walang kahalagahan. Ang rendered na DOM tree ay byte-equal sa source. Ang mga aggressive na toggle (remove-empty-attributes) ay maaaring magbago ng gawi para sa mga snippet na sadyang gumagamit ng value="" o alt="", kaya suriin ang output kung ifi-flip mo ang mga ito.

Nag-mi-minify ba ito ng inline CSS at JS?

Hindi sa tool na ito. Ang mga inline na <style> at <script> body ay pinapanatiling buo para hindi masira ng minifier ang isang CSS rule o isang JS statement sa pamamagitan ng pag-collapse ng whitespace sa loob ng isang string literal o isang regex. Para sa CSS-specific na minification, gumamit ng CSS Minifier; para sa JS, gumamit ng JS Minifier. Ang HTML Minifier ay nakatutok sa markup mismo.

Magkano ang maaari kong matipid?

Ang karaniwang pagtitipid sa hand-authored na HTML ay mula 10 hanggang 30 porsyento, depende sa kung gaano kadalas ang source ay gumagamit ng indentation, blank line, at verbose na attribute form. Ang pre-built na static HTML mula sa mga framework tulad ng Next.js ay madalas na nakatitipid ng 15 hanggang 25 porsyento dahil ang framework ay gumagawa na ng ilang optimization ngunit iniiwan ang human-readable na whitespace. Ang mga heavily-commented na template at email-style na HTML na may malalim na nesting ay maaaring umabot sa 40 porsyento o higit pa.

Napapanatili ba ang pre content?

Oo. Ang minifier ay tahasang nagto-tokenize ng <pre>, <textarea>, <script>, at <style> block bilang mga preserve-as-is na rehiyon at kinokopya ang nilalaman ng mga ito byte-for-byte sa output. Nakakaligtas ang whitespace, line break, at indentation sa loob ng mga tag na iyon nang hindi nababago, kaya ang mga code sample at ASCII art ay nag-re-render nang eksakto pagkatapos ng minification.

Ang browser-side HTML minification ay nagpapanatiling simple ang iyong build pipeline at maliit ang iyong markup. Mag-paste ng anumang HTML sa itaas, ayusin ang mga opsyong toggle, at kopyahin o i-download ang minified na output — walang upload, walang account, walang vendor library.