Dimensão Core/Dash: Urls
Isole e corrija gargalos de performance das Core Web Vitals por URLs específicas
Trusted by market leaders
Dimensão: Página e Navegação: URLs (u)
A dimensão Tipo de Elemento (LCP) (lcpet) categoriza o nó do Largest Contentful Paint em uma de quatro classes arquiteturais: text, image, background-image ou video.
Enquanto a dimensão Elemento de Atribuição identifica o nó DOM exato, a dimensão Tipo de Elemento dita a sua estratégia de engenharia de alto nível. O LCP é a soma de quatro intervalos de tempo: TTFB, Atraso de Carregamento, Tempo de Carregamento e Atraso de Renderização. 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 as 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 elemento LCP específico.
1. Texto (Text)
Quando o CoreDash reporta 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 é lento aqui, o problema é quase exclusivamente o Atraso de Renderização.
Para corrigir isso, foque inteiramente no Caminho Crítico de Renderização. O navegador provavelmente está bloqueado de pintar o texto por 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 está ocultando artificialmente o texto (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 é fortemente dependente do Atraso de Carregamento e do Tempo de Carregamento. 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 mais cedo.
A otimização aqui requer um gerenciamento rigoroso de ativos. Garanta que a tag <img> exista no código-fonte HTML inicial (Server-Side Rendering) para minimizar o Atraso de Carregamento. Adicione fetchpriority="high" e remova estritamente quaisquer atributos loading="lazy", pois estes atrasam a requisição do navegador. Finalmente, aborde o Tempo de Carregamento servindo formatos de próxima geração (AVIF/WebP) e usando srcset para impedir que dispositivos móveis baixem arquivos de tamanho desktop.
3. Imagem de Fundo (Background Image)
Esta classificação sinaliza uma ineficiência arquitetural. Como a imagem é definida no CSS (ex: background-image: url(...)), o navegador não consegue descobrir a URL até que tenha baixado e analisado totalmente suas folhas de estilo. Isso cria um Atraso de Carregamento massivo porque o Preload Scanner é efetivamente cego para o ativo.
A única correção de engenharia robusta é a refatoração. Mova o ativo visual do CSS para uma tag <img> HTML padrão para expor a URL ao navegador imediatamente. Se você não puder refatorar a marcação, deve usar <link rel="preload"> no cabeçalho do documento para forçar a descoberta antecipada, embora isso seja frequentemente um fardo de manutenção comparado ao 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 poster ou do primeiro quadro (se estiver em reprodução automática). Isso se comporta de forma semelhante ao tipo 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. Garanta 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 poster tão agressivamente quanto você faria com uma imagem LCP padrão.
Fluxo de trabalho: encontrando problemas de LCP baseados no tipo de elemento LCP
O Tipo de Elemento LCP não é estático nem o mesmo para cada visitante. Ele muda frequentemente com base no dispositivo do usuário, revelando falhas fundamentais no design responsivo.
Use o filtro Fator de Forma do Dispositivo do CoreDash para comparar Tipos de Elemento entre Mobile e Desktop. Você frequentemente descobrirá que usuários de Desktop obtêm um LCP de imagem (ex: um Hero Banner), enquanto usuários Mobile obtêm um LCP de texto. Isso confirma que seu layout CSS móvel empurra o Hero Banner para baixo da dobra ou o reduz tão significativamente que um parágrafo de texto se torna o "Maior" elemento.
Se você está otimizando a imagem hero para melhorar o LCP móvel neste cenário, você está desperdiçando esforço. O navegador nem sequer está contabilizando a imagem. Você deve ajustar o layout para trazer a imagem de volta à visualização primária ou mudar seu foco para otimizar a renderização do texto (fontes/CSS) para usuários móveis.
