Na maioria dos sites que abrimos para diagnosticar, imagem é o maior peso da página, e por uma margem enorme. A boa notícia é que essa é também a parte mais fácil de resolver. Não exige reescrever nada. Exige processo.
Por que imagem é quase sempre o maior peso da página
Faça a conta de uma página comum. O HTML tem alguns quilobytes. O CSS, algumas dezenas. O JavaScript, algumas centenas. E aí entra uma foto tirada com celular, subida direto para o site: sozinha, ela pode ter mais peso do que todo o resto da página somado.
Isso importa por dois motivos. O primeiro é o LCP, a métrica que mede quando o maior elemento visível termina de aparecer, e que na maioria das páginas é justamente a imagem do topo. O segundo é o custo real de quem acessa por dados móveis em uma conexão instável, situação bem mais comum do que a bancada de teste do desenvolvedor sugere. Os limiares dessa métrica estão em Core Web Vitals explicado.
JPEG, PNG, WebP e AVIF: quando usar cada um
| Formato | Suporte nos navegadores | Transparência | Animação | Quando usar |
|---|---|---|---|---|
| JPEG | Universal, inclusive em sistemas antigos | Não | Não | Fallback de fotografia quando o suporte precisa ser absoluto |
| PNG | Universal | Sim | Não (só o APNG) | Logos, ícones, capturas de tela e qualquer imagem com áreas chapadas e bordas nítidas |
| WebP | Todos os navegadores modernos | Sim | Sim | Padrão seguro para praticamente tudo hoje |
| AVIF | Amplo nos navegadores atuais, menor que o do WebP | Sim | Sim | Fotografia grande, onde a compressão superior mais compensa |
A regra prática é simples. WebP substitui JPEG e PNG na maior parte dos casos, mantendo qualidade parecida com arquivos bem menores, e aceita tanto compressão com perda quanto sem perda. AVIF costuma comprimir ainda melhor, especialmente em fotografia, ao custo de uma codificação mais lenta e de um suporte um pouco mais recente.
Para imagens de interface como logos e ícones, existe uma resposta ainda melhor: SVG. É vetorial, escala em qualquer tela sem perder nitidez e normalmente pesa uma fração de qualquer bitmap.
Uma observação sobre GIF, que ainda aparece muito: para animação curta, GIF é o pior formato disponível hoje. Um GIF de poucos segundos costuma pesar vários megabytes, enquanto o mesmo conteúdo em vídeo MP4 ou WebM ocupa uma fração disso, com qualidade melhor. Se a animação não precisa de som nem de controles, um vídeo curto em reprodução automática silenciosa substitui o GIF sem perda nenhuma.
Dimensionar antes de subir
Este é o erro mais comum de todos, e o mais caro. Uma foto de celular sai com algo entre 3000 e 4000 pixels de largura. Se ela vai ser exibida em uma coluna de 800 pixels, o navegador baixa a imagem inteira e depois joga fora a maior parte da informação para desenhá-la pequena. Você pagou pelo tráfego e não ganhou nada em qualidade visível.
Antes de qualquer conversa sobre formato, redimensione. Descubra a maior largura em que a imagem realmente aparece no layout, multiplique por dois para dar conta de telas de alta densidade, e use isso como largura máxima. Uma imagem exibida em 800 pixels raramente precisa de um arquivo com mais de 1600.
Só depois de redimensionar vale falar de qualidade de compressão. Em fotografia, uma qualidade entre 75 e 85 costuma ser indistinguível do original para o olho, com arquivos bem menores.
Aproveite para tirar os metadados. Uma foto de celular carrega dados de câmera, data e, em alguns casos, coordenadas de GPS do local onde foi tirada. Isso pesa, não serve para nada no site e ainda pode expor informação que você não pretendia publicar. A maioria das ferramentas de compressão remove esses dados por padrão, mas vale conferir.
srcset e sizes: imagens responsivas na prática
Um celular não precisa do mesmo arquivo que um monitor grande. O atributo srcset permite oferecer várias versões e deixar o navegador escolher a mais adequada para a tela e a conexão.
srcset="foto-400.webp 400w, foto-800.webp 800w, foto-1600.webp 1600w"O número seguido de w é a largura real do arquivo em pixels. Só isso não basta: o navegador também precisa saber qual espaço a imagem vai ocupar no layout, e é para isso que existe o sizes.
sizes="(max-width: 700px) 100vw, 800px"Lê-se assim: em telas de até 700 pixels, a imagem ocupa toda a largura da viewport; acima disso, ocupa 800 pixels. Sem o sizes, o navegador assume a largura total da tela e tende a baixar um arquivo maior do que o necessário.
Para servir AVIF com fallback automático, use <picture> com várias tags <source>, colocando o formato mais moderno primeiro. O navegador usa a primeira opção que sabe decodificar e ignora o resto. Assim ninguém fica sem imagem.
Lazy loading nativo
Não faz sentido baixar uma imagem que está a três telas de rolagem de distância antes de a pessoa chegar lá. O atributo loading="lazy" resolve isso sem biblioteca nenhuma: o navegador adia o download até a imagem se aproximar da área visível.
Aplique em tudo que está abaixo da dobra: galeria, imagens do meio do texto, cards de listagem, rodapé. O ganho aparece direto no peso inicial da página.
O mesmo raciocínio vale para iframes pesados, como mapas e vídeos incorporados, que também aceitam loading="lazy". Um mapa embutido no rodapé da página de contato pode custar mais que todas as imagens do site somadas, e quase ninguém rola até lá na primeira visita.
O que NUNCA deve ter lazy loading
A imagem do hero, aquela grande no topo da página. Parece contraintuitivo, mas colocar loading="lazy" nela piora a performance de forma mensurável. O motivo é que o lazy loading adia a descoberta e o download da imagem para depois do cálculo de layout, e essa imagem costuma ser exatamente o elemento que define o LCP. Você atrasa de propósito a métrica que quer melhorar.
Para o hero, faça o contrário: use loading="eager" e fetchpriority="high", sinalizando ao navegador que aquele arquivo tem prioridade sobre os demais.
width e height para evitar CLS
Toda imagem deve ter os atributos width e height no HTML, com os valores reais do arquivo. Isso não impede que o CSS a redimensione depois. O que esses atributos fazem é informar a proporção antes de o arquivo chegar, para que o navegador reserve o espaço correto e o texto não pule quando a imagem terminar de carregar.
Sem eles, a página monta com altura zero naquele ponto e depois empurra tudo para baixo. É a causa mais frequente de CLS ruim e uma das mais rápidas de corrigir.
Quando a imagem é recortada por CSS para caber em um espaço fixo, como em um card de listagem, mantenha os atributos com os valores reais do arquivo e controle o recorte com object-fit. Colocar no HTML valores inventados só para bater com o layout distorce a proporção que o navegador usa para reservar espaço, e o resultado é o oposto do pretendido.
Ferramentas gratuitas de conversão e compressão
- Squoosh, do Google, roda no navegador, converte para WebP e AVIF e mostra a comparação lado a lado com o tamanho final de cada opção. Ideal para calibrar a qualidade sem chutar.
- ImageMagick ou cwebp, na linha de comando, quando você precisa converter uma pasta inteira de uma vez.
- SVGO para limpar SVGs exportados de ferramentas de design, que costumam vir com muito metadado inútil.
- Plugins de otimização, se o site roda em CMS, para automatizar conversão e geração de tamanhos no upload.
Mais importante que a ferramenta é a rotina. Quem edita o site precisa saber que imagem não vai da câmera direto para o servidor. Essa combinação, de rotina definida e revisão periódica, é parte do que descrevemos em manutenção de site: a rotina. E vale conferir o item de imagens dentro do checklist de SEO técnico, porque formato e alt andam juntos.
Se as imagens do seu site estão pesadas e você não sabe por onde começar, fale com a ALB Seven. Costuma ser a correção de melhor retorno por hora de trabalho.