Imagem é o que mais pesa na sua página
Na maior parte das landing pages, as imagens respondem sozinhas pela maior fatia dos bytes baixados. É também o item mais fácil de corrigir, e o que quase ninguém corrige, porque o arquivo pesado parece exatamente igual ao leve na tela.
Por que a imagem domina o peso da página
Uma página bem construída tem alguns dezenas de kilobytes de HTML e CSS. Uma única foto tirada com celular moderno tem alguns megabytes. A conta não é próxima: uma foto sem tratamento pesa mais do que todo o resto da página somado, e às vezes mais do que a página inteira multiplicada por cem.
O motivo do descuido é psicológico. Texto pesado você percebe escrevendo. Imagem pesada é invisível: a foto de 6 MB aparece na tela exatamente igual à de 60 KB. Quem sobe o arquivo nunca vê a diferença, porque no computador dele a imagem já está em disco.
E o efeito não é só de peso total. A imagem do topo costuma ser justamente o elemento que define o LCP, a métrica de carregamento que o Google avalia. Otimizar imagem é quase sempre o caminho mais curto para corrigir Core Web Vitals.
Erro número um: subir a imagem no tamanho original
Antes de qualquer conversa sobre formato, existe um erro que sozinho responde pela maioria dos casos: a imagem é servida com muito mais pixels do que o espaço em que ela aparece.
A foto sai da câmera com 4000 pixels de largura. Ela é exibida num cartão de 400 pixels. O navegador baixa os 4000 e joga fora 90% da informação na hora de desenhar. O usuário pagou por dados que nunca chegaram a virar pixel na tela dele.
A regra prática: descubra a maior largura em que aquela imagem aparece no layout e gere o arquivo no dobro disso, para atender telas de alta densidade. Passar disso não melhora nada visível e custa banda em todo acesso.
Formatos: o que usar em 2026 e o que aposentar
| Formato | Use quando | Observação |
|---|---|---|
| AVIF | Foto, quando você consegue gerar variantes | Menor peso na mesma qualidade percebida. Codificação mais lenta na hora de gerar. |
| WebP | Padrão seguro para foto e para gráfico com transparência | Suporte universal nos navegadores atuais. É o ponto de equilíbrio entre ganho e trabalho. |
| SVG | Logo, ícone, ilustração de traço | Vetorial, não perde qualidade em nenhum tamanho, e costuma pesar poucos KB. |
| JPEG | Fallback para navegador antigo | Ainda funciona, mas você paga bytes a mais pela mesma imagem. |
| PNG | Só quando precisa de transparência sem perda | Para foto, é a pior escolha possível. É o formato que mais aparece pesado sem necessidade. |
A troca de PNG por WebP em foto costuma ser a mudança de maior retorno por minuto de trabalho que existe numa página. Não porque WebP seja mágico, mas porque PNG guarda foto de um jeito que nunca foi feito para foto.
Se você quer AVIF sem abrir mão de compatibilidade, o elemento <picture> resolve: você oferece o AVIF, o WebP e um fallback, e o navegador escolhe o primeiro que entende. O custo é ter que gerar mais arquivos.
Sobre qualidade de compressão
Comprimir com perda numa faixa entre 75 e 85 costuma ser indistinguível do original em foto, com uma fração do peso. Acima disso, você paga muito byte por diferença que ninguém enxerga no celular. Abaixo, começam a aparecer manchas em céu, pele e degradê. Vale sempre olhar o resultado antes de padronizar um valor.
Um caso concreto: as miniaturas deste portfólio
Este site mostra as landing pages que eu fiz, com uma miniatura para cada uma. As capturas originais dessas telas somavam cerca de 34 MB. Depois de redimensionar para as larguras realmente usadas no layout e converter para WebP com compressão, o conjunto inteiro que vai para o navegador ficou assim:
581 KB
é o peso somado de todas as miniaturas das landing pages deste portfólio, em duas larguras cada, contra cerca de 34 MB dos arquivos originais. Redução em torno de 98%, sem diferença visível na tela.
Vale ser claro sobre o que esse número é e o que ele não é. Ele não é uma promessa de que a sua página vai ficar 98% mais leve, e não é uma medição de velocidade de carregamento. É o peso de um conjunto específico de arquivos, antes e depois, e o motivo dele ser tão grande é banal: as capturas originais eram PNG em resolução de tela cheia, servidas num espaço muito menor.
É exatamente por ser banal que ele importa. Esse é o estado normal das imagens da maioria das páginas no ar hoje. O trabalho que produziu essa redução levou minutos, não dias.
Nenhuma otimização de código que eu conheça devolve 98% de peso em minutos. Imagem devolve, e é a primeira coisa que deixam de fazer.
srcset e sizes: uma imagem, vários tamanhos
Dimensionar resolve o desperdício médio, mas cria um novo problema: qual tamanho escolher? O ideal para o desktop é grande demais para o celular, e o ideal para o celular fica borrado no desktop.
A resposta nativa do HTML é oferecer várias versões e deixar o navegador escolher. É o que srcset faz. É por isso que as miniaturas deste site existem em duas larguras: uma para telas pequenas e outra para telas maiores.
O atributo que quase todo mundo erra
O srcset lista os arquivos disponíveis com a largura de cada um. O sizes informa ao navegador que largura aquela imagem vai ocupar no layout. Sem o segundo, o primeiro serve de pouco.
O detalhe que quebra tudo: o navegador escolhe a imagem antes de calcular o CSS, para poder começar o download o quanto antes. Ele não tem como saber que aquela foto vive numa grade de três colunas. Ele acredita no que você declarou em sizes.
Por isso o erro mais comum é deixar sizes="100vw" numa imagem que na prática ocupa um terço da tela. O navegador obedece, baixa o maior arquivo da lista, e você fica com toda a complexidade do srcset e nenhum benefício. sizes errado é pior que srcset ausente, porque dá a sensação de que o problema foi resolvido.
Lazy loading, e a exceção que muita gente ignora
O atributo loading="lazy" adia o download de uma imagem até ela chegar perto da área visível. Para uma página comprida, com depoimentos, galeria e rodapé, isso corta uma fatia enorme do que é baixado na abertura. É uma linha por imagem e não exige biblioteca nenhuma.
A regra é simples de decorar: acima da dobra, prioridade alta. Abaixo da dobra, preguiçoso. Se você não sabe onde fica a dobra da sua página, o critério prático é a primeira tela num celular comum.
Por que declarar width e height evita o conteúdo pular
Uma imagem sem dimensões declaradas ocupa zero de altura até o arquivo chegar. Quando ele chega, o navegador descobre o tamanho real e empurra tudo que estava embaixo para baixo. É esse empurrão que faz o texto pular enquanto você lê e o botão sumir debaixo do dedo.
A correção é declarar width e height no HTML com as proporções reais do arquivo. Não são dimensões de exibição: o CSS continua mandando no tamanho final. Elas servem para o navegador calcular a proporção e reservar o espaço antes da imagem existir.
Isso é o que os navegadores modernos fazem automaticamente com aspect-ratio derivado desses dois atributos. É correção de uma linha para um problema que penaliza uma das três métricas avaliadas, e mesmo assim continua ausente na maioria das páginas.
Se a imagem tem proporção variável, ou vem de um sistema que você não controla, reserve o espaço no CSS com aspect-ratio no contêiner. O importante não é o método, é que a altura exista antes do arquivo chegar.
Um fluxo que funciona, do original ao ar
- Corte antes de comprimir. Enquadramento errado desperdiça bytes em pixels que não interessam.
- Redimensione para a maior largura de uso, vezes dois. Esse único passo costuma responder pela maior parte do ganho.
- Converta para WebP na faixa de qualidade de 75 a 85, e olhe o resultado antes de aceitar.
- Gere as variações que o layout precisa e monte o
srcset, comsizesrefletindo o layout de verdade. - Declare
widtheheightem todas. - Marque a do topo com
fetchpriority="high"e todas as outras comloading="lazy". - Escreva o
alt. Descreva o que a imagem mostra para quem não pode vê-la. Imagem puramente decorativa levaaltvazio, não leva descrição inventada.
Nada nessa lista exige ferramenta paga nem pipeline complexo. Exige que alguém decida fazer, uma vez, antes de subir o arquivo. Depois que a página está no ar com 34 MB de foto, o custo de arrumar é o mesmo. A diferença é que nesse meio tempo todo visitante pagou a conta.
Perguntas frequentes
WebP ou AVIF, qual eu devo usar?
Se você precisa escolher um só e quer simplicidade, WebP. Ele tem suporte universal nos navegadores atuais e resolve a maior parte do problema. AVIF entrega arquivos menores na mesma qualidade percebida, mas custa mais tempo para gerar e faz mais sentido quando você já tem um processo automatizado. O ganho de trocar PNG por WebP é muito maior do que o ganho de trocar WebP por AVIF.
Qual o tamanho máximo que uma imagem deveria ter?
Não existe número universal, porque depende do espaço que ela ocupa. O critério certo é relativo: gere o arquivo com o dobro da maior largura em que a imagem aparece no layout. Uma foto de fundo de tela cheia legitimamente pesa mais que a miniatura de um cartão. O que nunca se justifica é servir 4000 pixels de largura num espaço de 400.
Posso simplesmente reduzir a imagem pelo CSS?
Visualmente funciona, e é exatamente isso que torna o problema invisível. O navegador baixa o arquivo inteiro e só depois desenha menor. O usuário paga por todos os bytes e não recebe nada em troca. Redimensionar pelo CSS resolve aparência, nunca peso.
Lazy loading serve para todas as imagens?
Para as que estão abaixo da dobra, sim, e o ganho é grande. Para a imagem principal do topo, não: ela normalmente é o elemento que define o LCP, e adiar o download dela piora justamente a métrica que o Google avalia. Nessa, use carregamento normal com fetchpriority alto.
Vale a pena usar um serviço de otimização de imagem?
Vale quando as imagens mudam com frequência ou são enviadas por outras pessoas, porque aí você precisa de um processo automático e não de disciplina humana. Para uma landing page com um punhado de imagens fixas, o processamento manual uma única vez resolve, custa nada e não adiciona dependência de terceiro na sua página.