O que o lazy loading realmente faz com o seu Largest Contentful Paint

Lazy loading é uma decisão de agendamento, não um feitiço de velocidade

Lazy loading costuma ser descrito como uma melhoria de performance, o que é verdade do mesmo modo que não arrumar uma mala reduz o peso. Ele ajuda porque o navegador faz menos trabalho logo no início.

Essa distinção importa para Largest Contentful Paint, geralmente abreviado como LCP. LCP mede quando o maior elemento significativo na viewport é renderizado. Em muitas páginas, esse elemento é uma imagem hero. Em outras, é um título grande, uma imagem de pôster, uma foto de produto ou um bloco de conteúdo.

Lazy loading muda quando os recursos são solicitados. Ele não faz uma imagem decodificar mais rápido, um servidor responder mais rápido ou uma fonte renderizar mais cedo. Se você aplica lazy loading ao recurso errado, especialmente ao elemento que se torna o LCP, está dizendo ao navegador para esperar antes de buscar justamente aquilo que ele precisa exibir para passar no Core Web Vitals.

É por isso que lazy loading é ao mesmo tempo usado em excesso e pouco compreendido.

O que o navegador faz quando você aplica lazy loading a uma imagem

O lazy loading nativo de imagens costuma ser adicionado assim:

<img src='hero.jpg' loading='lazy' alt='...'>

Com loading='lazy', o navegador tem permissão para adiar a busca da imagem até acreditar que ela provavelmente será necessária. Na prática, navegadores usam distância da viewport, condições de rede, dimensões da imagem e outras heurísticas. As regras exatas são detalhes de implementação e podem mudar.

Com loading='eager', ou sem o atributo lazy na maioria dos casos, o navegador trata a imagem como parte do processo normal de carregamento. Ele ainda precisa priorizar entre CSS, JavaScript, fontes, imagens e outras requisições, mas a imagem é descoberta imediatamente.

Isso significa que lazy loading afeta principalmente três fases:

• Descoberta: quando o navegador percebe o recurso.
• Início da requisição: quando a busca pela rede começa.
• Momento de renderização: quando o recurso finalmente pode ser decodificado e pintado.

Para LCP, o ponto perigoso é o início da requisição. Se a requisição da imagem de LCP começa tarde, tudo depois dela também é empurrado para mais tarde.

A regra simples: nunca aplique lazy loading ao candidato a LCP

Se uma imagem está visível na viewport inicial e provavelmente será o maior elemento de conteúdo, não aplique lazy loading a ela.

Isso inclui:

• imagens hero
• fotos principais de produto acima da dobra
• grandes imagens de abertura de artigos
• grandes imagens com aparência de fundo implementadas como <img>
• imagens de pôster de vídeo quando o pôster é o principal elemento visual

O navegador não consegue renderizar a imagem de LCP até que ela tenha sido solicitada, transferida, decodificada e pintada. Lazy loading insere incerteza antes do primeiro passo. Mesmo um pequeno atraso pode ser suficiente para mover o LCP de aceitável para ruim em uma conexão mais lenta.

Um padrão comum de falha se parece com isto:

1. O servidor envia o HTML.
2. O navegador analisa uma imagem acima da dobra.
3. A imagem tem loading='lazy'.
4. O navegador espera porque a heurística de lazy loading diz que pode.
5. CSS e JavaScript continuam carregando.
6. A requisição da imagem começa mais tarde do que deveria.
7. O LCP atrasa, mesmo que o arquivo da imagem em si esteja razoavelmente otimizado.

Isso é frustrante porque a página pode parecer correta em uma revisão de código. O problema não é apenas o tamanho do arquivo. É prioridade.

Se você está lendo a saída de laboratório e tentando entender se LCP é realmente o problema, nosso guia sobre como ler um relatório do Lighthouse sem entrar em pânico é intencionalmente prático: separe dados de campo, pistas de laboratório e correções antes de começar a mudar código. (Observação: se seu roteamento diferencia maiúsculas de minúsculas, use a URL exata do seu CMS.)

Correção: use a URL interna real

A URL correta do artigo da Wux é Como ler um relatório do Lighthouse sem entrar em pânico. O ponto permanece: identifique o elemento de LCP antes de mudar o comportamento de carregamento.

Quando lazy loading pode melhorar o LCP

Lazy loading pode melhorar o LCP indiretamente quando mantém recursos não críticos fora do caminho do navegador.

Imagine uma página de produto com uma imagem hero do produto no topo e um carrossel de doze imagens de recomendação abaixo da dobra. Se todas as treze imagens carregarem eager, o navegador pode gastar largura de banda e conexões em imagens que o usuário ainda não consegue ver. Em uma rede limitada, isso pode competir com a imagem hero, o CSS ou os arquivos de fonte.

Aplicar lazy loading às imagens do carrossel abaixo da dobra pode ajudar a imagem de LCP a carregar mais cedo porque menos requisições não críticas competem durante o carregamento inicial da página.

Este é o caso legítimo de performance para lazy loading:

• carregue eager o candidato a LCP acima da dobra
• aplique lazy loading a imagens abaixo da viewport inicial
• evite scripts pesados que inserem imagens importantes tardiamente
• mantenha as dimensões das imagens no HTML para evitar mudanças de layout

Lazy loading não é uma otimização de LCP por si só. É uma ferramenta de priorização de recursos. Ele ajuda quando protege o caminho crítico.

O melhor padrão para imagens de LCP

Para uma imagem de LCP acima da dobra, o objetivo é fazer o navegador descobri-la cedo, solicitá-la cedo e renderizá-la sem instabilidade de layout.

Uma boa base se parece com isto:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

As partes importantes não são decorativas:

• loading='eager' evita atraso de lazy loading.
• fetchpriority='high' diz ao navegador que esta imagem importa.
• width e height reservam espaço e reduzem mudanças de layout.
• srcset e sizes evitam downloads grandes demais.
• Um formato moderno pode reduzir o tempo de transferência quando usado com cuidado.

Se você ainda serve um único JPEG grande para todas as telas, o formato da imagem e o dimensionamento responsivo podem importar mais do que o atributo de lazy loading. Para uma árvore de decisão prática, veja quando AVIF supera WebP e quando não supera.

Imagens de fundo exigem cuidado extra

Imagens de fundo em CSS não são descobertas tão cedo quanto imagens HTML normais. O navegador precisa buscar e analisar o CSS antes de saber que elas existem. Se o seu elemento de LCP é uma imagem de fundo em CSS, você já tornou a descoberta mais difícil.

Isso não significa que imagens de fundo sejam proibidas. Significa que você deve ser deliberado.

Para imagens decorativas, fundos em CSS são aceitáveis. Para imagens hero significativas, um elemento <img> ou <picture> geralmente é melhor porque fica visível para o parser de HTML, oferece suporte a texto alt e funciona bem com atributos de imagem responsiva.

Se você precisa usar um fundo em CSS para uma imagem de LCP, considere fazer preload dela:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload também não é uma varinha mágica. Fazer preload de imagens demais cria o mesmo problema de prioridade com outra aparência. Use-o para a única imagem que realmente importa, não para todas as imagens do design system.

Lazy loading com JavaScript muitas vezes piora as coisas

Antes de o lazy loading nativo ser amplamente suportado, muitos sites usavam bibliotecas JavaScript que trocavam data-src por src depois do carregamento da página ou depois que um intersection observer disparava. Alguns ainda fazem isso.

Isso pode ser razoável para páginas de artigos longos ou galerias com muitas imagens. É uma escolha ruim para conteúdo acima da dobra.

O scanner de preload do navegador é rápido, mas ele não consegue solicitar uma imagem cuja URL está escondida em um atributo personalizado até que o JavaScript rode. Se sua imagem hero começa como data-src='hero.jpg', você atrasou a descoberta para depois do download, análise, execução de scripts e hidratação do framework.

Essa é uma troca ruim para LCP. Coloque URLs de imagens críticas em HTML real. Deixe o navegador fazer seu trabalho.

LCP nem sempre é um problema de imagem

Em algumas páginas, o elemento de LCP é texto. Nesse caso, aplicar lazy loading a imagens pode ter pouco efeito direto. Seu gargalo pode ser CSS bloqueador de renderização, resposta lenta do servidor, renderização no lado do cliente ou web fonts.

Fontes merecem destaque porque são uma causa oculta frequente de renderização tardia de texto. Um título grande pode se tornar o LCP, e o comportamento de carregamento de fontes pode atrasar ou alterar quando esse título é pintado. Se seu trabalho com imagens não está movendo a métrica, inspecione diretamente o elemento de LCP em vez de presumir. Nosso artigo sobre web fonts como ganho de performance cobre as correções entediantes que costumam funcionar: menos pesos, formatos modernos, fallbacks sensatos.

Como testar mudanças de lazy loading sem se enganar

Não teste ficando olhando para sua página no Wi-Fi do escritório. Você precisa ver o timing das requisições.

Use este fluxo de trabalho:

1. Abra o Chrome DevTools e grave um trace de Performance.
2. Ative o throttling de rede, como Fast 4G ou Slow 4G.
3. Recarregue a página com o cache desativado.
4. Encontre o marcador de LCP.
5. Identifique o elemento de LCP.
6. No painel Network, verifique quando esse recurso começou a carregar.

Se o recurso de LCP começa tarde, pergunte por quê:

• Ele recebeu lazy loading?
• Ele foi inserido por JavaScript?
• Ele estava escondido no CSS?
• Ele foi despriorizado atrás de outras imagens?
• O servidor demorou para responder?

Depois faça uma mudança e teste novamente. Trabalho de performance fica confuso quando equipes mudam formato de imagem, lazy loading, preloading, bundles JavaScript e configurações de CDN no mesmo deploy. Você pode melhorar a página, mas não saberá qual mudança importou.

Dados de campo também importam. Ferramentas de laboratório são úteis para diagnóstico, mas LCP varia por dispositivo, rede, viewport, estado de cache e geografia. Use monitoramento de usuários reais ou dados do Chrome User Experience Report quando puder.

<!-- tool-cta:start -->

💡 Experimente isto: Mantenha a sua imagem LCP pequena e carregada com prioridade, passando-a pelo Image Compressor, para que seja renderizada rapidamente sem precisar de lazy loading.

<!-- tool-cta:end -->

Uma política prática para a maioria dos sites

Para a maioria dos sites de marketing, páginas de ecommerce, sites de documentação e páginas editoriais, esta política é suficiente:

• Imagem principal acima da dobra: carregue eager, considere alta prioridade de fetch.
• Imagens de conteúdo abaixo da dobra: aplique lazy loading.
• Ícones e pequenos assets de UI: geralmente não vale a pena pensar neles individualmente.
• Hero em fundo CSS: reconsidere como imagem HTML ou faça preload com cuidado.
• Imagem hero inserida por JavaScript: corrija a arquitetura de renderização se possível.
• Carrosséis: carregue eager apenas o primeiro slide visível; aplique lazy loading ao restante.

Há casos de borda. As heurísticas dos navegadores melhoram. Frameworks adicionam componentes automáticos de imagem. Algumas plataformas agora evitam lazy loading em imagens detectadas perto da viewport. Ainda assim, o princípio não muda: recursos críticos devem aparecer cedo e de forma óbvia; recursos não críticos devem esperar.

Lazy loading é valioso quando expressa essa distinção. É prejudicial quando esconde o conteúdo mais importante do navegador até depois de a página já começar a perder a corrida do LCP.