Corrija hero images lentas e os Core Web Vitals

Como corrigir hero images lentas: em resumo

Hero images são imagens grandes no topo de uma página web. Essas hero images causarão um longo Largest Contentful Paint quando não estiverem otimizadas. 9 em cada 10 sites que me pedem para otimizar terão problemas com as hero images. Neste artigo, mostrarei diferentes técnicas de como acelerar hero images.

Última revisão por Arjen Karel em fevereiro de 2026

O que é uma hero image?

Uma hero image, às vezes chamada de 'hero header', é uma imagem grande com texto, frequentemente colocada no topo de uma página web. Uma hero image serve como o primeiro vislumbre do usuário sobre a sua empresa e oferta, devido à sua colocação proeminente no topo de uma página web que geralmente se estende por toda a largura.

Um lembrete rápido: Hero images, os Core Web Vitals e o Largest Contentful Paint: 
Devido ao tamanho da hero image (ela geralmente abrange toda a largura da página e uma boa parte da altura da viewport visível), este elemento se tornará o elemento Largest Contentful Paint em quase todos os casos.
O Largest Contentful Paint é uma métrica importante dos Core Web Vitals. O elemento do largest contentful paint é o maior elemento que será renderizado na viewport visível do navegador. De acordo com o Web Almanac de 2025, em 76% das páginas mobile o elemento LCP é uma imagem. Apenas 62% das origens mobile atualmente passam no LCP. Corrija a hero image e você corrige o LCP para a maioria dos sites.
Como imagens não otimizadas tendem a consumir muita largura de banda e, portanto, levam muito tempo para carregar, as hero images frequentemente causarão métricas ruins de Largest Contentful Paint.

Otimizando a hero image e o Largest Contentful Paint

Existem muitas técnicas para otimizar as hero images e o Largest Contentful Paint. Vou explicá-las aqui. A maioria das técnicas pode ser combinada para resultados ainda melhores!

1. Faça preload da hero image ou envie 103 Early Hints

Quando você quer que um elemento esteja disponível o mais rápido possível no navegador, você pode fazer o preload desse elemento. O preloading envolve o uso de resource hints. As resource hints informam ao navegador algo sobre a prioridade de um elemento e irão acionar um download muito inicial desse recurso. De acordo com o Web Almanac de 2025, apenas 2.1% das páginas fazem preload da sua imagem LCP. Essa é uma enorme oportunidade perdida.

<link
  rel="preload"
  as="image"
  href="wolf.jpg"
  fetchpriority="high"
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w"
  imagesizes="50vw">

Os 103 Early Hints permitem que os servidores enviem resource hints antes da resposta HTML final. O navegador pode começar a fazer preload da hero image enquanto o servidor ainda está gerando a página. Chrome, Edge e Firefox suportam preloading via Early Hints. O Safari suporta preconnect, mas ainda não suporta preload via Early Hints. Para detalhes sobre como configurar isso, leia o guia completo para 103 Early Hints.

Nos sites monitorados pelo CoreDash, as páginas com uma imagem LCP com preload têm uma taxa de LCP 'bom' de 81% em comparação com 64% sem preloading. Para um passo a passo completo de todas as opções de preloading, veja como fazer preload da imagem LCP.

2. Use fetchpriority="high" na hero image

O atributo fetchpriority informa ao navegador quais recursos são mais importantes. Definir fetchpriority="high" na sua hero image aumenta a sua prioridade de download acima de outras imagens e recursos concorrentes, como scripts e fontes.

<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">

De acordo com o Web Almanac de 2025, apenas 17% das páginas definem fetchpriority="high" em sua imagem LCP. Isso significa que 83% dos sites estão deixando ganhos fáceis de performance na mesa.

Você também pode adicionar fetchpriority="high" ao link de preload mostrado acima. Use fetchpriority="high" apenas em uma única imagem por página. Múltiplas imagens de alta prioridade competem entre si e anulam o benefício. Para mais informações sobre como os navegadores priorizam os recursos, leia o guia dos Core Web Vitals para priorização de recursos.

3. Comprima a hero image e use formatos de nova geração

Comprimir imagens deixará o tamanho do arquivo delas menor. Tamanhos de arquivo menores consumirão menos largura de banda e estarão disponíveis para o navegador o mais rápido possível. A compressão de imagens pode ser feita no seu editor de fotos, no seu CMS (dica: o seu desenvolvedor pode definir o nível de compressão do WordPress) ou com uma ferramenta online de compressão de imagens.

A maioria das hero images lentas são mais lentas do que precisam ser porque são servidas no container de imagem 'errado', como PNG ou JPEG. Existem alternativas muito mais rápidas ao JPEG e PNG, como WebP e AVIF. De acordo com o Web Almanac de 2025, 57% das imagens LCP ainda são servidas como JPEG e 26% como PNG, enquanto apenas 11% usam WebP e menos de 1% usam AVIF.

Para muitos sistemas CMS, existem plugins de conversão que converterão suas imagens para formatos de nova geração. Quando a conversão de imagens é difícil de integrar ao seu site, uma CDN com suporte para conversão de imagens pode ser a solução que você está procurando. Para uma visão geral completa das técnicas de otimização de imagens, veja como otimizar imagens para os Core Web Vitals.

4. Não use background images, use imagens responsivas normais

A sua hero image deve ser uma imagem normal e nunca uma background image. A maneira usual de fazer hero images é adicionando uma background image ao container hero e definindo o background-size desse container como cover. Isso garantirá que a hero image se ajuste à tela em todos os casos.

Background images são ruins para os Core Web Vitals. Lembre-se disso! Leia mais sobre por que background images são ruins para a performance. Se você não puder evitar background images inteiramente, você pode pelo menos adiar as background images que estão abaixo da dobra.

• Background images são carregadas com uma prioridade mais baixa
• Background images não são responsivas (não a menos que você realmente queira complicar as coisas)
• Background images podem causar problemas de Core Web Vitals com a maioria das bibliotecas de lazy loading

A maneira como eu faço isso é adicionando uma imagem normal em uma posição absoluta e definindo a propriedade object-fit dessa imagem como cover. Uma vez que eu tenha mudado a background image para uma imagem normal, eu posso começar a usar imagens responsivas. Se você estiver usando o Elementor, confira como corrigir hero images no Elementor.

Imagens responsivas significam que para dispositivos diferentes (mobile, desktop, tablet) uma versão diferente da mesma hero image pode ser enviada. Para um dispositivo desktop, eu posso enviar uma hero image enorme de 1920x1280, enquanto para um dispositivo mobile eu só precisaria enviar uma hero image menor de 400x266 pixels. Isso é 25 vezes menos dados!

• As hero images agora são carregadas com uma prioridade mais alta
• Eu agora posso usar imagens responsivas para a hero image

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Bem-vindo ao meu site</h1>
<picture>
    <source
        type="image/webp"
        media="(max-width:540px)"
        srcset="herosm.webp">
    </source>
    <img fetchpriority="high" loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

5. Sirva as hero images a partir do domínio principal e considere uma CDN

Muitas vezes eu vejo a imagem do largest contentful paint sendo servida a partir de um domínio diferente, por exemplo 'static.meudominio.com'. Esses subdomínios frequentemente apontam para uma CDN. Embora eu encoraje o uso de uma CDN (veja abaixo), uma configuração como essa não é aconselhável. A imagem no subdomínio requer uma nova conexão a um novo servidor. Novas conexões são custosas e tomarão um tempo valioso. Quando a imagem é servida a partir do domínio principal (www.meudominio.com, por exemplo), as imagens podem ser buscadas muito mais rapidamente através da conexão do servidor já estabelecida.

Quando configurada no domínio principal, uma CDN pode oferecer um enorme aumento de velocidade. Especialmente quando o seu site é visitado de todo o mundo. Uma CDN possui servidores estrategicamente posicionados em todo o mundo, onde os seus recursos estáticos (como imagens) são armazenados em cache para tempos de resposta locais rápidos. Isso significa que os dados não precisam viajar pelo mundo todo, mas podem ser servidos a partir de um edge server local. Para um guia de configuração completo, veja como configurar o Cloudflare para os Core Web Vitals.

6. Evite o lazy loading da hero image

Certifique-se de que não há lazy loading sendo aplicado à sua hero image. Hero images devem sempre carregar de forma eager.

Muitos sites, especialmente sites em WordPress, estão usando algum tipo de plugin de pagespeed para WordPress, como WP Rocket ou WP Core Web Vitals. Esses plugins geralmente fazem um ótimo trabalho em acelerar sites lentos, mas eles não conseguem consertar burrice :-)

Esses plugins farão lazy load de imagens que parecem boas candidatas para o lazy load. Se a hero image não for uma imagem eager, esses plugins provavelmente também farão lazy load da hero image.

Isso, na melhor das hipóteses, causará um pequeno atraso nas métricas de LCP. Na pior das hipóteses, especialmente quando o lazy loading baseado em JavaScript está ativado, isso causará um atraso maior. De acordo com o Web Almanac de 2025, cerca de 17% das páginas fazem lazy-load da sua imagem LCP. Isso representa 17% dos sites ativamente piorando o seu LCP. Se o Lighthouse estiver alertando sobre isso, veja como corrigir o aviso de imagem LCP carregada preguiçosamente.

Fazer com que as imagens carreguem de forma eager é simples. Basta adicionar loading="eager" à imagem. Note que eager é na verdade o padrão do navegador. Omitir o atributo loading inteiramente tem o mesmo efeito. O verdadeiro objetivo é garantir que a hero image NÃO tenha loading="lazy". Adicionar explicitamente eager ainda é útil como um sinal de intenção, especialmente em sites onde um CMS ou plugin pode aplicar lazy loading automaticamente.

<img src="hero.webp" loading="eager" fetchpriority="high" width="800" height="400">

7. Evite mudanças de layout (layout shifts) causadas pela hero image

Outro problema comum que eu vejo com hero banners e hero images é que eles causam um enorme layout shift. Esses layout shifts podem ocorrer por diferentes motivos.

• O elemento hero é criado com JavaScript. Alguns plugins de hero e page builders como o Elementor são conhecidos por depender do JavaScript para renderizar o conteúdo hero. Embora não haja nada de errado com o JavaScript, certifique-se de que o elemento hero seja renderizado da mesma forma sem JavaScript.
• As fontes no elemento hero causam um layout shift. O elemento hero geralmente contém algum texto grande com uma call to action e uma tagline. Certifique-se de que essas fontes grandes não causem um layout shift.
• Falta das dimensões da imagem. Quando a hero image não é uma cover image (seja como background image ou uma imagem posicionada de forma absoluta), a falta das dimensões da imagem (width e height) certamente causará um grande layout shift.

Embora corrigir o layout shift não melhore o Largest Contentful Paint, isso melhorará os Core Web Vitals da página. Para mais informações sobre como corrigir o layout shift, leia o guia aprofundado de como corrigir o Cumulative Layout Shift!

8. Use carregamento em 2 estágios (2-stage loading) para melhorar os Core Web Vitals do hero

O carregamento em 2 estágios (2-stage loading) é uma técnica rápida que aplicamos a todas as nossas imagens. Primeiro, servimos uma imagem de qualidade extremamente baixa que se espera que seja baixada muito antes da imagem maior de alta qualidade. Uma vez que a imagem de baixa qualidade tenha sido renderizada na tela, o navegador é acionado para buscar a imagem de alta qualidade em segundo plano. Assim que a imagem de alta qualidade for baixada, a imagem de baixa qualidade será substituída pela imagem de alta qualidade.

Existem 3 métodos de carregamento em 2 estágios. Os dois primeiros são métodos que você deve considerar. O último é um que você não deve fazer.

1. Carregamento completo em 2 estágios (Full 2-stage loading)

Com o carregamento completo em 2 estágios, a primeira imagem de baixa qualidade tem exatamente as mesmas dimensões (width e height) que a imagem original de alta qualidade.

O resultado deste carregamento em 2 estágios é que o elemento largest contentful paint será a imagem de baixa qualidade e muito mais rápida (que depois será trocada de forma lazy). A troca da imagem acontecerá tão rápido que um visitante casual provavelmente nunca notará. O resultado desta técnica é que o LCP é renderizado muito mais cedo, a página parece estar 'pronta' muito antes, o que contribui para uma user experience muito melhor e melhores Core Web Vitals.

2. Placeholders inline menores

O placeholder menor é uma técnica muito legal que tem uma desvantagem: ela não melhora os Core Web Vitals. Ainda é uma ótima técnica porque melhora a user experience.

A ideia básica é a mesma da técnica de carregamento em 2 estágios, mas em vez de uma imagem de baixa qualidade com as mesmas dimensões, uma imagem muito menor com dimensões menores é colocada inline através de um data URI. A hero image final, que será a imagem do largest contentful paint, ainda é baixada em segundo plano. Esse truque não melhorará o Largest Contentful Paint, mas fará com que a página pareça estar pronta ainda mais rápido do que a técnica de carregamento em 2 estágios.

3. Placeholders transparentes

Uma técnica comum de carregamento em 2 estágios e um método para enganar o navegador e fazê-lo enviar uma métrica antecipada de Largest Contentful Paint é o uso de elementos SVG transparentes. Esses elementos são pequenos e podem ser colocados inline, assim como o placeholder inline menor.

Usar um elemento SVG inline e trocá-lo é, na verdade, uma técnica de lazy loading. A vantagem dessa técnica é que ela funciona em todos os navegadores (cross-browser). 

O lazy loading, é claro, só deve ser aplicado a elementos fora da viewport. Neste caso, o elemento SVG transparente apenas atrasará a hero image real e não tem valor agregado para o seu visitante. Embora as métricas de paint possam ficar ótimas, a UX da página na verdade vai piorar.

É por isso que a hero image deve sempre ser carregada de forma eager, sem truques que causem uma UX ruim.

Juntando tudo

Aqui está a aparência de uma hero image otimizada quando você combina preloading, fetchpriority, imagens responsivas e carregamento eager:

<!-- No <head> -->
<link rel="preload" as="image" href="hero-800.webp" fetchpriority="high"
  imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  imagesizes="100vw">

<!-- No <body> -->
<img src="hero-800.webp"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  alt="Texto descritivo do alt">

Após fazer as alterações, verifique a melhoria com Real User Monitoring. O Lighthouse fornece um snapshot de laboratório, mas o Google ranqueia com base em dados de campo reais de usuários coletados ao longo dos últimos 28 dias.