Debounce dei gestori di input

I gestori di input sono una potenziale causa di problemi di prestazioni nelle tue app, in quanto possono impedire il completamento dei frame e causare un lavoro di layout aggiuntivo e non necessario.

I gestori di input sono una potenziale causa di problemi di prestazioni nelle tue app, in quanto possono impedire il completamento dei frame e causare un lavoro di layout aggiuntivo e non necessario.

Riepilogo

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

Evita i gestori di input a lunga esecuzione

Nel caso più veloce possibile, quando un utente interagisce con la pagina, il thread del compositor della pagina può acquisire l'input touch dell'utente e spostare semplicemente i contenuti. Ciò non richiede alcun lavoro da parte del thread principale, in cui vengono eseguiti JavaScript, layout, stili o disegno.

Se, tuttavia, colleghi un gestore di input, ad esempio touchstart, touchmove o touchend, il thread del compositor deve attendere il completamento dell'esecuzione di questo gestore perché potresti scegliere di chiamare preventDefault() e impedire lo scorrimento touch. Anche se non chiami preventDefault(), il compositor deve attendere e, di conseguenza, lo scorrimento dell'utente viene bloccato, il che può causare scatti e frame mancanti.

In breve, devi assicurarti che tutti i gestori di input che esegui vengano eseguiti rapidamente e consentano al compositor di svolgere il proprio lavoro.

Evita le modifiche allo stile nei gestori di input

I gestori di input, come quelli per lo scorrimento e il tocco, sono pianificati per essere eseguiti immediatamente prima di qualsiasi callback requestAnimationFrame.

Se apporti una modifica visiva all'interno di uno di questi gestori, all'inizio di requestAnimationFrame saranno presenti modifiche allo stile in attesa. Se poi leggi le proprietà visive all'inizio del callback requestAnimationFrame, come suggerito nel consiglio “Evita layout grandi e complessi e il layout thrashing”, attiverai un layout sincrono forzato.

Esegui il debouncing dei gestori di scorrimento

La soluzione a entrambi i problemi sopra indicati è la stessa: devi sempre eseguire il debouncing 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);

Inoltre, questo approccio ha il vantaggio di mantenere leggeri i gestori di input, il che è fantastico perché ora non blocchi elementi come lo scorrimento o il tocco su codice computazionalmente costoso.