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