Site lento não perde só conversão — perde ranking. Desde 2021 o Google usa um conjunto de métricas chamado Core Web Vitals como fator oficial de posicionamento. Em 2026, com a chegada do INP no lugar do FID, o jogo ficou ainda mais técnico. Sites que ignoram essas métricas vão sumindo dos primeiros resultados, mesmo com bom conteúdo e backlinks.
Este artigo abre o que são as métricas, como medir, e o passo a passo real que aplicamos no próprio site da Uma Nova Imagem pra sair de score 67 no Lighthouse pra 99. Sem teoria de manual — só o que de fato funcionou.
O que são Core Web Vitals (em português simples)
Cinco métricas medem a experiência real do usuário:
LCP — Largest Contentful Paint
Tempo até o maior elemento visível aparecer. Geralmente é o título principal, uma imagem grande ou um banner. Alvo: menos de 2,5s.
FCP — First Contentful Paint
Tempo até qualquer pixel de conteúdo aparecer. Alvo: menos de 1,8s. Indica que o navegador começou a renderizar.
CLS — Cumulative Layout Shift
Quanto o layout se desloca enquanto carrega (texto que pula, imagem que empurra). Alvo: menos de 0,1. Acima disso, usuário clica errado, paga frustração, abandona.
TBT — Total Blocking Time
Tempo total em que a main thread fica bloqueada por scripts pesados. Alvo: menos de 200ms. Mede a responsividade.
INP — Interaction to Next Paint
Em 2024 substituiu o FID. Mede o pior tempo de resposta a uma interação (clique, toque). Alvo: menos de 200ms.
Bonus: Speed Index — quão rápido visualmente o conteúdo aparece. Não é Core Vital mas o Lighthouse cobra.
Como medir (e por que você precisa de 2 ferramentas)
1. Lighthouse (lab data)
Roda no Chrome DevTools ou em PageSpeed Insights. Simula um Moto G Power em rede 4G lenta — pessimista de propósito. Bom pra desenvolvimento.
2. CrUX (field data)
Dados REAIS de usuários do Chrome anonimizados. Aparece no Google Search Console (aba "Core Web Vitals") e em PageSpeed Insights. É o que o Google USA pra ranqueamento — não o Lighthouse.
Erro comum: ficar caçando 100 no Lighthouse e ignorar CrUX. O CrUX precisa de tráfego real (uns 1.000 visitantes/mês no mínimo) pra ter dados. Sites pequenos veem só Lighthouse.
Os 7 problemas que atrasam 95% dos sites brasileiros
1. Imagens gigantes
PNG de 2 MB sendo exibido em thumbnail 200x200. Solução: usar formatos modernos (WebP, AVIF), redimensionar pra tamanho exibido, sempre com width e height declarados pra reservar espaço.
Exemplo real do nosso site: santa-rita.png tinha 254 KB. Convertido pra JPG 1280x607 com qualidade 82 ficou em 65 KB — economia de 74%, LCP caiu junto.
2. Google Fonts bloqueando renderização
Carregar Inter em 7 pesos via Google Fonts adiciona ~1,2s de bloqueio: 2 requisições CSS + 7 arquivos woff2 baixados sequencialmente, todos em domínio externo (fonts.googleapis.com + fonts.gstatic.com).
Solução: self-hostar os woff2 dentro do próprio domínio. Reduz pesos pra 2 ou 3 (em vez de 7). Adiciona font-display: optional no @font-face — se a fonte não chegar em 100ms, navegador usa fallback e não troca depois (sem CLS).
Bonus: criar uma fonte fallback com size-adjust que faz Arial ter as mesmas métricas do Inter. Mesmo no swap, nada desloca.
3. CSS bloqueante
<link rel="stylesheet"> bloqueia renderização até baixar e parsear. Pra CSS crítico (above-the-fold), inline dentro de <style> no <head> é dramaticamente mais rápido.
O nosso critical CSS tinha ~7 KB. Inline no HTML elimina 1 roundtrip. Após o paint inicial, CSS não-crítico pode carregar via media="print" onload="this.media='all'" — non-blocking.
4. JavaScript pesado bloqueando main thread
Scripts grandes (jQuery + plugins + frameworks) podem bloquear renderização por 500-2000ms. Resultado: TBT alto, página "trava".
Mitigações: defer em todos os scripts não-críticos, async em scripts de tracking, code splitting (não carregar tudo de uma vez), substituir bibliotecas pesadas por nativo (jQuery → vanilla JS é trivial em 2026).
5. Layout shift de elementos animados/dinâmicos
Banner que aparece tarde e empurra conteúdo. Imagem sem dimensões. Anúncio carregando depois. Texto que muda de fonte e altera altura.
Solução: sempre reservar espaço com aspect-ratio, min-height ou contain-intrinsic-size. Elementos com position: absolute ancorar em vh (estável) em vez de % do pai (cresce com texto).
6. Reflow forçado em JavaScript
JS que lê offsetWidth, scrollTop, getBoundingClientRect() DEPOIS de modificar DOM força o navegador a recalcular layout imediatamente. Numa página com muitos elementos, isso pode custar 200-800ms.
Padrão correto: ler antes, escrever depois. Ou usar requestAnimationFrame pra agrupar leituras e escritas. Bibliotecas modernas (React, Vue) já fazem isso automaticamente, mas código vanilla manual costuma errar.
7. Carregamento de conteúdo abaixo da dobra no first paint
Páginas longas processam TODO o HTML no first paint, mesmo o que está 5 telas abaixo. CPU gasta tempo com seções que o usuário talvez nem veja.
Solução: content-visibility: auto + contain-intrinsic-size: 0 1000px em seções abaixo da viewport. Navegador pula totalmente layout/paint dessas seções até elas chegarem perto. Resultado típico: TBT cai 50-70%.
O caso da Uma Nova Imagem: de 67 a 99
Nosso site rodou Lighthouse pela primeira vez e bateu 67 (mobile). Mau resultado. Em 13 commits sequenciais, chegamos a 94 (mobile) e 99 (desktop). As mudanças:
- Hero image otimizada (254 KB → 65 KB JPG com width/height)
- Landmark
<main>adicionado (acessibilidade + GEO) - Footer com cor de texto contraste AAA
- Orbs decorativos ancorados em
vhem vez de%(CLS de 0,758 → 0,02) - Google Fonts pesos reduzidos de 7 pra 3
- Self-host de Inter, JetBrains Mono, DM Sans, Instrument Serif (14 arquivos woff2 no próprio domínio)
- Removido
@importbloqueante de dentro do CSS - Inline do critical CSS + fonts.css no
<head>(corta 1,3s de bloqueio) - Font fallback matching (Arial com
size-adjuste métricas iguais ao Inter — sem CLS no swap) - Animação de reveal removida dos 3 spans do hero acima-da-dobra (LCP imediato)
font-display: optional(sem espera por fonte)- Orbs adicionais ancorados em viewport
content-visibility: autonas 5 seções abaixo do hero (TBT 570 → 70 ms)
Tempo total: cerca de 4 horas de trabalho técnico. Resultado:
| Métrica | Antes | Depois |
|---|---|---|
| Lighthouse Mobile | 67 | 94 |
| Lighthouse Desktop | — (não medido) | 99 |
| LCP Mobile | 2,7s | 3,0s* |
| LCP Desktop | — | 0,5s |
| CLS | 0,758 | 0,02 |
| TBT | 0ms (depois 570ms desktop) | 70ms |
*LCP mobile ficou em 3s porque o Lighthouse simula 4G lento. Em conexão real, fica em ~1,2s. CrUX (field data) confirma.
Erros comuns que você provavelmente está cometendo
- Carregar bibliotecas inteiras pra usar 1 função — moment.js pesa 60 KB.
new Date()é nativo. - Não usar lazy loading em imagens abaixo da dobra —
loading="lazy"resolve em 1 atributo - Não declarar width/height em
<img>— navegador não sabe o tamanho até baixar, layout pula quando termina - Múltiplos scripts de tracking síncronos — GA, Meta Pixel, Hotjar, e mais 5 carregando em sequence é receita pra TBT alto
- CDN sem cache configurado — Cloudflare/BunnyCDN sem cache rule serve cada request do origin
- Servidor compartilhado lento — TTFB acima de 600ms estraga qualquer otimização frontend
Quando contratar ajuda
Otimização de performance é técnica especializada. Sites com score abaixo de 70 no Lighthouse perdem ranqueamento, conversão e percepção de qualidade. Quando faz sentido contratar:
- Score Lighthouse abaixo de 80 (mobile)
- LCP acima de 4s
- CLS acima de 0,25
- Páginas com mais de 3 MB de transferência
- TBT acima de 600ms
- Bounce rate alto em mobile mesmo com bom conteúdo
O ROI costuma ser claro: cada 100ms a menos de LCP aumenta conversão em ~1% (estudos consistentes do Google, Akamai e WPO Stats). Pra um site que faz R$ 50.000/mês, melhorar 1s de LCP pode significar +R$ 5.000-10.000/mês recorrentes.
Como a Uma Nova Imagem entrega
Oferecemos auditoria de performance e otimização completa como serviço dedicado. O processo:
- Auditoria — Lighthouse + CrUX + análise manual do código. Relatório detalhado.
- Roadmap priorizado — quais mudanças têm maior impacto vs esforço.
- Implementação — código aplicado direto no site (não em ambiente de teste que você precisa replicar).
- Validação — Lighthouse antes/depois, CrUX em 30 dias.
A partir de R$ 1.200 (one-shot pra sites pequenos/médios) ou R$ 600/mês (programa contínuo pra sites em produção ativa).
