ركّز مشروع ركّز على تحسين "مؤشرات أداء الويب الأساسية" والانتقال إلى Next.js إلى زيادة بنسبة% 5 في معدّلات الإحالات الناجحة و% 87 في عدد الصفحات في الجلسة الواحدة.
QuintoAndar هي شركة برازيلية في مجال التكنولوجيا تقدّم منتجاتها حلولاً رقمية شاملة للعقارات. في هذا العام، نفذنا مشروعًا يركز على تحسين أداء مركز المحتوى في تطبيقنا، وحقق نتائج مشجّعة في زيادة عدد زيارات المستخدمين ومقاييس الإحالات الناجحة.
%46
انخفاض في معدل الارتداد
%87
زيادة في عدد الصفحات في كل جلسة
زيادة بنسبة %5
نسبة الزيادة في الإحالات الناجحة أثناء مرحلة التحقّق من الصحة
تحديات
يحتوي تطبيقنا على مركز لمحتوى الوحدات السكنية يحتوي على أكثر من 40000 صفحة، حيث يمكن للمستخدمين الحصول على معلومات حول ممتلكاتهم، والتحقق من صور المناطق المشتركة، وقراءة معلومات عن الحي، والعثور على إعلانات متاحة للإيجار أو البيع. هذه الصفحات مهمة جدًا بالنسبة إلى QuintoAndar:
- وتشكّل مصدرًا مهمًا للزيارات الواردة من نتائج البحث المجانية، حيث يزداد عدد المستخدمين الذين يصلون إلى موقعك الإلكتروني من نتائج محركات البحث بشكل منتظم.
- تحقّق هذه الصفحات معدلات إحالات ناجحة عالية على المدى المتوسط إلى الطويل مقارنةً بالصفحات الأخرى.
مع ذلك، واجهتنا تحديات في ما يتعلق بالأداء وتجربة المستخدم في الصفحات التالية:
- لم يتم تحسين مستوى الأداء وفقًا لمؤشرات أداء الويب الأساسية، وكانت هناك مشاكل معروفة متعلقة ببطء عمليات تحميل الصفحات وبطء الاستجابة لإدخال المستخدم وعدم استقرار التنسيق.
- كانت معدلات الارتداد مرتفعة، حتى إذا توقعنا أن تكون أعلى منها في أجزاء أخرى من التطبيق.
- ومن خلال التحديث الخاص بتجربة الصفحة في "بحث Google" والذي لم يتم إطلاقه بعد، يتضمّن "مؤشرات أداء الويب الأساسية" في خوارزمية الترتيب، ما يعني أنّ أداء الصفحة قد يؤثر في طريقة عرض نتائج البحث.
في الوقت نفسه، حددنا بعض الفرص لخبرة المطوّرين التي يمكن أن تحقِّق مكاسب في مشاريع أخرى عبر الشركة:
- وقد تم إنشاء منطق العرض من جهة الخادم داخل الشركة، وهو يعرض جميع الصفحات التي تستقبل عددًا كبيرًا من الزيارات، بما في ذلك صفحات الوحدات السكنية، وأصبح معقّدًا للغاية في حال صيانته وضمه إلى الموظفين الجدد.
- ولتحقيق أداء جيد للتطبيق، كانت الميزات الأساسية مثل تقسيم الرموز تتطلّب أيضًا إعدادًا مخصّصًا بالإضافة إلى عمل يدوي من المطوّرين.
- يضم تطبيق QuintoAndar أكثر من 30 تطبيق ويب من تطبيقات React. ويُعد تقديم تحديثات لهذه التطبيقات وصيانتها وفقًا لأفضل الممارسات مهمة شاقة.
الطريقة
بدأنا مشروع تحسين الأداء في مركز محتوى الوحدات السكنية لتحسين تجربة المستخدم، حيث يمكن أن تؤدي هذه التحسينات إلى تحقيق مكاسب في الإحالات الناجحة وتحسين محركات البحث وسهولة الاستخدام. كانت هذه المبادرة أيضًا فرصة مناسبة لتحسين تجربة المطوّرين أيضًا.
النقل إلى Next.js
تم تنفيذ الإصدار الجديد من صفحة الوحدات السكنية باستخدام Next.js. نظرًا كونه مستقلاً إلى حد كبير عن الأجزاء الأخرى من التطبيق، بدا مركز محتوى الوحدات السكنية مرشحًا جيدًا لتجربة إطار عمل جديد. سنتمكن من فهم حجم جهود نقل البيانات وتقييم مدى فائدة ميزاتها بدون التأثير في تطبيقات React الأخرى على QuintoAndar.
وكان من الصعب ضمان إمكانية زحف محرّكات البحث إلى الصفحات. تفي أداة Next.js بهذا الشرط من خلال دعم العرض من جهة الخادم خارج الصندوق، وتزيل الحاجة إلى إعداد مخصّص. تسهّل هذه المستندات مشاركة المعرفة حول طريقة تنفيذ المهام، مثل جلب البيانات على الخادم وإعداد برامج جديدة لتطوير البرامج. يُعرَف العرض من جهة الخادم أيضًا بأنّه يحسّن الأداء، مثل سرعة عرض أول محتوى مرئي (FCP).
ويوفّر إطار العمل ميزات أخرى متوافقة مع الأداء، مثل تقسيم الرموز التلقائي والجلب المسبق. على الرغم من أن الهيكل الحالي قدم مثل هذه الميزات بالفعل، إلا أن العمل الإضافي المطلوب من المطورين توقّف عن اعتمادهم. على سبيل المثال، كان يجب تقسيم الرمز على مستوى الصفحة أو المكوِّن يدويًا.
تحسين موارد JavaScript
تتمثّل الخطوة الأولى في إزالة الرموز غير المستخدَمة. لقد اطّلعنا على تقارير أداة تحليل حزمة Webpack التي تعرض محتوى كل حزمة JavaScript وراجعنا جميع النصوص البرمجية التابعة لجهات خارجية بعناية. ونتيجةً لذلك، تمكّنا من إزالة بعض مكتبات التتبُّع التي لم يتم استخدامها في هذه الصفحة تحديدًا.
بعد ذلك، قيّم فريقنا تكلفة أداء الميزات الحالية. على سبيل المثال، تطلّب زر "أعجبني" الكثير من ملفات JavaScript ليعمل. ومع ذلك، في صفحة الوحدات السكنية، تفاعل أقل من 0.5٪ من المستخدمين مع الزر، وهو متاح ويتم استخدامه بشكل أكثر تكرارًا في أجزاء أخرى من تطبيقنا. بعد مناقشة شملت كل من الهندسة والمنتج، قررنا إزالة هذه الميزة.
وقد تم تطبيق تحسينات JavaScript أخرى، مثل الضغط الثابت باستخدام Brotli، والذي تم إجراؤه في وقت الإصدار باستخدام BrotliWebpackPlugin، وتم تطبيقه أيضًا على أنواع أخرى من الموارد الثابتة. في البداية، كنّا نعتمد على عملية الضغط التي توفرها شبكة توصيل المحتوى (CDN)، وخفّضت Brotli حجم JavaScript بنسبة 18% مقارنةً بخدمة gzip. ولكن بعد ذلك، تحوّلنا إلى استخدام ضغط Brotli في وقت الإصدار، وتمكّنا من تحقيق تخفيض بنسبة 24%.
تحسين موارد الصور
توجد صورة الجزء الرئيسي تشغل معظم منطقة الجزء المرئي من الصفحة في إصدار الهاتف المحمول. ويحدث ذلك أيضًا بسبب سرعة عرض أكبر محتوى مرئي (LCP) للصفحة.
في السابق، كانت جميع الصور تحتوي على السمتَين srcset وsizes لعرض الصور المتجاوبة مع مختلف الأجهزة. استخدمنا أيضًا Thumbor لتغيير حجم الصور عند الطلب وإعداد شبكة توصيل المحتوى (CDN) لتخزينها مؤقّتًا بكفاءة.
تحتوي الأجهزة الجوّالة الحديثة على شاشات ذات كثافة عالية جدًا من وحدات البكسل، ما يعني أنّ المتصفّح سيعرض نسخًا بمعدّل 3 أضعاف أو 4 مرات من الصورة، في حال توفّرها. مع زيادة درجة الدقة، يصبح من الصعب على العين البشرية إدراك الاختلافات، ولكن ستزيد أحجام الملفات بغض النظر عن ذلك. من خلال وضع حدّ أقصى لدقة الصورة، يتم تحسين حجم الصورة بدون التأثير سلبًا في تجربة المستخدم. قمنا بتقييد صورة الجزء الرئيسي بحيث تعرض الإصدار 2x على الأكثر، والتي تكون أصغر بنسبة 35٪ تقريبًا من الإصدار 3x وأصغر بنسبة 50٪ من الإصدار 4x.
في النهاية، استخدمنا استراتيجية التحميل المُسبق لتنزيله وعرضه في أقرب وقت ممكن، ونتطلّع إلى تحسين مقياس LCP.
<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">
يشمل مكوِّن الصورة المضمَّن في Next.js العديد من هذه التحسينات مثل تغيير الحجم المتجاوب والتحميل حسب الأولوية. أثناء هذا المشروع، لم ننقل الصور الحالية لاستخدام هذا المكوِّن، ولكننا نخطط لاستخدامه في ميزات جديدة.
تقليل تغيُّر التصميم
حدثت بعض المشاكل في صفحة الوحدات السكنية المرتبطة بمتغيّرات التصميم التراكمية (CLS). تم عرض العناصر المسؤولة عن متغيّرات التصميم في برنامج العميل فقط، مثلاً، تعديل الترميز من جهة الخادم باستخدام المكوّنات التي يعرضها العميل، أو الصور بدون تحديد السمتَين width وheight.
ولحلّ هذه المسائل، نحدّد الأبعاد الدقيقة لهذه العناصر متى أمكن، أو نحدّد القيم المقدَّرة باستخدام min-height. تتوفّر خيارات إضافية مثل استخدام السمة aspect-ratio في خدمة مقارنة الأسعار (CSS). أنشأنا أيضًا عناصر نائبة لمنع المكونات المعروضة ديناميكيًا من التسبب في متغيّرات التصميم.
طرح التغييرات تدريجيًا
أراد فريقنا التحقق من أن الإصدار المحسّن من صفحة مركز الوحدات السكنية للتأكد من أن تجربة المستخدم ستكون أفضل. لتحقيق ذلك، اعتمدنا استراتيجية الطرح التدريجي:
- في المرحلة الأولى، تم نشر الإصدار الجديد لعدد قليل من عناوين URL التي تم اختيارها بعناية، وبالتالي لن يراها سوى عدد قليل من المستخدمين يوميًا.
- وفي المرحلة الثانية، تم نشره للمزيد من الصفحات، وهو ما يستقبل بضعة آلاف من المستخدمين يوميًا؛
- وفي المرحلة الثالثة والأخيرة، تم نشر الإصدار لجميع الصفحات، واكتملت عملية الطرح لجميع المستخدمين.
خلال هذه الفترة، عمل الفريق الهندسي باستمرار على قياس أداء الصفحات في مرحلة الإنتاج ومواصلة العمل على إجراء التحسينات. بالإضافة إلى ذلك، قام الفريق بمقارنة مقاييس الأعمال بين الإصدارين الجديدة والسابقة. وكانت النتائج خلال فترة التحقق هذه واعدة.
النتائج
استخدم الفريق SpeedCurve لإجراء اختبارات اختبارية باستمرار على صفحة الوحدات السكنية. في ما يلي نتائج الإصدار المخصص للأجهزة الجوّالة:
| مقياس مختبَر | قبل | بعد | الفرق |
|---|---|---|---|
| سرعة عرض أكبر محتوى مرئي (LCP) | 2.41 ثانية | 1.48 ثانية | -39% |
| مدّة التفاعل (TTI) | 12.16 ثانية | 7.48 ثانية | -39% |
| إجمالي وقت الحظر (TBT) | 1124 مللي ثانية | 1056 مللي ثانية | -4% |
| متغيّرات التصميم التراكمية (CLS) | 0.0402 | 0.0093 | -77% |
أردنا أيضًا التحقق من التأثير على مستخدمينا الحقيقيين. باستخدام البيانات الميدانية التي تم جمعها من خلال خدمة Instana Website Monitoring، نظرنا في الفترة التي تبلغ شهرًا واحدًا قبل عملية الطرح وبعدها. وبمقارنة الشريحة المئوية الخامسة والسبعين لمستخدمي الأجهزة الجوّالة، وجدنا أنّ سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) قد انخفضت بنسبة 26%، وانخفضت قيمة FID بنسبة 72%.
توفّر إحصاءات PageSpeed تقريرًا عن بيانات الحقول لآخر 28 يومًا. كانت صفحة الوحدات السكنية التي وصل إليها أكبر عدد من المستخدمين وحدها تحتوي على بيانات كافية لإنشاء تقرير لمستخدمي الأجهزة الجوّالة. اعتبارًا من تشرين الثاني (نوفمبر) 2021، سيتم إدراج جميع "مؤشرات أداء الويب الأساسية" ضمن مجموعة البيانات "الجيدة".
خلال الطرح التدريجي، لاحظنا انخفاضًا في معدلات الارتداد. عند الانتهاء من إصدار جميع الصفحات، أظهرت إحصاءات Google انخفاضًا بنسبة 46% في معدل الارتداد، وزيادة بنسبة 87% في عدد الصفحات لكل جلسة، وزيادة بنسبة 49% في متوسط مدة الجلسة. كان الانخفاض في معدل الارتداد أكبر بالنسبة لعمليات البحث المدفوعة، حيث وصل إلى انخفاض بنسبة 59%، وهي علامة إيجابية عندما يتعلق الأمر بالاستثمار في إعلانات الدفع بالنقرة (PPC).
بالنسبة إلى التأثير في مقاييس الأعمال، حلّلنا معدلات الإحالات الناجحة لمعاملات مثل جدولة جولة والتقدّم بطلب لاستئجار عقار أو شرائه. بينما كان لا يزال يتم طرح التحسينات، قارن فريقنا الإحالات الناجحة بين الإصدار السابق والجديد. وفي الأسبوع نفسه، شهدت مجموعة الصفحات التي تحتوي على النسخة الجديدة زيادة في الإحالات الناجحة بنسبة 5%، بينما شهدت الصفحات الأخرى انخفاضًا طفيفًا في المقياس نفسه.
الخلاصة
هذا المشروع هو الجزء الأول من جهود نقل البيانات على المدى الطويل من التفاعل بدون إطار عمل إلى Next.js. قدمت الفرق التي عملت في صفحة الوحدات السكنية منذ ذلك الحين ملاحظات إيجابية حول تجربة المطور المحسّنة. أما الفِرق الأخرى التي اضطرت إلى تشغيل تطبيقات ويب جديدة، فقد فعلت ذلك بالفعل باستخدام Next.js. نعتقد أنّ Next.js سيبسّط جهود الصيانة وسينشئ أرضية مشتركة بين التطبيقات المختلفة.
بشكل عام، كان مركز محتوى الوحدات السكنية ينمو بشكلٍ مستمر من حيث العدد المطلق للمستخدمين والمعاملات. وعلى المدى الطويل، ساهمت العديد من العوامل في ذلك، مثل توسيع نطاق عمليات QuintoAndar ومبادرات تحسين محركات البحث مثل تحسين فهرسة الصفحات. وخلال فترة هذا المشروع، لاحظنا أنّ أداء الصفحة يُعدّ أحد هذه العوامل التي يُحتمل أن تُحدث تأثيرًا إيجابيًا في الإحالات الناجحة.
نتوجّه بالشكر الخاص إلى بيدرو كارمو، مدير المنتجات في فريق تحسين محركات البحث، على الاطّلاع على تفاصيل بيانات المستخدمين وإنشاء كل تحليلات الإحالات الناجحة الواردة في دراسة الحالة هذه.