Otimização de imagens

TL;DR — Otimização de imagens significa deixar suas imagens menores para que as páginas carreguem rápido, sem que fiquem feias. Use um formato moderno como WebP, comprima o arquivo e não envie uma imagem muito maior do que o tamanho exibido na tela. A regra que as pessoas mais quebram: a imagem grande no topo da sua página deve carregar imediatamente — nunca use “lazy load” nela. Fazer isso bem não aumenta magicamente seu ranqueamento, nem garante uma pontuação de velocidade aprovada — apenas deixa suas páginas rápidas, e velocidade é o que importa, então verifique seus resultados reais antes e depois.

O que a otimização de imagens realmente faz

As imagens são quase sempre o elemento mais pesado de uma página da web. A documentação do Google diz que “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (tradução) «as imagens costumam ser o maior componente do tamanho total da página, o que pode tornar o carregamento lento e caro». Portanto, otimizar significa reduzir os bytes baixados para que a página apareça rapidamente.

A parte que surpreende as pessoas: o formato em si não é um fator de ranqueamento. Trocar seus JPEGs por WebP não vai elevar suas posições sozinho. O que isso faz é deixar os arquivos menores, o que torna a página mais rápida, e velocidade é o que ajuda. Este é o artigo irmão do hub mais amplo de SEO de imagens — aquele cobre texto alternativo, nomes de arquivo e pesquisa de imagens; este é o guia prático de “faça carregar rápido”.

As poucas coisas que importam

• Use um formato moderno. WebP e AVIF deixam os arquivos muito menores do que JPEGs e PNGs antigos sem piorar a aparência. WebP é o padrão seguro hoje.
• Comprima. Até um WebP pode ser grande demais. Passe as imagens por um compressor e encontre o ponto em que o arquivo é pequeno, mas ainda parece bom.
• Não envie uma imagem gigante para um espaço pequeno. Se uma imagem só aparece com 500 pixels de largura, você não precisa de um arquivo de 3 000 pixels — isso é download desperdiçado.
• Use lazy load em imagens abaixo da dobra. Adicionar loading="lazy" diz ao navegador para esperar até você rolar perto de uma imagem antes de carregá-la. Ótimo para imagens abaixo da dobra.
• Nunca use lazy load na imagem grande do topo. A maior imagem que as pessoas veem quando a página carrega pela primeira vez é aquela que o Google usa para medir sua velocidade. Essa deve carregar imediatamente.

O que a maioria das pessoas entende errado

Eles usam lazy load em tudo — inclusive na imagem hero no topo. Parece inteligente (“carregue menos coisas!”), mas é o contrário: a imagem do topo é aquela contra a qual sua pontuação de velocidade da página é medida, então atrasá-la piora sua pontuação. Carregue-a imediatamente e diga ao navegador que ela é importante. Explico exatamente como na aba Avançado.

Quer a versão precisa — as citações exatas do Google, as compensações entre WebP e AVIF, a matemática de dimensionamento e o truque do fetchpriority — mude para a aba Avançado.

TL;DR — A otimização de imagens é uma disciplina de velocidade de página / Core Web Vitals, não uma alavanca direta de ranqueamento. A escolha do formato (WebP, AVIF) reduz bytes, mas não dá nenhum impulso de SEO — Mueller já disse isso de três maneiras diferentes; também pese transparência, animação e suporte atual do navegador, não apenas a taxa de compressão. A regra mais valiosa: nunca use lazy-load na sua imagem LCP (geralmente o hero); isso atrasa exatamente a métrica que você está otimizando. Dê a ela loading="eager" + fetchpriority="high", embora dicas de prioridade só ajudem em um gargalo de descoberta/tempo de busca, não em todo problema de LCP. O loading="lazy" nativo é para imagens fora do viewport inicial — não uma linha fixa “abaixo da dobra”. A compressão não tem qualidade “certa” universal — teste por tipo de imagem. Dimensões corretas = tamanho do contêiner renderizado × proporção de pixels do dispositivo, e esse tamanho do contêiner em si muda com o layout responsivo, então entregue um intervalo de srcset/sizes (um valor errado de sizes baixa silenciosamente uma imagem superdimensionada) com um fallback <picture>. Imagens são o elemento LCP mais comum na web, por isso este artigo faz referência cruzada com Web Performance — mas nada disso garante uma pontuação Core Web Vitals aprovada, uma mudança de ranqueamento ou mais tráfego; meça antes e depois.

O que a otimização de imagens otimiza (desfaça o mito logo de cara)

Deixe-me acabar com o maior mito antes de qualquer coisa: o formato da imagem é uma alavanca de velocidade, não uma alavanca de ranqueamento. Converter para WebP ou AVIF não garante um aumento de ranqueamento. Garante arquivos menores, que garantem uma página mais rápida, que alimenta o Core Web Vitals — e essa é a parte que os sistemas de busca usam. A cadeia é real, mas indireta, e colapsá-la em “formatos de última geração ranqueiam melhor” é onde a maioria dos guias concorrentes erra.

A documentação do Google é direta sobre por que imagens importam para a velocidade: elas são “frequentemente o maior contribuidor para o tamanho geral da página, o que pode tornar as páginas lentas e caras de carregar”, e o conselho é “aplicar as técnicas mais recentes de otimização de imagens e imagens responsivas para fornecer uma experiência de usuário de alta qualidade e rápida” (Google Search Central — Imagens). Observe o enquadramento: experiência de usuário rápida, não uma recompensa de ranqueamento para o formato do arquivo.

Para o o quê/porquê do SEO de imagens em geral — texto alternativo, nomes de arquivo, sitemaps de imagem, dados estruturados, ranqueamento na busca de imagens — isso é trabalho do hub pai de SEO de Imagens. Este artigo é o como canônico: formatos, compressão, dimensionamento e estratégia de carregamento.

Comece com a regra que todos quebram: nunca use lazy-load na sua imagem LCP

Se você levar uma coisa desta página, leve esta. O elemento Largest Contentful Paint (LCP) — a maior coisa pintada no viewport ao carregar — é “ou uma imagem ou uma fonte da web”, segundo web.dev (Otimize o LCP), e na maioria das páginas é uma imagem: o hero, a imagem em destaque, a foto do produto. web.dev coloca a regra de forma tão direta quanto o Google costuma falar qualquer coisa:

“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (tradução) «Nunca use lazy load na imagem LCP, pois isso sempre causa atraso desnecessário no carregamento do recurso e prejudica o LCP.»

Essa é a nuance que a maioria dos conselhos de “apenas use lazy loading” ignora completamente. Lazy-loading é ótimo — para imagens abaixo da dobra. Aplique-o à imagem LCP e você atrasa ativamente a única métrica que está tentando melhorar. O guia de lazy-loading do web.dev diz o mesmo de outra direção: “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images” (tradução) «Não use lazy-load em imagens que provavelmente estarão no viewport quando a página carregar, especialmente imagens LCP» (Lazy loading em nível de navegador).

Fiz o mesmo argumento no meu artigo sobre LCP no Ahrefs: o maior elemento “geralmente será uma imagem em destaque ou talvez a tag <h1>”, e as correções decorrem disso. “Se você não precisa da imagem, a solução mais impactante é simplesmente se livrar dela. Se você precisa da imagem, sugiro otimizar o tamanho e a qualidade para mantê-la o menor possível.” Você deve “aplicar lazy load em qualquer imagem que não precise imediatamente” — mas o outro lado é uma regra rígida que coloquei em maiúsculas por um motivo: “Não aplique lazy load em imagens acima da dobra!”

fetchpriority="high" na imagem LCP

Não aplicar lazy load no hero é necessário, mas não suficiente. Para garantir que a imagem LCP carregue o mais cedo possível, indique sua prioridade ao navegador. Do web.dev:

“Você pode indicar ao navegador quais recursos são mais importantes usando o atributo fetchpriority… É uma boa ideia definir fetchpriority=\"high\" em um elemento <img> se você acha que ele provavelmente será o elemento LCP da sua página.”

<img src="/hero.webp" alt="…" fetchpriority="high" width="1200" height="675">

No meu artigo sobre LCP, descrevo fetchpriority="high" da mesma forma — ele “pode ser usado em as tags <img> ou <link> e diz aos navegadores para buscar a imagem cedo” — e eu o combino com Early Hints (uma resposta 103) como uma forma complementar de iniciar a busca antes mesmo de o HTML principal chegar. Então a receita para LCP é: carregamento imediato + fetchpriority="high" (+ Early Hints se sua stack suportar). Todo o resto da página pode usar lazy load.

Trate fetchpriority e preload como ferramentas específicas para gargalos, não como uma correção garantida. Eles ajudam quando a imagem LCP é descoberta ou buscada tarde; não fazem nada para uma resposta lenta do servidor, um recurso que bloqueia a renderização antes da imagem ou um arquivo genuinamente grande demais. Confirme qual gargalo você realmente tem (PageSpeed Insights ou Lighthouse divide o LCP em subpartes) antes de assumir que apenas uma dica de prioridade vai mudar o número.

loading="lazy" nativo — grátis, simples e correto abaixo da dobra

Para cada imagem que não está no viewport inicial, o lazy loading nativo é a vitória mais fácil em performance. web.dev: “Você pode usar o atributo loading para aplicar lazy load em imagens sem precisar escrever código de lazy loading personalizado ou usar uma biblioteca JavaScript separada.”

<img src="/below-the-fold.webp" alt="…" loading="lazy" width="800" height="600">

Duas coisas mantêm isso seguro:

• Baseie-se no viewport inicial, não em uma linha fixa de “abaixo da dobra”. “A dobra” não é um número fixo de pixels — ela muda com o tamanho do viewport e o layout. O teste real é se a imagem provavelmente estará visível quando a página for pintada pela primeira vez. Qualquer coisa que estiver — e especialmente a imagem LCP — recebe loading="eager" (o padrão), nunca lazy.
• Prefira o atributo nativo em vez de hacks em JavaScript. Lazy loaders em JavaScript que escondem a URL real em data-src e nunca expõem um src correm o risco de não serem indexados. O loading="lazy" nativo (ou um IntersectionObserver limpo) mantém o src visível para os rastreadores. O hub pai de SEO de Imagens cobre essa ressalva de indexação por completo.

Formatos modernos: WebP vs. AVIF vs. JPEG/PNG

Os formatos são onde a desmistificação mais importa, então vamos ser precisos sobre o que cada um oferece a você — que são bytes, não ranqueamento.

• WebP — “geralmente tem melhor compressão que JPEG, PNG ou GIF, oferecendo compressão com e sem perdas” (web.dev — Image performance). Aproximadamente 25–35% menor que JPEG com suporte quase universal dos navegadores. O padrão seguro para fotos hoje.
• AVIF — “suporta compressão com e sem perdas, e testes mostraram economia maior que 50% em comparação com JPEG em alguns casos.” Compressão de primeira linha, suporte ligeiramente menos universal, então combine-o com um fallback WebP ou JPEG.
• JPEG — o fallback universal para fotografias.
• PNG — quando você precisa de transparência ou gráficos com bordas nítidas.
• SVG — logotipos e ícones: vetorial, escala infinitamente, minúsculo.

O formato a ser escolhido também depende do que a imagem precisa fazer, não apenas de qual comprime mais: transparência, animação e a consistência com que um navegador ou ferramenta suporta essa combinação específica influenciam a escolha, além da economia bruta de tamanho acima — verifique o suporte atual para o recurso exato de que você precisa, especialmente para qualquer coisa animada, antes de se comprometer com um formato como padrão.

O Google Search suporta “BMP, GIF, JPEG, PNG, WebP, SVG e AVIF” referenciados em um src de <img>. Sirva o formato moderno com um fallback gracioso usando <picture>:

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

O <img src> na parte inferior é sua rede de segurança — navegadores e rastreadores mais antigos recorrem a ele, e é o URL que o Google realmente indexa.

O formato afeta o ranqueamento? (Não — e Mueller já disse isso de três maneiras)

Este é o único fio de desmistificação que vale a pena puxar por todo o tópico. Três declarações separadas e independentes de John Mueller chegam à mesma conclusão — o formato afeta a mecânica de rastreamento/indexação e o peso da página, nunca o ranqueamento diretamente:

1. AVIF não dá vantagem de SEO. Depois que o Google adicionou suporte nativo a AVIF, Mueller confirmou que não há “SEO boost” por usar AVIF em vez de outros formatos suportados (cobertura do SE Roundtable).
2. WebP é aceitável. “WebP images are fine for Image Search” (tradução) «imagens WebP funcionam normalmente na pesquisa de imagens» — aceitável, não superior (cobertura do SE Roundtable).
3. As peculiaridades de indexação do WebP não são específicas do formato. Quando as pessoas viram arquivos WebP aparecerem como “Crawled – currently not indexed” no GSC, o ponto de Mueller era que arquivos de imagem não são indexados como páginas HTML, e ele não acreditava que o fenômeno fosse limitado ao WebP (cobertura do SEJ).

Compressão e qualidade: não existe uma configuração “certa” universal

O conselho ruim mais comum em guias de imagem é um único item “comprima para 80%”. O web.dev é explícito que esse número mágico não existe:

“When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (tradução) «Na compressão, não existe uma configuração universal para todos os casos; teste níveis diferentes até equilibrar qualidade e tamanho do arquivo.»

Na prática: teste por tipo de imagem. Fotografias toleram bem compressão lossy agressiva; gráficos, logotipos e capturas de tela com texto mostram artefatos rapidamente e geralmente querem lossless ou uma configuração de qualidade mais alta. Em vez de confiar em um único controle deslizante, exporte a mesma imagem em dois ou três níveis de qualidade e observe-os no tamanho de exibição — o menor que você não consegue distinguir visualmente do original é sua resposta. Esse é um fluxo de trabalho real, não “passe pelo TinyPNG e torça”.

Dimensões corretas: tamanho do contêiner × proporção de pixels do dispositivo

“Apenas deixe menor” não é a regra — corresponder ao tamanho renderizado × a proporção de pixels do dispositivo (DPR) é. Do web.dev:

“An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (tradução) «Uma imagem exibida em um contêiner de 500 por 500 pixels tem tamanho ideal de 500 por 500 pixels.»

“If the device has a DPR of 2 and the image is displayed in a 500 pixel by 500 pixel container, then a square 1000 pixel image… is now the optimal size.” (tradução) «Se o dispositivo tem DPR 2 e a imagem ocupa um contêiner de 500 por 500 pixels, uma imagem quadrada de 1.000 pixels passa a ser o tamanho ideal.»

Então, um contêiner de 500×500 em uma tela 2× (classe Retina) quer uma fonte de 1 000×1 000. Vá maior que isso e você desperdiça bytes sem ganho perceptível; vá menor e fica suave em telas de alto DPR. É por isso que você serve uma faixa de tamanhos e deixa o navegador escolher, usando srcset + sizes:

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 500px"
  alt="…" width="800" height="600" loading="lazy">

O navegador lê a largura do contêiner (sizes) e seu próprio DPR, e então escolhe o candidato certo do srcset — a versão de entrega responsiva da matemática de DPR acima. O Google recomenda <picture> ou srcset para imagens responsivas e diz: “always specify a fallback URL using the src attribute.” (tradução) «sempre especifique uma URL alternativa com o atributo src».

Errar o sizes e nada avisa você. Se o valor que você declarou não corresponder à largura com que a imagem realmente renderiza — um bug comum após uma mudança de layout ou CSS — o navegador não tem como saber disso e simplesmente escolhe um candidato com base no número impreciso que você forneceu, o que normalmente significa que ele baixa um arquivo maior do que o layout precisa. Isso silenciosamente desfaz o trabalho de formato e compressão acima. A única maneira confiável de detectar isso: abra o painel Network do DevTools, encontre a solicitação da imagem e compare as dimensões do arquivo entregue com a largura real renderizada do contêiner.

Esse exemplo de 500×500 acima é ilustrativo, não um número para todo o site que deva ser codificado — a mesma imagem hero pode renderizar em uma largura diferente no mobile do que no desktop, então o “tamanho do contêiner” se move com seu layout responsivo em vez de permanecer fixo. É exatamente por isso que você entrega um intervalo de srcset em vez de exportar um tamanho “ótimo” e considerar o trabalho concluído.

Por que tudo isso se conecta ao Core Web Vitals

O fio condutor que conecta todas as técnicas acima é o LCP. As imagens são o elemento de LCP mais comum na web, e o LCP é um dos três Core Web Vitals. A meta do Google é que o LCP ocorra em até 2,5 segundos no 75º percentil de carregamentos em dispositivos móveis e computadores (web.dev — Vitals). “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (tradução) «Core Web Vitals são o subconjunto aplicável a todas as páginas, devem ser medidos por todos os proprietários e aparecem nas ferramentas do Google».

Então, a otimização de imagens não é um fator de ranqueamento discreto — é um contribuidor para um sinal de experiência de página (Core Web Vitals) que os sistemas de ranqueamento usam. Essa distinção é o enquadramento preciso, e é por isso que este artigo vive tanto no cluster de SEO de Imagens quanto no cluster de Web Performance. Para o mergulho profundo na métrica em si, veja Core Web Vitals e LCP em Web Performance.

Mais uma ressalva que vale a pena declarar claramente: nenhuma das correções nesta página garante qualquer coisa. Os bytes de imagem são apenas um componente possível do LCP — a própria análise do web.dev das subpartes do LCP inclui coisas como tempo de resposta do servidor e recursos que bloqueiam a renderização antes da imagem, nenhum dos quais o formato ou a compressão tocam — e as dimensões da imagem são apenas uma entrada para o CLS, não uma garantia de uma pontuação específica. Reduzir uma imagem hero pode ajudar de forma mensurável, não fazer nada, ou (se outra coisa for o gargalo real) mal mover o número. Otimizar imagens também não garante por si só uma avaliação de Core Web Vitals aprovada, uma mudança de ranqueamento, mais tráfego, mais conversões ou uma citação de busca por IA — essas coisas dependem de muito mais do que bytes de imagem. Trate cada correção de imagem como uma hipótese, não como algo garantido: meça LCP e CLS antes e depois, no laboratório e no campo, e deixe que esses dados — não a suposição de que a otimização “funcionou” — digam se algo mudou.

Armadilhas comuns de implementação

• Imagens de fundo CSS não são indexadas. Devs às vezes trocam um <img> por uma background-image por conveniência de layout. O Google “pode encontrar imagens no atributo src do elemento <img> (mesmo quando ele é filho de outros elementos, como o elemento <picture>)” mas “não indexa imagens CSS.” Se você quer a imagem na pesquisa de imagens, mantenha-a em um <img>. (Este ponto é relacionado a desempenho, mas o erro é comum o suficiente para destacar.)
• Não renomeie em massa arquivos existentes para um “refresh” de desempenho/SEO. Mueller disse que leva “muito tempo” para os sistemas do Google reprocessarem imagens renomeadas e o efeito é mínimo se o seu contexto já for bom — o hub pai de SEO de Imagens cobre isso em detalhes.
• Faltando largura/altura. Sempre defina width e height intrínsecos (ou aspect-ratio em CSS) para que o navegador possa reservar espaço antes de a imagem carregar — isso reduz o layout shift causado por imagens, mas é apenas uma entrada entre várias para o CLS, não uma garantia de uma pontuação específica.

Receita rápida

• Imagem hero / LCP: formato moderno, tamanho correto, loading="eager", fetchpriority="high".
• Tudo abaixo da dobra: loading="lazy".
• Sirva WebP/AVIF com um fallback de src em <picture>.
• Dimensione para o contêiner × DPR; entregue uma faixa de srcset com sizes.
• Comprima por tipo de imagem — teste 2–3 níveis de qualidade, não confie em um único controle.
• Sempre defina width/height.

Para o restante do SEO de imagens — texto alternativo, nomes de arquivo, sitemaps de imagem, dados estruturados e ranqueamento na pesquisa de imagens — volte ao hub de SEO de Imagens.

Resumo de IA

Uma visão condensada da versão Avançada:

• Otimização de imagens = velocidade, não uma alavanca de ranqueamento. A escolha do formato (WebP/AVIF) reduz bytes → página mais rápida → melhores Core Web Vitals. Não há aumento direto de ranqueamento para o formato em si — Mueller confirmou isso de três maneiras diferentes (AVIF “sem aumento de SEO,” WebP “ok,” peculiaridades de indexação do WebP não são específicas do formato).
• A regra nº 1: nunca use lazy-load na sua imagem LCP. A imagem provavelmente visível quando a página é pintada pela primeira vez (geralmente a hero) cronometra seu LCP; usar lazy-load nela atrasa exatamente a métrica que você está corrigindo. Dê a ela loading="eager" + fetchpriority="high" (opcionalmente Early Hints) — embora as dicas de prioridade apenas corrijam um gargalo de descoberta/tempo de busca, não todos os problemas de LCP (verifique as subpartes do LCP antes de assumir que uma dica sozinha ajudará).
• loading="lazy" nativo é gratuito e correto — para imagens fora do viewport inicial, não uma linha fixa de pixels “abaixo da dobra”. Evite lazy-loaders em JS que escondem a URL em data-src.
• Formatos: WebP é o padrão seguro (~25–35% menor que JPEG); AVIF comprime ainda mais (50%+ em alguns testes) com um fallback. A escolha também depende de transparência, animação e suporte atual do navegador/ferramenta, não apenas da taxa de compressão. Sirva via <picture> com um fallback de <img src> que o Google indexa.
• Compressão: não existe qualidade “certa” universal — teste por tipo de imagem (fotos comprimem bastante; texto/gráficos perdem qualidade rápido).
• Dimensionamento: tamanho correto = tamanho do contêiner renderizado × proporção de pixels do dispositivo (contêiner de 500px em DPR 2× = fonte de 1 000px) — e esse tamanho de contêiner em si muda com o layout responsivo, então entregue uma faixa via srcset + sizes em vez de uma única exportação fixa. Um valor errado de sizes silenciosamente faz o navegador baixar um candidato superdimensionado.
• Por que isso importa: imagens são o elemento LCP mais comum; a meta de LCP é 2,5s no 75º percentil. É por isso que isso se cruza com Web Performance — mas o LCP tem outras subpartes (tempo de resposta do servidor, recursos que bloqueiam a renderização) que os bytes de imagem sozinhos não corrigem.
• Sem garantias: otimizar imagens não garante por si só uma pontuação de Core Web Vitals aprovada, uma mudança de ranqueamento, mais tráfego, mais conversões ou uma citação na pesquisa de IA. Meça LCP/CLS antes e depois, no laboratório e no campo.
• Armadilhas: background-image em CSS não é indexada; não renomeie arquivos em massa; sempre defina width/height — isso pode reduzir o layout shift, mas não garante uma pontuação específica de CLS.

Documentação oficial

Documentação de fonte primária dos mecanismos de busca e da equipe do Chrome.

Google / web.dev

• Desempenho de imagens (web.dev “Aprenda Performance”) — formatos, o ponto de “nenhuma configuração universal de compressão” e a matemática de dimensionamento DPR.
• Carregamento preguiçoso de imagens em nível de navegador (web.dev) — como funciona o loading="lazy" nativo e a exceção de “não carregar preguiçosamente imagens no viewport / imagens LCP”.
• Otimize o LCP (web.dev) — fetchpriority, o recurso LCP é uma imagem ou fonte, e “nunca carregue preguiçosamente sua imagem LCP”.
• API Fetch Priority (web.dev) — o explicador completo de fetchpriority="high" para imagens LCP.
• Web Vitals (web.dev) — definições de Core Web Vitals e o limite de LCP ≤ 2,5 s / percentil 75.
• Práticas recomendadas do Google Images — formatos suportados, indexação de <img>/<picture> (não fundos CSS), imagens responsivas e a recomendação de src de fallback.

Bing / Microsoft

• O Bing não publica um guia técnico específico de otimização de imagens tão detalhado quanto o do Google; a orientação relevante está dentro das Diretrizes gerais para webmasters do Bing, que tratam a velocidade da página (incluindo o peso das imagens) como uma consideração. Estou sinalizando isso honestamente em vez de fabricar uma “citação” do Bing que não existe.
• Pesquisa Visual do Bing — pesquisa visual em nível de objeto; relevante para a descoberta de imagens, separada dos efeitos de velocidade de página do formato/compressão.

Citações da fonte

Declarações registradas da equipe do Chrome do Google e dos defensores da Pesquisa. Quando uma página expõe o texto, o link é um link profundo que salta para a passagem citada.

web.dev (equipe do Google Chrome) — as regras de LCP

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (tradução) «Nunca carregue preguiçosamente sua imagem LCP, pois isso sempre levará a um atraso desnecessário no carregamento do recurso e terá um impacto negativo no LCP.» Ir para a citação
• “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.” (tradução) «Não carregue preguiçosamente imagens que provavelmente estarão no viewport quando a página carregar, especialmente imagens LCP.» Ir para a citação
• “It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (tradução) «É uma boa ideia definir fetchpriority=\"high\" em um elemento <img> se você acha que ele provavelmente será o elemento LCP da sua página.» — web.dev, Otimize o LCP.

web.dev (equipe do Google Chrome) — formatos, compressão, dimensionamento

• “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (tradução) «WebP frequentemente tem melhor compressão que JPEG, PNG ou GIF, oferecendo compressão com e sem perdas.» Ir para a citação
• “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (tradução) «AVIF suporta compressão com e sem perdas, e testes mostraram economia de mais de 50% em comparação com JPEG em alguns casos.» — web.dev, Desempenho de imagens.
• “When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (tradução) «Ao comprimir, não existe uma configuração universal adequada para todos os casos. A abordagem recomendada seria experimentar diferentes níveis de compressão até encontrar um bom compromisso entre qualidade de imagem e tamanho do arquivo.» — web.dev, Desempenho de imagens.
• “An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” … “If the device has a DPR of 2 … then a square 1000 pixel image … is now the optimal size.” (tradução) «Uma imagem exibida em um contêiner de 500 por 500 pixels seria dimensionada de forma ideal em 500 por 500 pixels.» … «Se o dispositivo tiver um DPR de 2 … então uma imagem quadrada de 1000 pixels … agora é o tamanho ideal.» — web.dev, Desempenho de imagens.

Google Search Central — por que as imagens importam para a velocidade

• “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (tradução) «as imagens costumam ser o maior contribuinte para o tamanho geral da página, o que pode tornar as páginas lentas e caras para carregar.» Ir para a citação

web.dev — Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (tradução) «Core Web Vitals são o subconjunto de Web Vitals que se aplicam a todas as páginas da web, devem ser medidos por todos os proprietários de sites e serão exibidos em todas as ferramentas do Google.» Ir para a citação

John Mueller, Google — formato não é uma alavanca de ranqueamento

• Sobre AVIF: não há “impulso de SEO” por usar arquivos AVIF. Cobertura
• Sobre WebP: “WebP images are fine for Image Search.” (tradução) «Imagens WebP são adequadas para a Pesquisa de Imagens.» Cobertura

Lista de verificação de otimização de imagens

Execute esta passagem em qualquer página sensível ao desempenho:

• Identificou a imagem LCP (geralmente a imagem hero / imagem em destaque / primeira foto do produto).
• A imagem LCP não é carregada com lazy loading — ela usa loading="eager" (o padrão).
• A imagem LCP tem fetchpriority="high" (considere Early Hints se sua pilha suportar).
• Toda imagem abaixo da dobra tem loading="lazy".
• Formato moderno servido (WebP padrão, AVIF onde suportado) com fallback de src em <picture>.
• Cada imagem é dimensionada para o contêiner × proporção de pixels do dispositivo — sem arquivos de 3 000px em espaços de 500px.
• Entrega responsiva via srcset + sizes onde as imagens são renderizadas em larguras diferentes.
• Compressão testada por tipo de imagem (2–3 níveis de qualidade comparados no tamanho de exibição), não uma configuração única.
• width e height intrínsecos (ou CSS aspect-ratio) definidos em cada imagem para reduzir mudança de layout (CLS) — não é garantia de uma pontuação específica.
• Nenhuma imagem de conteúdo vive apenas em um background-image CSS (essas não são indexadas).
• Lazy loading usa o atributo nativo (ou IntersectionObserver limpo), não um hack de JS que esconde a URL em data-src.
• LCP verificado no campo (CrUX / PageSpeed Insights), visando ≤ 2,5 s no 75º percentil.

Folha de referência de otimização de imagens

As alavancas — o que cada uma faz e a melhor prática

Fatos rápidos

• O formato é uma alavanca de velocidade, não de ranqueamento — Mueller: sem “impulso de SEO” para AVIF; WebP “ok.”
• WebP ≈ 25–35% menor que JPEG; AVIF frequentemente 50%+ menor em testes.
• A regra de maior valor: nunca use lazy-load na sua imagem LCP.
• Meta de LCP: ≤ 2,5s no 75º percentil (mobile + desktop).
• Formatos suportados: BMP, GIF, JPEG, PNG, WebP, SVG, AVIF.
• Tamanho correto = tamanho do contêiner renderizado × proporção de pixels do dispositivo.

O erro que custa sua pontuação de LCP

Usar lazy-load na imagem hero é o erro mais caro abordado neste artigo, e é o que vale destacar por conta própria antes do restante.

• Errado: aplicar loading="lazy" (ou um lazy-loader em JS) à maior imagem acima da dobra — geralmente a hero, a imagem em destaque ou a primeira foto de produto. Por que está errado: essa imagem quase sempre é o seu elemento LCP, e o web.dev é explícito que usar lazy-load nela “sempre causará atraso desnecessário no carregamento de recursos e terá um impacto negativo no LCP.” Você acaba atrasando exatamente a métrica que tentava melhorar. Em vez disso: dê à imagem LCP loading="eager" (o padrão) além de fetchpriority="high", e reserve loading="lazy" para tudo abaixo da dobra.

Confiar em uma única configuração genérica de compressão

• Errado: processar todas as imagens com o mesmo preset “comprimir para 80%” independentemente do conteúdo. Por que está errado: o web.dev diz claramente que “não existe uma configuração universal adequada para todos os casos” — um preset ajustado para fotografias vai comprimir demais logotipos, capturas de tela e gráficos com muito texto, criando artefatos visíveis. Em vez disso: exporte a mesma imagem em dois ou três níveis de qualidade e compare-os no tamanho real de exibição; escolha o menor que você não consiga distinguir do original, por tipo de imagem.

Dimensionar imagens com base no arquivo que você tem, não no contêiner

• Errado: servir qualquer resolução que o arquivo original tenha (ou um único tamanho fixo para cada layout), em vez de adequar a imagem a onde ela realmente é renderizada. Por que está errado: segundo a própria matemática do web.dev, o tamanho correto é o tamanho do contêiner renderizado × a proporção de pixels do dispositivo — um contêiner de 500×500 com DPR 2× precisa de uma fonte de 1 000×1 000, não 500×500 e não 3 000×3 000. Uma fonte maior desperdiça bytes sem ganho visível; uma fonte menor perde nitidez em telas de alto DPR. Em vez disso: entregue uma faixa de srcset com sizes para que o navegador possa escolher o candidato certo para o contêiner e o dispositivo.

Esconder imagens de conteúdo real atrás de CSS

• Errado: trocar um <img> por um background-image por conveniência de layout. Por que está errado: o Google “não indexa imagens CSS” — uma imagem de conteúdo que só existe como background-image fica invisível para a pesquisa de imagens, mesmo que esteja totalmente otimizada em outros aspectos. Em vez disso: mantenha imagens de conteúdo em um <img> (ou como fallback de <img> dentro de um <picture>), e reserve fundos CSS para tratamentos puramente decorativos.

Pular width/height para “economizar marcação”

• Errado: deixar de colocar width e height intrínsecos (ou um aspect-ratio em CSS) nas tags <img>. Por que está errado: o navegador não consegue reservar espaço de layout antes de a imagem carregar, então a página pula conforme cada imagem chega — prejudicando o CLS, o Core Web Vital que acompanha o LCP. Em vez disso: sempre defina width/height (ou aspect-ratio) em todas as imagens, mesmo naquelas que você também está otimizando para formato e tamanho.

Os modelos mentais

1. Nunca use lazy-load na sua imagem LCP. A regra de maior valor em todo o tópico. O maior elemento acima da dobra — geralmente uma imagem — é o que define o tempo do seu LCP. Usar lazy-load nela não economiza nada; apenas atrasa a métrica que você está otimizando. Todo o resto na página é candidato a loading="lazy"; a imagem LCP nunca é.

2. Não existe uma configuração universal de compressão. Trate “qual qualidade devo comprimir?” como uma questão por imagem, não como uma política para todo o site. Fotografias toleram compressão com perdas agressiva; gráficos com muito texto e capturas de tela não. O fluxo de trabalho é comparativo — exporte em dois ou três níveis de qualidade e avalie-os no tamanho de exibição — não um único controle deslizante que você define uma vez e esquece.

3. Tamanho correto = tamanho do contêiner × proporção de pixels do dispositivo. “Menor é melhor” não é a regra; correspondência é. As dimensões ideais da fonte são o tamanho em que a imagem realmente é renderizada, multiplicado pela proporção de pixels do dispositivo — um contêiner de 500×500 em DPR 2× quer uma fonte de 1 000×1 000. Esta é a única fórmula que deve decidir o tamanho de exportação de cada imagem, e é por isso que você entrega uma faixa via srcset em vez de um único arquivo fixo.

4. O formato é uma alavanca de velocidade, não uma alavanca de ranqueamento. Entenda corretamente esta cadeia: escolha do formato → arquivos menores → página mais rápida → melhores Core Web Vitals → um sinal que os sistemas de ranqueamento usam. Pular direto para “formatos de próxima geração ranqueiam melhor” é a maneira mais comum de os guias concorrentes errarem neste tópico — Mueller disse que não há um impulso direto de SEO para o próprio formato, em três ocasiões separadas.

Os KPIs contínuos para velocidade de página orientada por imagens

Estes são os números contínuos que mostram se seu trabalho de otimização de imagens está realmente dando resultado — separados de qualquer imagem individual que você redimensiona ou converte esta semana.

Teste-se: Otimização de Imagens

Cinco perguntas rápidas sobre formatos, compressão, dimensionamento e estratégia de carregamento. Escolha uma resposta para cada uma e depois confira.

Registro de alterações