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.

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 i gestori di input a lunga esecuzione: possono bloccare lo scorrimento.
• Non apportare modifiche di stile nei gestori di input.
• Esegui 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 il termine dell'esecuzione di questo gestore perché potresti scegliere di chiamare preventDefault() e interrompere lo scorrimento 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 gli elaboratori di input che esegui vengano eseguiti rapidamente e consentano al compositore di svolgere il proprio compito.

Evita modifiche di stile nei gestori di input

I gestori di input, come quelli per scorrimento e tocco, sono pianificati per essere eseguiti appena prima di eventuali callback requestAnimationFrame.

Se apporti una modifica visiva in uno di questi gestori, all'inizio del requestAnimationFrame saranno presenti 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);

In questo modo, avrai anche il vantaggio di mantenere leggeri i gestori degli input, il che è fantastico perché ora non blocchi elementi come lo scorrimento o il tocco con codice dal costo computazionale elevato.