Imagem é, na maioria dos projetos, o ativo mais pesado da página. E o elemento que costuma definir o LCP. Ou seja: a decisão sobre como servir imagens não é de design, é de engenharia de performance.
Telas ficaram maiores e mais densas. Ao mesmo tempo, boa parte do tráfego chega por celular, com pacote de dados limitado e rede instável. Servir o mesmo arquivo de 1500px de largura para todo mundo resolve o problema de qualidade e cria um problema de carregamento, de banda e de experiência.
Imagem responsiva é a imagem que se adapta a diferentes resoluções sem perda de qualidade ou legibilidade, porque o navegador escolhe, entre os arquivos disponíveis, o mais adequado ao tamanho de tela e à densidade de pixels. A lógica é a mesma da interface responsiva, aplicada ao arquivo binário.
Na prática: 1024 x 768 no desktop, 800 x 600 no tablet, 320 x 320 no celular. Os números são exemplo, não receita. O correto é dimensionar os tamanhos a partir da interface real do site, da UX projetada e dos dispositivos que os seus usuários efetivamente usam.
Com HTML5 dá para declarar uma imagem por faixa de largura de tela. A tag <picture> permite estipular qual arquivo entra em cada breakpoint:
<picture class="card-thumb">
<source media="(min-width: 1024px)" srcset="<?php echo wp_get_attachment_image_src( $thumb_id, Image::SIZE_280_190, true )[0]; ?>">
<source media="(min-width: 768px)" srcset="<?php echo wp_get_attachment_image_src( $thumb_id, Image::SIZE_500_375, true )[0]; ?>">
<img src="<?php echo wp_get_attachment_image_src( $thumb_id, Image::SIZE_740_555, true )[0]; ?>" />
</picture>Funciona. Mas cobra caro em manutenção: você precisa registrar todos os thumbnail sizes, definir dimensões e fazer um get_attachment para cada tamanho, em cada template. Multiplique isso por um site com dezenas de componentes e vários editores publicando por dia. É exatamente o tipo de tarefa que vira fila de desenvolvimento e trava o lançamento de campanha.
Na versão 4.4, o WordPress passou a entregar isso de forma nativa. O recurso não nasceu no core: foi amadurecido antes no plugin RICG Responsive Images e, depois de testes, incorporado.
O mecanismo é simples de descrever. No upload, o WordPress gera automaticamente versões menores da imagem. Na renderização do front, ele injeta dinamicamente o atributo srcset na tag img, listando os tamanhos disponíveis. O navegador escolhe o arquivo mais adequado, baixa só ele e ignora os demais. Resultado: menos bytes trafegados, carregamento mais rápido e suporte a telas de alta densidade de pixels.
Nota prática para quem edita conteúdo: o srcset é adicionado dinamicamente no front. Se você abrir a aba “texto” do editor, verá apenas o src. Não é bug, é ordem de execução.
Por padrão, cada envio gera três novos arquivos além do original: miniatura (thumbnail), média (medium) e grande (large). Regra de 4 x 1, portanto: quatro arquivos armazenados por imagem enviada. Manter o original importa, é ele que permite regerar tamanhos quando o layout mudar.
Subindo uma imagem de 1500 x 706, você tem algo como:
Full Size, 1500 x 706
Large, 500 x 235
Medium, 300 x 141
Thumbnail, 150 x 150
Antes da 4.4, usar o tamanho total no conteúdo significava servir o tamanho total para qualquer dispositivo. Agora o tamanho adequado é selecionado no carregamento, sem intervenção do editor.
Os arquivos ficam em /wp-content/uploads. As dimensões padrão são definidas na tela administrativa de Configurações de mídia, e temas ou plugins registram tamanhos adicionais via código, cada um com nome, largura e altura.
Já encontramos projetos gerando dezenas de arquivos por upload. Isso tem os dois lados.
Do lado bom: encaixe perfeito em cada componente do layout, carregamento só do arquivo necessário, economia de banda e melhor experiência. Do lado ruim: processar imagem consome CPU. Muitos tamanhos registrados deixam o upload lento, elevam o consumo de infraestrutura e empurram o custo de hospedagem para cima.
A decisão é de arquitetura, não de preferência. Registre os tamanhos que o layout realmente usa, audite os órfãos e remova o que sobrou de temas antigos.
As APIs do WordPress são flexíveis, então é normal que um tema ou plugin esteja interferindo na marcação final das imagens. Vale sempre inspecionar o HTML servido, não só o código do template. Numa marcação padrão de post ou página, o resultado é assim:
<figure class="wp-block-image size-medium">
<img src="/imagem-300x205.png" alt="" class="wp-image-5"
srcset="/imagem-300x205.png 300w, /imagem-768x525.png 768w, /imagem.png 1000w"
sizes="(max-width: 300px) 100vw, 300px">
</figure>A figure envolve a img. O srcset lista os arquivos disponíveis com a largura de cada um. O sizes informa ao navegador o espaço que a imagem vai ocupar no layout, e é esse dado que orienta a escolha. sizes mal declarado é o erro mais comum: o navegador baixa um arquivo maior do que precisa e você perde o ganho todo.
Layout fluido resolve a metade visível do problema. A outra metade é o peso do que trafega. Imagem responsiva é o que impede que o celular baixe o arquivo de desktop para exibir num contêiner de 320px.
O ganho aparece em duas frentes. Na operação do site: menos tráfego de banda e menos pressão sobre a infraestrutura. Para o usuário:
navegação mais fluida;
menor consumo do pacote de dados no celular;
páginas carregando mais rápido;
melhor visualização das imagens, incluindo telas retina.
Isso conecta direto com Core Web Vitals. Quando o elemento de maior área visível é uma imagem, o arquivo escolhido pelo navegador é o que determina o LCP. E vale lembrar do contexto que empurrou essa mudança: com o crescimento do acesso por dispositivos móveis registrado em pesquisas do Comitê Gestor da Internet no Brasil (CGI.br), os buscadores passaram a dar mais relevância a sites que se adaptam bem a qualquer tela.
O WordPress resolve a parte mecânica: gera os tamanhos, escreve o srcset, entrega o arquivo certo. O que continua sendo trabalho de time é decidir quais tamanhos existem, garantir que o sizes reflita o layout e manter a operação de mídia sob controle quando há muitos editores publicando.
Convencer quem produz conteúdo de que otimização de imagem é parte do trabalho editorial, e não um detalhe técnico posterior, costuma ser o gargalo real. Menos arquivo pesado subindo na origem, menos correção depois.
Se a sua operação de conteúdo vive esse atrito entre marketing e TI, vale um diagnóstico da operação WordPress com o nosso time. Fale conosco.
Pablo Almeida 
Fabio Carvalho 
