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