Por que velocidade importa mais que design
Você pode ter o site mais bonito do mundo, se ele demora 5 segundos para abrir no celular, 53% dos visitantes fecham a aba antes de ver o herói. E cada 100ms a mais, em média, custam 1% de conversão em e-commerce.
"Velocidade é a única feature que 100% dos usuários usam."
Core Web Vitals, as métricas que Google usa
Desde 2021 fazem parte do ranking. Se você não passa nas três, você perde posições.
- 1
LCP (Largest Contentful Paint) < 2.5s
Quanto tempo até o elemento principal aparecer. Culpados típicos: imagem do herói pesada, fonte customizada bloqueando render, servidor lento.
- 2
INP (Interaction to Next Paint) < 200ms
Substituiu o FID em 2024. Mede a resposta da interface a cliques/toques. Culpado principal: JavaScript pesado bloqueando a main thread.
- 3
CLS (Cumulative Layout Shift) < 0.1
O quanto a página 'pula' enquanto carrega. Culpados: imagens sem dimensão, banners injetados tardiamente, fontes trocadas no meio do carregamento.
PageSpeed Insights mostra dois números: laboratório (simulado) e campo (usuários reais via CrUX). Priorize o campo, é o que Google usa para ranking.
Otimização de imagens, 70% do problema
- Sirva WebP ou AVIF em vez de JPG/PNG, 30 a 60% menor sem perda visível
- Redimensione no servidor: nunca sirva 4000px numa tela de 400px
- Lazy loading nativo com loading='lazy'só carrega quando o usuário chega perto
- Use srcset e sizes para servir a versão certa por breakpoint
- Preload apenas a imagem do herói (LCP), nunca todas
- Comprima antes de subir. TinyPNG, Squoosh ou pipeline automatizado
Se seu site atual tem imagens JPG de 2MB, só migrando para WebP redimensionado você pode subir de 55 para 90+ no Lighthouse mobile.
JavaScript, a segunda maior causa
Cada plugin de terceiros (chat, analytics, tag manager, popup, review widget) adiciona 30-200KB de JS que bloqueia interação. Somando 8 plugins você tem facilmente 1.5MB de JS antes do seu código próprio.
- Audite terceiros com Chrome DevTools > Coverage, quanto JS não é usado?
- Adie scripts não-críticos com async ou defer
- Use tag manager com moderação, cada tag é código executado
- Prefira ferramentas server-side (analytics via API) a scripts client-side quando possível
- Framework moderno com SSR (React Server Components, TanStack Start) reduz JS entregue drasticamente
Servidor e CDN, o alicerce
- 1
Use CDN edge
Cloudflare, Fastly, Vercel Edge, servem o conteúdo do ponto mais próximo. Um usuário em Manaus recebe o site de Manaus, não de São Paulo.
- 2
Cache agressivo
HTML com cache curto (5-60min), assets estáticos (imagens, CSS, JS) com cache de 1 ano + hash no nome. Diminui 80% dos requests repetidos.
- 3
Compressão Brotli
Sucessor do gzip. 15-25% menor. Todo CDN sério oferece, habilite.
- 4
HTTP/3 e QUIC
Reduz latência em redes móveis instáveis. Ativa em um clique nos principais CDNs.
Como medir de verdade
- PageSpeed Insights, visão geral rápida com dados de campo
- Chrome DevTools > Lighthouse, auditoria detalhada por rota
- WebPageTest.org, testes em condições reais (3G lento, dispositivo antigo)
- Real User Monitoring (RUM). Web Vitals JS lib coletando de usuários reais
- Search Console > Core Web Vitals, o que Google está vendo do seu site
Seu MacBook com Wi-Fi tem 10x a capacidade do celular Android do seu cliente no ônibus. Teste em modo 'Mobile. Slow 4G' com CPU 4x throttle.
Equipe Ambravia
Engenharia de front-end
Este guia nasceu de projetos reais que entregamos. Se quiser aplicar o que leu no seu negócio, fale com a gente. Analisamos o caso sem custo.