Cada segundo a mais no carregamento de uma página reduz a taxa de conversão em até 20%, segundo pesquisa conjunta do Google com a Deloitte publicada em 2019. Não é uma estimativa vaga. O estudo mediu 37 sites de varejo e serviços financeiros durante dois meses e encontrou esse número de forma consistente em verticais diferentes.
- Um site de alta performance não é apenas rápido: ele elimina fricção em cada ponto de contato entre o usuário e a ação que o negócio quer que ele execute.
- As métricas Core Web Vitals do Google (LCP, CLS e INP) são o critério técnico que separa sites que convertem dos que apenas existem.
- A stack Next.js com Vercel Edge Network permite atingir score 95 ou mais no PageSpeed Insights de forma consistente e reproduzível.
- Projetos reconstruídos com essa abordagem saem, em média, de score 43 para 94, com ganhos mensuráveis em tráfego orgânico e geração de leads.
- Um checklist de 12 otimizações cobre todos os pontos críticos aplicados em cada projeto entregue pelo W-ID.
O Google confirmou em 2021 que os Core Web Vitals são fator de ranqueamento direto. Sites com LCP abaixo de 2,5 segundos e CLS abaixo de 0,1 recebem um boost de posicionamento mensurável em SERPs competitivas. Para negócios que dependem de tráfego orgânico, isso não é detalhe técnico: é receita. Uma melhoria de uma posição nos resultados de busca aumenta o CTR médio em 2,8 pontos percentuais, de acordo com dados agregados da Ahrefs de 2023. Multiplicado pelo volume de buscas de qualquer nicho com demanda real, o impacto financeiro justifica qualquer investimento em performance.
O que os Core Web Vitals medem de verdade
O Google criou os Core Web Vitals para quantificar experiência do usuário com números objetivos. Antes deles, performance era um conceito difuso. Hoje, três métricas definem se um site entrega ou não uma experiência aceitável.
LCP: o momento em que o usuário decide ficar ou sair
O Largest Contentful Paint mede quanto tempo leva para o maior elemento visível da tela ser renderizado. Na prática, costuma ser o banner principal, o título H1 de destaque ou a imagem hero. O Google considera bom qualquer valor abaixo de 2,5 segundos. Entre 2,5 e 4 segundos é considerado necessita de melhoria. Acima de 4 segundos é ruim.
O que acontece quando o LCP está ruim? O usuário vê uma tela parcialmente carregada por segundos. O cérebro interpreta isso como instabilidade, mesmo que o conteúdo apareça depois. Segundo dados do Think with Google, 53% dos usuários de mobile abandonam uma página que demora mais de 3 segundos para carregar. O LCP alto não afasta apenas usuários impacientes: afasta a maioria.
As causas mais comuns de LCP alto incluem imagens sem compressão adequada, fontes carregadas de forma bloqueante, servidores com Time to First Byte (TTFB) elevado e ausência de CDN para distribuição geográfica dos assets.
CLS: o problema que irrita sem que o usuário saiba nomear
O Cumulative Layout Shift mede o quanto os elementos da página se movem de forma inesperada durante o carregamento. O score vai de 0 a qualquer valor positivo. Abaixo de 0,1 é considerado bom. Acima de 0,25 é ruim.
O impacto prático é frustrante: o usuário está prestes a clicar em um botão, o layout muda porque uma imagem carregou, e ele clica no elemento errado. Ou está lendo um parágrafo e o texto pula para baixo. O Google relatou que o CLS alto é um dos principais responsáveis por rejeição em páginas de e-commerce, especialmente em mobile.
As causas típicas de CLS alto são imagens sem dimensões definidas no HTML, banners de anúncio inseridos dinamicamente sem espaço reservado, e fontes web que substituem fontes fallback com métricas diferentes.
INP: a métrica que substituiu o FID e que a maioria dos times ainda ignora
O Interaction to Next Paint substituiu o First Input Delay como métrica oficial em março de 2024 e mede a latência de todas as interações do usuário com a página, não apenas a primeira. Um bom INP fica abaixo de 200 milissegundos. Acima de 500ms é classificado como ruim.
Na prática, um INP alto significa que o usuário clica em um menu, um filtro ou um campo de formulário e a página demora para responder. A sensação é de travamento. Em aplicações com muitos componentes interativos, isso destrói a percepção de qualidade mesmo que o carregamento inicial seja rápido.
JavaScript excessivo no thread principal é o principal culpado. Scripts de terceiros como chatbots, pixels de rastreamento e ferramentas de analytics mal configuradas bloqueiam o thread e aumentam o INP de forma consistente.
| Métrica | Bom | Necessita melhoria | Ruim | Principal causa de problema |
|---|---|---|---|---|
| LCP | Abaixo de 2,5s | 2,5s a 4s | Acima de 4s | Imagens sem compressão, ausência de CDN |
| CLS | Abaixo de 0,1 | 0,1 a 0,25 | Acima de 0,25 | Imagens sem dimensões, fontes sem size-adjust |
| INP | Abaixo de 200ms | 200ms a 500ms | Acima de 500ms | JavaScript excessivo no thread principal |
A stack que o W-ID usa para entregar score 95 de forma consistente
Existem muitas formas de construir um site rápido. A maioria envolve compensações. Algumas stacks são rápidas por padrão, mas limitam o que o designer pode fazer. Outras são flexíveis, mas exigem configuração manual de cada otimização. A combinação Next.js com Vercel elimina boa parte dessas compensações porque a performance está embutida na arquitetura, não adicionada depois como camada separada.
Next.js como base de renderização
O Next.js permite escolher, rota por rota, entre Static Site Generation (SSG), Server-Side Rendering (SSR) e Incremental Static Regeneration (ISR). Para um site institucional ou de marketing, SSG entrega o HTML pré-renderizado diretamente do CDN, sem nenhum processamento de servidor no momento da requisição. O resultado é um TTFB medido em milissegundos, não segundos.
O App Router do Next.js 13 em diante também introduziu os React Server Components, que eliminam JavaScript desnecessário do bundle enviado ao navegador. Componentes que apenas renderizam HTML estático não precisam de nenhum JavaScript no cliente. Em projetos com muitos componentes, isso reduz o Total Blocking Time de forma significativa.
Vercel Edge Network para distribuição global
Hospedar um site em um único servidor datacenter em São Paulo significa que usuários em Porto Alegre, Recife ou Manaus recebem a resposta com latência proporcional à distância física. A Vercel opera mais de 100 pontos de presença globais e serve o conteúdo estático a partir do ponto geograficamente mais próximo do usuário.
A diferença no TTFB entre um servidor único e uma edge network bem configurada costuma ser de 300ms a 800ms, dependendo da localização do usuário. Em uma métrica de LCP onde o alvo é 2,5 segundos totais, economizar 500ms na entrega do primeiro byte é mais impactante do que qualquer outra otimização isolada.
Otimização de imagem com next/image
O componente next/image faz automaticamente várias coisas que desenvolvedores costumam esquecer ou implementar de forma inconsistente. Ele converte imagens para WebP ou AVIF conforme o suporte do navegador, redimensiona para a largura exata necessária em cada viewport, e aplica lazy loading em imagens fora da viewport inicial. O atributo priority pode ser configurado na imagem hero para que ela seja carregada com preload, o que reduz diretamente o LCP.
Imagens são responsáveis por 50% do peso médio de uma página web, segundo o HTTP Archive. Usar next/image em vez de tags img convencionais reduz o peso de imagens em 40% a 60% na maioria dos projetos, sem nenhuma perda visual perceptível.
Font subsetting e eliminação de render-blocking
Fontes web são uma das causas mais subestimadas de LCP alto. Quando um navegador encontra uma fonte externa no CSS, ele bloqueia a renderização do texto até que a fonte carregue. O resultado é o Flash of Invisible Text (FOIT), onde o usuário vê a página sem texto por um momento, ou o Flash of Unstyled Text (FOUT), onde o texto aparece com a fonte fallback e depois muda.
O Next.js resolve isso com o módulo next/font, que baixa as fontes em build time, as serve do próprio domínio (eliminando a requisição externa ao Google Fonts) e aplica size-adjust automático na fonte fallback para minimizar o CLS causado pela troca de fontes.
Font subsetting é o complemento: em vez de carregar o arquivo completo de uma fonte (que pode ter 200kb ou mais para suporte a múltiplos idiomas), carrega-se apenas os glyphs realmente usados no projeto. Para um site em português, isso elimina centenas de caracteres desnecessários e reduz o tamanho do arquivo de fonte em até 70%.
O checklist de 12 otimizações aplicado em cada projeto do W-ID
Este checklist cobre todos os pontos verificados antes de qualquer entrega. Não é uma lista de boas práticas genéricas: cada item tem uma razão específica e um impacto mensurável.
- Imagem hero com preload e atributo priority ativo via next/image, garantindo que o LCP não seja bloqueado por carregamento tardio do maior elemento visual.
- Todas as imagens com dimensões width e height definidas no HTML, eliminando o CLS causado por reflow quando a imagem é carregada.
- Conversão automática para WebP e AVIF com fallback para JPEG/PNG em navegadores sem suporte.
- Fontes servidas via next/font com subset restrito ao latin e latin-ext, eliminando requisições externas e reduzindo o tamanho do arquivo.
- Scripts de terceiros (pixels, analytics, chat) carregados com strategy=”lazyOnload” via next/script, evitando que eles bloqueiem o thread principal durante o carregamento inicial.
- CSS crítico inlined no head para que a renderização da área visível não dependa de arquivos externos.
- Deploy na Vercel com Edge Network ativa e headers de cache configurados para assets estáticos com max-age de 31536000 segundos.
- Lighthouse CI integrado ao pipeline de deploy, bloqueando publicações que reduzam o score abaixo de 90.
- Eliminação de dependências JavaScript desnecessárias, com bundle analysis via @next/bundle-analyzer antes de cada release.
- Lazy loading de componentes abaixo da dobra via dynamic import do Next.js, reduzindo o JavaScript carregado na interação inicial.
- Configuração de size-adjust na fonte fallback para minimizar o CLS durante a transição entre fonte fallback e fonte web.
- Verificação de score no PageSpeed Insights em mobile e desktop como critério obrigatório de aceite antes da entrega ao cliente.
O item 8 é o que mais diferencia o processo: a maioria dos times verifica performance depois do lançamento. Bloquear o deploy automaticamente quando o score cai cria uma barreira que impede regressões. Um único script de terceiro adicionado sem cuidado pode derrubar o INP de 150ms para 600ms. O Lighthouse CI no pipeline detecta isso antes que chegue à produção.
Case real: de score 43 para 94 com impacto em tráfego orgânico
Os números abaixo refletem dados agregados dos projetos de reconstrução entregues pelo W-ID nos últimos 3 anos, considerando clientes que migraram de sites construídos em WordPress com builders visuais (Elementor, WPBakery) para projetos novos em Next.js.
| Métrica | Antes da migração | Após migração | Variação |
|---|---|---|---|
| PageSpeed Score (mobile) | 43 | 94 | +119% |
| LCP médio | 6,2s | 1,8s | -71% |
| CLS médio | 0,38 | 0,04 | -89% |
| Tráfego orgânico (6 meses após) | Baseline | +34% em média | +34% |
| Taxa de conversão (leads ou vendas) | Baseline | +27% em média | +27% |
O dado de 27% de aumento em taxa de conversão é o mais relevante para qualquer decisão de negócio. Performance não é uma conquista técnica isolada: ela muda o comportamento do usuário em cada etapa do funil. Um site que carrega em 1,8 segundos em vez de 6,2 segundos mantém o usuário na página, reduz o bounce rate e entrega mais sessões que chegam até o formulário ou o botão de compra.
O aumento de 34% em tráfego orgânico ao longo de 6 meses não é apenas efeito do boost de Core Web Vitals no algoritmo. Sites mais rápidos têm taxas de rastreamento (crawl rate) melhores porque o Googlebot consegue indexar mais páginas por sessão. E taxas de rejeição menores sinalizam relevância para o Google, o que contribui para melhorias de posicionamento além das métricas de velocidade.
O que costuma estar errado nos sites antes da migração
Builders visuais como Elementor carregam entre 400kb e 1,2mb de JavaScript e CSS por padrão, grande parte do qual não é usado em nenhuma página específica. Esse é o principal fator que leva scores de mobile para abaixo de 50. O WordPress em si não é o problema: o problema é a camada de abstração do builder, que prioriza facilidade de edição sobre eficiência de entrega.
Plugins de cache parcialmente resolvem o problema, mas não eliminam o JavaScript de renderização do builder. Um site construído no Elementor com WP Rocket configurado corretamente raramente passa de 70 no PageSpeed mobile. Para um site de alta performance com score consistentemente acima de 90, a reconstrução é o caminho mais direto.
Performance em mobile versus desktop: onde está o dinheiro
Uma armadilha comum é otimizar para desktop e considerar o trabalho feito. O PageSpeed Insights mostra dois scores separados por um motivo: as condições simuladas são radicalmente diferentes. O score de mobile simula uma conexão 4G lenta com um dispositivo de CPU equivalente a um Moto G4 de 2016.
No Brasil, 58% do tráfego web vem de dispositivos móveis, segundo dados da StatCounter de 2024. Para negócios B2C, esse número costuma ser ainda maior. Otimizar apenas para desktop significa otimizar para a minoria do tráfego.
A diferença típica entre score mobile e desktop em projetos mal otimizados chega a 40 pontos. Um site que marca 85 no desktop pode marcar 45 no mobile com os mesmos assets, porque o dispositivo simulado tem 6 vezes menos poder de CPU para processar o JavaScript. Isso significa que otimizar o JavaScript é proporcionalmente mais impactante do que qualquer outra melhoria de infraestrutura para usuários mobile.
Monitoramento contínuo: performance não é estado, é processo
Um score de 94 no momento do lançamento não garante 94 seis meses depois. Cada script de analytics adicionado, cada plugin de chat instalado, cada integração nova com ferramenta de marketing empurra o score para baixo. Sem monitoramento, a degradação é invisível até que seja grave o suficiente para aparecer em queda de tráfego.
O Google Search Console exibe um relatório de Core Web Vitals com dados reais de usuários (não dados de laboratório), divididos entre mobile e desktop. Esse relatório mostra URLs específicas com problemas e a escala do impacto. Verificar esse relatório mensalmente é suficiente para detectar regressões antes que afetem ranqueamento.
A diferença entre dados de laboratório (PageSpeed Insights) e dados de campo (Core Web Vitals no Search Console) é relevante. Um score de 94 no laboratório pode coexistir com um LCP de campo de 3,2 segundos se uma parcela dos usuários reais tiver conexões mais lentas ou dispositivos mais antigos. O Search Console mede o que os usuários reais experimentam, não o que a ferramenta de teste simula.
Ferramentas como Vercel Analytics e Sentry Performance Monitor permitem rastrear Core Web Vitals por rota em tempo real, com alertas configuráveis. Em projetos com atualizações frequentes de conteúdo ou integrações de terceiros, esse monitoramento automatizado substitui a verificação manual e detecta problemas antes que o Google os registre como tendência negativa.
Perguntas frequentes sobre site de alta performance
O Google classifica um site como de alta performance quando ele atinge LCP abaixo de 2,5 segundos, CLS abaixo de 0,1 e INP abaixo de 200ms. No PageSpeed Insights, isso corresponde a um score acima de 90, tanto em mobile quanto em desktop. Sites que atingem esses valores consistentemente recebem um boost de posicionamento nos resultados de busca.
WordPress sem builder visual, com tema leve e configuração cuidadosa de cache, pode atingir score entre 80 e 88 em mobile. Com builders como Elementor ou WPBakery, o teto prático fica entre 60 e 70 mesmo com plugins de otimização. Para score consistente acima de 90, especialmente em mobile, a arquitetura Next.js com deploy em edge network entrega resultados que o WordPress com builder não consegue reproduzir.
Um projeto institucional de 8 a 15 páginas leva entre 6 e 10 semanas com o processo completo de design customizado, desenvolvimento e otimização de performance. Projetos com muitas páginas de conteúdo dinâmico ou integrações complexas levam mais tempo. O W-ID entregou mais de 150 projetos nesse modelo em 7 anos, o que torna a estimativa de prazo previsível para a maioria dos casos.
Sim. O Google confirmou em maio de 2021, com o Page Experience Update, que Core Web Vitals são fator de ranqueamento. O impacto é mais relevante em nichos onde vários sites concorrem por posições com conteúdo de qualidade similar. Nesses casos, a performance técnica funciona como desempate. Em nichos com pouca concorrência técnica, sites rápidos ganham vantagem mais rápido ainda.
Depende do ponto de partida. Se o site atual tem score acima de 60 e foi construído com código limpo, otimizações pontuais resolvem. Se o score mobile está abaixo de 50 e o site usa builder visual, a reconstrução entrega resultado muito superior em menos tempo do que tentar corrigir os problemas na base existente. O custo de manutenção de um site mal estruturado ao longo de anos supera o investimento em reconstrução na maioria dos casos.
