Otimize o atraso de renderização do elemento LCP.

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

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-07-10
  1. Pt
  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 atraso de renderização do elemento é a fase final na linha do tempo do LCP. Ele representa a lacuna entre o término do download do recurso do LCP e o momento em que ele é visivelmente pintado na tela.

Otimize o atraso de renderização do elemento do LCP

Das quatro fases do LCP, o atraso de renderização do elemento é a mais mal compreendida. As equipes otimizam o TTFB, eliminam o atraso no carregamento do recurso e comprimem os ativos para encurtar a duração do carregamento do recurso. Elas veem a cascata de rede terminar e presumem que o trabalho acabou. Elas estão erradas.

O atraso de renderização do elemento é o tempo desde quando o recurso do LCP termina de ser baixado até quando o elemento é totalmente pintado na tela do usuário. Este não é um problema de rede; é um problema de main thread. Um alto atraso de renderização significa que o navegador tem a imagem ou a fonte, mas está muito ocupado com outras tarefas para realmente desenhá-la. Esse atraso penaliza diretamente sua pontuação de LCP. Às vezes, ele adiciona 200 ms ou mais depois que todas as requisições de rede estão concluídas.

Definição precisa: O problema da última milha

O atraso de renderização do elemento começa no momento em que o último byte do recurso do LCP (por exemplo, um arquivo de imagem ou uma web font) chega ao navegador. Ele termina quando o elemento do LCP é visivelmente pintado na tela. É, literalmente, a etapa final.

Para elementos do LCP baseados em texto que usam uma fonte do sistema, esse atraso geralmente é 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 personalizada, essa fase geralmente é 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, muitas vezes chamado de Caminho Crítico de Renderização. Pense nisso como a linha de montagem de uma fábrica:

  1. Construindo os projetos (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). Esses são os projetos para o conteúdo da página e sua estilização.
  2. Combinando projetos (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 árvore de renderização. Essa etapa também é conhecida como "reflow".
  4. Colorindo os pixels (Paint): O navegador preenche os pixels para cada elemento, considerando texto, cores, imagens, bordas e sombras.
  5. Montando 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 atraso de renderização do elemento é 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 analisando um arquivo CSS massivo, a linha de montagem para. A imagem do LCP pode ter chegado, mas ela está sentada na doca de carregamento esperando a main thread ficar livre para processá-la e pintá-la.

Como identificar com precisão o atraso de renderização do elemento

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

Etapa 1: Valide com field data (RUM)
Antes de abrir o DevTools, você deve confirmar que o atraso de renderização do elemento é um problema real para os seus usuários. Uma ferramenta de Real User Monitoring (RUM) de nível profissional como a minha, o CoreDash, é essencial. Ela vai dividir o LCP do seu site em suas quatro subpartes. Se os seus dados de RUM mostrarem um atraso de renderização do elemento 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 de Performance do Chrome DevTools para encontrar a causa. Nosso guia Diagnostique o LCP com o painel de Performance do Chrome DevTools cobre a configuração de limitação e o fluxo de trabalho de gravação passo a passo. Para o atraso de renderização especificamente:

  1. Grave um carregamento de página com o botão "Record and reload".
  2. Abra o insight "LCP breakdown" na barra lateral Insights e anote o valor para o atraso de renderização do elemento.
  3. Agora examine a trilha Main na linha do tempo. Procure por long tasks (blocos amarelos com cantos vermelhos) que ocorram 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 alto atraso de renderização do elemento 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é ter baixado e analisado todos os arquivos CSS vinculados no <head>. Uma folha de estilos grande e complexa pode ocupar a main thread por centenas de milissegundos, atrasando o início das etapas de layout e paint. Isso se agrava quando os sites carregam múltiplas folhas de estilos, cada uma exigindo uma requisição de rede e um ciclo de análise separados. Para estratégias detalhadas sobre como reduzir o payload do CSS, veja nosso guia sobre como remover CSS não utilizado.

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

  • Remova o CSS não utilizado: Esta é a otimização de maior impacto isolado. Em sites grandes, o CSS não utilizado pode representar 70% ou mais do tamanho total da folha de estilos. 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 main thread.
  • Mire em folhas de estilos pequenas e armazenáveis em cache: O ponto ideal para um arquivo CSS é de aproximadamente 10 a 15 kB (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 estilos bem estruturada nessa faixa é baixada rapidamente, analisada rapidamente e armazenada em cache pelo navegador para visitas repetidas.
  • Só faça o inline do CSS como último recurso: Fazer o inline do CSS crítico em um bloco <style> elimina a requisição de rede para o primeiro carregamento da 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 recorrentes, uma pequena folha de estilos externa que o navegador armazena em cache é a melhor escolha. O inline só faz sentido 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 atraso de renderização do elemento.

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 main thread. Uma única tarefa longa pode bloquear a renderização por centenas de milissegundos, adicionando diretamente ao atraso de renderização do elemento. O Google define uma long task como qualquer tarefa que leva mais de 50 ms. Tarefas que excedem 200 ms 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 fazendo o yielding do controle de volta ao navegador periodicamente usando setTimeout(..., 0) ou a mais nova API scheduler.yield(). Isso permite que o navegador realize atualizações de renderização entre as tarefas.
  • Otimize e adie terceiros: Audite cada script 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 por design.
  • Use o requestAnimationFrame para atualizações visuais: Se o JavaScript precisar realizar manipulação do DOM durante o carregamento da página, envolva o trabalho no requestAnimationFrame. Isso agenda o trabalho para ser executado logo antes do próximo paint. Isso garante que o navegador tenha a oportunidade de renderizar quadros entre as operações de JavaScript.

Identificando long tasks no DevTools

No painel de 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 um carregamento de página no painel de Performance.
  2. Localize o marcador do LCP na trilha Timings.
  3. Examine a trilha Main em busca de long tasks que ocorram 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 pilha de chamadas no painel Summary. A pilha de chamadas revelará o arquivo de origem e a função responsável pela long task.

Infratores comuns de terceiros

Com base em experiência real de consultoria, os scripts de terceiros mais comuns que causam o atraso de renderização do elemento incluem:

  • Ferramentas de teste A/B (Optimizely, VWO, AB Tasty): Elas frequentemente bloqueiam a renderização intencionalmente para evitar a cintilação do conteúdo entre as variantes. Mover a decisão do experimento para o lado do servidor (teste server-side) elimina esse problema por completo.
  • Gerenciadores de tags com tags síncronas: Um gerenciador de tags configurado com tags síncronas (não assíncronas) pode injetar scripts render blocking. Audite seu contêiner para garantir que todas as tags estejam configuradas para disparar após o DOM ready ou o window load.
  • Plataformas de gerenciamento 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 caminho crítico de renderização.
  • Widgets de chat: Scripts de chat ao vivo frequentemente executam um código de inicialização pesado no carregamento da página. Adie o carregamento para depois que a página estiver interativa ou carregue-os após a interação do usuário (por exemplo, um clique).

Causa: Renderização no lado do cliente (CSR)

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

A Solução: Renderize no servidor. Não há outro jeito. Use a renderização no lado do servidor (SSR) ou a geração de site estático (SSG) para garantir que o elemento do LCP esteja presente no documento HTML inicial enviado pelo servidor. Isso elimina toda a fase de renderização impulsionada 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 está oculto pelo CSS (por exemplo, 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 foi 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 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 certifique-se de que tenham um impacto mínimo na visibilidade do elemento do 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 paint deve processar mais nós, o que consome mais tempo na main thread. Mesmo se o seu CSS e JavaScript estiverem bem otimizados, um DOM inchado adiciona atraso de renderização por puro volume. Para estratégias detalhadas sobre como reduzir o tamanho do DOM, veja nosso guia sobre como evitar o 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 elementos wrapper desnecessários. Achate estruturas profundamente aninhadas. Use CSS Grid ou Flexbox em vez 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 que renderizam apenas os itens atualmente visíveis no viewport.
  • Renderize o conteúdo abaixo da dobra tardiamente: Use content-visibility: auto (coberto abaixo) para pular inteiramente a renderização de seções fora da tela.

Táticas avançadas: Assumindo controle total da renderização

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

Desbloqueando performance 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ê está dizendo ao navegador que ele pode pular o trabalho de layout, paint e composite para esse conteúdo até que ele esteja prestes a entrar no viewport. Isso corta a carga de trabalho da renderização inicial, liberando a main thread para pintar o elemento do LCP mais cedo.

A chave é combinar content-visibility: auto com contain-intrinsic-size, o que fornece um tamanho de espaço reservado para o conteúdo oculto. Sem isso, o comportamento da barra de rolagem se torna irregular porque o navegador não sabe 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 o content-visibility: auto às 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 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 navegadores modernos: Chromium, Firefox e Safari 18+.

Descarregando trabalho com Web Workers

Os Web Workers permitem que você rode o JavaScript em uma thread em segundo plano, completamente fora da main thread. 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. O benefício de 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, tornando a implementação difícil sem desenvolvimento personalizado. Se você tiver a capacidade técnica para usá-los, eles são uma das formas mais eficazes de manter a main thread livre. Porém, para a maioria das equipes, as outras otimizações desta página terão um impacto prático muito 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 main thread
worker.onmessage = (event) => {
  console.log('Analytics processed:', 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 arquivo CSS grande criava um atraso de renderização perceptível. A imagem do LCP foi baixada, mas o navegador ficou travado analisando o CSS. Ao simplesmente fazer o inline do CSS crítico, o navegador pôde pintar o conteúdo da página, incluindo o elemento do LCP, quase imediatamente após o HTML ser analisado. Isso eliminou efetivamente o atraso de renderização causado pela folha de estilos.
  • Caso 2: A penalidade dos testes A/B: Um grande site de e-commerce descobriu que seu LCP estava sendo contido por um script síncrono de teste A/B. Mesmo que a imagem do LCP tenha sido baixada rapidamente, o script bloqueou a main thread 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 imediatamente o LCP em mais de 400 ms. Todo esse tempo foi recuperado do atraso de renderização do elemento.

Checklist: Como eliminar o atraso de renderização do elemento

Um alto atraso de renderização do elemento indica uma main thread congestionada. As soluções envolvem limpar esse congestionamento para que o navegador possa pintar.

  1. Valide com o RUM: Use dados de usuários reais para confirmar que o atraso de renderização do elemento é o seu principal gargalo de LCP antes de começar a otimizar.
  2. Remova o CSS não utilizado: Audite e remova regras CSS que nunca são aplicadas. Esta é a otimização de CSS de maior impacto isolado. Use ferramentas como o PurgeCSS ou a aba Coverage no DevTools.
  3. Mantenha as folhas de estilos pequenas e armazenáveis em cache: Mire em aproximadamente 10 a 15 kB (comprimido) por arquivo CSS. Pequeno o suficiente para baixar rápido, grande o suficiente para evitar requisições paralelas excessivas. Deixe o navegador armazená-las em cache para visitantes recorrentes.
  4. Divida as long tasks de JavaScript: Nenhum script único deve rodar por mais de 50 ms. 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 terceiros merece 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 elemento do LCP. Envie o HTML totalmente formado pelo 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: Para 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 listas longas para reduzir o custo das operações de layout e paint.

Próximos passos: Continue otimizando o LCP

O atraso de renderização do elemento é a fase final. Para cobrir todas as quatro, continue com:

O Search Console reclamou do teu site?

Entrego uma lista de fixes por prioridade, assente em dados RUM. Sem PDF de 50 páginas.

Pedir auditoria
Otimize o atraso de renderização do elemento LCP. Core Web Vitals Otimize o atraso de renderização do elemento LCP.