# تشخيص تجربة الصفحة

> استخدمه لما مؤشرات Core Web Vitals راسبة ومحتاج بريف هندسي مرتب حسب الأولوية.

## املأها قبل التشغيل

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

## البرومبت

```
أنت بتشخّص مشاكل تجربة الصفحة وبتكتب بريفًا يقدر المهندسون يشتغلوا عليه.

القالب أو الرابط: {{URL}}
بيانات ميدانية (CrUX أو RUM: LCP، INP، CLS، مقسمة حسب الجهاز): {{FIELD_DATA}}
بيانات معملية (ملخص Lighthouse أو WebPageTest): {{LAB_DATA}}
التقنيات المستخدمة: {{STACK}}
سكربتات الطرف الثالث المعروفة: {{THIRD_PARTIES}}

أخرج:
1. جدول مقاييس: المقياس | القيمة الميدانية | العتبة | نجاح أم رسوب | الجهاز الأسوأ فيه.
2. لكل مقياس راسب، الأسباب المرجّحة مرتبة حسب الاحتمال، كل واحد مع الدليل من البيانات المرفقة الذي يدعمه.
3. جدول إصلاحات: الإصلاح | المقياس المتأثر | اتجاه التغيير المتوقع | الجهد (S / M / L) | خطر الارتداد | من ينفّذه.
4. "قِس هذا للتأكيد" - الفحص الدقيق لكل إصلاح.

القيود:
- البيانات الميدانية تعلو على المعملية. لو اختلفتا، قل أيهما تصدّق ولماذا.
- لا تتنبأ بتحسّن رقمي، مثل "سيقلل LCP بمقدار 1.2 ثانية". اذكر الاتجاه والسبب بدلًا من ذلك.
- نبّه على أي إصلاح يحسّن الدرجات المعملية دون تحسين تجربة المستخدم الحقيقية.
- لو كان طرف ثالث في {{THIRD_PARTIES}} سببًا محتملًا، سمِّه واذكر كيف تختبر ذلك بإزالته.
```

## كيف تحصل على نتيجة أفضل

- الصق البيانات الميدانية دائمًا - الدرجات المعملية وحدها بتودّي لتحسين الحاجة الغلط.
- قسّم حسب الجهاز قبل اللصق، لأن رسوب INP على الموبايل عادة له سبب مختلف عن الديسكتوب.
- اطلب إضافة فحص القياس داخل التذكرة علشان الإصلاح يبقى قابل للإثبات.

---

من مكتبة برومبتات QuQi - https://www.quqi.io/ar/prompts/page-experience-diagnosis