Otimize o atraso de renderização do elemento LCP

Do download à exibição: aprenda a melhorar o atraso de renderização do elemento do Largest Contentful Paint.

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

Este guia faz parte da seção Largest Contentful Paint (LCP) do nosso centro de recursos sobre Core Web Vitals. O Element Render Delay é a fase final na linha do tempo do LCP. Ele representa o intervalo entre o fim do download do recurso do LCP e o momento em que ele é visivelmente pintado na tela.

Otimize o Element Render Delay do LCP

Das quatro fases do 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 o Resource Load Duration. Elas veem a cascata de rede terminar e presumem que o trabalho acabou. Elas estão erradas.

O Element Render Delay é o tempo entre o fim do download do recurso do LCP e a pintura completa do elemento na tela do usuário. Isso não é um problema de rede; é um problema da main thread. Um alto atraso na renderização significa que o navegador tem a imagem ou fonte, mas está muito ocupado com outras tarefas para desenhá-la. Esse atraso é um imposto direto na sua pontuação de LCP. Às vezes, adiciona 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 do LCP (ex: um arquivo de imagem ou uma web font) chega ao navegador. Ele termina quando o elemento do LCP é visivelmente pintado na tela. É, de forma bastante literal, a etapa final.

Para elementos de LCP baseados em texto que usam uma fonte do sistema, esse atraso costuma ser zero, pois nenhum recurso externo é necessário. No entanto, para a grande maioria dos sites onde o elemento do LCP é uma imagem ou usa uma web font customizada, essa fase costuma ser o maior gargalo. O navegador gasta esse tempo em tarefas limitadas pela CPU: traduzir os bits baixados em pixels visíveis.

O 'porquê': uma linha de montagem travada

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 Critical Rendering Path. Pense nisso como a linha de montagem de uma fábrica:

  1. Construindo as plantas (DOM e CSSOM): O navegador faz o parse do HTML para construir o Document Object Model (DOM) e do CSS para construir o CSS Object Model (CSSOM). Essas 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. Essa etapa também é conhecida como "reflow".
  4. Colorindo os pixels (Paint): O navegador preenche os pixels de cada elemento. Ele considera texto, cores, imagens, bordas e sombras.
  5. Montando as camadas (Composite): A página é desenhada em diferentes camadas. Em seguida, elas 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 main thread. Se esse trabalhador estiver ocupado executando uma long task de JavaScript ou fazendo o parse de um arquivo CSS enorme, a linha de montagem para. A imagem do LCP pode ter chegado, mas ela fica parada na doca de carregamento. Ela aguarda a main thread ficar livre para processá-la e pintá-la.

Como identificar com precisão o Element Render Delay

O diagnóstico deste problema segue um processo rigoroso de duas etapas. Não pule a primeira etapa.

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

Etapa 2: Diagnosticar com o DevTools
Quando o RUM identificar as páginas com problema, use o painel Performance do Chrome DevTools para encontrar a causa. Nosso guia Diagnostique o LCP com o painel Performance do Chrome DevTools cobre a configuração de throttling e o fluxo de gravação passo a passo. Para o atraso de renderização especificamente:

  1. Grave o carregamento de uma página com o botão "Record and reload".
  2. Abra o insight "LCP breakdown" na barra lateral de Insights. Anote o valor do Element render delay.
  3. Agora, examine a trilha Main na timeline. Procure por long tasks (blocos amarelos com cantos vermelhos) que ocorrem entre o fim da requisição de rede do recurso do LCP e o marcador de tempo do 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 main thread bloqueada.

Causa: CSS render blocking

O Problema: Por padrão, o CSS é render blocking. O navegador não pintará nenhum pixel até baixar e fazer o parse de todos os arquivos CSS linkados no <head>. Uma folha de estilo grande e complexa pode ocupar a main thread por centenas de milissegundos. Isso atrasa o início das etapas de layout e paint. O problema se agrava quando os sites carregam múltiplas folhas de estilo. Cada uma exige uma requisição de rede e um ciclo de parse separados. Para estratégias detalhadas sobre como reduzir o payload do CSS, consulte nosso guia sobre como remover CSS não utilizado.

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

  • Remova o CSS não utilizado: Esta é a otimização de maior impacto isolada. 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 parse na main thread.
  • Busque folhas de estilo pequenas e cacheáveis: O tamanho ideal para um arquivo CSS é cerca de 10-15kB (comprimido). Menor do que isso e você corre o risco de dividir em requisições paralelas demais, cada uma com seu próprio overhead de conexão. Maior do 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, processada rapidamente e fica no cache do navegador para visitas repetidas.
  • Faça o inline de CSS apenas como último recurso: Inserir CSS crítico via inline em um bloco <style> elimina a requisição de rede no primeiro carregamento da página, mas tem um custo: o CSS inline não entra no cache do navegador. Cada visitante recorrente baixa tudo de novo em cada página. Para a maioria dos sites com usuários recorrentes, uma pequena folha de estilo externa com cache no navegador é a melhor escolha. O inline faz sentido apenas em landing pages com pouquíssimos visitantes recorrentes.

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

Causa: Long tasks de JavaScript

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

A Solução: Divida o trabalho.

  • Faça o yield para a main thread: As long tasks devem ser divididas em pedaços menores. Isso pode ser feito usando o yielding para devolver o controle ao navegador periodicamente. Use setTimeout(..., 0) ou a nova API scheduler.yield(). Isso permite que o navegador execute atualizações de renderização entre as tarefas.
  • Otimize e adie scripts de terceiros: Audite cada script de terceiros. Se 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 geralmente são render blocking por design.
  • Use requestAnimationFrame para atualizações visuais: Se o JavaScript precisar manipular o DOM durante o carregamento da página, envolva o trabalho no requestAnimationFrame. Isso agenda o trabalho para rodar pouco antes do próximo paint. Assim, o navegador tem a oportunidade de renderizar 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 do LCP na trilha Timings.
  3. Examine a trilha Main em busca de long tasks que ocorrem entre a conclusão da requisição de rede do recurso do LCP e o marcador do LCP.
  4. Clique nessas tarefas para ver a call stack no painel Summary. A call stack revelará o arquivo fonte e a função responsáveis pela long task.

Terceiros problemáticos mais comuns

Com base na minha experiência prática de consultoria, os scripts de terceiros mais comuns que causam o Element Render Delay incluem:

  • Ferramentas de teste A/B (Optimizely, VWO, AB Tasty): Elas geralmente bloqueiam a renderização de forma intencional para evitar a oscilação de conteúdo entre as variantes. Mover a decisão do experimento para o servidor (server-side testing) elimina esse problema por completo.
  • Tag managers com tags síncronas: Um tag manager configurado com tags síncronas (não async) pode injetar scripts render blocking. Audite seu contêiner para garantir que todas as tags disparem apenas após o DOM ready ou o window load.
  • 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 o LCP. Use uma implementação assíncrona que não bloqueie o Critical Rendering Path.
  • Widgets de chat: Scripts de live chat costumam executar código pesado de inicialização no carregamento da página. Adie o carregamento até que a página esteja interativa, ou carregue-os após uma interação do usuário (ex: clique).

Causa: Client-Side Rendering (CSR)

O Problema: No client-side rendering puro, o elemento do LCP frequentemente não existe no HTML inicial. O JavaScript deve rodar primeiro para construir o DOM e inserir o elemento do LCP. Só então o navegador pode finalmente renderizá-lo. Todo esse processo é um atraso de renderização gigante.

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

Causa: Conteúdo oculto por outro código

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

A Solução: Garanta a visibilidade imediata. Para o elemento do LCP, não use 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 teste A/B para rodarem de forma assíncrona ou garanta que elas tenham um impacto mínimo na visibilidade do elemento do LCP.

Causa: Tamanho excessivo do DOM

O Problema: Um DOM grande (com 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 paint precisa processar mais nós. Isso consome mais tempo na main thread. Mesmo que seu CSS e JavaScript estejam bem otimizados, um DOM inchado adiciona atraso de renderização pelo simples volume. Para estratégias detalhadas sobre como reduzir o tamanho do DOM, consulte nosso guia sobre como evitar um tamanho excessivo do DOM.

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

  • Simplifique a estrutura HTML: Remova wrappers desnecessários. Achate estruturas profundamente aninhadas. Use CSS Grid ou Flexbox no lugar de elementos <div> extras para o layout.
  • Virtualize listas longas: Para páginas com centenas de itens de lista (grades de produtos, tabelas de dados), use bibliotecas de virtualização. Elas renderizam apenas os itens visíveis no viewport no momento.
  • Faça o lazy-render do conteúdo abaixo da dobra: Use content-visibility: auto (abordado abaixo) para pular por completo a renderização das 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 main thread.

Desbloqueando o desempenho com content-visibility

A propriedade CSS content-visibility foi criada para páginas grandes. Ao definir 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 esse conteúdo. Ele só processará o conteúdo quando ele estiver prestes a entrar no viewport. Isso corta a carga de trabalho de renderização inicial. Assim, libera a main thread para pintar o elemento do LCP mais cedo.

A chave é combinar content-visibility: auto com contain-intrinsic-size. Isso fornece um tamanho de placeholder para o conteúdo oculto. Sem isso, o comportamento da barra de rolagem fica errático, pois o navegador não sabe qual é a altura das seções ocultas.

/* Aplique em 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 no desempenho: De acordo com uma postagem no blog do Chrome Developers, aplicar content-visibility: auto nas seções abaixo da dobra em uma página de blog reduziu o tempo de renderização em até 7 vezes. O navegador pula o trabalho de layout, paint e composite para essas seções por completo. Isso libera a main thread para focar no conteúdo acima da dobra, incluindo o elemento do LCP. O suporte dos navegadores cobre todos os modernos: Chromium, Firefox e Safari 18+.

Delegando o trabalho com Web Workers

Os Web Workers permitem que você rode o JavaScript em uma thread em segundo plano, totalmente fora da main thread. Qualquer computação pesada que rode em um Worker não pode bloquear a renderização. Este site, corewebvitals.io, usa um Web Worker para processar o seu analytics, e o benefício no desempenho é real: a main thread fica livre para pintar sem interrupções.

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

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

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

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

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

Impacto no mundo real

  • Caso 1: O gargalo do CSS render blocking: O DebugBear analisou um site onde um grande arquivo CSS criava um atraso de renderização visível. A imagem do LCP era baixada, mas o navegador ficava travado no parse do CSS. Ao simplesmente fazer o inline do CSS crítico, o navegador conseguiu pintar o conteúdo da página, incluindo o elemento do LCP, quase imediatamente após o parse do HTML. Isso eliminou de vez o atraso de renderização causado pela folha de estilo.
  • Caso 2: A penalidade do teste A/B: Um grande site de e-commerce descobriu que seu LCP estava sendo atrasado por um script de teste A/B síncrono. Mesmo que a imagem do LCP fosse baixada rapidamente, o script bloqueava a main thread enquanto decidia qual imagem de produto exibir. Mover o teste A/B para rodar após o carregamento inicial da página para os elementos não críticos melhorou de imediato o LCP deles em mais de 400ms. Todo esse tempo foi recuperado do Element Render Delay.

Checklist: Como eliminar o Element Render Delay

Um Element Render Delay alto indica uma main thread congestionada. As soluções envolvem limpar esse congestionamento para que o navegador possa pintar a página.

  1. Valide com RUM: Use dados de usuários reais para confirmar que o Element Render Delay é o seu principal gargalo do LCP antes de começar a otimizar.
  2. Remova o CSS não utilizado: Audite e remova regras de CSS que nunca são aplicadas. Essa é a otimização de CSS de maior impacto isolada. Use ferramentas como o PurgeCSS ou a aba Coverage no DevTools.
  3. Mantenha as folhas de estilo pequenas e cacheáveis: Busque em torno de 10-15kB (comprimido) por arquivo CSS. É pequeno o bastante para baixar rápido, e grande o bastante para evitar requisições paralelas em excesso. Deixe o navegador armazená-las no cache para os visitantes recorrentes.
  4. Divida as long tasks de JavaScript: Nenhum script isolado deve rodar por mais de 50ms. Faça o yield para a main thread para permitir atualizações de renderização.
  5. Audite e adie scripts de terceiros: Pergunte a si mesmo: cada script de terceiro justifica o seu lugar na página? Adie tudo o que não for essencial para o paint inicial.
  6. Use SSR ou SSG: Não dependa de JavaScript no lado do cliente para renderizar o seu elemento do LCP. Envie um HTML totalmente formado a partir do servidor.
  7. Garanta a visibilidade imediata do LCP: Remova quaisquer animações, scripts ou estilos que ocultem o elemento do LCP no carregamento da página.
  8. Use content-visibility: auto: Em páginas longas, diga ao navegador para pular a renderização do conteúdo fora da tela. Isso libera a main thread para a pintura acima da dobra.
  9. Reduza o tamanho do DOM: Achate o HTML profundamente aninhado, remova wrappers desnecessários e virtualize as listas longas. Isso reduz o custo das operações de layout e paint.

Próximos passos: continue otimizando o LCP

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

  • Identifique e corrija problemas de LCP: A metodologia de diagnóstico completa para encontrar e corrigir todos os problemas de LCP usando field data e ferramentas de laboratório.
  • Otimize a imagem do LCP: Escolha do formato de imagem, imagens responsivas, preloading e os erros mais comuns na otimização de imagens.
  • Resource Load Delay: Garanta que o navegador descubra o recurso do LCP o mais cedo possível. Esse costuma ser o maior gargalo isolado do 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 atraso de renderização do elemento LCP Core Web Vitals Otimize o atraso de renderização do elemento LCP