Como medir a velocidade do site e ler os resultados

Resposta curta: que ferramenta usar e que número olhar

Para medir a velocidade de um site sem entrar já em ferramentas técnicas, comece pelo PageSpeed Insights. Basta introduzir o endereço da página que quer testar. A ferramenta da Google analisa versões para telemóvel e computador e combina, quando existem dados suficientes, informação sobre a experiência de utilizadores reais com um teste realizado em ambiente controlado.

Se tiver pouco tempo, comece pelo resultado em telemóvel e procure a secção com dados de utilizadores reais. Os números mais importantes são as três Core Web Vitals: LCP, que indica quanto demora a aparecer o conteúdo principal; INP, que mede a rapidez de resposta às interações; e CLS, que mostra se os elementos da página mudam inesperadamente de posição enquanto esta carrega.

Como referência, a Google considera bons resultados um LCP até 2,5 segundos, um INP até 200 milissegundos e um CLS até 0,1, avaliados no percentil 75 das visitas. Isto significa que não interessa apenas saber como o site se comportou num teste isolado. Quando estão disponíveis, os dados reais ajudam a perceber a experiência que a maioria dos visitantes efetivamente teve em diferentes dispositivos e condições de ligação.

A pontuação de desempenho de 0 a 100 também é útil, sobretudo para diagnosticar problemas, mas não deve ser o primeiro número a perseguir. Um teste de laboratório pode variar entre execuções e não substitui os dados recolhidos de utilizadores reais. Se o PageSpeed Insights ainda não tiver dados reais suficientes para determinada página, use o resultado de laboratório como ponto de partida e volte a verificar mais tarde.

Caixa-resumo: medir a velocidade do site em 30 segundos

1. Ferramenta: abra o PageSpeed Insights e teste o URL da página.

2. Dispositivo: comece pelo resultado em telemóvel.

3. Números: procure LCP até 2,5 s, INP até 200 ms e CLS até 0,1.

4. Prioridade: leia primeiro os dados de utilizadores reais, quando estiverem disponíveis, e use o teste de laboratório para descobrir o que pode estar a causar os problemas.

Porque um site lento custa contactos e vendas

A velocidade de um site não é apenas uma questão técnica. Afeta diretamente a facilidade com que um potencial cliente consegue perceber a oferta, consultar um serviço, preencher um formulário ou avançar para um contacto.

Quando uma página demora a carregar, cada passo fica mais difícil. O visitante pode esperar pela imagem principal, tentar tocar num botão que ainda não responde ou ver o conteúdo mudar de posição enquanto lê. Mesmo alguns segundos de fricção podem ser suficientes para transformar uma visita com intenção numa saída sem contacto.

O problema é ainda mais visível em telemóvel. Quem pesquisa um serviço fora de casa, com uma ligação móvel menos estável, pode ter uma experiência muito diferente daquela que o proprietário do site vê no computador do escritório. Um site que parece rápido numa ligação Wi-Fi forte pode tornar-se frustrante em condições reais.

A lentidão também interfere com páginas que estão mais próximas de gerar negócio. Uma página de serviço pode perder visitantes antes de estes chegarem ao formulário. Uma landing page pode carregar o botão de contacto demasiado tarde. Numa loja online, imagens pesadas, scripts ou atrasos na resposta podem acrescentar obstáculos precisamente quando o utilizador está a tentar comparar produtos ou concluir uma compra.

Por isso, medir a velocidade do site faz sentido sobretudo como uma forma de encontrar problemas que dificultam ações importantes. O objetivo não é obter um número bonito num relatório, mas reduzir esperas, atrasos e movimentos inesperados que possam afastar pessoas interessadas.

Isto também ajuda a decidir onde investir primeiro. Se uma página recebe visitas e tem potencial para gerar contactos ou vendas, mas apresenta uma experiência lenta, melhorar essa página pode ser mais relevante do que otimizar outras áreas pouco visitadas do site.

Antes de corrigir qualquer problema, porém, é importante perceber que tipo de medição está a observar. Um teste feito naquele momento e os dados recolhidos de utilizadores reais respondem a perguntas diferentes, e confundir os dois pode levar a conclusões erradas.

Teste de laboratório ou dados reais: o que cada um mede

Ao abrir o PageSpeed Insights, pode encontrar dois tipos de resultados: dados de laboratório e dados de utilizadores reais. Os dois são úteis, mas respondem a perguntas diferentes. O teste de laboratório ajuda a diagnosticar o que está a acontecer numa execução controlada. Os dados reais mostram como o site tem sido sentido por pessoas que o visitaram de facto.

O que mostra um teste de laboratório

O teste de laboratório é realizado pelo Lighthouse num ambiente definido, com condições simuladas de dispositivo e ligação. Isto permite repetir a análise e identificar problemas técnicos, como recursos pesados, JavaScript que bloqueia o carregamento ou elementos que demoram demasiado a aparecer.

É especialmente útil para perceber por que razão uma página pode estar lenta e para comparar o resultado antes e depois de uma alteração. Também funciona em páginas novas ou com pouco tráfego, porque não depende de visitantes reais.

No entanto, continua a ser uma simulação. A pontuação pode variar entre testes e não representa necessariamente aquilo que todos os utilizadores sentem no dia a dia. Por isso, deve ser encarada sobretudo como uma ferramenta de diagnóstico, não como uma fotografia definitiva da experiência de todos os visitantes.

O que mostram os dados de utilizadores reais

Os dados reais do PageSpeed Insights vêm do Chrome User Experience Report, também conhecido como CrUX. Em vez de simular uma visita, esta informação agrega experiências reais de utilizadores do Chrome que cumprem os critérios de participação no conjunto de dados.

No PageSpeed Insights, estes resultados representam uma janela contínua dos 28 dias anteriores e são atualizados diariamente. É aqui que deve procurar LCP, INP e CLS para perceber como a página tem funcionado em condições reais, incluindo diferenças de dispositivos e qualidade de ligação.

Isto explica também por que uma melhoria feita hoje pode não provocar uma mudança imediata nos dados reais. O resultado continua a incluir visitas anteriores à alteração até que essas experiências sejam gradualmente substituídas por dados mais recentes.

Porque o seu site pode não ter dados reais suficientes

Nem todas as páginas apresentam dados de utilizadores reais. Uma página nova, com poucas visitas ou sem dados suficientes no CrUX pode mostrar apenas o teste de laboratório.

Quando não existem dados suficientes para o URL específico, o PageSpeed Insights pode apresentar dados agregados de todo o domínio. Se também não houver informação suficiente a esse nível, a secção de experiência real pode simplesmente não aparecer.

Isso não significa que o teste esteja errado ou que exista um problema no site. Significa apenas que não há uma amostra suficiente disponível para mostrar aquela medição real. Nessa situação, use os dados de laboratório para procurar problemas técnicos e continue a acompanhar o site à medida que acumula tráfego.

Os três números que dizem se um site é rápido

Depois de distinguir dados reais de testes de laboratório, a leitura do relatório torna-se mais simples. Para avaliar a experiência de velocidade, concentre-se em três Core Web Vitals: LCP, INP e CLS. Cada uma mede um problema diferente que o visitante pode sentir ao usar a página.

O LCP mede quanto tempo demora a aparecer o conteúdo principal. O INP mede a rapidez com que a página responde quando alguém clica, toca ou interage. O CLS mede a estabilidade visual, ou seja, se textos, botões e imagens mudam inesperadamente de posição.

Limiares de LCP, INP e CLS definidos pelo Google

Para uma boa experiência, o Google recomenda LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1. A avaliação das Core Web Vitals utiliza o percentil 75, o que significa que a página deve atingir estes valores em pelo menos 75% das experiências consideradas.

Os intervalos ajudam a perceber a gravidade do problema:

• LCP: bom até 2,5 s; precisa de melhorias entre 2,5 s e 4 s; fraco acima de 4 s.
• INP: bom até 200 ms; precisa de melhorias entre 200 ms e 500 ms; fraco acima de 500 ms.
• CLS: bom até 0,1; precisa de melhorias entre 0,1 e 0,25; fraco acima de 0,25.

Uma página pode estar bem numa métrica e mal noutra. Por exemplo, o conteúdo pode aparecer rapidamente, mas os botões demorarem a responder. Por isso, não reduza a análise a um único número. Veja qual das três métricas está fora do intervalo recomendado e investigue a causa correspondente.

A pontuação de 0 a 100 não é o que o Google avalia

O número grande que aparece no teste de desempenho do Lighthouse é fácil de interpretar, mas tem uma função diferente. É uma pontuação de laboratório, calculada a partir de várias métricas ponderadas. Não é uma Core Web Vital e pode variar entre testes devido às condições em que a medição é realizada.

No Lighthouse, uma pontuação de 90 a 100 aparece a verde, 50 a 89 a laranja e 0 a 49 a vermelho. Chegar aos 100 pontos não é necessário, e a própria documentação do Lighthouse indica que uma pontuação perfeita é difícil de atingir e não é esperada.

Erro comum: perseguir o 100

Melhorar uma página de 96 para 100 pode consumir tempo sem resolver o problema que mais afeta os visitantes. Use a pontuação para acompanhar o diagnóstico, mas dê prioridade às Core Web Vitals, aos dados de utilizadores reais e aos problemas que interferem com ações importantes no site.

Também não deve interpretar uma boa pontuação como garantia de melhor posição no Google. As Core Web Vitals são consideradas pelos sistemas de classificação, mas fazem parte de uma avaliação mais ampla da experiência na página, e bons resultados técnicos não garantem, por si só, posições elevadas na pesquisa.

Ferramentas gratuitas para testar a velocidade de um site

Não precisa de uma plataforma paga para começar a medir a velocidade de um site. As ferramentas abaixo cobrem necessidades diferentes, desde uma verificação rápida até à análise detalhada da ordem em que cada recurso é carregado.

PageSpeed Insights: o ponto de partida

Para a maioria dos proprietários de sites, o PageSpeed Insights é a ferramenta mais simples para começar. Introduza o URL e terá resultados separados para telemóvel e computador, dados reais do Chrome User Experience Report quando existe informação suficiente e uma análise de laboratório produzida pelo Lighthouse.

Além das métricas, o relatório apresenta diagnósticos e oportunidades de melhoria. Isto torna-o útil tanto para perceber se existe um problema como para levar informação concreta a quem gere tecnicamente o site.

Relatório Core Web Vitals no Google Search Console

Se tiver acesso ao Google Search Console, consulte também o relatório de Core Web Vitals. Ao contrário de um teste isolado de um URL, este relatório permite identificar grupos de páginas com problemas de LCP, INP ou CLS com base em dados reais de utilização.

É particularmente útil para acompanhar um site com muitas páginas. Se várias páginas semelhantes apresentarem o mesmo problema, pode existir uma causa comum que compensa resolver de forma global.

GTmetrix e WebPageTest: ver o que carrega e por que ordem

Quando sabe que uma página está lenta mas precisa de descobrir porquê, o GTmetrix e o WebPageTest permitem aprofundar a análise.

O GTmetrix inclui um gráfico waterfall que apresenta os pedidos da página pela ordem em que são carregados. Assim, pode detetar ficheiros grandes, scripts demorados, pedidos com falhas ou respostas lentas. Existe uma modalidade gratuita, embora algumas funcionalidades e limites dependam do plano.

O WebPageTest permite executar testes gratuitos e controlar condições como dispositivo, localização e velocidade da ligação. A análise detalhada da sequência de carregamento ajuda sobretudo quando é necessário investigar problemas que o PageSpeed Insights apenas sinaliza.

Lighthouse no Chrome: medir antes de publicar

O Lighthouse está integrado nas ferramentas de programador do Google Chrome e pode analisar desempenho, acessibilidade, boas práticas e SEO. Também consegue testar páginas locais ou áreas que exigem autenticação, algo útil durante o desenvolvimento.

Isto permite ao programador testar uma página antes de a publicar e voltar a medi-la depois de cada alteração. Para uma verificação ocasional, o PageSpeed Insights continua a ser mais simples. Para diagnosticar durante o trabalho técnico, o Lighthouse no Chrome oferece maior controlo.

Medir a velocidade do site em cinco passos

Uma medição útil deve ser repetível. Testar uma página uma única vez e guardar apenas a pontuação pode levar a conclusões erradas. O objetivo é criar uma pequena rotina que permita comparar resultados e perceber se uma alteração melhorou realmente a experiência.

1. Escolha as páginas que trazem clientes, não só a inicial

A página inicial é importante, mas raramente representa todo o site. Teste também as páginas que recebem tráfego relevante ou estão mais próximas de gerar contactos e vendas.

Inclua, por exemplo, páginas de serviços, páginas de produtos, landing pages, formulários de contacto e outras páginas que aparecem frequentemente nos resultados de pesquisa. Uma página pouco visitada pode ter uma pontuação excelente e, ainda assim, ser menos importante do que uma página de serviço lenta que recebe dezenas de potenciais clientes.

2. Comece pelo resultado em telemóvel

Faça primeiro o teste para telemóvel. Muitos utilizadores acedem ao site através de dispositivos móveis e podem estar ligados a redes mais lentas ou a equipamentos menos potentes do que o computador usado no escritório.

Se o resultado em telemóvel for fraco e o de computador for bom, não escolha apenas o número mais favorável. Analise o que está a prejudicar a experiência móvel e verifique se o problema afeta páginas importantes.

3. Leia os dados reais antes da pontuação

Quando o PageSpeed Insights apresenta dados de utilizadores reais, comece por aí. Verifique sobretudo LCP, INP e CLS e confirme se aparecem como bons, a precisar de melhorias ou fracos.

Só depois passe para a pontuação de laboratório e para a lista de recomendações. Esta ordem evita um erro comum: concentrar-se em subir alguns pontos no Lighthouse enquanto uma Core Web Vital continua a revelar um problema sentido pelos visitantes.

Se não existirem dados reais suficientes, use o teste de laboratório como referência e mantenha essa limitação em mente ao interpretar o resultado.

4. Repita o teste e anote a data

Um teste isolado pode variar. Execute a medição mais do que uma vez, sobretudo quando está a comparar o resultado antes e depois de uma alteração.

Anote a data, a página testada, o dispositivo e os principais valores. Não precisa de criar um relatório complexo. Uma folha de cálculo simples com LCP, INP, CLS e pontuação de desempenho já ajuda a manter um histórico coerente.

Também é útil evitar comparações feitas em condições completamente diferentes. Se usar ferramentas que permitem escolher localização, dispositivo ou velocidade de ligação, tente manter essas definições consistentes.

5. Guarde o resultado para comparar depois de cada alteração

Antes de otimizar imagens, remover plugins, trocar de alojamento ou alterar o código, guarde o resultado inicial. Pode ser uma captura de ecrã, um relatório exportado ou apenas os valores registados numa tabela.

Depois da alteração, teste novamente as mesmas páginas e compare os números. Isto permite perceber se a intervenção resolveu o problema ou apenas mudou a pontuação sem melhorar a experiência mais importante.

Ao repetir este processo, a medição deixa de ser uma fotografia ocasional e passa a funcionar como um controlo de qualidade. Cada alteração pode ser avaliada com base em resultados anteriores, em vez de depender apenas da impressão de que o site “parece mais rápido”.

Como ler o relatório e decidir por onde começar

Um relatório de velocidade pode apresentar dezenas de métricas, avisos e recomendações. Isso não significa que tenha dezenas de problemas igualmente urgentes. A leitura deve começar pelo impacto no utilizador e pelas páginas que têm maior importância para o negócio.

Resultado a verde, a amarelo ou a vermelho: o que fazer em cada caso

Um resultado a verde indica que a métrica está dentro do intervalo considerado bom. Não significa que a página esteja perfeita nem que nunca precise de ser revista, mas normalmente não é aí que deve concentrar o esforço imediato.

Um resultado a amarelo mostra que existe margem para melhoria. Vale a pena analisar a causa, sobretudo se a página recebe muito tráfego, gera contactos ou apresenta o mesmo problema de forma consistente em diferentes medições.

Um resultado a vermelho merece atenção prioritária, especialmente quando aparece nos dados de utilizadores reais. Se o LCP, INP ou CLS estiver num intervalo fraco, procure perceber que elemento ou comportamento está a causar o problema antes de começar a aplicar correções aleatórias.

A prioridade também depende da importância da página. Um problema vermelho numa página de serviço que recebe potenciais clientes pode justificar intervenção antes de um problema semelhante numa página antiga quase sem visitas.

Que recomendações do relatório tratar primeiro

Depois de identificar a métrica problemática, use as recomendações do relatório para procurar a causa. Nem todas têm o mesmo impacto, e uma lista longa não deve ser tratada como uma checklist que precisa de chegar a zero.

Comece pelas recomendações diretamente relacionadas com a métrica que está mal. Se o LCP estiver elevado, procure elementos principais demasiado pesados, tempos de resposta lentos ou recursos que atrasem a apresentação do conteúdo. Se o INP estiver fraco, investigue tarefas de JavaScript demoradas ou scripts que bloqueiam a resposta. Se o CLS for o problema, procure imagens, anúncios, tipos de letra ou outros elementos que mudem de tamanho ou posição durante o carregamento.

Dê também prioridade a problemas que se repetem em várias páginas. Uma imagem específica pode afetar apenas um URL, enquanto um plugin, tema, script ou configuração do servidor pode prejudicar uma grande parte do site. Resolver uma causa comum tende a produzir um benefício mais amplo.

Erro comum: corrigir tudo o que o relatório lista

Os relatórios de desempenho incluem oportunidades, diagnósticos e avisos com níveis de importância diferentes. Tentar eliminar cada item pode consumir tempo sem melhorar de forma relevante a experiência do visitante. Primeiro identifique a métrica que está pior, depois procure as recomendações que ajudam a explicar esse resultado e meça novamente após a alteração.

Evite ainda escolher uma correção apenas porque promete a maior redução teórica de milissegundos. Algumas alterações podem exigir muito trabalho, afetar funcionalidades ou produzir pouco efeito nas condições reais. O melhor ponto de partida é normalmente um problema claro, recorrente, com impacto numa página importante e cuja melhoria possa ser confirmada através de uma nova medição.

O que costuma tornar um site lento

Depois de identificar onde a velocidade está a falhar, o passo seguinte é perceber a causa provável. Um site lento raramente tem um único problema. Muitas vezes, imagens pesadas, scripts, plugins e servidor acumulam pequenos atrasos que acabam por afetar a experiência.

O que pedir ao fornecedor depois de medir

Depois de medir a velocidade do site, o relatório só é útil se ajudar a transformar um problema técnico numa ação concreta. Em vez de enviar apenas uma captura do PageSpeed Insights com uma pontuação baixa, vale a pena indicar ao fornecedor que páginas foram testadas, em que dispositivo e quais métricas apresentam problemas.

Isso reduz ambiguidades e facilita uma resposta objetiva. Por exemplo, dizer que “o site está lento” é muito vago. É mais útil informar que a página de um serviço apresenta LCP elevado em telemóvel ou que várias páginas têm problemas de CLS nos dados reais.

Também convém pedir ao fornecedor que identifique a causa antes de propor uma solução. Uma métrica fraca pode ter origens diferentes. O LCP pode estar relacionado com uma imagem pesada, com o servidor ou com recursos que bloqueiam o carregamento. O INP pode apontar para JavaScript excessivo, enquanto o CLS costuma estar ligado a elementos que mudam de posição durante a abertura da página.

Sempre que possível, peça ainda que o fornecedor explique o impacto esperado da alteração e como pretende confirmar o resultado depois de a implementar. Isto ajuda a evitar intervenções genéricas, como instalar mais um plugin de otimização ou alterar várias configurações ao mesmo tempo sem saber qual delas resolveu o problema.

Checklist para enviar ao fornecedor

• Indique os URLs das páginas que testou.
• Diga se o problema aparece em telemóvel, computador ou ambos.
• Partilhe os valores de LCP, INP e CLS que estão fora do intervalo recomendado.
• Informe se os valores vêm de dados reais ou apenas do teste de laboratório.
• Anexe o relatório ou uma captura com a data da medição.
• Pergunte qual é a causa provável de cada problema prioritário.
• Peça para distinguir problemas de imagens, código, plugins, scripts externos e alojamento.
• Pergunte que alterações serão feitas e se existe algum risco para o design ou para as funcionalidades do site.
• Peça uma nova medição das mesmas páginas depois da intervenção.
• Compare os resultados antes e depois, mantendo condições de teste semelhantes.

Se utiliza uma agência, programador ou empresa de manutenção, não precisa de saber executar cada correção. Precisa, sim, de conseguir verificar se o problema identificado foi compreendido, se a solução está relacionada com a causa e se existe uma medição que demonstre a melhoria.

Guardar os resultados anteriores torna esta conversa muito mais simples. Em vez de depender de afirmações como “o site já está mais rápido”, pode comparar as mesmas páginas e métricas antes e depois do trabalho. Assim, a velocidade deixa de ser uma questão de perceção e passa a ser um resultado que pode acompanhar ao longo do tempo.

É assim que a Dappio trata a velocidade numa consultoria SEO: os Core Web Vitals entram na auditoria técnica, ao lado da indexação e da arquitetura de URLs.

Perguntas frequentes sobre a velocidade de um site

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

Sim, mas não funciona como uma relação simples entre uma pontuação alta e uma posição melhor. O Google indica que as Core Web Vitals são usadas pelos seus sistemas de classificação, juntamente com muitos outros sinais relacionados com relevância, qualidade do conteúdo e experiência na página. Ter bons resultados de LCP, INP e CLS pode contribuir para o desempenho na pesquisa, mas não garante chegar às primeiras posições.

Por isso, melhorar a velocidade deve servir primeiro para oferecer uma experiência melhor aos visitantes. Tentar chegar aos 100 pontos no Lighthouse apenas por motivos de SEO não é uma utilização eficiente do tempo.

Com que frequência se deve repetir o teste de velocidade?

Não existe uma frequência obrigatória. Como regra prática, teste novamente sempre que fizer uma alteração relevante no site, como mudar o tema, instalar plugins, adicionar ferramentas externas, alterar o alojamento ou publicar uma página especialmente importante.

Quanto tempo demora o Google a refletir uma melhoria?

Num teste de laboratório, uma melhoria técnica pode aparecer logo após a alteração. Nos dados de utilizadores reais, o efeito é mais gradual porque as Core Web Vitals do CrUX utilizam dados agregados de uma janela móvel de 28 dias. Dados antigos vão sendo substituídos à medida que novas visitas entram na amostra.

Se o site abre depressa no meu computador, isso chega?

Não. O seu computador representa apenas uma combinação de dispositivo, ligação, localização, cache e condições de utilização.

Um cliente pode abrir a mesma página num telemóvel menos potente, através de dados móveis ou pela primeira vez, sem ter ficheiros guardados em cache. É precisamente por isso que os dados de utilizadores reais são importantes: mostram experiências agregadas em condições mais variadas do que uma verificação feita no seu próprio equipamento.

Como resolver um site lento sem o refazer?

Na maioria dos casos, um site lento não precisa de ser reconstruído de raiz. Comece pelas causas identificadas na medição e faça alterações específicas.

Pode ser suficiente comprimir e redimensionar imagens, melhorar a cache, reduzir scripts desnecessários, rever plugins, carregar determinados recursos apenas quando necessários ou corrigir um servidor lento. Em WordPress, uma auditoria aos plugins e ao tema também pode revelar funções duplicadas ou recursos carregados sem necessidade.