الانتقال إلى المحتوى
التعريف

CLS A/B testing

CLS (Cumulative Layout Shift) هو أحد مؤشرات Core Web Vitals الثلاثة التي حدّدتها Google، ويقيس الاستقرار البصري لصفحة الويب: أي الطريقة التي تتحرك بها العناصر بشكل غير متوقع أثناء التحميل.

CLS (Cumulative Layout Shift) هو أحد مؤشرات Core Web Vitals الثلاثة التي حدّدتها Google، ويقيس الاستقرار البصري لصفحة الويب: أي الطريقة التي تتحرك بها العناصر بشكل غير متوقع أثناء التحميل.
في إطار A/B testing، يُعد CLS فخًا شائعًا يمكن أن يُشوّه نتائج الاختبار أو يُضر بتجربة المستخدم، حتى لو بدت النسخة المُختبرة أفضل من حيث المضمون.

🎯 لماذا يُعد هذا الأمر حاسمًا في A/B testing

يهدف A/B test إلى عزل أثر تغيير معيّن على سلوك المستخدم (النقر، التحويل...). لكن إذا تسببت النسخة في انزياح بصري (مثل: زر يقفز، صورة تدفع المحتوى إلى الأسفل)، فإن:

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

💡 ارتفاع CLS بشكل مفرط لن يظهر في مؤشرات الأداء الرئيسية التقليدية، لكنه سيؤثر على CVR دون أن نفهم السبب.

🧪 كيف يمكن لـ A/B test أن يتسبب في CLS

إليك السيناريوهات الشائعة التي تتسبب فيها نسخة ما في CLS دون قصد:

  • إضافة صورة أو كتلة HTML دون حجز مساحة لها: يؤدي المحتوى إلى "دفع" بقية الصفحة بمجرد تحميله،
  • تحميل سكريبتات A/B test عبر tag manager بطيء (بدلًا من الدمج المباشر في <head>)،
  • إدراج ديناميكي لرسالة أو شريط ترويجي فوق المحتوى دون حجز مساحة له،
  • تغيير الخط أو وزن الخط دون preload، مما يتسبب في "قفزات" في النص،
  • استخدام رسوم متحركة CSS غير مُتحكَّم بها (مثل: تأثير slide أو fade-in يعيد رسم الصفحة).

📌 مخاطر مباشرة في اختبار A/B:

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

✅ أفضل ممارسات CRO لتجنّب التأثير على CLS:

  1. تخصيص المساحة اللازمة مسبقًا لكل عنصر يُضاف ضمن أحد المتغيّرات (مثال: حجز ارتفاع الصورة باستخدام خاصية CSS aspect-ratio أو عناصر نائبة placeholder)،
  2. تجنّب الإدراج المتأخر للمحتوى عبر JavaScript (يُفضَّل الإدراج من جهة الخادم أو في أقرب وقت ممكن من جهة العميل)،
  3. اختبار جميع المتغيّرات باستخدام Lighthouse أو PageSpeed Insights قبل النشر للتحقق من نتيجة CLS،
  4. دمج أكواد A/B test مباشرة ضمن الكود (head) لتجنّب ظاهرة الوميض (flickering)،
  5. قياس مؤشرات Core Web Vitals مباشرةً (live) لكل متغيّر باستخدام أداة مثل Web Vitals Extension أو SpeedCurve أو Datadog RUM أو BigQuery + GA4.

انتقل من التعريف إلى التطبيق

يقوم مستشارونا بتدقيق مساراتكم، وترتيب أولويات الروافع، وإدارة خارطة طريق التحسين الخاصة بكم. لنتحدث لمدة 30 دقيقة حول تحدياتكم.