Escolha o padrão correto
Troca por resolução (resolution switching) mantém a composição e oferece várias larguras de arquivo. É o padrão habitual para fotos de produto, figuras editoriais e cards. Use descritores de largura como 480w ou 1200w quando a largura renderizada variar com o layout. O número é a largura real em pixels do arquivo, não uma meta para telefones nem um comando CSS.
Troca por densidade (density switching) serve um slot CSS fixo com mais pixels de origem para telas de maior densidade. Seus descritores são 1x, 1.5x ou 2x, e ele é adequado para um logo ou ícone que, por exemplo, tem consistentemente 160 pixels CSS de largura. Não misture descritores de largura e de densidade no mesmo srcset.
Use descritores w com sizes quando um componente cresce ou encolhe.
Use descritores x sem sizes somente quando o tamanho CSS renderizado for estável.
Saiba como o sizes orienta a seleção
Com descritores de largura, o navegador avalia sizes antes de baixar uma imagem. Cada entrada combina uma condição de mídia opcional com um tamanho (length). A primeira condição que corresponder fornece o source size; o último tamanho incondicional é o fallback. sizes é uma dica de seleção, não uma regra CSS.
O navegador compara esse source size com as larguras dos candidatos para calcular a densidade efetiva, e então pode considerar densidade de exibição, zoom e condições de rede. Ele não é obrigado a escolher o nome de arquivo matematicamente mais próximo. Forneça candidatos honestos e uma estimativa de slot crível; a seleção final continua sendo decisão do agente do usuário.
A primeira condição de mídia que corresponder vence, então escreva a lista na ordem que torne essa primeira correspondência correta.
Um card de desktop que tem um terço da largura descrito como viewport‑wide pode acionar um candidato desnecessariamente grande.
Gere candidatos a partir do layout real
Faça inventário por componente, não por página. Um hero, figura editorial, galeria de produtos, miniatura de busca e logo do rodapé frequentemente têm larguras de slot diferentes. Para cada um, registre a largura estreita e a maior largura renderizada, a proporção (aspect ratio), o comportamento de crop e a visibilidade na tela inicial.
Gere larguras ao redor do intervalo significativo do slot do componente, com uma opção maior quando o detalhe justificar renderização de alta densidade. Arquivos quase idênticos adicionam complexidade de build e cache; apenas um arquivo muito pequeno e um muito grande forçam compromisso. Teste URLs gerados em vez de presumir que transformações de imagem funcionam.
Mantenha um src de fallback válido e atributos width e height que combinem com a proporção entregue. Eles reservam espaço mas não impedem o CSS responsivo de alterar as dimensões finais.
Um candidato anunciado como 800w deve realmente ter 800 pixels de largura.
Mantenha o plano de slot e candidatos junto das mudanças de template e design.
Use picture para direção de arte
Direção de arte (art direction) muda a composição, não apenas o tamanho do arquivo. Uma foto paisagem ampla pode precisar de um recorte retrato mais fechado em telas estreitas para que o assunto continue visível. O elemento picture pode oferecer opções de source específicas por mídia, seguidas por um img de fallback. O navegador avalia media, type e srcset de cada source; o img carrega o texto alternativo, dimensões e comportamento de fallback.
Prepare cada recorte com revisão editorial e de acessibilidade. Um crop móvel pode remover um detalhe do produto ou uma pessoa mencionada no texto alternativo. Coloque alt no img e descreva a informação ou função que a imagem transmite. Use alt="" apenas para imagem genuinamente decorativa; para uma imagem linkada ou botão, descreva a ação em vez da aparência. Não introduza picture quando o crop não muda: srcset baseado em largura é mais simples.
Um hero de desktop com composição complexa precisa de um recorte retrato distinto para o celular.
Um source dentro de picture pode fornecer um hint de type e preservar um img de fallback amplamente utilizável.
Evite erros caros de carregamento e marcação
O desperdício mais comum é copiar sizes="100vw" para toda imagem. Isso pode servir para uma figura estreita de largura total, mas não para um contêiner com limite de largura ou um card de desktop. A falha oposta é manter sizes desatualizado após um redesign. Altere CSS e sizes em conjunto.
Não faça lazy-load (carregamento preguiçoso) de uma imagem importante no conteúdo inicialmente visível. A orientação recomenda lazy‑loading para imagens abaixo da dobra e manter o hero visível ansioso (eager). Fetch priority pode elevar uma imagem realmente vital, mas regras amplas de alta prioridade ou preload podem prejudicar o desempenho. Não confie em nomes de arquivo ou resultados em cache como prova.
Um CMS, proxy ou cache pode ocultar um descritor errado ou uma requisição de imagem indesejada.
Não torne texto essencial da página dependente apenas de um recorte dirigido por arte.
Teste a requisição, o recorte e a correção
Teste páginas representativas em larguras que mudem o layout, incluindo pouco acima e pouco abaixo de um breakpoint do grid. Inclua uma configuração de alta densidade, desktop largo e estados que alterem o slot. Confirme dimensões renderizadas, recorte, texto alternativo e nitidez visual.
No Chrome DevTools, abra Network, recarregue com cache desabilitado ou use Empty Cache And Hard Reload, filtre por requisições de imagem e inspecione URL, tamanho transferido, cabeçalhos, initiator e timings. Aplique throttling para revelar trabalho tardio ou desperdiçado. Registre viewport, device scale factor, slot, candidato, bytes transferidos e resultado esperado.
Quando um template, breakpoint, CDN ou pipeline de ativos muda, torne isso um gate de lançamento. Repare de forma cirúrgica: corrija sizes, conserte um descritor, regenere um crop, restaure um fallback ou remova um preload desnecessário. Reteste com reload de cache vazio.
O painel Network registra o candidato realmente solicitado.
Isso verifica o comportamento de entrega de imagem, não a capacidade da origem, disponibilidade do CDN ou uptime geral.
Aplique como um controle de resiliência SIU
Imagens responsivas reduzem transferência evitável mas não garantem uma requisição bem‑sucedida. Erros de origem, transformações indisponíveis, hosts de terceiros e falhas de CDN exigem planejamento separado de continuidade e recuperação.
Para SIU, use registros de teste para detectar regressões de entrega cedo, identificar o template ou a regra de transformação responsável e fazer a menor correção segura antes do lançamento. Combine isso com preflight de disponibilidade e planejamento de rollback.
Atribua um responsável por componente e pela pipeline de imagens para cada verificação de seleção falhada.