Perché le persone riducono le risorse e non l’HTML?

Perché le persone suggeriscono di minimizzare le risorse web, come CSS e JavaScript, ma non suggeriscono mai che il markup sia minimizzato? CSS e JavaScript possono essere utilizzati su molte pagine diverse mentre il markup viene caricato ogni volta, rendendo molto più importante la minimizzazione del markup.

Un motivo probabile è che il markup in genere cambia MOLTO più spesso e dovrebbe essere minimizzato per ogni caricamento di pagina. Ad esempio, in una determinata pagina Overflow dello stack, sono presenti timestamp, nomi utente e conteggi delle rappresentazioni che potrebbero cambiare ad ogni caricamento della pagina, vale a dire che dovresti ridurre a ogni caricamento della pagina. Con i file “statici” come css e javascript, è ansible ridimensionare molto meno spesso, quindi nella mente di alcuni, vale la pena lavorare in anticipo.

Considera inoltre che tutti i principali web server e browser supportano gzip, che comprime comunque tutti i tuoi markup ( velocemente ) al volo. Poiché il minifying è più lento e molto meno efficace di gzipping, i webmaster potrebbero decidere che il minifying per ogni carico di pagina non vale il costo di elaborazione.

Le risposte qui scritte sono estremamente obsolete o, a volte, non hanno senso. Molte cose sono cambiate rispetto al vecchio 2009, quindi cercherò di rispondere correttamente.

Risposta breve: dovresti minimizzare l’HTML . Oggi è triviale e offre circa il 5% di aumento della velocità . Per una risposta più lunga leggi l’intera risposta

Ai vecchi tempi le persone stavano minettendo manualmente css / js (eseguendolo attraverso uno strumento specifico per ridimensionarlo). È stato piuttosto difficile automatizzare il processo e sicuramente richiesto alcune abilità. Sapendo che molti siti di alto livello anche in questo momento non stanno usando gzip (che è banale), è comprensibile che le persone fossero riluttanti a minimizzare l’html.

Allora perché la gente stava minificando js, ​​ma non html ? Quando si minimizza JS, si eseguono le seguenti operazioni:

  • rimuovere commenti
  • rimuovi spazi vuoti (tabulazioni, spazi, nuove righe)
  • cambia il nome lungo in corto ( var isUserLoggedIn in var a )

Il che ha dato molti miglioramenti anche ai vecchi tempi. Ma in html non eri in grado di cambiare i nomi lunghi in breve, inoltre non c’era quasi nulla da commentare durante quel periodo. Quindi l’unica cosa che è rimasta è quella di rimuovere spazi e ritorni a capo. Che dà solo una piccola quantità di miglioramento.

Un argomento errato scritto qui è che poiché il contenuto è servito con gzip, la minificazione non ha senso. Questo è totalmente sbagliato. Sì, è logico che gzip diminuisca il miglioramento della minificazione, ma perché dovresti gzipare commenti, spazi bianchi se puoi ritagliarli correttamente e gzip solo parte importante. È come se tu avessi una cartella da archiviare che ha qualche schifezza che non userai mai e tu decidi di comprimerla semplicemente, invece di pulirla e comprimerla.

Un altro argomento per cui è inutile fare minificazione è che è noioso. Potrebbe essere vero nel 2009, ma dopo questo tempo sono apparsi nuovi strumenti. Al momento non è necessario ridimensionare manualmente il markup. Con cose come Grunt è banale installare grunt-contrib-htmlmin e configurarlo per minimizzare il tuo html. Tutto ciò che serve è come 2 ore per imparare il grunt e per configurare tutto e poi tutto viene fatto automaticamente in meno di un secondo. Sembra che 1 secondo (che puoi persino automatizzare per non fare nulla con grunt-contrib-watch ) non sia poi così male per circa il 5% di miglioramento (anche con gzip).

Un altro argomento è che CSS e JS sono statici e HTML è generato dal server, quindi non è ansible pre-minificarlo. Ciò era vero anche nel 2009, ma attualmente sempre più siti sembrano un’app a pagina singola, in cui il server è scarso e il client sta eseguendo tutto il routing, i modelli e altre logiche. Quindi il server ti dà solo JSON e il client lo rende. Qui hai un sacco di HTML per la pagina e diversi modelli.

Quindi per finire i miei pensieri:

  • google sta minificando l’html.
  • pageSpeed chiede al tuo minify html
  • è banale da fare
  • dà ~ 5% di miglioramento
  • non è lo stesso di gzip

Considera questo:

HTML:

    Demo    

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Con questo file css:

 div[title="My non minifiable page"] p[class~="http://www.example.com/classs/class/lorem-ipsum"] { white-space:pre; } 

Detto questo, è effettivamente imansible per un minificatore HTML che può vedere solo il file HTML per trovare qualcosa che possa tranquillamente ridurre.

Suppongo sia difficile perché a volte cose come lo spazio bianco vengono usati per la formattazione, magari a seconda del doctype.

La velocità della pagina consiglia di ridurre il markup:

http://code.google.com/speed/page-speed/docs/payload.html#MinifyHTML

Markup tende ad essere generato dynamicmente in questi giorni, e anche quando è statico di solito c’è un sacco di pagine. JavaScript e CSS sono generalmente miniati in modo da un file per sito e quindi molto più facili da ridurre manualmente (o da script).