التفاعل حتى الرسم التالي (INP)

الخلاصة — يقيس INP سرعة استجابة صفحتك عندما ينقر شخص أو يلمس أو يكتب. يحسب المتصفح الزمن بين التفاعل والتحديث المرئي التالي طوال الزيارة، ويبلغ قيمة تقارب أسوأ تفاعل. أقل من 200 ms جيد، وأكثر من 500 ms ضعيف. وهو واحد من مؤشرات Core Web Vitals الثلاثة، وقد حل عام 2024 محل مقياس أقدم اسمه First Input Delay.

ما الذي يقيسه INP فعلًا؟

عندما تنقر زرًا أو تلمس قائمة أو تكتب في حقل، تتوقع أن تستجيب الصفحة: تفتح قائمة أو تتحدد خانة أو يظهر نص. يقيس التفاعل حتى الرسم التالي (INP) مدة ذلك، من لحظة التفاعل حتى يرسم المتصفح الإطار التالي الذي يظهر التغيير.

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

لا تدخل التمرير والتحويم والتكبير في الحساب. تُقاس النقرات واللمسات وتفاعلات لوحة المفاتيح فقط.

الحدود

يُبلغ INP بالميلي ثانية، وتقسمه Google إلى ثلاثة تقييمات:

• جيد: 200 ms أو أقل
• يحتاج إلى تحسين: أكثر من 200 ms وحتى 500 ms
• ضعيف: أكثر من 500 ms

للسياق، 200 ms سريع، لكنه لا يترك هامشًا كبيرًا. يجب أن ينجز كل ما تفعله الشفرة استجابة للنقرة، إضافة إلى رسم المتصفح للنتيجة، ضمن هذه المدة.

لماذا حل محل FID؟

كان مقياس الاستجابة السابق هو First Input Delay (FID). لم يقس FID إلا التأخر قبل بدء معالجة أول تفاعل في الصفحة، وتوقف التوقيت لحظة بدء العمل. فلم يحتسب مدة العمل نفسه ولا زمن تحديث الشاشة.

عالج INP هذه النقائص. فهو يقيس الزمن الكامل من البداية حتى التحديث المرئي لكل التفاعلات، لا الأول وحده. اعتمدت Google الانتقال رسميًا في 12 مارس 2024، وأزيل FID من الأدوات تمامًا بحلول سبتمبر 2024. Evidence for this claim INP observes click, tap, and keyboard interaction latency throughout a page visit rather than measuring only the first input delay. Scope: Current web.dev INP definition and qualifying interaction types. Confidence: high · Verified: 2026-07-14 web.dev: Interaction to Next Paint

ما الذي يجعل INP ضعيفًا، ببساطة؟

غالبًا تكون المشكلة استئثار JavaScript بالمسار الرئيسي. لا يستطيع المتصفح تنفيذ أكثر من عمل واحد عليه في الوقت نفسه؛ فإذا كانت كتلة شفرة تعمل، انتظرت نقرتك في الطابور. ومن المسببات الشائعة:

• عمل ثقيل داخل معالج النقر أو اللمس نفسه.
• «مهام طويلة» كبيرة من JavaScript تحجب كل شيء.
• نصوص برمجية خارجية للتحليلات وموافقات ملفات الارتباط والدردشة وإدارة الوسوم. وهي من أسوأ المسببات حتى في مواقع المحتوى البسيطة.

الحل العام هو تقليل العمل عند التفاعل وتقسيم الأعمال الكبيرة إلى أجزاء صغيرة كي يستطيع المتصفح إدخال التفاعل بينها.

هل تريد الآلية الفعلية، وتقسيم زمن الاستجابة إلى ثلاثة أجزاء، وحساب المئين 75، وطريقة إصلاح كل سبب، وأثر SEO؟ انتقل إلى تبويب Advanced.

الخلاصة — INP هو Core Web Vital الخاص بالاستجابة. يراقب زمن كل تفاعلات النقر واللمس ولوحة المفاتيح خلال الزيارة، ويبلغ القيمة عند المئين 75 مع إسقاط قيمة شاذة لكل 50 تفاعلًا، لا الإدخال الأول وحده كما فعل FID. زمن التفاعل = تأخر الإدخال + مدة المعالجة + تأخر العرض. الجيد ≤ 200 ms والضعيف > 500 ms وفق بيانات الحقل عند p75. حل محل FID في 12 مارس 2024، وأزيل FID من الأدوات في سبتمبر 2024. أصلحه بتقسيم المهام الطويلة وإتاحة المسار الرئيسي عبر scheduler.yield() وتقليل عمل معالجات الأحداث وحجم DOM وتأجيل النصوص الخارجية. إنه مقياس ميداني، وTotal Blocking Time بديله المختبري، وقد لا يتفقان.

ما الذي يقيسه INP، وكيف يختلف عن FID؟

تعريف Google دقيق: INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (ترجمة) «يقيّم استجابة الصفحة العامة لتفاعلات المستخدم برصد زمن كل تفاعلات النقر واللمس ولوحة المفاتيح طوال زيارة المستخدم». Evidence for this claim INP observes click, tap, and keyboard interaction latency throughout a page visit rather than measuring only the first input delay. Scope: Current web.dev INP definition and qualifying interaction types. Confidence: high · Verified: 2026-07-14 web.dev: Interaction to Next Paint عبارة «كل التفاعلات طوال الزيارة» هي جوهر الأمر. INP مقياس على مستوى الزيارة لا وقت التحميل، ومنطق Google أن معظم وقت المستخدم في الصفحة يأتي بعد تحميلها، لذا تكون الاستجابة أثناء الاستخدام أهم من الانطباع الأول وحده.

توضح المقارنة مع First Input Delay الفكرة: “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (ترجمة) «قاس FID تأخر الإدخال لأول تفاعل فقط، بينما يحسنه INP برصد كل التفاعلات من تأخر الإدخال حتى تشغيل معالجات الأحداث». قاس FID انتظار معالج تفاعل واحد وتجاهل مدة المعالج وزمن تحديث الشاشة؛ أما INP فيقيس الزمن الكامل لكل تفاعل.

هناك تفصيل مهم لأن خرافة شائعة تخطئه: لا يمثل INP أسوأ تفاعل حرفيًا. كي لا يعاقب الصفحة على قفزة عشوائية واحدة، يسقط المتصفح قيمة شاذة لكل 50 تفاعلًا، ثم يبلغ القيمة عند المئين 75 من مشاهدات الصفحة. في الزيارة قليلة التفاعلات تكون هذه أبطأ قيمة، وفي الزيارة الكثيفة تُستبعد أولًا قيمتان شاذتان مثلًا.

كما أن نطاق التفاعل أضيق مما يظنه الناس. تُقاس النقرات واللمسات وضغطات المفاتيح فقط، بينما تُستبعد التمرير والتحويم والتكبير صراحة. وقد تطلق إيماءة واحدة أحداثًا عدة؛ فاللمسة تنتج pointerdown وpointerup وclick، ويجمعها INP في تفاعل واحد لا ثلاثة. وداخل المجموعة يأخذ أطول مدة لحدث فردي لا مجموعها؛ فإذا كان pointerdown سريعًا وclick بطيئًا أُبلغ تفاعل واحد بحجم الحدث البطيء. وإذا لم تقع تفاعلات مؤهلة في الزيارة فلا يُبلغ INP للصفحة.

الأجزاء الثلاثة لزمن التفاعل

ينقسم زمن كل تفاعل إلى ثلاثة أجزاء متتابعة. احتفظ بهذا النموذج لأن كل جزء يشير إلى إصلاح مختلف:

Interaction latency = Input delay + Processing duration + Presentation delay

1. تأخر الإدخال: الوقت قبل أن تبدأ معالجات الأحداث، وغالبًا لأن المسار الرئيسي مشغول بإنهاء مهمة طويلة.
2. مدة المعالجة: وقت تنفيذ كل استدعاءات معالج الحدث.
3. تأخر العرض: الوقت من انتهاء المعالجات حتى رسم المتصفح الإطار التالي على الشاشة.

يكشف إصدار الإسناد من web-vitals الأجزاء الثلاثة (inputDelay وprocessingDuration وpresentationDelay) لتعرف المهيمن في تفاعل حقيقي. ووفق بيانات Web Almanac لعام 2024 يكون تأخر العرض غالبًا أكبر جزء منفرد عند الوسيط، لكن مدة المعالجة هي موضع التحسين غالبًا لأنها تتضخم في الصفحات السيئة البناء.

الحدود وقيد بيانات الحقل عند p75

تحدد Google Search Central الهدف بوضوح: “an INP of less than 200 milliseconds” (ترجمة) «قيمة INP أقل من 200 ميلي ثانية»، وتقول عن البرنامج كله: “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (ترجمة) «نوصي بشدة أن يحقق مالكو المواقع Core Web Vitals جيدة للنجاح في البحث». ميزانية 200 ms ضيقة فعلًا عندما تتذكر أن المتصفح يريد إطارًا كل نحو 16,7 ms عند 60 fps؛ فيجب أن ينجز عمل المعالج والعرض ضمنها. Evidence for this claim INP is good at 200 milliseconds or less and poor above 500 milliseconds, assessed at the 75th percentile. Scope: Current web.dev INP thresholds for field measurement. Confidence: high · Verified: 2026-07-14 web.dev: Interaction to Next Paint

لماذا INP مقياس ميداني، ولماذا لا تكفي بيانات المختبر؟

هذا فخ يقع فيه كثير من مختصي SEO: نتيجة Lighthouse خضراء لا تعني INP جيدًا. لكن عبارة «لا يستطيع Lighthouse قياس INP» تحتاج إلى ثلاث حالات منفصلة حتى لا تسيء قراءة الأدوات:

1. لا يبلغ تشغيل Lighthouse القياسي غير التفاعلي أي INP. فهو يراقب تحميل الصفحة ولا ينقر أو يلمس أو يكتب، لذلك لا يوجد تفاعل لتوقيته. ويستخدم Total Blocking Time (TBT) بديلًا عند التحميل. تقول Google: “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (ترجمة) «لارتباط TBT جيدًا بـINP، قد تشير قيمة TBT المرتفعة إلى قيم INP مرتفعة أثناء التحميل». المهم هو أثناء التحميل. لا يقول TBT شيئًا عن تفاعل يبطؤ بعد عشر ثوان عندما تعمل أداة مؤجلة؛ إنه بديل لا معادلة تحويل.
2. ينتج التفاعل المنفذ يدويًا أو اصطناعيًا زمنًا فعليًا شبيهًا بـINP لذلك التفاعل. يفيد النقر على زر في DevTools أو برمجة نقرة في إعادة خلل محدد، لكنه يظل مسارًا واحدًا على جهاز واحد، ولا يمثل مزيج الأجهزة والمستخدمين والأهداف وعمر الزيارة في الحقل. تقول Google إن القيمة “will be dependent on what interactions are performed during the measurement period” (ترجمة) «تعتمد على التفاعلات المنفذة خلال فترة القياس»، وسلوك المستخدم متغير أكثر من أن يمثله تشغيل مختبري واحد.
3. توزيع الحقل هو INP الفعلي. لذلك المصدر المعتمد هو بيانات الحقل من Chrome User Experience Report (CrUX) المعروضة في PageSpeed Insights وتقرير Core Web Vitals في Search Console. تقول Google: “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (ترجمة) «بيانات الحقل أفضل مصدر لفهم التفاعلات المسببة للمشكلات للمستخدمين الفعليين».

استخدم المختبر في الحالتين 1 و2 لاكتشاف التفاعل البطيء وإعادة إنتاجه، واستخدم الحقل في الحالة 3 لتأكيد أثره الفعلي في نتائج الزوار.

لماذا تكون نتيجة INP ضعيفة؟

ترجع كل مشكلات INP تقريبًا إلى حجب المسار الرئيسي عند تفاعل المستخدم. وهذه المسببات المعتادة:

• المهام الطويلة. كل مهمة على المسار الرئيسي تتجاوز 50 ms مهمة طويلة، وما فوق 50 ms هو «فترة الحجب». لا يمكن معالجة التفاعل أثناءها، وهي أكبر سبب منفرد.
• معالجات الأحداث الثقيلة. يرفع العمل المتزامن الزائد داخل معالج النقر أو الإدخال مدة المعالجة مباشرة.
• DOM كبير. تكلف الأشجار الأكبر عرضًا أكثر، فتزيد تأخر الإدخال والعرض.
• النصوص الخارجية. وفق Web Almanac، تعد أدوات الموافقة وإدارة الوسوم والتحليلات والدردشة من أبرز المسببات حتى في مواقع المحتوى البسيطة، وهي أول ما أفحصه في صفحة لم أبنها.
• JavaScript بعد التحميل. لا يعني رسم الصفحة اكتمال تحميلها؛ فقد تحجب النصوص المقيمة بعد الرسم الأول التفاعلات المبكرة.

كيف تصلحه؟

الاستراتيجيات، بترتيب تقريبي للأثر:

1. قسّم المهام الطويلة. جوهر نصيحة Google للمعالجات هو “do as little work as possible in them” (ترجمة) «نفّذ أقل قدر ممكن من العمل داخلها». قسّم العمل الكبير إلى مهام أصغر كي يدرج المتصفح تفاعل المستخدم بينها. وعند تقسيمها، “the browser can respond to higher-priority work much sooner — including user interactions.” (ترجمة) «يستطيع المتصفح الاستجابة للعمل الأعلى أولوية أسرع بكثير، ومنه تفاعلات المستخدم».

2. أفسح المجال للمسار الرئيسي. الطريقة الحديثة الموصى بها هي scheduler.yield() في Chrome 129+ وFirefox 142+: يوقف await scheduler.yield() شفرتك مؤقتًا ليتولى المتصفح العمل المعلق ثم يستأنفها بأولوية، فلا تتجاوزها مهام أخرى. البديل التقليدي setTimeout(..., 0) يعمل لكنه يضع الشفرة في آخر طابور المهام، وتفرض المتصفحات حدًا أدنى 5 ms بعد استدعاءات متداخلة عدة. توقف عن استخدام isInputPending()؛ إذ تقول Google: “we no longer recommend using this API.” (ترجمة) «لم نعد نوصي باستخدام API هذه». راجع تبويب Scripts للنمط.

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

4. تجنب تخبط التخطيط. قراءة خصائص التخطيط بعد كتابة الأنماط مباشرة في المهمة نفسها تجبر المتصفح على تخطيط متزامن كان يستطيع جمعه. اجمع القراءات ثم الكتابات.

5. قلّل حجم DOM. تُعرض الأشجار الأصغر أسرع. يستطيع content-visibility عرض العناصر خارج الشاشة عند الحاجة حتى لا تكلف أثناء التحميل أو التفاعل.

6. دقق النصوص الخارجية وأجّلها. هذا أعلى إصلاح أثرًا في SEO على المواقع الحقيقية. حمّل نصوص الموافقة والوسوم والتحليلات عند الحاجة أو اربطها بالتفاعل أو انقلها عن المسار الحرج. قد تفشل صفحة محتوى «خفيفة» في INP بسبب أداة مضمّنة ثقيلة وحدها.

هل يؤثر INP في الترتيب؟

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

نقطتان عمليتان في SEO. أولًا، الجوال هو القياس الأصعب. في Web Almanac لعام 2024 اجتاز نحو 74% من مواقع الجوال INP مقابل نحو 97% على سطح المكتب، وبما أن Google تفهرس للجوال أولًا فالرقم المتنقل هو المهم. ثانيًا، المواقع المعقدة أسوأ: اجتاز نحو 53% فقط من أكبر 1 000 موقع، لأن الصفحات الغنية بالميزات ترسل JavaScript أكثر يحجب المسار الرئيسي. تطوير الميزات الثقيلة خطر على INP، وتكون صفحات المنتجات والدفع والبحث والنماذج أشد تعرضًا من المحتوى الثابت.

INP مقابل FID: الصورة الكاملة

انتهى FID؛ أزيل من Search Console يوم إطلاق INP، ومن BigQuery وAPI في CrUX بحلول سبتمبر 2024. إذا ظلت أداة أو عملية تدقيق تشير إلى FID فهي قديمة.

حالات طرفية تجعل بيانات INP تختلف

تفسر بعض خصائص دورة الحياة معظم أسئلة «لماذا لا يطابق RUM لدي CrUX؟»:

• لا تفاعل، لا INP. إذا لم تتضمن الزيارة نقرة أو لمسة أو ضغطة مفتاح، أو لم تتضمن إلا إيماءات مستبعدة كالتمرير والتحويم، فلا توجد قيمة INP لمشاهدة الصفحة. هذا طبيعي في صفحات القراءة وليس خللًا في المراقبة.
• تدخل iframes في المقياس، لكن JavaScript لديك لا ترى داخلها. يسهم التفاعل داخل iframe مضمنة، مثل إعلان أو أداة أو نموذج، في INP للصفحة. لكن نص RUM من الطرف الأول لا يستطيع قراءة أحداث iframe عابرة للأصول كما يفعل مقياس المتصفح، لذلك قد يختلف CrUX وRUM من الأصل نفسه بصورة مشروعة في الصفحات ذات التضمينات الخارجية. وثق الفجوة بدل اعتبارها خللًا.
• تعيد الاستعادة من bfcache قيمة INP إلى الصفر. تبدأ الصفحة المستعادة من ذاكرة الرجوع والتقدم عدًا جديدًا، ولا تنتقل تفاعلات ما قبل المغادرة.
• يجب أن تبلغ علامات التبويب الطويلة العمر أو الموجودة في الخلفية. قد تبقى علامة مفتوحة ساعات دون unload، ولا سيما على الجوال حيث قد يقتلها النظام؛ لذلك التقط INP عند إخفاء الصفحة لا عند unload وحده. ستفقد إعدادات RUM التي لا ترسل إلا عند unload هذه الزيارات بصمت.

موقع INP ضمن الصورة

INP جزء من Core Web Vitals إلى جانب Largest Contentful Paint للتحميل وCumulative Layout Shift للاستقرار المرئي. افحصه في PageSpeed Insights وتقرير Search Console الميداني، وشخصه في Lighthouse وChrome DevTools مختبريًا عبر بديل TBT. وتأتي البيانات الأساسية من CrUX.

ملخص الذكاء الاصطناعي

خلاصة مكثفة من النسخة المتقدمة:

• INP هو Core Web Vital للاستجابة. يراقب زمن كل تفاعلات النقر واللمس ولوحة المفاتيح خلال الزيارة ويبلغ القيمة عند المئين 75، مع إسقاط قيمة شاذة لكل 50 تفاعلًا، لا الإدخال الأول كما فعل FID.
• الزمن = تأخر الإدخال + مدة المعالجة + تأخر العرض. يشير كل جزء إلى إصلاح مختلف، وغالبًا تكون مدة المعالجة موضع الأثر الأكبر.
• الحدود ميدانيًا عند p75: جيد ≤ 200 ms، يحتاج إلى تحسين ≤ 500 ms، وضعيف > 500 ms.
• تدخل النقرات واللمسات ولوحة المفاتيح فقط؛ وتستبعد التمرير والتحويم والتكبير، وتجمع أحداث الإيماءة الواحدة كتفاعل واحد.
• حل محل FID في 12 مارس 2024، وأزيل FID من الأدوات في سبتمبر 2024؛ إذ لم يقس سوى تأخر الإدخال الأول.
• إنه مقياس ميداني، وعبارة «Lighthouse لا يقيسه» لها ثلاث حالات: التشغيل القياسي غير التفاعلي لا يبلغ INP ويستخدم Total Blocking Time بديل تحميل؛ والتفاعل المختبري المنفذ يدويًا ينتج زمنًا حقيقيًا لتفاعل واحد لكنه لا يمثل الحقل؛ وبيانات CrUX وPageSpeed Insights وSearch Console الميدانية وحدها معتمدة.
• الأسباب: مهام طويلة (>50 ms)، ومعالجات ثقيلة، وDOM كبير، ولا سيما النصوص الخارجية.
• الإصلاحات: تقسيم المهام وإتاحة المسار عبر scheduler.yield() مع بديل setTimeout وعدم التوصية بـisInputPending()، وتقليل عمل المعالجات ومنع تخبط التخطيط وتقليل DOM وتأجيل النصوص الخارجية.
• الحالات الطرفية: لا تفاعل مؤهل يعني لا قيمة؛ وتفاعلات iframe تدخل المقياس ولا يراها RUM من الأصل نفسه؛ وتعيد bfcache العد؛ وينبغي الإبلاغ عند الإخفاء.
• SEO: إشارة ترتيب خفيفة. الجوال، بنحو 74% اجتياز مقابل 97% لسطح المكتب، هو المهم مع الفهرسة للجوال أولًا، والصفحات كثيرة التفاعل أشد تعرضًا.

الوثائق الرسمية

وثائق من المصادر الأولية لدى Google وفريق Chrome.

web.dev: مراجع INP

• Interaction to Next Paint (INP) — التعريف المعتمد والأنواع والأجزاء الثلاثة والحدود.
• Optimize Interaction to Next Paint — دليل تقليل عمل المعالجات وتأجيل غير الضروري وتخبط التخطيط وحجم DOM وcontent-visibility.
• Interaction to Next Paint officially becomes a Core Web Vital — إعلان 12 مارس 2024 وجدول إيقاف FID.
• First Input Delay (FID) — المقياس المتقاعد وسبب استبداله.
• مقياس استجابة جديد: نطلب ملاحظاتكم — قيود تصميم FID وتحسينات INP.
• Optimize long tasks — تعريف 50 ms وscheduler.yield() وبديل setTimeout وسبب عدم التوصية بـisInputPending().
• تقييم النصوص البرمجية والمهام الطويلة — TBT بديلًا لـINP وإرشاد حجم النصوص.
• Find slow interactions in the field — إصدار الإسناد من web-vitals وLong Animation Frames (LoAF).

Chrome وبحث Google

• مرجع ميزات الأداء في Chrome DevTools — مسار Interactions وLive Metrics وتحذير 200 ms.
• ملاحظات إصدار CrUX — تأكيد إزالة FID من BigQuery وAPI في سبتمبر 2024.
• Core Web Vitals ونتائج بحث Google — INP ضمن إشارة تجربة الصفحة وهدف ≤ 200 ms.

اقتباسات من المصدر

تصريحات موثقة من Google وفريق Chrome. ينتقل كل رابط إلى المقطع المقتبس في الصفحة الأصلية.

ما يقيسه INP واختلافه عن FID

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (ترجمة) «INP مقياس من Core Web Vitals يقيّم استجابة الصفحة العامة برصد زمن كل تفاعلات النقر واللمس ولوحة المفاتيح طوال زيارة المستخدم». — web.dev. الانتقال إلى الاقتباس
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (ترجمة) «قاس FID تأخر الإدخال لأول تفاعل فقط، ويحسنه INP برصد كل التفاعلات حتى تشغيل المعالجات». الانتقال إلى الاقتباس
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (ترجمة) «لم يعد FID من Core Web Vitals، وحل محله INP». الانتقال إلى الاقتباس

الانتقال من FID إلى INP

• “FID will be deprecated.” (ترجمة) «سيُوقف FID». — Jeremy Wagner وRick Viscomi. الانتقال إلى الاقتباس
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (ترجمة) «سيزال FID من Google Search Console فور اعتماد INP في 12 مارس». الانتقال إلى الاقتباس

المهام الطويلة: السبب الرئيسي

• “Any task that takes longer than 50 milliseconds is a long task.” (ترجمة) «كل مهمة تتجاوز 50 ميلي ثانية مهمة طويلة». — web.dev. الانتقال إلى الاقتباس

بيانات الحقل هي الأساس

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (ترجمة) «بيانات الحقل أفضل مصدر لفهم التفاعلات المسببة للمشكلات للمستخدمين الفعليين». — web.dev. الانتقال إلى الاقتباس

بحث Google

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (ترجمة) «نوصي بشدة أن يحقق مالكو المواقع Core Web Vitals جيدة للنجاح في البحث». — Google Search Central. المصدر

قائمة تحقق لإصلاح INP

اعمل من الأعلى إلى الأسفل؛ فالعناصر الأولى تحرك الرقم عادة أكثر:

• اجلب INP الميداني من PageSpeed Insights أو تقرير Core Web Vitals في Search Console، لا نتيجة مختبرية وحدها، وافحص الجوال منفصلًا.
• حدد التفاعلات البطيئة بإصدار الإسناد من web-vitals أو مسار Interactions في Chrome DevTools، الذي يميز ما يتجاوز 200 ms.
• اعثر على المهام الطويلة فوق 50 ms على المسار الرئيسي وقسّمها.
• أفسح المجال للمسار الرئيسي داخل الحلقات الطويلة باستخدام scheduler.yield() وبديل setTimeout(..., 0). توقف عن isInputPending().
• داخل كل معالج، شغّل تحديث العرض الضروري فقط بصورة متزامنة، وأجّل الحفظ والتحقق والتدقيق والتحليلات خلف rAF وsetTimeout.
• تحقق من تخبط التخطيط عند قراءة التخطيط مباشرة بعد كتابة الأنماط؛ اجمع القراءات ثم الكتابات.
• دقق النصوص الخارجية للموافقة وإدارة الوسوم والتحليلات والدردشة؛ أجّلها أو حمّلها عند الحاجة أو اربطها بالتفاعل.
• قلّل DOM وطبق content-visibility على الأقسام خارج الشاشة.
• أجّل JavaScript غير الضرورية أو قسّم شفرتها حتى لا تحجب النصوص اللاحقة للتحميل التفاعلات المبكرة.
• أعد القياس ميدانيًا بعد النشر؛ CrUX نافذة متحركة من 28 يومًا فتتغير النتيجة ببطء.

INP مقابل FID: ورقة مرجعية

حقائق سريعة

• الحدود ميدانيًا عند p75: جيد ≤ 200 ms · يحتاج إلى تحسين ≤ 500 ms · ضعيف > 500 ms.
• المحتسب: النقر واللمس ولوحة المفاتيح. المستبعد: التمرير والتحويم والتكبير.
• الزمن = تأخر الإدخال + مدة المعالجة + تأخر العرض.
• المهمة الطويلة هي كل مهمة على المسار الرئيسي > 50 ms.
• البديل المختبري Total Blocking Time، وهو مرتبط لكنه يعكس حجب وقت التحميل فقط. المصدر المعتمد بيانات الحقل من CrUX.
• معدل اجتياز الجوال، نحو 74%، أدنى كثيرًا من سطح المكتب، نحو 97%، والجوال هو المهم.

إتاحة المسار الرئيسي

عندما تكون لديك حلقة طويلة، كعرض قائمة كبيرة أو معالجة بيانات عند النقر، أعد التحكم دوريًا إلى المتصفح كي يخدم تفاعلًا معلقًا. API الحديثة هي scheduler.yield()، مع الرجوع إلى setTimeout حيث لا تُدعم.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

ملاحظات:

• يعيد scheduler.yield() وعدًا يُحل في مهمة مستقبلية، وتحظى متابعته بالأولوية فلا تتقدم مهام أخرى على الشفرة المستأنفة.
• يعمل setTimeout(..., 0) في كل مكان لكنه يدفع المتابعة إلى آخر الطابور، وتفرض المتصفحات حدًا يقارب 5 ms بعد استدعاءات متداخلة عدة.
• لا تستخدم isInputPending()؛ إذ تقول Google إنها “no longer recommend[s] using this API.” (ترجمة) «لم تعد توصي باستخدام API هذه».

أجّل العمل غير الضروري في المعالج

نفذ فقط ما يحتاجه الإطار التالي، وادفع الباقي إلى ما بعد الرسم.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

أدوات قياس INP وإصلاحه

الحقل، وهو المصدر المعتمد الذي تقيمه Google

• PageSpeed Insights: يعرض INP الميداني من CrUX للرابط أو الأصل، مفصولًا بين الجوال وسطح المكتب، مع تشخيص مختبري.
• Search Console، تقرير Core Web Vitals: حالة INP عبر الروابط مجمعة حسب المشكلة من بيانات الحقل.
• CrUX: مجموعة بيانات Chrome User Experience Report الأساسية، ويمكن الاستعلام عنها عبر API وBigQuery.

المختبر والتشخيص

• Chrome DevTools، لوحة Performance: يوقت مسار Interactions تأخر الإدخال والمعالجة والعرض لكل تفاعل ويميز ما يتجاوز 200 ms، وتتحدث Live Metrics أثناء النقر.
• Lighthouse: لا يقيس INP مباشرة، ويبلغ Total Blocking Time بديلًا مختبريًا.

مراقبة المستخدم الحقيقي (RUM)

• مكتبة web-vitals في JavaScript: توفر onINP() للقيمة، ويكشف إصدار الإسناد (web-vitals/attribution) قيم inputDelay وprocessingDuration وpresentationDelay ومحدد interactionTarget وإدخالات LoAF لمعرفة النص والعنصر المسببين. وثق معدل أخذ العينات وتغطية الإسناد؛ فلا تقارن رقم RUM بلا هذا السياق مع p75 في CrUX، ولا يستطيع RUM رؤية iframe عابرة للأصول كما يفعل المقياس المجمع.

كيف تسجل الأدوات نفسها؟

مثال مباشر للمقياس الذي تشرحه الصفحة: خدمات معروفة لسرعة الصفحات والمراقبة مرتبة وفق INP الحقيقي لمستخدمي الجوال من بيانات Chrome UX Report الميدانية:

إصلاحات INP التي تخطئ الهدف غالبًا

تحسين التفاعل الأول فقط

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

معاملة Total Blocking Time على أنه النتيجة

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

نقل العمل كله إلى استدعاء مؤجل واحد

قد ينقل تأجيل كتلة كبيرة التجمد فقط. قسّم العمل إلى مهام أصغر وأفسح المجال للمسار الرئيسي كي يرسم المتصفح بينها.

إزالة التغذية الراجعة المرئية لتقصير المعالج

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

تشخيص INP بنموذج الأجزاء الثلاثة

لكل تفاعل بطيء ثلاثة مواضع للفحص:

1. تأخر الإدخال: انتظر الحدث لأن عملًا سابقًا على المسار الرئيسي ظل يعمل. دقق المهام الطويلة وJavaScript الخارجية قبل بدء المعالج.
2. مدة المعالجة: نفذ معالج الحدث عملًا زائدًا. قلّل العمل المتزامن وقسّم الحلقات وأجّل ما لا يحتاجه الإطار التالي.
3. تأخر العرض: استغرقت الأنماط أو التخطيط أو الرسم وقتًا طويلًا بعد المعالج. قلّل تعقيد DOM وتجنب فرض حسابات التخطيط المتكررة.

ابدأ بأكبر مرحلة في الأثر. أعد تسجيل التفاعل نفسه بعد كل تغيير حتى لا يخفي معالج أسرع عنق زجاجة جديدًا في العرض.

أثبت أن تغيير INP حسّن التفاعل

اختبار إتاحة المعالج

الاختبار: سجل التفاعل المستهدف في لوحة Performance قبل تقسيم العمل الطويل أو إتاحته وبعده. المتوقع: تقصر مدة معالجة التفاعل أو يفصلها رسم. تفسير الإخفاق: العمل المكلف في موضع آخر أو ما زال متزامنًا. نافذة المراقبة: فورًا عبر آثار متكررة. سبب التراجع: تحديث عنصر التحكم بترتيب خاطئ أو فقدان الحالة أو ظهور أخطاء إدخال جديدة.

اختبار العرض

الاختبار: افحص عمل الأنماط والتخطيط والرسم بعد معالج الحدث في الأثر نفسه. المتوقع: يصل الرسم التالي أسرع دون مهمة تخطيط أكبر. تفسير الإخفاق: يظل حجم DOM أو التخطيط القسري عنق الزجاجة. نافذة المراقبة: فورًا في الآثار المختبرية. سبب التراجع: تصبح الاستجابة المرئية ناقصة أو غير مستقرة.

التأكيد الميداني

الاختبار: قارن إسناد onINP() بعد الإصدار للتفاعل والقالب المعدلين بخط الأساس. المتوقع: يتحسن INP عند p75 ولا يعود العنصر المستهدف مهيمنًا على الأحداث البطيئة. تفسير الإخفاق: لم تمثل الحالة المختبرية الأجهزة أو المسارات الحقيقية. نافذة المراقبة: RUM مع وصول الزيارات وCrUX خلال نافذة 28 يومًا المتحركة. سبب التراجع: تدهور الاستجابة أو اكتمال التفاعل باستمرار بعد النشر.

مقاييس INP الجديرة بالمتابعة

INP للمستخدم الحقيقي عند p75

المقياس: INP عند المئين 75 بحسب القالب وفئة الجهاز. ما يكشفه: هل تستجيب الزيارات الحقيقية المعتادة طوال رحلتها؟ كيفية جلبه: CrUX أو PageSpeed Insights أو RUM عبر web-vitals. المعيار أو النطاق الواقعي: 200 ms أو أقل جيد، وأكثر من 500 ms ضعيف. الإيقاع: راقبه بعد إصدارات JavaScript وراجع اتجاه الحقل المتحرك شهريًا.

معدل التفاعلات البطيئة

المقياس: نسبة التفاعلات المقاسة فوق 200 ms مجمعة حسب الهدف. ما يكشفه: عناصر التحكم التي تسبب أكبر تأخر مرئي حتى عندما يجتاز p75 للصفحة. كيفية جلبه: إصدار الإسناد من web-vitals أو بيانات Event Timing في RUM. المعيار أو النطاق الواقعي: ضع خط أساس لكل رحلة وقلّل المسببات الأعلى حجمًا. الإيقاع: أسبوعيًا للقوالب الشبيهة بالتطبيقات.

حصة مراحل الزمن

المقياس: تأخر الإدخال ومدة المعالجة وتأخر العرض للتفاعلات البطيئة. ما يكشفه: هل الجدولة أو شفرة المعالج أو العرض هو القيد الرئيسي؟ كيفية جلبه: آثار DevTools وإسناد INP. المعيار أو النطاق الواقعي: لا يوجد تقسيم صحي عالمي؛ قارن كل مرحلة بخطها الأساس وبحد الجيد الإجمالي 200 ms. الإيقاع: خلال كل تحقيق أداء مركز.

موارد تستحق وقتك

Google وChrome: المصادر المرجعية

• Interaction to Next Paint (INP) — ابدأ هنا.
• Optimize Interaction to Next Paint — الإصلاحات.
• Optimize long tasks — الإتاحة وscheduler.yield().
• Find slow interactions in the field — تشخيص LoAF والإسناد.
• INP becomes a Core Web Vital — إطلاق 12 مارس 2024.

البيانات

• Web Almanac 2024: Performance — نسب اجتياز INP الفعلية ووسيط الأجزاء.

من القطاع

• INP في MDN Web Docs — مرجع لمقارنة دعم المتصفحات وتعريف المقياس خارج وثائق Google.
• Scheduler API: scheduler.yield() في MDN — جدول الدعم وتفاصيل المواصفة لأداة الإتاحة الرئيسية.
• PerformanceEventTiming في MDN — API المتصفح الأساسية التي يقرأها INP للبحث في بيانات توقيت الأحداث الخام.
• Long Animation Frames API في Chrome Platform Status — تتبع دعم LoAF التي تدعم إسناد INP في مكتبة web-vitals.
• موضوع INP في Search Engine Land — تغطية أخبار تحديثات INP والاختبارات والانتقال من FID.

إحصاءات جديرة بالاستشهاد

• يجتاز INP نحو 74% من الجوال مقابل 97% من سطح المكتب عام 2024. الجوال أصعب كثيرًا، ومع الفهرسة للجوال أولًا فهو المهم في SEO. Web Almanac 2024
• يجتاز نحو 53% فقط من أكبر 1 000 موقع INP؛ فالمواقع الغنية بالميزات ترسل JavaScript أكثر يحجب المسار الرئيسي، لذلك تكون الأكبر أسوأ أحيانًا. Web Almanac 2024
• المهمة الطويلة = > 50 ms. يحجب ما يتجاوز 50 ms على المسار الرئيسي استجابة المتصفح، وهي الآلية المباشرة وراء INP الضعيف. web.dev: تحسين المهام الطويلة
• وسيط الأجزاء عام 2024: يكون تأخر العرض، نحو 36 ms، غالبًا أكبر مساهم منفرد عند الوسيط، مع تقارب تأخر الإدخال والمعالجة عند p75؛ وهذا يساعد في اختيار الثلث الذي تبدأ به. Web Almanac 2024

مقاطع الفيديو

• Google Chrome Developers على YouTube: شروح Core Web Vitals وINP من فريق Chrome، ومنها خطوات تشخيص التفاعلات البطيئة في DevTools. القناة

اختبر معلوماتك: التفاعل حتى الرسم التالي

خمسة أسئلة سريعة عن الاستجابة وتشخيص INP. اختر إجابة لكل سؤال ثم تحقق.

سجل التغييرات