INP Presentation Delay: Tamanho do DOM, Trabalho de Layout e Otimização de Renderização

Problemas de Interaction to Next Paint (INP) causados por atraso de apresentação

Esta página faz parte da nossa série sobre Interaction to Next Paint (INP). O INP mede o tempo total desde a interação do usuário até a próxima atualização visual. O atraso de apresentação (presentation delay) é a terceira e última fase do INP, seguindo o atraso de entrada (input delay) e o tempo de processamento (processing time). Se você é novo no INP, leia nosso guia sobre como identificar e corrigir problemas de INP primeiro.

Neste artigo, focamos no atraso de apresentação: o que o causa, como ele afeta o Interaction to Next Paint e como otimizá-lo para melhorar suas pontuações de INP.

Resumindo: O Interaction to Next Paint (INP) mede quanto tempo leva para um usuário ver uma mudança visual em uma página após interagir com ela. Este INP pode ser dividido em 3 componentes: "input delay" (atraso de entrada), "processing time" (tempo de processamento) e "presentation delay" (atraso de apresentação).

O atraso de apresentação é o maior contribuinte para o INP total, representando aproximadamente 42% do tempo total do INP em média. Isso significa que otimizar seu pipeline de renderização e simplificar sua estrutura HTML pode impactar significativamente a pontuação de INP do seu site.

Atraso de apresentação (Presentation Delay): Já clicou em um botão e se perguntou por que demorou uma fração de segundo a mais para ver o resultado? Isso é o Interaction to Next Paint (INP) em ação. O atraso de apresentação é a última etapa do processo de interação, entrando em ação após o clique ter sido processado, mas antes de você ver quaisquer alterações visuais.

Entendendo o atraso de apresentação

A apresentação (presentation) é a fase final de uma interação. O atraso de apresentação (presentation delay) representa o tempo que leva para o navegador renderizar as atualizações visuais que seguem a interação. O atraso de apresentação começa quando os manipuladores de eventos da interação terminam de ser executados e termina quando o próximo quadro (contendo as alterações visuais) é pintado. O atraso de apresentação pode ser afetado por vários fatores, incluindo a complexidade do layout, o tamanho do DOM e a quantidade de trabalho de renderização necessária.

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

O atraso de apresentação e o INP

O atraso de apresentação é a última fase do INP. Em média, o atraso de apresentação representa cerca de 42% do tempo total do INP, tornando-se o maior contribuinte isolado para interações lentas.

No CoreDash, coletamos milhões de pontos de dados de Core Web Vitals a cada hora. Com base nesses dados, o atraso de apresentação é responsável por 42% do Interaction to Next Paint. Isso é mais do que o tempo de processamento (40%) e significativamente mais do que o atraso de entrada (18%). Apesar de ser o maior contribuinte, o atraso de apresentação costuma ser a fase mais difícil de otimizar porque envolve o pipeline de renderização do navegador, e não o código da sua aplicação.

Exemplo de atraso de apresentação: Imagine que você está no seu celular navegando em um site de e-commerce em busca de um novo par de sapatos. Você toca na imagem de um produto para ver mais detalhes. No entanto, seu celular é um pouco mais antigo e tem dificuldade em acompanhar. Você toca na imagem (Interação). O celular leva algum tempo para processar a solicitação e atualizar a tela (Tempo de Processamento). O site precisa renderizar a nova página com a imagem maior e os detalhes. Finalmente, leva um tempo considerável para os novos detalhes e a imagem do produto aparecerem na sua tela (Atraso de Apresentação). Esse atraso no INP pode ser frustrante para os usuários e é por isso que é importante corrigi-lo.

O que causa um alto atraso de apresentação?

O atraso de apresentação engloba todo o trabalho que o navegador faz depois que seus manipuladores de eventos terminam e antes que os pixels apareçam na tela. Isso inclui recálculo de estilo, computação de layout, pintura (painting) e composição (compositing). Vários fatores contribuem para um alto atraso de apresentação:

Tamanho grande do DOM

Um DOM grande ou profundamente aninhado é uma das causas mais comuns de alto atraso de apresentação. Toda vez que o navegador precisa atualizar o estado visual da página após uma interação, ele deve recalcular estilos, computar o layout e repintar os elementos afetados. O custo de cada uma dessas etapas aumenta de acordo com o número de nós do DOM que são afetados.

O Google recomenda manter seu DOM abaixo de 1.400 elementos, com uma profundidade máxima de 32 níveis e não mais que 60 elementos filhos por nó pai. Quando seu DOM excede esses limites, o navegador gasta significativamente mais tempo no recálculo de estilo e na computação de layout após cada interação.

Considere este cenário: um usuário clica em um botão que alterna uma classe CSS em um elemento contêiner. Se esse contêiner tiver 5.000 nós descendentes, o navegador precisará recalcular os estilos de possivelmente todos eles, mesmo que apenas alguns elementos realmente mudem visualmente. Esse recálculo de estilo acontece de forma síncrona antes da próxima pintura, aumentando diretamente o atraso de apresentação.

Para técnicas específicas para reduzir seu DOM, leia nosso guia sobre como corrigir o tamanho excessivo do DOM.

Trabalho excessivo de layout

O layout (também chamado de "reflow") é o processo no qual o navegador calcula a posição e as dimensões de cada elemento visível na página. Após uma interação que modifica o DOM ou altera as propriedades CSS que afetam a geometria (width, height, margin, padding, top, left), o navegador deve realizar o layout antes de poder pintar o quadro atualizado.

Dois padrões são particularmente prejudiciais para o atraso de apresentação:

Layout síncrono forçado (Forced synchronous layout) ocorre quando o JavaScript lê uma propriedade de layout (como offsetHeight ou getBoundingClientRect()) após fazer uma alteração no DOM que invalida o layout. O navegador é forçado a realizar o layout de forma síncrona, dentro do seu manipulador de eventos, para retornar um valor preciso. Esse trabalho de layout então se torna parte do tempo de processamento, mas qualquer layout subsequente acionado por mais alterações no DOM torna-se parte do atraso de apresentação.

Layout thrashing é o padrão repetido de escrever no DOM e depois ler propriedades de layout em um loop. Cada leitura força o navegador a recalcular o layout, e cada gravação invalida o layout novamente. Isso pode causar dezenas ou até centenas de cálculos de layout desnecessários por interação. Aqui está um exemplo de layout thrashing e como corrigi-lo:

// RUIM: Layout thrashing dentro de um loop
function resizeItems() {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    // Ler (força o layout)
    const parentWidth = item.parentElement.offsetWidth;
    // Escrever (invalida o layout)
    item.style.width = parentWidth + 'px';
  });
}

// BOM: Leituras em lote, depois gravações em lote
function resizeItems() {
  const items = document.querySelectorAll('.item');
  // Ler todos os valores primeiro
  const widths = Array.from(items).map(
    item => item.parentElement.offsetWidth
  );
  // Depois escrever todos os valores
  items.forEach((item, i) => {
    item.style.width = widths[i] + 'px';
  });
}

Renderização no lado do cliente em Single Page Applications (SPAs)

A renderização de HTML no lado do cliente pode impactar significativamente o atraso de apresentação, particularmente em Single Page Applications (SPAs). Quando a interação de um usuário aciona uma mudança de rota ou uma grande atualização de interface do usuário, o framework da SPA deve:

1. Executar o algoritmo de diffing do virtual DOM para determinar o que mudou
2. Aplicar as mutações resultantes do DOM ao DOM real
3. Acionar o recálculo de estilo e o layout para todos os elementos afetados
4. Pintar o quadro atualizado

Em aplicações React, o processo de reconciliação do virtual DOM faz parte do tempo de processamento, mas as mutações do DOM resultantes e seu custo de renderização recaem no atraso de apresentação. Quanto mais nós do DOM a sua árvore de componentes produzir, mais cara será a reconciliação e o trabalho de renderização subsequente.

Para mitigar isso em aplicações React e Next.js:

• Use React.memo() para evitar novas renderizações desnecessárias de componentes filhos que recebem as mesmas props.
• Use useDeferredValue() para valores que acionam renderizações caras, permitindo que o React priorize atualizações mais urgentes.
• Mantenha as árvores de componentes rasas. Hierarquias de componentes profundamente aninhadas produzem um DOM profundamente aninhado, o que aumenta o custo da reconciliação e da renderização no navegador.
• Use bibliotecas de virtualização (como react-window ou @tanstack/react-virtual) para listas longas, de modo que o DOM contenha apenas os itens visíveis.

Reduzindo o atraso de apresentação

Agora que entendemos as causas, aqui estão as estratégias mais eficazes para minimizar o atraso de apresentação.

Minimizar o tamanho do DOM

A otimização mais impactante para o atraso de apresentação é manter o seu DOM pequeno. Aqui estão algumas técnicas práticas:

• Remova elementos HTML não utilizados, especialmente divs envoltórias (wrappers) profundamente aninhadas.
• Use a virtualização de listas para listas longas (renderize apenas itens visíveis mais um pequeno buffer).
• Achate estruturas profundamente aninhadas onde for possível.
• Use CSS Grid e Flexbox em vez de divs aninhadas para o layout.

// Virtualizar listas longas para reduzir o tamanho do DOM
// Antes: 10.000 itens no DOM
<ul>
  {allItems.map(item => <li key={item.id}>{item.name}</li>)}
</ul>

// Depois: apenas itens visíveis no DOM (usando react-window)
import { FixedSizeList } from 'react-window';

<FixedSizeList
  height={600}
  itemCount={allItems.length}
  itemSize={50}
  width="100%"
>
  {({ index, style }) => (
    <div style={style}>{allItems[index].name}</div>
  )}
</FixedSizeList>

Use content-visibility para renderização preguiçosa (lazy-render) de conteúdo fora da tela

A propriedade CSS content-visibility diz ao navegador para pular a renderização do conteúdo fora da tela até que o usuário role a página para perto dele. Isso reduz a quantidade de trabalho de renderização durante as interações, limitando o escopo do recálculo de estilo e do layout à porção visível da página.

/* Aplicar content-visibility às seções abaixo da dobra (below the fold) */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* Aplicar a itens individuais em listas longas */
.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

A propriedade contain-intrinsic-size fornece uma altura estimada para que o navegador possa calcular o tamanho da barra de rolagem corretamente sem renderizar o conteúdo. Isso evita mudanças de layout (layout shifts) quando o usuário rola a página e o conteúdo se torna visível.

Para mais estratégias de otimização de CSS que reduzem o custo de renderização, consulte nosso guia sobre como remover CSS não utilizado.

Minimizar o trabalho de layout acionado por interações

Ao projetar interações, prefira propriedades CSS que não acionam o layout. Propriedades como transform e opacity podem ser manipuladas pelo compositor da GPU sem acionar layout ou pintura. Em vez de animar top, left, width ou height, use transform: translate() e transform: scale().

Use a propriedade CSS will-change para indicar ao navegador que um elemento será animado. Isso permite que o navegador crie uma camada de compositor separada para o elemento, isolando sua renderização do resto da página:

/* Promover elementos para sua própria camada de compositor */
.animated-element {
  will-change: transform, opacity;
}

/* Alternar visibilidade com opacity em vez de display */
.modal {
  opacity: 0;
  pointer-events: none;
  transform: translateY(10px);
  transition: opacity 0.2s, transform 0.2s;
}

.modal.active {
  opacity: 1;
  pointer-events: auto;
  transform: translateY(0);
}

Identificando longos atrasos de apresentação

Para identificar longos atrasos de apresentação, você pode usar o perfilador de desempenho do Chrome. Abra o DevTools (Ctrl+Shift+I), navegue até a aba Performance, clique em gravar (record) e interaja com a página.

Em seguida, você pode analisar a linha do tempo de uma interação e visualizar as diferentes fases, incluindo o atraso de apresentação. Ao examinar as atualizações de renderização que ocorrem após o término dos manipuladores de eventos, você pode identificar quaisquer gargalos que contribuam para um longo atraso de apresentação. Procure por entradas grandes de "Recalculate Style" (Recalcular Estilo), "Layout" e "Paint" (Pintura) na linha do tempo. Elas representam o trabalho que o navegador faz durante a fase de atraso de apresentação.

Identificando o atraso de apresentação com dados de RUM

Medindo o atraso de apresentação com Long Animation Frames (LoAF)

A API Long Animation Frames (LoAF) fornece informações detalhadas sobre as causas dos atrasos de renderização, incluindo aqueles que ocorrem durante as interações do usuário. A API apresenta dados de tempo que ajudam a separar o tempo de processamento do atraso de apresentação e a identificar quais scripts contribuem para os gargalos de renderização.

As principais propriedades da API LoAF para entender o atraso de apresentação são:

• renderStart: quando o navegador iniciou a fase de renderização (recálculo de estilo, layout, pintura)
• styleAndLayoutStart: quando a computação de estilo e layout começou
• duration: duração total do frame de animação longo (long animation frame)
• blockingDuration: quanto do quadro foi bloqueado por scripts

A diferença entre o fim da execução do script e o fim do quadro representa o custo puro de renderização, que é o atraso de apresentação. Veja como observar e registrar esses dados:

// Medir o atraso de apresentação usando a API LoAF
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) {
      const scriptEnd = Math.max(
        ...entry.scripts.map(s => s.startTime + s.duration)
      );
      const presentationDelay = (
        entry.startTime + entry.duration
      ) - Math.max(scriptEnd, entry.renderStart);

      console.log('Presentation delay breakdown:', {
        totalDuration: entry.duration,
        renderStart: entry.renderStart,
        styleAndLayoutStart: entry.styleAndLayoutStart,
        estimatedPresentationDelay: presentationDelay,
        scriptCount: entry.scripts.length
      });
    }
  }
});

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

Ferramentas de RUM como o CoreDash integram dados da API LoAF e fornecem informações adicionais sobre os long animation frames, como dados de atribuição de script. Essas ferramentas ajudam a entender quais scripts e alterações no DOM estão contribuindo para os atrasos de renderização, para que você possa otimizar sua base de código visando uma melhor responsividade.

Explore as outras fases do INP

O atraso de apresentação é apenas uma parte do Interaction to Next Paint. Para otimizar totalmente suas pontuações de INP, você também deve abordar as outras duas fases:

• Input Delay: Minimize o tempo de espera antes que os manipuladores de eventos comecem a ser executados. O atraso de entrada é responsável por aproximadamente 18% do tempo total do INP.
• Processing Time: Otimize a execução do manipulador de eventos, que é responsável por aproximadamente 40% do tempo total do INP.

Para um fluxo de trabalho de diagnóstico completo, consulte nosso guia sobre como encontrar e corrigir problemas de INP. Para estratégias adicionais de otimização de renderização, explore nossos guias sobre como corrigir o tamanho excessivo do DOM e remover CSS não utilizado. Retorne à página principal de INP para a visão geral completa.