Como Redimensionar Imagens para a Web: Tamanhos, Retina e srcset

Última atualização: June 28, 2026

Eu redimensionei a mesma foto de capa de quatro maneiras e medi a diferença: um JPEG de câmera de 4.2MB, servido como está em um slot de exibição de 800px, virou um WebP de 94KB sem perda visível de qualidade. Redimensionar imagens para a web é o ganho de peso de página mais significativo disponível, e a maior parte disso se deve a quatro decisões: tamanho de exibição, fator retina, formato e compressão. Este é o fluxo de trabalho que eu executo em todos os sites que lanço.

Resposta rápida: como você deve redimensionar imagens para a web?

Redimensione cada imagem para aproximadamente o dobro da largura em que ela é renderizada (o fator retina), exporte-a como WebP, comprima para qualidade 80 e envie uma curta escada srcset para que celulares e laptops recebam um arquivo adequado. Para uma capa de largura total que exibe em 1920px, geralmente basta um único WebP de 1920 a 2560px com qualidade 80. Pular isso força cada dispositivo a baixar pixels de resolução desktop.

Qual deve ser o tamanho real de uma imagem web?

O tamanho correto é o tamanho de exibição, não o tamanho da fonte. Abra as DevTools, inspecione a imagem, leia a maior largura da caixa CSS que ela ocupa em todos os breakpoints e, em seguida, exporte para essa largura multiplicada pelo seu alvo de densidade.

Para a maioria das imagens de artigos e produtos que caem em uma faixa previsível. Eu meço cada slot antes de exportar, porque adivinhar é como uma foto de 4000px acabar em uma coluna de 600px.

Nunca deixe o CSS fazer o downscaling. Um <img> estilizado para width: 400px ainda baixa o arquivo completo — o navegador descarta os pixels extras depois que os bytes já estão no fio. Redimensione a fonte primeiro e, em seguida, confie no CSS apenas para layout.

Passo a passo: meu fluxo de trabalho de redimensionamento

Esta é a sequência exata que eu executo. Testei isso contra uma auditoria de imagens do Lighthouse e ele consistentemente passa na verificação de "imagens dimensionadas corretamente".

• Meça a maior largura renderizada com DevTools.
• Multiplique por 2 para retina (3x apenas para fotos de capa densas em celulares).
• Redimensione com um filtro de alta qualidade (Lanczos).
• Exporte como WebP com qualidade 80, diminuindo para 75 se o arquivo ainda estiver pesado.
• Gere uma escada srcset para slots responsivos.
• Comprima novamente se o arquivo ainda estiver acima de 200KB.

from PIL import Image

def resize_for_web(src, out, max_width=1440, quality=80):
    img = Image.open(src)
    if img.width > max_width:
        ratio = max_width / img.width
        img = img.resize((max_width, int(img.height * ratio)),
                         Image.LANCZOS)
    img.save(out, "WEBP", quality=quality)

Quando eu medi, isso transformou uma foto de 4000x2667 (JPEG de 4.2MB) em um WebP de 1440x960 com 94KB — uma redução de 98% sem perda visível de nitidez em uma tela padrão. As regras mais profundas para manter detalhes através de downscaling agressivo estão em manter qualidade ao redimensionar.

Retina e 2x: você realmente precisa do dobro dos pixels?

Na maioria das vezes, sim, para qualquer coisa que os usuários olhem de perto. Uma tela 2x empacota quatro vezes mais pixels no mesmo espaço físico, então um arquivo 1x parece suave. A regra segura: exporte na largura 2x da CSS para imagens de conteúdo.

Onde eu deliberadamente quebro essa regra:

• Fundos decorativos que desfocam ou desaparecem podem permanecer perto de 1x.
• Imagens abaixo da dobra onde a nitidez é menos crítica podem usar 1.5x.
• Ícones e logotipos são melhores como SVG, que é independente de resolução.

O guia de imagens web do Google recomenda descritores de densidade ou descritores de largura; os descritores de largura via srcset são mais fáceis de entender, então é isso que eu defino por padrão.

Servindo variantes responsivas com srcset

Um arquivo por imagem raramente está certo para todos os dispositivos. Um celular não precisa de um arquivo de 1440px, e um monitor 4K não deve se contentar com um de 480px. srcset permite que você ofereça várias larguras e deixe o navegador escolher.

<img
  src="hero-960.webp"
  srcset="hero-480.webp 480w, hero-720.webp 720w,
          hero-960.webp 960w, hero-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  alt="Ilustração de capa de um horizonte urbano ao anoitecer"
  width="960" height="640" loading="lazy">

O atributo sizes deve dizer a verdade sobre o slot renderizado. Se você o deixar no padrão 100vw, o navegador assume que a imagem abrange todo o viewport e baixa a variante maior. Escolher quais larguras gerar é uma decisão por si só — o método que uso para aparar a escada está em breakpoints de imagens responsivas.

Tamanho do arquivo vs. dimensões: o que importa mais?

Ambos importam, mas por razões diferentes. As dimensões decidem a contagem de pixels; a compressão e o formato decidem os bytes por pixel. Uma imagem com tamanho correto, mas má compressão, ainda é pesada, e uma imagem minúscula, mas excessivamente comprimida, parece quebrada.

O alvo que eu busco é abaixo de 200KB para a maioria das imagens de conteúdo e abaixo de 100KB para qualquer coisa acima da dobra que alimenta o Largest Contentful Paint. Quando um arquivo ultrapassa esse limite, a primeira alavanca que puxo é a qualidade de compressão, depois o formato. O detalhamento em nível de byte de como a compressão economiza peso está em comprimir sem perder qualidade.

O Lighthouse sinaliza imagens superdimensionadas como uma oportunidade concreta. Execute-o no Chrome DevTools ou siga a documentação do Lighthouse — a auditoria de "imagens dimensionadas corretamente" relata exatamente quantos KB você desperdiça ao servir mais pixels do que o slot precisa.

Escolhendo o formato certo

O formato é onde muitos bytes se escondem. Eu defino WebP para quase tudo fotográfico, com AVIF onde posso pagar por um fallback. Corresponder o formato ao conteúdo importa tanto quanto as dimensões: um PNG usado para uma foto é mais pesado que o mesmo arquivo como WebP sem benefício.

O guia de imagens responsivas do MDN cobre o elemento <picture> para servir AVIF com um fallback WebP ou JPEG. Eu busco por <picture> apenas quando preciso de negociação de formato; para fotos responsivas simples, srcset sozinho é suficiente.

Erros que vejo ao auditar sites

Quando eu audito um site lento, os problemas de imagem se repetem. Estes são os que eu corrijo com mais frequência.

• Fazer upload de arquivos na resolução da câmera e redimensioná-los com CSS.
• Um arquivo gigante para cada breakpoint em vez de uma escada srcset.
• Esquecer width e height, o que causa layout shift.
• Deixar sizes no padrão para que o navegador pegue o maior arquivo.
• Carregar todas as imagens com pressa em vez de adiar as abaixo da dobra.

Este último item é performance gratuita. O padrão para adiar imagens fora da tela está coberto em carregamento lento de imagens — adicione loading="lazy" e o navegador pula imagens que o usuário ainda não rolou até.

Resumo

Antes de lançar uma imagem, eu passo por esta lista: redimensionada para 2x da maior largura de exibição, exportada como WebP, comprimida abaixo de 200KB, com uma escada srcset, um atributo sizes verdadeiro, width e height explícitos, loading="lazy" abaixo da dobra e texto alt descritivo.

Um aviso real: redimensionar é a maior alavanca, mas não é o trabalho inteiro. Eu vi equipes acertarem as dimensões e ainda assim lançarem páginas lentas porque serviram arquivos da origem sem cache, sem CDN e sem nome de arquivo com hash de conteúdo. Meça com Lighthouse e perfis reais de dispositivos, e então confie nos números em vez da lista de verificação. Um WebP de 94KB que o navegador baixa novamente a cada navegação ainda é um erro de 94KB.

Perguntas frequentes

Qual deve ser o tamanho de uma imagem de capa web?

Combine com o tamanho de exibição: aproximadamente 1600px de largura para uma capa de largura total, 800–1200px para uma imagem em coluna de conteúdo. Exportar na largura 2x da exibição (para retina) dobra os pixels; sirva o tamanho certo por dispositivo com srcset em vez de enviar um arquivo enorme.

Preciso de imagens 2x para telas retina?

Para gráficos nítidos e fotos de capa, sim — as telas retina mostram suavidade caso contrário. Para abaixo da dobra e imagens decorativas, um único arquivo 1x é frequentemente suficiente. Use srcset para servir variantes 1x e 2x para que dispositivos não-retina não baixem o arquivo grande.

O que importa mais, dimensões ou tamanho do arquivo?

Ambos, mas o tamanho do arquivo move mais os Core Web Vitals. Redimensione primeiro para as dimensões de exibição (elimina pixels desperdiçados), depois comprima para uma qualidade alvo (elimina bytes desperdiçados). O guia de velocidade web cobre a ordem completa.

Como eu sirvo variantes responsivas?

Use srcset com fontes específicas de tamanho e um atributo sizes descrevendo a largura de exibição, deixando o navegador escolher o arquivo certo por viewport. Gere cada tamanho a partir do mestre, e então deixe o navegador escolher. Veja o guia de imagens responsivas.

O que é srcset?

Um atributo HTML que lista múltiplas fontes de imagem em diferentes tamanhos, deixando o navegador escolher o certo por viewport. Ele serve um arquivo pequeno para uma tela pequena e um arquivo grande para uma tela grande, economizando bytes. Veja o guia de imagens responsivas.

O que é o atributo sizes?

Um atributo HTML que diz ao navegador quão larga a imagem exibe em cada breakpoint, para que o navegador possa escolher a fonte srcset certa antes de baixar. Sem sizes, o navegador adivinha. Combine srcset (as fontes) com sizes (as larguras de exibição) para imagens responsivas que baixam eficientemente. Veja o guia de imagens responsivas.

Créditos das imagens

• Um MacBook em uma mesa mostrando um layout de site desenhado — foto por Tranmautritam em Pexels
• Close-up de um monitor de computador mostrando linhas de código fonte — foto por Nemuel Sereti em Pexels
• Tela de um laptop mostrando um site carregando em uma aba do navegador — foto por cottonbro studio em Pexels