# ما المقصود بـINP (التفاعل حتى الرسم التالي)؟

> يقيس INP (Interaction to Next Paint) سرعة استجابة الصفحة بصريًا للنقرات واللمسات والضغط على المفاتيح؛ والجيد هو 200 ميلي ثانية أو أقل.

URL: https://yes-seo.com/ar/glossary/inp

**التفاعل حتى الرسم التالي (Interaction to Next Paint — INP)** يقيس الزمن الذي تستغرقه الصفحة لتُظهر ردًا بصريًا بعد أن ينقر أحدهم أو يلمس أو يضغط مفتاحًا. وقد أصبح أحد [مؤشرات الويب الأساسية](https://yes-seo.com/ar/glossary/core-web-vitals) في مارس 2024 بدلًا من First Input Delay، ويجيب عن سؤال بسيط: حين أفعل شيئًا، هل تتفاعل الصفحة فورًا؟

## كيف يُقاس

لكل تفاعل، يقيس المتصفح ثلاث مراحل حتى الإطار التالي المرسوم:

- **تأخر الإدخال** — الخيط الرئيسي (main thread) مشغول بعمل آخر، فيضطر معالج الحدث إلى الانتظار.

- **زمن المعالجة** — تعمل معالجات الأحداث لديك.

- **تأخر العرض** — يعيد المتصفح حساب الأنماط والتخطيط ويرسم النتيجة.

ثم يبلّغ INP عن أحد أبطأ التفاعلات في الزيارة كلها؛ وفي الصفحات الكثيرة التفاعلات يتجاهل قيمة شاذة واحدة لكل 50 تفاعلًا. لذا قد تحدد قائمة واحدة متثاقلة درجتك كلها. ولا يُحتسب التمرير ولا تمرير المؤشر (hover). التفاصيل الكاملة في [web.dev: INP](https://web.dev/articles/inp).

## الحدود

الجيد هو **200 ms أو أقل**، والضعيف **أكثر من 500 ms**، عند المئين 75 من الزيارات الفعلية. وكان حدّ FID هو 100 ms، لكنه كان يقيس الانتظار قبل بدء أول معالج فقط، وهو ما تجتازه تقريبًا كل المواقع. أما INP فأشد صرامة وأقرب بكثير إلى ما يشعر به المستخدمون.

## ما الذي يبطّئ INP

- **المهام الطويلة (Long tasks)** — أي جافاسكربت يحجب الخيط الرئيسي أكثر من 50 ms. ومن المتسببين المتكررين ترطيب (hydration) الأطر البرمجية وحزم التحليلات الكبيرة وسكربتات اختبارات A/B.

- **معالجات ثقيلة** تفعل كل شيء بشكل متزامن — تصفية 5,000 صف أو إعادة عرض صفحة كاملة — قبل أن تدع المتصفح يرسم.

- **DOM ضخم جدًا**، فتصبح كل عملية أنماط وتخطيط مكلفة.

- **وسوم الأطراف الثالثة** المحمّلة مبكرًا والمتنافسة على الخيط الرئيسي؛ راجع [الموارد المعطِّلة للعرض](https://yes-seo.com/ar/glossary/render-blocking).

## مثال: استجب أولًا ثم اعمل

```
button.addEventListener('click', async () => {
  showSpinner();                 // أظهر ردًا مرئيًا أولًا
  await scheduler.yield();       // دع المتصفح يرسم
  applyFilters();                // العمل الثقيل بعد ذلك
});
```

تُدعم `scheduler.yield()` في المتصفحات المبنية على Chromium؛ وحيث لا تُدعم، ينشئ `await new Promise(r => setTimeout(r, 0))` فاصلًا مشابهًا. فيرى المستخدم ردًا فورًا، ويجري العمل المكلف في مهمة لاحقة.

## أخطاء شائعة

- **الاعتماد على Lighthouse وحده.** لا تستطيع تجربة المختبر النقر على أزرارك، لذا تعرض زمن الحجب الكلي (Total Blocking Time) بديلًا. أما INP الحقيقي فيأتي من بيانات الميدان.

- **فحص الصفحة الرئيسية فقط**، بينما توجد أبطأ التفاعلات في المرشحات والسلات ومربعات البحث والنماذج.

- **تحميل كل السكربتات مقدمًا**، ومنها أدوات الدردشة وخرائط الحرارة التي لا يستخدمها أحد في الثواني الأولى. حمّلها عند الطلب أو بعد استقرار الصفحة.

- **تجاهل الهواتف متوسطة الأداء.** فمعالج يستغرق 40 ms على حاسوب المطوّر قد يستغرق أضعاف ذلك على هاتف أندرويد اقتصادي.

## افحصه

تعرض [أداة اختبار سرعة الصفحة](https://yes-seo.com/ar/page-speed-test) قيمة INP الميدانية من Google PageSpeed Insights حين يملك الرابط زيارات Chrome كافية، إضافة إلى عدد السكربتات في الصفحة وحجمها — وهو عادةً أول ما يستحق التقليص.

## الأسئلة الشائعة

### لماذا لا توجد بيانات INP لصفحتي؟

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

### هل يؤثر INP في السيو؟

INP أحد مؤشرات الويب الأساسية التي تستخدمها أنظمة الترتيب في جوجل ضمن تجربة الصفحة. وتأثيره متواضع مقارنة بالصلة، لكن ضعف الاستجابة يضر التحويلات مباشرةً أيضًا.

### ما الفرق بين INP وزمن الحجب الكلي (Total Blocking Time)؟

زمن الحجب الكلي مقياس مختبر يجمع حجب الخيط الرئيسي أثناء تحميل الصفحة. أما INP فمقياس ميداني مبني على تفاعلات حقيقية. TBT بديل مفيد عند الاختبار، لكن بيانات الميدان وحدها تُظهر INP الفعلي لديك.