Uma imagem de 1920 pixels de largura numa página é baixada inteira também por quem usa celular, para depois ser reduzida a 390 pixels na tela: cinco vezes mais banda e um carregamento mais lento por nada. O srcset deixa o navegador escolher a versão que cabe na tela, desde que você tenha produzido essas versões.
Por que uma imagem só não basta
O LCP dos Core Web Vitals costuma ser a imagem grande acima da dobra. Se você entrega a um celular um arquivo de 1920 de largura e 400KB, o LCP raramente fecha em 2,5 segundos; uma versão de 480 de largura e 40KB, na mesma conexão, é uma ordem de grandeza mais rápida. O sinal de experiência da página do Google lê esse número diretamente.
Por outro lado, uma imagem de 768 de largura num desktop grande fica macia demais. Daí os vários tamanhos, escolhidos pelo navegador.
Uma tabela prática de breakpoints
Os breakpoints seguem a largura em que a imagem é exibida na página, não a do viewport. Para os dois casos comuns, banners em largura total e figuras dentro de artigos:
- Imagens em largura total (hero, banners): 480, 768, 1200, 1920. Celular, tablet, notebook, tela grande.
- Figuras de artigo (coluna de conteúdo de até uns 800): 400, 800, 1200; o 1200 atende telas de 1,5x–2x.
- Miniaturas e cards (exibidos a cerca de 300): 300 e 600.
Mais degraus não é melhor. Cada um é mais uma exportação e mais um arquivo para guardar, e os navegadores toleram diferenças, então degraus separados por 1,5–2x são o ponto ideal. Quatro degraus cobrem mais de nove em cada dez combinações de dispositivos.
Você precisa de versões 2x?
Telas Retina e a maioria dos celulares têm densidade de 2x–3x; uma imagem exibida com 400 de largura precisa de 800 pixels para ficar nítida ali. Os degraus maiores da tabela já funcionam como a versão 2x dos menores: 768 é o 2x de um celular de 390 de largura, e 1200 é o 2x de uma coluna de 600.
Então não é preciso um conjunto "@2x" separado. Mantenha um espaçamento de cerca de 2x entre os degraus e o navegador escolhe o maior conforme a densidade.
Formato: WebP primeiro, JPG como reserva
Com a mesma qualidade, o WebP é de 25 a 35% menor que o JPG e todo navegador moderno o suporta. Exporte WebP em cada tamanho e mantenha uma reserva em JPG pelo elemento picture para navegadores antigos; se os navegadores anteriores a 2020 já não importam para o seu público, só o WebP basta.
O AVIF é ainda menor, mas codifica bem mais devagar no navegador, o que pesa em lotes grandes. AVIF vs WebP vs JPEG trata das vantagens e desvantagens em detalhe.
Exportando o conjunto inteiro em lote
Jogue as imagens originais no Processamento de imagens em lote e rode uma vez por degrau, trocando a largura e o sufixo a cada vez:
- Tamanho: largura 480, Permitir ampliar desativado, saída WebP a 80%, sufixo -480.
- Mesmos ajustes em 768 com sufixo -768; depois 1200; depois 1920.
- Para a reserva em JPG, mude a saída para JPG, mantenha os sufixos e rode de novo.
Cada execução leva segundos e o ZIP já traz hero-480.webp, hero-768.webp e assim por diante, prontos para a pasta de imagens. Mantenha Permitir ampliar desativado para que um original de 1000 pixels nunca seja esticado até 1920.
Para ver a diferença de tamanho em cada degrau numa imagem só, experimente o Redimensionador de Imagens com um arquivo.
Escrevendo o HTML
Para uma imagem em largura total:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Para figuras de artigo, defina sizes com a largura real, por exemplo sizes="(max-width: 840px) 100vw, 800px". Inclua sempre width e height para que o navegador reserve o espaço e a página não dê saltos.
Feito isso, some as dicas de lazy loading e compressão de como fazer as imagens carregarem mais rápido e a parte de imagens da sua nota de desempenho fica praticamente no máximo.