حل مشكلات CLS في موقع التجارة الإلكترونية المدعوم من Next.js (دراسة حالة)

Fairprice هو أحد أكبر متاجر البقالة عبر الإنترنت في سنغافورة. نحن نبحث باستمرار عن مجالات الفرص لتحسين تجربة التسوق عبر الإنترنت للمستخدم. يعد الأداء أحد الجوانب الأساسية لضمان حصول مستخدمينا على تجربة مستخدم ممتعة بغض النظر عن أجهزتهم أو اتصال الشبكة.

هناك العديد من مؤشرات الأداء الرئيسية (KPI) التي تقيس نقاطًا مختلفة أثناء دورة حياة صفحة الويب (مثل TTFB و domInteractive و onload ) ، لكن هذه المقاييس لا تعكس كيفية تعامل المستخدم النهائي مع الصفحة.

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

هناك العديد من مقاييس الأداء التي تتمحور حول المستخدم لقياس نقاط مختلفة في دورة حياة الصفحة مثل FCP و LCP و FID و CLS وما إلى ذلك. بالنسبة لدراسة الحالة هذه ، سنركز بشكل أساسي على CLS.

يقيس CLS النتيجة الإجمالية لجميع تغييرات التخطيط غير المتوقعة التي تحدث بين وقت بدء تحميل الصفحة وحتى إلغاء تحميلها.

"

لذلك فإن الحصول على قيمة CLS منخفضة للصفحة يضمن عدم وجود تغييرات عشوائية في التخطيط تسبب إحباط المستخدم. كتب باري بولارد مقالة ممتازة ومتعمقة عن CLS.

كيف اكتشفنا مشكلة CLS في صفحة منتجاتنا

نحن نستخدم Lighthouse و WebPagetest كأدوات اختبار تركيبية للأداء لقياس CLS. نستخدم أيضًا مكتبة Web-الحيوية لقياس CLS للمستخدمين الحقيقيين. بصرف النظر عن ذلك ، نتحقق من قسم تقرير Google Search Console Core Web Vitals للحصول على فكرة عن أي مشكلات CLS محتملة في أي من صفحاتنا. أثناء استكشاف قسم التقرير ، وجدنا أن العديد من عناوين URL من صفحة تفاصيل المنتج تحتوي على أكثر من 0.1 قيمة CLS مما يشير إلى حدوث بعض أحداث تغيير التخطيط الرئيسية هناك.

تصحيح مشكلة CLS باستخدام أدوات مختلفة

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

لذلك قمنا بتشغيل المنارة للتحقق مما إذا كان بإمكانها العثور على أي عنصر يمكن أن يؤدي إلى تغيير كبير في التخطيط ، فقد أبلغنا عن CLS إلى .004 وهو منخفض جدًا.

تحتوي صفحة تقرير Lighthouse على قسم تشخيصي. هذا أيضًا لم يُظهر أي عنصر يتسبب في ارتفاع قيمة CLS.

ثم أجرينا WebpageTest وقررنا التحقق من عرض شريط الصور:

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

تتمثل ميزة CLS في أنها تسجل درجات تغيير التخطيط الفردي خلال العمر الافتراضي الكامل للصفحة وإضافتها.

"

ملاحظة : تم تغيير طريقة قياس CLS منذ يونيو 2021.

نظرًا لأن Lighthouse و WebpageTest لم يتمكنوا من اكتشاف أي عنصر أدى إلى حدوث تغيير كبير في التخطيط مما يعني أنه كان يحدث بعد تحميل الصفحة الأولية ربما بسبب بعض إجراءات المستخدم. لذلك قررنا استخدام ملحق Web Vitals Google Chrome لأنه يمكنه تسجيل CLS على صفحة أثناء تفاعل المستخدم معها. بعد تنفيذ إجراءات مختلفة وجدنا أن درجة تحول التخطيط تزداد عندما يستخدم المستخدم ميزة تكبير الصورة.

للتحقق مما إذا كان تغيير التخطيط يحدث أثناء تمرير الماوس على الصورة ، استخدمنا مقتطف الشفرة أدناه من https://web.dev/cls/ الذي يضيف console.log عند حدوث تغيير التخطيط:

 let cls = 0; new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { if (!entry.hadRecentInput) { cls += entry.value; console.log('Current CLS value:', cls, entry); } }}).observe({type: 'layout-shift', buffered: true});

في مزيد من التحقيق ، وجدنا أن ASDA واجهت نوعًا مشابهًا من المشكلات وقمنا برفعها بخصوص الكروم.

السبب الجذري

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

تساعد ميزة تكبير الصورة مستخدمينا في الحصول على شكل المنتج وطابعه بالإضافة إلى ضمان أنه البديل الصحيح للمنتج الذي يرغبون في شرائه.

لقد استخدمنا مكتبة react-image zoom التفاعلية لبناء وظيفة تكبير الصورة هذه.

عادةً ما تحتوي مكتبات Image Magnify على عدسة (مربع يتحرك عندما يتحرك الماوس داخل الصورة). نظرًا لأن هذه العدسة تغير موضعها العلوي والأيسر مع حركة الماوس ، فقد تم اكتشافها على أنها تحول في التخطيط يؤدي إلى تشغيل CLS. لقد فحصنا صفحة المكتبة بالإضافة إلى مكتبات تفاعل أخرى مماثلة ( react-image-magnify ، react-image-zoom ، react-image-magnifiers ) ووجدنا أن جميعهم يعانون من نفس مشكلة CLS.

كيف أصلحناه

لقد لاحظنا أن react-image-zoom كان يستخدم مكتبة js-image-zoom . لذلك كان علينا تعديل مكتبة js-image zoom لإصلاح المشكلة.

الحل واضح ومباشر. أثناء تحرك الماوس فوق صورة المنتج ، يتحرك عنصر عدسة الصورة عن طريق تغيير موضعه الأيسر والأعلى. لإصلاح المشكلة ، استخدمنا transform translate الذي ينقل العنصر إلى طبقة جديدة ، أي أن أي حركة تحدث في هذه الطبقة الجديدة لا تسبب تحولًا في التخطيط بعد الآن:

لقد قمت أيضًا بإنشاء PR إلى الريبو الأصلي بحيث يمكن للمطورين الآخرين الذين يستخدمون هذه المكتبة التخلص من مشكلة CLS.

أثر التغيير

بعد نشر الكود في الإنتاج ، تم إصلاح CLS في صفحة تفاصيل المنتج وتم تقليل عدد الصفحات المتأثرة بـ CLS بنسبة 98٪:

نظرًا لأننا استخدمنا transform ، فقد ساعد أيضًا في جعل الصورة مكبرة لتجربة أكثر سلاسة للمستخدمين.

ملاحظة : كتب Paul Irish مقالة ممتازة حول هذا الموضوع.

التغييرات الرئيسية الأخرى التي أجريناها على CLS

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

• خطوط الويب:
  لقد لاحظنا أن التحميل المتأخر للخطوط يتسبب في إحباط المستخدم منذ وميض المحتوى كما أنه يتسبب في قدر من تغييرات التخطيط. لتقليل هذا ، أجرينا بعض التغييرات:

  • لقد استضفنا الخطوط ذاتيًا بدلاً من التحميل من CDN التابع لجهة خارجية.
  • نقوم بتحميل الخطوط مسبقًا.
  • نحن نستخدم عرض الخط اختياري.

• الصور:
  يؤدي فقدان قيمة الارتفاع أو العرض في الصورة إلى إزاحة العنصر بعد الصورة بمجرد تحميلها. ينتهي هذا الأمر بأن يصبح مساهمًا رئيسيًا في CLS. نظرًا لأننا نستخدم Next.js ، فقد استفدنا من مكون الصورة المدمج المسمى next/images . يشتمل هذا المكون على العديد من أفضل الممارسات المتعلقة بالصور. إنه مبني على رأس علامة HTML <img> ويمكن أن يساعد في تحسين LCP و CLS. أوصي بشدة بقراءة هذا RFC لمعرفة الميزات والمزايا الرئيسية لاستخدامه.

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

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

كتب آدي عثماني مقالاً مفصلاً عن هذا النهج وأنا أوصي بشدة بمراجعته.

الماخذ الرئيسية

• بينما يساعد Lighthouse و WebpageTest في اكتشاف مشكلات الأداء التي تحدث حتى تحميل الصفحة ، لا يمكنهم اكتشاف مشكلات الأداء بعد تحميل الصفحة.
• يمكن لملحقات Web Vitals اكتشاف تغييرات CLS الناتجة عن تفاعلات المستخدم ، لذا إذا كانت الصفحة تحتوي على قيمة CLS عالية ولكن Lighthouse أو WebpageTest يبلغان CLS منخفضًا ، فيمكن أن يساعد ملحق Web Vitals في تحديد المشكلة.
• تستند بيانات Google Search Console إلى بيانات المستخدمين الحقيقيين بحيث يمكن أن تشير أيضًا إلى مشكلات الأداء المحتملة التي تحدث في أي وقت في دورة حياة الصفحة. بمجرد اكتشاف مشكلة وإصلاحها ، يمكن أن يساعد فحص قسم التقرير مرة أخرى في التحقق من فعالية إصلاح الأداء. تنعكس التغييرات خلال أيام في قسم تقرير مؤشرات الويب الحيوية.

افكار اخيرة

على الرغم من صعوبة تصحيح مشكلات CLS نسبيًا ، فإن استخدام مجموعة من الأدوات المختلفة حتى تحميل الصفحة (Lighthouse ، WebPageTest) وامتداد Web Vitals (بعد تحميل الصفحة) يمكن أن يساعدنا في تحديد المشكلة. إنه أيضًا أحد المقاييس التي تمر بالكثير من التطوير النشط لتغطية مجموعة واسعة من السيناريوهات وهذا يعني أن كيفية قياسها ستتغير في المستقبل. نحن نتابع https://web.dev/evolving-cls/ لمعرفة أي تغييرات قادمة.

أما بالنسبة لنا ، فنحن نعمل باستمرار على تحسين "أساسيات الويب الأساسية" الأخرى أيضًا. مؤخرًا ، قمنا بتنفيذ تحميل مسبق للصور سريع الاستجابة وبدأنا في تقديم الصور بتنسيق WebP مما ساعدنا على تقليل 75٪ من حمولة الصور وتقليل LCP بنسبة 62٪ ومؤشر السرعة بنسبة 24٪. يمكنك قراءة المزيد من التفاصيل حول التحسين لتحسين LCP ومؤشر السرعة أو متابعة مدونتنا الهندسية للتعرف على الأعمال المثيرة الأخرى التي نقوم بها.

نود أن نشكر Alex Castle لمساعدتنا في تصحيح مشكلة CLS على صفحة المنتج وحل المراوغات في تنفيذ next/images .