Como otimizar imagens de uma landing page criada por IA antes de publicar

Uma landing page criada por IA pode parecer pronta e ainda carregar uma imagem de vários megabytes, entregar o mesmo arquivo para celular e desktop ou deslocar todo o conteúdo quando a foto finalmente aparece.

O problema não é usar imagens. É publicar arquivos sem relacionar cada um ao espaço que ocupa, à ordem em que aparece e ao que comunica.

Este guia mostra como transformar “otimize as imagens” em uma revisão verificável: inventariar os arquivos, preservar a intenção visual, escolher formatos e dimensões adequados, ajustar o HTML, validar a build e só então publicar.

Comece pelo pacote que será publicado

Analise a saída final do projeto, não apenas a pasta de origem.

Um framework pode converter, duplicar ou renomear imagens durante a build. Também pode deixar de incluir um arquivo que funcionava no preview local. Gere o pacote e registre:

• caminho e tamanho de cada imagem;
• formato;
• dimensões em pixels;
• página e seção em que aparece;
• tamanho aproximado em que é renderizada;
• se está na primeira dobra;
• se é conteúdo, decoração ou interface;
• se existe uma variante para telas menores.

Uma tabela simples torna o excesso visível:

Não conclua que o maior arquivo é automaticamente o primeiro a remover. A imagem principal pode ter alto valor para a oferta. A textura quase invisível pode custar muito e não ajudar ninguém.

O checklist de QA para landing pages criadas com IA ajuda a conectar esse inventário ao restante do pacote, dos CTAs e da publicação.

Preserve a função antes de comprimir

Classifique cada imagem pela função:

• conteúdo: produto, pessoa, ambiente, prova ou comparação que precisa de texto alternativo;
• interface: ícone, ilustração funcional ou estado que participa da compreensão;
• decoração: forma, textura ou brilho que pode ter alt="" quando estiver em um elemento de imagem;
• fundo: recurso aplicado por CSS, sem alternativa textual nativa;
• social: imagem usada em metadados de compartilhamento, fora do fluxo visual da página.

Essa classificação evita duas correções ruins: apagar uma imagem necessária para melhorar uma métrica ou manter um arquivo caro só porque ele veio no primeiro layout.

Antes de editar, pergunte:

1. o que deixa de ser compreendido sem esta imagem?
2. ela precisa manter transparência?
3. contém detalhes que devem continuar legíveis?
4. aparece em qual largura máxima real?
5. existe texto incorporado que deveria ser HTML?

Texto dentro de imagem costuma escalar mal, não se adapta ao contraste do dispositivo e é mais difícil de manter. Quando o texto faz parte da mensagem, prefira HTML e preserve a imagem como apoio visual.

Escolha o formato pelo tipo de imagem

Não existe um formato vencedor para todo arquivo.

Fotografias e cenas com muitos tons

WebP e AVIF podem reduzir o peso de fotografias e ilustrações complexas mantendo boa qualidade. JPEG continua sendo uma opção compatível quando o pipeline ou o público exige.

Compare a saída visual, não apenas a extensão. Gradientes, pele, cabelo, sombras e detalhes pequenos podem degradar de modo diferente.

Transparência e gráficos

PNG é útil quando a imagem raster precisa de transparência ou detalhe sem perdas, mas pode ficar muito pesado para fotografias. WebP e AVIF também podem representar transparência em navegadores atuais e merecem um teste no pipeline.

SVG é apropriado para gráficos vetoriais confiáveis, como formas e ícones próprios. Não converta automaticamente uma fotografia para SVG e não publique SVG recebido de fonte desconhecida sem revisar seu conteúdo.

Animação

GIF costuma produzir arquivos grandes. Antes de substituí-lo por vídeo ou outro formato animado, confirme:

• se a animação é realmente necessária;
• se pode pausar;
• se respeita preferência por movimento reduzido;
• se o fallback preserva a mensagem;
• se o novo elemento continua acessível.

A escolha de formato é uma decisão de conteúdo, compatibilidade e custo, não uma corrida pelo menor número.

Entregue dimensões próximas ao uso real

Uma foto de 3200 pixels não precisa ser enviada inteira para um card que ocupa 320 pixels.

Defina o maior tamanho em que a imagem pode aparecer, considere telas de maior densidade e gere variantes coerentes. Para conteúdo responsivo, srcset permite oferecer diferentes larguras, enquanto sizes descreve o espaço que o elemento tende a ocupar:

<img
  src="/assets/produto-800.webp"
  srcset="
    /assets/produto-480.webp   480w,
    /assets/produto-800.webp   800w,
    /assets/produto-1280.webp 1280w
  "
  sizes="(max-width: 720px) 100vw, 50vw"
  width="1280"
  height="960"
  alt="Produto aberto ao lado dos acessórios incluídos"
/>

O navegador usa srcset e sizes para escolher uma fonte adequada. A documentação de imagens responsivas da MDN explica os descritores de largura e densidade.

As regras de CSS ainda controlam o layout:

img {
  max-width: 100%;
  height: auto;
}

Não copie o exemplo sem verificar a página. Se o card ocupa toda a tela no celular e um terço no desktop, o atributo sizes deve representar esse comportamento.

O guia de teste de responsividade em landing pages mostra como validar corte, ordem e legibilidade em larguras reais.

Reserve espaço para evitar saltos

Informe width e height no elemento <img> mesmo quando o CSS o torna fluido. Esses atributos ajudam o navegador a conhecer a proporção e reservar espaço antes do download.

Sem espaço reservado, o texto e os botões podem mudar de lugar quando a imagem chega. Isso prejudica leitura, cliques e CLS.

A referência do elemento img na MDN recomenda dimensões explícitas e detalha como elas interagem com carregamento e seleção responsiva.

Quando a proporção muda entre mobile e desktop, considere <picture> para direção de arte, com fontes e cortes deliberados. Não use object-fit: cover para esconder qualquer erro: ele pode cortar rosto, produto ou texto importante.

Carregue cedo apenas o que é prioritário

Imagens fora da primeira dobra podem usar carregamento tardio:

<img
  src="/assets/depoimento-640.webp"
  width="640"
  height="480"
  loading="lazy"
  alt="Cliente usando o produto em uma mesa de trabalho"
/>

Não aplique loading="lazy" indiscriminadamente. Se a imagem hero for o maior conteúdo visível, atrasá-la pode piorar LCP. O guia oficial sobre lazy loading de imagens recomenda atenção especial às imagens visíveis no carregamento inicial.

Também não marque todas as imagens como prioritárias. Prioridade deixa de ter significado quando tudo compete pelo mesmo espaço de rede.

Uma regra prática:

• imagem principal da primeira dobra: descoberta cedo e sem lazy loading;
• imagens abaixo da dobra: candidatas a loading="lazy";
• decoração dispensável: adiar, simplificar ou remover;
• imagem social não renderizada: não carregar no corpo da página.

Confirme a ordem no painel de rede do navegador. O atributo correto no arquivo errado não melhora a experiência.

Escreva alternativas que correspondam à imagem final

Compressão e recorte podem mudar o que a imagem mostra. Revise o alt depois da versão final.

Uma boa alternativa descreve a informação necessária naquele contexto. Evite repetir o título da seção ou escrever “imagem de”. Para decoração que não acrescenta conteúdo, use alternativa vazia quando o elemento apropriado permitir.

Compare:

<!-- Genérico demais -->
<img src="/assets/painel.webp" alt="Imagem do painel" />

<!-- Informa o que importa no contexto -->
<img src="/assets/painel.webp" alt="Painel com três sites publicados e seus respectivos status" />

Se a imagem contém um gráfico ou instrução essencial, uma frase curta pode não bastar. Inclua a explicação no conteúdo da página.

O guia de acessibilidade em sites criados por IA aprofunda alternativas textuais, contraste, foco e zoom.

Dê ao agente um pedido verificável

Evite pedir apenas “comprima tudo”. Um prompt melhor preserva escopo e evidência:

Audite as imagens da build desta landing page antes de editar.

Para cada arquivo, informe caminho, formato, dimensões, peso,
local de uso e se aparece na primeira dobra. Identifique:
- arquivos muito maiores que o tamanho renderizado;
- imagens sem width e height;
- uso indiscriminado de lazy loading;
- ausência de variantes responsivas;
- texto alternativo incompatível com a imagem final.

Proponha a menor correção por item. Preserve enquadramento,
copy, tracking e estrutura da página. Depois gere a build,
compare o peso final e liste os testes visuais ainda necessários.

Peça para o agente separar fato, hipótese e mudança. “A imagem tem 1,8 MB” é fato. “Ela causa o LCP ruim” é hipótese até a medição relacionar os dois.

Compare qualidade e custo

Para cada arquivo alterado, registre:

arquivo:
uso:
formato anterior:
formato novo:
dimensões anteriores:
dimensões novas:
peso anterior:
peso novo:
diferença visual observada:
larguras testadas:

Abra a imagem em tamanho real e dentro da página. Verifique:

• nitidez do assunto principal;
• faixas em gradientes;
• halos em transparências;
• corte em celular e desktop;
• contraste de texto sobreposto;
• modo escuro, quando existe;
• zoom;
• conexão lenta simulada;
• ausência de deslocamento no carregamento.

Uma redução grande de bytes não compensa uma foto de produto borrada ou uma prova social ilegível.

Valide a build e a URL publicada

Depois da alteração:

1. rode os checks do projeto;
2. gere uma build limpa;
3. confirme que todas as variantes entraram na saída;
4. procure caminhos quebrados e arquivos duplicados;
5. abra a página em larguras pequenas e grandes;
6. teste com cache desabilitado;
7. publique o artefato exato;
8. repita os testes na URL pública.

A documentação de Publicação descreve o diretório public/ e as file tools. Se a imagem está fora de public/, ela não está publicada.

Depois do deploy, meça novamente o cenário que motivou a mudança. O guia de Core Web Vitals em sites criados por IA mostra como comparar LCP, INP e CLS sem misturar várias causas na mesma rodada.

Se algo falhar, preserve o Site ID, corrija o pacote e siga o fluxo de republicação com agente de IA. Criar um Site novo para cada ajuste quebra a continuidade da URL e da medição.

Publique imagens com intenção

O objetivo não é deixar toda imagem mínima. É fazer cada arquivo justificar seu custo e chegar no tamanho, momento e contexto certos.

Inventarie a build, preserve a função visual, entregue variantes coerentes, reserve espaço, priorize apenas a primeira dobra e valide a URL real. Assim, a landing page continua convincente sem obrigar o visitante a baixar pixels que nunca verá.