Otimização de velocidade de sites e Core Web Vitals

O que um projeto de otimização de velocidade inclui#

A proposta indica os modelos de página incluídos, quais destas entregas se aplicam, quem implementa cada correção e como ela é aceita:

• Uma linha de base de dados de campo por modelo de página, a partir do CrUX, do Search Console e da sua analytics
• Rastreamentos de laboratório dos modelos mais lentos em um celular intermediário emulado, com a CPU desacelerada
• Uma lista de correções priorizada por visitas afetadas, métrica que melhora e esforço
• Um inventário de scripts de terceiros, com um responsável e uma decisão para cada tag
• Correções no seu código, tema ou CMS, ou tickets para os seus desenvolvedores
• Medição de usuários reais de LCP, INP e CLS onde faltam os dados do Google
• Um relatório de antes e depois com dados de campo

Quais notas são boas nos Core Web Vitals?#

O Google avalia três métricas no percentil 75 dos carregamentos de página, separadamente para mobile e desktop. O Largest Contentful Paint (LCP), o momento em que o conteúdo principal aparece, é bom com 2,5 segundos ou menos e ruim acima de 4 segundos. O Interaction to Next Paint (INP), a rapidez com que a página responde a uma interação, é bom com 200 milissegundos ou menos e ruim acima de 500. O Cumulative Layout Shift (CLS), o quanto o layout pula, é bom com 0,1 ou menos e ruim acima de 0,25.

O país dos seus visitantes muda o que é aprovado: em Core Web Vitals no Brasil comparamos os mesmos sites nos Estados Unidos e na região.

O INP substituiu o First Input Delay em 12 de março de 2024; uma auditoria ou um plugin que ainda avalia o First Input Delay está desatualizado.

Primeiro os dados de campo, depois os de laboratório#

Partimos do que os visitantes reais viveram e só então usamos testes de laboratório para achar a causa. Os dados de campo do Google são o Chrome User Experience Report (CrUX), uma média móvel de 28 dias das visitas de usuários elegíveis do Chrome. O relatório de Core Web Vitals do Search Console os lê, agrupa URLs parecidas e dá a cada grupo o status da sua pior métrica.

Como referência, nosso relatório de velocidade de plataformas web gratuito mostra como os sites da sua plataforma se saem com visitantes reais no seu país, com dados do Chrome UX Report atualizados todo mês.

O PageSpeed Insights mostra esses dados de campo acima de um teste do Lighthouse que simula um celular intermediário em uma rede móvel. O Lighthouse não consegue medir o INP, porque ninguém toca na página, e informa o Total Blocking Time no lugar. Os testes de laboratório mostram as causas; os dados de campo definem as prioridades.

O CrUX cobre apenas o Chrome no desktop e no Android, então os visitantes de iPhone ficam de fora, e páginas abaixo de um limite de tráfego não divulgado não têm dados. Quando essas lacunas importam, adicionamos medição de usuários reais ao seu site; desde o Safari 26.2, lançado em dezembro de 2025, ela também consegue registrar LCP e INP em iPhones.

O que deixa um site lento e como corrigimos cada causa#

A auditoria nomeia a causa por trás de cada métrica que falha. O web.dev divide o LCP em resposta do servidor, o atraso até o navegador encontrar a imagem principal, o download dela e a sua renderização, o que nos diz se devemos corrigir o servidor, o HTML ou o arquivo. A orientação do Google é direta em um ponto: nunca aplique lazy loading à imagem do LCP; dê a ela, em vez disso, uma prioridade de carregamento alta.

As correções são ordenadas pelas visitas que afetam e pelo esforço. Remover uma tag sem uso leva minutos; um page builder que carrega os mesmos scripts em todas as páginas obriga a refazer aquele modelo.

Os Core Web Vitals afetam o ranking no Google?#

Sim, mas como um sinal entre muitos, atrás da relevância. A documentação de experiência da página do Google diz que os "Core Web Vitals são usados pelos nossos sistemas de classificação" e também que a Busca mostra o conteúdo mais relevante mesmo quando a experiência da página é fraca. Boas notas não garantem as primeiras posições.

Por isso vendemos o trabalho de velocidade pensando nos seus visitantes, que passam a ler e agir mais cedo, e não como uma solução de ranking. Se o seu objetivo é o ranking, o nosso serviço de SEO técnico parte das buscas, páginas e links que pesam mais.

Como manter rápidas as páginas 3D e com muito movimento#

Uma página 3D pode passar nos Core Web Vitals se a cena carregar depois do conteúdo. Um canvas não está entre os tipos de elemento que o LCP considera, então deixamos o título, o texto e uma imagem de pôster no HTML e iniciamos a cena quando eles já estão na tela. O risco passa então para o INP: preparar shaders, texturas e modelos cria tarefas longas, que dividimos e testamos em celulares com rede e CPU limitadas.

Trabalhamos o nosso próprio site assim: a página inicial do dardo.studio é uma cena 3D em tempo real, medida com o Cloudflare Web Analytics e a biblioteca de código aberto web-vitals do Google, sem cookies. Lemos os dados brutos antes de mudar qualquer coisa. Em 3 de outubro de 2026, o tempo de carregamento de página de 24 horas da Cloudflare marcava 2,2 segundos, mas era a mediana de apenas 17 carregamentos, seis deles feitos fora da vista pelo navegador embutido da Meta, e essa métrica espera por todas as imagens e scripts, não pelo que os visitantes veem.

Testes de laboratório com limitações encontraram duas causas simples: uma captura de tela sem perdas que os celulares baixavam com 318 KB, agora com 81 KB, e uma analytics de gravação de sessões que começava antes de a página terminar de carregar, agora começa depois. Em 4G rápido, o celular emulado terminou de carregar em 894 milissegundos em vez de 1.476.

Os orçamentos de modelos e texturas estão no nosso artigo sobre como manter sites 3D rápidos; construir a cena é o nosso serviço de sites 3D interativos.

Como o trabalho acontece: auditoria, correções e uma verificação com dados de campo#

Cada projeto começa com uma linha de base e termina com uma comparação sobre os mesmos dados, para os modelos de página que concentram mais visitas ou receita: a página inicial, uma página de produto ou serviço, um artigo.

As correções vão primeiro para uma cópia de homologação antes da produção, ou para os seus desenvolvedores como tickets. Os testes de laboratório mostram o efeito no mesmo dia; os dados de campo levam mais tempo, porque o CrUX faz a média de 28 dias e o acompanhamento de correções do Search Console monitora as URLs afetadas por 28 dias. Anotamos a data de cada lançamento e comparamos quando a janela se renova.

O relatório e a configuração de medição ficam nas suas contas, e um plano de manutenção de sites pega as regressões causadas por novas tags e imagens depois de cada lançamento.

O que move o preço do trabalho de velocidade#

A otimização de velocidade não tem preço inicial publicado; a auditoria e as correções são orçadas separadamente. O que move o orçamento:

• Modelos de página incluídos: cada modelo distinto é rastreado, não cada URL
• Plataforma: em Shopify, Webflow ou um page builder de WordPress, parte do peso não pode ser removida
• Scripts de terceiros, cada um com a decisão do seu responsável
• Mudanças de design, como trocar um vídeo de capa ou uma família tipográfica
• Dados de campo ausentes, que precisam ser coletados antes de existir uma linha de base
• Quem implementa: a Dardo, os seus desenvolvedores ou ambos

As faixas de orçamento dos nossos projetos e os preços iniciais de outros serviços estão na página de preços.

Quando a otimização de velocidade não é a solução#

O trabalho de velocidade serve para um site cujo conteúdo e estrutura funcionam, mas cujas páginas são lentas. Se o tema ou a plataforma é o peso, reconstruir resolve mais do que ajustar: um redesign de site ou uma migração de site, por exemplo para o Astro, que gera as páginas como HTML antecipadamente. Se as páginas são rápidas mas os visitantes não agem, escolha a otimização da taxa de conversão. Para um site novo, planejamos a velocidade dentro da construção, por meio do desenvolvimento web, em vez de auditá-la depois.

Dúvidas antes de escolher#

Do blog#

• Core Web Vitals no Brasil e na América Latina: quantos sites são aprovados por país (dados 2026)

  Em setembro de 2026, só 33,7% dos sites foram aprovados nas Core Web Vitals no celular no Brasil, contra 63,3% nos EUA. Os dados por país e o que fazer.

• Como melhorar os Core Web Vitals: guia baseado em dados de campo para sites de marketing

  Descubra qual métrica e template falham no Search Console, corrija LCP, INP e CLS pela causa e confirme o resultado nos dados de campo cerca de 28 dias depois.