Otimize o Element Render Delay da LCP

Do download à exibição: aprenda como melhorar a parte do Element Render Delay da Largest Contentful Paint.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-03
  1. Pt br
  2. Core Web Vitals
  3. Largest contentful paint
  4. Element render delay

Este guia faz parte da seção de Largest Contentful Paint (LCP) do nosso centro de recursos das Core Web Vitals. O Element Render Delay é a fase final na linha do tempo da LCP, representando o intervalo entre quando o recurso da LCP termina de ser baixado e quando é visivelmente pintado na tela.

Otimize o Element Render Delay da LCP

Das quatro fases da LCP, o Element Render Delay é a mais mal compreendida. As equipes otimizam o TTFB, eliminam o Resource Load Delay e comprimem os ativos para encurtar a Resource Load Duration. Eles veem a cascata de rede terminar e presumem que o trabalho está concluído. Estão enganados.

O Element Render Delay é o tempo desde quando o recurso da LCP termina o download até quando o elemento é totalmente pintado na tela do usuário. Este não é um problema de rede; é um problema da thread principal. Um atraso de renderização alto significa que o navegador tem a imagem ou fonte, mas está muito ocupado com outras tarefas para realmente desenhá-la. Esse atraso é uma taxa direta na sua pontuação da LCP, às vezes adicionando 200ms ou mais após a conclusão de todas as requisições de rede.

Definição Precisa: O Problema da Última Milha

O Element Render Delay começa no momento em que o último byte do recurso da LCP (ex.: um arquivo de imagem ou uma fonte da web) chega ao navegador. Ele termina quando o elemento da LCP é visivelmente pintado na tela. É, de forma bastante literal, a etapa final.

Para elementos textuais da LCP que usam uma fonte do sistema, esse atraso frequentemente é zero, pois nenhum recurso externo é necessário. No entanto, para a vasta maioria dos sites onde o elemento da LCP é uma imagem ou utiliza uma fonte da web customizada, essa fase é frequentemente o maior gargalo. O navegador gasta esse tempo em tarefas limitadas pela CPU: traduzindo os bits baixados em pixels visíveis.

O 'Porquê': Uma Linha de Montagem Congestionada

Para corrigir o atraso de renderização, você deve entender como um navegador desenha uma página. É um processo de várias etapas frequentemente chamado de Caminho Crítico de Renderização. Pense nisso como a linha de montagem de uma fábrica:

  1. Construindo as Plantas (DOM e CSSOM): O navegador analisa o HTML para construir o Document Object Model (DOM) e o CSS para construir o CSS Object Model (CSSOM). Estas são as plantas para o conteúdo da página e seu estilo.
  2. Combinando as Plantas (Render Tree): O DOM e o CSSOM são combinados em uma Render Tree, que contém apenas os nós necessários para renderizar a página. Elementos como <head> ou aqueles com display: none; são omitidos.
  3. Calculando a Geometria (Layout): O navegador calcula o tamanho exato e a posição de cada elemento na render tree. Esta etapa também é conhecida como "reflow".
  4. Colorindo os Pixels (Paint): O navegador preenche os pixels de cada elemento, considerando texto, cores, imagens, bordas e sombras.
  5. Montando as Camadas (Composite): A página é desenhada em diferentes camadas, que então são montadas na ordem correta para criar a imagem final da tela.

O Element Render Delay é o tempo consumido por essas etapas finais: Layout, Paint e Composite. Toda essa linha de montagem é operada por um único trabalhador: a thread principal. Se esse trabalhador estiver ocupado executando uma longa tarefa de JavaScript ou analisando um arquivo CSS massivo, a linha de montagem para. A imagem da LCP pode ter chegado, mas está aguardando na área de carregamento até que a thread principal fique livre para processá-la e pintá-la.

Como Identificar o Element Render Delay

Diagnosticar esse problema segue um processo estrito de duas etapas. Não pule a primeira etapa.

Etapa 1: Valide com Dados de Campo (RUM)
Antes de abrir o DevTools, você deve confirmar que o Element Render Delay é um problema real para seus usuários reais. Uma ferramenta de Real User Monitoring (RUM) de nível profissional como a minha, o CoreDash, é essencial. Ela dividirá a LCP do seu site em suas quatro subpartes. Se os seus dados RUM mostrarem um Element Render Delay significativo no 75º percentil, você tem um problema validado e de alto impacto para resolver.

Etapa 2: Diagnostique com o DevTools
Uma vez que o RUM identificou as páginas com problema, use o painel Performance do Chrome DevTools para dissecar a causa.

  1. Vá para a aba Performance e ative a caixa de seleção "Web Vitals".
  2. Clique no botão "Record and reload page".
  3. Na trilha "Timings", clique no marcador LCP. A aba "Summary" abaixo mostrará a duração precisa para cada uma das quatro fases da LCP. Anote o valor do Element render delay.
  4. Agora, examine a trilha Main na linha do tempo. Procure por long tasks (blocos amarelos com cantos vermelhos) que ocorrem entre o fim da requisição de rede do recurso da LCP e o marcador de tempo da LCP. Essas tarefas são a causa direta do seu atraso. Passe o mouse sobre elas para identificar os scripts responsáveis.

Causas Comuns e Soluções de Alto Impacto

Um Element Render Delay alto é quase sempre causado por uma thread principal bloqueada.

Causa: CSS Bloqueador de Renderização

O Problema: Por padrão, o CSS bloqueia a renderização. O navegador não pintará nenhum pixel até que tenha baixado e analisado todos os arquivos CSS vinculados no <head>. Uma folha de estilo grande e complexa pode ocupar a thread principal por centenas de milissegundos, atrasando o início das etapas de layout e paint. Isso se agrava quando os sites carregam várias folhas de estilo, cada uma exigindo uma requisição de rede e ciclo de análise separados. Para estratégias detalhadas sobre a redução do payload de CSS, consulte o nosso guia sobre remover CSS não utilizado.

A Solução: Mantenha o seu CSS pequeno, limpo e armazenável em cache.

  • Remova CSS Não Utilizado: Esta é a otimização de maior impacto. Em sites grandes, o CSS não utilizado pode representar 70% ou mais do tamanho total da folha de estilo. Ferramentas como o PurgeCSS podem escanear seu HTML e JavaScript para identificar seletores não utilizados. Remover regras mortas reduz tanto o tempo de download quanto o tempo de análise na thread principal.
  • Busque folhas de estilo pequenas e armazenáveis em cache: O ponto ideal para um arquivo CSS é de aproximadamente 10-15kB (comprimido). Menor que isso e você corre o risco de dividir em muitas requisições paralelas, cada uma com sua própria sobrecarga de conexão. Maior que isso e o tempo de bloqueio cresce, especialmente em redes móveis lentas. Uma única folha de estilo bem estruturada nessa faixa é baixada rapidamente, analisada rapidamente e armazenada em cache pelo navegador para visitas repetidas.
  • Apenas inclua CSS inline como último recurso: A inclusão de CSS crítico inline em um bloco <style> elimina a requisição de rede para o primeiro carregamento de página, mas tem um custo: o CSS inline não pode ser armazenado em cache pelo navegador. Todo visitante recorrente faz o download novamente a cada página. Para a maioria dos sites com usuários que retornam, uma pequena folha de estilo externa que o navegador armazena em cache é a melhor escolha. A inclusão inline faz sentido apenas para landing pages com pouquíssimos visitantes recorrentes.

Quantificando o impacto do CSS: Para medir o quanto o seu CSS está contribuindo para o atraso de renderização, abra a aba Coverage do Chrome DevTools (Ctrl+Shift+P, depois digite "Coverage"). Carregue a página e observe a porcentagem de bytes não utilizados em seus arquivos CSS. Uma alta porcentagem de CSS não utilizado é um sinal claro de que a limpeza reduzirá o Element Render Delay.

Causa: Long Tasks de JavaScript

O Problema: Esta é a causa mais comum. A execução pesada de JavaScript, seja de frameworks, scripts de analytics, ferramentas de teste A/B ou código mal otimizado, pode monopolizar a thread principal. Uma única tarefa de longa duração pode bloquear a renderização por centenas de milissegundos, adicionando diretamente ao Element Render Delay. O Google define uma long task como qualquer tarefa que leve mais de 50ms, e tarefas que excedem 200ms são consideradas criticamente longas. Para uma coleção completa de estratégias de adiamento de JavaScript, veja o nosso artigo sobre 14 métodos para adiar o JavaScript.

A Solução: Quebre o trabalho.

  • Faça o yield para a Thread Principal: Long tasks devem ser divididas em pedaços menores. Isso pode ser feito fazendo o yield do controle de volta ao navegador periodicamente usando setTimeout(..., 0) ou a API mais recente scheduler.yield(). Isso permite que o navegador realize atualizações de renderização entre as tarefas.
  • Otimize e Adie Terceiros: Faça uma auditoria em todos os scripts de terceiros. Se eles não forem essenciais para a renderização inicial, carregue-os com o atributo defer ou injete-os após o carregamento da página. Scripts para testes A/B são particularmente problemáticos, pois frequentemente bloqueiam a renderização intencionalmente.
  • Use requestAnimationFrame para Atualizações Visuais: Se o JavaScript deve realizar manipulações no DOM durante o carregamento da página, envolva o trabalho no requestAnimationFrame. Isso programa o trabalho para rodar pouco antes do próximo paint, garantindo que o navegador tenha a oportunidade de renderizar os quadros entre as operações de JavaScript.

Identificando Long Tasks no DevTools

No painel Performance do Chrome DevTools, as long tasks aparecem como blocos amarelos com um triângulo vermelho no canto superior direito na trilha "Main". Para identificar quais scripts são responsáveis:

  1. Grave o carregamento de uma página no painel Performance.
  2. Localize o marcador da LCP na trilha Timings.
  3. Examine a trilha Main por long tasks que ocorrem entre a conclusão da requisição de rede do recurso da LCP e o marcador da LCP.
  4. Clique nestas tarefas para ver a pilha de chamadas (call stack) no painel Summary. A pilha de chamadas revelará o arquivo fonte e a função responsáveis pela long task.

Infratores Comuns de Terceiros

Com base em experiência de consultoria no mundo real, os scripts de terceiros mais comuns que causam Element Render Delay incluem:

  • Ferramentas de teste A/B (Optimizely, VWO, AB Tasty): Estas frequentemente bloqueiam a renderização intencionalmente para evitar a cintilação (flicker) de conteúdo entre as variantes. Mover a decisão do experimento para o lado do servidor (testes do lado do servidor) elimina totalmente esse problema.
  • Gerenciadores de tags com tags síncronas: Um gerenciador de tags configurado com tags síncronas (não-async) pode injetar scripts que bloqueiam a renderização. Faça uma auditoria no seu contêiner para garantir que todas as tags estejam configuradas para disparar após o DOM estar pronto ou a janela ser carregada.
  • Plataformas de gestão de consentimento: Banners de consentimento de cookies que bloqueiam a renderização até que uma decisão seja tomada podem atrasar a LCP. Use uma implementação async que não bloqueie o caminho crítico de renderização.
  • Widgets de chat: Scripts de live chat frequentemente executam código pesado de inicialização no carregamento da página. Adie o carregamento para depois que a página estiver interativa, ou os carregue numa interação do usuário (ex.: clique).

Causa: Client-Side Rendering (CSR)

O Problema: Com a renderização puramente do lado do cliente, o elemento da LCP frequentemente não existe no HTML inicial. O JavaScript deve rodar primeiro para construir o DOM, inserir o elemento da LCP, e então o navegador pode finalmente renderizá-lo. Todo esse processo é um grande atraso de renderização.

A Solução: Renderize no servidor. Não há outra forma. Use Server-Side Rendering (SSR) ou Static Site Generation (SSG) para garantir que o elemento da LCP esteja presente no documento HTML inicial enviado pelo servidor. Isso elimina completamente a fase de renderização orientada a JavaScript como uma fonte de atraso.

Causa: Conteúdo Oculto por Outro Código

O Problema: Às vezes, o elemento da LCP está no DOM, mas é ocultado por CSS (ex.: opacity: 0) ou por um script, como uma animação de "revelar ao rolar" ou uma ferramenta de teste A/B que ainda está decidindo qual variante mostrar. O elemento é baixado e está pronto, mas não pode ser pintado porque ainda não está visível.

A Solução: Garanta a visibilidade imediata. Para o elemento da LCP, não utilize animações de entrada ou qualquer lógica que o oculte no carregamento inicial. O elemento deve estar visível no DOM e estilizado para ser visível desde o primeiro paint. Configure as ferramentas de testes A/B para rodarem assincronamente ou garanta que elas tenham um impacto mínimo na visibilidade do elemento da LCP.

Causa: Tamanho Excessivo do DOM

O Problema: Um DOM grande (mais de 1.500 nós) aumenta o custo de cada operação de renderização. Cada cálculo de layout, recálculo de estilo e operação de pintura deve processar mais nós, o que leva mais tempo na thread principal. Mesmo que o seu CSS e JavaScript estejam bem otimizados, um DOM inchado adiciona atraso na renderização pelo simples volume. Para estratégias detalhadas sobre como reduzir o tamanho do DOM, consulte nosso guia sobre evitar um tamanho excessivo do DOM.

A Solução: Reduza o número de nós do DOM que participam na renderização inicial.

  • Simplifique a estrutura HTML: Remova elementos envoltórios (wrappers) desnecessários. Achate as estruturas profundamente aninhadas. Use CSS Grid ou Flexbox no lugar de elementos <div> extras para layout.
  • Virtualize listas longas: Para páginas com centenas de itens de lista (grades de produtos, tabelas de dados), use bibliotecas de virtualização que apenas renderizam os itens visíveis no momento no viewport.
  • Atrase a renderização de conteúdo abaixo da dobra: Use content-visibility: auto (abordado abaixo) para pular inteiramente a renderização de seções fora da tela.

Táticas Avançadas: Assumindo o Controle Total da Renderização

Aplicações complexas precisam de mais controle sobre a thread principal.

Desbloqueando a Performance com content-visibility

A propriedade CSS content-visibility foi feita para páginas grandes. Ao configurar content-visibility: auto; em seções da sua página que estão abaixo da dobra, você diz ao navegador que ele pode pular o trabalho de layout, paint e composite para aquele conteúdo até que ele esteja prestes a entrar no viewport. Isso corta a carga de trabalho de renderização inicial, liberando a thread principal para pintar o elemento da LCP mais cedo.

A chave é combinar content-visibility: auto com contain-intrinsic-size, que fornece um tamanho de espaço reservado para o conteúdo oculto. Sem isso, o comportamento da barra de rolagem torna-se instável porque o navegador não sabe qual é a altura das seções ocultas.

/* Aplique às seções abaixo da dobra */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* Altura estimada da seção */
}

/* Exemplo: Uma página de artigo longo */
.article-comments {
  content-visibility: auto;
  contain-intrinsic-size: auto 800px;
}

.related-products {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

.site-footer {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;
}

Impacto na performance: De acordo com um post do blog dos Desenvolvedores do Chrome, aplicar content-visibility: auto a seções abaixo da dobra de uma página de blog reduziu o tempo de renderização em até 7x. O navegador pula o trabalho de layout, paint e composite para essas seções inteiramente, liberando a thread principal para se focar no conteúdo acima da dobra, incluindo o elemento da LCP. O suporte dos navegadores cobre todos os navegadores modernos: Chromium, Firefox e Safari 18+.

Descarregando Trabalho com Web Workers

Os Web Workers permitem que você execute JavaScript em uma thread em segundo plano, completamente fora da thread principal. Qualquer computação pesada que roda em um Worker não pode bloquear a renderização. Este site, corewebvitals.io, usa um Web Worker para o seu processamento de analytics, e o benefício de performance é real: a thread principal permanece livre para pintar sem interrupções.

Dito isso, Web Workers não são um padrão comum na maioria dos sites. Eles requerem um arquivo JavaScript separado, comunicação via postMessage, e não possuem acesso ao DOM. A maioria das plataformas de CMS e construtores de sites não oferecem suporte embutido para eles, tornando a implementação difícil sem desenvolvimento customizado. Se você tem a capacidade técnica de usá-los, eles são uma das maneiras mais efetivas de manter a thread principal desobstruída. Mas para a maioria das equipes, as outras otimizações nesta página terão um impacto prático maior.

// main.js: Crie um worker e envie os dados para processamento
const worker = new Worker('/js/analytics-worker.js');

// Descarregue o processamento pesado de analytics para a thread do worker
worker.postMessage({
  type: 'process-events',
  events: collectedEvents
});

// Receba os resultados sem bloquear a thread principal
worker.onmessage = (event) => {
  console.log('Analytics processado:', event.data.summary);
};

// analytics-worker.js: Roda numa thread em segundo plano
self.onmessage = (event) => {
  if (event.data.type === 'process-events') {
    // A computação pesada acontece aqui, fora da thread principal
    const summary = processEvents(event.data.events);
    self.postMessage({ summary });
  }
};

Impacto no Mundo Real

  • Caso 1: O Gargalo de CSS Bloqueador de Renderização: O DebugBear analisou um site onde um grande arquivo CSS criava um atraso perceptível de renderização. A imagem da LCP foi baixada, mas o navegador estava travado analisando o CSS. Ao simplesmente incluir o CSS crítico de forma inline, o navegador pôde pintar o conteúdo da página, incluindo o elemento da LCP, quase imediatamente após o HTML ter sido analisado, efetivamente eliminando o atraso de renderização causado pela folha de estilo.
  • Caso 2: A Penalidade dos Testes A/B: Um grande site de e-commerce descobriu que a sua LCP estava sendo retida por um script síncrono de teste A/B. Mesmo que a imagem da LCP tivesse sido baixada rapidamente, o script bloqueava a thread principal enquanto determinava qual imagem de produto exibir. Mover o teste A/B para rodar após o carregamento inicial da página para elementos não-críticos melhorou a sua LCP imediatamente em mais de 400ms, os quais foram recuperados inteiramente do Element Render Delay.

Lista de Verificação: Como Eliminar o Element Render Delay

Um Element Render Delay alto indica uma thread principal congestionada. As soluções envolvem limpar esse congestionamento para que o navegador consiga pintar.

  1. Valide com RUM: Use dados de usuários reais para confirmar que o Element Render Delay é o seu gargalo principal de LCP antes de começar a otimizar.
  2. Remova CSS Não Utilizado: Faça uma auditoria e elimine as regras de CSS que nunca são aplicadas. Esta é a otimização de CSS de maior impacto. Use ferramentas como o PurgeCSS ou a aba Coverage no DevTools.
  3. Mantenha as folhas de estilo pequenas e armazenáveis em cache: Busque em torno de 10-15kB (comprimido) por arquivo CSS. Pequeno o suficiente para baixar rápido, grande o suficiente para evitar requisições paralelas excessivas. Deixe o navegador armazená-los em cache para visitantes recorrentes.
  4. Quebre Long Tasks de JavaScript: Nenhum script único deve rodar por mais de 50ms. Faça o yield para a thread principal para permitir atualizações de renderização.
  5. Faça uma Auditoria e Adie Scripts de Terceiros: Pergunte a si mesmo: cada script de terceiros faz por merecer o seu lugar na página? Adie qualquer coisa que não seja essencial para a pintura inicial.
  6. Use SSR ou SSG: Não dependa de JavaScript no lado do cliente para renderizar o seu elemento da LCP. Envie o HTML totalmente formado pelo servidor.
  7. Garanta Visibilidade Imediata da LCP: Remova quaisquer animações, scripts ou estilos que ocultem o elemento da LCP no carregamento da página.
  8. Use content-visibility: auto: Para páginas longas, diga ao navegador para pular a renderização do conteúdo fora da tela para liberar a thread principal para a pintura acima da dobra.
  9. Reduza o Tamanho do DOM: Achate HTML profundamente aninhado, remova wrappers desnecessários e virtualize listas longas para reduzir o custo de operações de layout e paint.

Próximos Passos: Continue Otimizando a LCP

O Element Render Delay é a fase final. Para abranger todas as quatro, continue com:

  • Corrija & Identifique Problemas da LCP: A metodologia de diagnóstico completa para encontrar e corrigir todos os problemas da LCP usando dados de campo e ferramentas de laboratório.
  • Otimize a Imagem da LCP: Seleção de formato da imagem, imagens responsivas, pré-carregamento e os erros comuns de otimização de imagens.
  • Resource Load Delay: Garanta que o navegador descubra o recurso da LCP o mais cedo possível. Este é frequentemente o maior gargalo único da LCP.
  • Resource Load Duration: Reduza o tempo de download por meio de compressão, formatos modernos, configuração de CDN e otimização de rede.

Seu site vai passar nos Core Web Vitals.

Mais de 500 mil páginas para grandes publishers europeus e plataformas de e-commerce. Escrevo os fixes e confirmo tudo com dados de campo.

Como eu trabalho
Otimize o Element Render Delay da LCPCore Web Vitals Otimize o Element Render Delay da LCP