A Coisa Mais Pesada na Sua Página Provavelmente É uma Imagem

Quando abrimos qualquer página web, vemos texto, botões, animações e talvez alguns vídeos. Mas a coisa mais pesada nessa página é quase sempre uma imagem. Não é um vídeo, não é uma fonte, não é um bundle de JavaScript. É um arquivo de imagem.

Você pode tentar abrir o DevTools do navegador em qualquer site, ir à aba Network, filtrar por Img e ordenar por tamanho de arquivo. As chances são de que você vai encontrar algo surpreendente: um punhado de arquivos de imagem que anão em comparação com tudo mais na página. O JavaScript, o CSS, as fontes — tudo isso combinado frequentemente pesa menos do que uma única fotografia hero.

Isso não é acidente. De acordo com o HTTP Archive's 2025 Web Almanach, a página desktop mediana pesa agora 2,9 MB e tem crescido aproximadamente 7 a 8 por cento a cada ano. As imagens respondem por mais de 1 MB disso — mais do que o JavaScript em bytes brutos, apesar de o JavaScript receber toda a atenção de performance. No mobile, onde as conexões são mais lentas e as CPUs são mais fracas, as mesmas imagens chegam com a mesma contagem de bytes.

A maioria dos desenvolvedores já sentiu esse problema. Uma página que carrega instantaneamente em um servidor de desenvolvimento local com uma máquina rápida e uma conexão cabeada se comporta de forma muito diferente para um usuário em um celular intermediário, em 4G, em um país onde a latência de rede é alta. A diferença entre "funciona bem pra mim" e "está lento demais para usuários reais" é frequentemente explicada inteiramente por imagens.

O que é menos óbvio é que a compressão é apenas metade da resposta. Às vezes nem é a metade mais importante.

Existem Duas Formas Completamente Diferentes de uma Imagem Ser Grande Demais

Quando desenvolvedores pensam em otimização de imagens, normalmente pensam em compressão: passar o arquivo por uma ferramenta, reduzir a configuração de qualidade, diminuir os bytes. Essa é uma técnica legítima e importante. Mas não é onde vêm as maiores economias na maioria dos sites.

Os dois problemas são distintos e precisam ser tratados na ordem correta:

1: A imagem tem o tamanho errado para seu contêiner

As dimensões do arquivo de imagem são muito maiores do que as dimensões do elemento em que ela é renderizada. Esse é o problema mais comum, e é o que causa mais desperdício. Já vi casos em que "desenvolvedores" (leia-se designers) enviavam 2.400 pixels de imagem para um elemento do navegador que a renderizaria com 600 pixels de largura. O navegador baixa todos os 2.400 pixels, decodifica todos os 2.400 pixels na memória e depois reduz a escala da imagem para exibição. Os pixels extras nunca foram mostrados ao usuário. Foram desperdiçados por completo.

2: A imagem tem o tamanho certo, mas está codificada de forma ineficiente

As dimensões são adequadas, mas o formato do arquivo está desatualizado (um JPEG de 2012), a configuração de qualidade está em 100 "só pra garantir", ou o arquivo nunca foi comprimido desde que saiu de uma câmera ou ferramenta de design.

Ambos os problemas desperdiçam largura de banda. O primeiro problema desperdiça muito mais, e afeta cada visitante do seu site independentemente do dispositivo ou velocidade de conexão.

A ordem correta é sempre servir as dimensões corretas e depois comprimir essas dimensões de forma eficiente. Comprimir uma imagem de 2.400px que deveria ter 400px de largura ainda entrega cinco vezes mais pixels do que o navegador jamais utilizará. Nenhuma quantidade de compressão corrige isso.

O Problema de Dimensionamento em Números Reais

Vamos tornar isso concreto, porque os números são impactantes o suficiente para mudar permanentemente a forma como você pensa sobre isso.

Pegue uma fotografia baixada do Unsplash ou exportada de uma câmera. Uma DSLR típica fotografa em torno de 7.000 por 4.700 pixels e produz um JPEG de aproximadamente 4 a 5 MB. Um fotógrafo pode exportar esse arquivo e um desenvolvedor pode colocá-lo diretamente em um projeto como imagem hero ou ilustração de um post de blog.

Essa imagem será exibida com no máximo cerca de 1.200 a 1.400 pixels de largura na maioria dos layouts desktop, e de 375 a 430 pixels de largura na tela de um celular típico. A diferença entre o original e o que é realmente renderizado no mobile não é pequena.

Redimensionar essa imagem de 7.000 pixels para 1.266 pixels de largura (adequado para uma tela desktop retina) reduz o tamanho do arquivo de 4,3 MB para 495 KB. Isso representa uma redução de 89% antes de qualquer compressão ser aplicada. Antes de tocar em um controle de qualidade. Antes de mudar o formato. Apenas combinando as dimensões da imagem ao contêiner em que ela realmente será exibida.

Agora aplique compressão nessa imagem corretamente dimensionada: um JPEG com qualidade 75 a leva para cerca de 161 KB. A economia acumulada ao dimensionar corretamente e depois comprimir é de aproximadamente 96% do tamanho original do arquivo.

Essa é a ordem de magnitude de desperdício que acontece todo dia em sites onde as imagens vêm diretamente de ferramentas de design ou bibliotecas de imagens sem nenhuma etapa de redimensionamento.

O Que "Otimização" Realmente Abrange

Otimização de imagens é um termo guarda-chuva para vários problemas relacionados, mas distintos. Tratá-la como "apenas compressão" é o motivo pelo qual tantos sites ainda têm performance ruim de imagens mesmo depois de alguém ter oficialmente "otimizado" as imagens.

Veja como é o panorama completo:

Dimensões. A imagem tem o número correto de pixels para o espaço que ocupa? Uma imagem de barra lateral que renderiza com 300px de largura não deveria ser servida com 2.000px de largura.

Dimensionamento responsivo. Dispositivos diferentes têm telas diferentes. Um usuário desktop e um usuário mobile visitando a mesma página devem receber imagens dimensionadas para seus respectivos viewports, não o mesmo arquivo. É isso que os atributos srcset e sizes do HTML resolvem.

Formato. A imagem está usando um formato moderno e eficiente? JPEG é universal, mas ineficiente. WebP produz a mesma qualidade visual com arquivos aproximadamente 30% menores. AVIF chega a 50% menor. Escolher o formato certo é a segunda alavanca depois de acertar as dimensões.

Compressão. Para formatos com perdas, a configuração de qualidade controla quão agressivamente o codificador descarta dados. Ajustar isso corretamente (nem muito alto, nem muito baixo) é a compressão no sentido tradicional.

Estratégia de carregamento. Quando a imagem é baixada? Imagens abaixo da dobra não devem bloquear o carregamento inicial da página. O atributo loading="lazy" instrui o navegador a adiar esses downloads. A imagem hero, por outro lado, deve ser tratada como um recurso prioritário, não como algo a ser carregado de forma lazy.

Entrega. De onde vêm as imagens e com que rapidez a CDN que as serve responde? Isso está fora do escopo desta série, mas mesmo imagens perfeitamente otimizadas podem ser lentas se servidas de uma origem distante sem cache.

Esta série aborda todos os pontos acima, exceto entrega, construindo desde os fundamentos da escolha de formato até um pipeline completo de otimização client-side em Svelte 5.

Por Que Isso Continua Acontecendo

Se imagens superdimensionadas são um problema tão comum e custoso, por que persistem? A resposta é principalmente fricção, não ignorância.

Um designer exporta uma imagem hero do Figma em 2x para telas retina e a envia ao desenvolvedor. Parece ótimo. O desenvolvedor a coloca em static/. Ainda parece ótimo em desenvolvimento. Ninguém sinaliza durante a revisão. Vai para produção.

Um editor de conteúdo faz upload de uma fotografia para um post de blog. O CMS a aceita e armazena. Ninguém configurou redimensionamento automático. O original de 5 MB é servido para cada visitante.

Um desenvolvedor adiciona uma nova seção a uma página de marketing, copia uma URL de imagem da biblioteca de assets da marca e a cola em uma tag <img>. A imagem da biblioteca tem 4.000 pixels de largura. A seção tem 800 pixels de largura. Ninguém verificou.

Nenhuma dessas pessoas estava sendo descuidada. Elas estavam fazendo seus trabalhos corretamente dentro do sistema que tinham. O problema é que o estado padrão da maioria dos fluxos de trabalho de publicação web é servir qualquer imagem que o criador fez upload, nas dimensões em que foi criada, para cada dispositivo que visita a página.

A otimização requer intervenção deliberada. Sem uma ferramenta, um processo ou um framework que torne a coisa certa o padrão, a coisa errada acontece automaticamente.

Abra o DevTools em qualquer página web e execute uma auditoria do Lighthouse (DevTools → Lighthouse → Performance). Procure duas entradas específicas na seção Opportunities: "Properly size images" e "Serve images in next-gen formats". Essas duas auditorias sozinhas revelam a maior parte do desperdício de imagens em um site típico. O Lighthouse mostra a economia estimada em kilobytes e tempo de carregamento para cada imagem que sinaliza, tornando o problema impossível de ignorar.

A Diferença Mobile Torna Isso Urgente

Tudo o que foi dito acima é mais grave no mobile, e o mobile é de onde vem a maioria do tráfego web.

Uma imagem hero de 2.400px exibida em um viewport mobile de 390px está transmitindo mais de 37 vezes mais pixels do que o navegador vai renderizar. Todos esses bytes extras são baixados por uma conexão mobile, decodificados por uma CPU mais fraca e então descartados. A bateria, o plano de dados e o tempo do usuário são todos gastos em pixels que nunca foram visíveis.

O Google usa indexação mobile-first desde 2019, o que significa que a versão mobile da sua página determina seu ranking de busca. Problemas de performance de imagem que só aparecem no mobile (pontuações ruins de Largest Contentful Paint, First Contentful Paint lento, alto Cumulative Layout Shift) afetam diretamente onde sua página aparece nos resultados de busca, não apenas a velocidade de carregamento.

A implicação prática é que o dimensionamento de imagens deve ser resolvido por breakpoint, não escolhendo uma resolução "média" e torcendo para que funcione. Uma imagem corretamente dimensionada para um hero desktop e uma imagem corretamente dimensionada para um hero mobile são arquivos diferentes. Servir ambas corretamente é exatamente para o que srcset e o elemento <picture> existem.

Para Onde Esta Série Avança

As primeiras lições são sobre fundamentos: entender formatos (Lição 1), entender as ferramentas (Lição 2) e construir um primeiro compressor funcional (Lição 3). Os problemas de dimensionamento e dimensionamento responsivo são abordados diretamente nas Lições 7 e 8, onde você vai construir os componentes ResponsiveImage e LazyImage que lidam com o dimensionamento correto em todos os breakpoints.

Ao final da série, você terá:

Um modelo mental para qual formato usar e por quê, para cada tipo de imagem
Um pipeline de compressão client-side que processa imagens no navegador sem custo de servidor
Componentes que servem imagens corretamente dimensionadas para cada dispositivo usando srcset, sizes e o elemento <picture>
Uma estratégia de carregamento que prioriza imagens acima da dobra e adia todo o resto
Auditorias do Lighthouse aprovadas para as oportunidades relacionadas a imagens

O objetivo não é fazer o tratamento de imagens parecer complicado. É tornar as escolhas certas as automáticas, para que o estado padrão da sua aplicação SvelteKit seja "imagens são tratadas corretamente" em vez de "imagens são o que o editor de conteúdo fez upload na última terça-feira."

Principais Conclusões

Imagens respondem por mais de 1 MB dos 2,9 MB do peso mediano de uma página desktop em 2025; elas são o tipo de recurso mais pesado em bytes, mais pesadas do que o JavaScript.
Imagens superdimensionadas (dimensões erradas para seu contêiner) são frequentemente um problema maior do que imagens não comprimidas. Redimensionar uma foto de DSLR de 4,3 MB para suas dimensões reais de exibição reduz o tamanho do arquivo em 89% antes de qualquer compressão ser aplicada.
A otimização de imagens abrange seis problemas distintos: dimensões, dimensionamento responsivo, escolha de formato, compressão, estratégia de carregamento e entrega. Tratá-la como "apenas compressão" ignora as intervenções mais impactantes.
A diferença mobile torna isso urgente: uma imagem hero de 2.400px em uma tela mobile de 390px transmite 37 vezes mais pixels do que o navegador vai renderizar, e a indexação mobile-first do Google significa que isso afeta diretamente o ranking de busca.

Leitura Adicional

HTTP Archive 2025 Web Almanac: Page Weight - dados de origem para as estatísticas de peso de página neste artigo
HTTP Archive 2024 Web Almanac: Media - análise detalhada do uso de formatos de imagem, bits por pixel e tendências de compressão
web.dev: Image Performance - guia autoritativo do Google cobrindo srcset, sizes, lazy loading e dicas de prioridade
MDN: Responsive Images - a referência completa para srcset, sizes e o elemento picture

Veja Também

Lição 2: A Fundação de Formatos - a próxima lição, cobrindo quando escolher JPEG, PNG, WebP, AVIF ou SVG.
Lição 8: Pare de Enviar Imagens de 4000px para um Celular de 400px - a metade de entrega responsiva do problema de peso de página que esta lição identifica.
Lição 15: A Prova de Trabalho - Auditorias do Lighthouse - a auditoria ao final do percurso que prova que os números de peso de página realmente mudam.