تغییر چیدمان تجمعی (CLS) یک معیار اصلی حیاتی وب اصلی است. این یک معیار مهم و کاربر محور برای اندازهگیری ثبات بصری است، زیرا به کمیت کردن تعداد دفعاتی که کاربران تغییرات طرحبندی غیرمنتظره را تجربه میکنند کمک میکند. CLS پایین به اطمینان از لذت بخش بودن صفحه کمک می کند.
تغییرات غیرمنتظره چیدمان میتواند تجربه کاربر را از بسیاری جهات مختل کند، از این که باعث شود در هنگام خواندن در صورت جابجایی ناگهانی متن، مکان خود را از دست بدهند تا روی پیوند یا دکمه اشتباه کلیک کنند. در برخی موارد، این می تواند آسیب جدی ایجاد کند.
حرکت غیرمنتظره محتوای صفحه معمولاً زمانی اتفاق میافتد که منابع به صورت ناهمزمان بارگیری میشوند یا عناصر DOM به صورت پویا قبل از محتوای موجود به صفحه اضافه میشوند. دلیل این حرکت ممکن است تصویر یا ویدیویی با ابعاد ناشناخته، فونتی باشد که بزرگتر یا کوچکتر از نسخه اصلی آن نمایش داده می شود، یا یک تبلیغ شخص ثالث یا ابزارک که به صورت پویا خود را تغییر اندازه می دهد.
تفاوت بین نحوه عملکرد یک سایت در توسعه و نحوه تجربه کاربران آن، این مشکل را بدتر می کند. مثلا:
- محتوای شخصی یا شخص ثالث اغلب در توسعه و تولید رفتار متفاوتی دارد.
- تصاویر آزمایشی اغلب در حافظه پنهان مرورگر توسعهدهنده قرار دارند، اما بارگذاری برای کاربر نهایی زمان بیشتری میبرد.
- تماسهای API که به صورت محلی اجرا میشوند، اغلب آنقدر سریع هستند که تاخیرهای غیرقابل توجه در توسعه میتواند در تولید قابل توجه باشد.
متریک تغییر چیدمان تجمعی (CLS) به شما کمک میکند با اندازهگیری تعداد دفعاتی که برای کاربران واقعی اتفاق میافتد، این مشکل را برطرف کنید.
CLS چیست؟
CLS اندازهگیری بزرگترین پیاپی امتیازات تغییر صفحهبندی برای هر تغییر غیرمنتظرهای که در طول عمر یک صفحه رخ میدهد است.
هر زمانی که یک عنصر قابل مشاهده موقعیت خود را از یک فریم رندر شده به فریم بعدی تغییر می دهد، تغییر طرح رخ می دهد. برای جزئیات نحوه اندازهگیری این تغییرات ، امتیاز تغییر طرحبندی را ببینید.
انبوهی از تغییرات طرحبندی، که به عنوان پنجره جلسه شناخته میشود، زمانی است که یک یا چند جابجایی طرحبندی به صورت متوالی با کمتر از 1 ثانیه بین هر شیفت، در مدت حداکثر 5 ثانیه اتفاق میافتد.
بزرگترین انفجار پنجره جلسه با حداکثر امتیاز تجمعی از تمام تغییرات طرح در آن پنجره است.
نمره CLS خوب چقدر است؟
برای ارائه یک تجربه کاربری خوب، یک سایت باید دارای امتیاز CLS 0.1 یا کمتر باشد. برای اطمینان از رسیدن به این هدف برای اکثر کاربران خود، توصیه می کنیم صدک 75 بارگذاری صفحه را اندازه گیری کنید که در دستگاه های تلفن همراه و دسکتاپ تقسیم بندی شده است.
برای کسب اطلاعات بیشتر در مورد تحقیق و روش شناسی پشت این توصیه، به تعریف آستانه معیارهای Core Web Vitals مراجعه کنید.
چیدمان با جزئیات تغییر می کند
layout-shift
چیدمان توسط Layout Instability API تعریف میشوند، که هر زمانی که عنصری که در نمای پورت قابل مشاهده است، موقعیت شروع خود را تغییر دهد (مثلاً موقعیت بالا و چپ در حالت نوشتن پیشفرض) بین دو فریم، ورودیهای تغییر طرح را گزارش میکند. عناصری که موقعیت شروع آنها تغییر می کند، عناصر ناپایدار در نظر گرفته می شوند.
تغییر چیدمان تنها زمانی اتفاق میافتد که عناصر موجود موقعیت شروع خود را تغییر دهند. اگر یک عنصر جدید به 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
است.
مثال زیر نشان میدهد که چگونه چندین عنصر ناپایدار بر امتیاز تغییر طرحبندی صفحه تأثیر میگذارند:
اولین مورد در لیست ("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 را می توان در آزمایشگاه یا میدان اندازه گیری کرد و در ابزارهای زیر موجود است.
ابزارهای میدانی
- گزارش تجربه کاربر Chrome
- PageSpeed Insights
- کنسول جستجو (گزارش Core Web Vitals)
- کتابخانه جاوا اسکریپت
web-vitals
ابزار آزمایشگاهی
تغییرات طرحبندی را در جاوا اسکریپت اندازهگیری کنید
برای اندازهگیری تغییرات طرحبندی در جاوا اسکریپت، از 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 برای آن صفحه است، اما چند استثنا مهم در بخش بعدی ذکر شده است. کتابخانه جاوا اسکریپت web vitals
این موارد را تا آنجا که ممکن است، در محدوده محدودیت های API های وب، حساب می کند.
تفاوت بین متریک و API
- اگر صفحهای در پسزمینه بارگذاری میشود، یا اگر قبل از اینکه مرورگر محتوایی را نقاشی کند، پسزمینه شده است، نباید مقدار CLS را گزارش کند.
- اگر صفحه ای از حافظه پنهان عقب یا جلو بازیابی شود، مقدار CLS آن باید به صفر بازنشانی شود زیرا کاربران این را به عنوان یک بازدید از صفحه مجزا تجربه می کنند.
- API ورودیهای
layout-shift
برای تغییراتی که در iframe رخ میدهد گزارش نمیکند، اما معیار این کار را انجام میدهد زیرا بخشی از تجربه کاربر از صفحه است. این می تواند به عنوان تفاوت بین CrUX و RUM نشان داده شود . برای اندازه گیری صحیح CLS، باید iframe ها را در آن قرار دهید. فریمهای فرعی میتوانند از 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 مراجعه کنید.
منابع اضافی
- راهنمایی Google Publisher Tag در مورد به حداقل رساندن تغییر طرح
- درک تغییر چیدمان تجمعی توسط آنی سالیوان و استیو کوبز در #PerfMatters (2020)
تغییرات
گاهی اوقات، اشکالاتی در APIهای مورد استفاده برای اندازه گیری معیارها و گاهی اوقات در تعاریف خود معیارها کشف می شود. در نتیجه، گاهی اوقات باید تغییراتی ایجاد شود و این تغییرات میتواند به صورت بهبود یا پسرفت در گزارشهای داخلی و داشبورد شما نشان داده شود.
برای کمک به شما در مدیریت این موضوع، همه تغییرات در پیاده سازی یا تعریف این معیارها در این Changelog نشان داده شده است.
اگر بازخوردی برای این معیارها دارید، آن را در گروه web-vitals-feedback Google ارائه کنید.