Sovraccarico di indentazione degli spazi bianchi HTML

Question

Ho iniziato a chiedermi qual è l'impatto complessivo dell'utilizzo degli spazi bianchi per indentare i documenti html.

Perché non utilizzare semplicemente le schede per il rientro? Non sarebbe più economico: 1 carattere (\ t) rispetto all'esempio 4 caratteri (spazi)?

Ho fatto pochi esperimenti convertendo una pagina asp.net per utilizzare le schede e confrontate le dimensioni dei markup renderizzati. Sostituendo solo uno spazio bianco di una vista parziale, una pagina di dimensioni di 22kb è stata ridotta a 19,4kb -> questa è una riduzione del 12%. Cambiando tutti i rientri, la pagina ha finito per allocare 16,7kb - riduzione del 24%! (usato gli strumenti di sviluppo di Chrome e Fiddler per la verifica)

Il mio suono di ragionamento? Le schede dovrebbero essere utilizzate come primarie per il rientro dell'HTML? C'è qualche ragione per usare gli spazi (come la compatibilità con i browser esotici)?

ps. Stackoverflow sembra utilizzare anche gli spazi. La conversione della pagina principale SO per utilizzare le schede ha dato una riduzione del 9%. Questa osservazione è valida? Se è così, perché non hanno usato le schede?

Answer 1

StackOverflow utilizza HTTP Compression - quando questo è attivo, le differenze tra l'uso di spazi e schede diminuiscono - molto.

È necessario run your tests contro le versioni compresse per risultati affidabili.

Si ha comunque un punto per i casi in cui un browser non supporta gli schemi di compressione supportati dal server.

Answer 2

Per prima cosa: html non ha una regola per fare indentazione. È fatto dai programmatori per la leggibilità del codice e la struttura del programma. Più di sempre Possiamo ridurre le dimensioni prese da rientri e spazi bianchi mediante compressione.

Minimizza/compatta/comprime HTML: la compattazione del codice HTML consente di risparmiare molti byte di dati e velocizza il download, l'analisi e il tempo di esecuzione.

StackOverflow utilizza la compressione HTTP

Minimizzando HTML ha gli stessi vantaggi come quelli per minifying CSS e JS: ridurre la latenza di rete, migliorando la compressione, e più veloce del browser di caricamento e di esecuzione. Inoltre, HTML spesso contiene codice JS in linea (nei tag) e CSS in linea (nei tag), quindi è utile anche ridimensionarli.

Nota: Questa regola è sperimentale ed è attualmente focalizzata sulla riduzione delle dimensioni piuttosto che sulla rigidità del linguaggio HTML. Le versioni future della regola terranno conto anche della correttezza. Per i dettagli sul comportamento corrente, vedere il wiki della velocità della pagina.

Suggerimento: Quando si esegue Page Speed ​​nei confronti di un file HTML pagina referencing, viene eseguito automaticamente il compattatore Page Speed ​​HTML (che a sua volta applica JSMin e cssmin.js a qualsiasi linea Javascript e CSS) sui file e salva l'output minificato in una directory configurabile.

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

Answer 3

Perché non è sufficiente utilizzare schede per il rientro? Non sarebbe più economico: 1 carattere (\ t) rispetto all'esempio 4 caratteri (spazi)?

Se siete preoccupati per dimensioni HTML scaricato, non sarà chiasso per le schede-vs-spazi - vi compress your HTML as it goes over the wire and minify your markup, CSS, and Javascript, che forniscono risparmi reali e non interferiscono con le proprie linee guida di codifica.