Esiste un limite al numero di elementi html, che il browser può visualizzare senza problemi?

Question

Fondamentalmente ho una tabella enorme, che diventa ancora più grande quando l'utente scorre verso il basso (pre-caricando automaticamente le righe successive). Ad un certo punto il browser diventa lento, inizia a bloccarsi per un momento mentre faccio clic o cerco di scorrere e più lento diventa, più file ottiene. Mi chiedo se c'è un limite al numero di elementi che la pagina può contenere? O forse è solo il mio javascript che perde da qualche parte (anche se ho un solo gestore di eventi, attaccato al tbody del tavolo - e uno script che analizza gli eventi ribolliti di mousedown).

Aggiornamento: Il ritardo diventa evidente dopo migliaia di righe caricate. La velocità di scorrimento è abbastanza sopportabile, ma ad esempio l'evidenziazione della riga cliccata (con l'aiuto di un singolo gestore di eventi su tbody) è dolorosa (occorrono almeno 2-3 secondi e il ritardo aumenta con il numero di righe). Osservo il ritardo su tutti i browser. Non sono solo io, ma quasi tutti quelli che visitano la pagina, quindi credo che in qualche modo colpisca ogni piattaforma.

Aggiornamento: mi si avvicinò con semplice esempio qui: http://client.infinity-8.me/table.php?num=1000 (si può passare qualunque sia il numero che si desidera num), in fondo si rende un tavolo con num righe e ha un unico gestore di eventi collegato a un tabella genitore. Dovrei concludere da questo, che in realtà non vi è alcun calo sensibile delle prestazioni, causato dal numero di elementi figli. Quindi è probabilmente una perdita da qualche altra parte :(

Answer 1

Non penso che ci sia un limite definito dallo standard. Potrebbe esserci un limite codificato in ogni implementazione del browser, anche se immagino che questo limite sia probabilmente di miliardi di elementi. Un altro limite è la quantità di memoria indirizzabile.

Per risolvere il problema: oltre a caricare automaticamente gli elementi mentre si scorre verso il basso, è possibile scaricare automaticamente quelli che sono stati spostati verso l'alto dallo schermo. Quindi il tuo programma rimarrà veloce anche dopo averlo fatto scorrere molto.

Si consiglia inoltre di prendere in considerazione un'interfaccia alternativa come il paging.

Answer 2

Io non credo che ci sia un limite. Tuttavia, il più a lungo di un file HTML è, più risorse, il computer avrà bisogno. Ma la tabella deve essere molto grande then ...

Answer 3

Il limite è realmente determinato dall'agente utente e dal computer client utilizzati. L'HTML, allo stesso modo di XML, è un formato ad albero di dati. Quindi più elementi, più l'albero passa il browser del client deve cercare per eseguire il rendering della pagina

Ho riscontrato problemi con l'aggiunta di più di 100 tabelle a un div (come soluzione alternativa a IE6 che non è in grado di creare dinamicamente gli elementi tabella)

Answer 4

Se JS è presente su ogni riga della tabella, i vecchi computer non lo gestiranno. Per l'HTML stesso non dovresti preoccuparti troppo.

Dovresti preoccuparti del fatto che all'essere umano normale non piacciono i tavoli di grandi dimensioni, questo è l'impaginazione. Separalo usando il cercapersone per una migliore usabilità e altre preoccupazioni.

Pensa al libro che non ha pagine ma una pagina grande, ti piacerebbe leggerlo? Anche se i tuoi occhi (PC nel nostro caso) possono gestirlo.

Answer 5

Che browser stai utilizzando? Alcuni browser sono in grado di gestire le cose meglio di altri: ad esempio, se utilizzi IE, non sarei sorpreso se fosse lento - non gestisce gli eventi javascript così come i browser basati su webkit.

L'altra cosa è ovviamente il tuo computer (RAM e CPU). Ma per essere onesti, la maggior parte dei computer non dovrebbe avere un problema con quello a meno che non stiamo parlando di 10000+ righe ... e anche allora ...

Puoi pubblicare un po 'di codice?

Answer 6

Dato che esiste una moltitudine di browser e motori di rendering e tutti hanno caratteristiche di prestazioni diverse e anche dato che quei motori vengono costantemente migliorati per quanto riguarda le prestazioni e l'hardware del computer diventa sempre più veloce: No non c'è un limite superiore fisso cosa può gestire un browser. Tuttavia, esistono limiti massimi attuali su hardware specifico per versioni specifiche dei browser.

Se non si definisce più l'hardware e il browser che sono difficili da aiutare. Inoltre, nessuno può suggerire in merito alle possibili prestazioni del tuo Javascript se non inserisci il codice. Anche se si tratta di un solo gestore di eventi, se esegue un loop infinito o se è chiamato per ogni elemento, può rallentare considerevolmente il processo di rendering.

Answer 7

Nevermind RAM o utilizzo della CPU, qual è la dimensione effettiva del file dopo il suo precarico?

Se la tua tabella è davvero così grande, potresti costringere i tuoi utenti a scaricare megabyte di dati - Ho scoperto che alcune macchine tendono a bloccarsi dopo 2-4 MB di dati.

Answer 8

Un'altra cosa da guardare è il dimensionamento della tabella. Se hai il tuo tavolo in stile con table-width:auto; il browser deve misurare ogni singolo elemento della tabella per ridimensionarlo. Questo può diventare follemente lento.

Scegliere invece una larghezza fissa o almeno lo stile della tabella utilizzando table-width:fixed.

Answer 9

Depends. Ad esempio, IE non inizierà il rendering di una tabella fino a quando non verrà caricato tutto il contenuto. Quindi, se avessi una tabella di 5.000 righe, è necessario caricare tutte le 5.000 righe di dati prima di renderle dove, mentre gli altri browser iniziano il rendering una volta che hanno dati parziali e semplicemente aggiustano un po '(se necessario) man mano che la tabella cresce.

Generalmente parlando il rendering rallenta con la quantità di nodi ma anche con la complessità dei nodi ... Evita tabelle nidificate e, se possibile, prova a suddividere tabelle enormi in blocchi ... E.g. Ogni 100 righe (se possibile)

Answer 10

Non c'è davvero un motivo al mondo per pubblicare un intero set di dati enorme su una singola pagina. Se il requisito è fornire all'utente tutti i dati, è necessario esportarlo in un file che può essere letto da un software migliore rispetto a un browser.

Invece, suggerisco di creare una pagina guidata AJAX, in cui si consente all'utente di vedere una parte dei dati e se hanno bisogno di vedere di più, si dovrebbe semplicemente scaricare quella porzione del set di dati e sostituire il dataset corrente su la pagina. Questa è paginazione. La ricerca su Google è un eccellente esempio di questo.

Answer 11

Se ci sono dei limiti, dipende dal browser. Ma il problema è che non si tratta di limiti, dal momento che il browser visualizza ancora la pagina.

Le tabelle grandi sono sempre un problema con i browser. Il rendering di una tabella di grandi dimensioni richiede molto tempo. Pertanto, è spesso una buona idea per dividere un grande tavolo in tabelle più piccole.

Inoltre, è possibile specificare le larghezze delle colonne.Senza questo, il browser deve scaricare l'intera tabella prima che possa calcolare la larghezza di ogni colonna e rendere la tabella. Se si specificano le larghezze nel codice HTML, il browser può visualizzare la pagina mentre sta ancora scaricando. (Nota: specificare la larghezza dell'intera tabella non è sufficiente, è necessario specificare la larghezza di ogni colonna.)

Se si aggiunge una singola riga in una grande tabella utilizzando Javascript, il browser deve probabilmente rendere il intero tavolo di nuovo. Questo è il motivo per cui diventa così lento. Se si dispone di tabelle più piccole, è necessario eseguire nuovamente il rendering di una sola tavoletta. Meglio ancora, se carichi un sotto-tavolo alla volta invece di una sola riga.

Ma il metodo più efficace è dividere i dati in più pagine. Probabilmente anche gli utenti preferiscono questo. Questo è il motivo per cui Google visualizza solo così tanti risultati su ogni pagina.