SEO
Diagnóstico de experiência de página
Use quando as Core Web Vitals estão a falhar e precisa de um briefing de engenharia priorizado.
page-experience-diagnosis.md
Está a diagnosticar problemas de experiência de página e a escrever um briefing sobre o qual os engenheiros possam agir.
Template ou URL: {{URL}}
Dados de campo (CrUX ou RUM: LCP, INP, CLS, divididos por dispositivo): {{FIELD_DATA}}
Dados de laboratório (resumo de Lighthouse ou WebPageTest): {{LAB_DATA}}
Stack: {{STACK}}
Scripts de terceiros conhecidos: {{THIRD_PARTIES}}
Devolva:
1. Uma tabela de métricas: Métrica | Valor de campo | Limiar | Passa ou falha | Dispositivo onde está pior.
2. Para cada métrica que falha, as causas prováveis ordenadas por probabilidade, cada uma com a evidência dos dados fornecidos que a sustenta.
3. Uma tabela de correções: Correção | Métrica afetada | Direção esperada da mudança | Esforço (S / M / L) | Risco de regressão | Quem faz.
4. "Meça isto para confirmar" - a verificação exata para cada correção.
Restrições:
- Os dados de campo prevalecem sobre os de laboratório. Quando divergirem, diga em qual está a confiar e porquê.
- Não preveja uma melhoria numérica, por exemplo "vai cortar 1,2s ao LCP". Indique direção e raciocínio.
- Assinale qualquer correção que melhore as pontuações de laboratório sem melhorar a experiência real do utilizador.
- Se algum terceiro em {{THIRD_PARTIES}} for causa plausível, nomeie-o e diga como testar removendo-o.
Preencher antes de executar
Substitua cada espaço pelos seus próprios dados. Quanto mais específico for, menos o modelo inventa.
- {{URL}}
- {{FIELD_DATA}}
- {{LAB_DATA}}
- {{STACK}}
- {{THIRD_PARTIES}}
Como obter um resultado melhor
-
1
Cole sempre dados de campo: só com pontuações de laboratório acaba a otimizar a coisa errada.
-
2
Divida por dispositivo antes de colar, já que as falhas de INP em mobile costumam ter causa diferente do desktop.
-
3
Peça que a verificação de medição fique no ticket para que a correção possa ser provada.