Minificatore HTML

Informazioni sulla minificazione HTML

L'HTML è la prima cosa che il browser scarica, analizza e visualizza a ogni caricamento di pagina. Il documento HTML si trova sul percorso di rendering critico: il browser non può iniziare a recuperare CSS, JS o immagini finché non ha analizzato abbastanza HTML per scoprire cosa siano. Ogni kilobyte di HTML trasferito e analizzato ritarda il Time to First Byte (TTFB) e il Largest Contentful Paint (LCP), due dei tre Core Web Vitals che Google usa come segnali di ranking. La minificazione HTML rimuove i byte che gli umani inseriscono per leggibilità (spazi tra i tag, commenti, sintassi ridondante degli attributi) senza cambiare ciò che il browser vede. La compressione Gzip e Brotli al margine della CDN gestisce la maggior parte della dimensione (i nomi di tag ripetuti si comprimono splendidamente), ma la minificazione applicata sopra fa risparmiare tipicamente 5-15% di byte aggiuntivi rimuovendo ciò che il compressore non riesce a vedere (byte semanticamente morti che si comprimono in output simile ma non identico). Sembra poco finché non si moltiplica per ogni richiesta di pagina su un sito ad alto traffico; la fattura della larghezza di banda e il miglioramento di LCP contano entrambi su larga scala.

Ci sono due casi complementari in cui i risparmi sono più ampi: pagine renderizzate lato server (Next.js, Remix, Hugo, Eleventy) dove l'HTML viene generato fresco a ogni richiesta e i template del framework includono spesso indentazione generosa e commenti utili; e build di siti statici dove la minificazione viene eseguita una volta sola in fase di build e il guadagno resta per sempre. I generatori di siti statici moderni offrono la minificazione HTML come opzione di build: il flag --minify di Hugo è arrivato con la v0.47 (17 agosto 2018), Eleventy usa html-minifier-terser tramite plugin, Next.js applica la minificazione attraverso SWC, e Astro 3.0 include la minificazione HTML built-in con l'integrazione opzionale astro-compress sovrapposta. Per HTML scritto a mano o template senza pipeline di build, questo minificatore in-browser è la strada di minor resistenza.

Cosa fa davvero un minificatore

• Collasso degli spazi tra elementi. Spazi e a-capo tra i tag vengono rimossi: <p> Ciao </p> diventa <p>Ciao</p> quando è sicuro farlo. Il qualificatore "quando è sicuro" è importante: lo spazio tra elementi inline (<span>, <a>, <em>) viene reso visivamente (quindi "foo bar" deve preservare lo spazio tra gli span). Lo spazio tra elementi a blocco (<div>, <p>) di solito no.
• Rimozione dei commenti. I blocchi <!-- ... --> vengono eliminati. I commenti condizionali (<!--[if IE]>...<![endif]-->) vengono preservati quando presenti, anche se Microsoft ha rimosso l'elaborazione dei commenti condizionali da Internet Explorer 10 in poi: sono sicuri da eliminare su qualsiasi sito che non supporti IE9 o precedenti.
• Semplificazione degli attributi. Le virgolette degli attributi vengono rimosse quando il valore non contiene spazi, >, = né caratteri di virgolette di alcun tipo: class="btn" diventa class=btn. Gli attributi booleani vengono semplificati: disabled="disabled", checked="checked", selected="selected", readonly="readonly" diventano tutti il solo nome dell'attributo. I valori di default degli attributi vengono eliminati: type="text" su un input, type="text/javascript" su un tag script, method="get" su un form.
• Gli elementi void restano void. <br>, <hr>, <img>, <input>, <meta> e <link> non hanno tag di chiusura in HTML5. La barra di auto-chiusura XHTML (<br />) viene eliminata: <br /> diventa <br>.
• Contenuto protetto. I contenuti di <pre>, <textarea>, <script> e <style> vengono preservati alla lettera perché lo spazio al loro interno è significativo. JavaScript e CSS inline necessitano di passaggi di minificazione separati (strumenti dedicati).

I casi in cui lo spazio è significativo e che ti faranno male

Il rischio più grande nella minificazione HTML è collassare lo spazio dove conta. Gli elementi inline con spazio circostante rendono lo spazio come uno spazio visibile; foo <em>bar</em> baz ha spazi attorno a bar; se un minificatore collassa quegli spazi a nulla, il testo renderizzato diventa "foobarbaz" senza separazione. I minificatori conservativi preservano qualsiasi singolo spazio tra testo ed elementi inline; quelli aggressivi (con conservativeCollapse: true disattivato) lo rimuovono. Anche lo spazio dentro elementi con CSS white-space: pre viene reso; i minificatori non possono vedere le regole CSS e potrebbero collassarlo in modo errato. I commenti rimossi all'interno di commenti condizionali possono rompere comportamenti specifici di IE su siti legacy. I commenti usati come marcatori di build (i placeholder <!---> di Vue, le <!--bindings={...}--> di Angular) devono sopravvivere al passaggio di minificazione. I minificatori moderni gestiscono questi casi; un approccio basato solo su regex (questo strumento) è conservativo: preserva lo spazio dentro i blocchi protetti ma non ha piena consapevolezza inline-vs-block. Per siti di produzione con prosa ricca di elementi inline, testa l'output minificato prima del deploy.

La sintassi permissiva di HTML5 e perché XHTML ha perso

La permissività di HTML5 è ciò che rende possibile la minificazione. XHTML (la variante abbandonata di HTML con sintassi XML) richiedeva una sintassi rigorosa: ogni tag chiuso, ogni attributo virgolettato, ogni attributo scritto in minuscolo. XHTML 2.0 fu abbandonato quando il suo charter W3C scadde il 2 luglio 2009; HTML5 divenne una W3C Recommendation il 28 ottobre 2014. HTML5 consente deliberatamente più sintassi equivalenti: <br> e <br/> sono entrambi legali; type="text" su un input è il default e può essere omesso; le virgolette attorno a class=btn sono opzionali quando il valore è semplice. Questa permissività è esattamente ciò che i minificatori sfruttano: ogni elemento sintattico "opzionale" è byte che il minificatore può eliminare. Il compromesso è che l'HTML minificato è più difficile da leggere per gli umani (il che va bene perché nessuno legge l'HTML di produzione, se non tramite "Visualizza sorgente").

Breve storia degli strumenti di minificazione HTML

HTMLMinifier di Will Peavy (lo strumento willpeavy.com, dalla metà degli anni 2000 fino a circa il 2010) è stato il minificatore HTML basato su browser originale e più citato: uno strumento single-page che prendeva HTML incollato ed emetteva una versione ripulita. html-minifier di kangax (Juriy "kangax" Zaytsev, annunciato il 9 marzo 2010 sul suo blog Perfection Kills) è stato il primo serio minificatore HTML Node.js consapevole dell'AST; per quasi un decennio è stato lo strumento Node canonico, usato da webpack-html-plugin, dalle pipeline Gulp e dalla maggior parte dei generatori di siti statici. L'ultimo rilascio di kangax è stato la v4.0.0 il 1° aprile 2019; il repository è di fatto non manutenuto dal 2021 ma non è formalmente archiviato. html-minifier-terser (mantenuto da Daniel Ruf con contributi di kangax, Alex Lam e altri) è il fork attivamente mantenuto che ha raccolto il testimone dove kangax si era fermato; è ciò che webpack-html-plugin usa di default oggi e ciò che la maggior parte delle pipeline di build esegue effettivamente. minify-html di Wilson Lin è un minificatore basato su Rust con prestazioni sostanzialmente migliori per input HTML grandi. tdewolff/minify è l'alternativa Go usata in Hugo e in vari generatori di siti statici basati su Go. swc e Lightning CSS hanno supporto HTML nelle rispettive toolchain Rust, usate rispettivamente da Next.js (che è passato da Babel a SWC a partire da Next.js 12) e Parcel. html-minifier-next (annunciato tramite issue GitHub #1165 il 10 luglio 2025) è il fork kangax più recente verso cui alcuni progetti stanno migrando.

L'HTML per email, un mondo a parte

L'HTML per email è il suo proprio campo minato di minificazione. I client di posta hanno parser notoriamente eterogenei: Outlook 2007-2019 usa il rendering HTML di Microsoft Word (progettato per documenti elaborati da word processor, non per il web), Gmail elimina i tag <style> sopra una certa soglia di dimensione, Apple Mail e Yahoo Mail seguono gli standard web più da vicino. Le regole di minificazione HTML per il web non si applicano tutte alle email: rimuovere lo spazio tra i tag può rompere il layout di Outlook; rimuovere virgolette opzionali può rompere alcuni parser webmail; rimuovere l'attributo type="text/css" sui tag <style> inline può essere silenziosamente eliminato da Gmail. Il livello "giusto" di minificazione per email è molto più conservativo che per HTML web, tipicamente solo rimozione di commenti e spazi, lasciando intatto tutto il resto. Strumenti specifici per email come MJML e Foundation for Emails gestiscono le stranezze dell'HTML email in fase di compilazione; eseguire un minificatore HTML web generico su un template Mailchimp probabilmente lo romperà in Outlook.

AMP HTML e l'approccio validator-first

Il progetto Accelerated Mobile Pages di Google (lanciato il 7 ottobre 2015) adotta l'approccio opposto: invece di minificare a posteriori, AMP definisce un sottoinsieme rigoroso di HTML che è già piccolo per costruzione. AMP richiede un singolo blocco <style amp-custom> inline (75 KB max dal 13 marzo 2020, alzato dai 50 KB precedenti), vieta la maggior parte di JavaScript tranne amp-script e usa un validatore rigoroso per imporre tutte le regole. Il progetto è stato deprioritizzato nel 2021-2022 quando il vantaggio di ranking del carosello AMP è stato ridotto, e molti editori si sono allontanati da AMP a favore di HTML normale minificato e ottimizzato; è ancora usato da editori di notizie che dipendono dal traffico di Google Discover. La rilevanza per un minificatore HTML generico è che AMP mostra come appare uno standard HTML aggressivamente attento ai byte: opinionato, imposto da validatore e piccolo.

Ambito onesto: cosa fa e non fa questo strumento

Questo strumento è un minificatore HTML basato su regex, circa 30 righe di JavaScript. Tokenizza i contenuti di <pre>, <textarea>, <script> e <style> in placeholder così che le trasformazioni successive non possano corromperli; elimina i commenti <!-- ... --> (con un lookahead per preservare i commenti condizionali <!--[if); collassa lo spazio tra i tag; rimuove conservativamente le virgolette degli attributi quando i valori contengono solo caratteri sicuri ([a-zA-Z0-9_-]+); e semplifica un elenco hardcoded di quindici attributi booleani. Ciò che questo strumento non fa, e che i minificatori di produzione gestiscono: non elimina i tag di chiusura opzionali (</li>, </td> in molti contesti), che richiede comprendere il content model di HTML5; non rimuove gli attributi ridondanti dai valori di default (type="text" sugli input, type="text/javascript" sugli script) oltre a quelli esplicitamente elencati; non minifica i contenuti di <style> o <script> inline (usa gli strumenti dedicati CSS Minifier e JS Minifier per quelli, poi reincolla); non ordina alfabeticamente gli attributi (cosa che può migliorare leggermente la compressione gzip); non gestisce le regole di minificazione specifiche per SVG. Per progetti con una pipeline di build, usa html-minifier-terser, minify-html o swc; per HTML una tantum, questo strumento elimina l'attrito.

Privacy: perché "solo browser" qui conta

I minificatori HTML lato server richiedono il caricamento del sorgente. Per pagine web pubblicate questo è innocuo (l'HTML è già pubblico). Per template di strumenti admin interni, pagine di prodotto non ancora rilasciate, varianti HTML di test A/B o template email con contenuto personalizzato, la minificazione lato server è una fuga di dati. Questo strumento esegue l'intera trasformazione nel tuo browser tramite JavaScript: niente attraversa la rete. Verifica nel pannello Network di DevTools mentre clicchi Minify, oppure metti la pagina offline (modalità aereo) dopo che si è caricata e lo strumento continuerà a funzionare.

Domande frequenti