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 Elemento de Atribuição aponta o nó exato 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ções.
Otimizando os 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 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 está disponível imediatamente após a resposta inicial do servidor (TTFB). Se o seu LCP estiver lento aqui, o problema é quase exclusivamente o Render Delay.
Para corrigir isso, concentre-se inteiramente no Caminho Crítico de Renderização. O navegador provavelmente está bloqueado de 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á ocultando o texto artificialmente (FOIT) enquanto aguarda o download do arquivo de 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 é fortemente dependente 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 detectável o mais cedo possível.
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. Por fim, lide com o Load Time servindo formatos de próxima geração (AVIF/WebP) e usando srcset para evitar que dispositivos móveis baixem arquivos com tamanho de 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 o URL até que tenha baixado e analisado totalmente as suas folhas de estilo. Isso cria um enorme Load Delay porque o Preload Scanner fica 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> HTML padrão para expor o URL ao navegador imediatamente. Se você não puder refatorar a marcação, deverá usar <link rel="preload"> no head do documento para forçar a descoberta antecipada, embora isso seja frequentemente um fardo de manutenção em comparação com o uso de um elemento de imagem nativo.
4. Vídeo
Quando o elemento LCP é um vídeo, o navegador mede o tempo de pintura da imagem de pôster (poster) ou do primeiro quadro (se estiver em reprodução automática). Isso se comporta de maneira semelhante ao tipo de Imagem, mas costuma ser 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 poster leve esteja presente no HTML para que o navegador não precise baixar segmentos de vídeo para renderizar o primeiro pixel. Comprima a imagem de 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 muda frequentemente com base no dispositivo do usuário, revelando falhas fundamentais no design responsivo.
Use o filtro Device Form Factor do CoreDash para comparar Tipos de Elemento entre dispositivos móveis e desktop. Você frequentemente descobrirá que os usuários de desktop obtêm um LCP de imagem (por exemplo, um Hero Banner), enquanto os usuários de dispositivos móveis obtêm um LCP de texto. Isso confirma que o seu layout CSS mobile empurra o Hero Banner para baixo da dobra ou o redimensiona tão significativamente que um parágrafo de texto se torna o "Maior" elemento.
Se você está otimizando a hero image para melhorar o LCP mobile neste cenário, está desperdiçando esforço. O navegador nem sequer está contabilizando 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 mobile.
