Debounce dei gestori di input

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

Paul Lewis

I gestori di input sono una potenziale causa di problemi di prestazioni nelle app, possono bloccare il completamento dei frame e causare ulteriori lavoro di layout.

Riepilogo

• Evita gestori di input a lunga esecuzione. bloccare lo scorrimento.
• Non apportare modifiche di stile nei gestori di input.
• Eseguire il debounce dei gestori; Archivia i valori degli eventi e gestisci le modifiche di stile nel callback requestAnimationFrame successivo.

Evita gestori di input a lunga esecuzione

Nel caso più veloce possibile, quando un utente interagisce con la pagina, il thread del compositore della pagina può prendere l'input tattile dell'utente e spostare semplicemente i contenuti. Non è richiesto alcun intervento da parte del thread principale, dove vengono eseguiti JavaScript, layout, stili o colorazione.

Tuttavia, se colleghi un gestore di input, come touchstart, touchmove o touchend, il thread del compositore deve attendere che questo gestore termini l'esecuzione, perché potresti scegliere di chiamare preventDefault() e interrompere lo scorrimento del tocco. Anche se non chiami preventDefault(), il compositore deve attendere e, di conseguenza, lo scorrimento dell'utente viene bloccato, causando stuttering e fotogrammi mancanti.

In breve, devi assicurarti che tutti i gestori di input che esegui devono essere eseguiti rapidamente e consentire al compositore di svolgere il proprio lavoro.

Evita modifiche di stile nei gestori di input

I gestori di input, come quelli per lo scorrimento e il tocco, sono pianificati per essere eseguiti poco 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 in "Evita layout grandi e complessi e il thrashing del layout", attiverai un layout sincrono forzato.

Eseguire il debounce dei gestori di scorrimento

La soluzione a entrambi i problemi sopra è la stessa: devi sempre rimandare le modifiche visive al successivo callback requestAnimationFrame:

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);

Questo approccio offre anche il vantaggio aggiuntivo di mantenere leggeri i gestori di input, il che è fantastico perché ora non si bloccano cose come lo scorrimento o il tocco di codice che richiede molte risorse di calcolo.