Pagina 1 di 6 1 2 3 ... ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 57
  1. #1
    Utente di HTML.it
    Registrato dal
    Feb 2009
    Messaggi
    20

    HTML <div>: più veloce del table. Perché?

    Salve.

    Stavo pensando ad una cosa piùttosto "filosofica" della resa e del caricamento di un layout HTML da parte di un browser.
    Ho letto che costruire i layout con le tabelle (<table>) è sconsigliato, e non solo per l'uso improprio, a livello logico, di un tag che dovrebbe descrivere la struttura e invece viene utilizzato per specificare l'aspetto del sito, venendo meno allo scopo dell'HTML, ma anche perché le tabelle, specie quando contengono molti elementi e soprattutto altre tabelle annidate, sono molto più lente da caricare, costruire, piazzare e rendere nel viewport del browser rispetto ad un sistema basato su div annidati.

    Mi domandavo, perché i div annidati si comportano "meglio" delle tabelle annidate, e sono più veloci da caricare e rendere? Alla fine il browser deve comunque calcolare lo spazio dei contenuti... come fa per le tabelle.

    Io sono sostenitore della separazione delle funzioni, quindi sostengo e uso i CSS in file separati e JS non invasivi, ma mi domandavo come mai per i browser fosse più facile rendere div rispetto a table.

    Grazie, e scusate per l'aspetto "teorico", ma secondo me interessante, della domanda.

    Nillus

  2. #2
    Molto semplicemente, non e' vero. Il motivo per cui molti evitano di usare le tabelle e' solo per evitare di utilizzare strumenti in modo "improprio", anche se spesso si sconfina nella guerra di religione e alcune soluzioni in versione "purista" richiedono vari hack per dare lo stesso risultato che con una tabella si ottiene molto piu' semplicemente, soprattutto per quanto riguarda la compatibilita' tra i browser. Ma differenze di velocita' direi proprio di no.

  3. #3
    Frontend samurai L'avatar di fcaldera
    Registrato dal
    Feb 2003
    Messaggi
    12,924
    La differenza di velocità c'è : il rendering di una tabella è molto più lento di un div per due motivi essenzialmente

    1) da un punto di vista della marcatura in sé è chiaro che per il browser fare il solo parsing di <div></div> è evidentemente più semplice rispetto a <table><thead><tr><th></th></tr><tbody><tr><td></td></tbody></table>. Parsing più veloce significa ridurre il tempo d'attesa del rendering.

    2) usare le tabelle al posto dei div significa aumentare il codice di almeno il 50% rispetto ad un codice table-less.
    Pagine più pesanti comportano rendering più lunghi. Considera che il browser in certe circostanze può anche decidere di iniziare a mostrare i contenuti solo una volta aver finito il parsing della tabella se questa è particolarmente complessa (sarebbe infatti troppo dispendioso e potenzialmente inutile farlo durante il calcolo delle dimensioni delle varie celle) Con i div questo non succede.
    Vuoi aiutare la riforestazione responsabile?

    Iscriviti a Ecologi e inizia a rimuovere la tua impronta ecologica (30 alberi extra usando il referral)

  4. #4
    Utente di HTML.it L'avatar di Marcolino's
    Registrato dal
    May 2003
    residenza
    Udine
    Messaggi
    3,606
    Originariamente inviato da k.b
    Molto semplicemente, non e' vero. Il motivo per cui molti evitano di usare le tabelle e' solo per evitare di utilizzare strumenti in modo "improprio", anche se spesso si sconfina nella guerra di religione e alcune soluzioni in versione "purista" richiedono vari hack per dare lo stesso risultato che con una tabella si ottiene molto piu' semplicemente, soprattutto per quanto riguarda la compatibilita' tra i browser. Ma differenze di velocita' direi proprio di no.
    E invece sbagli il contenuto delle tabelle viene mostrato solo dopo che il codice della tabella è stato scaricato e renderizzato dal browser in uso.
    Per tabelle molto complesse e nidificate questo si può tradurre in tempi di attesa lunghi, sopratutto se non si hanno connessioni veloci il che in Italia si traduce nel 50% di chi ha internet.
    Tieni presente che il browser comincia a renderizzare il codice appena ha un elemento finito e non quando ha finito di scaricare l'intero documento (ecco perché bisogna sempre chiudere i tag); per esempio in un classico layout a div in cui un contenitore contiene altri div, appena si rende disponibile il div di chiusura mostrerà quello che c'è dentro, poi un altro e poi un altro fino a che l'ultimo div contenitore si chiude, a quel punto si potrebbe vedere lo spostamento che spesso si avverte in certi siti per il quale tutto si posta nel punto dove deve stare Semplicemente perché magari si è chiuso l'ultimo div, spesso chiamato container perché raccoglie il tutto e porta le indicazioni di stile per mettere tutto centrato (o su un lato o dove si vuole).
    Con le tabelle è la stessa cosa, con l'unico problema che non viene rendirizzata ogni singola cella appena scaricata, ma si aspetta la chiusura del tag table alla fine e poi si reindirizza il tutto.
    Molto più lento nel modo di rappresentare specialmente se dentro il codice ci sono più tabelle annidate.
    Per quanto riguarda l'uso improprio di tabelle, il buon Diodati ammise che si possono utilizzare per un layout che include una sola tabella non annidata a patto che si utilizzino tutti i mezzi a disposizione per facilitarne l'accessibilità.
    Uno dei problemi dell'uso delle tabelle per realizzare siti è il rumore di fondo che generano quando si "legge" la pagina con un lettore di schermo.
    Gli elementi grafici inseriti nelle celle per dare corpo al disegno confondono chi ascolta con una serie di dati superflui e inutili, usare i div per lo stesso scopo con gli elementi grafici inseriti via CSS vengono ignorati dai lettori di schermo se non contengono dati significativi.
    Usare sempre l'attributo summary nell'elemento table per raccontare ai lettori di schermo cosa troveranno all'interno della tabella.
    Usare bene i vari componenti della tabella come caption, thead, tfoot, tbody come riportato nel manuale: http://www.diodati.org/w3c/html401/s...tml#edef-TFOOT
    Insomma ne vale la pena? non è un problema di "talebanesimo" ma di rendere il sito accessibile a tutti, browser che non leggono i div non ne esistono più, già IE4 e Netscape 4 li leggevano, il concetto Anybrowser è oramai superato dalla standirdazione quindi non c'è motivo di usare le tabelle per reggere il layout.
    Vedi CSS Zen Garden

  5. #5
    Utente di HTML.it L'avatar di Marcolino's
    Registrato dal
    May 2003
    residenza
    Udine
    Messaggi
    3,606
    Originariamente inviato da fcaldera
    La differenza di velocità c'è : il rendering di una tabella è molto più lento di un div per due motivi essenzialmente

    1) da un punto di vista della marcatura in sé è chiaro che per il browser fare il solo parsing di <div></div> è evidentemente più semplice rispetto a <table><thead><tr><th></th></tr><tbody><tr><td></td></tbody></table>. Parsing più veloce significa ridurre il tempo d'attesa del rendering.

    2) usare le tabelle al posto dei div significa aumentare il codice di almeno il 50% rispetto ad un codice table-less.
    Pagine più pesanti comportano rendering più lunghi. Considera che il browser in certe circostanze può anche decidere di iniziare a mostrare i contenuti solo una volta aver finito il parsing della tabella se questa è particolarmente complessa (sarebbe infatti troppo dispendioso e potenzialmente inutile farlo durante il calcolo delle dimensioni delle varie celle) Con i div questo non succede.
    Ecco, vivala sintetizzazione

  6. #6
    Frontend samurai L'avatar di fcaldera
    Registrato dal
    Feb 2003
    Messaggi
    12,924
    un paio di suggerimenti per velocizzare il rendering delle tabelle (da usare solo quando parliamo di dati tabellari ovviamente)

    1) esiste il tag <col /> che permette di attribuire alcune proprietà di stile alle colonne di una tabella
    questo dovrebbe evitare se non altro l'uso di classi sulle <td> solo per definire la loro larghezza o magari l'allineamento del testo

    2) esiste la proprietà css table-layout: fixed. In pratica serve per specificare che la tabella è "regolare" (ad esempio senza colspan o rowspan) e dà indicazione al browser che dovrebbe usare le dimensioni calcolate nella prima riga della tabella per disegnare (più velocemente) le righe successive.
    Vuoi aiutare la riforestazione responsabile?

    Iscriviti a Ecologi e inizia a rimuovere la tua impronta ecologica (30 alberi extra usando il referral)

  7. #7
    Originariamente inviato da fcaldera
    La differenza di velocità c'è : il rendering di una tabella è molto più lento di un div per due motivi essenzialmente

    1) da un punto di vista della marcatura in sé è chiaro che per il browser fare il solo parsing di <div></div> è evidentemente più semplice rispetto a <table><thead><tr><th></th></tr><tbody><tr><td></td></tbody></table>. Parsing più veloce significa ridurre il tempo d'attesa del rendering.

    2) usare le tabelle al posto dei div significa aumentare il codice di almeno il 50% rispetto ad un codice table-less.
    Pagine più pesanti comportano rendering più lunghi. Considera che il browser in certe circostanze può anche decidere di iniziare a mostrare i contenuti solo una volta aver finito il parsing della tabella se questa è particolarmente complessa (sarebbe infatti troppo dispendioso e potenzialmente inutile farlo durante il calcolo delle dimensioni delle varie celle) Con i div questo non succede.
    Classici esempi fuorvianti, da un lato UN SINGOLO DIV contro un ipotetico markup di 10 tabelle annidate (che nessuno fa). Grazie che in questo caso uno e' molto piu' veloce, ma avete presente quanti tag <div> ci sono in una pagina complessa nel mondo reale? Hai presente quanto markup e quante dichiarazioni di stile ci vogliono per fare il classico layout "100% width fluido con colonne alte uguali"?

    Hai qualche benchmark che mostri quanto i due tipi di layout differiscano come velocita' nella pratica? Perche' io faccio veramente fatica a credere che qualche centinaio di byte e un pizzico di millisecondi (quand'anche fosse vero che c'e' una differenza sensibile nelle du cose) si possano notare nell'uso comune.

  8. #8
    Originariamente inviato da Marcolino's
    E invece sbagli il contenuto delle tabelle viene mostrato solo dopo che il codice della tabella è stato scaricato e renderizzato dal browser in uso.
    Per tabelle molto complesse e nidificate questo si può tradurre in tempi di attesa lunghi, sopratutto se non si hanno connessioni veloci il che in Italia si traduce nel 50% di chi ha internet.
    Tieni presente che il browser comincia a renderizzare il codice appena ha un elemento finito e non quando ha finito di scaricare l'intero documento (ecco perché bisogna sempre chiudere i tag); per esempio in un classico layout a div in cui un contenitore contiene altri div, appena si rende disponibile il div di chiusura mostrerà quello che c'è dentro, poi un altro e poi un altro fino a che l'ultimo div contenitore si chiude, a quel punto si potrebbe vedere lo spostamento che spesso si avverte in certi siti per il quale tutto si posta nel punto dove deve stare Semplicemente perché magari si è chiuso l'ultimo div, spesso chiamato container perché raccoglie il tutto e porta le indicazioni di stile per mettere tutto centrato (o su un lato o dove si vuole).
    Con le tabelle è la stessa cosa, con l'unico problema che non viene rendirizzata ogni singola cella appena scaricata, ma si aspetta la chiusura del tag table alla fine e poi si reindirizza il tutto.
    Molto più lento nel modo di rappresentare specialmente se dentro il codice ci sono più tabelle annidate.
    Per quanto riguarda l'uso improprio di tabelle, il buon Diodati ammise che si possono utilizzare per un layout che include una sola tabella non annidata a patto che si utilizzino tutti i mezzi a disposizione per facilitarne l'accessibilità.
    Uno dei problemi dell'uso delle tabelle per realizzare siti è il rumore di fondo che generano quando si "legge" la pagina con un lettore di schermo.
    Gli elementi grafici inseriti nelle celle per dare corpo al disegno confondono chi ascolta con una serie di dati superflui e inutili, usare i div per lo stesso scopo con gli elementi grafici inseriti via CSS vengono ignorati dai lettori di schermo se non contengono dati significativi.
    Usare sempre l'attributo summary nell'elemento table per raccontare ai lettori di schermo cosa troveranno all'interno della tabella.
    Usare bene i vari componenti della tabella come caption, thead, tfoot, tbody come riportato nel manuale: http://www.diodati.org/w3c/html401/s...tml#edef-TFOOT
    Insomma ne vale la pena? non è un problema di "talebanesimo" ma di rendere il sito accessibile a tutti, browser che non leggono i div non ne esistono più, già IE4 e Netscape 4 li leggevano, il concetto Anybrowser è oramai superato dalla standirdazione quindi non c'è motivo di usare le tabelle per reggere il layout.
    Vedi CSS Zen Garden
    Cerchiamo di non fare come al solito e dare per scontato che ci siano solo due categorie:
    • i layout con tabelle fatti male, con markup deprecato, con immagini ovunque, con tabelle annidate, tag <font> e nessun uso dei fogli di stile
    • i layout table-less, perfettamente semantici, validati strict, con CSS con selettori efficienti, perfettamente accessibili e via dicendo

    perche' e' quello che si legge piu' spesso quando si parla di queste cose. In realta' non esiste CSS vs tables, perche' usare una tabella per realizzare un layout a griglia non significa non usare i fogli di stile, significa magari non voler impazzire con dei trucchi (es. faux columns) per avere la compatibilita' su tutti i browser (che con le tabelle e' certa). Per contro non basta non usare tabelle per fare pagine pulite, valide ed accessibili.

    Non e' sbagliato usare le tabelle per i layout, e' sbagliato che non ci sia ancora un'alternativa altrettanto semplice e cross-browser per realizzare alcuni particolari tipi di layout (o anche semplici pezzetti, come allineare label e input tag senza usare width fisse). L'uso indiscriminato di tabelle e' senz'altro da condannare, ma voler negare che in alcuni casi una tabella sia tutt'ora la soluzione purtroppo piu' efficiente (sostanzialmente per colpa dei browser) tende un po' al fanatismo

  9. #9
    Frontend samurai L'avatar di fcaldera
    Registrato dal
    Feb 2003
    Messaggi
    12,924
    Originariamente inviato da k.b
    Classici esempi fuorvianti, da un lato UN SINGOLO DIV contro un ipotetico markup di 10 tabelle annidate (che nessuno fa). Grazie che in questo caso uno e' molto piu' veloce, ma avete presente quanti tag <div> ci sono in una pagina complessa nel mondo reale? Hai presente quanto markup e quante dichiarazioni di stile ci vogliono per fare il classico layout "100% width fluido con colonne alte uguali"?
    Fuorviante? Scusa, ma dove vedi tabelle annidate nell'esempio? Quello è un div contro una tabella di UNA cella con marcatura quasi completa (non ho messo il tfoot)

    Circa il mondo reale, ti assicuro che talvolta mi capita di dover mettere mano a pagine reali (altrui) con 8/10/15 tabelle annidate, pagine che inizialmente pesano 100/120kb che poi tornano a 30/40Kb dopo un lavoro estenuante di pulizia.

    Secondo te 80kb di meno non fanno differenza nella velocità di rendering?

    Originariamente inviato da k.b
    Hai qualche benchmark che mostri quanto i due tipi di layout differiscano come velocita' nella pratica? Perche' io faccio veramente fatica a credere che qualche centinaio di byte e un pizzico di millisecondi (quand'anche fosse vero che c'e' una differenza sensibile nelle du cose) si possano notare nell'uso comune.
    Se prendiamo come esempio un div contro una tabella probabilmente non c'è alcuna differenza di velocità. Se ritorniamo all'esempio che ti ho fatto prima la differenza si percepisce eccome, altro che centinaio di bytes
    Vuoi aiutare la riforestazione responsabile?

    Iscriviti a Ecologi e inizia a rimuovere la tua impronta ecologica (30 alberi extra usando il referral)

  10. #10
    Amministratore L'avatar di Vincent.Zeno
    Registrato dal
    May 2003
    residenza
    Emilia-Romagna (tortellini und cappelletti land!)
    Messaggi
    20,660
    Originariamente inviato da fcaldera
    Circa il mondo reale, ti assicuro che talvolta mi capita di dover mettere mano a pagine reali (altrui) con 8/10/15 tabelle annidate, pagine che inizialmente pesano 100/120kb che poi tornano a 30/40Kb dopo un lavoro estenuante di pulizia.

    + decine di macatori per la formattazione (ndM)


    il "bello" è che il cliente nemmeno se ne accorge

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.