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