Retornar os gerenciadores de entrada

Os gerenciadores de entrada são uma possível causa de problemas de desempenho nos aplicativos, pois podem bloquear a conclusão de frames e causar trabalho de layout adicional e desnecessário.

Os gerenciadores de entrada são uma possível causa de problemas de performance nos apps, já que podem bloquear a conclusão de frames e causar mais trabalho de layout desnecessário.

Resumo

  • Evite gerenciadores de entrada com execução longa, porque eles podem bloquear a rolagem.
  • Não faça mudanças de estilo nos gerenciadores de entrada.
  • Atrase seus gerenciadores: armazene valores de evento e lide com as mudanças de estilo no próximo retorno de chamada de requestAnimationFrame.

Evite gerenciadores de entrada de longa duração

No caso mais rápido possível, quando um usuário interage com a página, o thread compositor da página pode usar a entrada de toque do usuário e simplesmente mover o conteúdo. Isso não exige trabalho da linha de execução principal, onde são realizados JavaScript, layout, estilos ou pintura.

Rolagem leve; somente compositor.

No entanto, se você anexar um gerenciador de entrada, como touchstart, touchmove ou touchend, o thread do compositor vai precisar aguardar o término da execução do gerenciador, porque você pode chamar preventDefault() e impedir que a rolagem por toque ocorra. Mesmo que você não chame preventDefault(), o compositor precisa esperar, e como a rolagem do usuário é bloqueada, pode resultar em oscilação e quadros ausentes.

Rolagem pesada. O compositor está bloqueado no JavaScript.

Em resumo, verifique se todos os gerenciadores de entrada que você executa devem ser executados rapidamente e permitir que o compositor faça seu trabalho.

Evitar mudanças de estilo nos gerenciadores de entrada

Os gerenciadores de entrada, como os usados na rolagem e no toque, são programados para serem executados logo antes de qualquer callback requestAnimationFrame.

Se você fizer uma mudança visual dentro de um desses gerenciadores, haverá mudanças de estilo pendentes no início do requestAnimationFrame. Depois, se você ler as propriedades visuais no início do callback requestAnimationFrame, conforme sugerido em Evite layouts grandes e complexos e a troca frequente de layouts, vai acionar um layout síncrono forçado.

Rolagem pesada. O compositor está bloqueado no JavaScript.

Rejeite a reprodução dos gerenciadores de rolagem

A solução para ambos os problemas acima é a mesma: retarde sempre as alterações visuais para o próximo 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);

Esse retardo oferece o benefício adicional de manter os gerenciadores de entrada leves, o que é muito bom porque ações como rolagem ou toque não são mais bloqueadas em código com alto custo computacional!