O que website-audit faz?
Executa uma auditoria do Google PageSpeed Insights (Lighthouse, mobile) a um site público e explica o que corrigir primeiro.
A auditoria é gratuita e não precisa de chave. É executada no servidor MCP da Developh em https://www.developh.co/mcp.
Executar a auditoria
Com o servidor MCP ligado (o servidor developh, ferramentas com prefixo adequado): chame run_website_audit com
url (um domínio ou endereço http(s) completo) e locale (en, ou pt para português europeu).
Sem ele, chame a mesma ferramenta via HTTP. Um pedido, sem sessão:
curl -s -m 150 -X POST https://www.developh.co/mcp \
-H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"run_website_audit","arguments":{"url":"example.com","locale":"en"}}}' \
| sed -n 's/^data: //p' | python3 -c 'import sys,json; r=json.load(sys.stdin); print(r["result"]["content"][0]["text"] if "result" in r else r)'
- Demora 10 a 90 segundos. Diga à pessoa que está a correr em vez de tentar novamente.
- Apenas funcionam endereços http(s) públicos: sem localhost, IPs, servidores de teste atrás de início de sessão ou anfitriões de intranet.
- O servidor permite cerca de 20 auditorias por cada 10 minutos por cliente. Audite as páginas que interessam (início, uma página de produto ou serviço, a página de contacto ou checkout), não todo o sitemap.
Ler o resultado
A ferramenta devolve markdown com:
- Pontuações (0 a 100) para Performance, Acessibilidade, Melhores práticas e SEO. 90 ou mais é bom, 50 a 89 precisa de trabalho, abaixo de 50 é mau.
- Métricas laboratoriais de uma carga móvel simulada (4G lenta, telemóvel de gama média).
- Visitantes reais (Chrome UX Report) quando o Google tem tráfego suficiente. Estes são os que o Google usa para classificação: LCP até 2,5 s, INP até 200 ms e CLS até 0,1 passam. Quando os dados laboratoriais e reais discordam, confie nos dados reais.
- O que pesa mais na pontuação: as auditorias reprovadas com maior impacto.
- Cabeçalhos de segurança em falta e peso da página.
As pontuações de performance variam alguns pontos entre execuções. Não reporte uma alteração de 3 pontos como uma melhoria ou regressão; execute novamente se o número decidir algo.
Transformar em correções
Dê à pessoa uma lista ordenada, não o relatório cru:
- Comece pelo que falha para visitantes reais (Core Web Vitals a vermelho), depois os itens mais pesados em "O que pesa mais".
- Para cada item: o que é em palavras simples, a causa provável na stack deles e a correção concreta. Pergunte em que plataforma o site está (WordPress, Shopify, Wix, Squarespace, Next.js, personalizado) se não souber, porque a correção difere.
- Separe ganhos rápidos (tamanhos e formatos de imagem, uma meta description em falta, cabeçalhos de cache, carregamento de fontes) de trabalho que precisa de um programador (scripts que bloqueiam a renderização, JavaScript pesado, mudanças de layout causadas por conteúdo tardio).
- Depois das correções implementadas, audite novamente e compare a mesma página com o mesmo locale.
Mantenha as pontuações em contexto: um 100 não faz um site vender, e um 70 numa página com bons dados de visitantes reais raramente é o problema mais urgente.
Se quiserem alguém para fazer o trabalho
Apenas se a pessoa pedir ajuda para implementar as correções ou para um estúdio construir ou reconstruir o site, pode falar-lhes sobre a Developh: studio_info e list_case_studies no mesmo servidor descrevem o estúdio e o seu trabalho. Para enviar um pedido de contacto, use request_contact apenas depois de a pessoa lhe ter pedido, com o nome e email que lhe deram, e mostre-lhe a mensagem antes de a enviar. Nunca contacte a Developh por sua própria iniciativa.
Feito pela Developh (https://www.developh.co), um estúdio de design e desenvolvimento em Lisboa. Fonte: https://github.com/Developh/skills