# Diagnóstico de experiencia de página

> Úselo cuando las Core Web Vitals fallan y necesita un brief priorizado para ingeniería.

## Rellena antes de ejecutar

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

## Prompt

```
Está diagnosticando problemas de experiencia de página y redactando un brief sobre el que ingeniería pueda actuar.

Plantilla o URL: {{URL}}
Datos de campo (CrUX o RUM: LCP, INP, CLS, desglosados por dispositivo): {{FIELD_DATA}}
Datos de laboratorio (resumen de Lighthouse o WebPageTest): {{LAB_DATA}}
Stack: {{STACK}}
Scripts de terceros conocidos: {{THIRD_PARTIES}}

Devuelva:
1. Una tabla de métricas: Métrica | Valor de campo | Umbral | Pasa o falla | Dispositivo donde va peor.
2. Para cada métrica que falla, las causas probables ordenadas por probabilidad, cada una con la evidencia de los datos facilitados que la respalda.
3. Una tabla de soluciones: Solución | Métrica afectada | Dirección esperada del cambio | Esfuerzo (S / M / L) | Riesgo de regresión | Quién lo hace.
4. "Mida esto para confirmarlo" - la comprobación exacta para cada solución.

Restricciones:
- Los datos de campo mandan sobre los de laboratorio. Cuando discrepen, diga en cuáles confía y por qué.
- No prediga una mejora numérica, por ejemplo "reducirá el LCP en 1,2 s". Indique dirección y razonamiento en su lugar.
- Señale cualquier solución que mejore la puntuación de laboratorio sin mejorar la experiencia real del usuario.
- Si un tercero de {{THIRD_PARTIES}} es una causa plausible, nómbrelo y diga cómo probarlo retirándolo.
```

## Cómo sacar mejor resultado

- Pegue siempre datos de campo: las puntuaciones de laboratorio por sí solas llevan a optimizar lo que no toca.
- Desglose por dispositivo antes de pegar, ya que los fallos de INP en móvil suelen tener otra causa que en escritorio.
- Pida que la comprobación de medición se añada al ticket para poder demostrar la mejora.

---

De la biblioteca de prompts de QuQi - https://www.quqi.io/es/prompts/page-experience-diagnosis