كيفية نجاح شركة QuintoAndar في زيادة معدلات الإحالات الناجحة والصفحات لكل جلسة من خلال تحسين أداء الصفحات

حقّق المشروع الذي يركّز على تحسين "مؤشرات أداء الويب الأساسية" والانتقال إلى Next.js زيادة في معدلات الإحالات الناجحة بنسبة% 5 وزيادة عدد الصفحات في الجلسة بنسبة% 87.

Daniela Sayuri Yassuda

QuintoAndar هي شركة برازيلية في مجال تكنولوجيا الإعلان تقدم منتجاتها حلولاً رقمية شاملة للعقارات. هذا العام، نفّذنا مشروعًا تركّز على تحسين أداء مركز المحتوى في تطبيقنا، وحقّقنا نتائج مشجّعة في زيادة عدد زيارات المستخدمين ومقاييس الإحالات الناجحة.

التحديات

يتضمّن تطبيقنا مركزًا لمحتوى الشقق المشترَكة يتضمّن أكثر من 40,000 صفحة، حيث يمكن للمستخدمين الحصول على معلومات عن العقارات التي يملكونها والاطّلاع على صور للمناطق المشتركة والتعرّف على معلومات عن الحي والعثور على بيانات العقارات المتاحة للإيجار أو البيع. هذه الصفحات مهمة جدًا لشركة QuintoAndar:

• وهي مصدر مهم للزيارات الواردة من نتائج البحث المجانية، مع زيادة عدد المستخدمين الذين يأتون من نتائج محرّكات البحث بشكل مطرد.
• تحقّق هذه الصفحات معدّلات إحالات ناجحة مرتفعة على المدى المتوسط إلى الطويل مقارنةً بالصفحات الأخرى.

ومع ذلك، واجهنا بعض التحديات في ما يتعلّق بالأداء وتجربة المستخدم في هذه الصفحات:

• وإذا تم قياس أداء هذه الأجهزة من خلال مؤشرات أداء الويب الأساسية، لم يتم تحسين أدائها، كما كانت هناك مشاكل معروفة تتعلّق بطء عمليات تحميل الصفحات وبطء الاستجابة لإدخالات المستخدم وعدم ثبات التنسيق.
• كانت معدلات الارتداد مرتفعة، حتى لو توقّعنا أن تكون أعلى من أجزاء أخرى من التطبيق.
• إنّ التحديث المتعلّق بتجربة الصفحة في "بحث Google"، والذي لم يتم إطلاقه بعد في ذلك الوقت، يتضمّن مؤشرات Core Web Vitals في خوارزمية الترتيب، ما يعني أنّ أداء الصفحة يمكن أن يؤثّر في طريقة عرض نتائج البحث.

في الوقت نفسه، حددنا بعض فرص تجربة المطورين التي يمكن أن تحقق مكاسب في مشاريع أخرى على مستوى الشركة:

• تم إنشاء منطق العرض من جهة الخادم، الذي يعرض جميع الصفحات التي تجذب عددًا كبيرًا من الزيارات، بما في ذلك صفحات الشقق السكنية، داخل الشركة، وأصبح معقدًا جدًا للحفاظ عليه وإعداد الموظفين الجدد.
• تتطلّب الميزات الأساسية لتحقيق أداء جيد للتطبيق، مثل تقسيم الرموز البرمجية، أيضًا إعدادًا مخصّصًا بالإضافة إلى عمل يدوي من المطوّرين.
• لدى 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 مرات، إذا كان ذلك متاحًا. ومع زيادة درجة الدقة، يصبح من الصعب على العين البشرية تمييز الاختلافات، ولكن ستزداد أحجام الملفات بغض النظر عن ذلك. أدّى وضع حد أقصى لدقة الصورة إلى تحسين حجم الصورة بدون التأثير في تجربة المستخدم. لقد اقتصرنا على عرض نسخة الصورة الرئيسية بمقدار ضعف حجمها كحد أقصى، وهي أصغر بنسبة %35 تقريبًا من النسخة بمقدار ثلاثة أضعاف و%50 من النسخة بمقدار أربعة أضعاف.

في الختام، استخدمنا استراتيجية التحميل المُسبَق لتنزيله وعرضه في أقرب وقت ممكن، ونتطلع إلى تحسين مقياس LCP.

<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">

يشتمل مكوِّن الصور المضمَّن في Next.js على العديد من هذه التحسينات، مثل تغيير الحجم المتجاوب والتحميل حسب الأولوية. خلال هذا المشروع، لم نقلّل الصور الحالية لاستخدام هذا المكوّن، ولكننا نخطّط لاعتماده في الميزات الجديدة.

الحدّ من متغيّرات التصميم

كانت صفحة الشقة السكنية تتضمّن بعض المشاكل المتعلّقة بمقياس متغيّرات التصميم التراكمية (CLS). كان يتم عرض العناصر المسؤولة عن متغيّرات التصميم في العميل فقط، مثل إعادة تحميل الترميز من جهة الخادم باستخدام المكوّنات التي يعرضها العميل، أو الصور بدون سمتَي width وheight محدّدتَين.

لحلّ هذه المشاكل، نضبط أبعادًا دقيقة لهذه العناصر كلما أمكن ذلك، أو نضبط قيمًا مقدَّرة باستخدام min-height. هناك المزيد من الخيارات، مثل استخدام سمة CSS "aspect-ratio". أنشأنا أيضًا عناصر نائبة لمنع العناصر المعروضة ديناميكيًا من التسبب في تغييرات في التنسيق.

طرح التغييرات تدريجيًا

أراد فريقنا التحقق من أن الإصدار المحسّن من صفحة مركز الوحدات السكنية للتأكد من أن تجربة المستخدم ستكون أفضل. ولتحقيق ذلك، اعتمدنا استراتيجية طرح تدريجية:

1. في المرحلة الأولى، تم نشر الإصدار الجديد لعدد قليل من عناوين URL التي تم اختيارها بعناية، وبالتالي لن يراها سوى عدد قليل من مئات المستخدمين يوميًا؛
2. في المرحلة الثانية، تم نشره لعدد أكبر من الصفحات، ما يمثّل بضعة آلاف من المستخدمين يوميًا.
3. في المرحلة الثالثة والأخيرة، تم نشرها لجميع الصفحات، واستكملت عملية الطرح لجميع المستخدمين.

خلال هذه الفترة، كان الفريق الهندسي يقيس باستمرار أداء الصفحة في مرحلة الإنتاج واستمر في العمل على إجراء التحسينات. بالإضافة إلى ذلك، قارن الفريق مقاييس الأعمال بين الإصدارَين الجديد والسابق. كانت النتائج في فترة التحقّق هذه مبشرة.

النتائج

استعان الفريق بخدمة SpeedCurve لإجراء اختبارات معملية باستمرار على صفحة الوحدة السكنية. في ما يلي النتائج الخاصة بإصدار الأجهزة الجوّالة:

أردنا أيضًا التحقّق من تأثير هذه التغييرات على المستخدمين الفعليين. باستخدام البيانات الميدانية التي تم جمعها من خلال Instana Website Monitoring، اطّلعنا على فترة شهر واحد قبل الطرح وبعده. عند مقارنة القيمة المئوية التسعون لمستخدمي الأجهزة الجوّالة، تبيّن لنا أنّ مقياس LCP انخفض بنسبة %26، ومقياس FID انخفض بنسبة %72.

توفّر إحصاءات PageSpeed تقريرًا لبيانات الحقل عن آخر 28 يومًا. كانت صفحة الشقق الأكثر زيارة وحدها تحتوي على بيانات كافية لإنشاء تقرير لمستخدمي الأجهزة الجوّالة. اعتبارًا من تشرين الثاني (نوفمبر) 2021، تم تصنيف جميع "مؤشرات أداء الويب الأساسية" ضمن الفئة "جيّد".

أثناء الطرح التدريجي، لاحظنا انخفاضًا في معدلات الارتداد. بحلول الوقت الذي انتهينا فيه من طرح الإصدار لجميع الصفحات، أظهرت إحصاءات Google انخفاضًا بنسبة% 46 في معدّل الارتداد، وزيادةً بنسبة% 87 في عدد الصفحات لكلّ جلسة، وزيادةً بنسبة% 49 في متوسّط مدّة الجلسة. وكان انخفاض معدّل الارتداد أكبر في نتائج البحث المدفوعة، حيث وصل إلى 59%، ما يشكّل علامة إيجابية في ما يتعلق باستثمارات الإعلانات التي تستخدِم نموذج الدفع لكل نقرة.

أما بالنسبة إلى التأثير في مقاييس النشاط التجاري، فقد حلّلنا معدّلات الإحالات الناجحة للمعاملات، مثل تحديد موعد لجولة والتقدّم بطلب لاستئجار أو شراء عقار. وبينما كان يتم طرح التحسينات، قارَن فريقنا الإحالات الناجحة بين الإصدار السابق والإصدار الجديد. في الأسبوع نفسه، سجّلت مجموعة الصفحات التي تتضمّن الإصدار الجديد زيادة في الإحالات الناجحة بنسبة% 5، في حين سجّلت الصفحات الأخرى انخفاضًا طفيفًا في المقياس نفسه.

الخاتمة

هذا المشروع هو الجزء الأول من جهود نقل البيانات على المدى الطويل من React بدون إطار عمل إلى Next.js. وقد قدّمت الفِرق التي عملت على صفحة الشقق السكنية منذ ذلك الحين ملاحظات إيجابية حول تجربة المطوّرين المحسّنة. سبق أن استخدمت فِرق أخرى Next.js لإنشاء تطبيقات ويب جديدة. نعتقد أنّ Next.js سيبسّط جهود الصيانة ويرسي أرضية مشتركة بين التطبيقات المختلفة.

بشكل عام، يشهد مركز المحتوى الخاص بالشقق المشترَكة نموًا مستمرًا من حيث العدد المطلق للمستخدمين والمعاملات. في التحليل على المدى الطويل، هناك العديد من العوامل التي تساهم في ذلك، مثل توسيع نطاق عمل QuintoAndar ومبادرات تحسين محركات البحث، مثل تحسين فهرسة الصفحات. خلال هذا المشروع، تبيّن لنا أنّ أداء الصفحة هو أيضًا أحد هذه العوامل التي تتضمّن إمكانات كبيرة للتأثير الإيجابي في الإحالات الناجحة.

نشكر بيدرو كارمو، مدير المنتجات في فريق تحسين محركات البحث، على الاطّلاع على بيانات المستخدِمين وإنشاء جميع تحليلات الإحالات الناجحة الواردة في هذه الدراسة.