تحسين استخدام ذاكرة الواجهة الأمامية بمقدار 30 ضعفًا عند تحميل الكاروسيل

في الربع الثاني من عام 2020، قمنا بإعادة هيكلة تقنية لصفحة التجارب، حيث أعدنا كتابتها باستخدام React واستخدمنا واجهة برمجة تطبيقات REST. ولكن أثناء التنفيذ، واجهنا مشكلة مثيرة للاهتمام.

يوجد حوالي 20 عرضًا متتابعًا على صفحة التجارب، يحتوي كل منها على 60 مربعًا على الأقل. لذا، ستعرض الصفحة أكثر من 1200 تجربة، بما في ذلك المعلومات ذات الصلة مثل العنوان وتقييم المستخدمين والمستخدمين المتزامنين والصور المصغرة. في كل عرض متتابع، سيؤدي النقر على زر التمرير الأيمن إلى إرسال طلب لتحميل الدفعة التالية من التجارب إذا كان هناك المزيد. ثم ستُضاف البيانات الجديدة الناتجة عن الطلب إلى الكاروسيل، مما يعني إضافة المزيد من العقد إلى DOM وعرض المزيد من الصور المصغرة في المتصفح. سيزداد استخدام الذاكرة داخل المتصفح مع قيام المستخدمين بالتمرير لطلب المزيد من البيانات، ومن ثم ستتباطأ تجربة المستخدم وستبدأ في التأخر.

ملف تعريف الذاكرة

يمكننا استخدام أدوات مطوري Chrome لتحليل هذه المشكلة. يتم التقاط اللقطة الأولى عند تحميل الصفحة لأول مرة، والثانية بعد أن ينقر المستخدم 12 مرة على زر التمرير التالي في أحد الكاروسيل. نلاحظ زيادة في استخدام الذاكرة بنحو 9.7 ميجابايت بسبب أكثر من 100 عقدة سلسلة وزيادة عرض الصور المصغرة.

الحل

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

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

ملف تعريف الذاكرة

لنلقِ نظرة على أدوات مطوري Chrome مرة أخرى. كما في السابق، تم التقاط اللقطة الأولى عند وقت التهيئة، والثانية بعد التمرير إلى اليمين 12 مرة. الآن، لا يكلف تحميل أكثر من 100 عنصر سوى 0.3 ميغابايت من الذاكرة الإضافية، مقارنة بـ 9.7 ميغابايت سابقًا.

ما هي الخطوة التالية؟

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

في حين أن مجموعة تطبيقات الويب الحديثة تتجه نحو الواجهة الأمامية، فإن التقاط وتحسين قياس الأداء للواجهة الأمامية لا يقل أهمية عن قياس الأداء التقليدي للواجهة الخلفية.