لقد خفّضَ خفض TBT بمقدار 30 مرّة والنقل إلى Next.js The Ecomonic Times بمقدار أربع مرات تقريبًا، ما أدّى إلى انخفاض بنسبة% 50 في معدّل الارتداد وارتفاعًا بنسبة% 43 في مشاهدات الصفحة على الويب.
مدى استجابة الصفحة لتفاعلات المستخدم (INP) هو مقياس يقيّم مدى استجابة الموقع الإلكتروني للبيانات التي يُدخلها المستخدمون. تعني الاستجابة الجيدة أن الصفحة سريعة الاستجابة لتفاعلات المستخدم. وكلما انخفض "مدى استجابة الصفحة لتفاعلات المستخدم" (INP)، زادت قدرة الصفحة على الاستجابة لتفاعلات المستخدمين بشكل أفضل.
البداية الغامضة
عندما قدّمت Google مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) في البداية كمقياس تجريبي مع إمكانية تطويره إلى أحد مقاييس "مؤشرات أداء الويب الأساسية"، توجَّه فريق Economic Times إلى التحدي لإصلاحه قبل الانتقال إلى مقياس آخر، وذلك لأنّ توفير تجربة مستخدم رفيعة المستوى هو عامل أساسي في قيمنا الأساسية للنشاط التجاري.
كان مقياس INP أحد أصعب المقاييس التي يجب حلّها حتى الآن. في البداية، لم يكن من الواضح كيفية قياس INP بشكل فعال. وما جعل الأمر أكثر صعوبة هو عدم توفّر دعم من المنتدى، بما في ذلك معظم مقدّمي خدمات تتبُّع المستخدمين الحقيقية (RUM) الذين لا يدعمون الخدمة بعد. ومع ذلك، استخدمنا أدوات RUM من Google، مثل تقرير تجربة المستخدم على Chrome (CrUX) ومكتبة JavaScript web-vitals وغيرها من الأدوات التي توفّر لنا، ما منحنا فكرة عن موقفنا أثناء تقييمنا للمستقبل. عندما بدأنا باستخدام مقياس INP، كان معدّل INP يقترب من 1,000 ملّي ثانية على مستوى المصدر.
من بين النقاط التي ظهرت أثناء تصحيح مقياس INP في المجال أنّ أحد المقاييس المعملية التي يجب استهدافها قد يكون إجمالي وقت الحظر (TBT). وقد تم توثيق TBT بشكل جيد بالفعل ودعمها من قبل المنتدى. على الرغم من استيفائنا للمعايير المحددة مسبقًا في "مؤشرات أداء الويب الأساسية"، لم يكُن أدائنا جيدًا في مقدّمة "TBT"، فقد استغرقنا أكثر من 3 ثوانٍ على بدء استخدام "مؤشرات أداء الويب الأساسية".
ما هو TBT، وما الخطوات التي اتخذناها لتحسينه؟
TBT هو مقياس مختبري يقيس مدى استجابة صفحة الويب لإدخال المستخدم أثناء تحميل الصفحة. تعتبر أي مهمة يستغرق تنفيذها أكثر من 50 مللي ثانية مهمة طويلة، ويُعرف الوقت بعد حد 50 مللي ثانية باسم وقت الحظر.
يتم حساب TBT من خلال جمع مجموع وقت الحظر لجميع المهام الطويلة أثناء تحميل الصفحة. على سبيل المثال، في حال وجود مهمتين طويلتين أثناء التحميل، يتم تحديد وقت الحظر على النحو التالي:
- تستغرق المهمة "أ" 80 مللي ثانية (30 مللي ثانية أكثر من 50 مللي ثانية).
- تستغرق المهمة "ب" 100 مللي ثانية (50 مللي ثانية أكثر من 50 مللي ثانية).
سيكون وقت TBT الخاص بالصفحة: 80 مللي ثانية (30 + 50). كلما انخفضت TBT، كان النطاق أفضل، ويرتبط هذا المقياس أيضًا بشكل جيد بمقياس INP.
في ما يلي مقارنة اختبارية سريعة بين TBT قبل وبعد اتخاذ الخطوات لتحسينه:
تقليل سلسلة العمل الرئيسية
تتعامل سلسلة التعليمات الرئيسية للمتصفِّح مع كل شيء بدءًا من تحليل HTML وإنشاء نموذج كائن المستند (DOM) إلى تحليل CSS وتطبيق الأنماط، بالإضافة إلى تقييم JavaScript وتنفيذها. تتعامل سلسلة المحادثات الرئيسية أيضًا مع تفاعلات المستخدمين، أي النقر والنقر والضغط على المفاتيح. وإذا كانت سلسلة التعليمات الرئيسية مشغولة بإجراء أعمال أخرى، قد لا تستجيب بشكل فعّال للبيانات التي أدخلها المستخدم، وقد تؤدي إلى تجربة مستخدم سيئة.
وكانت هذه أصعب مهمة بالنسبة إلينا، لأنّنا طوّرنا خوارزمياتنا الخاصة لاكتشاف هوية المستخدم لعرض الإعلانات استنادًا إلى حالة الاشتراك والنصوص البرمجية التابعة لجهات خارجية لاختبار A/B والإحصاءات وغير ذلك.
لقد اتّخذنا خطوات صغيرة في البداية، مثل عدم منح الأولوية لتحميل مواد العرض الأقل أهمية في الأنشطة التجارية. ثانيًا، استخدمنا requestIdleCallback للأعمال غير الحرجة، ما يمكن أن يساعد في تقليل الوقت الذي يتم تحديده لاحقًا.
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". لقد ساعدتنا هذه الميزة في تحديد المناطق التي كانت فيها حاجة إلى اهتزاز الشجرة لشحن رموز أقل أثناء تحميل الصفحة، وبالتالي تقليل الحجم الأوّلي لحزمة التطبيق.
تقليل حجم DOM
وفقًا لأداة Lighthouse، تزيد أحجام عناصر DOM الكبيرة من استخدام الذاكرة، وتؤدي إلى إعادة احتساب أنماط أطول، وينتج عنها عمليات إعادة عرض لتنسيق مكلفة.
قمنا بخفض عدد عُقد DOM بطريقتين:
- أولاً، عرضنا عناصر القائمة بناءً على طلب المستخدم (عند النقر). أدى إلى تقليل حجم DOM بحوالي 1200 عقدة.
- ثانيًا، حمّلنا التطبيقات المصغّرة الأقل أهمية باستخدام طريقة "التحميل الكسول".
وبفضل كل هذه الجهود، استطعنا تقليل نسبة TBT بشكل كبير، وتم خفض INP وفقًا لذلك بنسبة 50% تقريبًا:
في هذه المرحلة، أوشكنا على تحقيق نتائج سهلة من أجل تقليل نسبة TBT (ومدى استجابة الصفحة لتفاعلات المستخدم) (INP) بالوكالة، لكنّنا كنّا نعلم أنّ أمامنا مجالاً كبيرًا للتحسين. لقد قرّرنا ترقية النص النموذجي المخصّص لواجهة المستخدم إلى أحدث إصدار من React مع Next.js للاستفادة بشكل أفضل من عناصر الجذب لتجنُّب إعادة عرض المكوّنات غير الضرورية.
نظرًا لحدوث تحديثات أكثر تكرارًا وانخفاض عدد الزيارات نسبيًا مقارنةً بالأجزاء الأخرى من الموقع الإلكتروني، بدأنا بنقل صفحات المواضيع إلى Next.js. واستخدمنا أيضًا PartyTown لإخلاء المزيد من سلاسل المحادثات الرئيسية الثقيلة للعاملين على الويب، إلى جانب أساليب مثل requestIdleCallBack لتأجيل المهام غير المُهمّة.
كيف ساهم تحسين مقياس INP في مساعدة صحيفة The Economic Times؟
TBT وINP الحاليان في المصدر
في وقت نشر هذه المشاركة، كانت المدة الزمنية المخصّصة لتحديد موعد الإرسال 120 ملّي ثانية، أي انخفضت من 3,260 ملّي ثانية عندما بدأنا جهودنا في التحسين. وبالمثل، كان مقياس INP الأصلي 257 ملّي ثانية بعد جهود التحسين، أي انخفاض من أكثر من 1,000 ملّي ثانية.
مؤشر INP CrUX
تمثّل الزيارات التي تتلقّاها صفحات المواضيع جزءًا صغيرًا جدًا من إجمالي عدد الزيارات. ولهذا السبب، كان هذا المشروع مكانًا مثاليًا للاختبار. كانت نتائج تقرير تجربة المستخدم على Chrome إلى جانب نتائج النشاط التجاري مشجّعة للغاية، وقادتنا إلى توسيع جهودنا في الموقع الإلكتروني بأكمله لجني المزيد من المزايا.
تحليل Akamai mPulse TBT
نستخدم Akamai mPulse كحل RUM الذي يقيس القيمة المضافة في المجال. وقد لاحظنا انخفاضًا ثابتًا في TBT، ما نشير بوضوح إلى نتائج جهودنا لخفض INP. وكما يظهر في لقطة الشاشة أدناه، انخفضت قيم TBT في النهاية من حوالي 5 ثوانٍ إلى حوالي 200 مللي ثانية في الحقل.
نتائج النشاط التجاري
بوجهٍ عام، تمكّنا من خفض TBT بمقدار 30 مرّة، وإلى جانب الانتقال إلى Next.js، تمكّنا من خفض INP بمقدار 4 مرّات تقريبًا، ما أدّى في النهاية إلى انخفاض بنسبة 50% في معدّل الارتداد و 43% في مشاهدات الصفحة على الويب على صفحات المواضيع.
الخاتمة
باختصار، ساعد مقياس INP بشكل كبير في تحديد مشاكل الأداء في وقت التشغيل في أجزاء من موقع Economic Times الإلكتروني. لقد أثبت أنّه من أكثر المقاييس فعالية للتأثير بشكل إيجابي في نتائج الأعمال. ونظرًا للأرقام المشجعة للغاية التي لاحظناها نتيجةً لهذه الجهود، فنحن متحمسون لتوسيع نطاق جهود التحسين لتشمل مجالات أخرى في موقعنا الإلكتروني وتحقيق فوائد إضافية.