Signup form que converte: imagens leves (WebP/AVIF) + Core Web Vitals (ROI rápido)
O gargalo do signup form quase sempre é uma imagem de 200 KB
Se eu tivesse que apostar onde seu signup form (cadastro) está perdendo conversão, eu apostaria em bytes no topo: logo, badge de pagamento, selo de segurança e um hero “bonito”. A copy pode estar ok. O layout pode estar limpo. Mas a página demora a “assentar” e o usuário sente isso antes de ler qualquer coisa.
Em Core Web Vitals, você não precisa de mágica: precisa de previsibilidade. Metas do Google: LCP ≤ 2,5 s, CLS ≤ 0,1, INP ≤ 200 ms. Formulário é o lugar onde 300–800 ms a mais doem, porque a intenção é imediata: cadastrar, entrar, continuar o checkout.
O padrão que mais aparece quando eu audito Register Page: imagens “pequenas” somam e viram LCP. Um logo de 40 KB + três ícones de 15 KB + um hero de 250 KB dá 335 KB antes do primeiro campo ficar confortável de usar no 4G. E se essas imagens chegam sem espaço reservado, você ainda paga em CLS (campos pulando).
Se quiser pular para a parte prática, vai em JPEG vs WebP vs AVIF e depois em 3 testes rápidos.
Velocidade, confiança e o que o usuário percebe no primeiro scroll
Uma cena que eu vejo direto em e-commerce: o time troca a headline da página de cadastro (signup page), ajusta o CTA, muda o texto de “Criar conta” para “Continuar”. A conversão mexe pouco. Aí alguém abre o DevTools e percebe que o topo do formulário carrega um banner em JPEG “otimizado” que ainda pesa 400 KB, mais um PNG do logo com fundo transparente de 120 KB.
Imagem pesa, mas imagem também vende confiança. Logo, selo, badges (“Visa/Mastercard”, “SSL”, “Entrega rápida”) não são enfeite — eles diminuem fricção. O problema é pagar esse custo do jeito errado: no LCP e no CLS.
| Elemento no topo do formulário | Risco de performance | Como corrigir sem perder confiança |
|---|---|---|
| Hero/cover (foto do produto ou creator) | LCP alto (imagem vira “maior elemento”) | Trocar para WebP/AVIF, definir width/height, priorizar só 1 imagem |
| Logo (geralmente PNG) | Bytes “invisíveis” somam + pode atrasar fonte/layout | Usar SVG quando possível; se raster, WebP lossless e dimensões corretas |
| Badges e ícones | Muitos requests pequenos + CLS se sem tamanho fixo | Inline SVG, sprite, ou imagens com tamanho reservado e lazy fora do topo |
| Ilustrações decorativas | Bloqueiam render e distraem | Empurrar para depois do primeiro scroll ou remover do fluxo principal |
Se você usa shadcn/ui (ou qualquer kit semelhante), o componente do formulário geralmente está ok. O que derruba é o “embrulho”: header com logo grande, background com imagem, e um grid que muda de altura quando a imagem finalmente chega.
Hosted signup form entra aqui: é quando o formulário fica hospedado em um serviço (ex.: ferramenta de e-mail marketing ou de formulários) e você só embeda um link/iframe. Ele pode ser mais rápido porque já vem com infra e CDN — ou mais lento, se embutido com scripts pesados. Vale tratar do mesmo jeito: imagens leves e espaço reservado no layout.
JPEG vs WebP vs AVIF: quando usar em páginas de cadastro
Qual formato eu uso no hero do signup form: JPEG, WebP ou AVIF? Minha regra prática: WebP como padrão seguro; AVIF quando você quer apertar mais sem degradar; JPEG só quando o pipeline é limitado ou para compatibilidade legada.
- JPEG: ainda serve para fotos quando você precisa do caminho mais simples. Contra: normalmente fica maior que WebP/AVIF na mesma qualidade percebida; não tem transparência real.
- WebP: foi anunciado pelo Google em 2010 e hoje é o “padrão moderno” para a maioria dos sites. Pró: ótima relação peso/qualidade, suporta lossy e lossless, e animação quando necessário. Contra: pode dar trabalho ajustar o pipeline e revisar qualidade em tons de pele e gradientes.
- AVIF: geralmente consegue arquivos menores, bom para heros e fotos grandes. Pró: dá para reduzir peso agressivo mantendo uma qualidade aceitável. Contra: encode pode ser mais pesado no build e a compatibilidade ainda pede fallback bem feito.
Compressão com qualidade aceitável (sem matar confiança): em página de cadastro, eu priorizo “parecer nítido” no primeiro scroll. Se a foto do produto fica lavada, a sensação é de loja barata. Então eu ajusto pelo olho com checkpoints simples: 1) bordas do produto, 2) texto dentro da imagem (se existir), 3) tons de pele, 4) fundos com gradiente.
Fallback e compatibilidade: use <picture> com fontes em AVIF/WebP e um fallback em JPEG/PNG. Assim, browsers que não suportam AVIF ainda carregam WebP; e os que não suportam WebP caem no JPEG. O ganho vem sem quebrar nada.
<picture>
<source type="image/avif" srcset="/img/hero.avif">
<source type="image/webp" srcset="/img/hero.webp">
<img src="/img/hero.jpg" width="1200" height="800" alt="Produto">
</picture>Repara no detalhe que mais evita CLS: width/height (ou aspect-ratio) para a imagem já nascer com espaço reservado. Em signup form, isso vale mais do que “mais uma variação de headline”.
Copy não salva um LCP ruim: prove com 3 testes rápidos
Vou ser direto: se seu signup form está lento e instável, mexer na copy primeiro é trabalhar no sintoma. O ajuste de ROI rápido é reduzir bytes e estabilizar layout. Depois, sim, você lapida mensagem e microcopy.
Teste 1 — Descubra se “imagem pequena” é seu LCP
Abra o Chrome DevTools → Lighthouse ou Performance. Se o LCP aponta para uma imagem no topo (às vezes o logo, às vezes um badge), você achou um ganho barato. Eu já vi logo “pequeno” virar o maior elemento visível em telas mobile, porque o hero estava abaixo do fold e o header dominava.
Teste 2 — Caça-CLS em 60 segundos
Recarregue a página em 4G/Slow 4G e observe se os campos “pulam” quando o logo/hero carrega. Se sim: reserve espaço. Defina dimensões (ou use aspect-ratio) e evite inserir imagens acima dos campos sem altura fixa. CLS baixo (≤ 0,1) é UX básica: o dedo vai onde o usuário quer clicar, não onde o layout decidiu ir depois.
Teste 3 — Experimento A/B de performance (sem mexer na copy)
Faça uma variante com: hero em WebP/AVIF, logo em SVG/WebP lossless, badges como SVG, e o resto igual. Meça: tempo até o primeiro campo estar pronto para digitar (na prática, você vai sentir) e taxa de conclusão do signup form. Se a conversão sobe, você ganhou argumento interno para padronizar formatos next-gen no site todo.
“Mas o Google tem signup form?” Tem, em vários produtos (Conta Google, Google Workspace, etc.), e o padrão é claro: foco em poucos elementos acima do fold, layout estável, nada de imagem pesada disputando atenção com o campo. Não é porque é Google — é porque formulário é fluxo, não vitrine.
Se eu fosse resumir em uma frase para o time: o signup form é um produto de interação; imagem é suporte, não protagonista
. Deixe o visual forte, mas pague por isso com WebP/AVIF + fallback, não com LCP alto e CLS visível.
FAQ
O que é um signup form?
É o formulário de criação de conta (cadastro) que transforma visitante em usuário: nome, e-mail, senha e, às vezes, telefone. Em e-commerce, ele aparece no Register Page e também no checkout quando você pede conta antes de pagar.
“Signup form” é uma palavra só?
Como termo, “signup” pode aparecer junto em contextos de produto (“signup flow”, “signup page”). Mas “sign up” (verbo) é separado. Para SEO e consistência de UI, “signup form” (duas palavras) costuma funcionar bem.
O que é um hosted signup form?
É um formulário hospedado por um serviço externo (ex.: ferramenta de formulários ou automação) que você publica via link, embed ou iframe. Ele economiza tempo de dev, mas você ainda precisa controlar imagens, scripts e estabilidade visual para não perder conversão.
Como evitar CLS causado por imagens no topo do formulário?
Reserve espaço para cada imagem acima do fold: defina width e height (ou aspect-ratio) e evite carregar assets que mudam a altura do header depois do primeiro paint. Se o topo for responsivo, teste em mobile: é lá que o “pulo” mais atrapalha.
