Dimensão Core/Dash: Tipo de Elemento (LCP)
Corrija o Largest Contentful Paint filtrando o tráfego com base no tipo de elemento arquitetônico.
Trusted by market leaders · Client results
Dimensão: Recurso: Tipo de Elemento LCP (lcpet)
A dimensão Tipo de Elemento (LCP) (lcpet) categoriza o nó do Largest Contentful Paint em uma de quatro classes arquitetônicas: text, image, background-image ou video.
Enquanto a dimensão Attribution Element identifica exatamente o nó do DOM, a dimensão Tipo de Elemento dita sua estratégia de engenharia de alto nível. O LCP é a soma de quatro intervalos de tempo: TTFB, Load Delay, Load Time e Render Delay. O Tipo de Elemento informa qual desses intervalos está prejudicando sua pontuação, permitindo que você selecione o protocolo de otimização correto sem adivinhação.
Otimizando o Core Web Vitals por tipo de elemento LCP
Após melhorar o TTFB, que é independente do tipo de elemento LCP, você deve adotar uma abordagem diferente para otimizar o LCP analisando o seu tipo de elemento LCP.
1. Texto
Quando o CoreDash relata texto como o Tipo de Elemento, a largura de banda de recursos de rede estáticos raramente é o gargalo. O texto reside diretamente no documento HTML, o que significa que o conteúdo fica disponível imediatamente após a resposta inicial do servidor (TTFB). Se o seu LCP for lento aqui, o problema será quase exclusivamente o Render Delay.
Para corrigir isso, concentre-se inteiramente no Critical Rendering Path. É provável que o navegador esteja bloqueado para pintar o texto devido a cálculos pesados de CSS ou JavaScript síncrono no <head>. Além disso, verifique sua estratégia de carregamento de fontes; se você não estiver usando font-display: swap ou optional, o navegador estará escondendo o texto artificialmente (FOIT) enquanto aguarda o download do arquivo da fonte.
2. Imagem (<img>)
Este tipo aciona o pipeline completo de recursos: descoberta, download e decodificação. Ao contrário do texto, um LCP de imagem depende fortemente do Load Delay e do Load Time. Você está lutando contra a física e a latência da rede aqui, então seu objetivo é tornar o ativo mais leve e ser descoberto mais cedo.
A otimização aqui requer um gerenciamento rigoroso de ativos. Certifique-se de que a tag <img> exista no código-fonte HTML inicial (Server-Side Rendering) para minimizar o Load Delay. Adicione fetchpriority="high" e remova estritamente quaisquer atributos loading="lazy", pois eles atrasam a solicitação do navegador. Finalmente, enfrente o Load Time servindo formatos de última geração (AVIF/WebP) e usando srcset para evitar que dispositivos móveis façam download de arquivos com o tamanho da versão desktop.
3. Imagem de Fundo
Esta classificação sinaliza uma ineficiência arquitetônica. Como a imagem é definida no CSS (por exemplo, background-image: url(...)), o navegador não pode descobrir a URL até ter feito o download completo e analisado suas folhas de estilo. Isso cria um enorme Load Delay porque o Preload Scanner é efetivamente cego para o ativo.
A única correção robusta de engenharia é a refatoração. Mova o ativo visual do CSS para uma tag <img> padrão do HTML para expor a URL ao navegador imediatamente. Se você não puder refatorar a marcação, você deve usar <link rel="preload"> no cabeçalho (head) do documento para forçar uma descoberta antecipada, embora isso frequentemente seja um fardo de manutenção comparado ao uso de um elemento nativo de imagem.
4. Vídeo
Quando o elemento LCP é um vídeo, o navegador mede o tempo de pintura da imagem de pôster ou do primeiro quadro (se estiver em reprodução automática). Isso se comporta de forma semelhante ao tipo de Imagem, mas frequentemente é mais pesado devido ao tamanho do arquivo dos ativos de vídeo.
Trate isso estritamente como uma tarefa de otimização de imagem. Certifique-se de que um atributo de pôster leve esteja presente no HTML para que o navegador não tenha que fazer o download de segmentos de vídeo para renderizar o primeiro pixel. Comprima a imagem do pôster de forma tão agressiva quanto faria com uma imagem LCP padrão.
Fluxo de trabalho: encontrando problemas de LCP com base no tipo de elemento LCP
O Tipo de Elemento LCP não é estático nem o mesmo para todos os visitantes. Ele frequentemente muda com base no dispositivo do usuário, revelando falhas fundamentais no design responsivo.
Use o filtro Device Form Factor do CoreDash para comparar os Tipos de Elemento entre dispositivos móveis (Mobile) e computadores (Desktop). Frequentemente, você descobrirá que os usuários de Desktop recebem um LCP de imagem (por exemplo, um Hero Banner), enquanto os usuários de Mobile recebem um LCP de texto. Isso confirma que seu layout CSS móvel empurra o Hero Banner para baixo da dobra (below the fold) ou o reduz tão significativamente que um parágrafo de texto se torna o "Maior" (Largest) elemento.
Se você estiver otimizando a hero image para melhorar o LCP no dispositivo móvel neste cenário, você estará desperdiçando esforço. O navegador sequer está contando a imagem. Você deve ajustar o layout para trazer a imagem de volta para a visualização principal ou mudar seu foco para otimizar a renderização de texto (fontes/CSS) para usuários de dispositivos móveis.
