Velocidade do site: o que o Google mede

Digite “velocidade do site” no Google. A primeira página é quase toda de ferramentas de teste. PageSpeed Insights, Pingdom, GTmetrix e outros pedem um endereço e devolvem um número. ¹

Na mesma página aparecem o Fast.com e o Speedtest. Os dois medem a conexão de internet de quem faz o teste. ¹ ² Por isso, um recorte antes de seguir. Aqui, velocidade é a da página que o visitante abre.

A Visão geral criada por IA da mesma busca resume o que quase todo mundo procura. Segundo ela, o PageSpeed Insights mostra notas de 0 a 100 e aponta as falhas. ¹

Fiz esse teste na página inicial do seogenome.com em 14 de setembro de 2026. No celular, a nota de desempenho foi 98. ³ Na mesma tela, um bloco acima, os visitantes reais do site contavam outra história. No teste, o maior elemento da página aparecia em 1,4 segundo. Nas visitas reais, a referência era 2,4 segundos. ³

Os dois números estão certos. Eles medem coisas diferentes, e este texto mostra quais. Depois vêm o que o Google diz sobre velocidade e classificação, o que o Search Console agrupa e o que costuma deixar um site lento. Tudo com a documentação aberta, conferida em 14 de setembro de 2026.

O que o visitante sente

Pense na entrada de uma loja. Você passa pela porta e fica um tempo no escuro até a luz acender. Pede ajuda no balcão e o atendente demora a levantar a cabeça. Quando vai pegar a peça na vitrine, alguém muda a vitrine de lugar.

Nenhuma das três esperas cabe numa nota só. Todas pesam na paciência de quem entrou. O Google junta essas sensações a outras, como conexão segura, boa exibição no celular e ausência de anúncios que atrapalham. Isso se chama experiência de página. ⁴

As três esperas da loja têm métricas próprias, medidas com dados de visitantes reais. Uma olha o carregamento, outra a resposta ao toque, a última a estabilidade da tela. O trio se chama Core Web Vitals. ⁵ Os nomes, os limites e o conserto de cada uma estão no texto sobre Core Web Vitals. Aqui o assunto é a velocidade inteira.

O que o Google diz sobre velocidade e classificação

O Google trata velocidade como sinal de classificação desde abril de 2010. O anúncio daquele ano já vinha com ressalvas. O sinal novo pesava menos que a relevância da página. ⁶ Afetava menos de 1% das buscas, e só as feitas em inglês no Google.com. ⁶

Em janeiro de 2018, veio a vez do celular. O Google anunciou a velocidade como fator nas buscas móveis, a partir de julho daquele ano. ⁷ A mudança atingiria só as páginas mais lentas e uma pequena parte das buscas. ⁷ E o texto repetia a ressalva de 2010. Uma página lenta ainda pode ficar bem colocada, se tiver conteúdo ótimo e relevante. ⁷

A página atual sobre experiência de página foi atualizada em dezembro de 2025. Ela diz que não existe um sinal único. Os sistemas centrais de classificação olham vários sinais alinhados à experiência. ⁴ As Core Web Vitals estão entre eles. ⁴

Os outros aspectos da experiência, segundo o mesmo texto, não ajudam diretamente a subir. Eles deixam o site mais agradável de usar, e isso anda junto com o que os sistemas querem premiar. ⁴ A avaliação costuma ser feita página a página, com algumas avaliações do site inteiro. ⁴

Pense em duas farmácias na mesma rua. Se só uma tem o remédio, você enfrenta a fila dela. Se as duas têm, você entra na que atende primeiro.

A documentação escreve a mesma ordem. O Google busca mostrar o conteúdo mais relevante, mesmo com experiência de página abaixo do ideal. ⁴ Quando existe muito conteúdo útil para a mesma busca, a boa experiência pode contribuir para o sucesso. ⁴

O mesmo texto avisa sobre a nota. Resultado bom no relatório do Search Console ou em ferramenta de terceiros não garante o topo. E perseguir a nota perfeita só por SEO pode não ser o melhor uso do seu tempo. ⁴

Falta saber de onde vem o dado que conta. A página do relatório de experiência do usuário do Chrome responde. Os dados dele informam o fator de experiência de página da Busca. ⁸ E são dados de usuários reais do Chrome. ⁸ Guarde esse detalhe para a próxima seção.

Laboratório e campo: por que as ferramentas discordam

Pense no consumo de combustível que vem na etiqueta do carro novo. Ele sai de um teste padronizado, com o mesmo trajeto para todos os modelos. Serve para comparar um carro com o outro. O consumo no trânsito da sua cidade é outro número, e é esse que pesa no bolso.

Na velocidade do site, o teste padronizado se chama dado de laboratório. O trânsito da cidade se chama dado de campo.

O dado de laboratório sai de uma página carregada em ambiente controlado, com aparelho e rede definidos antes. ⁹ O web.dev resume os limites do teste em três: um aparelho, uma rede, um lugar. ⁹ As ferramentas do Chrome que fazem esse teste costumam rodar o Lighthouse. ⁹ Ele é de código aberto e roda no próprio Chrome, pelo painel de desenvolvedor, em qualquer página. ¹⁰

O dado de campo vem das visitas reais, com os aparelhos, as redes e os lugares de quem visita. ⁹ No Chrome, a fonte é o relatório de experiência do usuário, conhecido pela sigla CrUX. ⁸ ⁹ Ele guarda uma distribuição de 28 dias. Nela cabem visitas rápidas e visitas lentas. ⁹

Quando uma ferramenta mostra um número só para o campo, ele é o percentil 75. ⁹ Em linguagem de gente: três de cada quatro visitas foram iguais ou melhores que aquele valor. O PageSpeed explica a escolha. A ideia é que a página funcione bem para a maioria, inclusive nas piores condições de aparelho e rede. ¹¹

O web.dev lista os motivos da discordância. ⁹ O teste costuma chegar com o navegador vazio, sem nada guardado de visita anterior. Na vida real, quem volta já tem parte da página no aparelho. O teste também não rola a tela nem toca em nada. A pessoa real rola, toca e seleciona texto. ⁹ E a tela do aparelho simulado pode mostrar outro elemento no topo. ⁹

A regra de prioridade também está escrita. Com os dois dados da mesma página na mão, o de campo decide por onde começar, porque mostra o que as pessoas vivem. ⁹ O de laboratório serve para achar a causa e testar a correção antes de publicar. ⁹ E existe um lembrete que quase ninguém lê. O campo só registra quem conseguiu carregar a página. ⁹

O PageSpeed Insights junta os dois na mesma tela. Em cima, os visitantes reais do CrUX, nos últimos 28 dias. Embaixo, o diagnóstico do Lighthouse, num carregamento simulado. ¹¹ A ajuda da ferramenta avisa que nota boa no laboratório não garante boa experiência para os visitantes reais. ¹¹

Quando a página não tem visitas suficientes, a ferramenta mostra o site inteiro no lugar dela. Às vezes nem o site tem dado, e a parte de cima fica vazia. ¹¹

O caso da casa: o 98 e o 2,4

Volte ao teste da abertura. Rodei o PageSpeed Insights na página inicial do seogenome.com às 5h59 de 14 de setembro de 2026, no formato celular. ³

O laboratório simulou um Moto G Power numa rede 4G lenta, com o navegador na América do Norte. ³ A nota de desempenho foi 98. O primeiro conteúdo apareceu em 1,0 segundo, e o maior elemento em 1,4. A lista de recursos de terceiros veio vazia. ³

A parte de cima avisou que a página inicial, sozinha, não tinha visitas suficientes. Mostrou então o site inteiro. ³ O período ia de 15 de agosto a 11 de setembro. Três de cada quatro visitas viram o maior elemento em até 2,4 segundos. Uma em cada dez esperou mais de 4 segundos. ³ A resposta do servidor chegou em até 0,8 segundo para três de cada quatro visitas. ³

A diferença tem três explicações, e as três estão documentadas.

A janela. O site novo entrou no ar em 2 de setembro, no lugar do WordPress antigo, no mesmo endereço. ¹² Dos 28 dias medidos, 18 ainda eram do site velho. O dado de campo carrega o passado por quase um mês.

O aparelho e o lugar. O laboratório simula um celular numa rede definida, rodando longe do Brasil. ³ O campo é o celular real de quem visitou, na rede que essa pessoa tinha. ⁹

O consentimento. No site novo, a medição de audiência só liga depois que o visitante aceita os cookies. Antes do aceite, nenhuma requisição sai para terceiros. ¹² O teste não toca em nada, e por isso a lista de terceiros veio vazia. ³ ⁹ Quem clica em aceitar recebe mais scripts do que o robô recebeu. ¹²

O registro interno de 2 de setembro já trazia essa ressalva. O Lighthouse tinha dado nota máxima nas cinco rotas medidas, no celular e no computador. ¹² A anotação da equipe avisava que o site medido estava sem o Google Analytics. A nota, portanto, não media o impacto dele. ¹²

Nenhum dos dois números mente. O 98 mostra a página como o robô a recebeu. O 2,4 mostra o que os visitantes viveram, somando o site velho e o novo. Para julgar só o site novo, a janela precisa encher de visitas dele. Pela conta das datas, isso acontece no fim de setembro.

O relatório de Core Web Vitals do Search Console

Pense numa escola que manda para casa o boletim da turma inteira. A nota de cada aluno fica diluída no grupo. Se a turma vai mal, todo mundo recebe o mesmo aviso.

O relatório de Core Web Vitals do Search Console trabalha assim. Ele junta páginas com experiência parecida, que o Google presume dividirem a mesma estrutura. E dá um status ao grupo inteiro. ¹³ Isso se chama grupo de URLs.

O dado vem do CrUX, de visitantes reais. ¹³ O status do grupo é o da pior métrica, e vale o que 75% das visitas tiveram nos últimos 28 dias. ¹³ Na versão em português, os rótulos são Ruim, Melhorias necessárias e Bom, separados para celular e computador. ¹³

Algumas regras mudam a leitura. Só entram páginas indexadas, e a lista é uma amostra. ¹³ O dado fica preso ao endereço visitado. Nos outros relatórios, costuma ficar no canônico. ¹³ Grupo sem visitas suficientes vira grupo da origem, com o site inteiro. Sem dado nem na origem, aparece a tela sem dados. ¹³

O relatório também mistura todos os lugares. Se boa parte das visitas vem de um país com internet lenta, o desempenho geral cai. ¹³

Daí vem outra discordância. O PageSpeed mostra a página, e o relatório mostra o grupo. Uma página pode ser a exceção do grupo dela. ¹³ O PageSpeed ainda tira os parâmetros do endereço antes de mostrar o dado. ¹³

Status que muda sem você mexer em nada também tem explicação na ajuda. Muitas páginas estavam no limite, e um evento no site inteiro empurrou todas. Um pico de tráfego ou um servidor de imagens mais lento bastam. ¹³

Depois de corrigir, o botão de validação abre um acompanhamento de 28 dias. Ele não pede nova indexação. Só reinicia o relógio da medição. ¹³ A ordem de correção, com Ruim primeiro e depois as páginas que mais importam, está no exame 3 da auditoria de SEO.

O que costuma deixar um site lento

O resumo de IA da busca lista dicas soltas: imagem, código e hospedagem. ¹ A documentação do Chrome mostra onde o tempo costuma ir embora. Quatro suspeitos aparecem em quase todo diagnóstico.

A imagem do topo

O cartaz da vitrine é a primeira coisa grande que o visitante vê. Em 73% das páginas de celular, o maior elemento do carregamento é uma imagem, pelo Web Almanac de 2024 citado no web.dev. ¹⁴

Aqui é onde quase ninguém entendeu. Na maioria dos sites com carregamento ruim, baixar essa imagem ocupa menos de 10% do tempo. ¹⁴ Nessas páginas, a imagem principal espera 1,29 segundo para começar a baixar, no percentil 75. ¹⁴ Boa parte da espera vem de o navegador descobrir a imagem tarde. Em 35% das páginas cuja maior peça é uma imagem, o endereço dela nem estava no HTML inicial. ¹⁴

O web.dev aponta duas causas comuns. Esconder a imagem atrás de script, e mandar a imagem do topo carregar só quando aparecer na tela, com o atributo loading="lazy". ¹⁴ A mesma página registra que 66% das páginas têm pelo menos uma imagem sem largura e altura declaradas. Sem essas medidas, o espaço nasce com altura zero, e o texto pula quando a imagem chega. ¹⁴

Para quem não é técnico, a ajuda do Search Console dá duas réguas. A página inteira, com tudo o que ela puxa, abaixo de 500 KB. E no máximo 50 recursos por página no celular. ¹³

As fontes

Ninguém leva a caixa de ferramentas inteira para trocar um parafuso. As fontes do site fazem isso quando trazem todos os pesos e caracteres, e a página usa uma fração deles.

Fonte também é arquivo, e o navegador costuma atrasar o texto até ela chegar. Quando ela chega ocupando outro espaço, a página pula. ¹⁵ O web.dev faz um alerta para quem hospeda as próprias fontes. Os provedores costumam cortar os caracteres que a página não usa. Quem copia o arquivo para o próprio servidor pode perder esse corte e servir um arquivo maior. ¹⁵ Isso se chama subconjunto de fonte.

Foi o nosso caso. O primeiro diagnóstico do site novo apontava as imagens de algumas páginas. O peso maior estava nas fontes, cobrado em toda página: 50,3 KB de peso morto. ¹² Os arquivos traziam o eixo de peso inteiro, de 100 a 900, e o site pedia de 400 a 600. ¹²

Com o subconjunto, a fonte principal caiu de 48 para 20,8 KB. ¹² No conjunto das correções daquele dia, a página inicial foi de 150 para 94 KB. No teste de laboratório registrado, o maior elemento no celular passou de 1,95 para 1,50 segundo. ¹²

Os scripts de terceiros

Imagine uma loja que deixa cinco fornecedores montarem estandes na entrada. Cada um traz a própria equipe e o próprio barulho. O cliente passa por todos antes de chegar ao balcão.

Script de terceiro é o código que outra empresa coloca no seu site. Botão de rede social, vídeo incorporado, anúncio, medição de audiência e teste A/B entram na lista do web.dev. ¹⁶ O artigo abre sem rodeio. Se você já otimizou o seu código e o site continua lento, a culpa provavelmente é deles. ¹⁶

Muitos desses scripts entram por um gerenciador de tags. O artigo do web.dev sobre o assunto registra uma correlação entre gerenciadores maiores e pior tempo de resposta ao toque. ¹⁷ Uma tag sozinha pode pesar pouco. Dezenas ou centenas na mesma página pesam muito. ¹⁷ O mesmo texto desaconselha carregar pelo gerenciador o aviso de cookies e a imagem principal. ¹⁷

A hospedagem

No restaurante, nenhum prato começa antes de a cozinha confirmar o pedido. Na página, a confirmação é a primeira resposta do servidor. Isso se chama tempo até o primeiro byte, ou TTFB na sigla em inglês. ¹⁸

Ele vem antes de tudo o que o visitante vê, e cada atraso nele empurra o resto. ¹⁸ Não é uma das Core Web Vitals, e o web.dev trata os limites dele como guia aproximado. ¹⁸

A seção do web.dev sobre servidor tem título com a mesma palavra três vezes: hospedagem. ¹⁸ Antes de qualquer outro ajuste, a recomendação é conferir se o servidor aguenta o tráfego que recebe. Hospedagem compartilhada costuma ser mais lenta. Para um site pequeno de arquivos estáticos, o próprio texto diz que provavelmente serve. ¹⁸

No WordPress, o mesmo artigo aponta a quantidade e a qualidade dos plugins e o tema escolhido. ¹⁸ O que o WordPress faz sozinho e o que o plugin acrescenta está no texto de SEO para WordPress. Outras duas contas pesam no primeiro byte. Cada redirecionamento no caminho soma espera. ¹⁸ E servidor longe de quem visita também. A rede de distribuição de conteúdo, a CDN, guarda cópias perto do visitante. ¹⁴ ¹⁸

O servidor lento cobra também do robô do Google. O guia de rastreamento diz que o limite de rastreamento cai quando o site fica lento ou responde com erro. Aí o Google rastreia menos. ¹⁹ O guia foi escrito para sites muito grandes. A leitura dessa tela num site real está em rastreamento e orçamento de rastreamento.

A conferência de uma manhã

Separe a página que mais recebe visitas vindas do Google.

Abra o PageSpeed Insights no formato celular. Leia primeiro a parte de cima. Anote se o dado é da página ou do site inteiro, e o período. ¹¹
Leia o laboratório como diagnóstico. Use a nota para comparar a página com ela mesma, antes e depois de mexer. ⁹ ¹¹
Confira o que mudou na janela. Troca de plataforma, tema novo ou migração nos últimos 28 dias misturam dois sites no mesmo número. ⁹
Abra o relatório de Core Web Vitals, versão celular. Anote os grupos em Ruim e o endereço de exemplo de cada um. ¹³
Pese a página. Compare com as duas réguas da ajuda: 500 KB e 50 recursos. ¹³
Liste os scripts de terceiros. Para cada um, pergunte quem na empresa usa aquele botão ou aquele dado. ¹⁶
Olhe a imagem do topo e as fontes. A imagem precisa estar no HTML, sem carregamento adiado. As fontes, só com os pesos e caracteres em uso. ¹⁴ ¹⁵
Corrigiu? Valide. O acompanhamento do Search Console leva 28 dias. ¹³

O resto do território técnico, da indexação aos dados estruturados, está em SEO técnico.

A partir de agora, quando alguém mostrar uma nota de velocidade, você vai perguntar duas coisas. Se o número é de laboratório ou de visitantes reais. E de qual período ele é.

A primeira resposta diz se aquilo é diagnóstico ou experiência. A segunda diz de qual site o número está falando.

Abra hoje o PageSpeed Insights, cole o endereço da sua página mais visitada e leia primeiro a parte de cima.

Perguntas frequentes

A velocidade do site influencia a posição no Google?

Influencia, dentro de limites que o Google escreveu. As Core Web Vitals são usadas pelos sistemas de classificação. ⁴ Ainda assim, o Google mostra o conteúdo mais relevante, mesmo com experiência abaixo do ideal. A boa experiência pesa quando há muito conteúdo útil para a mesma busca. ⁴

Qual é a nota boa no PageSpeed Insights?

No laboratório, 90 ou mais é considerado bom. ¹¹ A própria ferramenta avisa que nota boa no laboratório não garante boa experiência para os visitantes reais. ¹¹ E o Google escreve que perseguir nota perfeita só por SEO pode não ser o melhor uso do tempo. ⁴

Por que a nota muda quando rodo o teste de novo?

A ajuda do PageSpeed cita a rede local, o hardware disponível e a disputa por recursos durante o teste. ¹¹ Rode mais de uma vez antes de concluir qualquer coisa.

Por que o PageSpeed e o Search Console mostram números diferentes?

O PageSpeed mostra uma página, e o relatório de Core Web Vitals mostra grupos de páginas parecidas. ¹³ Dentro do PageSpeed, o laboratório simula um aparelho, e o campo junta 28 dias de visitas reais. ⁹ ¹¹

Meu site não aparece no relatório de Core Web Vitals. Está errado?

Não necessariamente. O relatório só mostra grupos com visitas suficientes, e site novo ou com pouco tráfego pode cair na tela sem dados. ¹³ Nesse caso, a ajuda indica o PageSpeed Insights ou o Lighthouse para testar página por página. ¹³

Teste de velocidade da internet mede a velocidade do site?

Não. O Fast.com e o Speedtest medem a conexão de quem faz o teste. ¹ Para o site, a ajuda do Search Console indica o PageSpeed Insights, o Lighthouse e o relatório de Core Web Vitals. ¹³

Notas e fontes

Leitura ao vivo da página de resultados do Google Brasil para “velocidade do site”, 14 de setembro de 2026, endereço https://www.google.com.br/search?q=velocidade+do+site&hl=pt-BR&gl=br&pws=0, em aba própria do navegador do autor. Resultados orgânicos da primeira página, na ordem: PageSpeed Insights (pagespeed.web.dev), Pingdom, PageSpeed Insights em português, GTmetrix, SpeedVitals, DialHost, Google for Developers (página do PageSpeed Insights), Fast.com (“faz uma estimativa da velocidade do seu provedor”) e Speedtest by Ookla (“Teste de Velocidade de Conexão”). A Visão geral criada por IA apareceu depois dos orgânicos, com os trechos “PageSpeed Insights: Mostra notas de 0 a 100 e aponta falhas de código ou imagens” e, nas dicas, imagens, código e “Hospedagem: Contrate um servidor estável e rápido”. Acesso em 14 de setembro de 2026.
Medição da SEO Genome no Semrush, base Brasil, 14 de setembro de 2026. “velocidade do site”: 2.400 buscas por mês, dificuldade 42. Entre os dez primeiros resultados orgânicos do retrato do Semrush estão speedtest.net e fast.com, dois testes de conexão de internet; a base de celular não tem retrato para o termo.
Medição da SEO Genome no PageSpeed Insights, página https://seogenome.com/, formato celular, relatório criado em 14 de setembro de 2026 às 5h59 (horário de Brasília), https://pagespeed.web.dev/analysis/https-seogenome-com/4114yrs2j7?form_factor=mobile. Acesso em 14 de setembro de 2026. Laboratório: “Moto G Power emulado with Lighthouse 13.4.1”, “Limitação lenta de 4G”, “Local do navegador: América do Norte”; desempenho 98; First Contentful Paint 1,0 s; Largest Contentful Paint 1,4 s; Total Blocking Time 0 ms; “Mostrar recursos de terceiros (0)”. Campo: “Os dados de usuário real deste URL são insuficientes. Estamos retomando os dados agregados de toda a experiência do usuário nesta origem (https://seogenome.com)”; período de coleta de 15 de agosto a 11 de setembro de 2026; Largest Contentful Paint no percentil 75 de 2,4 s, com 75% boas, 15% precisa melhorar e 10% ruins (acima de 4 s); Time to First Byte no percentil 75 de 0,8 s; avaliação das Core Web Vitals “aprovado”.
Google Search Central, “Understanding page experience in Google Search results”, https://developers.google.com/search/docs/appearance/page-experience, página atualizada em 10 de dezembro de 2025. Acesso em 14 de setembro de 2026. Trechos: a autoavaliação com “Do your pages have good Core Web Vitals?”, “Are your pages served in a secure fashion?”, “Does your content display well on mobile devices?” e o item sobre anúncios em excesso; “There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience”; “Core Web Vitals are used by our ranking systems”; “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. However, they can make your website more satisfying to use, which is generally aligned with what our ranking systems seek to reward”; “Our core ranking systems generally evaluate content on a page-specific basis” e “However, we do have some site-wide assessments”; “Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases”; “getting good results in reports like Search Console’s Core Web Vitals report or third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results” e “trying to get a perfect score just for SEO reasons may not be the best use of your time”.
Google Search Central, “Understanding Core Web Vitals and Google search results”, https://developers.google.com/search/docs/appearance/core-web-vitals, página atualizada em 10 de dezembro de 2025. Acesso em 14 de setembro de 2026. Trecho: “Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page”.
Amit Singhal e Matt Cutts, “Using site speed in web search ranking”, Google Search Central Blog, 9 de abril de 2010, https://developers.google.com/search/blog/2010/04/using-site-speed-in-web-search-ranking. Acesso em 14 de setembro de 2026. Trechos: “While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page” e “Currently, fewer than 1% of search queries are affected by the site speed signal in our implementation and the signal for site speed only applies for visitors searching in English on Google.com at this point”. A página traz aviso de que o texto é antigo e pode estar desatualizado.
Zhiheng Wang e Doantam Phan, “Using page speed in mobile search ranking”, Google Search Central Blog, 17 de janeiro de 2018, com atualização de 9 de julho de 2018, https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search. Acesso em 14 de setembro de 2026. Trechos: “starting in July 2018, page speed will be a ranking factor for mobile searches”; “will only affect pages that deliver the slowest experience to users and will only affect a small percentage of queries”; e “a slow page may still rank highly if it has great, relevant content”.
Chrome for Developers, “Overview of CrUX”, https://developer.chrome.com/docs/crux, página atualizada em 8 de fevereiro de 2024. Acesso em 14 de setembro de 2026. Trechos: “a dataset that reflects how real-world Chrome users experience popular destinations on the web” e “is used by Google Search to inform the page experience ranking factor”.
Philip Walton, “Why lab and field data can be different (and what to do about it)”, web.dev, página atualizada em 18 de julho de 2022, https://web.dev/articles/lab-and-field-data-differences. Acesso em 14 de setembro de 2026. Trechos: “data collected in a controlled environment with predefined device and network settings”; “A single device… connected to a single network… run from a single geographic location”; “Chrome tools that report lab data are generally running Lighthouse”; “Chrome tools that report field data generally get that data from the Chrome User Experience Report (CrUX)”; “CrUX reports show a distribution of performance metrics from real Chrome users over a 28-day period”; “Tools that report Core Web Vitals field scores do so using the 75th percentile”; “Lab tests typically load a page with a cold cache”; “real-user behavior, such as scrolling, selecting text, or tapping elements on the page”; o exemplo das telas de tamanhos diferentes, que mudam o maior elemento; “field data is what you should use to prioritize your efforts”; “The controlled environment of the lab is useful when debugging issues or testing features before deploying to production”; e “it only does so for users who are successfully able to load your site”.
Chrome for Developers, “Introduction to Lighthouse”, https://developer.chrome.com/docs/lighthouse/overview, página atualizada em 2 de junho de 2025. Acesso em 14 de setembro de 2026. Trechos: “Lighthouse is an open-source, automated tool”; “You can run it on any web page, public or requiring authentication”; e o painel próprio no Chrome DevTools.
Google for Developers, “About PageSpeed Insights”, https://developers.google.com/speed/docs/insights/v5/about, página atualizada em 21 de outubro de 2024. Acesso em 14 de setembro de 2026. Trechos: “PSI provides both lab and field data about a page”; os dados de campo do CrUX “over the previous 28-day collection period”; “When this happens, PSI will fall back to origin-level granularity” e “Sometimes the origin may also have insufficient data, in which case PSI will be unable to show any real-user experience data”; “PSI uses Lighthouse to analyze the given URL in a simulated environment”; “A score of 90 or above is considered good”; “By focusing on 75th percentile values for our metrics, this ensures that pages provide a good user experience under the most difficult device and network conditions”; “having good lab data does not necessarily mean real-user experiences will also be good”; e as fontes de variação “local network availability, client hardware availability, and client resource contention”.
Registro interno da SEO Genome sobre a construção do site novo, entradas de 2 de setembro de 2026. Lighthouse com nota máxima nas cinco rotas medidas, no celular e no computador, com a ressalva escrita de que o build medido estava sem Google Analytics e de que a nota não media o impacto dele; o diagnóstico inicial apontava imagens de algumas páginas, e o maior peso estava nas fontes, com 50,3 KB de peso morto em toda página, o eixo de peso de 100 a 900 contra 400 a 600 pedidos; a fonte Inter de 48 para 20,8 KB; a página inicial de 150 para 94 KB; o maior elemento no celular, no laboratório, de 1.954 para 1.504 milissegundos; a medição de audiência atrás do consentimento, com zero requisição para terceiros antes do aceite; e o seogenome.com servido pelo site novo desde 2 de setembro de 2026, com o WordPress antigo fora do ar no mesmo endereço.
Ajuda do Search Console, “Core Web Vitals report”, https://support.google.com/webmasters/answer/9205520, versões em inglês e em português. Acesso em 14 de setembro de 2026. Trechos da versão em inglês: “based on real world usage data (sometimes called field data)”; “URL performance grouped by status (Poor, Need improvement, Good), metric type (CLS, INP, and LCP), and URL group (groups of similar web pages)”; “the URL group’s status is its most poorly performing metric”; “75% of page requests” nos últimos 28 dias; “Only indexed URLs can appear in this report”; “It shows a sample of pages”; “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports”; “data is combined for all requests from all locations”; o grupo de origem criado quando falta dado; a tela “No data available”; “PageSpeed Insights strips all parameter data from the URL”; “Reduce your page size: best practice is less than 500KB for a page and all its resources” e “Limit a page to 50 resources for best performance on mobile”; o caso do status que muda sem alteração no site, com o exemplo de “the service that serves your image files experienced a latency change”; “start a 28-day monitoring session” e “Start tracking does not trigger re-indexing”; e a indicação do PageSpeed Insights e do Lighthouse para testar URLs individuais. Os rótulos em português (Ruim, Melhorias necessárias, Bom) são os da versão em português da mesma ajuda.
web.dev, “The most effective ways to improve Core Web Vitals”, adaptado de um post de 2023, página atualizada em 31 de outubro de 2024, https://web.dev/articles/top-cwv. Acesso em 14 de setembro de 2026. Trechos: “Per the 2024 Web Almanac by HTTP Archive, 73% of mobile pages have an image as their LCP element”; “the majority of origins with poor LCP spend less than 10% of their p75 LCP time downloading the LCP image”; “Among pages with poor LCP, loading their LCP images is delayed on the client by 1,290 milliseconds at the 75th percentile”; “35% of those images had source URLs that were not discoverable in the initial HTML response”; a recomendação contra data-src e a de remover loading="lazy" da imagem principal; “66% of pages have at least one unsized image” e “these images have an initial height of 0px”; e o uso de CDN para servir o conteúdo perto de quem visita.
Katie Hempenius e Barry Pollard, “Best practices for fonts”, web.dev, página atualizada em 4 de outubro de 2022, https://web.dev/articles/font-best-practices. Acesso em 14 de setembro de 2026. Trechos: “If a web font has not loaded, browsers typically delay text rendering”; “These layout shifts occur when a web font and its fallback font take up different amounts of space on the page”; e, sobre o subconjunto, “When moving to self-hosting, this is an optimization that can be missed and lead to larger font files locally”.
Addy Osmani e Arthur Evans, “Load Third-Party JavaScript”, web.dev, página atualizada em 19 de fevereiro de 2024, https://web.dev/articles/optimizing-content-efficiency-loading-third-party-javascript. Acesso em 14 de setembro de 2026. Trechos: “If you’ve optimized your code, but your site still loads too slowly, it’s probably the fault of third-party scripts”; e a lista de exemplos, com botões de compartilhamento, vídeos incorporados, anúncios, scripts de medição e de teste A/B.
Katie Hempenius e Barry Pollard, “Best practices for tags and tag managers”, web.dev, publicado em 29 de julho de 2021 e atualizado em 24 de agosto de 2022, https://web.dev/articles/tag-best-practices. Acesso em 14 de setembro de 2026. Trechos: “we have seen a correlation between the size of tag managers and poorer INP scores”; “the performance impact of any single tag may be negligible” e “can become significant when tens or hundreds of tags are used on the same page”; e “Tag managers aren’t typically the best way to load resources that implement immediate visual or functional aspects of the user experience, such as cookie notices, hero images, or site features”.
Barry Pollard e Jeremy Wagner, “Optimize Time to First Byte”, web.dev, publicado em 19 de janeiro de 2023 e atualizado em 28 de novembro de 2025, https://web.dev/articles/optimize-ttfb. Acesso em 14 de setembro de 2026. Trechos: o TTFB “precedes every other meaningful user experience metric” e “high TTFB values add time to the metrics that follow it”; “TTFB is not a Core Web Vitals metric”; os limites como “a rough guide”; a seção “Hosting, hosting, hosting”, com “Before you even consider other optimization approaches, hosting should be the first thing you consider”, “ensure that your website’s host is capable of handling the traffic you send to it” e o trecho sobre hospedagem compartilhada e site pequeno de arquivos estáticos; “WordPress performance is impacted by the number and quality of plugins, or what themes are used”; “One common contributor to a high TTFB is redirects”; e a CDN como forma de aproximar o servidor de quem visita.
Google, “Optimize your crawl budget”, documentação da infraestrutura de rastreamento, https://developers.google.com/crawling/docs/crawl-budget, página atualizada em 22 de julho de 2026. Acesso em 14 de setembro de 2026. Trechos: “If the site slows down (latency increases or response times become longer), or responds with server errors ( 5xx HTTP status codes) or rate-limiting signals (such as HTTP 429 ), the limit goes down and Google crawls less”; “If Google can load and render your pages faster, we might be able to read more content from your site”; e o público do guia, sites com mais de 1 milhão de páginas ou com mais de 10 mil páginas que mudam todo dia.

Velocidade do site: o que o Google mede, o que ele diz e o que deixa a página lenta