Imagens: o peso que se poupa, e o salto na página que ninguém reserva

Uma imagem mal servida custa duas coisas diferentes, e só uma delas se mede em quilobytes. A outra é o salto que a página dá quando ela finalmente chega — e essa quem a sofre é quem já estava a ler.

1. Os formatos, em três linhas

AVIF para fotografia, quando se pode gerar: poupa à volta de metade do JPEG com a mesma qualidade aparente. WebP como rede, porque é universal há anos e já ganha ao JPEG. JPEG como último recurso. PNG só quando há transparência, ou texto e linhas dentro da imagem. SVG para o que é desenho — ícones, logótipos, gráficos — porque não tem resolução nenhuma e por isso nunca tem a resolução errada.

A regra que resolve a dúvida: fotografia perde qualidade sem se notar, desenho não. Comprimir uma fotografia a 80% é invisível; comprimir um logótipo a 80% dá uma orla suja a toda a volta.

2. O srcset, e a parte que quase todos erram

<img
  src="retrato-800.jpg"
  srcset="retrato-400.jpg 400w, retrato-800.jpg 800w, retrato-1600.jpg 1600w"
  sizes="(max-width: 700px) 100vw, 400px"
  alt="..."
/>

O srcset diz que ficheiros existem e que largura real tem cada um. O sizes diz que espaço a imagem vai ocupar na página — e é este que quase todos deixam de fora, ou põem a mentir.

Sem sizes, o browser assume 100vw. Num ecrã de 1600 pontos vai buscar o ficheiro de 1600, mesmo que a imagem apareça numa coluna de 400: serviram-se quatro vezes mais bytes do que era preciso, com o srcset todo bem escrito. É o erro mais fácil de cometer nesta matéria, porque nada avisa — a imagem aparece certa.

3. Quando o optimizador não serve

Em Next, o next/image faz isto tudo sozinho: converte para AVIF ou WebP, gera os tamanhos, escreve o srcset. É a escolha certa — quando as imagens são nossas.

Neste site a maioria não é. São de dezenas de domínios de fora, escritas dentro do HTML dos artigos desde 2009, e cada domínio teria de ser autorizado no next.config para o optimizador lhes poder tocar. Seria uma lista a crescer para sempre, que parte em silêncio no dia em que um artigo novo traz uma imagem de um domínio que ninguém se lembrou de acrescentar.

Por isso a listagem usa <img> à mão, e o next/image ficou para a única imagem que o site controla: o retrato do autor, com priority, porque é a maior coisa visível no topo e é ela que decide o LCP.

Não é desistir do optimizador — é notar que ele optimiza o que lhe pertence.

4. O salto na página, que é o erro mais caro

Este merece ser contado em detalhe, porque a correção óbvia não funciona. Punham-se width e height no <img>, e a lista continuava a saltar a cada imagem que carregava.

A razão: com a largura em auto — que é o que um max-width: 100% produz — o browser não tem por onde reservar nada. Os atributos dão-lhe a proporção, não o espaço.

O que resolveu foi calcular a caixa no servidor, onde o tamanho da imagem já é conhecido, e enviá-la já aplicada:

// A caixa é calculada aqui, no servidor, onde o tamanho da imagem já se sabe:
// é o que reserva o espaço antes de ela chegar.
const { caixa, cortada } = caixaDaAntevisao(media);

E para as oito das sessenta e duas imagens do arquivo que não trazem tamanho declarado não há cálculo possível: resta limitar a altura e deixar que seja a imagem a dizê-la quando chegar. É pior do que reservar, e é muito melhor do que saltar meia página.

Isto é o CLS do artigo das três medidas que o Google olha — e é a única das três que se corrige com marcação, sem tocar em desempenho nenhum.

5. O lazy, e a imagem que não pode levar lazy

<img src="..." loading="lazy" decoding="async" />

São vinte antevisões por página, e quem chega vê três. O loading="lazy" é das pouquíssimas coisas em desempenho que se ganham com um atributo e sem pensar.

Com uma exceção, que se vê muito por aí: a imagem de cima nunca leva lazy. Ela é o LCP. Pô-la em diferido é atrasar de propósito a medida que se estava a tentar melhorar — e é por isso que o retrato leva priority, que é precisamente o contrário.

6. O alt, e o link que fica sem nome

Há um pormenor que só aparece quando se envolve a imagem num link: uma imagem sem alt não dá nome ao link que a envolve, e um leitor de ecrã anuncia-o vazio — «link», e mais nada.

Neste site isso é o caso de todos os cartoons e de todas as miniaturas de vídeo. A saída não foi inventar um alt que ninguém pode escrever por 200 imagens alheias: foi esconder esse link da acessibilidade, porque o título logo acima leva exactamente ao mesmo sítio. Um link a menos é melhor do que um link sem nome, como no artigo das cinco coisas de acessibilidade.

O resumo

O peso resolve-se com o formato e com o sizes. O salto resolve-se reservando espaço — e não com os atributos que parecem reservá-lo. E o optimizador do framework é excelente para as imagens que são nossas, o que acaba por ser uma frase sobre quem controla o conteúdo, e não sobre a ferramenta.