البحث في مجلة Times الاقتصادية عن إصلاح INP

فقد ساعدَ خفض TBT بمقدار 30 مرة والانتقال إلى Next.js في تخفيض INP بأربع مرات تقريبًا، ما أدى إلى انخفاض في معدل الارتداد بنسبة 50% وزيادة بنسبة 43% في مشاهدات الصفحة.

بارون كومار
بارون كومار
دايا رام ياداف
ديا رام ياداف
سوراب راجبال
سوراب راجبال

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

إنّ قيم مقياس INP الجيدة هي 200 ملّي ثانية أو أقلّ، والقيم الضعيفة أكبر من 500 مللي ثانية، وأي قيمة تتراوح بين 10% و 100 ريال سعودي.

البداية الضبابية

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

كان مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) أحد أصعب المقاييس التي يمكن حلّها حتى الآن. في البداية، لم يكن بالإمكان قياس مدى فعالية INP بشكل فعال. وقد جعل هذا الأمر أكثر صعوبة هو الافتقار إلى دعم المنتدى، بما في ذلك عدم دعم معظم مقدمي خدمة مراقبة المستخدم الفعلي (RUM) حتى الآن. ومع ذلك، وفّرنا أدوات Google RUM، مثل تقرير تجربة المستخدم على Chrome (CrUX) ومكتبة JavaScript لبرامج web-vitals وغيرها من الأدوات المتوافقة، ما منحنا فكرة عن موقفنا بينما كنا نقيّم المسار المستقبلي. كان مقياس INP (مدى استجابة الصفحة لتفاعلات المستخدم) يقترب من 1,000 مللي ثانية على مستوى المصدر عندما بدأنا.

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

ما معنى "TBT"، وما هي الخطوات التي اتّخذناها لتحسينه؟

TBT هو مقياس اختباري يقيس مدى استجابة صفحة الويب لإدخالات المستخدم أثناء تحميل الصفحة. تُعتبر أي مهمة يستغرق تنفيذها أكثر من 50 ملي ثانية مهمة طويلة، ويُعرَف الوقت الذي يلي بعد الحدّ البالغ 50 مللي ثانية باسم وقت الحظر.

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

  • تستغرق المهمة "أ" 80 مللي ثانية (30 مللي ثانية أكثر من 50 مللي ثانية).
  • تستغرق المهمة "ب" 100 مللي ثانية (50 مللي ثانية أكثر من 50 مللي ثانية).

ستكون قيمة التاريخ المحدَّد لاحقًا للصفحة: 80 مللي ثانية (30 + 50). كلما انخفضت نسبة TBT، كان ذلك أفضل، وترتبط TBT بشكل جيد أيضًا بمقياس INP.

إليك مقارنة مختبرية سريعة بين ما يتم تحديده لاحقًا قبل اتخاذ الخطوات اللازمة لتحسينه:

صورة مركّبة للمهام الطويلة أثناء بدء التشغيل كما هو موضّح في لوحة الأداء في "أدوات مطوري البرامج في Chrome"، وتقرير عن مقاييس الصفحة تم حظر سلسلة التعليمات الرئيسية أثناء تحميل الصفحة لمدة 3260 مللي ثانية.
سلسلة التعليمات الرئيسية أثناء بدء التشغيل قبل تحسين TBT. المدة التي يتم تحديدها لاحقًا هي 3,260 مللي ثانية.
صورة مركّبة للمهام الطويلة أثناء بدء التشغيل كما هو موضّح في لوحة الأداء في "أدوات مطوري البرامج في Chrome"، وتقرير عن مقاييس الصفحة تم حظر سلسلة التعليمات الرئيسية أثناء تحميل الصفحة لمدة 120 مللي ثانية.
سلسلة التعليمات الرئيسية أثناء بدء التشغيل بعد تحسين TBT. المدة التي يتم تحديدها لاحقًا هي 120 مللي ثانية.

تصغير سلسلة العمل الرئيسية

وتعالج سلسلة التعليمات الرئيسية للمتصفّح كل شيء بدءًا من تحليل HTML، وإنشاء نموذج العناصر في المستند (DOM)، ووصولاً إلى تحليل CSS وتطبيق الأنماط، بالإضافة إلى تقييم JavaScript وتنفيذها. تتعامل سلسلة التعليمات الرئيسية أيضًا مع تفاعلات المستخدم - أي النقر والنقر والضغط على المفاتيح. إذا كانت سلسلة التعليمات الرئيسية مشغولة بأعمال أخرى، فقد لا تستجيب لإدخالات المستخدم بكفاءة، وقد تؤدي إلى تجربة مستخدم رديئة.

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

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

if ('requestIdleCallback' in window) {
  this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}

يُنصَح بتحديد مهلة عند استخدام السمة requestIdleCallback، لأنّها تضمن تنفيذ عملية معاودة الاتصال على الفور بعد انقضاء الوقت المحدَّد ولم يتم استدعاء هذه العملية على الفور.

تقليل وقت تقييم النص البرمجي

نعمل أيضًا على التحميل الكسول لمكتبات الجهات الخارجية باستخدام مكوّنات قابلة للتحميل. أزلنا أيضًا محتوى JavaScript وCSS غير المستخدَم من خلال تحليل الصفحة باستخدام أداة التغطية في "أدوات مطوري البرامج في Chrome". لقد ساعدتنا في تحديد المناطق التي كان يجب فيها اهتزاز الأشجار لشحن رموز أقل أثناء تحميل الصفحة، وبالتالي تقليل حجم حِزمة التطبيق الأولية.

لقطة شاشة لأداة التغطية في "أدوات مطوري البرامج في Chrome". وتعرض الأداة هنا أجزاءً غير مستخدَمة من ملفات JavaScript وCSS أثناء تحميل الصفحة.

تقليل حجم DOM

وفقًا لـ Lighthouse، تزيد أحجام DOM الكبيرة من استخدام الذاكرة، وتؤدي إلى عمليات إعادة احتساب أطول للأنماط، وإنتاجية عمليات إعادة تدفق مكلّفة.

لقطة شاشة للتدقيق في حجم نموذج العناصر في المستند (DOM) في Lighthouse عدد عناصر DOM التي تم الإبلاغ عنها هو 2,706 عنصر.

تم تقليل عدد عُقد DOM بطريقتين:

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

وبسبب كل هذه الجهود، استطعنا تقليل تحديد ما يُسمّى TBT بشكل كبير، وبالتالي خفّضنا مقياس INP بنسبة %50 تقريبًا:

لقطة شاشة لتدقيق INP في CrUX. يبلغ مقياس INP للصفحة 539 ملي ثانية، وهو ما يتجاوز الحدّ الأدنى "ضعيف".

في هذه المرحلة، استنفدنا تقريبًا المكاسب السهلة لخفض عدد مرات تحديد ما إذا كان يمكن تحديد ما إذا كان ذلك قد تم تحديده (ومدى استجابة الصفحة لتفاعلات المستخدم) بشكلٍ أكبر، ولكنّنا أدركنا أنّ هناك مجالاً كبيرًا للتحسين. قرّرنا ذلك عندما قرّرنا ترقية النص النموذجي المخصّص لواجهة المستخدم إلى أحدث إصدار من React إلى جانب Next.js للاستفادة بشكل أفضل من الجذب لتجنّب عمليات إعادة عرض غير ضرورية للمكوّنات.

بسبب زيادة وتيرة التعديلات وانخفاض عدد الزيارات نسبيًا مقارنةً بالأجزاء الأخرى من الموقع الإلكتروني، بدأنا بنقل صفحات المواضيع إلى Next.js. استخدمنا أيضًا PartyTown لإخلاء مسؤولية المزيد من سلاسل التعليمات الرئيسية الثقيلة للعاملين على الويب، إلى جانب أساليب مثل requestIdleCallBack لتأجيل المهام غير المهمة.

كيف ساهم تحسين مقياس INP في صحيفة The Economic Times؟

البيانات الحالية لتحديد المصدر بالاستناد إلى البيانات (TBT) ومقياس INP (مدى استجابة الصفحة لتفاعلات المستخدم) على نقطة الانطلاق

في وقت نشر هذه المشاركة، كان يتم تحديد الوقت الذي سيتم تحديده لاحقًا لمصدرنا 120 مللي ثانية، بعد أن كان 3260 مللي ثانية، بعد أن بدأنا في إجراء التحسين. وبالمثل، كان مقياس INP (مدى استجابة الصفحة لتفاعلات المستخدم) الخاص بمصدرنا 257 مللي ثانية بعد جهود التحسين، بعد أن كان أكثر من 1,000 مللي ثانية.

لقطة شاشة لتدقيق INP في CrUX. يبلغ مقياس INP للصفحة 257 ملي ثانية، وهو ما يقع ضمن الحدود الدنيا لـ "بحاجة إلى تحسين".

مؤشر INP CrUX

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

لقطة شاشة لتوزيعات INP كما تظهر في تقرير تجربة المستخدم على Chrome على مدى أربعة أشهر، بدءًا من تموز (يوليو) 2022 وانتهاءً في تشرين الأول (أكتوبر) 2022. انخفضت القيم ضمن الحدّ الأدنى "ضعيف" و"بحاجة إلى تحسين" إلى حدٍّ ما، في حين ارتفعت القيم ضمن الحدّ "الجيد".

تحليل Akamai mPulse TBT

تجدر الإشارة إلى أنّنا نستخدم Akamai mPulse كحلّ RUM، ويقيس هذا المقياس تحديد ما يُسمّى TBT في الحقل. لاحظنا انخفاضًا ثابتًا في مؤشر "TBT"، مع الإشارة بوضوح إلى نتائج جهودنا لتقليل مدى استجابة الصفحة لتفاعلات المستخدم (INP). وكما هو موضّح في لقطة الشاشة أدناه، انخفضت قيم TBT في النهاية من 5 ثوانٍ إلى 200 ملّي ثانية تقريبًا في الحقل.

لقطة شاشة لرسم بياني في Akamai mPulse يُظهر انخفاضًا في TBT على مدار شهر تقريبًا

نتيجة الأعمال

بشكل عام، ساعدتنا جهودنا لخفض معدّل TBT بمقدار 30 مرة، إلى جانب الانتقال إلى Next.js، في خفض INP بمقدار 4 مرات تقريبًا، ما أدّى في النهاية إلى انخفاض بنسبة 50% في معدل الارتداد وزيادة بنسبة 43% في مشاهدات الصفحة على الويب في صفحات المواضيع.

لقطة شاشة من "إحصاءات Google" تقارن بين مشاهدات الصفحة على الويب ومعدّل الارتداد بفضل التحسينات التي تم إجراؤها على مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) على موقع The Economic Times، تم تحقيق انخفاض بنسبة 50% في معدل الارتداد وزيادة بنسبة 43% في عدد مشاهدات الصفحة على الويب.

الخلاصة

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