كيفية إصلاح مشكلات تغيير التخطيط التراكمي (CLS)

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

في هذه المقالة ، سأناقش بعض أنماط الواجهة الأمامية لتقليل CLS . لن أتحدث كثيرًا عن قياس CLS حيث غطيت ذلك بالفعل في مقال سابق. ولن أتحدث كثيرًا عن آليات كيفية حساب CLS: لدى Google بعض الوثائق الجيدة حول ذلك ، ودليل Jess Peck's The Almost Full Layout Shift هو غوص عميق رائع في ذلك أيضًا. ومع ذلك ، سأقدم القليل من الخلفية اللازمة لفهم بعض التقنيات.

لماذا تختلف CLS

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

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

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

أحد أسباب اختلاف CLS هو أنه يتم قياسه من خلال عمر الصفحة - وهذا هو الجزء "التراكمي" من الاسم! يتوقف العاملان الأساسيان الآخران للويب بعد العثور على المكون الرئيسي على الصفحة بعد التحميل (لـ LCP) ، أو للتفاعل الأول (لـ FID). هذا يعني أن أدواتنا المعملية التقليدية ، مثل Lighthouse ، غالبًا لا تعكس CLS بالكامل لأنها تحسب فقط الحمل الأولي CLS. في الحياة الواقعية ، سوف يقوم المستخدم بالتمرير لأسفل الصفحة وقد يحصل على المزيد من المحتوى الذي يتسبب في مزيد من التحولات.

CLS هو أيضًا رقم مصطنع قليلاً يتم حسابه بناءً على مقدار تحرك الصفحة وعدد المرات. بينما يتم قياس LCP و FID بالمللي ثانية ، فإن CLS هو ناتج رقم بدون وحدة من خلال حساب معقد. نريد أن تكون الصفحة 0.1 أو أقل لتمرير Core Web Vital. أي شيء أعلى من 0.25 يُنظر إليه على أنه "ضعيف".

لا يتم احتساب التحولات الناتجة عن تفاعل المستخدم. يتم تعريف هذا على أنه ضمن 500 مللي ثانية من مجموعة محددة من تفاعلات المستخدم على الرغم من استبعاد أحداث المؤشر والتمرير. من المفترض أن المستخدم الذي ينقر على زر قد يتوقع ظهور المحتوى ، على سبيل المثال من خلال توسيع قسم مطوي.

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

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

هذا يعني أنه إذا كان لديك ثلاثة أجزاء من CLS 0.05 و 0.06 و 0.04 ، فسيتم تسجيل ذلك سابقًا على أنه 0.15 (أي تجاوز الحد "الجيد" البالغ 0.1) ، بينما سيتم تسجيله الآن على أنه 0.06. لا يزال تراكميًا بمعنى أن النتيجة قد تتكون من نوبات منفصلة ضمن هذا الإطار الزمني (أي إذا كانت نتيجة 0.06 CLS ناتجة عن ثلاث نوبات منفصلة قدرها 0.02) ، ولكنها لم تعد تراكمية على مدار العمر الإجمالي للصفحة بعد الآن .

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

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

تعيين العرض والارتفاعات على الصور وإطارات iFrames

لقد كتبت عن هذا من قبل ، ولكن أحد أسهل الأشياء التي يمكنك القيام بها لتقليل CLS هو التأكد من تعيين سمات width height على صورك . بدونها ، ستؤدي الصورة إلى تحول المحتوى اللاحق لإفساح المجال له بعد تنزيله:

هذه مجرد مسألة تغيير ترميز الصور الخاص بك من:

 <img src="hero_image.jpg" alt="...">

ل:

 <img src="hero_image.jpg" alt="..." width="400" height="400">

يمكنك العثور على أبعاد الصورة عن طريق فتح DevTools والتمرير فوق العنصر (أو النقر فوقه).

أنصح باستخدام الحجم الداخلي (وهو الحجم الفعلي لمصدر الصورة) وسيقوم المتصفح بعد ذلك بتقليص حجمها إلى الحجم المعروض عند استخدام CSS لتغييرها.

نصيحة سريعة : إذا كنت مثلي ، لا تتذكر ما إذا كان العرض والارتفاع أم الارتفاع والعرض ، فكر في الأمر على أنه إحداثيات X و Y ، لذلك ، مثل X ، يتم إعطاء العرض دائمًا أولاً.

إذا كانت لديك صور متجاوبة واستخدمت CSS لتغيير أبعاد الصورة (على سبيل المثال لتقييدها max-width بنسبة 100٪ من حجم الشاشة) ، فيمكن استخدام هذه السمات لحساب height - بشرط أن تتذكر تجاوز هذا إلى auto في CSS الخاص بك:

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

تدعم جميع المتصفحات الحديثة هذا الآن ، على الرغم من أنها لم يتم تناولها حتى وقت قريب في مقالتي. يعمل هذا أيضًا مع عناصر <picture> وصور srcset (قم بتعيين width height على عنصر img الاحتياطي) ، ولكن ليس بعد للصور ذات نسب العرض إلى الارتفاع المختلفة - يتم العمل عليها ، وحتى ذلك الحين لا يزال يتعين عليك تعيين width height لأن أي قيم ستكون أفضل من القيم الافتراضية من 0 إلى 0 !

يعمل هذا أيضًا على الصور الأصلية المحملة ببطء (على الرغم من أن Safari لا يدعم التحميل البطيء بشكل افتراضي حتى الآن).

خاصية CSS الجديدة aspect-ratio

يمكن تعميم تقنية width height أعلاه ، لحساب الارتفاع للصور المتجاوبة ، على عناصر أخرى باستخدام خاصية aspect-ratio CSS الجديدة ، والتي تدعمها الآن المتصفحات المستندة إلى Chromium و Firefox ، ولكن أيضًا في Safari Technology Preview. نأمل أن يعني ذلك أنه سيصل إلى الإصدار الثابت قريبًا.

لذلك يمكنك استخدامه في فيديو مضمن على سبيل المثال بنسبة 16: 9:

 video { max-width: 100%; height: auto; aspect-ratio: 16 / 9; }

 <video controls width="1600" height="900" poster="..."> <source src="/media/video.webm" type="video/webm"> <source src="/media/video.mp4" type="video/mp4"> Sorry, your browser doesn't support embedded videos. </video>

ومن المثير للاهتمام ، أنه بدون تحديد خاصية aspect-ratio ، ستتجاهل المتصفحات ارتفاع عناصر الفيديو سريعة الاستجابة وتستخدم نسبة عرض إلى ارتفاع افتراضية تبلغ 2: 1 ، لذلك يلزم ما سبق لتجنب تغيير التخطيط هنا.

في المستقبل ، يجب أن يكون من الممكن تعيين aspect-ratio ديناميكيًا بناءً على سمات العنصر باستخدام aspect-ratio: attr(width) / attr(height); لكن للأسف لم يتم دعم هذا حتى الآن.

أو يمكنك حتى استخدام aspect-ratio على عنصر <div> لنوع من التحكم المخصص الذي تقوم بإنشائه لجعله مستجيبًا:

 #my-square-custom-control { max-width: 100%; height: auto; width: 500px; aspect-ratio: 1; }

 <div></div>

بالنسبة إلى المتصفحات التي لا تدعم aspect-ratio يمكنك استخدام اختراق الحشو السفلي الأقدم ، ولكن مع بساطة aspect-ratio الأحدث والدعم الواسع (خاصة بمجرد انتقال هذا من Safari Technical Preview إلى Safari العادي) ، فهو كذلك من الصعب تبرير تلك الطريقة القديمة.

Chrome هو المتصفح الوحيد الذي يرسل CLS إلى Google ويدعم aspect-ratio مما يعني أنه سيحل مشكلات CLS من حيث Core Web Vitals. لا أحب إعطاء الأولوية للمقاييس على المستخدمين ، ولكن حقيقة أن متصفحي Chromium و Firefox الآخرين بهما هذا وآمل أن يكون Safari قريبًا ، وأن هذا تحسين تدريجي يعني أنني أود أن أقول إننا وصلنا إلى النقطة التي نحن فيها يمكن ترك اختراق الحشو السفلي وراءه وكتابة رمز أنظف.

استفد من min-height

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

 header { min-height: 50px; } @media (min-width: 600px) { header { min-height: 200px; } }

 <header> ... </header>

بالطبع ينطبق الأمر نفسه على min-width للعناصر الموضوعة أفقيًا ، لكن الارتفاع هو عادة ما يسبب مشكلات CLS.

هناك تقنية أكثر تقدمًا للمحتوى المحقون ومحددات CSS المتقدمة وهي الاستهداف عندما لا يتم إدراج المحتوى المتوقع بعد. على سبيل المثال ، إذا كان لديك المحتوى التالي:

 <div class="container"> <div class="main-content">...</div> </div>

ويتم إدخال div إضافي عبر JavaScript:

 <div class="container"> <div class="additional-content">.../div> <div class="main-content">...</div> </div>

بعد ذلك ، يمكنك استخدام المقتطف التالي لترك مساحة لمحتوى إضافي عندما يتم تقديم div main-content البداية.

 .main-content:first-child { margin-top: 20px; }

سينشئ هذا الرمز في الواقع تحولًا إلى عنصر main-content حيث يتم احتساب الهامش كجزء من هذا العنصر ، لذا سيظهر أنه يتحول عند إزالته (على الرغم من أنه لا يتحرك فعليًا على الشاشة). ومع ذلك ، لن يتم نقل المحتوى الموجود أسفله على الأقل ، لذا يجب تقليل CLS.

بدلاً من ذلك ، يمكنك استخدام ::before pseudo-element لإضافة مساحة لتجنب التغيير في عنصر main-content أيضًا:

 .main-content:first-child::before { content: ''; min-height: 20px; display: block; }

ولكن بكل صدق ، فإن الحل الأفضل هو الحصول على div في HTML والاستفادة من min-height في ذلك.

تحقق من العناصر الاحتياطية

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

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

لقد استخدمت العناصر الدلالية ولذا استخدمت عنصر الربط ( <a href="#table-of-contents"> ) للرابط الاحتياطي ولكنني استبدلت ذلك بـ <button> للقائمة الديناميكية التي تعتمد على JavaScript. تم تصميم هذه العناصر لتبدو متشابهة ، لكن الرابط الاحتياطي كان أصغر من الزر ببضع بكسل!

كان هذا صغيرًا جدًا ، وعادة ما يتم تشغيل JavaScript بسرعة كبيرة ، لدرجة أنني لم ألاحظ أنه تم إيقاف تشغيله. ومع ذلك ، لاحظ Chrome ذلك عند حساب CLS ، ولأن هذا كان في الرأس ، فقد نقل الصفحة بأكملها لأسفل بضع بكسل. لذلك كان لهذا تأثير كبير على درجة CLS - وهو ما يكفي لوضع جميع صفحاتنا في فئة "بحاجة إلى تحسين".

كان هذا خطأ من جانبي ، وكان الإصلاح ببساطة هو مزامنة العنصرين (كان من الممكن أيضًا معالجته عن طريق تعيين min-height أدنى على الرأس كما تمت مناقشته أعلاه) ، لكنه أربكني قليلاً. أنا متأكد من أنني لست الشخص الوحيد الذي ارتكب هذا الخطأ ، لذا كن على دراية بكيفية عرض الصفحة بدون JavaScript. ألا تعتقد أن المستخدمين لديك يقومون بتعطيل JavaScript؟ جميع المستخدمين لديك ليسوا من JS أثناء تنزيلهم JS.

تتسبب خطوط الويب في حدوث تغييرات في التخطيط

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

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

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

خيار آخر هو التأكد من أن الأقسام ذات حجم مناسب (على سبيل المثال مع min-height ) لذلك بينما قد يتحول النص فيها قليلاً ، لن يتم دفع المحتوى الموجود أدناه لأسفل حتى عند حدوث ذلك. على سبيل المثال ، قد يؤدي تعيين الحد min-height على عنصر <h1> إلى منع المقالة بأكملها من الانتقال لأسفل إذا تم تحميل خطوط أطول قليلاً - توفير الخطوط المختلفة لا يتسبب في عدد مختلف من الأسطر. سيؤدي ذلك إلى تقليل تأثير التحولات ، ومع ذلك ، بالنسبة للعديد من حالات الاستخدام (مثل الفقرات العامة) سيكون من الصعب تعميم حد أدنى للارتفاع.

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

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } @font-face { font-family: "Lato-fallback"; size-adjust: 97.38%; ascent-override: 99%; src: local("Arial"); } h1 { font-family: Lato, Lato-fallback, sans-serif; }

قبل ذلك ، كان تعديل الخط الاحتياطي مطلوبًا باستخدام Font Loading API في JavaScript والذي كان أكثر تعقيدًا ، ولكن هذا الخيار الذي سيتم طرحه قريبًا جدًا قد يمنحنا أخيرًا حلاً أسهل من المرجح أن يكتسب قوة جذب. راجع مقالتي السابقة حول هذا الموضوع لمزيد من التفاصيل حول هذا الابتكار القادم ومزيد من الموارد حول ذلك.

القوالب الأولية للصفحات المقدمة من جانب العميل

تعرض العديد من الصفحات المعروضة من جانب العميل ، أو تطبيقات الصفحة الواحدة ، صفحة أساسية أولية باستخدام HTML و CSS فقط ، ثم "ترطيب" القالب بعد تنزيل JavaScript وتشغيله.

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

لذا قم بمراجعة جميع القوالب الأولية للتأكد من أنها لا تزال عناصر نائبة أولية جيدة. وإذا كان النموذج الأولي يتكون من <div> s فارغة ، فاستخدم الأساليب المذكورة أعلاه للتأكد من حجمها بشكل مناسب لمحاولة تجنب أي تحولات.

بالإضافة إلى ذلك ، يجب أن يحتوي عنصر div الأولي الذي يتم حقنه مع التطبيق على min-height أدنى لتجنب عرضه بارتفاع 0 في البداية قبل إدراج القالب الأولي.

 <div></div>

طالما أن الحد min-height أكبر من معظم إطارات العرض ، فيجب أن يتجنب هذا أي CLS لتذييل موقع الويب ، على سبيل المثال. يتم قياس CLS فقط عندما يكون في إطار العرض وبالتالي يؤثر على المستخدم. بشكل افتراضي ، يبلغ ارتفاع عنصر div الفارغ 0 بكسل ، لذا امنحه أدنى min-height أقرب إلى الارتفاع الفعلي عند تحميل التطبيق.

تأكد من اكتمال تفاعلات المستخدم في غضون 500 مللي ثانية

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

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

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

هنا يمكنك أن ترى أننا حصلنا على 0.3359 درجة هائلة - تجاوزت حد 0.1 الذي نهدف إلى أن نكون أقل منه ، لكن النتيجة التراكمية لم تتضمن هذا ، لأنه تم تعيين الإدخال الأخير على الاستخدامات.

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

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

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

جافا سكريبت متزامن

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

سيخفي HTML أدناه div مبدئيًا ، ثم يقوم بتحميل بعض جافا سكريبت الذي يحظر العرض لملء div ، ثم إظهاره. نظرًا لأن JavaScript يحظر العرض ، فلن يتم عرض أي شيء أدناه (بما في ذلك كتلة style الثانية لإخفائها) وبالتالي لن يتم تكبد أي تغييرات.

 <style> .cls-inducing-div { display: none; } </style> <div class="cls-inducing-div"></div> <script> ... </script> <style> .cls-inducing-div { display: block; } </style>

من المهم تضمين CSS في HTML بهذه التقنية ، لذلك يتم تطبيقها بالترتيب. البديل هو إظهار المحتوى باستخدام JavaScript نفسه ، ولكن ما يعجبني في الأسلوب أعلاه هو أنه لا يزال يُظهر المحتوى حتى إذا فشل JavaScript أو تم إيقاف تشغيله بواسطة المتصفح.

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

 <head> ... <link rel="preload" href="cls-inducing-javascript.js" as="script"> ... </head> <body> ... <style> .cls-inducing-div { display: none; } </style> <div class="cls-inducing-div"></div> <script src="cls-inducing-javascript.js"></script> <style> .cls-inducing-div { display: block; } </style> ... </body>

الآن ، كما أقول ، أنا متأكد من أن هذا سيجعل أداء الويب يتأرجح ، حيث أن النصيحة هي استخدام النوع غير async, defer أو المؤجل أو type="module" (التي تم defer افتراضيًا) على جافا سكريبت على وجه التحديد لتجنب الحظر تقدم ، بينما نفعل العكس هنا! ومع ذلك ، إذا كان المحتوى لا يمكن تحديده مسبقًا وسيؤدي إلى تحولات متناقضة ، فلا فائدة من تقديمه مبكرًا.

لقد استخدمت هذه التقنية لبانر ملف تعريف الارتباط الذي تم تحميله في الجزء العلوي من الصفحة ونقل المحتوى إلى أسفل:

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

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

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

يمكن أن يؤثر استخدام هذه التقنية على المقاييس الأخرى (خاصة LCP وكذلك First Contentful Paint) حيث تقوم بتأخير العرض ، ويحتمل أيضًا حظر أداة التحميل المسبق للتطلع إلى الأمام ، ولكنها أداة أخرى يجب مراعاتها في تلك الحالات التي لا يوجد فيها خيار آخر.

خاتمة

يحدث التحول التراكمي في التخطيط نتيجة تغيير أبعاد المحتوى ، أو إدخال محتوى جديد في الصفحة عن طريق تأخر تشغيل JavaScript. في هذا المنشور ، ناقشنا العديد من النصائح والحيل لتجنب ذلك. أنا سعيد لأن Core Web Vitals قد سلطت الضوء على هذه المشكلة المزعجة - لقد تجاهلنا مطورو الويب (وأنا بالتأكيد أدرج نفسي في هذا) هذه المشكلة.

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

المزيد من الموارد

• مقالات Core Web Vitals هنا في Smashing Magazine ، بما في ذلك مقالاتي عن Setting Width and Heights on Images ، وقياس Core Web Vitals ، و CSS Font Descriptors.
• وثائق "أساسيات الويب الأساسية" من Google بما في ذلك صفحتها على CLS.
• مزيد من التفاصيل حول التغيير الأخير في CLS ثم بدأ هذا التغيير في التحديث في أدوات Google المختلفة.
• يوضح CLS Changelog بالتفصيل التغييرات في كل إصدار من Chrome.
• الدليل شبه الكامل لتغيير التخطيط التراكمي بقلم جيس بيك.
• التحول في التخطيط التراكمي: قياس وتجنب عدم الاستقرار المرئي بواسطة كارولينا شتشور.
• مولد GIF لتحويل التخطيط للمساعدة في إنشاء عروض توضيحية قابلة للمشاركة من CLS.