Desenvolvimento WordPress

Faça imagens responsivas da forma certa no WordPress 4.4

Entenda como o WordPress 4.4 consegue prever o tamanho da imagem ideal para o dispositivo em uso, revolucionando a web atual com as imagens responsivas.
Escrito Por Leandro Vieira em dezembro de 2015 /6 min de leitura
Conteúdo escrito por humano
wordpress 4 4 release overview

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.

O que é uma imagem responsiva

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.

A tag <picture>

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.

Imagens responsivas e automáticas

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.

O que acontece a cada upload

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.

Quantos tamanhos são tamanhos demais

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.

A marcação que o WordPress entrega

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.

Mobile First não é layout. É orçamento de banda

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.

Concluindo

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.

Links Úteis

Leandro Vieira

Uma das grandes referências de WordPress no Brasil, entusiasta e evangelista da plataforma. Fundador e CEO da Apiki, empresa especializada no desenvolvimento web com WordPress.
Qual nota você da para este artigo?
Ruim

O que você achou disso?

Clique nas estrelas

Média da classificação 0 / 5. Número de votos: 0

Nenhum voto até agora! Seja o primeiro a avaliar este post.

Excelente
Artigos Relacionados
file 10

IA no desenvolvimento de sites em WordPress

  1. Mas a tag picture já é aceita pelos navegadores atuais? Há alguns meses ali que ela ainda não era suportada nem pelo Chrome. Se for, é um game changer! :)
    1. Olá Pablo, como vai? Uma boa forma de conferir o suporte aos navegadores é pelo o site CanIUse, segue o link: http://caniuse.com/#search=picture

Construa seu site WordPress sob medida com os maiores especialistas em WordPress da America Latina
Conheça a Apiki

Faça um comentário
Cadastre-se rápido

Fazer Login