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 da web. Essas hero images causarão um longo Largest Contentful Paint quando as hero images não estiverem otimizadas. 9 de 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.

Revisado pela última vez 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 da web. Uma hero image serve como o primeiro vislumbre do usuário da sua empresa e oferta por causa de seu posicionamento proeminente no topo de uma página da 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 (geralmente abrange toda a largura da página e uma boa parte da altura da viewport visível), este elemento se tornará o elemento do 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á pintado 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 passam atualmente no LCP. Corrija a hero image e você corrige o LCP para a maioria dos sites.
Como imagens não otimizadas tendem a ocupar 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 o 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 dizem 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 de sua imagem LCP. Essa é uma grande 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 o preloading 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 sobre 103 Early Hints.

Em sites monitorados pelo CoreDash, as páginas com uma imagem LCP com preload têm uma taxa de LCP 'boa' 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 diz ao navegador quais recursos são mais importantes. Configurar fetchpriority="high" na sua hero image aumenta 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 configuram 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" em apenas uma única imagem por página. Várias imagens de alta prioridade competem entre si e anulam o benefício. Para mais informações sobre como os navegadores priorizam recursos, leia o guia dos Core Web Vitals para priorização de recursos.

3. Comprima a hero image e use formatos de próxima geração

Comprimir imagens tornará o tamanho do arquivo menor. Tamanhos de arquivo menores ocuparã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 em seu editor de fotos, em seu CMS (dica: seu desenvolvedor pode configurar 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 contêiner 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 próxima geração. Quando a conversão de imagem for difícil de integrar ao seu site, uma CDN com suporte para conversão de imagem pode ser a solução que você está procurando. Para uma visão geral completa das técnicas de otimização de imagem, veja otimize imagens para os Core Web Vitals.

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

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 contêiner hero e configurando o background-size desse contêiner para 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 o desempenho. Se você não conseguir evitar totalmente as background images, você pode pelo menos adiar background images que estão abaixo da dobra.

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

A maneira como eu faço é adicionando uma imagem normal em uma posição absolute e configurando a propriedade object-fit dessa imagem para cover. Depois de mudar a background image para uma imagem normal, posso começar a usar imagens responsivas. Se você estiver usando Elementor, confira como corrigir hero images do Elementor.

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

• As hero images agora são carregadas com uma prioridade mais alta
• 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 hero images do domínio principal e considere uma CDN

Muitas vezes, vejo a imagem do largest contentful paint sendo servida de um domínio diferente, por exemplo, 'static.mydomain.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.mydomain.com, por exemplo), as imagens podem ser buscadas muito mais rapidamente através da conexão de servidor já estabelecida.

Quando configurada no domínio principal, uma CDN pode oferecer um grande aumento de velocidade. Especialmente quando seu site é visitado de todo o mundo. Uma CDN tem servidores estrategicamente posicionados em todo o mundo, onde 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 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 haja lazy loading sendo aplicado à sua hero image. Hero images sempre devem carregar com eager.

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

Esses plugins farão o lazy load de imagens que parecem boas candidatas para lazy load. Se a hero image não for uma imagem eager, esses plugins provavelmente também farão 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 é ativado, causará um atraso maior. De acordo com o Web Almanac de 2025, aproximadamente 17% das páginas fazem lazy-load de sua imagem LCP. Isso são 17% dos sites piorando ativamente seu LCP. Se o Lighthouse estiver avisando você sobre isso, veja como corrigir o aviso de imagem LCP com lazy load.

Fazer as imagens carregarem com eager é simples. Basta adicionar loading="eager" à imagem. Observe que eager é na verdade o padrão do navegador. Omitir inteiramente o atributo loading 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 layout shifts causados pela hero image

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

• O elemento hero é criado com JavaScript. Alguns plugins hero e construtores de páginas 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 um call to action e uma tagline. Certifique-se de que essas fontes grandes não causem um layout shift.
• Falta de dimensões da imagem. Quando a hero image não é uma imagem cover (seja como uma background image ou uma imagem com posição absolute), a falta de dimensões da imagem (width e height) certamente causará um grande layout shift.

Embora a correção do layout shift não vá melhorar o Largest Contentful Paint, ela irá melhorar os Core Web Vitals da página. Para obter mais informações sobre como corrigir o layout shift, por favor, leia o guia detalhado sobre como corrigir o Cumulative Layout Shift!

8. Use 2-stage loading para melhorar os Core Web Vitals da hero image

O 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 ser baixada muito antes da imagem maior de alta qualidade. Uma vez que a imagem de baixa qualidade tenha sido pintada na tela, o navegador é acionado para buscar a imagem de alta qualidade em segundo plano. Uma vez que a imagem de alta qualidade tenha sido baixada, a imagem de baixa qualidade será substituída pela imagem de alta qualidade.

Existem 3 métodos de 2-stage loading. Os dois primeiros são métodos que você deve considerar. O último é um que você não deve fazer.

1. 2-stage loading completo

Com o 2-stage loading completo, a primeira imagem de baixa qualidade tem exatamente as mesmas dimensões (width e height) que a imagem original de alta qualidade.

O resultado desse 2-stage loading é que o elemento do largest contentful paint será a imagem muito mais rápida e de baixa qualidade (que será então trocada lazily). A troca da imagem acontecerá tão rápido que um visitante casual provavelmente nunca notará. O resultado dessa técnica é que o LCP é pintado muito antes, a página parece 'pronta' muito mais cedo, o que contribui para uma user experience muito melhor e Core Web Vitals aprimorados.

2. Placeholders inline menores

O placeholder menor é uma técnica muito legal que tem uma desvantagem: ele 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 2-stage loading, 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 pronta ainda mais rápido do que a técnica de 2-stage loading.

3. Placeholders transparentes

Uma técnica comum de 2-stage loading e um método para enganar o navegador e enviar uma métrica de Largest Contentful Paint antecipada é usar 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 cross-browser. 

O lazy loading, obviamente, deve ser aplicado apenas 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. Onde as métricas de paint podem ser ótimas, a UX da página na verdade vai piorar.

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

Juntando tudo

Veja como é uma hero image otimizada quando você combina preloading, fetchpriority, imagens responsivas e carregamento eager:

<!-- In the <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">

<!-- In the <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="Descriptive alt text">

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