خطط لتحسين مقياس متغيّرات التصميم التراكمية (CLS) ليصبح أكثر إنصافًا للصفحات الطويلة الأمد.
لقد أوضحنا مؤخرًا (فريق مقاييس السرعة في Chrome) بحثنا الأولي حول خيارات جعل مقياس متغيّرات التصميم التراكمية (CLS) أكثر إنصافًا للصفحات المفتوحة لفترة طويلة. لقد تلقّينا العديد من الملاحظات المفيدة جدًا، وبعد إكمال التحليل على نطاق واسع، وضعنا اللمسات الأخيرة على التغيير الذي نخطّط لإجرائه على المقياس: الحد الأقصى لفترة الجلسة بلغ ثانية واحدة، بحد أقصى 5 ثوانٍ.
يُرجى مواصلة القراءة للاطّلاع على التفاصيل.
كيف قيّمنا الخيارات؟
لقد راجعنا جميع الملاحظات التي تلقيناها من منتدى المطورين وأخذناها في الحسبان.
لقد نفذنا أيضًا أهم الخيارات في Chrome وأجرينا تحليلاً واسع النطاق للمقاييس عبر الملايين من صفحات الويب. لقد تحققنا من أنواع المواقع الإلكترونية التي حسّنها كل خيار، وكيفية مقارنة الخيارات، خصوصًا عند النظر في المواقع التي حصلت على درجات مختلفة من خلال خيارات مختلفة. وبشكلٍ عام، وجدنا ما يلي:
- قللت جميع الخيارات من الارتباط بين الوقت المستغرَق في الصفحة ودرجة تغيُّر التصميم.
- لم يؤدِّ أي من الخيارات إلى نتيجة أسوأ لأي صفحة. لذلك، لا داعي للقلق من أنّ هذا التغيير سيؤدي إلى تفاقم النتائج الخاصة بموقعك الإلكتروني.
نقاط القرار
ما سبب أهمية فترة الجلسة؟
في مشاركتنا السابقة، تناولنا بعض استراتيجيات النوافذ المختلفة لتجميع متغيّرات التصميم معًا مع ضمان عدم زيادة النتيجة غير محدودة. فضلت الملاحظات التي تلقيناها من المطورين بشكل كبير عن استراتيجية فترة الجلسة لأنها تجمع متغيرات التصميم معًا بشكل بديهي.
لمراجعة فترات الجلسات، في ما يلي مثال:
في المثال أعلاه، تحدث العديد من متغيّرات التصميم بمرور الوقت عندما يشاهد المستخدم الصفحة. يتم تمثيل كل منها بشريط أزرق. ستلاحظ أعلاه أن الأشرطة الزرقاء لها ارتفاعات مختلفة؛ وهي تمثل درجة كل متغيّرات تصميم فردية. تبدأ نافذة الجلسة بمتغيّرات التصميم الأولى وتستمر في التوسّع حتى تكون هناك فجوة بدون أي متغيّرات في التصميم. عند حدوث تغيُّر التصميم التالي، تبدأ نافذة جلسة جديدة. نظرًا لوجود ثلاث فجوات بدون متغيّرات في التخطيط، توجد ثلاث نوافذ جلسات في المثال. وعلى غرار التعريف الحالي لمتغيّرات التصميم التراكمية (CLS)، تتم إضافة درجات كل نوبة عمل، بحيث تكون نتيجة كل نافذة هي مجموع متغيّرات التصميم الفردية الخاصة بها.
استنادًا إلى البحث الأولي، اخترنا فجوة تبلغ ثانية واحدة بين فترات الجلسات، وقد نجحت هذه الفجوة في إجراء تحليل واسع النطاق. إذًا، تساوي "فجوة الجلسة" في المثال أعلاه ثانية واحدة.
لماذا تم تحديد فترة الحد الأقصى للجلسة؟
تم تضييق نطاق استراتيجيات التلخيص إلى خيارين في بحثنا الأولي:
- متوسط النتيجة لجميع فترات الجلسات، بالنسبة إلى فترات الجلسات الكبيرة جدًا (النوافذ غير المُحاطة بفترة زمنية تبلغ 5 ثوانٍ بينها).
- النتيجة الحد الأقصى لجميع فترات الجلسات للفترات الأصغر حجمًا (بحدّ أقصى 5 ثوانٍ، مع فجوات مدتها ثانية واحدة بينها).
بعد البحث الأوّلي، أضفنا كل مقياس إلى Chrome كي نتمكّن من إجراء تحليل واسع النطاق على الملايين من عناوين URL. وفي التحليل الواسع النطاق، اكتشفنا الكثير من عناوين URL التي تحتوي على أنماط متغيّرات في التصميم مثل ما يلي:
في أسفل يسار الصفحة، يمكنك أن ترى أن هناك تغييرًا واحدًا صغيرًا فقط في التنسيق في فترة الجلسة 2، ما يمنحه نتيجة منخفضة للغاية. هذا يعني أن متوسط الدرجات منخفض جدًا. ولكن ماذا لو قام المطور بإصلاح هذا التغيير الصغير في التصميم؟ وبعد ذلك، يتم احتساب النتيجة فقط في النافذة رقم 1 للجلسة، ما يعني أنّ نتيجة الصفحة تضاعف تقريبًا. سيكون الأمر مربكًا حقًا ولا يشجع المطورين على تحسين متغيّرات التصميم لديهم لمعرفة أن النتيجة ازدادت سوءًا. ومن الواضح أنّ إزالة هذا التغيير الصغير في التصميم يكون أفضل قليلاً بالنسبة إلى تجربة المستخدم، وبالتالي يجب ألا يؤدي ذلك إلى تدهور النتيجة.
وبسبب هذه المشكلة المتعلقة بالمتوسطات، قرّرنا المضيّ قُدمًا في استخدام النوافذ الأصغر حجمًا والمغطاة والحد الأقصى للنوافذ. لذلك في المثال أعلاه، سيتم تجاهل فترة الجلسة 2 وسيتم الإبلاغ فقط عن مجموع متغيّرات التصميم في فترة الجلسة 1.
لماذا تحتاج إلى 5 ثوانٍ؟
لقد قيّمنا أحجام النوافذ المتعددة وتوصلنا إلى أمرين:
- بالنسبة إلى النوافذ القصيرة، قد تؤدي عمليات تحميل الصفحات البطيئة والاستجابات الأبطأ لتفاعلات المستخدم إلى إيقاف عمليات تبديل التصميم إلى نوافذ متعددة وتحسين النتيجة. أردنا إبقاء النافذة كبيرة بما يكفي حتى لا تكافئ البطءات!
- هناك بعض الصفحات التي تحتوي على تدفق مستمر من متغيّرات التصميم الصغيرة. على سبيل المثال، صفحة نتائج رياضية تتغير قليلاً مع كل تحديث للنتيجة. هذه الورديات مزعجة، لكنها لا تزعجك أكثر بمرور الوقت. لذلك أردنا التأكد من تخصيص النافذة لهذه الأنواع من متغيرات التصميم.
بوضع هذين الأمرين في الاعتبار، ومقارنة مجموعة متنوعة من أحجام النوافذ على العديد من صفحات الويب في الواقع، توصلنا إلى أن 5 ثوانٍ ستكون حدًا مناسبًا لحجم النافذة.
كيف سيؤثر ذلك في نتيجة متغيّرات التصميم التراكمية لصفحتي؟
وبما أنّ هذا التعديل يضع حدًا لمتغيّرات التصميم التراكمية (CLS) لإحدى الصفحات، لن تحصل أي صفحة على نتيجة أسوأ نتيجةً لهذا التغيير.
واستنادًا إلى تحليلنا، لن تشهد% 55 من المصادر أي تغيير في متغيّرات التصميم التراكمية (CLS) على الإطلاق عند الشريحة المئوية الخامسة والسبعين. ويرجع ذلك إلى أنّ صفحاتهم إما لا تحتوي حاليًا على أي متغيّرات في التنسيق أو أنّ التحولات التي يجرونها محصورة بالفعل في نافذة جلسة واحدة.
ستشهد بقية المصادر نتائج محسّنة عند الشريحة المئوية الخامسة والسبعين مع هذا التغيير. سيشهد معظمهم تحسنًا طفيفًا، ولكن حوالي 3% سيشهدون تحسنًا في درجاتهم من الحصول على تقييم "بحاجة إلى تحسين" أو "ضعيف" إلى الحصول على تقييم "جيد". تستخدم هذه الصفحات عادةً أدوات تمرير لا متناهية أو تتضمّن العديد من التحديثات البطيئة لواجهة المستخدم، كما هو موضّح في مشاركتنا السابقة.
كيف يمكنني تجربة الميزة؟
سنعدّل أدواتنا لاستخدام تعريف المقياس الجديد قريبًا. وحتى ذلك الحين، يمكنك تجربة الإصدار المحدَّث من متغيّرات التصميم التراكمية (CLS) على أي موقع إلكتروني باستخدام أمثلة لعمليات تنفيذ JavaScript أو الشوكة في إضافة "مؤشرات أداء الويب".
شكرًا لكل من قضى وقتًا في قراءة المشاركة السابقة وتقديم ملاحظاته.