O que aprendi entregando 50 sites com nota A no PageSpeed para empresas no Brasil e em Londres.
Atingir Nota A no Google PageSpeed e no GTMetrix (com LCP < 1,8s, INP < 100ms e CLS = 0,00) não é obra de um plugin milagroso de última hora: é resultado de quatro decisões tomadas antes da página subir para produção — hospedar a fonte variável localmente em WOFF2 (~22 KB), priorizar a imagem da primeira dobra com fetchpriority="high" em AVIF, aplicar decoding="async" nas mídias e substituir pacotes de ícones por SVG Sprite inline.
Muita gente trata otimização de performance como uma "faxina" feita no dia anterior ao lançamento: instala três plugins de minificação, ativa um lazy-load agressivo que esconde até o banner principal e torce para o velocímetro ficar verde. O problema é que essa abordagem quase sempre piora a métrica mais importante de todas — o LCP (Largest Contentful Paint).
Depois de projetar e colocar no ar cerca de 50 sites em produção — desde indústrias na Paraíba até agências e espaços de eventos em Londres (como a Business Network AM Branding e o Wimbledon Venue) —, consolidei um protocolo que garante nota A já na arquitetura base.
1. Por que parei de buscar fontes na CDN do Google Fonts
Cada vez que o navegador encontra um link para fonts.googleapis.com e fonts.gstatic.com, ele precisa abrir uma nova resolução de DNS, conexão TCP e handshake TLS antes de baixar o CSS e os arquivos de fonte. Além disso, como os navegadores modernos particionam o cache por domínio (Cache Partitioning), o mito de que "o usuário já tem a fonte em cache de outro site" deixou de existir.
Quando hospedo o subset latino da Manrope Variável em um único arquivo .woff2 de 22 KB no mesmo domínio do site com <link rel="preload">, todos os pesos (do 200 ao 800) chegam na primeira viagem HTTP/3 com zero salto de layout (CLS 0,00).
2. Regra de ouro do LCP: nunca aplique lazy-load na primeira dobra
O erro número um que encontro em auditorias de performance é colocar loading="lazy" ou animações de entrada em JavaScript (fade-in) na imagem principal do topo da página. Isso força o navegador a esperar o término do parse de todo o JS para só então descobrir que a imagem é visível.
<!-- Padrão correto para a imagem de LCP na primeira dobra -->
<picture>
<source type="image/avif" srcset="/assets/hero-560.avif 560w, /assets/hero-880.avif 880w" sizes="(min-width: 1024px) 440px, 90vw">
<img src="/assets/hero-720.webp" width="720" height="900" fetchpriority="high" decoding="async" alt="Descrição semântica">
</picture>3. Cortando o Total Blocking Time (TBT) e o INP no celular
No desktop com processador potente, quase qualquer site parece rápido. O teste real acontece num processador mobile intermediário sob rede 4G. Adicionar decoding="async" nas imagens retira a descompressão de bitmap da thread principal, enquanto trocar bibliotecas externas de ícones por um <svg><defs> enxuto elimina dezenas de milissegundos de bloqueio de renderização.
Perguntas frequentes
Qual é a diferença prática entre LCP, INP e CLS no ranking do Google?
Essas são as três métricas oficiais dos Core Web Vitals: o LCP mede a velocidade de carregamento visual do elemento principal (< 2,5s), o INP mede a rapidez de resposta ao toque/clique do usuário (< 200ms) e o CLS mede a estabilidade visual da tela (< 0,1).
Scripts de rastreamento (Meta Pixel, Google Tag Manager, Hotjar) destroem a nota do PageSpeed?
Se injetados de forma síncrona no <head>, sim. A solução limpa é carregar o gerenciador de tags com atraso controlado após a primeira interação ou via Cloudflare Zaraz / Server-Side Tagging na borda.