Verificador de velocidade da página e Core Web Vitals
Free, no signup. Core Web Vitals reports are usually a wall of numbers before they tell you anything useful. This leads with one sentence: whether the page passes, and the single thing to fix first — real Chrome user data when it exists, a Lighthouse lab audit when it doesn't.
+ salva o site ou a página atual. Use ☆ ao lado de qualquer site, página ou lista salva para adicioná-la aos favoritos. O histórico de verificações recentes aparece abaixo.
Criar uma lista nomeada
Alvo preenchido a partir das suas escolhas locais.
Passaporte do site Contexto local deste site salvo
Dados locais
Alvos salvos, listas nomeadas e resumos de verificações recentes permanecem apenas neste navegador.
Lab methodology and provenance
Geography: PSI does not provide a test location. A non-regional lab result is diagnostic, not evidence of performance for local users or a target market. Use a regional provider when geography matters.
Lab vs. field comparison
Field data describes real Chrome visits over 28 days; lab data is one simulated run. Use the lab trace to investigate, then use field data to judge the real-user outcome.
What to fix, in order
Elements Lighthouse singled out
Compare a later check
Download this result as a private JSON baseline, then import it after another check to compare the verdict, data source, and metric changes.
Avaliar esta ferramenta
Origin scorecard (mobile field data)
| Origin | Verdict | Worst metric | LCP | INP | CLS |
|---|
Field data is Google's Chrome UX Report — the same 28-day real-user dataset Search uses for the page-experience signal; it updates daily, so repeat checks within 24 hours are served from cache. Lab numbers come from Lighthouse with simulated throttling: expect them to differ from field data and to vary between runs. Lab audits can't measure INP (it needs real users).
Sobre esta ferramenta
Grátis, sem cadastro. Os relatórios de Core Web Vitals geralmente são uma parede de números antes de dizer qualquer coisa útil. Este verificador começa com uma frase: se a página passa e qual é a única coisa a corrigir primeiro — dados de usuários reais do Chrome quando disponíveis, ou uma auditoria de laboratório do Lighthouse quando não estão.
Recursos
- Veredito primeiro: uma frase simples identifica a métrica com pior desempenho no dispositivo pior, em vez de uma parede de números.
- Dados de campo de usuários reais primeiro (CrUX), com fallback automático para dados da origem e depois uma auditoria de laboratório do Lighthouse — cada fonte é identificada no cartão.
- Cartões de dispositivos móveis e desktop lado a lado, com o celular destacado como o dispositivo usado pelo Google para classificar.
- Lista de correções diagnósticas priorizada a partir das auditorias do Lighthouse realmente executadas, além de auditoria de laboratório opcional e modo em massa para até 5 domínios com exportação CSV.
Como funciona
O verificador consulta primeiro dados de campo de usuários reais do Chrome UX Report (CrUX) para a URL exata e, quando não há amostra, tenta os dados da origem; se ainda não houver dados, executa uma auditoria de laboratório do Lighthouse. O veredito usa os limites oficiais exatos de LCP, INP e CLS e escolhe a restrição determinante pela distância de cada métrica abaixo do esperado em relação à faixa boa, priorizando o celular em empates. O mecanismo de correções relaciona a métrica de pior desempenho às auditorias do Lighthouse acionadas na página, garantindo pelo menos um próximo passo concreto.
Limitações
- Os dados de campo precisam de tráfego: páginas novas ou com pouco tráfego podem não ter amostra do CrUX, então você verá dados da origem ou números de laboratório. As auditorias de laboratório usam limitação simulada; esta verificação pública executa uma vez, varia entre execuções e não mede INP a partir de interações reais. Auditorias pagas ou administrativas podem usar a mediana de três execuções. O PSI não informa uma localização regional de teste, portanto o resultado de laboratório não deve ser tratado como desempenho do mercado-alvo; use um provedor regional quando a geografia importar. Os dados de campo podem atrasar a realidade em até 28 dias, então uma correção publicada ontem não aparece imediatamente na janela contínua.
- Nada do que você verifica é armazenado; verificações repetidas em até 24 horas são atendidas pelo cache.
Perguntas frequentes
Quais são os limites dos Core Web Vitals?
Uma página passa quando sua pontuação do 75º percentil é "boa" nas três métricas: Maior pintura com conteúdo (LCP) em 2.5 segundos ou menos, Interação até a próxima pintura (INP) em 200 milissegundos ou menos e Mudança cumulativa de posição (CLS) em 0.1 ou menos. LCP acima de 4 segundos, INP acima de 500 milissegundos ou CLS acima de 0.25 é "ruim"; qualquer valor entre os dois limites "precisa melhorar". A ferramenta usa esses limites oficiais exatos.
Por que minhas pontuações de Core Web Vitals diferem das do PageSpeed Insights?
Elas devem coincidir quando consultam a mesma fonte. Esta ferramenta mostra primeiro os dados de campo do Chrome UX Report (CrUX) — o mesmo conjunto de dados de usuários reais usado pela Pesquisa — e só recorre a uma auditoria de laboratório do Lighthouse quando a página não tem dados de campo. Os números de laboratório usam limitação simulada e variam entre execuções, portanto uma pontuação de laboratório não corresponde à de campo. Se o seu número vier do laboratório e o nosso vier dos dados de campo, ou o contrário, essa é a diferença.
Por que o verificador informa "sem dados de campo" para minha URL?
O CrUX só informa uma URL quando ela tem tráfego suficiente do Chrome para formar uma amostra estatisticamente estável nos 28 dias anteriores. Páginas com pouco tráfego ou recém-criadas nunca atingem esse limite. Quando isso acontece, a ferramenta recorre aos dados de campo no nível da origem (o site inteiro) ou a uma auditoria de laboratório simulada do Lighthouse e identifica a fonte usada em cada cartão, para que você nunca confunda números de laboratório com dados de usuários reais.
Esta ferramenta consegue medir o INP?
Ela consegue informar o INP a partir de dados de campo, pois o INP é medido com interações de usuários reais. Não consegue produzir um número de INP em uma auditoria de laboratório — o Lighthouse não tem usuários de verdade para interagir com a página, então um resultado somente de laboratório mostra "sem INP de laboratório" para essa métrica. Se você precisa de um valor de INP e a página não tem dados de campo, precisa de tráfego de usuários (ou das ferramentas de INP do Chrome DevTools aplicadas às suas próprias interações).
Qual dispositivo o Google usa para classificar — celular ou computador?
O Google avalia o sinal de experiência da página em dispositivos móveis, então a ferramenta marca o cartão móvel como "o que o Google usa para classificar" e, quando uma página não passa em ambos os dispositivos, identifica a métrica móvel como a restrição determinante. As pontuações do computador são mostradas como contexto, mas não decidem a avaliação de classificação móvel.
Problemas comuns e como corrigi-los
- Erro LCP está ruim Correção: Reduza o LCP para menos de 2.5 segundos otimizando o elemento LCP medido e seu caminho crítico de entrega; depois confirme com dados de campo recentes.
- Aviso O LCP precisa melhorar Correção: Traga o LCP para menos de 2.5 segundos priorizando o elemento LCP medido e removendo o atraso do caminho de entrega.
- Erro INP está ruim Correção: Reduza o INP para menos de 200 ms encurtando as tarefas de interação mais longas e reduzindo o trabalho de JavaScript no processamento principal.
- Aviso O INP precisa melhorar Correção: Traga o INP para menos de 200 ms dividindo os manipuladores de interação longos e cedendo o processamento principal.
- Erro CLS está ruim Correção: Reduza o CLS para menos de 0.1 reservando espaço para elementos que mudam de posição e evitando trocas tardias de fonte ou conteúdo.
- Aviso O CLS precisa melhorar Correção: Traga o CLS para menos de 0.1 adicionando dimensões estáveis e espaços reservados para elementos que se movem após a primeira pintura.
- Aviso Recursos que bloqueiam a renderização podem atrasar o LCP Correção: Inclua o CSS crítico diretamente no documento e adie folhas de estilo ou códigos não críticos que bloqueiam a renderização do recurso LCP.
- Aviso A resposta do servidor pode atrasar o LCP Correção: Reduza o tempo inicial de resposta do servidor com armazenamento local, processamento mais rápido no servidor e uma CDN próxima dos usuários antes de otimizar o recurso LCP.
- Aviso A entrega da imagem pode atrasar o LCP Correção: Redimensione e compacte a imagem LCP, sirva-a em um formato moderno com srcset e faça o carregamento antecipado quando a descoberta ocorrer tarde.
- Informação A origem crítica não tem preconnect Correção: Adicione preconnect somente à origem crítica de terceiros que serve o recurso LCP, incluindo crossorigin quando necessário.
- Aviso Código de terceiros contribui para o INP Correção: Adie ou atrase gerenciadores de tags não críticos, atendimento, análise e códigos de teste até depois da primeira interação; remova os fornecedores não utilizados.
- Aviso O trabalho do processamento principal contribui para o INP Correção: Divida tarefas longas do processamento principal em partes menores, mova cálculos pesados para um processo auxiliar e reduza o trabalho de posição síncrono.
- Aviso JavaScript não utilizado contribui para o INP Correção: Separe o código por rota e componente para que a página baixe, analise e execute apenas o JavaScript necessário para a visualização atual.
- Aviso Elementos que mudam de posição contribuem para o CLS Correção: Dê dimensões explícitas às imagens, incorporações, anúncios e regiões injetadas informadas, ou reserve espaços antes que sejam carregados.
- Aviso O carregamento de fontes contribui para o CLS Correção: Faça o carregamento antecipado de fontes críticas, use alternativas compatíveis com as métricas e escolha um comportamento de font-display que evite uma troca tardia que altere a posição.
- Aviso O desempenho de laboratório e de campo diverge Correção: Use o rastreamento do Lighthouse para diagnosticar o gargalo da execução simulada e monitore a métrica correspondente do CrUX antes de afirmar ou encerrar uma regressão de usuários reais.