NUEVOInstagram, TikTok, YouTube y más — el tamaño y recorte exactos, sin salir de tu navegador.Probar SmallAdapt
← Blog

A evolução da web e o peso das imagens

20 de agosto de 2026 · 5 min de leitura

A primeira página web da história, publicada por Tim Berners-Lee em agosto de 1991 a partir do CERN, não tinha uma única imagem. Era texto simples com hiperligações sublinhadas, a explicar o que era este projeto chamado "World Wide Web". Mais de trinta anos depois, uma página de produto de e-commerce média carrega mais de dois megabytes só em imagens. Esta é a história de como passámos de uma coisa à outra — e de porque é que, para quem gere um site hoje, o peso das imagens continua a ser a variável isolada que mais compromete a velocidade de um site.

Captura de ecrã da primeira página web da história, info.cern.ch, tal como foi publicada por Tim Berners-Lee
A primeira página web da história, tal como Tim Berners-Lee a escreveu no CERN — apenas texto, sem uma única imagem. Domínio público, via Wikimedia Commons.

1991-1995: uma web feita para modems de 2400 baud

Os primeiros navegadores gráficos — o Mosaic em 1993, depois o Netscape Navigator em 1994 — já permitiam incorporar imagens, mas o contexto técnico impunha uma disciplina brutal. Um modem doméstico típico de 1994 transmitia a 14,4 ou 28,8 kbps. Uma única imagem JPG de 100 KB, que hoje consideraríamos minúscula, podia demorar quase um minuto a carregar a essa velocidade. O resultado: os sites da época usavam imagens a conta-gotas, quase sempre em GIF de 256 cores (mais leve do que um JPG em gráficos simples), e qualquer fotografia real era recortada e comprimida de forma agressiva. A estética "pixelada" que hoje associamos aos anos 90 não era uma escolha de design — era a única opção que a largura de banda permitia.

Captura de ecrã do navegador NCSA Mosaic, o primeiro navegador gráfico popular, lançado em 1993
NCSA Mosaic, o navegador que popularizou a navegação gráfica com imagens em 1993 — Charles Severance, CC0 / domínio público, via Wikimedia Commons.

1995-2005: banda larga, e a imagem deixa de ser um luxo

A chegada do ADSL e do cabo aos lares mudou as regras. No início dos anos 2000, uma ligação doméstica média já suportava centenas de kbps ou mais, e os sites começaram a ser tratados como catálogos visuais, não apenas documentos com hiperligações. A Amazon, o eBay e as primeiras lojas online perceberam depressa que uma fotografia de produto vendia mais do que uma descrição — e as páginas começaram a encher-se de imagens sem que ninguém se preocupasse muito com o seu peso, porque a banda larga parecia resolver tudo. Esse otimismo gerou um hábito que ainda hoje custa a erradicar: carregar a foto tal como sai da câmara ou do telemóvel, sem comprimir, porque "afinal já não há dial-up".

2007-2015: o telemóvel muda tudo (outra vez)

O iPhone, em 2007, e a onda de smartphones que se seguiu, ressuscitaram o mesmo problema dos anos 90, mas ao contrário: agora a ligação voltava a ser limitada (3G, dados móveis com tarifários por megabyte) precisamente quando os sites já se tinham habituado a pesar vários megabytes em fixo. A resposta da indústria foi o design responsivo (o termo foi cunhado por Ethan Marcotte em 2010) — fazer com que o mesmo site se adapte a qualquer ecrã — e, mais devagar, a ideia de servir imagens de tamanho diferente consoante o dispositivo, em vez de enviar a mesma foto de secretária para um ecrã de telemóvel que nem precisa dela nem a consegue mostrar por inteiro.

2015-hoje: a Google começa a medir a velocidade, e de repente isso importa

A mudança mais determinante da última década não foi técnica, foi de incentivos: a Google começou a usar a velocidade de carregamento como fator de posicionamento, e em 2021 formalizou isto com os Core Web Vitals — métricas concretas como o LCP (Largest Contentful Paint, quanto tempo demora a pintar-se o elemento visível maior, quase sempre uma imagem) que afetam diretamente o SEO. De repente, comprimir bem uma imagem deixou de ser "boa prática" e passou a ser algo com impacto mensurável na quantidade de tráfego que um site recebe. É a razão pela qual ferramentas como esta existem: não é uma moda de design, é que o peso das imagens se tornou uma métrica de negócio.

Tendências de imagem em 2026

Com esta base histórica, isto é o que se vê agora, em 2026, na forma como as imagens são usadas na web:

  • AVIF e WebP como padrão, não como exceção. Há uns anos, servir estes formatos exigia verificar a compatibilidade do navegador com cuidado. Hoje o suporte é praticamente universal, e a pergunta já não é "posso usar WebP?" mas sim "porque continuo a servir JPG por defeito?".
  • Menos fotografia de stock genérica, mais conteúdo gerado ou retocado com IA. Não porque seja mais barato (embora também seja), mas porque encaixa melhor em marcas que querem uma estética própria em vez da mesma imagem de pessoas a sorrir num escritório que toda a gente usa.
  • Formatos verticais por defeito. O consumo maioritário já é móvel, e o design de imagem — para redes sociais, para banners, para miniaturas — pensa-se primeiro em vertical (9:16, 4:5) e só depois se adapta ao horizontal, ao contrário do que se fazia há uma década.
  • Carregamento diferido (lazy loading) nativo como padrão. O atributoloading="lazy" do próprio HTML, sem bibliotecas, tornou-se a norma para não carregar imagens que o utilizador nunca chega a ver.
  • Pressão constante para reduzir o peso, não para acrescentar mais resolução. Os ecrãs continuam a melhorar (mais densidade de pixels, mais HDR), mas a tendência real em produção web é o contrário do que se poderia esperar: exportar mais comprimido, não menos, porque o custo de transferir dados e o impacto nos Core Web Vitals pesam mais do que o ganho visual marginal de um ficheiro um pouco mais nítido.

Se o teu site ainda serve JPG ou PNG sem compressão, é o sítio mais fácil por onde começar a ganhar velocidade: comprime as tuas imagens aqui, no navegador, sem enviar nada para nenhum servidor.

SMALLNUEVO

Adapta tus fotos a cada red social

Instagram, TikTok, YouTube y más — el tamaño y recorte exactos, sin salir de tu navegador.

Probar SmallAdapt