Ferramentas de desempenho web

TL;DR — Há três ferramentas principais para medir a velocidade das páginas, e as pessoas as confundem o tempo todo. O Google Lighthouse executa um único teste em um “laboratório” simulado e dá uma pontuação de 0 a 100. O CrUX reúne dados reais de usuários reais do Chrome — e é a fonte de dados de campo usada nos relatórios de Core Web Vitals. O PageSpeed Insights mostra ambos na mesma tela. A grande lição: sua pontuação de laboratório não é o que o Google usa para ranquear.

Três ferramentas, três funções

Ao começar a medir a velocidade de páginas, você encontrará três nomes repetidamente — Google Lighthouse, PageSpeed Insights e Chrome UX Report (CrUX). A maioria das pessoas acha que são a mesma coisa. Não são. Esta é a forma mais simples de diferenciá-los:

• Google Lighthouse é uma ferramenta de teste. Ele carrega sua página em um celular lento simulado, executa várias verificações e atribui uma pontuação de 0 a 100. É um teste de laboratório — uma máquina, um momento, condições controladas.
• Chrome UX Report (CrUX) reúne dados reais de usuários reais do Chrome que visitam seu site. São dados de campo — e são os dados que o Google usa para ranquear.
• PageSpeed Insights (PSI) é uma página gratuita que mostra ambos: os dados de campo de usuários reais (do CrUX) na parte superior e um teste de laboratório do Lighthouse abaixo.

Laboratório vs. campo — a ideia que você deve lembrar

“Lab” Tradução: “laboratório” significa um teste controlado: um dispositivo, uma configuração de rede, executado sob demanda. “Field” Tradução: “campo” significa pessoas reais em celulares e notebooks reais, em conexões reais, medidas enquanto de fato usam seu site.

Isso importa porque o Google se baseia em dados de campo para ranquear, não na pontuação de laboratório. Você pode obter 100 no Lighthouse e ainda oferecer uma página lenta aos usuários reais — ou ter uma pontuação baixa no laboratório e passar sem problemas para visitantes reais. Quando os dois discordam, os dados de usuários reais (campo) são os que contam para SEO.

Então, qual devo usar?

• “How am I doing for ranking?” Tradução: “Como está meu desempenho para ranqueamento?” → Veja os dados de campo (CrUX), mais fáceis de consultar no PageSpeed Insights ou no Google Search Console.
• “What’s making my page slow?” Tradução: “O que está deixando minha página lenta?” → Execute o Lighthouse (ele lista o que corrigir).
• “I just want one place to see both.” Tradução: “Só quero ver os dois em um único lugar.” → PageSpeed Insights.

Quer o quadro completo — como funcionam as pontuações do Lighthouse, o que significa “p75”, por que tantas páginas não têm dados de campo e o fluxo exato que uso para encontrar e corrigir problemas? Acesse a aba Avançado.

TL;DR — Medir desempenho web se resume a laboratório vs. campo. Lighthouse = laboratório: auditoria simulada (4G lento, CPU 4× mais lenta) que pontua a página de 0 a 100 (Desempenho = TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%). É um diagnóstico, não um sinal de ranqueamento, e não mede INP — usa TBT como proxy. CrUX = campo: usuários reais do Chrome que aceitaram o compartilhamento, no 75º percentil de uma janela móvel de 28 dias — o conjunto de dados de campo por trás dos relatórios públicos de CWV do Google. PageSpeed Insights = ambos em uma interface: dados de campo do CrUX na parte superior (a avaliação CWV Aprovada/Reprovada que importa para SEO) e uma execução de laboratório do Lighthouse abaixo (a pontuação de 0 a 100, que não importa). Use dados de campo para saber sua situação, dados de laboratório para diagnosticar e o Search Console para encontrar grupos de páginas com falha em escala. Apenas cerca de 11,9% das 43,66 milhões de páginas únicas do Site Audit na minha amostra de janeiro de 2022 tinham uma métrica do CrUX; portanto, muitas páginas dessa amostra não tinham dados de campo, e o PSI mostra apenas uma pontuação de laboratório.

A base: dados de laboratório vs. dados de campo

Quase todo mal-entendido sobre essas ferramentas vem de misturar dois tipos de dados. O enquadramento do próprio web.dev é o mais claro: “CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab.” Tradução: “O CrUX é uma coleção de experiências de usuários reais em campo, enquanto o Lighthouse é um teste controlado em laboratório.”

• Dados de laboratório são “collected in a controlled environment with predefined device and network settings.” Tradução: “coletados em um ambiente controlado com configurações predefinidas de dispositivo e rede.” São reproduzíveis, rápidos e ótimos para detectar regressões — mas representam um visitante sintético, não seu público.
• Dados de campo “is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” Tradução: “são determinados monitorando todos os usuários que visitam uma página e medindo um conjunto de métricas de desempenho para a experiência individual de cada um.” São ruidosos, atrasam e representam a realidade.

A orientação de prioridade do Google é explícita: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” Tradução: “Se você tem dados de campo e de laboratório para uma página, use os dados de campo para priorizar seus esforços.” Portanto, a pergunta que todo profissional de SEO deve fazer antes de ler qualquer número é: estou olhando para dados de laboratório ou de campo agora?

Google Lighthouse — o diagnóstico de laboratório

O Lighthouse é “an open-source, automated tool to help you improve the quality of web pages.” Tradução: “uma ferramenta automatizada e de código aberto que ajuda a melhorar a qualidade das páginas web.” Você fornece uma URL, ele “runs a series of audits against the page,” Tradução: “executa uma série de auditorias na página”, e retorna um relatório de Desempenho, Acessibilidade, Boas práticas e SEO. O Lighthouse 12 removeu a antiga categoria PWA — mas, desde o Lighthouse 13.3 (lançado em maio de 2026), há novamente uma quinta categoria: Agentic Browsing, uma auditoria experimental de como a página funciona para agentes de IA (qualidade da árvore de acessibilidade, estabilidade do layout e registro de ferramentas WebMCP). Ela não usa a pontuação ponderada de 0 a 100 das outras quatro — relata verificações aprovadas/reprovadas e uma contagem fracionária de prontidão —, portanto não a inclua no número de Desempenho abaixo.

A pontuação de Desempenho é uma média ponderada de cinco métricas de laboratório (válida no Lighthouse 10 — o Google versiona esses pesos, portanto trate os números exatos como verificáveis, não permanentes):

Faixas de cor: 0–49 vermelho (ruim), 50–89 laranja (precisa melhorar), 90–100 verde (bom). Alguns pontos que as pessoas ignoram:

• Ele aplica limitação deliberadamente — 4G lento e CPU 4× mais lenta —, por isso sua pontuação costuma ser menor do que a experiência ágil na sua máquina rápida.
• Ele não mede INP. Como diz o web.dev, ferramentas “that load pages in a simulated environment without a user cannot measure INP… the Total Blocking Time (TBT) metric is lab-measurable and is a proxy for INP.” Tradução: “que carregam páginas em ambiente simulado sem usuário não conseguem medir INP… a métrica Total Blocking Time (TBT) pode ser medida em laboratório e serve como proxy para INP.” Um TBT perfeito não garante INP aprovado em campo.
• A pontuação varia entre execuções — o Google afirma isso claramente. Execute de 3 a 5 vezes no modo anônimo, sem extensões, e trate o resultado como uma faixa.
• Ela não é um sinal de ranqueamento. Lighthouse é um diagnóstico para encontrar o que corrigir. → Análise detalhada: Google Lighthouse.

Chrome UX Report (CrUX) — o conjunto de dados de usuários reais no qual o Google se baseia para ranquear

O CrUX é “a dataset that reflects how real-world Chrome users experience popular destinations on the web,” Tradução: “um conjunto de dados que reflete como usuários reais do Chrome vivenciam destinos populares na web”, e, crucialmente: “CrUX data is used by Google Search to inform the page experience ranking factor.” Tradução: “Os dados do CrUX são usados pela Pesquisa Google para embasar o fator de ranqueamento de experiência na página.” Esses são os dados por trás do programa Core Web Vitals — os que realmente alimentam o ranqueamento.

O que você precisa saber:

• É exclusivo do Chrome e depende de consentimento. Chrome para desktop e Android de usuários que aceitaram relatórios — sem Chrome no iOS, WebViews, Edge, Safari ou Firefox. Para um público concentrado no Safari, o CrUX pode capturar uma minoria dos usuários reais.
• É uma média móvel de 28 dias no 75º percentil. p75 significa “75% of page loads experienced the given metric at or less than this value.” Tradução: “75% dos carregamentos de página tiveram a métrica indicada nesse valor ou abaixo dele.” Os valores p75 são derivados sinteticamente — “it does not imply that any user actually experienced the value indicated.” Tradução: “isso não significa que algum usuário tenha realmente experimentado o valor indicado.”
• Feedback lento. Com a janela de 28 dias e atraso de cerca de 2 dias, uma correção leva aproximadamente 30 dias para aparecer por completo nos dados de campo.
• Cobertura parcial. No meu estudo de dados de Core Web Vitals da Ahrefs, apenas cerca de 11,9% das 43,66 milhões de páginas analisadas tinham algum dado do CrUX, e cerca de 21,2% das páginas passavam nos Core Web Vitals. As taxas de aprovação por origem são maiores (cerca de 33%), mas dados de origem ocultam páginas individuais com falha — e o Google ranqueia com dados de página.
• Seis formas de acesso: PageSpeed Insights, relatório de CWV do Search Console, API do CrUX, API de histórico do CrUX, BigQuery (somente origem, desde 2017) e CrUX Vis. Observe que o painel do CrUX no Looker Studio foi descontinuado em novembro de 2025 — use CrUX Vis (cruxvis.withgoogle.com). → Análise detalhada: Chrome UX Report (CrUX).

PageSpeed Insights (PSI) — campo + laboratório em um único lugar

O PSI “reports on the user experience of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved.” Tradução: “relata a experiência do usuário de uma página em dispositivos móveis e computadores e oferece sugestões para melhorá-la.” Na prática, são dois conjuntos de dados sob a mesma aparência:

• Parte superior: dados de campo do CrUX. “Real-user experience data in PSI is powered by the Chrome User Experience Report (CrUX) dataset.” Tradução: “Os dados de experiência de usuários reais no PSI vêm do conjunto de dados Chrome User Experience Report (CrUX).” Isso define a avaliação de Core Web Vitals — Aprovada ou Reprovada no p75 de LCP, INP e CLS: “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals.” Tradução: “Para passar, o percentil precisa ser classificado como ‘bom’ nos três Core Web Vitals.” Se a URL exata não tiver dados, o sistema recorre ao nível da origem e depois a “No data” Tradução: “Sem dados”.
• Parte inferior: execução de laboratório do Lighthouse. “PSI uses Lighthouse to analyze the given URL in a simulated environment.” Tradução: “O PSI usa o Lighthouse para analisar a URL fornecida em um ambiente simulado.” Essa é a pontuação de Desempenho de 0 a 100 e os diagnósticos.

O ponto crítico de SEO: a pontuação de 0 a 100 é dado de laboratório e NÃO entra no ranqueamento. Somente a avaliação de CWV de campo (a seção do CrUX) reflete o que o Google usa para ranquear. O PSI funciona com qualquer URL pública (portanto você pode verificar concorrentes), mas apenas URLs públicas — “It cannot be used on development sites that are not publicly accessible.” Tradução: “Ele não pode ser usado em sites de desenvolvimento que não são publicamente acessíveis.” Para esses casos, execute o Lighthouse no DevTools. → Análise detalhada: PageSpeed Insights (PSI).

Como escolher a ferramenta certa

A decisão se resume a algumas perguntas:

Duas regras por trás da tabela: campo para avaliação, laboratório para diagnóstico — e site inteiro no Search Console, URLs individuais no PSI. Se uma página não tiver dados do CrUX, você não poderá avaliar seus CWV de campo pelo PSI; restará uma pontuação de laboratório, que não diz nada sobre o sinal de ranqueamento.

Além das três: DevTools, grupos do Search Console, RUM e monitoramento sintético

Lighthouse, PSI e CrUX cobrem a maior parte das necessidades diárias de um profissional de SEO, mas chamá-las de “the three tools” Tradução: “as três ferramentas” subestima o restante do conjunto:

• Métricas ao vivo e trace de desempenho do Chrome DevTools. Abra uma página no painel Performance do DevTools; LCP, CLS e INP serão atualizados conforme você interage com a página. Grave um trace para encontrar o script ou recurso exato que causa o atraso. Como há uma interação real, ele pode capturar INP — ao contrário do carregamento de laboratório sem interação do Lighthouse.
• O relatório de Core Web Vitals do Search Console agrupa URLs semelhantes; ele não rastreia uma página isolada. É uma superfície de triagem para todo o site, útil para encontrar templates ou padrões de URL com falha em escala; abra um grupo e leve uma URL representativa ao PSI ou DevTools para diagnosticar.
• Monitoramento sintético repete a mesma verificação automatizada em um cronograma, a partir de locais e perfis de dispositivo escolhidos, muitas vezes integrado à CI — assim uma regressão é detectada antes do lançamento, e não cerca de 30 dias depois no CrUX. É repetível e controlado, mas observa apenas os cenários configurados, não seu tráfego real.
• RUM privado (Real User Monitoring) instrumenta seu site para registrar a experiência real de cada visitante — não apenas a população elegível do Chrome que aceitou participar do CrUX — e pode segmentar por contexto de negócio (usuários conectados, checkout, receita), algo que o CrUX não faz. Isso também significa que pode discordar legitimamente do CrUX: cobertura de navegadores, regras de consentimento, amostragem e janelas de agregação diferentes. Você assume as concessões de configuração, privacidade/consentimento e custo.

Nada disso muda a base: dados de campo (CrUX ou seu próprio RUM) mostram sua situação; ferramentas de laboratório, trace e sintéticas explicam o motivo. E, se você realmente quer uma lista ranqueada de produtos, não um mapa de tarefas — há muitas listas de “best web performance tools” Tradução: “melhores ferramentas de desempenho web” —, geralmente é mais rápido testar sua URL em uma ferramenta pública primeiro, pois a lista ranqueia fornecedores, não sua página.

O fluxo que realmente uso

1. Google Search Console → relatório de Core Web Vitals. Encontre grupos de páginas com falha em escala no site.
2. PageSpeed Insights. Confirme no nível da página — leia o veredito da avaliação de CWV de campo para uma URL representativa.
3. Seção de laboratório do PSI/Lighthouse/Chrome DevTools. Diagnostique a causa-raiz e itere sobre a correção com feedback rápido de laboratório.
4. Espere cerca de 30 dias. Os dados de campo são atualizados conforme a janela de 28 dias + atraso.
5. Verifique novamente o campo no PSI + Search Console para confirmar a melhora dos usuários reais.

Dados de laboratório são seu ciclo rápido de feedback após uma alteração; dados de campo são a confirmação lenta e confiável.

Como os rankings de CWV realmente funcionam (resumo)

O Google documenta Core Web Vitals como algo usado por seus sistemas de ranqueamento e o CrUX como o conjunto de dados por trás dos relatórios públicos de CWV no PSI, Search Console e API do CrUX — isso está bem estabelecido, não as pontuações de laboratório. O que não é documentado publicamente é um mapeamento direto entre o número exato exibido por uma superfície pública do CrUX e o valor interno literal que os sistemas de ranqueamento do Google leem para a página — trate o número público como o melhor proxy disponível do sinal, não como uma leitura verificada dele. De todo modo, é um sinal real, mas modesto. John Mueller o chamou de “more than a tie-breaker, but it also doesn’t replace relevance,” Tradução: “mais do que um critério de desempate, mas também não substitui a relevância”, e, na época da atualização da documentação de 2024, disse “it’s not going to make your site’s rankings jump up.” Tradução: “isso não fará os rankings do seu site dispararem.” A própria documentação de experiência na página do Google agora diz “trying to get a perfect score just for SEO reasons may not be the best use of your time.” Tradução: “tentar obter uma pontuação perfeita apenas por motivos de SEO talvez não seja o melhor uso do seu tempo.” Para o tratamento completo — limites, as três métricas e o peso a atribuir — consulte o hub de Core Web Vitals.

Uma observação sobre o Bing

O Bing não publicou documentação que posicione essas ferramentas de desempenho como fatores de ranqueamento da mesma forma que o Google; Core Web Vitals é principalmente uma iniciativa do Google. O Bing Webmaster Tools exibe uma visão geral de Core Web Vitals, e melhorias subjacentes de UX/velocidade beneficiam todos os mecanismos de busca — mas o conjunto de ferramentas desta página é do Google.

Próximos passos

Este hub é o mapa; cada ferramenta tem sua própria análise detalhada agrupada sob ele:

• Google Lighthouse — mecanismo de auditoria de laboratório: as quatro categorias, como é construída a pontuação ponderada de Desempenho de 0 a 100, por que aplica limitação e varia e por que é um diagnóstico, não uma entrada de ranqueamento.
• PageSpeed Insights (PSI) — ferramenta de dois conjuntos de dados em uma interface: a seção de campo do CrUX vs. a seção de laboratório do Lighthouse, avaliação de CWV Aprovada/Reprovada, fallback de dados e API do PSI para testes em lote.
• Chrome UX Report (CrUX) — conjunto de dados de campo de usuários reais: cobertura do Chrome por consentimento, janela de 28 dias no p75, dados de origem vs. URL, por que páginas mostram “No data” Tradução: “Sem dados” e as seis formas de acesso (incluindo CrUX Vis após a descontinuação do Dashboard).

Para as métricas medidas por essas ferramentas — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, além de Total Blocking Time e Speed Index — e os limites usados pelo Google, comece pelo hub de Core Web Vitals.

Resumo por IA

Uma versão condensada da seção Avançado:

• Três ferramentas, dois tipos de dados. Lighthouse = laboratório; CrUX = campo; PageSpeed Insights = ambos em uma interface. A primeira pergunta para qualquer número: laboratório ou campo?
• O Google se baseia em dados de campo (CrUX) para ranquear, não em pontuações de laboratório. Dados de campo orientam prioridades; dados de laboratório servem para depuração.
• Lighthouse é uma auditoria simulada (4G lento, CPU 4× mais lenta) que pontua de 0 a 100 — Desempenho (pesos do Lighthouse 10, versionados e verificáveis, não permanentes) = TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Faixas: 0–49 vermelho/50–89 laranja/90–100 verde. Ele não mede INP (usa TBT como proxy), varia entre execuções e não é um sinal de ranqueamento. Desde o Lighthouse 13.3 (maio de 2026), há uma quinta categoria experimental, Agentic Browsing — verificações de aprovação/reprovação para prontidão de agentes de IA, separadas da pontuação de 0 a 100.
• CrUX = usuários do Chrome que aceitaram participar (sem Chrome no iOS, Edge, Safari ou Firefox) no p75 de uma janela móvel de 28 dias; o conjunto de dados no qual a Pesquisa Google se baseia para ranquear. Uma correção leva cerca de 30 dias para aparecer. Na minha amostra da Ahrefs de janeiro de 2022, apenas cerca de 11,9% das 43,66 milhões de páginas únicas do Site Audit tinham uma métrica do CrUX; cerca de 21,2% das páginas medidas passavam nos CWV. O painel do CrUX no Looker Studio foi descontinuado em nov. de 2025 → use CrUX Vis.
• PageSpeed Insights mostra dados de campo do CrUX em cima (a avaliação de CWV Aprovada/Reprovada que importa para SEO) e uma execução de laboratório do Lighthouse abaixo (a pontuação de 0 a 100, que NÃO é fator de ranqueamento). Apenas URLs públicas; funciona para concorrentes.
• Regras de decisão: campo para avaliação, laboratório para diagnóstico; site inteiro → Search Console, URLs individuais → PSI; páginas protegidas por login → Lighthouse no DevTools.
• Além das três: métricas ao vivo/trace do DevTools podem capturar um INP real durante a interação; o Search Console agrupa URLs semelhantes em vez de rastrear uma página; monitoramento sintético repete verificações em cronograma/CI; RUM privado cobre toda sua população de visitantes (e pode discordar legitimamente do CrUX). Uma lista ranqueada de “best tools” Tradução: “melhores ferramentas” responde a uma pergunta diferente deste hub — teste sua URL em uma ferramenta pública primeiro.
• Ressalva de ranqueamento: o Google documenta CWV como entrada dos sistemas de ranqueamento e CrUX como o conjunto por trás dos relatórios públicos de CWV — confirmado. Não há prova pública de que o número exato de uma superfície pública do CrUX seja o valor interno literal por página lido pelos sistemas; trate-o como o melhor proxy público, não uma leitura verificada.
• Fluxo: GSC (encontrar grupos com falha) → PSI (confirmar no nível da página) → Lighthouse/DevTools (diagnosticar + corrigir) → esperar cerca de 30 dias → verificar o campo novamente.

Documentação oficial

Documentação de fontes primárias do Google (e uma observação sobre o Bing).

Google — as ferramentas

• Visão geral do Lighthouse — o que é, o que audita e onde executá-lo.
• Pontuação de desempenho do Lighthouse — pesos das métricas, faixas de pontuação e por que a pontuação varia.
• Pontuação de navegação agêntica do Lighthouse — quinta categoria experimental (lançada no Lighthouse 13.3, maio de 2026): verificações de prontidão de agentes aprovadas/reprovadas, separadas da pontuação de 0 a 100.
• Referência do painel Performance do Chrome DevTools — métricas ao vivo e traces gravados para medição local baseada em interação (incluindo INP).
• PageSpeed Insights — Sobre — o PSI combina dados de laboratório do Lighthouse e dados de campo do CrUX; faixas de pontuação.
• Como usar CrUX no PageSpeed Insights — como funciona a seção de campo e a avaliação Aprovada/Reprovada.
• Visão geral do Chrome UX Report (CrUX) — o conjunto de dados, seu papel nos CWV e as formas de acesso.
• Metodologia do CrUX — quem é elegível e quais plataformas são incluídas.
• API do CrUX — média móvel de 28 dias e definição de p75.
• CrUX Vis — ferramenta visual de tendências que substituiu o Dashboard descontinuado.

Google — laboratório vs. campo e ranqueamento

• Diferenças entre dados de laboratório e de campo — Philip Walton explica cada tipo e qual priorizar.
• Ferramentas de Core Web Vitals (web.dev) — visão geral do próprio Google sobre as ferramentas.
• Entenda Core Web Vitals e resultados da Pesquisa Google — como CWV se alinha aos sistemas de ranqueamento.
• Entenda a experiência na página na Pesquisa Google — o enquadramento “perfect score… may not be the best use of your time” Tradução: “uma pontuação perfeita… talvez não seja o melhor uso do seu tempo”.

Bing/Microsoft

• O Bing não publicou orientação que posicione essas ferramentas de desempenho como fatores de ranqueamento; o Bing Webmaster Tools exibe uma visão geral de Core Web Vitals, mas CWV continua sendo principalmente uma iniciativa do Google. Consulte a ajuda do Bing Webmaster Tools para sua orientação geral.

Citações das fontes

Declarações públicas do Google. Cada link leva diretamente ao trecho citado na página de origem.

Google — o que é cada ferramenta

• “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” Tradução: “O Lighthouse é uma ferramenta automatizada e de código aberto que ajuda a melhorar a qualidade das páginas web.” — Documentação do Chrome for Developers. Ir para a citação
• “PageSpeed Insights (PSI) reports on the user experience of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved.” Tradução: “O PageSpeed Insights (PSI) relata a experiência do usuário de uma página em dispositivos móveis e computadores e oferece sugestões para melhorá-la.” Ir para a citação
• “The Chrome User Experience Report… is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” Tradução: “O Chrome User Experience Report… é um conjunto de dados que reflete como usuários reais do Chrome vivenciam destinos populares na web.” Ir para a citação

Google — laboratório vs. campo e em qual o Google se baseia para ranquear

• “Real-user experience data in PSI is powered by the Chrome User Experience Report (CrUX) dataset.” Tradução: “Os dados de experiência de usuários reais no PSI vêm do conjunto de dados Chrome User Experience Report (CrUX).” Ir para a citação
• “CrUX data is used by Google Search to inform the page experience ranking factor.” Tradução: “Os dados do CrUX são usados pela Pesquisa Google para embasar o fator de ranqueamento de experiência na página.” Ir para a citação
• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” Tradução: “Se você tem dados de campo e de laboratório para uma página, use os dados de campo para priorizar seus esforços.” — Philip Walton, web.dev. Ir para a citação
• “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” Tradução: “Os dados no Chrome UX Report são uma média móvel de 28 dias de métricas agregadas.” Ir para a citação
• “trying to get a perfect score just for SEO reasons may not be the best use of your time.” Tradução: “tentar obter uma pontuação perfeita apenas por motivos de SEO talvez não seja o melhor uso do seu tempo.” — Google Search Central, documentação sobre experiência na página. Ir para a citação

John Mueller, Google (por meio de cobertura secundária)

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” Tradução: “É um fator de ranqueamento e mais do que um critério de desempate, mas também não substitui a relevância.” Sobre Core Web Vitals como sinal de ranqueamento. Leia a cobertura
• “it’s not going to make your site’s rankings jump up.” Tradução: “isso não fará os rankings do seu site dispararem.” Na época da atualização da documentação de experiência na página de março de 2024. Leia a cobertura

Ferramentas de desempenho web — referência rápida

Resumo das três ferramentas

Fatos rápidos

• O Google se baseia em dados de campo (CrUX) para ranquear, não na pontuação de laboratório. O número de 0 a 100 do PSI não entra no ranqueamento.
• Pesos de Desempenho do Lighthouse (Lighthouse 10, versionados — confira antes de citar): TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Faixas: 0–49 vermelho/50–89 laranja/ 90–100 verde. O Lighthouse 13.3+ (maio de 2026) acrescenta uma quinta categoria experimental, Agentic Browsing (aprovação/reprovação, fora da pontuação de 0 a 100).
• O Lighthouse não mede INP — usa TBT como proxy. A tela de métricas ao vivo do DevTools pode observar um INP real, pois você gera a interação.
• O CrUX é exclusivo do Chrome e depende de consentimento (sem Chrome no iOS, Edge, Safari ou Firefox), p75, janela de 28 dias, atraso de cerca de 2 dias → uma correção leva aproximadamente 30 dias para aparecer.
• Apenas cerca de 11,9% das 43,66 milhões de páginas únicas do Site Audit na minha amostra de janeiro de 2022 tinham uma métrica do CrUX; cerca de 21,2% das páginas medidas passavam nos CWV (meu estudo de dados de CWV da Ahrefs).
• Painel do CrUX descontinuado em nov. de 2025 → use CrUX Vis (cruxvis.withgoogle.com).
• Campo para avaliação, laboratório para diagnóstico. Site inteiro → Search Console; URLs individuais → PSI; páginas protegidas por login → Lighthouse no DevTools.

Erros na medição de desempenho web

Relatar a pontuação do Lighthouse como entrada de ranqueamento do Google

Lighthouse é um diagnóstico de laboratório. O Google usa dados de campo do CrUX na avaliação de Core Web Vitals, portanto rotule a pontuação corretamente.

Usar dados de campo para diagnosticar uma linha de código

O CrUX mostra que usuários reais têm um problema, mas não a causa exata na implementação. Reproduza a jornada afetada no DevTools ou Lighthouse depois de encontrar o segmento de campo fraco.

Comparar condições de teste diferentes

Uma execução aquecida no desktop e uma execução fria em celular limitado respondem a perguntas diferentes. Mantenha ferramenta, local, perfil de dispositivo, estado do cache e jornada consistentes nas comparações antes/depois.

Otimizar o agregado e ignorar grupos de páginas

Uma aprovação no nível da origem pode ocultar um template lento, e uma reprovação no nível da origem pode ocultar páginas saudáveis. Comece de forma ampla e depois segmente por padrão de URL e experiência.

Resolva divergências comuns entre ferramentas

PageSpeed Insights mostra dados de campo da origem, não da URL

Causa provável: a URL não tem dados elegíveis suficientes no CrUX. Correção: leia o rótulo de escopo e use os dados da origem apenas como contexto; depois acrescente RUM ou grupos do Search Console às decisões por página. Confirmação: o relatório identifica claramente o escopo representado por cada valor.

Lighthouse muda a cada execução

Causa provável: resultados de laboratório variam conforme rede, CPU, cache, resposta do servidor e atividade de terceiros. Correção: padronize as condições e compare várias execuções, não uma única pontuação. Confirmação: a mesma oportunidade persiste no conjunto de execuções.

Search Console está ruim enquanto um teste local está bom

Causa provável: o laboratório local não representa dispositivos, locais ou jornadas mais longas de usuários reais. Correção: use o relatório de campo para identificar o grupo afetado e reproduza esse cenário em uma ferramenta de diagnóstico. Confirmação: o trace de laboratório explica o gargalo do segmento de campo.

Uma correção aparece no Lighthouse, mas não no CrUX

Causa provável: o Lighthouse é imediato, enquanto o CrUX usa uma janela móvel de campo. Correção: valide primeiro com execuções controladas de laboratório e seu próprio RUM; depois aguarde a atualização da janela pública de campo. Confirmação: o RUM melhora antes de a tendência do CrUX acompanhar.

Teste seus conhecimentos: ferramentas de desempenho web

Cinco perguntas rápidas sobre as três ferramentas e dados de laboratório vs. campo. Escolha uma resposta para cada uma e depois confira.

Registro de alterações