2009-04-16 13 views
12

Sono un fan delle valide pagine Web e passano sempre del tempo passando nuovi siti tramite lo W3C validator.Le pagine Web valide si caricano più velocemente?

Quando si cerca di fare un caso per il motivo per cui le aziende dovrebbero convalidare le pagine web ho subito pensato di accessibilità e il a prova di futuro del sito web su dispositivi più primitivi come i telefoni, frigoriferi, orologi, il di prossima big-thing ecc.

Tuttavia, mi sono chiesto se si verifica un sovraccarico computazionale nel rendering delle pagine Web che non vengono convalidate?

Sono state effettuate ricerche in questo settore? e alcuni browser gestiscono contenuti non validi meglio di altri?

risposta

12

È probabile che una pagina non valida impiegherà più tempo per il rendering perché il browser dovrà implementare un ripristino dei guasti (lavoro deduttivo per trovare dove è il prossimo contenuto valido e in che modo il browser può continuare a renderlo) e questo può introdurre un spese generali.

La differenza effettiva può essere detta solo dopo accurate misurazioni e (se possibile) analisi del codice sorgente del browser.

0

Non credo. Penso che sia lo stesso, forse anche di più per pagine valide (cose come & in URL). Specialmente dal alcuni browser (ahem, IE) sono praticamente progettati per pagine non valide. Per non dire che mi piace l'HTML non valido, comunque.

+6

Ho sentito numeri come il 70% del codice di rendering in un browser, è lì per capire che cosa intendevi davvero fare quando gli dai un po 'di merda. –

+0

"Crap" può riferirsi solo a complesse combinazioni di elementi che sono difficili da rappresentare correttamente, non codice non valido. –

4

Sospetto che il costo di qualsiasi ripristino di errore o altra gestione di contenuto non valido sarà reso trascurabile solo dalle latenze di rete e altri costi.

+2

Punto valido, ma non sottovalutare le dimensioni e la complessità delle pagine: l'analisi e il rendering delle stesse può richiedere molto tempo. – sharptooth

1

Mi sono quindi chiesto se è necessario un sovraccarico computazionale per il rendering delle pagine Web che non vengono convalidate?

Certo, ma è praticamente minuscolo. La velocità di analisi in generale non avrà un impatto tangibile, rispetto ai ritardi molto più grandi causati dal tempo di download della rete.

Dove può fare la differenza per i tempi di caricamento è quando si chiude un commento in modo errato. Le correzioni per i problemi relativi ai commenti possono essere ritardate fino alla fine della pagina, quindi il rendering progressivo non si verificherà e non verrà eseguito il rendering fino a quando non verrà scaricata l'intera pagina.

+0

È un dato di fatto che la velocità di rendering non è importante? So che Google Chrome è veloce come un fulmine, ma potrebbe essere più legato all'enorme quantità di JavaScript in questi giorni? –

+1

La velocità di rendering può essere importante. La velocità di scripting è importante. La velocità di analisi, che si verifica una volta per pagina, è improbabile che sia molto evidente tranne che in file patologicamente grandi. – bobince

0

Sto solo speculando qui, perché non ho riferimenti o dati rigidi per eseguire il backup, ma penso che la modalità di rendering scelta dal browser possa avere un certo impatto. La maggior parte dei browser ha due o tre modalità di rottura, una per le pagine standard (ovvero di solito attivata quando si fornisce al browser un documento html valido, ma non sempre) e la modalità quirks, che cerca semplicemente di ottenere il meglio da qualsiasi ci passi. Posso immaginare che l'esecuzione della modalità standard degli standard sia molto meglio di quella della modalità quirk, ma ancora una volta: solo speculando qui. Se qualcuno può sostenere con prove o un buon riferimento, sentiti libero di commentare o pubblicare una risposta migliore!

6

Penso che il tuo argomento più forte sarà in manutenzione. Ho progettato l'intranet per l'ultima grande azienda per cui ho lavorato. Ho creato modelli di pagina con markup valido e ho utilizzato commenti condizionali per i fogli di stile di destinazione per diverse versioni di IE. Il sito è stato lanciato 2 anni fa; sembra lo stesso in Firefox 2 & 3, Safari 2 & 3 e IE 6, 7, & 8!Non sono necessarie modifiche al markup o allo stile. Ciò significa che quando l'organizzazione si aggiorna infine a IE 7, il team degli sviluppatori web non dovrà fare nulla. Grande vittoria in costi di manutenzione ridotti.

Problemi correlati