تغییر چیدمان تجمعی (CLS)

میلیکا میهالیجا
فیلیپ والتون

پشتیبانی مرورگر

  • کروم: 77.
  • لبه: 79.
  • فایرفاکس: پشتیبانی نمی شود.
  • سافاری: پشتیبانی نمی شود.

منبع

تغییرات غیرمنتظره چیدمان می‌تواند تجربه کاربر را از بسیاری جهات مختل کند، از این که باعث شود در هنگام خواندن در صورت جابجایی ناگهانی متن، مکان خود را از دست بدهند تا روی پیوند یا دکمه اشتباه کلیک کنند. در برخی موارد، این می تواند آسیب جدی ایجاد کند.

تغییر ناگهانی در چیدمان باعث می‌شود کاربر سفارش بزرگی را که قصد لغو آن را دارد تأیید کند.

حرکت غیرمنتظره محتوای صفحه معمولاً زمانی اتفاق می‌افتد که منابع به صورت ناهمزمان بارگیری می‌شوند یا عناصر DOM به صورت پویا قبل از محتوای موجود به صفحه اضافه می‌شوند. علت تغییر چیدمان ممکن است تصاویر یا ویدیوهایی با ابعاد ناشناخته، فونت‌هایی باشد که بزرگ‌تر یا کوچک‌تر از نسخه اولیه آن نمایش داده می‌شوند، یا تبلیغات شخص ثالث یا ویجت‌هایی که به صورت پویا تغییر اندازه می‌دهند.

تفاوت بین نحوه عملکرد یک سایت در توسعه و نحوه تجربه کاربران آن، این مشکل را بدتر می کند. به عنوان مثال:

  • محتوای شخصی یا شخص ثالث اغلب در توسعه و تولید رفتار متفاوتی دارد.
  • تصاویر آزمایشی اغلب در حافظه پنهان مرورگر توسعه‌دهنده قرار دارند، اما بارگذاری برای کاربر نهایی زمان بیشتری می‌برد.
  • تماس‌های API که به صورت محلی اجرا می‌شوند، اغلب آنقدر سریع هستند که تاخیرهای غیرقابل توجه در توسعه می‌تواند در تولید قابل توجه باشد.

متریک تغییر چیدمان تجمعی (CLS) به شما کمک می کند این مشکل را با اندازه گیری تعداد دفعات وقوع آن برای کاربران واقعی برطرف کنید.

CLS چیست؟

CLS اندازه‌گیری بزرگ‌ترین انبوه امتیازات تغییر صفحه‌بندی برای هر تغییر غیرمنتظره‌ای که در طول چرخه عمر یک صفحه رخ می‌دهد است.

هر زمانی که یک عنصر قابل مشاهده موقعیت خود را از یک فریم رندر شده به فریم بعدی تغییر می دهد ، تغییر طرح رخ می دهد. (جزئیات در مورد نحوه محاسبه امتیازات شیفت طرح بندی فردی بعداً در این راهنما پوشش داده می شود.)

یک سری تغییرات طرح‌بندی، که به عنوان پنجره جلسه شناخته می‌شود، زمانی اتفاق می‌افتد که یک یا چند جابجایی طرح‌بندی به صورت متوالی و با کمتر از 1 ثانیه در بین هر تغییر و حداکثر 5 ثانیه برای کل مدت زمان پنجره اتفاق می‌افتد.

بزرگترین انفجار پنجره جلسه با حداکثر امتیاز تجمعی از تمام تغییرات طرح در آن پنجره است.

نمونه ای از پنجره های جلسه نوارهای آبی نشان دهنده نمرات هر تغییر چیدمان فردی است.

نمره CLS خوب چقدر است؟

برای ارائه یک تجربه کاربری خوب، سایت ها باید تلاش کنند تا امتیاز CLS 0.1 یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای اکثر کاربران خود، یک آستانه خوب برای اندازه گیری صدک 75 بارگذاری صفحه است که در دستگاه های تلفن همراه و دسکتاپ تقسیم بندی شده است.

مقادیر خوب CLS 0.1 یا کمتر هستند، مقادیر ضعیف بیشتر از 0.25 هستند و هر چیزی در این بین نیاز به بهبود دارد.
مقادیر خوب CLS 0.1 یا کمتر است. مقادیر ضعیف بیشتر از 0.25 هستند.

برای کسب اطلاعات بیشتر در مورد تحقیق و روش شناسی پشت این توصیه، به تعریف آستانه معیارهای Core Web Vitals مراجعه کنید.

چیدمان در جزئیات تغییر می کند

جابه‌جایی‌های طرح‌بندی توسط Layout Instability API تعریف می‌شوند، که هر زمان که عنصری که در نمای نمای قابل مشاهده است، موقعیت شروع خود را (به عنوان مثال، موقعیت بالا و چپ در حالت نوشتن پیش‌فرض) بین دو فریم تغییر می‌دهد، ورودی‌های layout-shift گزارش می‌کند. چنین عناصری عناصر ناپایدار در نظر گرفته می شوند.

توجه داشته باشید که تغییرات چیدمان تنها زمانی رخ می دهد که عناصر موجود موقعیت شروع خود را تغییر دهند. اگر یک عنصر جدید به DOM اضافه شود یا یک عنصر موجود اندازه آن را تغییر دهد، به عنوان یک تغییر چیدمان به حساب نمی آید - تا زمانی که این تغییر باعث نشود که سایر عناصر قابل مشاهده موقعیت شروع خود را تغییر دهند.

نمره تغییر چیدمان

برای محاسبه امتیاز تغییر چیدمان ، مرورگر به اندازه نمای و حرکت عناصر ناپایدار در نما بین دو فریم رندر شده نگاه می کند. امتیاز تغییر طرح محصول دو معیار آن حرکت است: کسر ضربه و کسر فاصله (هر دو در زیر تعریف شده اند).

layout shift score = impact fraction * distance fraction

کسر ضربه

کسر ضربه نحوه تاثیر عناصر ناپایدار بر ناحیه دید بین دو فریم را اندازه گیری می کند.

کسر ضربه برای یک قاب معین، ترکیبی از نواحی قابل مشاهده همه عناصر ناپایدار برای آن فریم و فریم قبلی، به عنوان کسری از مساحت کل نمای درگاه است.

مثال کسری ضربه با یک عنصر ناپایدار
اگر یک عنصر موقعیت خود را تغییر دهد، موقعیت قبلی و فعلی آن به کسر ضربه ای آن کمک می کند.

در تصویر قبلی، عنصری وجود دارد که نیمی از نمای در یک فریم را اشغال می کند. سپس، در فریم بعدی، عنصر به میزان 25 درصد از ارتفاع درگاه دید به پایین جابه‌جا می‌شود. مستطیل نقطه‌دار قرمز نشان‌دهنده اتحاد ناحیه قابل مشاهده عنصر در هر دو فریم است که در این حالت 75٪ از کل دید است، بنابراین کسر ضربه آن 0.75 است.

کسر فاصله

بخش دیگر معادله امتیاز تغییر چیدمان، فاصله ای را که عناصر ناپایدار نسبت به درگاه دید حرکت کرده اند اندازه گیری می کند. کسر فاصله بزرگترین فاصله افقی یا عمودی است که هر عنصر ناپایدار در قاب حرکت کرده است تقسیم بر بزرگ ترین بعد نمای درگاه (عرض یا ارتفاع، هر کدام بیشتر باشد).

مثال کسری فاصله با یک عنصر ناپایدار
کسر فاصله اندازه‌گیری می‌کند که یک عنصر چقدر در وسعت دید حرکت کرده است.

در مثال قبلی، بزرگترین بعد درگاه دید، ارتفاع است و عنصر ناپایدار 25 درصد از ارتفاع درگاه دید جابجا شده است، که کسری فاصله را 0.25 می کند.

بنابراین، در این مثال کسر ضربه 0.75 و کسر فاصله 0.25 است، بنابراین نمره تغییر طرح 0.75 * 0.25 = 0.1875 است.

نمونه ها

مثال بعدی نشان می‌دهد که چگونه افزودن محتوا به یک عنصر موجود بر امتیاز تغییر طرح‌بندی تأثیر می‌گذارد:

مثال تغییر چیدمان با چندین عنصر پایدار و _ناپایدار_
افزودن یک دکمه به پایین کادر خاکستری، کادر سبز را به سمت پایین و تا حدی خارج از پنجره نمایش می راند.

در این مثال، اندازه جعبه خاکستری تغییر می کند، اما موقعیت شروع آن تغییر نمی کند، بنابراین یک عنصر ناپایدار نیست.

"مرا کلیک کن!" دکمه قبلاً در DOM نبود، بنابراین موقعیت شروع آن نیز تغییر نمی کند.

با این حال، موقعیت شروع کادر سبز تغییر می‌کند، اما از آنجایی که تا حدی به خارج از نما منتقل شده است، هنگام محاسبه کسر ضربه ، ناحیه نامرئی در نظر گرفته نمی‌شود. اتحاد نواحی قابل مشاهده برای کادر سبز در هر دو فریم (که با مستطیل نقطه‌دار قرمز نشان داده شده است) با مساحت کادر سبز در اولین فریم برابر است - 50٪ از نمای دید. کسر ضربه 0.5 است.

کسر فاصله با فلش بنفش نشان داده شده است. کادر سبز حدود 14 درصد از نمای دید به سمت پایین حرکت کرده است، بنابراین کسر فاصله 0.14 است.

امتیاز تغییر طرح 0.5 x 0.14 = 0.07 است.

مثال زیر نشان می‌دهد که چگونه چندین عنصر ناپایدار بر امتیاز تغییر طرح‌بندی صفحه تأثیر می‌گذارند:

مثال تغییر چیدمان با عناصر پایدار و _ناپایدار_ و برش درگاه دید
همانطور که نام های بیشتری در این لیست مرتب شده ظاهر می شود، نام های موجود برای حفظ ترتیب حروف الفبا حرکت می کنند.

در اولین فریم در تصویر قبلی، چهار نتیجه از یک درخواست API برای حیوانات وجود دارد که به ترتیب حروف الفبا مرتب شده اند. در فریم دوم، نتایج بیشتری به لیست مرتب شده اضافه می شود.

اولین مورد در لیست ("Cat") موقعیت شروع خود را بین فریم ها تغییر نمی دهد، بنابراین پایدار است. به طور مشابه، موارد جدید اضافه شده به لیست قبلاً در DOM نبودند، بنابراین موقعیت شروع آنها نیز تغییر نمی کند. اما اقلام با برچسب "سگ"، "اسب" و "زبرا" همگی موقعیت شروع خود را تغییر می دهند و آنها را به عناصر ناپایدار تبدیل می کنند.

مجدداً، مستطیل‌های قرمز نقطه‌دار نشان‌دهنده اتحاد این سه عنصر ناپایدار «قبل و بعد» است که در این مورد حدود 60 درصد مساحت نمای درگاه است ( کسری ضربه 0.60 ).

فلش ها نشان دهنده فواصلی هستند که عناصر ناپایدار از موقعیت شروع خود جابجا شده اند. عنصر "Zebra" که با فلش آبی نشان داده می شود، بیشترین جابجایی را داشته است، در حدود 30٪ از ارتفاع دید. این باعث می شود کسر فاصله در این مثال 0.3 .

امتیاز تغییر طرح 0.60 x 0.3 = 0.18 است.

تغییرات طرح‌بندی مورد انتظار در مقابل غیرمنتظره

همه جابجایی های چیدمان بد نیستند. در واقع، بسیاری از برنامه های کاربردی وب پویا مرتباً موقعیت شروع عناصر را در صفحه تغییر می دهند. تغییر طرح تنها زمانی بد است که کاربر انتظار آن را نداشته باشد.

تغییر طرح توسط کاربر

تغییرات طرح‌بندی که در پاسخ به تعاملات کاربر رخ می‌دهد (مانند کلیک کردن یا ضربه زدن روی یک پیوند، فشار دادن یک دکمه یا تایپ کردن در کادر جستجو) معمولاً خوب هستند، تا زمانی که این تغییر به اندازه کافی نزدیک به تعامل باشد که رابطه واضح باشد. کاربر

به عنوان مثال، اگر یک تعامل کاربر یک درخواست شبکه را راه‌اندازی می‌کند که ممکن است تکمیل آن مدتی طول بکشد، بهتر است فوراً مقداری فضا ایجاد کنید و نشانگر بارگیری را نشان دهید تا از تغییر چیدمان ناخوشایند هنگام تکمیل درخواست جلوگیری کنید. اگر کاربر متوجه نشود که چیزی در حال بارگیری است، یا احساسی از زمان آماده شدن منبع نداشته باشد، ممکن است سعی کند در حین انتظار روی چیز دیگری کلیک کند - چیزی که می تواند از زیر آنها خارج شود.

تغییرات طرح‌بندی که در عرض 500 میلی‌ثانیه از ورودی کاربر رخ می‌دهند دارای پرچم hadRecentInput هستند، بنابراین می‌توان آنها را از محاسبات حذف کرد.

انیمیشن ها و انتقال ها

انیمیشن ها و انتقال ها، زمانی که به خوبی انجام شوند، راهی عالی برای به روز رسانی محتوای صفحه بدون تعجب کاربر هستند. محتوایی که به‌طور ناگهانی و غیرمنتظره در صفحه جابه‌جا می‌شود تقریباً همیشه یک تجربه کاربری بد ایجاد می‌کند. اما محتوایی که به‌تدریج و به‌طور طبیعی از یک موقعیت به موقعیت دیگر حرکت می‌کند، اغلب می‌تواند به کاربر کمک کند تا بهتر بفهمد چه اتفاقی می‌افتد و او را بین تغییرات حالت راهنمایی کند.

مطمئن شوید که به تنظیمات مرورگر prefers-reduced-motion احترام بگذارید، زیرا برخی از بازدیدکنندگان سایت ممکن است اثرات نامطلوب یا مشکلات توجه را از انیمیشن تجربه کنند.

ویژگی transform CSS به شما امکان می‌دهد عناصر را بدون ایجاد تغییرات طرح‌بندی متحرک کنید:

  • به جای تغییر ویژگی های height و width ، از transform: scale() استفاده کنید.
  • برای جابجایی عناصر به اطراف، از تغییر ویژگی های top ، right ، bottom یا left خودداری کنید و به جای آن transform: translate() استفاده کنید.

نحوه اندازه گیری CLS

CLS را می توان در آزمایشگاه یا میدان اندازه گیری کرد و در ابزارهای زیر موجود است:

ابزارهای میدانی

ابزار آزمایشگاهی

تغییرات طرح‌بندی را در جاوا اسکریپت اندازه‌گیری کنید

برای اندازه‌گیری تغییرات طرح‌بندی در جاوا اسکریپت، از Layout Instability API استفاده می‌کنید.

مثال زیر نحوه ایجاد یک PerformanceObserver برای ثبت ورودی های layout-shift به کنسول را نشان می دهد:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

اندازه گیری CLS در جاوا اسکریپت

برای اندازه‌گیری CLS در جاوا اسکریپت، باید این ورودی‌های layout-shift غیرمنتظره را در جلسات گروه‌بندی کنید و حداکثر مقدار جلسه را محاسبه کنید. می توانید به کد منبع کتابخانه جاوا اسکریپت web vitals مراجعه کنید که حاوی یک پیاده سازی مرجع در مورد نحوه محاسبه CLS است.

در بیشتر موارد، مقدار CLS فعلی در زمانی که صفحه در حال بارگیری است، مقدار نهایی CLS برای آن صفحه است، اما چند استثنا مهم وجود دارد که در بخش بعدی ذکر شد. کتابخانه جاوا اسکریپت web vitals این موارد را تا آنجا که ممکن است، در محدوده محدودیت های API های وب، حساب می کند.

تفاوت بین متریک و API

  • اگر صفحه‌ای در پس‌زمینه بارگذاری می‌شود، یا اگر قبل از اینکه مرورگر محتوایی را نقاشی کند، پس‌زمینه شده است، نباید هیچ مقدار CLS را گزارش کند.
  • اگر صفحه ای از حافظه پنهان عقب/ جلو بازیابی شود، مقدار CLS آن باید به صفر بازنشانی شود زیرا کاربران این را به عنوان یک بازدید از صفحه مجزا تجربه می کنند.
  • API ورودی‌های layout-shift را برای تغییراتی که در iframe اتفاق می‌افتد گزارش نمی‌کند، اما معیار اندازه‌گیری را به‌عنوان بخشی از تجربه کاربر صفحه انجام می‌دهد. این می تواند به عنوان تفاوت بین CrUX و RUM نشان داده شود . برای اندازه گیری صحیح CLS باید آنها را در نظر بگیرید. فریم‌های فرعی می‌توانند از API برای گزارش ورودی‌های layout-shift خود به قاب والد برای تجمیع استفاده کنند.

علاوه بر این استثناها، CLS به دلیل این واقعیت که کل طول عمر یک صفحه را اندازه گیری می کند، پیچیدگی بیشتری نیز دارد:

  • کاربران ممکن است یک برگه را برای مدت بسیار طولانی باز نگه دارند - روزها، هفته ها، ماه ها. در واقع، یک کاربر ممکن است هرگز یک برگه را نبندد.
  • در سیستم‌عامل‌های تلفن همراه، مرورگرها معمولاً برای برگه‌های پس‌زمینه، بازخوانی بارگیری صفحه را اجرا نمی‌کنند و گزارش مقدار «نهایی» را دشوار می‌کند.

برای رسیدگی به چنین مواردی، CLS باید هر زمان که یک صفحه پس‌زمینه است گزارش شود - علاوه بر هر زمانی که بارگیری می‌شود ( رویداد visibilitychange هر دوی این سناریوها را پوشش می‌دهد). و سیستم های تحلیلی که این داده ها را دریافت می کنند، باید مقدار نهایی CLS را در باطن محاسبه کنند.

توسعه دهندگان می توانند به جای حفظ کردن و دست و پنجه نرم کردن با همه این موارد، از کتابخانه جاوا اسکریپت web-vitals برای اندازه گیری CLS استفاده کنند، که شامل همه موارد ذکر شده در بالا به جز مورد iframe است:

import {onCLS} from 'web-vitals';

// Measure and log CLS in all situations
// where it needs to be reported.
onCLS(console.log);

نحوه بهبود CLS

برای راهنمایی بیشتر در مورد شناسایی تغییرات چیدمان در زمینه و استفاده از داده های آزمایشگاهی برای بهینه سازی آنها، به راهنمای ما برای بهینه سازی CLS مراجعه کنید.

منابع اضافی

تغییرات

گاهی اوقات، اشکالاتی در APIهای مورد استفاده برای اندازه گیری معیارها و گاهی اوقات در تعاریف خود معیارها کشف می شود. در نتیجه، گاهی اوقات باید تغییراتی ایجاد شود، و این تغییرات می‌تواند به صورت بهبود یا پسرفت در گزارش‌های داخلی و داشبورد شما نشان داده شود.

برای کمک به شما در مدیریت این موضوع، همه تغییرات در اجرا یا تعریف این معیارها در این Changelog ظاهر می‌شود.

اگر بازخوردی برای این معیارها دارید، می‌توانید آن را در گروه web-vitals-feedback Google ارائه کنید.