Come molti altri hanno già detto, non puoi davvero "caricare il saldo" in javascript. A meno che tu non stia usando lavoratori, javascript fa una cosa alla volta. Il meglio che puoi sperare di fare è lavorare per ottenere le attività fuori dalla coda più velocemente di quanto stanno arrivando. Ecco alcune cose da considerare:
Fai attenzione con il DOM
Una grande parte di questo è, come le altre risposte, evitando i ripetuti del DOM, poiché possono essere estremamente costosi. Prova a fare tutte le tue letture DOM in un unico passaggio e tutte le tue scritture in un altro, poiché la lettura dal DOM spesso lo induce a disegnare tutte le modifiche in coda per assicurarti che abbia informazioni aggiornate. Se stai utilizzando le informazioni per apportare più modifiche al DOM, verrà ridisegnato di nuovo e l'utente non vedrà nemmeno quel primo ridisegno.
Evita setInterval
Se la funzione di callback impiega più tempo dell'intervallo da eseguire, si otterranno più copie della funzione di callback nella coda e il codice scenderà sempre più indietro mentre scorre. Questo è il motivo per cui molte persone suggeriscono di usare un setTimeout che si imposta quando è finito. In questo modo, c'è sempre un'istanza della richiamata in attesa in coda.
Eventi "Burst" di buffer
Alcuni eventi sparano più volte contemporaneamente, ma in realtà dovresti reagire solo all'ultimo evento. Un esempio di ciò che ho visto spesso è un listener di eventi di scroll. Quando l'utente scorre la pagina, questo evento può sparare più volte al secondo, e se il listener fa un vero lavoro, allora la coda si sta accumulando molto più velocemente di quanto non lo sia. Ecco perché vedi spesso schemi come questo:
var scrollTimer;
function scrollHandler(e) {
// Actually handle the scrolling, DOM manipulations, real work...
}
window.addEventListener('scroll', function (e) {
clearTimeout(scrollTimer);
scrollTimer = setTimeout(scrollHandler, 100, e);
});
In questo modo, indipendentemente da quanto l'utente scorre, il codice pesante non viene effettivamente eseguito finché non smettono di scorrere (in questo caso per un decimo di secondo).
Eventi continui cache
Ho scoperto che in alcune situazioni alcuni eventi arrivano quasi continuamente e hanno più ascoltatori. Se stai reagendo all'accelerometro, al GPS, ai controller di gioco (o alle tastiere utilizzate come controller), probabilmente gli eventi arriveranno il più velocemente possibile, innescando i loro ascoltatori quasi costantemente. Ogni cosa cerca di accadere il più velocemente possibile, e questo lo rende lento . A differenza degli eventi "scoppiati", tuttavia, non puoi semplicemente aspettare che questi eventi si fermino prima di reagire. L'intero punto è reagire mentre cambiano.
Se ci pensi, però, il tuo codice deve solo reagire una volta per frame. Avere un singolo keydown / keyup listener che imposta i flag per le chiavi che si desidera. Avere un unico aggiornamento per l'ascoltatore dell'accelerometro e un array con dati di orientamento, oppure un ascoltatore GPS memorizza la latitudine e la longitudine. Questi ascoltatori dovrebbero essere abbastanza veloci da mantenere lo svuotamento della coda tanto rapidamente quanto si riempie. Con quello in atto, puoi passare in rassegna tutti i tuoi oggetti una volta sola e farli controllare i flag e gli array per le informazioni di cui hanno bisogno.