مستوى أداء أُطر العمل الحديثة على مقياس INP الجديد

فهم مدى تأثير مقياس INP الجديد في تجربة المواقع الإلكترونية التي تم إنشاؤها باستخدام إطارات عمل ومكتبات JavaScript

Leena Sohoni

Addy Osmani

Keen Yee Liau

طرح Chrome مؤخرًا مقياسًا تجريبيًا للاستجابة في تقرير تجربة المستخدم في Chrome. يُعرف هذا المقياس الآن باسم مدى استجابة الصفحة لتفاعلات المستخدم (INP)، وهو يقيّم مدى استجابة الصفحة بشكل عام لتفاعلات المستخدمين عليها. نريد اليوم مشاركة إحصاءات عن مستوى أداء المواقع الإلكترونية التي تم إنشاؤها باستخدام إطارات عمل JavaScript الحديثة في ما يتعلّق بهذا المقياس. نريد مناقشة سبب صلة INP بالأُطر وكيفية عمل Aurora والأُطر لتحسين الاستجابة.

الخلفية

يستخدم Chrome مقياس "مهلة الاستجابة الأولى" (FID) كجزء من "مؤشرات أداء الويب الأساسية" (CWV) لقياس استجابة التحميل للمواقع الإلكترونية. يقيس مقياس FID وقت الانتظار من أول تفاعل للمستخدِم إلى اللحظة التي يتمكّن فيها المتصفّح من معالجة معالجات الأحداث المرتبطة بالتفاعل. ولا يشمل الوقت المستغرَق لمعالجة معالِجات الأحداث أو معالجة التفاعلات اللاحقة على الصفحة نفسها أو رسم الإطار التالي بعد تنفيذ عمليات الاستدعاء للأحداث. ومع ذلك، فإنّ سرعة الاستجابة مهمة لتجربة المستخدم على مدار دورة حياة الصفحة لأنّ المستخدمين يقضون ما يقرب من% 90 من الوقت على الصفحة بعد تحميلها.

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

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

دور الأطر

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

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

يعمل فريق Aurora في Chrome مع إطارات عمل الويب مفتوحة المصدر لمساعدة المطوّرين على تحسين جوانب مختلفة من تجربة المستخدم، بما في ذلك الأداء ومقاييس CWV. مع طرح مبادرة INP، نريد الاستعداد للتغيير في مقاييس CWV للمواقع الإلكترونية المستندة إلى إطار العمل. لقد جمعنا البيانات استنادًا إلى مقياس الاستجابة التجريبي في تقارير CrUX. سنشارك إحصاءات وإجراءات لتسهيل عملية الانتقال إلى مقياس INP للمواقع الإلكترونية المستندة إلى إطار العمل.

بيانات مقياس الاستجابة التجريبي

يشير مقياس INP الذي تقل قيمته عن 200 ملي ثانية أو تساويها إلى سرعة استجابة جيدة. تقدّم لنا بيانات تقرير CrUX وتقرير تكنولوجيا "مؤشرات أداء الويب الأساسية" لشهر حزيران (يونيو) 2023 المعلومات التالية حول سرعة الاستجابة لإطارات عمل JavaScript الشائعة.

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

كيف يؤثر JavaScript في INP؟

ترتبط قيم INP في الحقل بشكل جيد بإجمالي وقت الحظر (TBT) الذي تم رصده في المختبر. قد يعني ذلك أنّ أي نص برمجي يحظر سلسلة التعليمات الرئيسية لفترة طويلة سيكون سيئًا لقياس INP. إنّ تنفيذ JavaScript بشكل مكثّف بعد أي تفاعل قد يؤدي إلى حظر سلسلة المحادثات الرئيسية لفترة طويلة وتأخير الردّ على هذا التفاعل. في ما يلي بعض الأسباب الشائعة التي تؤدي إلى حظر النصوص البرمجية:

• JavaScript غير المحسَّن: يمكن أن يؤدي الرمز المتكرّر أو استراتيجيات تقسيم الرمز وتحميله غير الفعالة إلى زيادة حجم JavaScript وحظر السلسلة الرئيسية لفترات طويلة. يمكن أن يؤدي تقسيم الرموز البرمجية والتحميل التدريجي وتقسيم المهام الطويلة إلى تحسين أوقات الاستجابة بشكل كبير.

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

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

• التكلفة الإضافية للإطار على معالجة الأحداث: قد تتضمّن الإطارات ميزات أو بنية إضافية لمعالجة الأحداث. على سبيل المثال، تستخدم Vue v-on لإرفاق أدوات الاستماع إلى الأحداث بالعناصر، في حين تُغلِّف Angular معالجات أحداث المستخدم. يتطلّب تنفيذ هذه الميزات رمزًا إضافيًا للإطار الأساسي فوق JavaScript العادي.

• المعالجة: عند استخدام إطار عمل JavaScript، من الشائع أن ينشئ الخادم رمز HTML الأولي للصفحة، والذي يجب بعد ذلك تعزيزه مع معالجات الأحداث وحالة التطبيق حتى يمكن أن يكون تفاعليًا في متصفّح ويب. نسمي هذه العملية "ترطيب". يمكن أن تكون هذه عملية مرهقة أثناء التحميل، وذلك حسب المدة التي يستغرقها JavaScript للتحميل ومدة اكتمال عملية الترطيب. ويمكن أن يؤدي ذلك أيضًا إلى أن تبدو الصفحات تفاعلية على الرغم من أنّها ليست كذلك. غالبًا ما يحدث الترطيب تلقائيًا أثناء تحميل الصفحة أو بشكل بطيء (على سبيل المثال، عند تفاعل المستخدم) ويمكن أن يؤثر في INP أو وقت المعالجة بسبب جدولة المهام. في المكتبات مثل React، يمكنك الاستفادة من useTransition لكي يظهر جزء من عرض المكوّن في اللقطة التالية ويتم ترك أيّ تأثيرات جانبية أكثر تكلفة للّقطات المستقبلية. وبناءً على ذلك، يمكن أن تكون التعديلات في مرحلة انتقالية تؤدي إلى تعديلات أكثر إلحاحًا، مثل النقرات، نمطًا جيدًا لنسبة INP.

• التحميل المُسبَق: يمكن أن يؤدي التحميل المُسبَق بشكلٍ فعّال للموارد اللازمة للتنقّلات اللاحقة إلى تحسين الأداء عند تنفيذه بشكلٍ صحيح. في المقابل، إذا كنت تُحمِّل مسبقاً مسارات التطبيقات المُنشِئة للصفحات الديناميكية وتُعرِضها بشكل متزامن، قد يؤدّي ذلك إلى التأثير سلبًا في INP لأنّ كلّ هذه المحاولات المُكلِّفة لعرض المحتوى تحاول إكمالها في إطار واحد. يُرجى مقارنة ذلك بعدم بدء تحميل المسار مسبقًا وبدء العمل المطلوب بدلاً من ذلك (على سبيل المثال، fetch()) وإلغاء حظر الطلاء. ننصحك بإعادة فحص ما إذا كان منهج إطار العمل المُستخدَم في ميزة "التحميل المُسبَق" يقدّم تجربة المستخدم المثلى ومدى تأثير ذلك في INP (إن وُجد).

من الآن فصاعدًا، للحصول على نتيجة INP جيدة، على المطوّرين التركيز على مراجعة الرمز البرمجي الذي يتم تنفيذه بعد كل تفاعل على الصفحة وتحسين استراتيجيات تقسيم البيانات وإعادة عرضها وتحميلها وحجم كل تعديل على render() لكل من النصوص البرمجية التابعة للطرف الأول والطرف الثالث.

كيف تعالج Aurora والأُطر مشاكل INP؟

تعمل Aurora مع الأطر من خلال دمج أفضل الممارسات لتقديم حلول مضمّنة للمشاكل الشائعة. لقد عملنا مع Next.js وNuxt.js وGatsby وAngular على الحلول التي توفّر إعدادات تلقائية قوية ضمن إطار العمل لتحسين الأداء. في ما يلي أهم ما توصلنا إليه في هذا السياق:

• React وNext.js: يساعد مكوّن نص Next.js البرمجي في معالجة المشاكل الناتجة عن عدم كفاءة تحميل النصوص البرمجية التابعة لجهات خارجية. تمّ تقديم ميزة تقسيم الرمز البرمجي إلى أجزاء دقيقة في Next.js للسماح بتقسيم الرمز البرمجي المشترَك إلى أجزاء أصغر حجمًا. ويساعد ذلك في تقليل مقدار الرمز البرمجي الشائع غير المستخدَم الذي يتم تنزيله على جميع الصفحات. نحن نعمل أيضًا مع Next.js لتوفير بيانات INP كجزء من خدمة Analytics.

• Angular: تتعاون Aurora مع فريق Angular لاستكشاف تحسينات العرض من جهة الخادم وتحسينات إعادة الترطيب. ونخطّط أيضًا لمراجعة التحسينات في معالجة الأحداث ورصد التغييرات لتحسين ميزة INP.

• Vue وNuxt.js: نستكشف مجالات التعاون، ويتعلق ذلك بشكل أساسي بتحميل النصوص البرمجية وعرضها.

كيف تنظر الأطر إلى تحسين INP؟

React وNext.js

تتيح لك ميزة تقسيم الوقت في React.js، التي يتم تنفيذها من خلال startTransition وSuspense، تفعيل ميزة الترطيب الانتقائي أو التدريجي. وهذا يعني أنّ عملية الترطيب ليست عملية متزامنة. ويتم ذلك على أجزاء صغيرة يمكن إيقافها في أي وقت.

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

نفَّذ Next.js إطار عمل توجيه جديدًا يستخدم startTransition تلقائيًا لنقل المسار. يتيح ذلك لمالكي المواقع الإلكترونية التي تستخدم Next.js استخدام ميزة "تقسيم الوقت" في React وتحسين سرعة استجابة عمليات النقل بين المسارات.

Angular

يستكشف فريق Angular العديد من الأفكار التي من المفترض أن تساعد أيضًا في تحسين سرعة التحميل:

• الرمز البرمجي غير المرتبط بمنطقة معيّنة: يقلل من حجم الحزمة الأولية والرمز البرمجي المطلوب تحميله قبل أن يتمكّن التطبيق من عرض أي محتوى.
• إعادة الترطيب: إعادة الترطيب على غرار تقنية "الجزيرة" للحد من عدد أجزاء التطبيق التي يجب إعادة تنشيطها للتفاعل
• تقليل التكاليف الإضافية لعملية التطوير المستمر: على سبيل المثال، يمكنك تقليل تكلفة رصد التغييرات، والعثور على طرق لفحص جزء أقل من التطبيق، والاستفادة من الإشارات التفاعلية حول التغييرات التي تم إجراؤها.
• تقسيم الرموز البرمجية بشكل أدق: يمكنك تصغير الحِزمة الأولية.
• دعم أفضل لمؤشرات التحميل:: على سبيل المثال، أثناء إعادة عرض المحتوى من خلال تقنية SSR، وأثناء التنقّل في المسار، وفي عمليات التحميل غير المتزامن.
• أدوات وضع التقارير: أدوات تطوير أفضل لفهم تكلفة التفاعل، لا سيما تكلفة رصد التغييرات في تفاعلات معيّنة.

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

الخاتمة

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

• إنشاء قنوات للوصول بسهولة إلى بيانات تجارب المستخدمِين الحقيقيِين على INP لإطارات العمل ومطوّري الويب
• العمل مع أُطر العمل لإنشاء ميزات ستُحسِّن INP تلقائيًا

نرحب بملاحظات مستخدمي إطار العمل عند بدء رحلات تحسين INP.