Como o tamanho das imagens afeta a velocidade do seu site
Se o seu site parece lento, as imagens são o primeiro lugar para olhar. Na maioria dos sites, elas representam mais peso total de página do que todos os outros recursos somados — HTML, CSS e JavaScript incluídos. Isso também as torna o ponto de maior alavancagem para corrigir, já que um punhado de imagens bem comprimidas pode tirar segundos de um carregamento que uma dúzia de pequenos ajustes de código não conseguiria.
Onde as imagens realmente prejudicam: Core Web Vitals
Os Core Web Vitals do Google são as métricas de velocidade que entram no ranking de busca, e as imagens influenciam diretamente duas das três:
- Largest Contentful Paint (LCP): quanto tempo leva para o maior elemento visível da página renderizar. Na maioria das páginas, esse elemento é uma imagem — um banner principal, a foto de um produto, a imagem de capa de um post do blog. Uma imagem pesada e não otimizada é uma das causas isoladas mais comuns de um LCP ruim.
- Cumulative Layout Shift (CLS): o quanto o conteúdo se movimenta enquanto a página carrega. Isso não tem a ver diretamente com o tamanho do arquivo, mas com imagens que carregam sem ter suas dimensões reservadas com antecedência, fazendo o resto da página se deslocar assim que elas aparecem.
Se você já rodou uma página no PageSpeed Insights ou no Lighthouse e viu "Largest Contentful Paint" marcado em vermelho, há uma boa chance de uma imagem ser a causa.
O que realmente faz diferença
Em ordem aproximada de impacto:
- Comprimir antes de enviar, não depois. Uma foto direto do celular ou da câmera costuma pesar de 3 a 10 MB. A mesma imagem, bem comprimida, pode ficar em algumas centenas de KB sem diferença visível no tamanho normal de visualização. Só esse passo geralmente já representa o maior ganho.
- Servir as imagens no tamanho em que elas realmente aparecem. Uma foto de 4000px de largura exibida em uma coluna de blog de 600px só desperdiça banda: o navegador baixa os 4000px inteiros de dados mesmo assim, só para reduzi-la visualmente. Redimensione para algo próximo do tamanho real de exibição antes de enviar.
- Usar um formato moderno. O WebP já é seguro para usar em qualquer lugar hoje e costuma sair 25-35% menor que um JPG equivalente com a mesma qualidade visual; o AVIF pode ficar ainda menor onde há suporte. (Cobrimos essas diferenças em WebP vs JPG vs PNG vs AVIF.)
- Reservar espaço para as imagens antes de carregarem. Definir uma largura e altura explícitas (ou um aspect-ratio) nas tags de imagem permite que o navegador reserve o espaço certo imediatamente, em vez de deslocar o layout quando a imagem chega — isso é o que realmente resolve o CLS.
- Carregar de forma preguiçosa (lazy-load) o que está abaixo da dobra. Imagens que o visitante ainda não rolou até ver não precisam carregar imediatamente, e a maioria dos navegadores modernos já suporta isso com um único atributo HTML (
loading="lazy"), sem precisar de ferramentas extras.
Os passos 1 a 3 têm a ver com o peso do arquivo. Os passos 4 e 5 têm a ver com como o navegador lida com esse peso enquanto a página carrega. Os dois importam, mas se você só puder fazer uma coisa hoje, é comprimir suas imagens direito — é o que tem a melhor relação entre esforço e impacto dos cinco.
Como saber em que situação seu site está
Antes de chutar, meça. O PageSpeed Insights (a ferramenta do próprio Google, construída sobre o Lighthouse) mostra o LCP e o CLS reais de qualquer URL pública, e aponta especificamente quais imagens são as maiores vilãs. É gratuito, leva uns 30 segundos, e te diz exatamente onde focar em vez de otimizar no escuro.
Fazendo a parte da compressão do jeito certo
O erro mais comum não é pular a compressão — é usar uma ferramenta que envia suas imagens para o servidor de outra pessoa para processá-las, o que é mais lento e significa que uma cópia do seu conteúdo (possivelmente ainda não publicado) fica em algum lugar fora do seu controle enquanto é processada.
Os passos 1 e 3 da lista acima, comprimir e converter entre JPG, PNG, WebP e AVIF, acontecem direto no seu navegador com o img-compress. Ele também lê fotos HEIC (o padrão do iPhone) no Safari, e nada é enviado para lugar nenhum: igual de rápido tanto para uma única imagem principal quanto para um lote inteiro de fotos de produto antes do lançamento de um site. (Redimensionar para as dimensões corretas de exibição, o passo 2, ainda vale a pena fazer no seu editor de imagens ou CMS antes de chegar a essa etapa.)