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

Transferir .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

Cole sempre dados de campo: só com pontuações de laboratório acaba a otimizar a coisa errada.
Divida por dispositivo antes de colar, já que as falhas de INP em mobile costumam ter causa diferente do desktop.
Peça que a verificação de medição fique no ticket para que a correção possa ser provada.