بعد مرور عدة أشهر من العمل على تحسين "مؤشرات أداء الويب الأساسية" على الصفحة الرئيسية لتطبيق Mail.ru، ازدادت نسبة %75 في متغيّرات التصميم التراكمية (CLS) بنسبة %75، ما أدى إلى زيادة متوسط وقت الجلسة بنسبة %2.7 وزيادة معدّلات الإحالات الناجحة في الأقسام الأساسية بنسبة تزيد عن %10.
المكان الذي بدأنا فيه
Mail.ru هي إحدى خدمات البريد الإلكتروني الرائدة على الإنترنت الناطق باللغة الروسية على الإنترنت وضمن أفضل 5 مواقع في روسيا من حيث عدد الزيارات. يعد Mail.ru موردًا مهمًا للعديد من الأشخاص. وهو يتلقى عدة مئات الملايين من الزيارات شهريًا، وهو بوابة يمكن من خلالها للأشخاص الوصول إلى البريد الإلكتروني والأخبار ووسائل التواصل الاجتماعي وعمليات البحث ذات الصلة بالأداء على الإنترنت وغير ذلك.
أرادت شركة Mail.ru تقديم تجربة مستخدِم عالية الجودة لزوّارها، لذا بدأ العمل على تحسين "مؤشرات أداء الويب الأساسية". قبل مناقشة استراتيجية التحسين، يجب ملاحظة بعض التفاصيل الفنية للصفحة الرئيسية لـ Mail.ru.
وقد تم تطوير المشروع منذ فترة طويلة باستخدام محرّك النماذج الداخلي Fest، لكننا بدأنا بالانتقال إلى Svelte 3 في عام 2019.
تنفِّذ Svelte عملية التفاعل بطريقة لا تستخدم Virtual DOM، ما يجعلها أقل استهلاكًا للموارد. يزيل أسلوب Svelte الدوال غير المستخدمة من حِزم الإنتاج لأن الرمز البرمجي الذي ينفِّذها لا ينشئه برنامج التجميع في حال عدم استخدام الدوال. تتم إزالة الرمز غير المستخدم أثناء التحويل البرمجي، ما يؤدي إلى ظهور حِزم أصغر. قد يساعد ذلك في تقليل إجمالي وقت الحظر (TBT) أثناء بدء تشغيل الصفحة.
تتبُّع مقاييس الأداء
قبل تحسين "مؤشرات أداء الويب الأساسية"، من المفيد تقييم الأداء في هذا المجال. قبل "مؤشرات أداء الويب الأساسية"، كنّا نتتبّع مقاييس أخرى، مثل سرعة عرض أول محتوى مرئي (FCP)، في لوحة بيانات الأداء الداخلية.
تم تعديل النص البرمجي الخاص بمجموعة المقاييس لجمع مؤشرات أداء الويب الأساسية ونقلها إلى لوحة بيانات الأداء بهدف عرضها. تماشيًا مع اقتراحات Google، يستخدم النص البرمجي واجهة برمجة التطبيقات PerformanceMonitorer للحصول على المقاييس التي تشكّل جزءًا من الواجهة الأمامية العامة "النظام الأساسي" داخل Mail.ru.
عرضت لوحة البيانات المقاييس التالية للمستخدمين (متوسط القيم للأسبوع الذي يبدأ من 15 إلى 21 آذار (مارس) 2021):
| اسم مجموعة المقاييس | مؤشرات أداء الويب الأساسية | مؤشرات أداء الويب الأخرى | |||||
|---|---|---|---|---|---|---|---|
| اسم المقياس | سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) | مهلة الاستجابة لأوّل إدخال (FID) | متغيّرات التصميم التراكمية (CLS) | سرعة عرض المحتوى على الصفحة | يُحدَّد لاحقًا | مُؤَشِّرْ تَارِيخْ | |
| حصة المستخدمين وفقًا لحدود "مؤشرات أداء الويب الأساسية" | جيد | 52% | 92% | 33% | 35% | 42% | 43% |
| بحاجة إلى تحسين | 19% | 5% | 23% | 38% | 16% | 25% | |
| ضعيفة | 29% | 3% | 44% | 27% | 42% | 32% | |
تحسين "مؤشرات أداء الويب الأساسية"
على الرغم من توفُّر العديد من الإرشادات لتحسين "مؤشرات أداء الويب الأساسية"، يواجه كل مشروع تحديات فريدة. بالنسبة إلى صفحة Mail.ru الرئيسية، تم تحديد الفرص التالية:
- تنفيذ العناصر النائبة لإعلانات البانر في الإعلانات لتقليل متغيّرات التصميم التراكمية (CLS)
- استخدام العرض من جهة الخادم (SSR) لتقليل سرعة عرض أكبر محتوى مرئي (LCP).
- تقسيم الرمز لتقليل سرعة عرض أكبر محتوى مرئي (LCP) ومهلة الاستجابة الأولى (FID)
هياكل عظمية لتحسين متغيّرات التصميم التراكمية (CLS)
كانت متغيّرات التصميم التراكمية (CLS) أحد أسوأ مقاييس الحقول أداءً في صفحة Mail.ru الرئيسية. وكشف المواصفات التالية لهذه الصفحة في لوحة الأداء ضمن "أدوات مطوري البرامج في Chrome" أنّ الإعلانات هي مصدر المشكلة. لتحسين ثبات التصميم، قرّر فريقنا استخدام العناصر النائبة لحجز مساحة للإعلانات قبل تحميلها.
عند تنفيذ العناصر النائبة، تكون الخطوة الأولى هي تحديد أبعاد المحتوى التي ستحل محلها. لحسن الحظ، تم توثيق أحجام الإعلانات بدقة في إصدار سطح المكتب من صفحة Mail.ru الرئيسية. وبعد التحدث مع فريق التصميم، تم استخدام الهياكل العظمية لواجهة المستخدم المتحركة بتنسيق الرسومات الموجّهة التي يمكن تغيير حجمها (SVG) كعناصر نائبة لأنّها تقلّل من وقت التحميل الملحوظ للمحتوى.
عودة SSR
لتسهيل الانتقال من Fest إلى Svelte، أعدنا كتابة المشروع الحالي تدريجيًا بدلاً من البدء من جديد. وبحلول آذار (مارس) 2021، رحَّلنا معظم الواجهة الأمامية إلى Svelte، وفي النهاية أحضرنا SSR إلى تطبيق الإنتاج بعد فرز مشكلات الأداء في الخلفية وإصلاحها.
بعد تطبيق آلية SSR، اكتشف الفريق سبب انحدار متغيّرات التصميم التراكمية (CLS) الذي لم يلاحظه أحد في البداية وهو عدم إدراج قسم الأخبار عند عرض المحتوى الأول على الصفحة. حدث تأخير بين الرسم الأولي لترميز الصفحة الذي قدّمه الخادم وبين إدراج قسم الأخبار في البرنامج. وأدّى هذا السلوك إلى حدوث تغيير في هيكل الإعلان، ما أدّى إلى تدهور متغيّرات التصميم التراكمية (CLS).
على الرغم من أنّ أدوات مطوّري البرامج في Chrome عرضت أحداث "متغيّرات التصميم"، لم نتمكّن من العثور على سببها في البداية. على الرغم من أن SSR بحد ذاته لم يكن المشكلة، إلا أنه ساعد في اكتشاف الحل في وقت لاحق. إصلاح الرمز المسؤول عن تأخير الرسم أدى إلى تحسين ثبات التنسيق في مكوّن الأخبار.
يمكن أن يحدث تأثير آخر لمتغيّرات التصميم التراكمية (CLS) في حركة المكوّنات قبل ترطيب الماء وبعده، ما قد يؤدي إلى تغييرات إضافية في التصميم. وقد واجهنا هذه المشكلة في نسخة الموقع الإلكتروني المخصّصة للأجهزة الجوّالة تحديدًا، ما تطلّب اهتمامًا خاصًا من ترميز المكوّنات المائية. كان أحد الحلول الجيدة لهذه المشكلة هو نقل أكبر قدر ممكن من منطق العرض من JavaScript إلى CSS.
تقسيم الرمز واستخدام رموز polyfill غير المستخدَمة
لتحسين سرعة تحميل الصفحة التي يتم رصدها، كان مطلوبًا من المستخدم خفض قيم LCP وFID. ويمكنك تحقيق ذلك من خلال تقسيم الرموز. بالإضافة إلى الصفحة الرئيسية لموقع Mail.ru نفسه، يعمل فريقنا على تطوير أداة للتنقّل في البوابة. وهي مضمّنة حاليًا في العديد من مشاريع الشركة.
ولأسباب سابقة، يتم إدراج التطبيق المصغّر في بداية الصفحة كنص برمجي للتحميل المتزامن. زادت نسبة رموز polyfill في هذا النص البرمجي بمرور الوقت. وللحدّ من تأثيرات الأداء السلبية لتحميل رموز polyfill هذه، نفّذنا عملية تقسيم الرموز البرمجية لكل من المتصفِّحات الحديثة والقديمة.
لقد قرّرنا عدم استخدام نمط module/nomodule لتحميل حِزم JavaScript للمتصفّحات الحديثة أو القديمة، لأنّ السمة type="module" في العنصر <script> لم تستهدِف المتصفّحات الحديثة بما يكفي لاحتياجاتنا. لمعالجة هذه المشكلة، يستخدم Mail.ru أداة داخلية لتحديد إصدارات المتصفحات الحديثة في الخلفية، ويمكنه التكيف مع تلك المتصفحات وفقًا لذلك.
وبمجرد تحديد المتصفحات في الخلفية، قمنا بتنفيذ تقسيم التعليمات البرمجية للمتصفحات الحديثة والقديمة. وكانت النتيجة انخفاضًا بنسبة 43.3% في حجم تطبيق JavaScript المصغّر الذي يتم تحميله بشكل متزامن للمتصفّحات الحديثة. تم تطبيق هذه الممارسة على بعض النصوص البرمجية الأخرى للبوابة أيضًا.
بالإضافة إلى تقليل حجم الحزمة والتأثيرات الإيجابية في "مؤشرات أداء الويب الأساسية"، يساعد تقسيم الرمز في تحسين تجربة المطوّرين أيضًا. تجدر الإشارة إلى أن 3.5% فقط من المستخدمين يستخدمون المتصفحات القديمة وهذه المشاركة تتراجع تراجعًا، ولذلك سمح تطبيق تقسيم الرموز للمطورين باستخدام أحدث واجهات برمجة التطبيقات للمتصفح بدون تقديم رموز polyfill الكبيرة اللازمة للمتصفحات القديمة لجميع المستخدمين.
النتائج
بعد جهود التحسين، لاحظنا القيم المتوسطة للأسبوع من 24 إلى 30 أيار (مايو) 2021 في البيانات الميدانية:
| اسم مجموعة المقاييس | مؤشرات أداء الويب الأساسية | مؤشرات أداء الويب الأخرى | |||||
|---|---|---|---|---|---|---|---|
| اسم المقياس | سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) | مهلة الاستجابة لأوّل إدخال (FID) | متغيّرات التصميم التراكمية (CLS) | سرعة عرض المحتوى على الصفحة | يُحدَّد لاحقًا | مُؤَشِّرْ تَارِيخْ | |
| حصة المستخدمين وفقًا لحدود "مؤشرات أداء الويب الأساسية" | جيد | 58% (+6%) | 93% (زيادة بنسبة %1) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| بحاجة إلى تحسين | 18% | 4% | 3% | 34% | 17% | 24% | |
| ضعيفة | 24% | 3% | 4% | 23% | 34% | 25% | |
تعرِض الرسوم البيانية أدناه التغييرات في قيم مقاييس أداء صفحات الويب وفقًا لـ "النظام الأساسي". لاحظ التاريخين المهمين في الرسوم البيانية:
- 23 آذار (مارس) 2021: إصدار التكرار مع نقل آخر أقسام الصفحة إلى Svelte
- 19 نيسان (أبريل) 2021: تم إصدار التكرار مع عرض SSR مع تعديل التخطيط لتصحيح انحدارات متغيّرات التصميم التراكمية (CLS)
يرجع الانخفاض في القيم من 1 إلى 10 أيار (مايو) إلى عطلات شهر أيار (مايو) في روسيا.
تتوافق النتائج التي تم الحصول عليها باستخدام "النظام الأساسي" مع نمو قيم المقاييس في تقرير تجربة المستخدم على Chrome (CrUX).
عند المقارنة بين قيم متوسط مدة جلسة المستخدم قبل أسبوع من طرح التحسينات الأولية وأسبوع بعد الطرح، تظهر زيادة بنسبة% 2.7. إضافةً إلى ذلك، هناك زيادة كبيرة إجمالية في الإحالات الناجحة في معظم أقسام الصفحة. وعلى وجه التحديد، زادت الإحالات الناجحة إلى تطبيق البريد الإلكتروني Mail.ru بنسبة 11.6%، وزاد معدّل تحويل قسم الأخبار بنسبة 13.5%.
زيادة بنسبة %181
زيادة حصة الحدّ الأدنى لمتغيّرات التصميم التراكمية (CLS) الجيدة
زيادة بنسبة %2.7
متوسط مدة الجلسة أعلى
زيادة بنسبة %13.5
في معدّل الإحالات الناجحة لأقسام الأخبار
وكانت النتيجة غير المتوقعة التي حصلنا عليها هي زيادة بنسبة 17.4% في نسبة النقر إلى الظهور (CTR) لإعلان البانر التسويقي (وقد أدى ذلك إلى خفض وقت العرض بشكل كبير بفضل طرح علامات التسجيل المسبق وعلامات التحميل المسبق).
وبعد تحليل باقي الأقسام على الصفحة، لاحظنا تحسُّنًا كبيرًا في الأداء في الغالبية العظمى منها. حتى بالنسبة إلى أقسام مثل "الطقس" و"فيروس كورونا" التي لا تشكّل عاملاً أساسيًا في صفحتنا، نشهد زيادة في الإحالات الناجحة بنسبة 9.6% و 9.5% على التوالي.
الخلاصة
يعد تحسين الأداء أمرًا صعبًا حيث إن العمل المطلوب قد يكون طويلاً. يجب مراقبة التغييرات في المقاييس بانتظام بمرور الوقت والتأكّد من أنّ جميع ميزات المنتج الجديدة لا تتسبب في أي تراجع في "مؤشرات أداء الويب الأساسية". لتحقيق ذلك، نراقب التغييرات التي تطرأ على "مؤشرات أداء الويب الأساسية" في ميزانية الأداء.
والأهم من ذلك، شدّدنا على أهمية "مؤشرات أداء الويب الأساسية" لجميع أعضاء فريق المنتج، من المدراء والمصممين إلى المختبِرين وتأكيد الجودة. يجب أن يكون كل عضو في الفريق على دراية بمقاييس الأداء وأن يكون مخولاً لتحسينها. ونطبّق أيضًا أهداف تحسين الأداء في عملياتنا التجارية بوتيرة منتظمة. لا يمكن توفير تجربة مستخدم عالية الجودة بنجاح إلا من خلال جهد مشترك من قبل جميع أعضاء الفريق.