Imagens e velocidade: formatos, tamanhos e lazy loading

Porque é que as imagens decidem o tempo de carregamento

A Google escreve que as imagens são muitas vezes o que mais contribui para o tamanho total da página, o que pode tornar as páginas lentas e caras de carregar. Duas das Core Web Vitals (métricas essenciais da Web) dependem diretamente das imagens. Largest Contentful Paint (LCP) mede o carregamento: a Google aconselha que o maior elemento apareça nos primeiros 2,5 segundos depois de a página começar a carregar. Em muitas páginas, esse elemento é uma imagem, por exemplo uma fotografia grande no topo. Cumulative Layout Shift (CLS) mede a estabilidade visual e deve ficar abaixo de 0,1. As imagens que chegam sem espaço reservado empurram o texto para baixo e aumentam este valor.

O formato certo

• Fotografias: o JPEG funciona em todo o lado. O WebP e o AVIF são muitas vezes claramente mais pequenos com uma qualidade semelhante.
• Gráficos com contornos nítidos ou transparência: PNG, ou WebP e AVIF, que também podem ser transparentes.
• Logótipos e ícones: SVG, porque se mantém nítido em qualquer tamanho e costuma ser muito pequeno.
• A Pesquisa Google suporta imagens no atributo src nos formatos BMP, GIF, JPEG, PNG, WebP, SVG e AVIF.

Se ofereces WebP ou AVIF, podes manter um JPEG como alternativa num elemento picture. O navegador escolhe a primeira fonte que compreende.

O tamanho certo

Uma imagem com 2400 píxeis de largura mostrada a 600 píxeis desperdiça a maior parte dos seus bytes. Exporta as imagens mais ou menos com a largura com que são mostradas e, para ecrãs nítidos, com cerca do dobro dessa largura. Depois, comprime-as. Em muitos programas de imagem, uma definição de qualidade a meio da escala chega para fotografias na Web. Verifica o resultado em tamanho real antes de substituir o original.

srcset e sizes

Um único ficheiro nunca serve para todos os ecrãs. Com srcset ofereces vários ficheiros da mesma imagem e indicas a largura de cada um. Com sizes dizes ao navegador com que largura a imagem vai ser mostrada. O navegador escolhe então o ficheiro mais pequeno que seja suficientemente nítido.

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

Neste exemplo, a imagem ocupa todo o ecrã em ecrãs estreitos e tem 700 píxeis de largura nos mais largos. A Google recomenda manter sempre uma alternativa no atributo src. Escreve um texto alternativo a sério em vez das reticências.

width e height contra as mudanças de esquema

Sem width e height, o navegador não sabe quanto espaço uma imagem precisa até o ficheiro chegar. O texto que está por baixo salta então para baixo. O guia do web.dev sobre mudanças de esquema aconselha a incluir sempre os atributos width e height nas imagens e nos elementos de vídeo, com o tamanho em píxeis do ficheiro ou, pelo menos, a proporção correta. Os navegadores modernos definem a proporção predefinida de uma imagem a partir destes valores e reservam o espaço. No CSS, width: 100% e height: auto mantêm a imagem flexível. Se não puderes definir os atributos, o guia indica como alternativa a propriedade CSS aspect-ratio.

Carregamento diferido (lazy loading)

Com loading="lazy", o navegador só carrega uma imagem quando ela se aproxima da área visível. Isto poupa dados nas imagens mais abaixo na página. A Google diz sobre o carregamento diferido: não o acrescentes a conteúdos que provavelmente ficam visíveis logo que um utilizador abre uma página. O carregamento diferido incorporado no navegador está disponível para imagens e iframes.

A imagem LCP

A maior imagem no topo, muitas vezes uma imagem de destaque (hero) ou a fotografia principal do produto, é o ficheiro mais importante da página. O guia do web.dev sobre LCP diz: nunca carregues a tua imagem LCP de forma diferida. fetchpriority="high" é uma indicação ao navegador para a carregar cedo. Segundo o guia, uma prioridade alta em mais de uma ou duas imagens já não ajuda. As imagens cujo endereço uma biblioteca de scripts esconde em data-src, ou que são apenas um fundo CSS, são encontradas tarde pelo navegador. Para uma imagem de fundo, o guia indica um pré-carregamento com link rel="preload" no HTML. AVIF ou WebP e um ficheiro mais pequeno também encurtam o tempo de carregamento.

Para veres o desempenho das tuas páginas, a Google remete para o relatório Core Web Vitals da Search Console. Para uma única página, as ferramentas de desempenho do teu navegador mostram qual é o elemento LCP e que elementos deslocam o esquema. Mede antes e depois de uma alteração, para saberes se ajudou.

Uma lista de verificação curta

• A maior imagem no topo é carregada normalmente e não de forma diferida?
• Cada img tem width e height, ou o espaço reservado com aspect-ratio?
• Cada ficheiro tem mais ou menos a largura com que é mostrado, e está comprimido?
• As fotografias grandes existem em várias larguras com srcset e sizes?
• Há ficheiros JPEG ou PNG que poderiam ser WebP ou AVIF?

Trabalhar com o Do4U

A Verificação de imagens lê uma página e cada imagem que ela contém. Para cada ficheiro indica o formato, o tamanho do ficheiro e os píxeis e, a partir do HTML, width e height, loading, fetchpriority, srcset e sizes, as fontes de picture e as imagens de fundo em atributos style. O Do4U deduz do HTML qual é provavelmente a imagem LCP. Não a mede, porque o elemento LCP real é decidido pelo navegador. Recebes uma tabela das imagens com as conclusões, o peso total e um resumo curto. As imagens que o JavaScript insere e as imagens de fundo de ficheiros CSS externos não estão incluídas. Não é usada IA, e a verificação é gratuita, com um limite diário.

O Do4U encontra indícios; tu verificas e decides. Confirma o elemento LCP com as ferramentas de desempenho do teu navegador antes de alterares a página.