Como o Mecita pontua
Esta checagem vale 2 pontos na nota. A tabela mostra o que o diagnóstico procura e quanto paga em cada caso, com os mesmos números que o scanner usa.
O que vale ponto
máximo 2 pontos- PassaPágina inicial entregue em menos de 1,2 segundo2
- AtençãoEntre 1,2 e 3 segundos1
- Falha3 segundos ou mais0
Esta checagem mede uma coisa só: quanto tempo o seu servidor leva para entregar a página inicial, do pedido até o último byte do HTML. Não é sobre a sensação de velocidade de quem navega, com imagens aparecendo aos poucos. É sobre quanto um robô precisa esperar antes de ter o texto em mãos.
É a checagem de menor peso na nota, junto com o sitemap. Um site um pouco lento ainda é lido. Mas um site muito lento corre o risco de não ser lido por inteiro, ou de ser lido menos vezes.
O que o Mecita verifica
O diagnóstico faz um único pedido à sua página inicial, seguindo redirecionamentos, como http para https ou o domínio sem www para o domínio com www. O cronômetro começa no pedido e para quando o HTML chega completo. O tempo inclui, portanto, cada redirecionamento, o processamento no servidor e a transferência do arquivo.
A régua tem três faixas:
- Menos de 1,2 segundo: a checagem passa com a pontuação cheia.
- Entre 1,2 e 3 segundos: alerta, com metade dos pontos. Robôs costumam ter paciência curta, e cada segundo a mais é uma chance de a leitura ser interrompida.
- 3 segundos ou mais: falha, sem pontos. Nessa faixa, muitos robôs desistem antes de ler a página.
Se a página não chega dentro do limite de espera do próprio diagnóstico, não há HTML para analisar, e o resultado mostra que não foi possível ler o site em vez de uma nota.
Uma medição, não uma média
O Mecita mede uma vez, a partir do nosso servidor. O tempo varia com o horário, com a carga do seu servidor e com a distância entre os dois. Por isso esta checagem vale pouco: ela aponta um problema provável, não dá um veredito. Se o resultado surpreender, rode o diagnóstico de novo em outro horário antes de mexer em qualquer coisa.
Por que isso importa para os assistentes
Os robôs que alimentam os assistentes visitam uma quantidade enorme de páginas e não podem esperar indefinidamente por cada uma. Um robô que busca uma resposta ao vivo, enquanto a pessoa aguarda no chat, tem ainda menos paciência. Se o seu site demora, a resposta pode sair com o site do concorrente, que respondeu primeiro.
Existe também um efeito acumulado. Um site lento tende a ser visitado com menos frequência, e as correções que você fizer no texto demoram mais para ser percebidas.
Como corrigir
A maior parte do tempo de resposta costuma vir de três lugares: redirecionamentos em cadeia, páginas geradas do zero a cada visita e hospedagem sobrecarregada.
Corte redirecionamentos em cadeia
Cada redirecionamento é uma viagem a mais. Um visitante que digita padariaestrela.com.br não deveria passar por http://, depois https://, depois https://www. até chegar à página. Configure um único redirecionamento direto para o endereço final. Você pode ver a cadeia com:
curl -sIL https://padariaestrela.com.br/ | grep -iE "^(HTTP|location)"
WordPress
WordPress monta cada página a cada visita, a não ser que exista cache. Um plugin de cache de página (há vários conhecidos, gratuitos e pagos) guarda o HTML pronto e costuma ser a correção de maior efeito. Desative plugins que você não usa: cada um acrescenta trabalho a cada visita. Se ainda assim o tempo ficar alto, o limite pode ser a hospedagem.
Wix, Shopify e Nuvemshop
Nessas plataformas o servidor é da própria empresa, e você não controla a infraestrutura. O que está nas suas mãos é o peso da página inicial: aplicativos e integrações instalados, vídeos de fundo, carrosséis com muitas imagens. Remova o que não traz resultado e teste de novo.
Next.js
Prefira páginas estáticas ou com revalidação periódica a páginas renderizadas do zero a cada visita. No App Router, uma página que não depende de dados da requisição pode ser gerada no build e servida do cache:
// Regenera a página no máximo uma vez por hora.
export const revalidate = 3600
Evite buscar dados lentos, como uma API externa sem cache, no caminho da página inicial.
Site próprio
Ponha uma CDN na frente do servidor, ative a compressão (gzip ou brotli) e guarde em cache as páginas que não mudam a cada visita. Meça o tempo do servidor isoladamente para saber se o gargalo é o código, o banco de dados ou a rede:
curl -o /dev/null -s -w "total: %{time_total}s\n" https://padariaestrela.com.br/
Como conferir depois de corrigir
Rode o comando acima algumas vezes, em horários diferentes, e veja se o tempo total fica abaixo de 1,2 segundo com folga. Depois rode o diagnóstico de novo: o detalhe da checagem mostra o tempo medido em milissegundos.
Perguntas frequentes
Meu site abre rápido no meu celular. Por que o Mecita mediu mais de 3 segundos?
O seu celular provavelmente já tem boa parte do site guardada em cache, e você está perto do servidor. O Mecita faz uma visita do zero, como um robô faria, e mede até o HTML chegar inteiro. Uma medição isolada também varia; se o resultado surpreender, rode de novo.
Esta checagem é a mesma coisa que o Core Web Vitals do Google?
Não. O Core Web Vitals mede a experiência de quem visita no navegador, com imagens, scripts e interação. Esta checagem mede só quanto tempo o servidor leva para entregar o HTML da página inicial, que é o que um robô de IA espera antes de ler.
E se o site demorar demais e não responder?
Se a página não chega dentro do limite de espera do diagnóstico, não há o que analisar, e o resultado mostra que não foi possível ler o site. Um robô de IA também desistiria, e esse costuma ser um problema mais urgente que qualquer outra checagem.