Que tamanho suas imagens de site devem ter de verdade?

Quase todo conselho sobre esse assunto se resume a «depende» ou a um número sem nenhuma explicação por trás. Aqui estão os números e, depois, o raciocínio, para que você possa ajustá-los quando o seu caso não for o comum.

A tabela

Trate os pesos como metas, não como limites. Uma fotografia cheia de detalhes merece mais bytes que um gráfico chapado. Se você fica sempre 20% acima, tudo bem; se está em quatro vezes o número, algo está errado.

De onde vêm essas larguras

O número que manda é a largura em que a imagem é exibida, não a largura da tela. A maioria dos sites de conteúdo limita a coluna de leitura a algo entre 650 e 800 px, porque linhas longas são mais difíceis de ler. Então uma imagem dentro de um artigo aparece com cerca de 700 px por maior que seja o monitor, e é por isso que 1200 px é generoso, não mesquinho.

As imagens hero são a exceção: elas realmente ocupam todo o viewport, então precisam cobrir uma largura de desktop comum. 1920 px cobre a esmagadora maioria das telas. Ir para 2560 px atende a uma pequena minoria de monitores enormes com um custo real para todo o resto.

A questão retina

As telas de alta densidade colocam dois ou três pixels físicos em cada pixel CSS, então uma imagem exibida a 700 px consegue aproveitar 1400 px de detalhe real. A conclusão ingênua é dobrar todos os números acima. Não faça isso.

Dobrar a largura quadruplica a quantidade de pixels, e o benefício visível cai rápido. Duas coisas melhoram muito esse equilíbrio:

• Comprima mais a versão grande. Uma imagem 2× com 60% de qualidade fica melhor que uma 1× com 90%, e muitas vezes pesa menos. A resolução extra esconde os artefatos.
• Sirva as duas e deixe o navegador escolher. O atributo srcset permite oferecer um arquivo 1× e outro 2×; o navegador baixa só o de que precisa. Essa é a resposta certa se o seu site conseguir fazer isso.

Se você só pode publicar um arquivo, ir para cerca de 1,5× a largura de exibição e comprimir um pouco mais é o meio-termo pragmático. No caso do artigo, isso cai exatamente nos 1200 px da tabela.

A prévia social é um caso à parte

A imagem que aparece quando alguém compartilha o seu link é de 1200 × 630 px e, ao contrário de tudo o mais nesta página, isso é uma especificação, não uma sugestão. Facebook, LinkedIn e X recortam em direção a essa proporção, e errar significa que a sua prévia sai com tarjas pretas ou com as cabeças cortadas.

Duas coisas em que as pessoas tropeçam: qualquer texto em cima dela precisa ser grande, porque muitas vezes ele é exibido a um terço do tamanho dentro de um feed; e o arquivo precisa estar acessível em uma URL absoluta, porque os scrapers não resolvem caminhos relativos.

Como chegar às metas

Redimensionar faz a maior parte do trabalho e a compressão termina o serviço, nessa ordem, porque é no redimensionamento que está a economia de verdade. As duas coisas acontecem em uma única passada no compressor de imagens: escolha a largura máxima da tabela, deixe a qualidade em 75 e ele mostra o antes e o depois em bytes, para você ver se ficou abaixo da meta. Se você precisa de um tamanho exato em pixels em vez de um teto — um espaço de banner que pede exatamente 1200 × 628, digamos — o redimensionador de imagens aceita os números direto.

Processar em lote importa mais do que parece. Vinte fotos de produto de 3 MB cada uma são 60 MB de peso de página que deveriam ser cerca de 3 MB. Fazer uma por uma é o jeito de largar o trabalho no meio.

O que realmente quebra quando você erra

Os Core Web Vitals do Google incluem o Largest Contentful Paint, que mede quanto tempo o maior elemento visível leva para aparecer. Na maioria das páginas esse elemento é uma imagem, então um hero grande demais é medido diretamente como página lenta, e os Core Web Vitals entram no ranqueamento.

Também existe um custo mais simples. Quem entra pelo celular com sinal fraco paga por cada byte e vai embora muito antes de o seu hero de 6 MB terminar de chegar. Essa pessoa nunca aparece no analytics como rejeição, porque a página nunca carregou o suficiente para registrar a visita.

Mais uma coisa que vale a pena além do tamanho

Adicione os atributos width e height às suas tags <img>, com as dimensões reais. Assim o navegador reserva o espaço exato antes de a imagem chegar, em vez de refazer o layout quando ela aparece. Esse salto é o Cumulative Layout Shift, o outro Core Web Vital, e é o que faz você tocar no botão errado porque a página pulou. Custa dois atributos e resolve o problema por completo.

Última atualização 19 de setembro de 2026