تحسين متغيّرات التصميم التراكمية

التعرّف على كيفية تجنُّب التغييرات المفاجئة في التنسيق لتحسين تجربة المستخدم

Addy Osmani

Barry Pollard

متغيّرات التصميم التراكمية (CLS) هو أحد مقاييس مؤشرات أداء الويب الأساسية الثلاثة. يقيس هذا المقياس عدم ثبات المحتوى من خلال الجمع بين مقدار المحتوى المرئي الذي تم نقله في إطار العرض والمسافة التي تم نقل العناصر المتأثرة بها.

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

لتقديم تجربة جيدة للمستخدم، يجب أن تسعى المواقع الإلكترونية إلى أن تكون قيمة مقياس CLS 0.1 أو أقلّ لما لا يقلّ عن% 75 من زيارات الصفحة.

تكون قيم CLS الجيدة 0.1 أو أقل. القيم السيئة أكبر من 0.25.

على عكس مؤشرات "Core Web Vitals" الأخرى، وهي قيم مستندة إلى الوقت تقاس بالثواني أو بالمللي ثانية، تكون نتيجة متغيّرات التصميم التراكمية (CLS) غير موحدة تستند إلى حساب مقدار تغيُّر المحتوى ومدى تغيُّر المحتوى.

في هذا الدليل، سنتناول تحسين الأسباب الشائعة لمتغيّرات التصميم.

في ما يلي الأسباب الأكثر شيوعًا لانخفاض قيمة مقياس CLS:

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

ملاحظة: للحصول على نظرة عامة مرئية على بعض المحتوى المعروض في هذا الدليل، يمكنك الاطّلاع على فيديو "تحسين الأداء وفقًا لمؤشرات أداء الويب الأساسية" من Google I/O 2020:

فهم أسباب متغيّرات التصميم

قبل البدء في البحث عن حلول لمشاكل CLS الشائعة، من المهم فهم نتيجة CLS ومعرفة مصدر التغيُّرات.

متغيّرات التصميم التراكمية (CLS) في الأدوات المعملية مقارنةً بالمجال

من الشائع أن يعتقد المطوّرون أنّ متغيّرات التصميم التراكمية (CLS) الذي تم قياسه من خلال تقرير تجربة المستخدم في Chrome (CrUX) غير صحيح لأنّه لا يتطابق مع متغيّرات التصميم التراكمية (CLS) الذي يقيسونه باستخدام "أدوات مطوري البرامج في Chrome" أو الأدوات الاختبارية الأخرى. قد لا تعرض أدوات مختبر أداء الويب، مثل Lighthouse، قيمة CLS الكاملة للصفحة لأنّها عادةً ما تُجري عملية تحميل بسيطة للصفحة لقياس بعض مقاييس أداء الويب وتقديم بعض الإرشادات (على الرغم من أنّ مسارات المستخدِمين في Lighthouse تتيح لك إجراء قياسات أبعد من التدقيق التلقائي في تحميل الصفحة).

تُعدّ CrUX مجموعة البيانات الرسمية لبرنامج Web Vitals، ولهذا السبب، يتم قياس متغيّرات التصميم التراكمية (CLS) على مدار فترة تشغيل الصفحة بالكامل وليس فقط أثناء التحميل الأولي للصفحة الذي تقيس أدوات المختبر عادةً.

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

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

تعرِض إحصاءات PageSpeed كلاً من قياس CLS الذي يلاحظه المستخدم من عنوان URL في قسم "التعرّف على تجربة المستخدمين"، وقياس CLS المستنِد إلى المختبر في قسم "تحديد مشاكل الأداء وحلّها". من المرجّح أنّ الاختلافات بين هذه القيم هي نتيجة متغيّرات التصميم التراكمية بعد التحميل (CLS).

في هذا المثال، تقيس CrUX قيمة CLS أكبر بكثير من Lighthouse.

ملاحظة: ستعرض "إحصاءات PageSpeed" البيانات على مستوى عنوان URL حيثما كانت متوفّرة، وستحاول الرجوع إلى البيانات على مستوى المصدر في حال عدم توفّرها. تحقَّق دائمًا من البيانات التي يتم عرضها لضمان عدم إضاعة الوقت في محاولة تتبُّع مشكلة CLS التي تظهر في الواقع على صفحات أخرى على مصدرك. في المثال السابق، نلاحظ أنّ هذه البيانات على مستوى عنوان URL، كما هو موضّح في أعلى يسار الصورة.

تحديد مشاكل وقت تحميل مقياس CLS

عندما تكون نتائج CLS في CrUX وLighthouse من PageSpeed Insights متطابقة بشكل عام، يشير ذلك عادةً إلى وجود مشكلة في CLS أثناء التحميل رصدتها أداة Lighthouse. في هذه الحالة، ستساعد أداة Lighthouse في إجراء عمليتي تدقيق لتوفير مزيد من المعلومات عن الصور التي تتسبب في حدوث متغيّرات التصميم التراكمية (CLS) بسبب عدم توفّر العرض والارتفاع، كما ستسرد أيضًا جميع العناصر التي تم تغييرها لتحميل الصفحة إلى جانب المساهمة في متغيّرات التصميم التراكمية (CLS). يمكنك الاطّلاع على عمليات التدقيق هذه من خلال الفلترة حسب عمليات تدقيق CLS:

بيانات تشخيص متغيّرات التصميم التراكمية (CLS) التفصيلية من Lighthouse.

ملاحظة: ستحدِّد أداة Lighthouse العناصر التي تم تغييرها، ولكنّها غالبًا ما تكون تلك العناصر المتأثرة وليس العناصر التي تسبّب متغيّرات التصميم التراكمية (CLS). على سبيل المثال، في حال إدراج عنصر جديد في DOM، ستظهر العناصر التي تليه في عملية التدقيق هذه، ولكن السبب الأساسي هو إضافة العنصر الجديد أعلاه. ومع ذلك، من المفترض أن يكون العنصر الذي تم نقله كافيًا لمساعدتك في تحديد السبب الأساسي وحلّه.

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

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

تحديد مشاكل CLS بعد التحميل

غالبًا ما يشير الاختلاف بين نتائج CLS في CrUX وLighthouse إلى حدوث CLS بعد التحميل. قد يكون من الصعب تتبُّع هذه التغيُّرات بدون بيانات الحقول. للمزيد من المعلومات عن جمع بيانات الحقول، يُرجى الاطّلاع على مقالة قياس عناصر متغيّرات التصميم التراكمية (CLS) في الحقل.

يمكن استخدام إضافة "مؤشرات أداء الويب" في Chrome لتتبُّع مقياس CLS أثناء تفاعلك مع الصفحة، إما في شاشة معلومات عاجلة أو في وحدة التحكّم، حيث يمكنك الحصول على مزيد من التفاصيل فوق العناصر التي تمّ نقلها.

كبديل لاستخدام الإضافة، يمكنك تصفُّح صفحة الويب أثناء تسجيل تغييرات التنسيق باستخدام أداة Performance Observer التي تم لصقها في وحدة التحكّم.

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

لمزيد من المعلومات، يُرجى الاطّلاع على تصحيح أخطاء تغيُّر تنسيق الإعلان.

بعد تحديد أيّ أسباب شائعة لقيمة CLS، يمكن أيضًا استخدام وضع مسار المستخدِم في الفترات الزمنية في Lighthouse لضمان عدم تراجع مسارات المستخدِمين المعتادة من خلال إدخال تغييرات في التنسيق.

قياس عناصر CLS في الحقل

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

تحتوي مكتبة web-vitals على وظائف تحديد مصدر تتيح لك جمع هذه المعلومات الإضافية. لمزيد من المعلومات، يُرجى الاطّلاع على تصحيح أخطاء الأداء في الميدان. بدأ أيضًا مزوّدو ميزة قياس الأداء في موقعك الإلكتروني الآخرون في جمع هذه البيانات وعرضها بالطريقة نفسها.

ملاحظة: إنّ حلول RUM التي تقيس متغيّرات التصميم التراكمية (CLS) في الحقل، بما في ذلك مكتبة web-vitals، قد تُظهر اختلافات في بيانات CrUX كما هو موضّح في المشاركة التالية: لماذا تختلف بيانات CrUX عن بيانات RUM؟. على وجه التحديد، لا يمكن قياس متغيّرات التصميم التراكمية التي تحدث في إطارات iframe من خلال واجهات برمجة تطبيقات الويب، ولكنها مرئية للمستخدم، وبالتالي يتم تضمينها في CrUX. وبالتالي، على الرغم من أنّ بيانات الحقول يمكن أن تكون قيّمة لتحديد مشاكل CLS، يُرجى العِلم أنّها قد تكون غير مكتملة في سيناريوهات معيّنة.

الأسباب الشائعة لبطء استجابة الصفحة

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

صور بدون أبعاد

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

صور لم يتم تحديد عرض أو ارتفاع لها.

الصور التي تم تحديد عرضها وارتفاعها

تأثير أداة Lighthouse 6.0 في ضبط أبعاد الصور على متغيّرات التصميم التراكمية (CLS)

سجلّ سمتَي width وheight في الصور

في الأيام الأولى من ظهور الويب، كان المطوّرون يضيفون سمتَي width وheight إلى علامات <img> لضمان تخصيص مساحة كافية على الصفحة قبل أن يبدأ المتصفّح في جلب الصور. سيؤدي هذا إلى تقليل إعادة التدفّق وإعادة التخطيط.

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

لا يتضمّن width وheight في هذا المثال وحدات. تضمن هذه الأبعاد بالبكسل أن يحتفظ المتصفّح بمنطقة 640×360 في تنسيق الصفحة. وستتم إطالة الصورة لتلائم هذه المساحة، بغض النظر عمّا إذا كانت الأبعاد الفعلية تتطابق معها.

عند طرح تصميم الويب السريع الاستجابة، بدأ المطوّرون في حذف width وheight وبدؤوا في استخدام CSS لتغيير حجم الصور بدلاً من ذلك:

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

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

هنا يأتي دور نسبة العرض إلى الارتفاع. نسبة العرض إلى الارتفاع للصورة هي نسبة عرضها إلى ارتفاعها. من الشائع أن يتم التعبير عن ذلك في شكل رقمين مفصولين بنقطتين (على سبيل المثال، 16:9 أو 4:3). بالنسبة إلى نسبة العرض إلى الارتفاع x:y، تكون الصورة بعرض x وحدة وبارتفاع y وحدة.

وهذا يعني أنّه إذا كنا نعرف أحد الأبعاد، يمكن تحديد الآخر. بالنسبة إلى نسبة العرض إلى الارتفاع 16:9:

• إذا كان ارتفاع puppy.jpg هو 360 بكسل، يكون العرض 360 x ‏ (16 / 9) = 640 بكسل.
• إذا كان عرض puppy.jpg‏ هو 640 بكسل، يكون ارتفاعها 640 x ‏ (9 / 16) = 360 بكسل.

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

أفضل الممارسات الحديثة لضبط أبعاد الصور

بما أنّ المتصفّحات الحديثة تضبط نسبة العرض إلى الارتفاع التلقائية للصور استنادًا إلى سمتَي width وheight في الصورة، يمكنك منع حدوث تغييرات في التصميم من خلال ضبط هاتين السمتَين على الصورة وتضمين ملف CSS السابق في ورقة الأنماط.

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

ستضيف بعد ذلك نسبة عرض إلى ارتفاع تلقائية استنادًا إلى السمتَين width وheight الحاليتَين للعنصر.

يحدِّد هذا المقياس نسبة العرض إلى الارتفاع استنادًا إلى سمتَي width وheight قبل تحميل الصورة. وتوفّر هذه المعلومات في بداية عملية احتساب التنسيق. بعد تحديد عرض معيّن للصورة (مثل width: 100%)، يتم استخدام نسبة العرض إلى الارتفاع لاحتساب الارتفاع.

يتم احتساب قيمة aspect-ratio هذه من خلال المتصفّحات الرئيسية أثناء معالجة صفحات HTML، بدلاً من استخدام جدول تنسيقات تلقائي لوكيل المستخدم (اطّلِع على هذه المشاركة للاطّلاع على تفاصيل أكثر حول السبب)، لذلك يتم عرض القيمة بشكل مختلف قليلاً. على سبيل المثال، يعرض Chrome هذا الأسلوب على النحو التالي في قسم "الأنماط" ضمن لوحة "العنصر":

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

يعمل Safari بنفس الطريقة، حيث يستخدم مصدر نمط سمات HTML. لا يعرض Firefox هذا aspect-ratio المحسوب على الإطلاق في لوحة المدقق، ولكنه يستخدمه لتنسيق الصفحة.

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

ملاحظة: إذا كنت تواجه صعوبة في فهم نسبة العرض إلى الارتفاع، يمكنك استخدام آلة حاسبة مساعدة.

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

إذا كانت صورتك في حاوية، يمكنك استخدام CSS لتغيير حجم الصورة إلى عرض الحاوية. نضبط height: auto; لتجنُّب استخدام قيمة ثابتة لارتفاع الصورة.

img {
  height: auto;
  width: 100%;
}

ماذا عن الصور المتجاوبة مع مختلف الأجهزة؟

عند استخدام الصور السريعة الاستجابة، تحدِّد سمة srcset الصور التي تسمح للمتصفّح باختيارها وحجم كل صورة. لضمان إمكانية ضبط سمتَي <img> width وheight، يجب أن تستخدم كل صورة نسبة العرض إلى الارتفاع نفسها.

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

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

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

يتيح Chrome وFirefox وSafari الآن ضبط width وheight على العناصر <source> ضمن عنصر <picture> محدّد:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>

الإعلانات والمحتوى المضمّن والمحتوى الآخر الذي يتم تحميله بعد وقت قصير

إنّ الصور ليست النوع الوحيد من المحتوى الذي يمكن أن يتسبب في تغييرات التنسيق. يمكن أن تؤدي الإعلانات والعناصر المضمّنة وإطارات iframe وغير ذلك من المحتوى الذي يتم إدخاله ديناميكيًا في ظهور المحتوى بعدها، ما يؤدي إلى زيادة متغيّرات التصميم التراكمية (CLS).

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

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

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

حجز مساحة للمحتوى الذي يتم تحميله بعد وقت طويل

عند وضع محتوى يتم تحميله بعد وقت من تحميل المحتوى الرئيسي، يمكن تجنُّب تغييرات التنسيق من خلال حجز مساحة له في التنسيق الأولي.

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

يمكن أن يؤدي حجز مساحة للإعلانات إلى منع تغييرات التنسيق

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

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

يمكنك بدلاً من ذلك ضبط الحجم الأولي على أصغر حجم سيتم استخدامه، وقبول بعض مستوى التحول للمحتوى الأكبر حجمًا. يتيح استخدام min-height، كما اقترحنا سابقًا، توسيع العنصر الرئيسي حسب الضرورة مع تقليل تأثير تغييرات التصميم، مقارنةً بالحجم التلقائي 0px للعنصر الفارغ.

حاوِل تجنُّب تصغير المساحة المحجوزة من خلال عرض عنصر نائب في حال عدم عرض أي إعلان مثلاً. يمكن أن تؤدي إزالة المساحة المخصّصة للعناصر إلى زيادة مقدار CLS بقدر ما يؤديه إدراج المحتوى.

وضع المحتوى الذي يتم تحميله متأخرًا في موضع أدنى في إطار العرض

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

تجنَّب إدراج محتوى جديد بدون تفاعل من المستخدم.

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

محتوى ديناميكي بدون مساحة محجوزة

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

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

• استبدِل المحتوى القديم بالمحتوى الجديد ضمن حاوية بحجم ثابت أو استخدِم لوحة عرض دوّارة وأزِل المحتوى القديم بعد عملية النقل. احرص على إيقاف أي روابط وعناصر تحكّم إلى أن تكتمل عملية النقل لمنع النقرات أو اللمسات غير المقصودة أثناء ظهور المحتوى الجديد.
• اطلب من المستخدم بدء تحميل المحتوى الجديد حتى لا يتفاجأ بالتغيير (على سبيل المثال، باستخدام زر "تحميل المزيد" أو "إعادة تحميل"). ننصح بجلب المحتوى مسبقًا قبل تفاعل المستخدم كي يظهر على الفور. للتذكير، لا يتم احتساب عمليات تغيير التنسيق التي تحدث خلال 500 ملي ثانية من إدخال المستخدم ضمن مقياس CLS.
• تحميل المحتوى بسلاسة خارج الشاشة وعرض إشعار للمستخدم يفيد بتوفّره (على سبيل المثال، باستخدام زر "الانتقال للأعلى")

أمثلة على تحميل المحتوى الديناميكي بدون حدوث متغيّرات غير متوقعة في التصميم: على يمين الشاشة: يتم تحميل محتوى الخلاصة المباشرة على Twitter. على اليمين: مثال على "Load more" (تحميل المزيد) على موقع Chloé الإلكتروني اطّلِع على كيفية تحسين فريق YNAP لمتغيّر التصميم التراكمية عند تحميل المزيد من المحتوى.

ملاحظة: إذا كان من المحتمل أن يستغرق المحتوى أكثر من 500 مللي ثانية، على سبيل المثال، يتطلب استرجاع البيانات من الشبكة، يمكنك حجز المساحة المتوقّعة ضمن الإطار الزمني البالغ 500 ملّي ثانية ومراعاة تأثير أي تبديل مستقبلي، ما يضمن عدم تضمين أي تغييرات في نتيجة متغيّرات التصميم التراكمية (CLS).

الصور المتحركة

يمكن أن تتطلب التغييرات في قيم خصائص CSS أن يتفاعل المتصفّح مع هذه التغييرات. تؤدي بعض القيم، مثل box-shadow وbox-sizing، إلى إعادة التنسيق والطلاء والتركيب. يؤدي تغيير السمتَين top وleft أيضًا إلى تغييرات في التصميم، حتى عندما يكون العنصر الذي يتم نقله في طبقته الخاصة. تجنَّب استخدام هذه السمات لإنشاء تأثيرات متحركة.

يمكن تغيير خصائص CSS الأخرى بدون إعادة ترتيب العناصر. ويشمل ذلك استخدام transform مؤثرات متحركة لنقل العناصر أو تغيير حجمها أو تدويرها أو تمويهها.

لا يمكن للصور المتحركة المركبة التي تستخدم translate التأثير في العناصر الأخرى، وبالتالي لا يتم احتسابها ضمن مقياس CLS. ولا تؤدي الصور المتحركة غير المركّبة أيضًا إلى إعادة التنسيق. لمزيد من المعلومات عن خصائص CSS التي تؤدي إلى تغييرات في التنسيق، اطّلِع على مقالة الرسوم المتحرّكة العالية الأداء.

خطوط الويب

عادةً ما يتم التعامل مع تنزيل خطوط الويب وعرضها بإحدى الطريقتين قبل تنزيل خط الويب:

• يتم تبديل الخط الاحتياطي بخط الويب، ما يؤدي إلى ظهور النص بخط مختلف (FOUT).
• يتم عرض النص "غير المرئي" باستخدام الخط الاحتياطي إلى أن يتوفّر خط ويب ويتم عرض النص (FOIT - وميض النص غير المرئي).

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

يمكن أن تساعدك الأدوات التالية في تقليل تغيُّر النص:

• يمكن أن يتجنب font-display: optional إعادة التنسيق لأنّه لا يتم استخدام خط الويب إلا إذا كان متاحًا في وقت التنسيق الأولي.
• تأكَّد من استخدام الخط الاحتياطي المناسب. على سبيل المثال، سيضمن استخدام font-family: "Google Sans", sans-serif; استخدام الخط الاحتياطي sans-serif للمتصفّح أثناء تحميل "Google Sans". سيؤدي عدم تحديد خط احتياطي باستخدام font-family: "Google Sans" فقط إلى استخدام الخط التلقائي، وهو "Times" في Chrome، وهو خط مكتوب بحرف لاتيني عريض يشبه الخط التلقائي sans-serif.
• عليك تقليل الاختلافات في الحجم بين الخط الاحتياطي وخط الويب باستخدام واجهات برمجة التطبيقات الجديدة size-adjust وascent-override وdescent-override وline-gap-override كما هو موضّح بالتفصيل في مشاركة الخطوط الاحتياطية المحسّنة.
• يمكن لواجهة برمجة التطبيقات Font الأحداث API تقليل الوقت المستغرق للحصول على الخطوط اللازمة.
• حمِّل خطوط الويب المهمة في أقرب وقت ممكن باستخدام <link rel=preload>. سيكون للخط المحمَّل مسبقًا فرصة أكبر في العرض الأول، وفي هذه الحالة لن يتم تغيير التنسيق.

اطّلِع على أفضل الممارسات المتعلّقة بالخطوط للتعرّف على أفضل الممارسات الأخرى المتعلّقة بالخطوط.

خفض متغيّرات التصميم التراكمية (CLS) من خلال التأكد من أهلية الصفحات لاستخدام ميزة "التخزين المؤقت للصفحات"

من الأساليب الفعّالة للغاية للحفاظ على انخفاض نتائج CLS هي التأكّد من أنّ صفحات الويب مؤهّلة لاستخدام ذاكرة التخزين المؤقت للرجوع/التقديم (bfcache).

تحافظ ذاكرة التخزين المؤقت للصفحات Bfcache على الصفحات في ذاكرة المتصفّح لفترة قصيرة بعد الانتقال بعيدًا عنها، فإذا عدت إليها، ستتم استعادتها كما تركتها تمامًا. وهذا يعني أنّ الصفحة التي تم تحميلها بالكامل تكون متاحة على الفور، بدون أي تغييرات قد تظهر عادةً أثناء التحميل لأي من الأسباب المذكورة سابقًا.

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

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

عند طرح هذه الميزة في Chrome، لاحظنا تحسينات ملحوظة في مقياس CLS.

تُستخدَم ميزة "التخزين المؤقت للصفحات" تلقائيًا في جميع المتصفّحات، ولكن تكون بعض المواقع الإلكترونية غير مؤهَّلة لاستخدام ميزة "التخزين المؤقت للصفحات" لأسباب مختلفة. يمكنك الاطّلاع على دليل استخدام Bfcache للحصول على مزيد من التفاصيل حول كيفية اختبار وتحديد أي مشاكل تمنع استخدام Bfcache للتأكّد من الاستفادة الكاملة من هذه الميزة لمساعدتك في النتيجة الإجمالية لمتغيّرات التصميم التراكمية (CLS) لموقعك الإلكتروني.

الخاتمة

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