Velocidade da página: otimização completa do carregamento do site

A velocidade da página é um dos investimentos que mais impactam SEO e conversão ao mesmo tempo. A Amazon calculou que cada 100 ms de latência extra custa 1% das vendas. O Google usa a velocidade como fator de ranqueamento no desktop desde 2010 e no mobile desde 2018. Em 2021, ele introduziu os Core Web Vitals como sinal direto de Page Experience.

zoom_in

O que é a velocidade da página e como ela é medida

A velocidade da página não é um número só. É um conjunto de métricas, e cada uma mede um aspecto diferente da experiência de carregamento. O Google combina no PageSpeed Insights os dados de laboratório (Lighthouse) e os dados de campo de usuários reais (Chrome User Experience Report). A nota final, de 0 a 100, é uma soma ponderada de várias métricas. Por isso, não a use como único alvo de otimização.

Para SEO, o que importa são os dados de campo (CrUX): o Google usa o 75º percentil de usuários reais do Chrome para avaliar os Core Web Vitals. O Lighthouse ajuda a diagnosticar problemas, mas não entra diretamente no algoritmo de ranqueamento.

Principais métricas de velocidade

Cada métrica trata de um aspecto específico da experiência do usuário. Entender a diferença entre elas é a base de um diagnóstico correto.

Diagnóstico: por onde começar a otimização

Otimizar às cegas é tempo perdido. A sequência correta: medir primeiro, identificar o gargalo, corrigir e medir de novo.

1. Abra o PageSpeed Insights e teste de 5–10 páginas-chave: página inicial, categorias, cards de produtos, landing pages. Olhe os dados de campo, e não apenas a nota do Lighthouse.
2. No Google Search Console, acesse Core Web Vitals. Ele mostra quais URLs têm avaliação “Ruim” ou “Precisa de melhorias” para LCP, INP e CLS, com dados reais de usuários.
3. Execute o WebPageTest para uma análise profunda: waterfall de carregamento, filmstrip, TTFB e impacto do CDN. Escolha a região de teste mais próxima do seu público principal.
4. Use o Chrome DevTools → Performance e grave o carregamento de uma página. O flame chart mostra qual script ocupa a thread principal e bloqueia a renderização.
5. Confira o Coverage (DevTools → Coverage): CSS e JS não usados são candidatos diretos à remoção ou ao carregamento adiado.

Otimização do servidor e do TTFB

O TTFB (Time to First Byte) é a base de toda a velocidade. Se o servidor responde devagar, cada otimização seguinte trabalha contra um teto artificial. Meta: TTFB < 200 ms em ambientes com CDN e < 400 ms em servidores dinâmicos.

Hospedagem e infraestrutura

Escolha da hospedagem

A hospedagem compartilhada, com recursos divididos entre milhares de sites, limita o TTFB de forma física. Um VPS ou servidor dedicado com Nginx/Caddy e cache adequado entrega TTFB de 20–80 ms para conteúdo estático.

CDN (Content Delivery Network)

Cloudflare, BunnyCDN, Fastly — o nó de borda mais próximo responde no lugar do seu servidor de origem. Para conteúdo estático ou em cache, o TTFB cai para 10–50 ms. Para conteúdo dinâmico, depende da configuração do cache de borda.

HTTP/2 e HTTP/3 (QUIC)

O HTTP/2 elimina o bloqueio head-of-line e oferece multiplexação. O HTTP/3 sobre QUIC acelera ainda mais o estabelecimento da conexão (0-RTT) e resiste melhor à perda de pacotes em redes móveis.

Localização do servidor

A distância física entre o usuário e o servidor acrescenta cerca de 1 ms a cada 100 km (ida e volta). Para um público principalmente europeu, um servidor em Frankfurt ou Amsterdã é bem mais rápido do que o US-East.

Compressão e codificação

• Ative o Brotli (br): ele economiza 15–25% em relação ao gzip, com velocidade de descompressão parecida. É suportado por todos os navegadores modernos.
• Mantenha o gzip como alternativa para clientes antigos. Mínimo: nível de compressão 6.
• Configure a compressão para HTML, CSS, JS, JSON, XML e SVG. Imagens e arquivos binários já são comprimidos, então aplicar gzip neles não adianta.
• Use o cabeçalho Vary: Accept-Encoding para que o CDN guarde versões separadas para clientes diferentes.

Cache no servidor

Páginas dinâmicas (PHP, Node.js, Python) consultam o banco de dados a cada requisição. Um cache permite entregar o HTML pronto, sem recálculo.

• Cache de página inteira: Nginx FastCGI Cache, Varnish, Redis — guardam o HTML pronto e o entregam sem tocar na aplicação.
• Cache de objetos: Redis ou Memcached para guardar resultados de consultas ao banco, sessões e dados calculados.
• Regras de invalidação: o cache precisa ser limpo quando o conteúdo muda (webhook do CMS ou expiração por TTL).
• Stale-while-revalidate: entregue o cache antigo na hora e regenere em segundo plano — o usuário não espera a regeneração.

Otimização de recursos: imagens, fontes, CSS

Imagens

As imagens costumam ser a categoria mais pesada de uma página. Otimizá-las bem gera economia de 30–70% no tráfego e afeta diretamente o LCP.

Use o elemento <picture> para servir o formato certo: AVIF para os navegadores que suportam, WebP como alternativa e JPEG/PNG para navegadores antigos. O componente Image do Next.js faz isso automaticamente.

Fontes

• Hospede as fontes você mesmo: sirva arquivos .woff2 do seu próprio domínio. Assim você elimina a consulta DNS, o handshake TCP e a dependência do CDN do Google Fonts.
• Pré-carregue as fontes críticas: <link rel="preload" as="font" type="font/woff2" crossorigin> no <head> — o navegador começa a carregar antes de o CSS ser lido.
• font-display: swap — o navegador mostra a fonte do sistema enquanto a personalizada carrega. Isso elimina o FOIT (texto invisível).
• Subconjunto de fontes: carregue só os glifos necessários (alfabeto latino + cirílico). Ferramentas: glyphhanger ou fonttools.
• Use fontes variáveis (variable fonts): um arquivo só, em vez de vários pesos (regular, negrito, itálico). Isso economiza 30–50% do tamanho total das fontes.

CSS

CSS crítico inline

Os estilos acima da dobra são inseridos diretamente no <head>, dentro de uma tag <style>. O navegador renderiza a primeira tela sem esperar um arquivo CSS externo. O restante do CSS carrega de forma assíncrona.

Minificação

Remoção de espaços e comentários, e encurtamento de propriedades. Cssnano ou LightningCSS. Economia típica: 10–30% do tamanho original.

Remoção de CSS não utilizado

PurgeCSS, UnCSS ou o mecanismo embutido do framework (purge do Tailwind). É especialmente importante ao usar Bootstrap ou Material UI, que trazem milhares de regras não utilizadas.

Evite @import no CSS

O @import em CSS cria requisições em sequência: o navegador carrega o arquivo, encontra o @import e só então começa a carregar o próximo. Use tags <link> para carregamento paralelo.

JavaScript: bloqueio de renderização e thread principal

O JavaScript é o principal inimigo da velocidade da página em sites modernos. Ele bloqueia a renderização, ocupa a thread principal e atrasa a interatividade. Meta: pouco JS no caminho crítico e o máximo possível de defer, async e import dinâmico.

Estratégias de carregamento

Bundle e divisão de código

• Code splitting: divida o JS em partes (chunks) e carregue só o necessário para a página atual. No Next.js, isso acontece automaticamente por página.
• Import dinâmico: import('module') para componentes que não são necessários no carregamento inicial (janelas modais, abas, filtros).
• Tree shaking: o bundle inclui apenas o código realmente usado. Webpack e Rollup fazem isso com pacotes ESM. Confira se há dependências CommonJS quebrando o tree shaking.
• Análise do bundle: bundlephobia.com para checar o tamanho dos pacotes npm, e @next/bundle-analyzer para o Next.js, que mostra exatamente o que ocupa espaço.
• Evite bibliotecas monolíticas grandes: moment.js (67 KB) → day.js (2 KB), lodash → utilitários individuais, jQuery → JS nativo.

SPA e renderização no servidor

SPAs no cliente (React sem SSR, Angular, Vue com CSR) devolvem HTML vazio e geram o conteúdo no navegador. Isso leva a um LCP alto e a um Time to Interactive ruim.

SSR (Server-Side Rendering)

O HTML completo é gerado no servidor, e o navegador recebe o conteúdo pronto de imediato. LCP, FCP e Lighthouse Score melhoram muito. Exige hidratação no cliente, então leve em conta o TTI (Time to Interactive).

SSG (Static Site Generation)

O HTML é gerado no momento do build. Velocidade máxima de TTFB e LCP. Indicado para conteúdo que muda pouco: blog, documentação e landing pages.

PPR (Partial Prerendering)

Novidade do Next.js 15: uma casca estática da página com partes dinâmicas em streaming. A casca é servida na hora pelo CDN, enquanto os dados dinâmicos chegam conforme ficam prontos.

Cache: navegador e CDN

Um cache bem configurado é a otimização mais barata e a de maior impacto para visitantes recorrentes. Meta: todos os recursos estáticos em cache por 1 ano; o HTML com pouco ou nenhum cache.

• Hash baseado no conteúdo (fingerprinting): Webpack, Vite e Next.js acrescentam automaticamente um hash do conteúdo ao nome do arquivo. Quando o código muda, o hash muda e o cache antigo não é usado.
• ETag e Last-Modified: se o cliente já tem o recurso, o servidor responde 304 Not Modified, sem corpo. Gasta menos tráfego, mas ainda há a ida e volta da rede.
• Service Worker: um cache programável no navegador. Permite estratégias complexas (Cache-First, Network-First, Stale-While-Revalidate) para PWAs e uso offline.
• Cache-Control no CDN: use o s-maxage para controlar o cache do CDN separadamente do max-age do navegador. O CDN guarda por mais tempo, e o navegador, por menos.

Scripts de terceiros: o vilão oculto

Scripts de terceiros (analytics, chats, pixels, testes A/B, widgets) costumam ser a principal causa de TBT e INP ruins. Uma página comercial média carrega de 15 a 30 scripts de terceiros.

Perguntas frequentes