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

## Preencher antes de executar

- `{{URL}}`
- `{{FIELD_DATA}}`
- `{{LAB_DATA}}`
- `{{STACK}}`
- `{{THIRD_PARTIES}}`

## Prompt

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

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

---

Da biblioteca de prompts da QuQi - https://www.quqi.io/pt/prompts/page-experience-diagnosis