Para melhorar o LCP no WordPress, encontre o elemento LCP de cada template que reprova e encurte cada parte da linha do tempo dele: resposta do servidor, atraso até o navegador pedir o recurso, download e renderização. Na maioria dos sites WordPress isso significa um cache de página funcionando, uma imagem hero ou destacada sem lazy load e com fetchpriority="high", srcset e sizes corretos para o celular receber um arquivo do tamanho de celular, e menos CSS e JavaScript bloqueando a renderização vindos do tema e dos plugins. O Google considera o LCP bom em até 2,5 segundos no percentil 75 dos dados de campo.
O Largest Contentful Paint é um dos três Core Web Vitals, e no WordPress é por ele que costumo começar, porque as maiores causas estão no servidor e no tema, onde uma correção ajuda todas as páginas. Se você precisa da visão geral antes, leia o guia completo de Core Web Vitals no WordPress.
Qual é o elemento LCP de uma página WordPress?
O LCP é o tempo de renderização da maior imagem ou bloco de texto visível na viewport. O navegador considera elementos img, elementos image dentro de SVG, imagens de poster de vídeo, elementos com imagem de background no CSS carregada por url() e texto em nível de bloco, como títulos e parágrafos.
O elemento muda conforme o template e o dispositivo. Num post de blog costuma ser a imagem destacada. Na home é a imagem hero ou o título principal. Numa página de produto do WooCommerce é a imagem principal do produto. No celular, um título pode ser o LCP enquanto no desktop a mesma página usa uma imagem. Então “corrigir o LCP” na verdade quer dizer “corrigir o LCP deste template, neste dispositivo”.
Para encontrar o elemento:
- O PageSpeed Insights mostra o elemento LCP nos diagnósticos do Lighthouse daquele teste.
- O painel Performance do Chrome DevTools marca o LCP e mostra o elemento.
- O build de attribution da biblioteca web-vitals informa o elemento LCP das visitas reais, e é a fonte em que mais confio.
Como o LCP se divide?
O tempo de LCP é a soma de quatro partes. Olhar cada uma separadamente mostra onde trabalhar, sem precisar adivinhar.
| Parte | O que cobre | Causa típica no WordPress |
|---|---|---|
| Time to First Byte | Do início da navegação até o primeiro byte do HTML | Sem cache de página, bypass do cache, PHP ou banco lentos |
| Resource load delay | Do primeiro byte até o navegador começar a baixar a imagem do LCP | Lazy load, imagens de background no CSS, sliders montados por JavaScript |
| Resource load duration | O download do recurso do LCP | Imagens grandes demais, sem formatos modernos, servidor de imagens lento |
| Element render delay | Do fim do download até o elemento ser pintado | CSS e JavaScript bloqueando a renderização, carregamento de fonte quando o LCP é texto |
O guia de otimização de LCP do web.dev recomenda manter o load delay e o render delay pequenos, para que a maior parte do tempo de LCP fique na resposta do servidor e no download em si. Em sites WordPress com LCP ruim encontro muitas vezes o contrário: a imagem é leve, mas o navegador só fica sabendo dela tarde, ou ela espera atrás de uma pilha de CSS de plugins.
Quais são as causas mais comuns de LCP lento no WordPress?
| Causa | Correção |
|---|---|
| HTML sem cache, servidor lento | Cache de página, object cache persistente, PHP atual com OPcache. Veja o guia de TTFB abaixo |
| Imagem do LCP com lazy load aplicado por plugin, tema ou builder | Exclua as primeiras imagens do lazy load. Deixe o core decidir, ou defina loading="eager" |
| Hero definido como background no CSS | Use um elemento img no HTML, ou faça preload da imagem |
| Primeiro slide montado por script de slider | Renderize o primeiro slide no HTML do servidor, ou troque o slider por um hero estático |
| Imagem muito maior que o tamanho exibido | Tamanhos de imagem registrados, sizes correto, WebP ou AVIF |
| CSS e JavaScript bloqueando a renderização | Defer nos scripts, remoção por template dos assets de plugin não usados, CSS crítico inline |
| LCP de texto esperando uma web font | Hospede a fonte no próprio servidor, faça preload, use um font-display adequado |
A primeira linha merece um artigo próprio, porque o TTFB é o piso de todas as outras partes. Se o seu HTML leva 1,5 segundo para chegar, sobra um segundo para todo o resto. Leia como reduzir o TTFB no WordPress antes de mexer nas imagens.
Como fazer o WordPress priorizar a imagem do LCP?
O core do WordPress já faz parte do trabalho. Desde o WordPress 6.3 ele adiciona fetchpriority="high" na imagem que considera mais provável de ser o LCP, normalmente a imagem destacada ou a primeira imagem grande do conteúdo, e evita colocar loading="lazy" nas imagens perto do topo da página. O problema é tudo o que roda em volta do core. Plugins de lazy load que colocam loading="lazy" ou trocam src por data-src em todas as imagens. Builders com uma configuração global de lazy load. Templates do tema que imprimem imagens com atributos fixos no código.
Confira o código-fonte HTML de uma página que reprova, não o DOM renderizado. A imagem do LCP precisa estar no HTML, sem lazy load, com fetchpriority="high". Se o seu tema gera o hero diretamente, passe os atributos de forma explícita:
wp_get_attachment_image( $id, 'full', false, array( 'loading' => 'eager', 'fetchpriority' => 'high' ) );
Quando a imagem do LCP precisa continuar como background no CSS, faça o preload dela no head com <link rel="preload" as="image" href="..." fetchpriority="high">, acrescentando imagesrcset e imagesizes se você servir versões responsivas. Use prioridade alta em uma imagem por página. Se tudo tem prioridade alta, nada tem.
Como tamanho e formato de imagem afetam o LCP?
O WordPress gera vários tamanhos para cada upload e imprime srcset e sizes nas imagens do conteúdo. O navegador escolhe um arquivo do srcset com base no sizes, então um sizes errado faz o celular baixar o arquivo de desktop. Heros de largura total muitas vezes precisam de sizes="100vw", e temas que imprimem o hero com código customizado costumam omitir o sizes por completo. Registre tamanhos que combinem com o seu layout usando add_image_size() em vez de servir o arquivo original do upload.
O formato ajuda na parte do download. O WordPress aceita upload de WebP desde a versão 5.8 e de AVIF desde a 6.5, desde que a biblioteca de imagens do servidor suporte esses formatos. Converter um hero JPEG de 600 KB para um formato moderno bem comprimido é um dos ganhos de LCP mais baratos que existem. Mantenha a qualidade num nível razoável, porque uma imagem de LCP feia vai ser trocada por um designer em menos de um mês.
Por que CSS e JavaScript atrasam o LCP?
Folhas de estilo no head bloqueiam a renderização. Uma página WordPress carrega o CSS do tema mais os estilos de cada plugin que faz enqueue global, então o navegador pode já ter baixado a imagem do LCP e continuar esperando para pintá-la. Temas de blocos carregam só os estilos dos blocos usados em cada página, e temas clássicos podem ativar o mesmo comportamento com o filtro should_load_separate_core_block_assets.
Para scripts, o WordPress 6.3 trouxe as estratégias de carregamento: registre um script com 'strategy' => 'defer' e o core imprime ele com defer, fora do caminho crítico. Nos plugins que não usam isso, faça o dequeue dos assets nos templates que não precisam deles com wp_dequeue_script() e wp_dequeue_style(). O CSS crítico de um plugin de cache também pode ajudar no render delay, mas teste com cuidado, porque um arquivo de CSS crítico errado cria os layout shifts que descrevo em como reduzir o CLS no WordPress.
Como confirmar uma correção de LCP?
Confira o laboratório primeiro: um teste no Lighthouse e um trace no DevTools devem mostrar a imagem do LCP sendo pedida cedo e as quatro partes diminuindo. Depois confira as visitas reais. O monitoramento de usuários reais com a biblioteca web-vitals mostra a mudança em poucos dias. O CrUX, que alimenta o PageSpeed Insights e o Search Console, precisa da janela completa de 28 dias para o p75 refletir a correção. Não confie numa melhora de laboratório até o campo confirmar. Explico o motivo em Core Web Vitals: dados de campo vs laboratório. Se o gargalo é o servidor, escolher a camada de cache certa normalmente vem antes.
Precisa de ajuda com o LCP do seu site WordPress?
Se o seu LCP continua reprovando depois das correções óbvias, a causa costuma estar no servidor ou na forma como o tema monta o topo da página. Eu audito os dois e entrego uma ordem de correção por template, baseada em dados de campo. Conheça meu trabalho de auditoria e consultoria em Core Web Vitals.