Os gerenciadores de entrada são uma possível causa de problemas de desempenho nos aplicativos, pois podem bloquear a conclusão de quadros e gerar mais atividades de layout do que o necessário.
TL;DR
- Evite gerenciadores de entrada com execução longa: eles podem bloquear a rolagem.
- Não faça mudanças de estilo nos gerenciadores de entrada.
- Rejeite ruído nos gerenciadores: armazene valores de evento e trate as mudanças de estilo no próximo retorno de chamada de requestAnimationFrame.
Evite gerenciadores de entrada com execução longa
No caso mais rápido possível, quando um usuário interage com a página, o thread compositor da página pode pegar a entrada de toque do usuário e simplesmente mover o conteúdo. Isso não exige trabalho do encadeamento principal, onde são executados JavaScript, layout, estilos e coloração.
No entanto, se você anexar um gerenciador de entrada como touchstart
, touchmove
ou touchend
, o thread do compositor deve aguardar o término da execução do gerenciador, pois você pode optar por chamar preventDefault()
e evitar que a rolagem do toque ocorra. Mesmo se você não chamar preventDefault()
, o compositor deve aguardar e, como a rolagem do usuário é bloqueada, pode resultar em oscilação e quadros ausentes.
Resumindo, verifique se todos os gerenciadores de entrada usados são executados rapidamente e permitem que o compositor faça seu trabalho.
Evite mudanças de estilo nos gerenciadores de entrada
Os gerenciadores de entrada, como os usados na rolagem e no toque, são agendados para executar logo antes de qualquer retorno de chamada do requestAnimationFrame
.
Se você fizer uma mudança visual dentro de um desses gerenciadores, haverá mudanças de estilo pendentes no início do requestAnimationFrame
. Se você ler nesse momento as propriedades visuais no início do retorno de chamada do requestAnimationFrame, como sugerido em "Evite layouts grandes e complexos e a troca frequente de layouts", acionará um layout síncrono forçado!
Retarde os gerenciadores de rolagem
A solução para ambos os problemas acima é a mesma: retarde sempre as alterações visuais para o próximo retorno de chamada do 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!