كيف يُسهم تحسين Core Web Vitals على الأجهزة المحمولة في خفض INP؟

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

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

يقيس INP المدة من التفاعل حتى الإطار التالي، لا وقت إتمام العملية التجارية

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

في تقييم Google لمؤشرات Core Web Vitals، تكون قيمة INP «جيدة» إذا لم تتجاوز 200 مللي ثانية، و«تحتاج إلى تحسين» إذا تجاوزت 200 مللي ثانية ولم تتجاوز 500 مللي ثانية، و«ضعيفة» إذا تجاوزت 500 مللي ثانية. ويُحدَّد اجتياز الموقع استنادًا إلى بيانات الزيارات الفعلية عند المئين الخامس والسبعين، مع تقييم الأجهزة المحمولة وأجهزة سطح المكتب كلٌّ على حدة. وهذا يختلف عن اختيار تفاعل ممثل ضمن زيارة واحدة للصفحة، فهما مستويان إحصائيان مختلفان.

لا يُعد INP أيضًا زمن استجابة واجهة API. فإذا عُرضت حالة «جارٍ الإرسال» فور تقديم استفسار، ثم اكتمل طلب الشبكة لاحقًا، فقد تكون قيمة INP لهذا التفاعل منخفضة. لكن انخفاض INP لا يعني نجاح العملية التجارية؛ لذا ينبغي أيضًا مراقبة مدة الطلبات ومعدل الإخفاقات وعمليات الإرسال المكررة كلٌّ على حدة.

حدّد أولًا موضع التأخير، ثم قرر ما ينبغي تحسينه

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

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

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

تقليل الحظر أهم من مجرد تأجيل النصوص البرمجية

عندما يكون زمن انتظار الإدخال مرتفعًا، ينبغي التحقق مما إذا كانت النصوص البرمجية تُنفَّذ بكثافة بعد بدء المستخدم التفاعل. وفي مواقع التسويق، يجدر فحص مكونات خدمة العملاء عبر الإنترنت، وعلامات الإحصاءات، وتتبع الإعلانات، والنوافذ المنبثقة واحدًا تلو الآخر من حيث وقت التحميل وكلفة التنفيذ. يمكن أن يؤدي استخدام async أو defer إلى تغيير توقيت تحميل النصوص البرمجية وتنفيذها، لكنه لا يلغي استهلاكها لموارد سلسلة التعليمات الرئيسية أثناء التشغيل.

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

ينبغي تقسيم العمليات الحسابية المتزامنة إلى دفعات وإتاحة الفرصة لسلسلة التعليمات الرئيسية بين الدفعات. يمكن للمتصفحات المدعومة استخدام scheduler.yield()؛ أما البيئات الأخرى فتحتاج إلى حل بديل. ولا يُعتمد على تقسيم العمل باستخدام Promise أو queueMicrotask وحدهما، لأن قائمة المهام الدقيقة قد تستمر في التنفيذ قبل الرسم. ويمكن نقل العمليات التي تستهلك CPU ولا تعتمد على DOM إلى Web Worker، مع تقييم كلفة الاتصال ونسخ البيانات.

ينبغي تقليل عبء دوال معالجة الأحداث والعرض معًا

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

يمكن تخزين نتائج تصفية المنتجات مؤقتًا لتجنب المرور على جميع البيانات من جديد عند كل تفاعل. كما ينبغي تجنب إعادة التحقق من النموذج بأكمله عند كل إدخال لحرف. يناسب تأخير التنفيذ الارتدادي (debounce) تقليل عمليات البحث التي لا تتطلب استجابة فورية، لكن ينبغي ألا يؤخر الاستجابة المرئية للزر أو يُستخدم لإخفاء بطء العمليات الضرورية.

عند ارتفاع تأخر العرض، ينبغي فحص حجم DOM ونطاق تأثير الأنماط وحدود تحديث المكونات. يمكن عرض قوائم المنتجات الطويلة افتراضيًا، مع مراعاة متطلبات إمكانية الوصول وفهرسة محركات البحث. وقد تؤدي عمليات «كتابة الأنماط ثم قراءة الأبعاد» المتكررة إلى فرض إعادة التخطيط؛ لذا يُفضّل تجميع عمليات القراءة أولًا ثم الكتابة. وفي التطبيقات المبنية على أطر العمل، ينبغي أيضًا التحقق مما إذا كان تغيير الحالة محليًا يؤدي إلى تحديث مكونات غير ذات صلة، بدلًا من الاكتفاء بقياس مدة دالة معالجة الحدث.

إن requestAnimationFrame ليس حاوية للأعمال المستهلكة للوقت؛ فالشيفرة التي تُنفَّذ داخله تعمل قبل الرسم، ولذلك فإن وضع عمليات حسابية كثيرة فيه قد يحظر الإطار التالي.

تحقق باستخدام بيانات الزيارات الفعلية، لا باختبار واحد فقط

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

يمكن استخدام web-vitals وميزة إسناد الأسباب المرفقة به داخل الموقع لتسجيل هدف التفاعل ونوع الصفحة والوقت المستغرق في كل مرحلة، مع تجنب جمع معلومات شخصية مثل محتوى النماذج. وينبغي أن تشمل الاختبارات أجهزة محمولة فعلية وظروفًا معقولة لإبطاء CPU؛ فالاكتفاء بوضع عرض ضيق في متصفح سطح المكتب لا يُظهر اختلاف القدرة على المعالجة بين الأجهزة المحمولة.

ينبغي أن تقارن اختبارات القبول بعد الإطلاق توزيع INP بين صفحات متشابهة وفي ظروف أجهزة متقاربة، وأن تعيد اختبار استمرار إتمام التفاعلات الأساسية على نحو صحيح. وتعتمد CrUX بيانات متحركة على مدى 28 يومًا، لذلك لا يُتوقع أن تعكس جميع آثار التعديلات فورًا. ووفقًا لـتعريف Google لمؤشر INP، فإن الدليل على فعالية التحسين هو تقليل مدة الانتظار الفعلية أثناء التفاعل، لا انخفاض حجم الموارد أو ارتفاع نتيجة اختبار لمرة واحدة.