Debounce dei gestori di input

I gestori di input sono una potenziale causa di problemi di prestazioni nelle app, in quanto possono bloccare il completamento dei frame e possono causare operazioni di layout aggiuntive e non necessarie.

Paul Lewis

I gestori di input sono una potenziale causa di problemi di prestazioni nelle app, in quanto possono bloccare il completamento dei frame e possono causare operazioni di layout aggiuntive e non necessarie.

Riepilogo

  • Evita gestori di input a lunga esecuzione, che possono bloccare lo scorrimento.
  • Non apportare modifiche allo stile nei gestori di input.
  • Elimina il rimbalzo dei gestori; memorizza i valori degli eventi e gestisci le modifiche di stile nel callback requestAnimationFrame successivo.

Evita gestori di input a lunga esecuzione

Nel caso più rapido possibile, quando un utente interagisce con la pagina, il thread di composizione della pagina può prendere l'input tocco dell'utente e spostare semplicemente i contenuti. Ciò non richiede alcuna operazione da parte del thread principale, dove vengono eseguiti JavaScript, layout, stili o Paint.

Scorrimento leggero; solo compositor.

Tuttavia, se colleghi un gestore di input, come touchstart, touchmove o touchend, il thread del compositore deve attendere che l'esecuzione del gestore venga completata perché puoi scegliere di chiamare preventDefault() e interrompere lo scorrimento al tocco. Anche se non chiami preventDefault(), il compositore deve attendere e pertanto lo scorrimento dell'utente viene bloccato, il che può causare interruzioni e fotogrammi persi.

Scorrimento intensivo; il compositore è bloccato su JavaScript.

In breve, dovresti assicurarti che eventuali gestori di input da eseguire vengano eseguiti rapidamente e consentire al compositore di svolgere il proprio lavoro.

Evitare modifiche dello stile nei gestori dell'input

I gestori di input, come quelli per scorrimento e tocco, sono programmati per essere eseguiti subito prima di qualsiasi callback requestAnimationFrame.

Se apporti una modifica visiva all'interno di uno di questi gestori, all'inizio di requestAnimationFrame ci saranno modifiche di stile in attesa. Se quindi leggi le proprietà visive all'inizio del callback requestAnimationFrame, come suggerito nel paragrafo "Evita layout complessi e di grandi dimensioni e thrashing di layout", attiverai un layout sincrono forzato.

Scorrimento intensivo; il compositore è bloccato su JavaScript.

Rimuovere il rimbalzo dei gestori di scorrimento

La soluzione a entrambi i problemi è la stessa: devi sempre eseguire il debounce delle modifiche visive al callback requestAnimationFrame successivo:

function onScroll (evt) {

    // Store the scroll value for laterz.
    lastScrollY = window.scrollY;

    // Prevent multiple rAF callbacks.
    if (scheduledAnimationFrame)
    return;

    scheduledAnimationFrame = true;
    requestAnimationFrame(readAndUpdatePage);
}

window.addEventListener('scroll', onScroll);

Questa operazione ha anche il vantaggio di mantenere leggeri i gestori dell'input, il che è fantastico, perché ora non puoi bloccare cose come lo scorrimento o la necessità di toccare codice dispendioso in termini di calcolo.