INP Input Delay: Causas, Diagnóstico e Correções

Problemas de Interaction to Next Paint (INP) causados por input delay

Esta página faz parte da nossa série sobre Interaction to Next Paint (INP). O INP mede o tempo total desde uma interação do usuário até a próxima atualização visual. O input delay é a primeira de três fases que compõem o INP, seguida pelo processing time e presentation delay. Se você é novo no INP, leia primeiro nosso guia sobre como identificar e corrigir problemas de INP.

DICA DE INP: na maioria das vezes, o input delay ocorrerá durante os estágios iniciais de carregamento da página da web. É quando o navegador está mais ocupado analisando e executando scripts.

O que é input delay?

O input delay refere-se ao tempo que o navegador leva para começar a processar um callback de evento após o usuário interagir com uma página da web (por exemplo, clicando em um botão ou pressionando uma tecla). Embora sempre exista algum input delay (até os navegadores precisam de tempo para agendar os callbacks), um input delay excessivo ocorre quando o navegador está ocupado executando outras tarefas agendadas e não consegue agendar imediatamente os callbacks solicitados pela interação.

Durante o input delay, o usuário já realizou sua ação (clique, toque ou pressionamento de tecla), mas o navegador ainda não começou a executar o manipulador de eventos associado. O usuário não vê nenhuma resposta. Isso é diferente do processing time, onde o manipulador de eventos está em execução ativamente, e do presentation delay, onde o navegador está renderizando a atualização visual. O input delay é um tempo de espera puro causado por uma thread principal congestionada.

Input delay e o INP

O Interaction to Next Paint (INP) pode ser dividido em 3 subpartes: "Input Delay", "Processing Time" e "Presentation Delay".

Você pode notar que existem semelhanças de nomenclatura entre o Input Delay e o antigo Core Web Vital "First Input Delay" (FID). O Interaction to Next Paint substituiu o FID como um Core Web Vital em março de 2024. O First Input Delay media apenas o tempo entre a primeira interação e o callback de evento. Embora o FID tenha sido descontinuado, o input delay ainda é importante porque está na base de cada medição do Interaction to Next Paint.

A importância do input delay

Como muitos desenvolvedores pensam em melhorar o INP em termos de otimização de funções de callback (otimizando o processing time), o input delay é frequentemente negligenciado. É verdade que o input delay geralmente não é a maior parte do INP, mas se otimizarmos o input delay, frequentemente otimizaremos todas as interações de INP de uma vez. Reduzir o input delay melhora cada interação na página, não apenas a pior.

No CoreDash, coletamos milhões de pontos de dados de Core Web Vitals a cada hora. Com base nesses dados, o input delay é responsável por aproximadamente 18% do Interaction to Next Paint. Isso é menos do que o processing time ou o presentation delay, mas o input delay geralmente é a fase mais fácil de reduzir porque a causa raiz quase sempre é "muito JavaScript rodando na hora errada".

Causas do input delay

O input delay ocorre quando a thread principal está ocupada executando outras tarefas. Essas tarefas podem se originar de:

1. Tarefas iniciais. Scripts normais, adiados (deferred) e assíncronos (async) que são enfileirados logo no início criarão tarefas iniciais. Essas são a fonte mais comum de input delay porque são executadas durante a janela crítica de inicialização, quando os usuários têm maior probabilidade de interagir com a página.
2. Tarefas agendadas. Algumas tarefas não são executadas no início do carregamento da página, mas podem ser agendadas para depois que a página for carregada. Essas tarefas também podem interferir no INP e causar um input delay. Por exemplo, scripts que rodam após o evento window.onload ou scripts que são atrasados pelos chamados plugins de otimização. Saiba mais sobre quando usar async ou defer para JavaScript.
3. Tarefas repetidas. Tarefas recorrentes via setInterval() que levam um tempo relativamente longo para serem executadas e coocorrem com o INP.
4. Callbacks sobrepostos. Callbacks sobrepostos são uma causa comum de input delay. Múltiplos callbacks agendados próximos uns dos outros podem criar uma fila, atrasando o processamento da próxima interação. Por exemplo, um manipulador mouseover que dispara logo antes de um manipulador click pode empurrar o processamento do clique para trás pela duração da tarefa do mouseover.

Minimizar o input delay

1. Divida tarefas iniciais longas em várias tarefas menores. Durante tarefas longas, o navegador não consegue responder às entradas do usuário, enquanto após cada tarefa curta, o navegador consegue responder às entradas do usuário. Divida tarefas longas com scheduler.yield() ou encapsulando cada função em um timeout de 0 com setTimeout(callback, 0).
2. Gerencie elementos interativos. Considere não apresentar elementos interativos (como uma barra de pesquisa) antes que o código JavaScript que os controla esteja totalmente carregado. Isso evitará cliques precoces em elementos que não estão prontos para receber cliques. Para otimizar a UX desse padrão, você pode priorizar o carregamento do JavaScript necessário ou ocultar/desativar temporariamente o elemento até que ele esteja funcional.
3. Execução de script em tempo ocioso. Agende scripts não críticos para rodar durante os períodos ociosos do navegador com requestIdleCallback(). Esta função é executada quando o navegador está ocioso e não precisa processar a entrada do usuário.
4. Use web workers para executar JavaScript fora da thread principal do navegador. Web workers permitem que scripts sejam executados fora da thread principal. Isso evitará que a thread principal seja bloqueada e cause problemas de input delay no INP.
5. Verifique se há input pendente durante tarefas repetidas. Antes de executar um conjunto de tarefas agendadas, verifique se há input pendente antes de iniciar as tarefas. Se houver algum input pendente, faça um yield para a thread principal primeiro.
6. Remova código desnecessário. Audite regularmente seus scripts e remova qualquer código desnecessário ou até mesmo scripts inteiros, pois cada linha de código pode potencialmente causar um input delay que afeta o Interaction to Next Paint. Veja nosso guia sobre 14 métodos para adiar JavaScript para técnicas práticas.

Dividindo tarefas com scheduler.yield()

A API scheduler.yield() é a maneira recomendada de dividir tarefas longas. Diferentemente do setTimeout(callback, 0), que coloca a continuação no final da fila de tarefas, o scheduler.yield() preserva a prioridade da tarefa. Isso significa que o navegador retomará seu código o mais rápido possível após lidar com qualquer entrada pendente do usuário. Aqui está uma função auxiliar reutilizável:

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

// Example: break up a long initialization sequence
async function initializeApp() {
  loadCriticalFeatures();
  await yieldToMain();  // Let the browser handle any pending input

  loadSecondaryFeatures();
  await yieldToMain();

  loadAnalytics();
  await yieldToMain();

  loadNonEssentialWidgets();
}

Para saber mais sobre como o scheduler.yield() funciona nos bastidores, consulte o blog do Chrome Developers.

Priorizando tarefas com scheduler.postTask()

Enquanto o scheduler.yield() divide tarefas, o scheduler.postTask() oferece controle refinado sobre a prioridade da tarefa. A API aceita três níveis de prioridade: "user-blocking" para tarefas críticas que exigem a prioridade mais alta, "user-visible" para tarefas de prioridade média e "background" para tarefas de prioridade mais baixa que devem ser executadas durante o tempo ocioso.

Usando postTask() você pode garantir que trabalhos não essenciais não bloqueiem as interações do usuário. Aqui está um exemplo prático que agenda o trabalho de análise na prioridade background, enquanto mantém as atualizações da UI na prioridade mais alta:

// High priority: UI feedback runs first
scheduler.postTask(() => {
  showLoadingSpinner();
}, { priority: 'user-blocking' });

// Medium priority: fetch data
scheduler.postTask(async () => {
  const data = await fetchSearchResults(query);
  renderResults(data);
}, { priority: 'user-visible' });

// Low priority: analytics can wait
scheduler.postTask(() => {
  trackSearchEvent(query);
  sendToAnalytics('search', { query });
}, { priority: 'background' });

Verifique a tabela de suporte de navegadores para o scheduler.postTask() antes de usá-lo em produção. Para navegadores que não suportam a API, use o fallback requestIdleCallback() para tarefas em background e queueMicrotask() para tarefas de alta prioridade.

Implicações práticas

O que isso significa para o seu site? Aqui estão recomendações específicas para WordPress e React/Next.js.

WordPress

O WordPress, devido à sua arquitetura baseada em plugins, costuma vir com um tema e um grande número de plugins. Tanto os plugins quanto os temas frequentemente dependem do JavaScript para sua funcionalidade. Como esses plugins e temas são mantidos por desenvolvedores de terceiros, você não tem controle sobre o conteúdo. Isso significa que você não pode alterar os arquivos e otimizar "códigos ruins". Mesmo que os scripts se comportem bem hoje, não há garantia de que farão o mesmo após a próxima atualização.

Para minimizar o input delay e otimizar o Interaction to Next Paint (INP) no WordPress, siga as seguintes etapas:

• Evite usar plugins sempre que possível. Embora os plugins sejam uma maneira fácil de adicionar funcionalidade, eles frequentemente adicionam scripts à página. Esses scripts causarão um input delay que impacta o INP. Para cada plugin, pergunte a si mesmo: consigo alcançar a mesma funcionalidade com um código personalizado ou uma solução do lado do servidor?
• Escolha temas leves. Muitos temas do WordPress "oferecem de tudo". Embora isso pareça uma ótima ideia, significa que eles provavelmente estão repletos de funcionalidades que não são usadas, mas que consomem um tempo valioso de CPU.
• Evite page builders. Page builders como o Elementor ou o WPBakery oferecem uma interface visual e amigável para a construção de layouts. Infelizmente, eles muitas vezes dependem de scripts pesados para apresentar esse layout aos visitantes.
• Carregue scripts apenas quando forem necessários. O WordPress tem a tendência de carregar todos os scripts em todas as páginas. Para corrigir isso, crie um tema filho (child theme) e cancele o registro de scripts desnecessários por tipo de página:

function my_deregister_scripts() {
  if ( ! is_page( 'contact' ) ) {
    // Deregister contact form script on non-contact pages
    wp_dequeue_script( 'contact-form-script' );
  }
}
add_action( 'wp_enqueue_scripts', 'my_deregister_scripts' );

• Faça uma auditoria no seu Tag Manager. Contêineres do Google Tag Manager costumam acumular tags ao longo do tempo. Cada tag disparada durante o carregamento da página adiciona uma tarefa à thread principal. Remova tags não utilizadas, defina gatilhos apropriados (por exemplo, dispare tags de marketing apenas em páginas de conversão) e use os relatórios de tempo integrados do Tag Manager para identificar tags lentas.
• Adie scripts não essenciais de terceiros. Widgets de chat, ferramentas de feedback e incorporações de mídias sociais não precisam carregar imediatamente. Use requestIdleCallback() ou um gatilho baseado em rolagem para carregá-los apenas quando o usuário provavelmente precisar deles. Para estratégias detalhadas, leia nosso guia sobre 14 métodos para adiar JavaScript.

React / Next.js

Sites em React e Next.js são alimentados principalmente por JavaScript. Executar scripts de inicialização, hidratar componentes e processar o DOM virtual exigem tempo e podem causar um input delay para o Interaction to Next Paint (INP). A boa notícia é que tanto o React quanto o Next.js fornecem ferramentas para gerenciar isso de forma eficaz.

• Use componentes de servidor (React Server Components no App Router do Next.js). Os componentes de servidor são renderizados no servidor e enviam zero JavaScript ao cliente, o que reduz diretamente a quantidade de código competindo pelo tempo da thread principal.
• Carregue scripts de terceiros com a estratégia correta. No Next.js, use o componente next/script com strategy="afterInteractive" para scripts necessários após a hidratação, ou strategy="lazyOnload" para scripts que podem carregar durante o tempo ocioso do navegador. Consulte nosso guia de async vs defer JavaScript para entender os princípios subjacentes.
• Implemente um padrão idle-until-urgent. Este padrão prioriza as interações do usuário em relação às tarefas em background, usando o requestIdleCallback() para inicializações não críticas, enquanto mantém um fallback síncrono que é ativado quando o componente é realmente necessário.
• Faça o lazy load de componentes. Carregue de forma lazy os componentes que não são necessários imediatamente usando o React.lazy() ou o dynamic() do Next.js com { ssr: false } para componentes exclusivos do cliente.
• Use o Suspense para componentes interativos. Envolva componentes interativos em limites do <Suspense> para que o restante da página possa ser renderizado e se tornar interativo enquanto componentes pesados carregam em background. Isso evita que um único componente lento bloqueie o processamento de input em toda a página.
• Use transições do React para atualizações não urgentes. Envolva atualizações de estado não críticas no startTransition() para que o React possa interrompê-las caso o usuário realize uma nova interação. Isso mantém a UI responsiva mesmo quando grandes re-renderizações estão em andamento.

Explore as outras fases do INP

Para manter o seu INP sob controle, aborde as outras duas fases também:

• Processing Time: Otimize o código do manipulador de eventos que roda durante a interação. Na maioria das páginas, é aqui que grande parte do seu esforço de otimização compensa.
• Presentation Delay: Reduza o trabalho de renderização e pintura que se segue ao processamento do evento. Em páginas complexas com DOMs grandes, essa costuma ser a maior fase.

Para um fluxo de trabalho de diagnóstico completo, veja nosso guia sobre como encontrar e corrigir problemas de INP, e retorne à página central do INP para a visão geral completa.