Interaction to Next Paint (INP): O Que É, Como Medir e Melhorar

A Interaction to Next Paint (INP) é uma Core Web Vital que mede a rapidez com que uma página da web responde às interações do usuário, como cliques, toques e pressionamentos de tecla. A INP captura a latência total, desde a entrada do usuário, passando pelo processamento do JavaScript, até a atualização visual final na tela. Uma boa pontuação de INP é de 200 milissegundos ou menos no 75º percentil. A INP substituiu o First Input Delay (FID) como uma Core Web Vital em março de 2024.

O que é a Interaction to Next Paint (INP)?

A Interaction to Next Paint (INP) é uma métrica de Core Web Vitals que mede a responsividade de uma página da web durante toda a visita de um usuário. Ao contrário de seu predecessor, o First Input Delay (FID), que media apenas o atraso antes do início do manipulador de eventos da primeira interação, a INP avalia cada interação que um usuário faz com a página e relata um único valor que representa a responsividade geral da página.

Toda vez que um usuário clica em um botão, toca em um link, pressiona uma tecla no teclado ou interage com um controle personalizado, o navegador mede o tempo total desde o momento da entrada até quando o próximo quadro é renderizado na tela. A INP seleciona uma das interações mais lentas como a pontuação de responsividade da página. Para páginas com menos de 50 interações no total, a INP relata a pior interação única. Para páginas com muitas interações, a INP geralmente usa o 98º percentil para filtrar exceções ocasionais.

Uma INP baixa significa que a página responde de forma confiável à entrada do usuário em tempo hábil. Uma INP alta significa que a página parece lenta, não responsiva ou "janky" (com travamentos) porque o navegador não consegue processar as interações e atualizar a tela com rapidez suficiente.

INP vs FID: O Que Mudou e Por Quê

A INP substituiu oficialmente o First Input Delay (FID) como uma Core Web Vital em março de 2024. O Google aposentou o FID porque ele tinha duas limitações fundamentais que o tornavam uma medida incompleta da responsividade da página.

Primeiro, o FID media apenas a primeira interação em uma página. Se o primeiro clique de um usuário fosse rápido, mas as interações subsequentes fossem lentas, o FID relataria uma pontuação de aprovação, apesar da experiência ruim. A INP mede todas as interações ao longo da sessão, fornecendo uma imagem muito mais precisa da responsividade real.

Segundo, o FID media apenas a fase de atraso de entrada (input delay), o que significa que capturava o tempo que o navegador passava esperando antes de começar a processar o evento. Ele ignorava completamente o tempo gasto na execução do código do manipulador de eventos (tempo de processamento) e o tempo necessário para renderizar o resultado visual na tela (atraso de apresentação). A INP captura todas as três fases, dando aos desenvolvedores uma visão completa da latência da interação.

A transição do FID para a INP causou uma queda de cerca de 5 pontos percentuais nas taxas de aprovação de Core Web Vitals em dispositivos móveis, de acordo com o Web Almanac de 2025 do HTTP Archive. Isso aconteceu porque muitos sites que pareciam responsivos no FID tinham interações posteriores lentas que a INP agora captura.

Quais Interações a INP Mede?

A INP mede apenas interações que envolvem entradas discretas do usuário que o navegador pode observar através de manipuladores de eventos. Entender quais interações contam é essencial para uma depuração e otimização precisas.

Interações que contam para a INP

• Cliques do mouse (incluindo cliques em botões, links, caixas de seleção e controles personalizados)
• Toques em telas sensíveis ao toque (equivalente a cliques em dispositivos móveis)
• Pressionamentos de tecla em um teclado físico ou na tela (incluindo digitação em campos de formulário, pressionar Enter, usar atalhos de teclado)

Interações que NÃO contam para a INP

• Rolagem (Scrolling) não conta porque é tratada pela thread do compositor do navegador e geralmente não bloqueia a thread principal
• Passar o mouse (Hovering) não conta porque é um estado contínuo do ponteiro, não uma interação discreta do usuário
• Gestos de arrastar não contam, embora o pointerdown inicial que inicia o arrasto possa acionar uma entrada na INP
• Transições e animações CSS que ocorrem sem a entrada do usuário não são interações

Um equívoco comum é que a rolagem afeta a INP. Ela não afeta. No entanto, se sua página usar uma rolagem baseada em JavaScript em vez da rolagem nativa do navegador, esses manipuladores de rolagem do JavaScript podem acionar callbacks de eventos que o navegador mede como interações. Essa é uma das razões pelas quais a rolagem CSS nativa supera consistentemente a rolagem do JavaScript em termos de responsividade.

As Três Fases de uma Interação INP

Cada interação medida pela INP consiste em três fases sequenciais. O valor total da INP é a soma de todas as três. Entender cada fase é fundamental porque a estratégia de otimização difere para cada uma delas.

1. Atraso de Entrada (Input Delay)

O atraso de entrada é o tempo entre o momento em que o usuário interage com a página e quando o navegador começa a executar os manipuladores de eventos associados. Esse atraso ocorre porque a thread principal do navegador pode estar ocupada com outro trabalho, como analisar JavaScript, executar tarefas agendadas anteriormente ou processar outros callbacks de eventos.

O atraso de entrada é especialmente problemático durante a fase de carregamento da página, quando muitos scripts estão sendo analisados e executados simultaneamente. Os dados do CoreDash mostram que interações durante a fase de carregamento têm uma INP no p75 de 132ms, em comparação com apenas 50ms para interações após a conclusão do carregamento da página. Essa é uma diferença de 2,6x. Reduzir a contenção da thread principal durante a inicialização da página é uma das maneiras mais eficazes de melhorar a INP.

Na mediana, o atraso de entrada é a menor subparte da INP. Mas no 90º percentil, o atraso de entrada se torna o contribuinte dominante porque tarefas longas na thread principal podem atrasar o processamento de eventos em centenas de milissegundos. O Web Almanac de 2025 do HTTP Archive descobriu que menos de 25% dos sites mantêm a duração das tarefas abaixo do limite recomendado de 50ms.

2. Tempo de Processamento (Processing Time)

O tempo de processamento é o tempo total que o navegador gasta executando todos os callbacks do manipulador de eventos associados à interação. Isso inclui qualquer JavaScript que seja executado em resposta ao evento, desde validação de formulários até atualizações de estado e chamadas de rastreamento de análises.

O tempo de processamento é responsável por uma parte significativa da INP total. Se um manipulador de eventos realizar operações complexas no DOM, fizer chamadas de API síncronas ou executar loops ineficientes, o tempo de processamento irá aumentar exponencialmente. Um padrão comum que infla o tempo de processamento é executar códigos não essenciais (como eventos de análise ou callbacks de tags de terceiros) dentro do mesmo manipulador de eventos da atualização visual crítica.

3. Atraso de Apresentação (Presentation Delay)

O atraso de apresentação é o tempo entre a conclusão de todos os manipuladores de eventos e quando o navegador apresenta o próximo quadro contendo a atualização visual. Essa fase inclui o recálculo de estilos, a computação de layout, a pintura (painting) e a composição (compositing).

Na mediana, o atraso de apresentação é a maior subparte da INP porque cada interação requer pelo menos um passe de renderização. Páginas com um DOM grande ou profundamente aninhado levam mais tempo para recalcular estilos e realizar o layout. Single Page Applications (SPAs) que renderizam novamente grandes árvores de componentes após mudanças de estado são particularmente suscetíveis a um alto atraso de apresentação.

Quais são as Pontuações Boas e Ruins de INP?

Para passar na avaliação do Core Web Vitals para a métrica de Interaction to Next Paint, o 75º percentil de todas as interações registradas em campo deve permanecer abaixo de 200 milissegundos:

• Uma INP abaixo ou igual a 200 milissegundos significa que sua página tem uma boa responsividade.
• Uma INP entre 200 e 500 milissegundos significa que a responsividade da sua página precisa de melhorias.
• Uma INP acima de 500 milissegundos significa que sua página tem uma responsividade ruim.

É importante entender que a INP usa o 75º percentil, não a média. Isso significa que 75% dos seus usuários reais devem experimentar interações mais rápidas que 200ms. A metodologia do 75º percentil garante que a métrica reflita a experiência dos usuários em dispositivos e conexões mais lentos, não apenas daqueles com hardware de ponta.

Como Medir a Interaction to Next Paint (INP)

A Interaction to Next Paint só pode ser medida com ferramentas de campo que capturam interações de usuários reais. Ao contrário das métricas de laboratório que simulam um único carregamento de página, a INP requer visitantes reais clicando, tocando e digitando em suas páginas. Não há como obter uma pontuação de INP significativa a partir de um teste sintético porque a INP depende do comportamento humano real.

Obtenha as Métricas Oficiais de INP

Você pode obter as métricas oficiais de INP do PageSpeed Insights ou do painel CrUX e Google BigQuery. O PageSpeed Insights relata a pontuação do 75º percentil com base nos últimos 28 dias de dados de usuários do Chrome. O Google BigQuery fornece mais contexto histórico e permite consultas personalizadas em todo o conjunto de dados CrUX.

O Google Search Console também relata problemas de INP na seção Core Web Vitals, agrupando URLs afetados e sinalizando páginas que precisam de melhorias ou têm uma responsividade ruim.

Rastreie a INP com Real User Monitoring (RUM)

Embora o conjunto de dados CrUX oficial seja a fonte definitiva para as pontuações do Core Web Vitals, ele é altamente anonimizado e não suporta monitoramento em tempo real ou filtragem detalhada. É por isso que os profissionais de desempenho web dependem de ferramentas de Real User Monitoring (RUM) como o CoreDash para obter dados de INP práticos e em tempo real. As ferramentas RUM coletam medições de INP a cada carregamento de página, atribuem-nas a elementos específicos, estados de carregamento e tipos de dispositivos, e permitem diagnosticar exatamente quais interações estão causando problemas.

Meça a INP para a Sessão Atual

A maneira mais simples de depurar a INP durante o desenvolvimento é através do Chrome DevTools. Abra o painel de Desempenho (Performance) e use o modo "timespan" (período de tempo) no Lighthouse para registrar as interações e ver sua latência. Você também pode usar a extensão Core Web Vitals Visualizer, que sobrepõe as pontuações de INP na página conforme você interage com ela.

Para depuração prática, use a Biblioteca JavaScript Web Vitals do Google para registrar interações individuais no console:

Registre a INP no console com a biblioteca JavaScript Web Vitals

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Como Melhorar a Interaction to Next Paint

Melhorar a Interaction to Next Paint requer a otimização de todas as três fases: atraso de entrada, tempo de processamento e atraso de apresentação. Sua página pode responder instantaneamente à maioria das interações, mas se pelo menos uma interação for lenta, ela pode definir toda a pontuação de INP. É por isso que uma abordagem sistemática é necessária.

Dica do PageSpeed: na maioria das vezes, a INP será muito pior quando um usuário interagir com a página durante a fase de inicialização do carregamento da página. É por isso que, ao depurar a INP, faz sentido registrar todas as interações, bem como o estado de carregamento da página!

1. Minimize o Atraso de Entrada: Evite Tarefas Longas na Thread Principal

Geralmente, qualquer página é menos responsiva durante a fase de inicialização da página, quando ocorre a maior parte do trabalho da thread principal (análise, decodificação, renderização e scripts). Para manter a thread principal o mais livre possível:

• Remova códigos não utilizados. Use tree shaking para remover códigos inativos e code splitting (divisão de código) para dividir seu pacote (bundle) em blocos menores que são carregados sob demanda. Audite a cobertura do seu código usando o Chrome DevTools para identificar scripts que carregam, mas nunca são executados.
• Carregue códigos não essenciais durante o tempo ocioso do navegador. Você realmente precisa de um widget de chat durante os primeiros 500ms do carregamento da página? Agende scripts não críticos com requestIdleCallback() para serem executados apenas quando o navegador estiver ocioso.
• Identifique e reescreva scripts lentos que consomem recursos excessivos de CPU. Use o painel de Desempenho (Performance) do Chrome para encontrar scripts com longos tempos de execução e busque otimizá-los.
• Mantenha sua página fácil de renderizar. Evite tamanhos grandes de DOM, imagens excessivas, muitos vídeos e animações CSS que exigem muito da CPU.
• Use async e defer nas tags de script para evitar que o JavaScript bloqueie o analisador de HTML. Considere adiar o JavaScript não crítico completamente até que a página se torne interativa.

Divida Tarefas Longas com scheduler.yield()

O JavaScript roda na thread principal do navegador usando um modelo "run to completion" (executar até a conclusão): quando uma tarefa começa, ela bloqueia a thread principal até terminar. Tarefas longas (mais de 50ms) impedem que o navegador responda à entrada do usuário. A API scheduler.yield() permite que você crie explicitamente pontos de yield (cedência) dentro de códigos de longa duração, dando ao navegador a oportunidade de processar as interações pendentes do usuário antes de continuar.

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

// Uso: divida uma tarefa longa em blocos menores
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Faz um yield (cede) a cada 5 itens para deixar o navegador lidar com a entrada do usuário
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Adie Trabalhos Não Críticos com requestIdleCallback

Use requestIdleCallback() para agendar tarefas não essenciais (análises, telemetria, prefetching) para quando o navegador estiver ocioso. Isso mantém a thread principal livre para interações do usuário e reduz diretamente o atraso de entrada.

// Em vez de executar análises de forma síncrona:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Crítico: atualize a interface do usuário (UI) imediatamente
  showConfirmation();

  // Não crítico: envie as análises durante o tempo ocioso
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Use Ouvintes de Eventos Passivos (Passive Event Listeners)

Para eventos que não precisam chamar preventDefault(), marque seus ouvintes de eventos (event listeners) como passivos. Isso informa ao navegador que ele não precisa esperar o seu manipulador (handler) decidir se deve cancelar o comportamento padrão, permitindo uma rolagem mais suave e uma resposta de toque mais rápida.

// Ouvinte passivo: o navegador não espera por preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Minimize o Tempo de Processamento: Forneça Feedback Imediato

Quando um visitante realiza uma ação, como enviar um formulário ou adicionar um item ao carrinho, não espere pela confirmação do lado do servidor antes de atualizar a interface do usuário. Forneça um feedback visual imediato ("Enviando seu formulário...", "Adicionando item ao carrinho...") e depois conclua a operação em segundo plano.

Além disso, ceda (yield) a thread principal o mais rápido possível após a atualização visual crítica. Como o JavaScript segue um modelo "run to completion", ele bloqueia a thread principal até que todo o código no callback tenha sido executado. Você pode criar manualmente um ponto de yield onde o navegador pode atualizar o layout e depois continuar executando o código não crítico restante.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Enviando o formulário... aguarde";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. Minimize o Atraso de Apresentação: Mantenha as Coisas Simples

Quando a página precisa ser atualizada após uma interação, o navegador deve recalcular estilos, realizar o layout, pintar (paint) os pixels alterados e compor (composite) o resultado. A complexidade e o tamanho do seu DOM determinam diretamente quanto tempo esse trabalho de renderização leva.

Alguns ambientes SPA mal otimizados renderizam novamente uma quantidade de conteúdo muito maior do que o necessário após cada interação. Por exemplo, ao atualizar um contador, certifique-se de atualizar apenas o elemento do contador, e não toda a árvore de componentes.

Siga estas duas regras de ouro para uma renderização mais rápida:

1. Mantenha o DOM pequeno e simples. É muito mais fácil para um navegador renderizar uma página com menos elementos DOM (nós HTML) do que uma página com estruturas DOM profundamente aninhadas e complicadas. Busque ter menos de 1.400 elementos DOM no total, e evite aninhar mais de 32 níveis.
2. Use content-visibility para atrasar a renderização do conteúdo fora da tela (lazy-render). A propriedade CSS content-visibility: auto acelera a renderização inicial adiando a renderização do conteúdo fora da tela até que o usuário role a página para perto dele.

/* Aplique content-visibility para seções fora da tela */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Depurando a INP com a API Long Animation Frames (LoAF)

A API Long Animation Frames (LoAF) é uma ferramenta poderosa para diagnosticar problemas de INP. Ela fornece informações detalhadas sobre quadros que levam mais de 50ms para renderizar, incluindo dados de atribuição de script que dizem exatamente quais scripts estão contribuindo para interações lentas.

Ao contrário da antiga API Long Tasks, a LoAF captura o tempo de renderização, bem como o tempo de execução do script, o que a torna particularmente útil para diagnosticar problemas de atraso de apresentação. As entradas da LoAF incluem a duração do quadro, a duração do bloqueio e uma matriz (array) de entradas de script que mostram o URL de origem, o nome da função e o tempo de execução de cada script que foi executado durante o quadro.

// Observe o Long Animation Frames para encontrar gargalos na INP
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Analise apenas os quadros com mais de 100ms
    if (entry.duration > 100) {
      console.log('Quadro longo:', entry.duration + 'ms');

      // Registre cada script que contribuiu
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Função:', script.sourceFunctionName,
          'Duração:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Ferramentas RUM como o CoreDash integram os dados do LoAF automaticamente, correlacionando os longos quadros de animação com as interações específicas do usuário para que você possa identificar exatamente qual script, em qual página e para qual tipo de interação, está causando as suas piores pontuações de INP.

INP e LCP: A Conexão com as Tarefas Longas (Long Tasks)

Tarefas longas na thread principal afetam tanto a INP quanto o Largest Contentful Paint (LCP). Uma tarefa JavaScript que bloqueia a thread principal por 200ms atrasa o processamento de eventos (piorando a INP) e também atrasa o navegador de renderizar o elemento LCP (piorando o LCP). Quando você otimiza a sua thread principal dividindo tarefas longas, adiando o JavaScript não crítico e reduzindo o tempo de execução de scripts, você melhora ambas as métricas simultaneamente.

Estudos de Caso: Melhorias de INP em Produção

redBus: 80 a 100% de Melhoria na Conversão em Dispositivos Móveis

A redBus, uma das maiores plataformas de emissão de passagens de ônibus online do mundo, investiu na otimização de Core Web Vitals em seus mercados globais. O foco na redução do tempo de execução de JavaScript e na otimização de manipuladores de eventos contribuiu para uma melhoria de 80 a 100% nas taxas de conversão em dispositivos móveis em seus mercados globais. As melhorias foram impulsionadas por uma combinação de redução do tempo de bloqueio da thread principal, otimização do carregamento de scripts de terceiros e implementação de code splitting para reduzir a quantidade de JavaScript analisada durante a inicialização da página.

Preply: INP de 250ms para 185ms, US$ 200.000 por Ano em Economia Estimada em SEO

A Preply, uma plataforma online de tutoria de idiomas, melhorou a INP de sua página inicial de aproximadamente 250ms para 185ms e a INP de sua página de pesquisa de aproximadamente 250ms para 175ms. A equipe alcançou esses ganhos ao fazer o profiling de seu aplicativo React, identificando e eliminando re-renderizações desnecessárias e adiando callbacks de eventos não críticos. As pontuações melhoradas do Core Web Vitals se correlacionacionaram com classificações de pesquisa mais altas, traduzindo-se em cerca de US$ 200.000 por ano em valor orgânico de SEO.

O que os Dados do Mundo Real Mostram Sobre a INP

A Diferença de INP entre Dispositivos Móveis e Desktop

Os dados do CoreDash revelam que a INP em dispositivos móveis (131ms no p75) é 2,8 vezes pior do que a INP no desktop (48ms no p75). Essa é a maior diferença entre dispositivos de qualquer métrica de Core Web Vital. Os dispositivos móveis têm processadores mais lentos, menos memória e maior latência de rede, e todos esses fatores contribuem para tempos de bloqueio mais longos na thread principal e um processamento de eventos mais lento. No desktop, 95,6% das interações alcançam uma pontuação "boa" de INP, enquanto nos dispositivos móveis esse número cai para 88,0%. Os usuários móveis também experimentam 5 vezes mais eventos de INP "ruins" (9,6% vs 1,9%).

Interações de Teclado vs Ponteiro

Os dados do CoreDash mostram que interações de teclado (75ms no p75) são 56% mais lentas do que interações de ponteiro (49ms no p75). Os eventos de teclado também têm um número significativamente maior de experiências ruins: 7,4% das interações de teclado resultam em uma INP ruim, em comparação com apenas 1,4% para interações de ponteiro. Essa lacuna se deve, provavelmente, ao fato de que eventos de teclado, especialmente em campos de formulário, acionam processamentos mais complexos, como validação de entrada, sugestões de preenchimento automático (autocomplete) e atualizações de estado.

Interações Durante o Carregamento vs Pós-Carregamento

Interações que ocorrem durante o carregamento da página têm uma INP drasticamente maior do que as interações que acontecem depois que a página está totalmente carregada. Os dados do CoreDash mostram que as interações durante a fase de "carregamento" (loading) têm uma INP no p75 de 132ms, em comparação com apenas 50ms para interações pós-carregamento. Isso é uma diferença de 2,6 vezes. Mesmo as interações durante a fase "dom-content-loaded" (75ms) apresentam uma INP elevada porque scripts assíncronos e sub-recursos ainda estão sendo processados. Esses dados apoiam fortemente a recomendação de adiar o JavaScript não crítico para reduzir a contenção da thread principal durante a inicialização da página.

Taxas Globais de Aprovação na INP

De acordo com o Web Almanac de 2025 do HTTP Archive, 77% de todas as páginas móveis atingem uma pontuação "boa" de INP (um aumento em relação aos 55% de 2022). No entanto, apenas 53% dos 1.000 sites mais visitados passam na avaliação de INP. Sites de alto tráfego tendem a ter um JavaScript mais complexo, mais scripts de terceiros e estruturas DOM mais intrincadas, o que contribui para uma responsividade pior. No desktop, 97% das páginas atingem boas pontuações de INP, destacando a enorme disparidade de desempenho entre dispositivos móveis e desktops. A mediana do Tempo de Bloqueio Total (Total Blocking Time) em testes de laboratório é de 67ms em computadores, mas 1.209ms em dispositivos móveis.

Perguntas Frequentes

Guias Relacionados

Esta página central aborda os fundamentos da Interaction to Next Paint. Para obter orientação aprofundada sobre aspectos específicos da otimização da INP, explore estes artigos dedicados:

• <strong>Encontre e Corrija Problemas de INP</strong>: Uma metodologia de diagnóstico passo a passo usando o Search Console, dados de RUM e o Chrome DevTools para identificar exatamente quais interações estão causando suas piores pontuações de INP.
• <strong>INP: Atraso de Entrada</strong>: Aborda a primeira fase da INP. Aprenda como tarefas longas na thread principal bloqueiam o processamento de eventos e como minimizar o atraso de entrada usando o agendamento de tarefas (task scheduling), code splitting e web workers.
• <strong>INP: Tempo de Processamento</strong>: Aborda a segunda fase da INP. Aprenda a otimizar callbacks de manipuladores de eventos, a priorizar o código crítico, a adiar o trabalho não essencial e a usar os recursos de concorrência do React para reduzir o tempo de processamento.
• <strong>INP: Atraso de Apresentação</strong>: Aborda a terceira fase da INP. Entenda como o tamanho do DOM, a fragmentação do layout (layout thrashing) e a renderização no lado do cliente contribuem para atualizações visuais lentas e como reduzir o atraso de apresentação.

Você também pode achar úteis estes guias de otimização de PageSpeed para melhorar a INP:

• Melhore a INP: Abandone a Rolagem por JavaScript
• Async vs Defer: Estratégias de Carregamento de JavaScript
• 14 Métodos para Adiar JavaScript
• Widget de Chat com Core Web Vitals Perfeitos
• Correção: Evite Tamanho Excessivo do DOM