Redimensione para a largura real de exibição do seu site, depois comprima com a ferramenta acima — os alvos de tamanho e o raciocínio abaixo ajudam a escolher os números certos para o papel de cada imagem na página.
Alvos de tamanho por função
- Imagens de banner/hero (largura total, visíveis sem rolar): abaixo de 200KB. Esse costuma ser o elemento de Largest Contentful Paint da maioria das páginas, então o tempo de carregamento afeta diretamente uma métrica de Core Web Vitals usada pelo Google no ranqueamento.
- Fotos no meio do conteúdo / blog: abaixo de 100KB. Carregam conforme o usuário rola a página, então são menos críticas que a imagem de hero, mas uma página com 10 ou mais delas a 500KB cada soma um peso que deixa a página genuinamente lenta.
- Miniaturas / imagens de grid de produto: abaixo de 50KB cada. O tamanho pequeno de exibição faz com que compressão agressiva não tenha custo visual, e grids costumam mostrar uma dúzia ou mais de uma vez.
Esses são alvos, não regras rígidas — um site de portfólio fotográfico legitimamente precisa de imagens maiores e mais fiéis que um blog cheio de texto. O ponto é ser deliberado sobre esse trade-off em vez de subir direto o que a câmera ou o celular produziu por padrão.
Por que isso afeta o ranqueamento, não só a experiência do usuário
Os Core Web Vitals do Google incluem o Largest Contentful Paint (LCP): o tempo até o maior elemento visível — geralmente uma imagem de banner ou um título — terminar de renderizar. Esse é um fator de ranqueamento medido, não uma vaga referência a “experiência do usuário”. Um banner de vários megabytes sem otimização pode empurrar o LCP no celular bem além do limite “bom” do Google (2,5 segundos) numa conexão mediana, e isso é suficiente para prejudicar visivelmente o ranqueamento independente da qualidade do conteúdo da página — um risco real no Brasil, onde grande parte do acesso ainda é por celular em conexão 4G.
Redimensionar antes de comprimir, não em vez de
Compressão e redimensionamento resolvem problemas diferentes. Compressão reduz os bits usados para codificar cada pixel; redimensionamento reduz o número de pixels. Se a coluna de conteúdo do seu site tem 900px de largura mas você está servindo uma foto de 4000px de largura (só comprimida no tamanho do arquivo), você está gastando bits codificando detalhe que nenhum navegador vai exibir nessa largura — o mesmo espaço de arquivo aplicado a uma imagem já redimensionada para 900px fica visivelmente mais nítido. Redimensione sempre para a largura máxima real de exibição primeiro.
WebP vs. JPEG para uso web
O WebP costuma ganhar do JPEG por 25-35% na mesma qualidade visual para conteúdo fotográfico, com suporte universal em navegadores modernos. Se o seu CMS ou plataforma suporta, converter JPEGs já comprimidos para WebP é quase uma redução de tamanho de graça. A economia costuma ser ainda maior para gráficos e prints de tela convertidos de PNG — veja a solução relacionada abaixo.
Lazy loading não substitui compressão
Adiar imagens fora da tela com loading="lazy" melhora o carregamento inicial ao não baixar tudo de uma vez, mas cada imagem ainda baixa em peso total assim que entra na tela visível — e sua imagem de hero/LCP é visível imediatamente, então não deveria usar lazy loading de jeito nenhum. Compressão reduz os bytes de fato transferidos; lazy loading só muda quando eles são transferidos.
Perguntas frequentes
- Qual o tamanho de arquivo que uma imagem de site deveria ter?
- Como regra prática: imagem de banner/hero (largura total, visível sem rolar) abaixo de 200KB, fotos no meio do conteúdo ou no blog abaixo de 100KB, e miniaturas ou imagens de grid de produto abaixo de 50KB. Não são limites rígidos — são alvos que mantêm o peso total de imagens de uma página típica numa faixa (mais ou menos 1-2MB no total) que carrega rápido numa conexão móvel mediana, o que é especialmente relevante no Brasil, onde boa parte do tráfego ainda vem de 4G com dados limitados.
- O tamanho da imagem realmente afeta o SEO?
- Sim, de forma indireta mas mensurável. Os Core Web Vitals do Google incluem o Largest Contentful Paint (LCP) — o tempo até o maior elemento visível, geralmente uma imagem de banner, terminar de renderizar — como sinal de ranqueamento. Um banner de 3-5MB sem otimização pode sozinho jogar o LCP de uma página para a faixa 'ruim' em conexão móvel, o que afeta o ranqueamento independente da qualidade do conteúdo da página.
- Devo redimensionar a imagem, comprimir, ou os dois?
- Os dois, nessa ordem. Redimensione primeiro para a largura máxima de exibição real (o corpo de um post de blog raramente passa de 800-1200px de largura mesmo num monitor grande, por causa do max-width do CSS da coluna de conteúdo), depois comprima. Servir uma foto de câmera com 4000px de largura só comprimida no tamanho do arquivo desperdiça bits codificando detalhe que nenhuma tela vai mostrar, quando o mesmo espaço de arquivo aplicado a uma imagem já redimensionada para 1000px fica visivelmente mais nítido.
- Quando usar WebP em vez de JPEG nas imagens do site?
- Quase sempre, para fotos: o WebP costuma gerar arquivos 25-35% menores que o JPEG na mesma qualidade visual, e é suportado por todo navegador lançado desde 2020. Use JPEG só se precisar especificamente de compatibilidade com software bem antigo que processa as imagens do site fora de um navegador (alguns plugins de CMS legados, certos fluxos de impressão a partir da web). Veja converter PNG para WebP para o mesmo trade-off partindo de PNG.
- E o lazy loading — isso significa que não preciso comprimir as imagens?
- O lazy loading (atributo nativo loading="lazy" ou uma biblioteca JS) adia o carregamento de imagens fora da tela até o usuário rolar até perto delas, o que ajuda no carregamento inicial mas não reduz o tamanho final do download — cada imagem ainda baixa em peso total assim que entra na área visível. É um complemento à compressão, não um substituto, e não faz nada pela sua imagem de LCP, que por definição é visível imediatamente e não deveria usar lazy loading de jeito nenhum.