Interaction to Next Paint - Tempo de Processamento

Problemas de Interaction to Next Paint (INP) causados pelo tempo de processamento

No nosso artigo anterior falamos sobre o Interaction to Next Paint e sobre como identificar problemas de Interaction to Next Paint. Se você gostaria de ler sobre os conceitos básicos, este é um ótimo lugar para começar!

Neste artigo vou focar no 'tempo de processamento'. Como isso afeta os problemas de Interaction to Next Paint e então explicar como minimizar o tempo de processamento para melhorar o Interaction to Next Paint!

Em resumo: O Interaction to Next Paint (INP) mede quanto tempo leva para ver uma mudança visual em uma página após o usuário ter interagido com ela. Este INP pode ser dividido em 3 componentes: 'input delay', 'tempo de processamento' e 'presentation delay'. O tempo de processamento é um grande contribuinte para o INP total, representando aproximadamente 40% do atraso em média.  Isso significa que otimizar seu código JavaScript, particularmente os event handlers, pode impactar significativamente a pontuação de INP do seu site.

DICA INP: o tempo de processamento pode ser otimizado executando imediatamente o código importante que precede a atualização de layout e agendando todo o outro código para executar depois disso.

O que é tempo de processamento?

O Interaction to Next Paint (INP) pode ser dividido em 3 sub-partes: 'Input Delay', 'Tempo de Processamento' e 'Presentation Delay'

O tempo de processamento refere-se ao tempo que o navegador leva para processar o callback de evento associado após o usuário interagir com uma página web (por exemplo, clicar em um botão ou pressionar uma tecla). Embora sempre haja algum tempo de processamento, os problemas de INP ocorrem quando os callbacks de evento consomem tempo de processamento demais.

Tempo de processamento e o INP

O Tempo de Processamento pode ser 'a coisa' quando você pensa em otimizar o Interaction to Next Paint. É o 'trabalho que precisa ser feito' antes que o layout possa ser atualizado pelo navegador.

Muitos desenvolvedores pensam em melhorar o INP em termos de otimizar a função de callback (otimizar o tempo de processamento) e eles estão certos. Mas em termos de importância, o tempo de processamento nem é a parte mais importante a melhorar, mas ainda assim, em média, representa cerca de 40% do tempo total de INP.

No CoreDash coletamos milhões de pontos de dados de Core Web Vitals a cada hora. Com base nesses dados, o tempo de processamento representa 40% do Interaction to Next Paint. E embora isso seja muito, otimizar o tempo de processamento sozinho provavelmente não será suficiente para corrigir problemas de INP

Exemplo de tempo de processamento: Quando um usuário interage com uma página web, como clicar em um botão, o tempo que o event handler associado a esse clique leva para completar sua execução é conhecido como tempo de processamento. Por exemplo, se um usuário clica em um botão para enviar um formulário, o código que valida os dados do formulário, envia-os ao servidor e trata a resposta contribuiria para o tempo de processamento. Quanto mais longas essas operações levarem, maior o tempo de processamento e potencialmente pior a pontuação de INP.

O que causa alto tempo de processamento?

Para começar a corrigir problemas de INP causados por alto tempo de processamento, precisamos entender quais podem ser as possíveis causas do alto tempo de processamento.  Alto tempo de processamento, o tempo que os callbacks de evento levam para completar a execução, pode ser causado por código desnecessário, código não otimizado, callbacks agrupados e layout thrashing. Vamos examinar melhor essas 4 áreas.

1. Código desnecessário. Código antigo, não utilizado ou código sem relevância imediata para a interação do usuário, pode prolongar o tempo de execução do callback.
   
2. Código não otimizado. Código ineficiente (geralmente loops ou consultas DOM ineficientes) pode fazer os callbacks de evento executarem mais lentamente do que o necessário.
   
3. Callbacks agrupados: Múltiplos callbacks de evento agendados próximos uns dos outros criam uma fila. Se um callback acionado pela interação do usuário ficar preso nesta fila, a resposta parece atrasada.
   
4. Layout thrashing: Manipulações frequentes do DOM que disparam recálculos de layout podem sobrecarregar o navegador e levar a regressões de desempenho.

Minimizar o tempo de processamento

Para minimizar o tempo de processamento precisamos fazer com que o código, responsável pela atualização de layout subsequente, execute o mais rápido possível. Podemos fazer isso otimizando o código existente (remover código desnecessário e otimizar o código atual) e distinguindo entre código que precisa executar antes e depois da atualização de layout. Basicamente, o código crítico para a atualização de layout precisa executar antes dela e todo o outro código pode executar depois da atualização de layout.

1. Remover código não utilizado.  Embora remover código não utilizado possa parecer óbvio, na maioria dos sites há pelo menos algum código antigo e não utilizado que simplesmente executa sem realmente adicionar nada à página nem à UX.  Isso significa que a primeira coisa a fazer é garantir que não há código executando que não é necessário. Isso pode ser feito de várias formas. Por exemplo, por um processo chamado tree shaking ou code splitting. Ou manualmente, inspecionando a cobertura de código no Chrome e também usando um bom IDE que indicará código não utilizado. (Dica profissional: também dê uma olhada crítica nos recursos carregados pelo seu Tag Manager)
2. Minimizar o Tempo de Execução do Callback: Use um profiler JavaScript para identificar gargalos no seu código e direcione essas áreas para otimização. Considere técnicas como memorização, pré-cálculo e cache para evitar computações redundantes. (Dica: você pode usar o painel de desempenho do Chrome para encontrar scripts com longo tempo de execução!)
   
3. Priorizar código crítico e agendar outro código: Quando o código do callback foi otimizado, divida o código em código que precisa executar imediatamente e código que pode ser adiado. Veja este exemplo da vida real:
   
   Neste exemplo, os callbacks de eventos do Google Tag Manager e Facebook são executados antes do código (REACT) que precede a atualização de layout. A solução seria agendar os callbacks do GTM para quando o navegador estiver ocioso
4. Evitar Layout Thrashing ou reflow. Layout thrashing acontece quando atualizações de estilo e leituras de estilo são misturadas em um loop, fazendo o navegador recalcular o layout inúmeras vezes. 
   Para evitar layout thrashing, execute todas as alterações de estilo (os "sets") antes de solicitar valores de estilo (os "gets"). Essa abordagem minimiza a frequência de atualizações de layout, levando a uma página web mais rápida.
   Por exemplo, em um loop que define a largura de cada parágrafo para corresponder à largura de um elemento, leia a largura do elemento uma vez antes do loop e use esse valor para atualizar as larguras dos parágrafos dentro do loop.

Como Priorizar Código Crítico

O último item 'Priorizar código crítico e agendar outro código' pode ser um pouco abstrato para muitos de vocês. Podemos priorizar Código Crítico usando requestIdleCallback() e yielding para a thread principal.

Usamos requestIdleCallback para tarefas menos importantes que não precisam executar imediatamente: Aqui está um exemplo de antes e depois de agendar um evento GTM.

/* before :: immediately run code  */
gtag('event', '<event_name>', {
   'event_category': '<event_category>',
 });

/* after :: run the same code during browser idle */
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
  });
}, { timeout: 1000 });

A desvantagem do requestIdleCallback é que o código pode não executar tão cedo quanto você gostaria. Nesse caso, podemos fazer yielding para a thread principal após o código mais importante ter executado e, assim, dar ao navegador um momento para executar as atualizações de layout. Aqui está um exemplo de como dividir tarefas fazendo yielding para a thread principal

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

async function handleClick(){
 // do the most important layout updates here
 await yieldToMain();
 // do other tasks that need to run as asap after the layout update
}

No futuro poderemos fazer muito mais com o window.scheduler do que apenas yielding para a thread principal. Também poderíamos priorizar tarefas usando a scheduler API (veja Tabela de Suporte).

A scheduler API fornece a função postTask() para agendamento mais refinado de tarefas definindo prioridades, o que ajuda o navegador a priorizar o trabalho para que tarefas de baixa prioridade façam yielding para a thread principal. 

A função postTask() aceita três configurações de prioridade: 'background' para tarefas de menor prioridade, 'user-visible' para tarefas de prioridade média, e 'user-blocking' para tarefas críticas que requerem alta prioridade. 

Ao priorizar tarefas críticas com 'user-blocking', os desenvolvedores podem garantir que elas sejam executadas com maior prioridade, permitindo que o navegador lide com interações do usuário de forma mais responsiva. A scheduler API fornece a função postTask() para agendamento mais refinado de tarefas definindo prioridades, o que ajuda o navegador a priorizar o trabalho para que tarefas de baixa prioridade façam yielding para a thread principal. 

Implicações Práticas

Vamos à pergunta mais importante: 'O que tudo isso significa para o meu site'. Vamos detalhar para WordPress & REACT e ver como você pode melhorar o Interaction to Next Paint quando se trata de tempo de processamento.

WordPress

O WordPress oferece muito pouco controle quando se trata de scripts. Muitos scripts são adicionados através de plugins. Na maioria das vezes, esses scripts adicionam 'event listeners' à página que não fazem nada além de atrasar o Interaction to Next Paint (INP).  Se o seu site WordPress está tendo problemas com o Interaction to Next Paint causados por longo tempo de processamento, siga os seguintes passos:

• Verifique as configurações do tema. Desmarque quaisquer opções desnecessárias como 'smooth scroll' ou 'animated menu'. Configurações como essas tendem a causar problemas de INP.
• Verifique quais scripts são responsáveis pelo longo tempo de processamento (dica: use o painel de desempenho do Chrome). Se esses scripts estão relacionados a plugins, considere encontrar outro plugin que faça aproximadamente o mesmo
• Frequentemente há scripts personalizados executando na página. Verifique esses scripts e certifique-se de que eles façam yielding para a thread principal com frequência e encapsulem callbacks menos importantes em uma função requestIdleCallback
• Descarregue scripts não utilizados por página (dica: use wp_deregister_script). Alguns plugins tendem a injetar scripts em todas as páginas mesmo quando a funcionalidade não é necessária.
• Verifique seu Tag Manager e remova tags não utilizadas ou desnecessárias.
• Use temas leves e limpos. Frequentemente temas multiuso que 'fazem tudo' tendem a ter mais scripts
• Evite page builders pois eles frequentemente dependem muito de JavaScript para apresentar páginas ao usuário final

REACT / NextJS

Os hooks e recursos do React tornam possível reduzir o tempo de processamento do INP:

Priorize a Interação do Usuário com os Recursos de Concorrência do React:

Os recursos de concorrência do React introduzidos nas versões 16 e 18 fornecem hooks e mecanismos para otimizar a renderização para uma user experience mais suave, especialmente durante a entrada de dados.

• useTransition & startTransition: Marque atualizações não críticas para renderização posterior. Isso evita que grandes atualizações bloqueiem a interação do usuário.
• useDeferredValue: Divida sua UI em seções essenciais e menos críticas. O React pode interromper a renderização das partes menos críticas para uma experiência mais responsiva.
• useOptimistic: Mostre um estado temporário e otimista enquanto operações assíncronas (como requisições de rede) estão em andamento. Isso mantém a UI responsiva mesmo durante a busca de dados.

Suspense para Busca de Dados (React 18+):

O Suspense no React 18 pode ser usado para melhorar o INP (Interaction to Next Paint) permitindo que o navegador priorize as interações do usuário e otimize a renderização. Enquanto o React 16 introduziu o Suspense para code splitting, o React 18 estende essa funcionalidade para abranger a busca de dados.

• Um componente fallback, como um indicador de carregamento, é exibido enquanto os dados carregam.
  
• Quando os dados chegam, o React retoma a renderização do componente suspenso.
• O Suspense, combinado com a renderização interrompível no Concurrent React, prioriza as interações do usuário. Se um usuário interage com um componente suspenso, o React prioriza a renderização desse componente, mantendo a responsividade.

No geral, esses recursos trabalham juntos para garantir que o React priorize as interações do usuário e evite bloquear a UI durante atualizações ou busca de dados.