قياس INP وتحسين استجابة الموقع باستخدام INP Scanner

يشرح هذا الدليل INP واستخدام INP Scanner Milten لدراسة التفاعلات البطيئة. حلّ INP محل FID ضمن Core Web Vitals في مارس 2024. يغطي الاختبار المخبري الإجراءات المنفذة، لا تجارب جميع الزوار.

ما هو Interaction to Next Paint ‏(INP)؟

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

الميزات الرئيسية لـ INP:

• التجميع: INP ليس متوسطًا. يعكس عادة أبطأ تفاعل، مع استبعاد بعض القيم الشاذة في الزيارات كثيرة التفاعلات.
• الحدود: جيد عند 200 مللي ثانية أو أقل؛ يحتاج إلى تحسين فوق 200 وحتى 500 مللي ثانية؛ ضعيف فوق 500 مللي ثانية. تُقيّم الزيارات الفعلية عند المئين 75 مع فصل الهاتف عن الحاسوب.
• الإجراءات المشمولة: النقر واللمس ولوحة المفاتيح. التمرير والتحويم لا يُعدّان بحد ذاتهما تفاعلات INP.

لماذا يعد INP مهمًا بالنسبة لك؟

1. تجربة المستخدم (UX)

قد يجعل التأخر المرئي الزر يبدو غير مستجيب، فيكرّر المستخدم النقر. قِس التفاعل المحدد ونتيجته. لا تُعدّ إحصاءات تحميل الصفحات دليلًا مقاسًا على تأثير INP في معدل الارتداد لموقعك.

2. تحسين محركات البحث وتصنيفات البحث

ينتمي INP إلى Core Web Vitals التي تستخدمها أنظمة ترتيب Google. لا تضمن النتيجة الجيدة ترتيبًا أعلى، ولا تثبت النتيجة الضعيفة وجود عقوبة ثابتة. قيّم الاستجابة مع صلة المحتوى وسائر جوانب تجربة الصفحة.

3. السرعة كميزة تنافسية

تؤكد الاستجابة المرئية السريعة أن الإجراء قد استُقبل. قارن المهام المهمة لجمهورك؛ فقد يختلف أثر التأخير نفسه باختلاف المهمة.

استخدام INP Scanner من Milten

يساعد INP Scanner على دراسة الاستجابة في تشغيل متحكم به للمتصفح. راجع الإجراءات المنفذة وحدود التقرير قبل تعميم النتائج.

1. تحقق من التفاعلات المختبرة

اختر مسارًا ممثلًا للاستخدام وتأكد من الإجراءات التي نُفذت فعلًا:

• النقر على الأزرار والروابط.
• إدخال لوحة المفاتيح في الحقول المعنية.
• التمرير للوصول إلى العنصر؛ فالتمرير نفسه ليس تفاعل INP.

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

2. فسّر بيانات التوقيت

يستخدم قياس INP بيانات Event Timing. يستطيع PerformanceObserver مراقبة سجلات event المدعومة؛ ولا يوجد نوع عام باسم render لهذا الغرض. تتولى مكتبة مثل web-vitals تجميع التفاعلات وحساب INP.

• ميّز بين انتظار الإدخال وتنفيذ المعالج وتأخير العرض.
• افحص مهام JavaScript الطويلة في الخيط الرئيسي.
• افحص سلاسة الحركة بوصفها مسألة مرتبطة، لكنها منفصلة.

3. ابحث في الملاحظات

اعتمد على الأدلة الموجودة فعلًا في التقرير:

• حدد التفاعلات المسجلة والعناصر المستهدفة.
• افحص إجراءً بطيئًا، مثل زر شراء افتراضي يستغرق 600 مللي ثانية. الرقم مثال توضيحي، لا قياس لمشروع عميل.
• تحقق من السبب المحتمل في تسجيل أداء المتصفح، وجرّب تعديلًا محدودًا في الشيفرة.

حدود الاختبار الآلي

• راجع شروط الخدمة الحالية وحقول التقرير المتاحة.
• لا يثبت الاختبار في المتصفح أنه جرى على أجهزة الزوار الفعلية.
• تبقى الإجراءات غير المنفذة والبيانات المفقودة غير متحققة. أضف بيانات الزيارات الفعلية عند توفرها.

أسباب شائعة لبطء التفاعلات

1. معالجات الأحداث الطويلة

مثال توضيحي؛ يجب تعريف الدوال والبيانات في التطبيق:

button.addEventListener('click', () => {
	// Synchronous processing of 10,000 data rows
	const result = heavyCalculation(data)
	updateUI(result)
})

المشكلة: يشغل الحساب المتزامن heavyCalculation الخيط الرئيسي، وقد يؤخر التحديث المرئي التالي. الحل: قلّل العمل أو قسّمه، أو انقل الحسابات المناسبة إلى Web Worker. يؤجل استدعاء واحد لـsetTimeout المهمة الثقيلة نفسها، ولا ينقلها خارج الخيط الرئيسي.

2. عرض حظر CSS/JS

مثال:

<link rel="stylesheet" href="large-styles.css" />
<script src="analytics.js" defer></script>

المشكلة: قد تؤخر ورقة أنماط تحجب العرض أو شيفرة مكلفة التنفيذ إظهار الصفحة أو معالجة الإدخال. يغيّر defer توقيت التنفيذ، لكنه لا يلغي كلفته. تنطبق ورقة المثال على الشاشة؛ أما media="print" وحده فلا يطبق هذه الأنماط عليها. تحسينات محتملة:

• ضمّن CSS الضروري فعلًا بعد قياس الأثر.
• افحص الأصناف الديناميكية وحالات الواجهة قبل حذف الأنماط غير المستخدمة؛ تحتاج PurgeCSS إلى إعداد مناسب.
• أجّل الشيفرة غير الضرورية وقلّل كلفة تنفيذها.

3. الرسوم المتحركة البطيئة

مثال:

@keyframes fade {
	from {
		opacity: 0;
		transform: translateX(-100px);
	}
	to {
		opacity: 1;
		transform: translateX(0);
	}
}

المشكلة: تكون حركات opacity وtransform فعّالة غالبًا، لكن تحريك عناصر كثيرة معًا قد يسبب تقطعًا. تحسينات محتملة:

• بسّط الحركة وقلّل العناصر المتحركة في الوقت نفسه.
• استخدم will-change: transform عند الحاجة فقط، وقبل التغيير بقليل. إنه تلميح لا ضمان لتسريع GPU، والإفراط فيه يستهلك الموارد. قِس النتيجة.

4. إعادة حساب التخطيط قسرًا وبشكل متكرر (layout thrashing)

مثال:

for (let i = 0; i < 100; i++) {
	element.style.height = `${i}px`
	console.log(element.offsetHeight) // Forces layout recalculation
}

المشكلة: قد يؤدي التناوب بين كتابة الأنماط وقراءة الأبعاد مثل offsetHeight إلى تكرار حساب التخطيط. حساب التخطيط يختلف عن الرسم. الحل:

• اجمع قراءات الأبعاد قبل الكتابات كلما أمكن.
• استخدم requestAnimationFrame لتخطيط التغييرات المرئية عند ملاءمته، لكن نقل حلقة القراءة والكتابة نفسها إليه لا يعالج المشكلة تلقائيًا.

كيفية تحسين INP: 5 نصائح عملية

1. تحسين معالجات الأحداث

• قسّم المهام الطويلة وأعد التحكم إلى المتصفح بين الأجزاء بآلية مناسبة مثل setTimeout.
• لا يتيح queueMicrotask فرصة للرسم؛ قد تبقي سلسلة المهام المصغرة الصفحة محجوبة.
• قلّل العمل الفوري في المعالج واعرض استجابة سريعة.

2. تقليل حجم حزمة جافا سكريبت

• قم بإزالة المكتبات غير المستخدمة (على سبيل المثال، باستخدام Webpack Bundle Analyzer).
• قم بتطبيق تقسيم التعليمات البرمجية لتحميل الوحدات ديناميكيًا.

3. استخدم debounce وthrottle

حدّد وتيرة العمل المكلف إذا سمحت المهمة بذلك. يفترض المثال تعريف debounce أو استيراده. أبق استجابة حقل الإدخال المرئية فورية؛ فمدة 300 مللي ثانية مثال لجدولة الطلب وليست هدفًا لـINP.

const debouncedSearch = debounce((query) => {
	fetchResults(query)
}, 300)

4. تحسين العرض

• قلّل تعقيد DOM غير الضروري.
• قِس كلفة الأنماط والتخطيط بدل افتراض أن المحددات هي السبب.
• جرّب content-visibility: auto للأقسام خارج الشاشة، مع فحص التخطيط والتركيز وإمكانية الوصول.

5. اختبر على أجهزة محدودة الإمكانات

اختبر أجهزة محدودة الإمكانات ممثلة للجمهور عند الإمكان. ويمكن لأدوات المتصفح محاكاة CPU وشبكة أبطأ، مثل إبطاء المعالج أربع مرات واتصال محمول محدود. هذه ظروف مخبرية توضيحية، وليست تأكيدًا لملف 3G ثابت في الخدمة أو لاختبار أجهزة فعلية.

تحقق من النتيجة

أعد التفاعل نفسه بعد النشر وفي ظروف قابلة للمقارنة. تحقق من الزمن وصحة المهمة: يجب أن تظل السلة الأسرع محتوية على المنتج الصحيح.

استخدم INP Scanner من Milten ضمن الدراسة:

• سجّل الإجراءات المختبرة والأدلة الناقصة.
• قارن المسار نفسه قبل التعديل وبعده.
• قيّم الزيارات الفعلية ببياناتها؛ فالنتيجة المخبرية الجيدة لا تثبت INP جيدًا لجميع المستخدمين.

اختر تفاعلًا بطيئًا مهمًا، وحدد سببًا محتملًا، واختبر إصلاحًا محدودًا. ميّز بين الفحوص الناجحة والفاشلة وغير المنفذة.

راجع دليل قياس INP ودليل تحسين INP.