2010-07-21 12 views
24

Ci sono dei vantaggi nell'omettere il corpo di chiusura e i tag html?I vantaggi dell'omissione dei tag body e html di chiusura?

Perché la home page di google.com manca del corpo di chiusura e dei tag html?

  • modifica - per quanto riguarda la larghezza di banda , è una quantità estremamente piccola, davvero. Dì 10 milioni di accessi @ circa 10 byte salvati ~ 100 mb solo ... Ci sono motivi diversi dalla larghezza di banda?

  • modificare 2 - e no, google (yahoo, Microsoft e altri) sono non w3-validatore compatibile ... quando si tratta di larghezza di banda di risparmio in massa vs w3 rispetto, credo che queste ultime di buono per il sacrificio?

+1

"è davvero una piccola quantità" - giusto, ma se non ci sono svantaggi nel farlo, non hai bisogno di altri motivi per farlo. Prendi tutte le piccole cose simili che Google fa, e alla loro portata, significa che possono prendere i risparmi della larghezza di banda e mettere i soldi verso cose che avvantaggiano il loro business. –

+2

"quando si risparmia in termini di larghezza di banda rispetto alla conformità con w3, immagino che quest'ultimo sia buono per il sacrificio?", Dipende. Ogni decisione è un compromesso. Stanno sacrificando la validità, pensiamo, la larghezza di banda e le prestazioni. Nella loro posizione, probabilmente ne vale la pena, in quanto larghezza di banda = denaro e prestazioni = popolarità (credo che Google abbia fatto ricerche che dimostrano che rendere una pagina più lenta per frazioni di secondo si traduce in una percentuale di persone che non fanno la ricerca che stavano per fare) . Ma per il tipo di lavoro sul Web che faccio, la validità è più importante perché si traduce in un numero inferiore di bug e più facili da individuare. –

risposta

10

Pensa a quante volte quella pagina viene servita ogni giorno. Anche piccole riduzioni di dimensioni possono essere significative a quel volume di traffico.

(Anche se io lavoro per Google, si prega di non trattare questo come un "risposta ufficiale da parte di Google." - si tratta di una supposizione, ma un educato)

4

Oltre ad un aumento di larghezza di banda, là isn' t.

Solo perché lo fanno non dovresti.

6

Stai pensando a ciò come una cosa indipendente. Se hanno fatto diverse cose che risparmiano la larghezza di banda, allora tutto si aggiunge. Ognuno potrebbe non essere significativo per conto proprio, ma se hanno 5 o 10 ottimizzazioni allora è significativo in totale.

Inoltre, questi dieci byte possono ridurre le dimensioni dei dati in modo sufficiente a farci prendere un pacchetto TCP/IP in meno, che avrà un risparmio significativamente più elevato riducendo semplicemente la dimensione di uno.

3

In aggiunta alla risposta di Jon Skeet, questo page mostra che ci sono 3 miliardi di ricerche su Google al giorno. Non so quanto sia accurato, ma direi che è nel parco giochi.

</body></html> è 14 caratteri e al 3 miliardi di ricerche al giorno, che ammonta a circa 39.12 GB dei dati per compressioni ignorando giorno, o intorno 26 GB se prendiamo in considerazione gzipping.

Tuttavia, Google potrebbe effettivamente inviare i tag di chiusura per body e html per i browser più vecchi esaminando i relativi programmi utente. Non posso confermarlo o negarlo, ma guardando i browser moderni - Safari, Firefox e Chrome mostrano che mancano tutti i tag di chiusura.

Quindi se pensi che funzioni per te, allora vai a prenderlo :). Non c'è nulla di male nell'implementare questo, che potrebbe essere o meno una micro-ottimizzazione per te, a seconda della scala su cui stai operando.

+0

Anche i browser più vecchi penso che accetteranno felicemente quei tag mancanti, quindi dubito che si siano presi la briga di annusare su questo particolare problema. – Chris

+0

" è di 14 caratteri" - sebbene stiano gzipando anche la pagina (presumo), quindi i caratteri di origine non vengono mappati direttamente ai byte nel file inviato. Scommetto che non salverà quanto hai stimato quando è stato preso in considerazione il gzipping. –

+0

@Paul - sì, ho accennato "ignorando le compressioni" nella mia risposta. Per me, la dimensione del byte non compresso è '8113'. Il contenuto compresso con gzip è '5585' byte che, per mantenere le cose semplici, se mappato fornisce direttamente una riduzione di circa un terzo. Ciò si tradurrebbe in '26 GB', invece di' 39'. Sì, hai ragione, è un enorme calo dopo aver incluso la compressione, ma "26 GB" non è di per sé un numero insignificante. – Anurag

6

Penso che JB sia sulla strada giusta. La loro home page è di circa 8750 byte (per me), il che significa che se possono ottenere 1458 byte per segmento di tcp, saranno sei pacchetti. Il punto non è tanto per renderlo 8750 byte piuttosto che 8760 ma per renderlo sei pacchetti anziché sette.

Ciò renderebbe una domanda di intervista di Google carina.:-)

Perché il numero di pacchetti è importante? Perché per le moderne connessioni Internet, è la latenza che conta, non i viaggi di andata e ritorno. Un pacchetto completo è appena più lento di un pacchetto da 1 byte. Il valore è particolarmente importante all'inizio di una connessione quando lo TCP windows si sta ancora aprendo.

Inoltre, maggiore è il numero di pacchetti, maggiore è la probabilità che uno di essi vada perso, causando forse un ritardo molto lungo. La possibilità non è molto alta, ma se sei già così teso, vale la pena.

Quindi dovresti farlo? In generale, direi di no, a meno che tu non sia sicuro che stai già inviando solo una manciata di pacchetti per la pagina in questione. (Dovresti misurarlo da una posizione realistica del client.) Sapere che la pagina è valida vale la pena.

+2

Quanto è cambiato in 5 anni! La pagina ora ha i tag '', ma è (per me su Chrome) 90% comprendente Javascript. – poolie

0

According to W3C, corpo e tag HTML sono opzionali e possono essere omessi

tag di chiusura Un html di elemento può essere omesso se l'elemento HTML non è immediatamente seguito da un commento.

A corpo il tag di chiusura dell'elemento può essere omesso se l'elemento del corpo non è immediatamente seguito da un commento.

Se la raccomandazione del W3C dice che ora è ok, allora dovrebbe essere totalmente valida. Quindi non c'è motivo per non farlo, a meno che non ti piaccia non i tag chiusi

+0

Questo in realtà non risponde alla domanda. La domanda riguarda i vantaggi e non l'hai affatto affrontata. – ItamarG3

+0

@ ItamarG3 Una delle domande è fondamentalmente "vale la validità del sacrificio per un paio di byte?". Se la raccomandazione del W3C dice che ora è ok, allora dovrebbe essere totalmente valida. Quindi non c'è motivo per non farlo, a meno che non ti piaccia non i tag chiusi –

Problemi correlati