Retornar os gerenciadores de entrada

Os processadores de entrada são uma possível causa de problemas de desempenho nos apps, já que podem impedir a conclusão de frames e causar um trabalho de layout extra e desnecessário.

Os processadores de entrada são uma possível causa de problemas de desempenho nos apps, já que podem impedir a conclusão de frames e causar um trabalho de layout extra e desnecessário.

Resumo

  • Evite processadores de entrada de longa duração, porque eles podem bloquear a rolagem.
  • Não faça mudanças de estilo nos processadores de entrada.
  • Faça a eliminação de ruído dos processadores. Armazene os valores de eventos e lide com mudanças de estilo no próximo callback requestAnimationFrame.

Evitar processadores de entrada de longa duração

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

Rolagem leve: o atraso entre o toque do usuário e o commit da GPU é mínimo apenas com o compositor.

No entanto, se você anexar um gerenciador de entrada, como touchstart, touchmove ou touchend, a linha de execução do compositor precisará aguardar a conclusão desse gerenciador, porque você pode chamar preventDefault() e impedir que a rolagem de toque ocorra. Mesmo que você não chame preventDefault(), o compositor precisa esperar e, portanto, a rolagem do usuário é bloqueada, o que pode resultar em renderização lenta e frames perdidos.

Rolagem pesada: depois do toque do usuário, a rolagem é bloqueada, e o commit da GPU é atrasado pelo manipulador "onTouchMove".

Em resumo, verifique se todos os processadores de entrada executados são rápidos e permitem que o compositor faça o trabalho dele.

Evitar mudanças de estilo nos processadores de entrada

Os processadores de entrada, como os de rolagem e toque, são programados para serem executados pouco antes de qualquer callback requestAnimationFrame.

Se você fizer uma mudança visual em um desses processadores, no início do requestAnimationFrame, haverá mudanças de estilo pendentes. Se você ler propriedades visuais no início do callback requestAnimationFrame, conforme sugerido em “Evitar layouts grandes e complexos e layout thrashing”, vai acionar um layout síncrono forçado.

Rolagem intensa; o estilo de programação lido após requestAnimationFrame resulta em um layout de sincronização forçada.

Eliminar ruído dos processadores de rolagem

A solução para os dois problemas acima é a mesma: você sempre precisa eliminar ruído das mudanças 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);

Isso também tem o benefício adicional de manter os processadores de entrada leves, o que é ótimo porque agora você não está bloqueando ações como rolagem ou toque em códigos computacionalmente caros.