Gzip contro minify

L’altro giorno ho avuto una discussione piuttosto vivace sulla minimizzazione di Javascript e CSS rispetto a qualcuno che preferisce usare Gzip.

Chiamerò questa persona X.

X ha detto che Gzip minimizza già il codice, dato che cancella i tuoi file.

Non sono d’accordo. Zip è un metodo senza perdita di dimensione del file. Lossless significa che l’originale deve essere ripristinato perfettamente, il che significa che le informazioni devono essere memorizzate per poter ripristinare gli spazi, i caratteri non necessari, il codice commentato e tutto il resto. Questo occupa più spazio, dal momento che più deve essere compresso.

Non ho alcun metodo di test, ma credo che il Gzip di questo codice:

.a1 { background-color:#FFFFFF; padding: 40px 40px 40px 40px; } 

Sarà ancora più grande del Gzip di questo codice:

 .a1{body:background-color:#FFF;padding:40px} 

C’è qualcuno in grado di dimostrare questo giusto o sbagliato.
E per favore non venite a dire “È giusto perché è quello che ho sempre usato”.

Sto chiedendo prove scientifiche qui.

Molto semplice da testare. Ho preso il tuo js, ​​li ho messi in file diversi e ho eseguito gzip -9 su di essi. Ecco il risultato. Questo è stato fatto su una macchina WinXP con Cygwin e gzip 1.3.12.

 -rwx------ 1 xxxxxxxx mkgroup-ld 88 Apr 30 09:17 expanded.js.gz -rwx------ 1 xxxxxxxx mkgroup-ld 81 Apr 30 09:18 minified.js.gz 

Ecco un altro test usando un esempio JS del mondo reale. Il file sorgente è “common.js”. La dimensione del file originale è 73134 byte. Minificato, arrivò a 26232 byte.

File originale:

 -rwxrwxrwx 1 xxxxxxxx mkgroup-ld 73134 Apr 13 11:41 common.js 

File miniato:

 -rwxr-xr-x 1 xxxxxxxx mkgroup-ld 26232 Apr 30 10:39 common-min.js 

File originale gzip con opzione -9 (stessa versione di sopra):

 -rwxrwxrwx 1 xxxxxxxx mkgroup-ld 12402 Apr 13 11:41 common.js.gz 

File minisito gzip con opzione -9 (stessa versione di sopra):

 -rwxr-xr-x 1 xxxxxxxx mkgroup-ld 5608 Apr 30 10:39 common-min.js.gz 

Come puoi vedere, c’è una netta differenza tra i vari metodi. La soluzione migliore è sia per minify che per gzip.

Ecco i risultati di un test che ho fatto un po ‘di tempo fa, usando un file CSS “reale” dal mio sito web. CSS Optimiser è usato per la minimizzazione. L’app di archiviazione Linux standard fornita con Ubuntu è stata utilizzata per Gzipping.

Originale: 28.781 byte
Minificato: 22.242 byte
Gzip: 6.969 byte
Min + Gzip: 5,990 byte

La mia opinione personale è di andare per Gzipping per primo, dal momento che ovviamente fa la differenza più grande. Per quanto riguarda la minificazione, dipende da come lavori. Dovresti conservare il file CSS originale per apportare modifiche più avanti. Se non ti infastidisce minimizzarlo dopo ogni cambiamento, allora fallo.

(Nota: ci sono altre soluzioni, come eseguirlo attraverso un minificatore “on-demand” durante la pubblicazione del file e la sua memorizzazione nella cache nel filesystem.)

Attenzione quando testate questo: quei due snippet di CSS sono banalmente piccoli, quindi non beneficiano della compressione GZIP – l’aggiunta dell’intestazione piccola di GZIP da sola perderà i guadagni realizzati. In realtà non avresti un file CSS così piccolo e ti preoccupi di comprimerlo.

minify + gzip comprime molto più di gzip

La risposta alla domanda originale è, sì, minify + gzip otterrà una quantità significativa di compressione in più rispetto a gzip. Questo è vero per qualsiasi esempio non banale (cioè qualsiasi codice JS o CSS utile che supera le poche centinaia di byte).

Per esempi di questo in effetti, prendi il codice sorgente di Jquery che è disponibile minisito e non compresso, comprimili entrambi con gzip e dai un’occhiata.

Vale la pena notare che Javascript beneficia molto più della minificazione rispetto ai CSS ottimizzati, ma c’è ancora un vantaggio.

Ragionamento:

La compressione GZIP è senza perdita di dati. Ciò significa che deve memorizzare tutto il testo, inclusi lo spazio bianco esatto, i commenti, i nomi di variabili lunghe e così via, in modo che possano essere riprodotti perfettamente in seguito. D’altra parte, la minificazione è una perdita. Se si minimizza il codice, si rimuovono molte di queste informazioni dal codice, lasciando meno che GZIP abbia bisogno di preservare.

  • Il minatore elimina gli spazi bianchi inutilmente, lasciando gli spazi solo dove necessario per ragioni sintattiche.
  • Minification rimuove i commenti.
  • La minificazione del codice può sostituire i nomi degli identificatori con nomi più brevi dove non ci sarebbero effetti collaterali.
  • La minificazione del codice può rendere banali ‘ottimizzazioni del compilatore’ al codice che sono possibili solo analizzando effettivamente il codice
  • La minificazione CSS può eliminare le regole ridondanti o combinare regole che hanno lo stesso selettore.

Hai ragione.

Non è lo stesso per minify di gzipping (sarebbero chiamati lo stesso se fosse così). Ad esempio, non è lo stesso per gzip questo:

 var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null; 

Di minify per finire con qualcosa di simile:

 var a = null; 

Naturalmente, nella maggior parte dei casi, direi l’approccio migliore per minimizzare FIRST e Gzip, piuttosto che minimizzare o gzip, anche se a seconda del codice, a volte solo minifying o gzipping ti daranno risultati migliori di entrambi.

C’è una soglia in cui la codifica gzip è vantaggiosa. La regola generale è: più grande è il file, migliore sarà la compressione e gzip vincerà a mani basse. Ovviamente puoi prima minificare poi gzip dopo.

Ma se stiamo parlando di gzip vs minify su un piccolo pezzo di testo non più lungo di 100 byte, un confronto “oggettivo” è inaffidabile, anche inutile – a meno che non usiamo un testo di riferimento per stabilire un metodo standard di benchmarking, come un tipo Lorem Ipsum ma scritto in Javascript o CSS.

Quindi lasciatemi proporre di confrontare le ultime versioni di jQuery e MooTools (le versioni non compresse) usando il mio codice Fat-Free Minify (PHP) (semplicemente eliminando spazi bianchi e commenti, senza accorciare le variabili, senza codifica BaseX)

Ecco i risultati di minify vs. gzip (a livello di compressione conservativa di 5) vs. minify + gzip:

 MooTools-Core ------------- Baseline 102,991 bytes Minified 79,414 (77.1% of original) Gzipped 27,406 (26.6%) Minified+Gzipped 22,446 (21.8%) jQuery ------ Baseline 170,095 Minified 99,735 (58.6% of original) Gzipped 46,501 (27.3%) Minified+Gzipped 27,938 (16.4%) 

Prima che qualcuno salti la pistola, questa non è una battaglia di librerie JS.

Come puoi vedere, minifying + gzip ti offre una migliore compressione su file di grandi dimensioni . Il codice minifying ha i suoi vantaggi, ma il fattore principale è la quantità di spazio e commenti presenti nel codice originale. In questo caso, jQuery ha di più quindi offre una migliore minificazione (molti più spazi bianchi nella documentazione inline). La forza di compressione di Gzip è in quanta ripetizione c’è nel contenuto. Quindi non si tratta di minimizzare contro gzip. Fanno le cose in modo diverso. E ottieni il meglio da entrambi i mondi usando entrambi.

Perché non usare entrambi?

È facile da testare: basta inserire il testo del tuo css in file di testo e comprimerlo con un archiver come gzip su linux.

Ho appena fatto questo, e succede che per il primo css, la dimensione è 184 byte e per il secondo 162 byte.

Quindi, hai ragione, lo spazio bianco conta anche per i file compressi con gzip, ma come si può vedere da questo piccolo test, per i file veramente piccoli, la dimensione del file compresso potrebbe essere maggiore della dimensione del file originale.

Questo è solo a causa delle ridotte dimensioni del tuo esempio, per i file più grandi, gzipping ti porterà file più piccoli.

Non ho visto nessuno menzionare Mangling, quindi sto pubblicando i miei risultati su questo.

Ecco alcune cifre che ho trovato usando UflifyJS per minification e Gzip. Ho avuto circa 20 file che ho concatenato insieme a circa 2,5 MB con commenti e tutti.

File Concat 2.5 MB

 uglify({ mangle: false }) 

Minificato senza maciullamento: 929kb

 uglify({ mangle: true }) 

Minorato e mutilato: 617kb

Ora, se prendo quei file e li gzip, avrò rispettivamente 239kb e 190kb.

C’è un metodo molto semplice per testare questo: creare un file composto solo da spazi bianchi e un altro file che sia veramente vuoto. Quindi prendi Gzip e confronta le loro dimensioni. Il file con lo spazio bianco in esso sarà ovviamente più grande.

Ovviamente la compressione lossy “umana” che preserva il layout o alcune altre cose importanti e rimuove qualsiasi junk non necessaria (spazi bianchi, commenti, elementi ridondanti ecc.) Sarà migliore di una compressione gZip senza perdita di dati.

Ad esempio, cose come marchi o nomi di funzioni molto probabilmente avranno una certa lunghezza per descrivere il significato. Sostituendo questo nome con un carattere lungo, si risparmia molto spazio e non è ansible con la compressione senza perdita di dati.

A proposito, per i CSS ci sono strumenti come il compressore CSS che faranno il lavoro che perderà per te.

Tuttavia, otterrete i migliori risultati combinando “ottimizzazione per perdita” e compressione senza perdita di dati.

ovviamente puoi testare – scrivere il tuo in un file e gzip con zlib . Puoi anche provare con il programma di utilità “gzip”.

torna alla tua domanda: non esiste una relazione definita tra la lunghezza della fonte e il risultato compresso. il punto chiave è l ‘”entropia” (quanto è diverso ogni elemento nella fonte).

quindi, dipende da come è la tua fonte. per esempio, molti spazi continui (ex,> 1000) possono essere compressi come le stesse dimensioni di pochi (ex, <10) spazi.

questo è il risultato quando gziping i due file

 bytes File 45 min.txt 73 min.gz 72 normal.txt 81 normal.gz 

Sei corretto, minify + gzip risulta in meno byte. Nessuna prova scientifica però.

Come mai non hai metodi di test?

Riduci il codice in un file e lascialo “non terminato” su un altro. Carica su un server web in grado di gzipare l’output (mod_deflate per Apache, ad esempio), installa l’estensione Firebug per firefox, svuota la cache e accedi a entrambi i file. La scheda “NET” di Firebug conterrà la quantità esatta di dati trasferiti, li confronterai e avrai una prova “empirica”.