ارزیابی شاخص Cumulative Layout Shift (CLS)

مقدمه – CLS چیست و چرا اهمیت دارد؟

فرض کنید در حال خواندن یک مقاله آنلاین هستید که ناگهان متن زیر چشمانتان پایین می‌پرد، یا می‌خواهید روی دکمه‌ای کلیک کنید اما در آخرین لحظه جایش عوض می‌شود. 😮 این پدیده همان «تغییر چیدمان تجمعی» یا Cumulative Layout Shift است که به اختصار CLS نامیده می‌شود. CLS یکی از سه شاخص مهم «هسته حیاتی وب» (Core Web Vitals) گوگل است که ثبات بصری صفحه را اندازه‌گیری می‌کند . هر چه CLS یک صفحه کمتر باشد، آن صفحه از نظر بصری پایدارتر بوده و تجربه کاربری دلپذیرتری ارائه می‌دهد . بالعکس، CLS بالا نشان می‌دهد اجزای صفحه به طور غیرمنتظره جابه‌جا می‌شوند و ممکن است کاربر را سردرگم یا کلافه کنند.

چرا این موضوع برای ما (به عنوان توسعه‌دهنده وب یا متخصص سئو) مهم است؟ اولاً، تجربه کاربری در اولویت است – هیچکس از “رقصیدن” عناصر صفحه خوشش نمی‌آید. جابه‌جایی ناگهانی محتوا می‌تواند باعث شود کاربر جای خود را در متن گم کند یا روی لینک/دکمه اشتباهی کلیک کند . حتی مواردی بوده که تغییر چیدمان باعث کلیک تصادفی روی دکمه تأیید سفارش شده و خسارت واقعی به بار آورده است ! ثانیاً، گوگل CLS را به عنوان سیگنال رتبه‌بندی در سئو در نظر می‌گیرد. یعنی یک CLS پایین (خوب) می‌تواند به بهبود رتبه صفحات شما در نتایج جست‌وجو کمک کند . پس بهبود CLS فقط لطف به کاربر نیست، بلکه از نظر سئو هم اهمیت دارد.

معیار CLS به صورت یک عدد بدون واحد بیان می‌شود. هر چه این عدد کوچکتر باشد بهتر است. گوگل برای درک بهتر، آستانه‌هایی تعریف کرده است

امتیاز CLS	وضعیت تجربه کاربر
0.1 یا کمتر	خوب (Good) 😊
بین 0.1 تا 0.25	نیاز به بهبود (Needs Improvement) 😕
بالاتر از 0.25	ضعیف (Poor) 😣

به عبارت دیگر، برای تجربه کاربری مطلوب باید CLS صفحه را تا حد امکان زیر 0.1 نگه دارید. در گزارش Core Web Vitals گوگل (که در سرچ کنسول موجود است) معیار CLS صفحات شما بر اساس چهلمین صدک – در واقع 75% بازدیدها – سنجیده می‌شود. بنابراین اگر می‌خواهید صفحه‌ای «خوب» تلقی شود، باید حداقل 75% بازدیدهای کاربران از آن صفحه، CLS معادل 0.1 یا کمتر داشته باشند.

برای درک بهتر مفهوم CLS، به تصویر زیر توجه کنید. در این مثال (تصویر فیلم‌نواری) صفحه ابتدا محتوای متنی خود را رندر کرده (در 2.0 ثانیه – اولین رندر)، سپس در 2.5 ثانیه فونت وب لود شده و باعث تغییر جزئی در اندازه متن شده است، و در 2.8 ثانیه یک بنر تبلیغاتی در بالای صفحه ظاهر شده که کل محتوا را به پایین می‌راند. این دو جابه‌جایی (یکی کوچک به علت فونت، دیگری بزرگ‌تر به علت بنر) روی هم یک CLSرابر حدود 0.13 ایجاد کرده‌اند .

مثال فیلم‌نواری از یک صفحه وب که در آن پس از بارگذاری اولیه (2.0s – اولین رندر)، در 2.5s بارگذاری فونت باعث بالا رفتن جزئی متن (Flash of Unstyled Text) شده و در 2.8s ظاهر شدن بنر بالای صفحه، تیتر و متن را به پایین می‌راند. این جابه‌جایی‌های ناگهانی مجموعاً CLS ≈ 0.13 را رقم زده‌اند

در ادامه این مقاله، با جزئیات بیشتری به تعریف دقیق CLS، شیوه محاسبه آن و عوامل مؤثر بر آن می‌پردازیم و راهکارهای عملی برای بهبود آن ارائه می‌کنیم. با لحنی خودمانی و آموزشی، مثل یک معلم دلسوز قدم به قدم جلو می‌رویم تا مطمئن شویم مفهوم را کاملاً درک کرده‌اید. 😉

جابه‌جایی غیرمنتظره در برابر جابه‌جایی مورد انتظار

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

به طور مشخص، هر جابه‌جایی که طی ۵۰۰ میلی‌ثانیه پس از یک تعامل کاربر رخ دهد، از دید CLS نادیده گرفته می‌شود.

فرض کنید کاربر روی دکمه “نمایش بیشتر” کلیک می‌کند و لیست محصولات بلندتر می‌شود؛ این جابه‌جایی چون بلافاصله پس از تعامل کاربر است، انتظار می‌رود و در محاسبه CLS اثر ندارد. اما اگر با تأخیر این اتفاق بیفتد (مثلاً کاربر کلیک کند و ۲ ثانیه بعد محتوا ناگهان ظاهر شود)، آن‌وقت جابه‌جایی حاصل ممکن است چون از نگاه کاربر غیرمنتظره بوده، در CLS لحاظ شود.

گوگل حتی به جز کلیک کاربر، سناریوهای “تعامل عمدی” دیگر را هم لحاظ کرده است. برای مثال، اگر کاربر عنصری را با ماوس درگ (کشیدن و رها کردن) کند یا اندازه صفحه را تغییر دهد، جابه‌جایی‌های حین این عمل نیز غیرمجازات هستند (در نسخه‌های جدید کروم، این موارد از CLS حذف شده‌اند).

خلاصه اینکه CLS نگران تغییراتی است که کاربر انتظارشان را ندارد – تغییراتی که مثل یک شوک ظاهر می‌شوند نه آن‌هایی که کاربر خودش عاملشان بوده است.

محاسبه CLS چگونه انجام می‌شود؟

حالا بیایید ببینیم عدد CLS دقیقاً چطور به دست می‌آید. اگر اصطلاح “تجمعی” (Cumulative) در نام CLS شما را ترسانده، نگران نباشید! محاسبه آن به زبان ساده این‌گونه است:

هر بار که چیدمان صفحه بین دو فریم رندر تغییر کند (یعنی المانی از جای قبلی‌اش به مکانی جدید برود)، یک «امتیاز جابه‌جایی» محاسبه می‌شود

دو عامل کلیدی در این امتیاز دخیل‌اند:

• Impact Fraction (کسر تاثیر) – چه مقدار از فضای دید کاربر (viewport) تحت تاثیر جابه‌جایی قرار گرفت.
• Distance Fraction (کسر مسافت) – المان (یا المان‌های) جابه‌جا شده نسبت به ابعاد صفحه، چه مسافتی را طی کرد.

این‌ها ممکن است کمی انتزاعی به نظر برسند، پس اجازه دهید با یک مثال عددی توضیح دهیم. فرض کنید در یک تغییر چیدمان:

• محتوای اصلی صفحه (مثلاً یک متن) ۵۰٪ از ارتفاع صفحه را گرفته بود.
• سپس یک عنصر جدید (مثلاً یک تصویر یا تبلیغ) بالای آن ظاهر می‌شود و ۲۰٪ از ارتفاع صفحه را اشغال می‌کند. در نتیجه، متن اصلی به پایین رانده می‌شود.

در این حالت:

• Impact Fraction: بخشی از صفحه که درگیر تغییر شده = ۷۰٪ از ارتفاع صفحه. چرا؟ چون ابتدا متن ۵۰٪ صفحه را پر کرده بود و اکنون با اضافه شدن ۲۰٪ فضای جدید در بالا، مجموع فضایی که موقعیت قبلی و جدید محتوا اشغال کرده‌اند ۷۰ ٪ صفحه است (متن در جای قبلی + متن در جای جدید + فضای تبلیغ)

• Distance Fraction: بیشترین مسافتی که یک عنصر حرکت کرده نسبت به بعد بزرگ‌تر صفحه. در مثال ما متن ۲۰٪ ارتفاع صفحه به پایین حرکت کرده است (که بزرگ‌ترین جابجایی است)

حال امتیاز جابه‌جایی برای این تغییر = حاصل‌ضرب این دو کسر. یعنی 0.7 * 0.2 = 0.14

این عدد 0.14 نشان‌دهنده شدت آن جهش بصری است.

فرمول کلی را می‌توان این‌طور نوشت:

امتیاز هر تغییر چیدمان = Impact Fraction × Distance Fraction:contentReference[oaicite:19]{index=19}:contentReference[oaicite:20]{index=20}

به عنوان نمونه، در مثال بالا Impact Fraction برابر 0.7 و Distance Fraction برابر 0.2 بود که حاصل‌ضربشان 0.14 شد. هرچه یک المان بزرگ‌تر باشد یا مسافت بیشتری بپرد، امتیاز بالاتری تولید می‌کند. جالب است بدانید در ابتدای تعریف CLS فقط Impact Fraction ملاک بود، اما بعدها Distance Fraction اضافه شد تا مواردی که المان بزرگ فقط کمی تکان می‌خورد بیش از حد جریمه نشوند

حالا CLS کل صفحه چگونه به دست می‌آید؟ این‌جاست که بحث “تجمعی” مطرح می‌شود. در گذشته، CLS جمع تمام امتیازهای جابه‌جایی طی عمر صفحه بود
 یعنی هر تغییری از لحظه بارگذاری تا بستن صفحه رخ می‌داد روی هم جمع می‌شد. اما در نسخه‌های جدید، CLS دیگر یک جمع بی‌حد و مرز نیست بلکه به صورت «بدترین سناریوی پیوسته» اندازه‌گیری می‌شود. به این مفهوم Session Window (پنجره جلسه) می‌گویند

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

بنابراین اگر صفحه شما چند جهش کوچک پراکنده داشته باشد ولی یک جای دیگر یک جهش بزرگ پشت سر هم رخ دهد، CLS همان جهش بزرگ را گزارش می‌کند (چون بیشترین اثر منفی را همان دارد).

برای مثال، اگر در یک صفحه طی ۲ ثانیه اول دو سه تغییر کوچک داشته باشید و بعد یک دوره پایدار باشد و مجدداً مثلاً در ثانیه ۱۰ تا ۱۲ چند تغییر بزرگ رخ دهد، CLS نهایی برابر مجموع آن تغییرات بزرگ در بازه ۱۰-۱۲ ثانیه خواهد بود (چون «بدترین پنجره ۵ ثانیه‌ای» همان بوده است)

این تعریف جدید باعث می‌شود صفحات تک‌صفحه‌ای (SPA) یا دارای اسکرول بی‌نهایت که مدام محتوا اضافه می‌کنند، CLS منطقی‌تری داشته باشند و اندازه‌گیری بین سایت‌ها منصفانه‌تر شود

تغییرات CLS در نسخه‌های مختلف Chrome

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

معرفی اولیه (Chrome 77 و 79): مفهوم CLS اولین بار در کروم 77 (سال 2019) از طریق API «ناپایداری چیدمان» (Layout Instability API) معرفی شد و در کروم 79 به یک متریک پایدار تبدیل گردید

یعنی از آن زمان مرورگر می‌توانست امتیاز CLS را برای صفحات گزارش دهد.

• تعریف قدیمی (قبل از 2021):

تا قبل از سال 2021، CLS مجموع تمام جابه‌جایی‌های طول عمر صفحه بود

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

• تعریف جدید (Chrome 91 به بعد):

در سال 2021، تیم کروم تعریف CLS را به “بزرگ‌ترین پنجره ۵ ثانیه‌ای جابه‌جایی‌ها” تغییر داد

که توضیح دادیم. این تغییر رسماً در کروم 91 پیاده‌سازی شد و از اول ژوئن 2021 در ابزارهایی مثل Lighthouse، PageSpeed Insights و گزارش UX کروم (CrUX) نیز منعکس گردید

به عبارتی از اواسط 2021 به بعد، همه ابزارهای اصلی وب از تعریف جدید CLS استفاده کردند و سرچ کنسول نیز اعداد CLS را با این رویکرد محاسبه می‌کند

• بهبودهای بعدی:

پس از تعریف جدید، اصلاحات جزئی دیگری هم در نسخه‌های Chrome صورت گرفته تا CLS منصفانه‌تر باشد. برای مثال، در Chrome 88 تشخیص تغییر مکان عناصر fixed یا sticky بهبود یافت تا CLS ناشی از آنها دقیق‌تر محاسبه شود. یا در Chrome 93 تصمیم گرفته شد جابه‌جایی عناصر هنگام درگ کردن با ماوس یا تغییر سایز صفحه توسط کاربر در CLS لحاظ نشود (چون این‌ها تعامل کاربرند). همچنین کروم باگ‌هایی را در محاسبه محدوده تاثیر (Impact region) و موارد خاص مثل opacity:0 یا المان‌های خارج از viewport رفع کرد خلاصه اینکه CLS اکنون نسبت به روزهای اول خود بسیار هوشمندانه‌تر شده و بهتر می‌تواند موارد آزاردهنده واقعی را منعکس کند.

نکته: اگر از ابزار Lighthouse نسخه 8 به بعد استفاده کنید، امتیاز CLS که می‌بینید بر اساس تعریف جدید است. با این حال، Lighthouse برای اهداف آزمایشی اجازه می‌دهد CLS قدیمی (تجمع کل) را هم ببینید (از طریق property مخفی totalCumulativeLayoutShift در خروجی JSON) بیشتر ابزارها دیگر فقط همان CLS جدید را نشان می‌دهند که معیار رسمی Core Web Vitals است.

دلایل رایج برای نمره CLS ضعیف

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

• تصاویر و ویدیوها بدون ابعاد مشخص:

وقتی <img> یا ویدیو را درج می‌کنید و برای آن width و height مشخص نمی‌کنید (یا معادل CSS آن)، مرورگر نمی‌داند چقدر فضا برایش در نظر بگیرد. نتیجه؟ صفحه رندر می‌شود و متن و دیگر اجزا در جای خود قرار می‌گیرند، سپس به محض لود شدن تصویر، ناگهان فضایی اشغال می‌کند و محتوا را هل می‌دهد. این یک علت کلاسیک CLS است. در گذشته توسعه‌دهندگان برای ریسپانسیو بودن تصاویر، ارتفاع/عرض را حذف می‌کردند و فقط با CSS مثلاً width: 100% تصویر را تنظیم می‌کردند. اما این کار بدون تعیین نسبت ابعاد، منجر به پرش صفحه هنگام لود تصویر می‌شود.

• فونت‌های وب (Web Fonts) و پدیده FOIT/FOUT:

استفاده از فونت‌های سفارشی وب ممکن است به پرش متن منجر شود. دو حالت رایج وجود دارد: یا تا زمانی که فونت لود شود متن اصلاً نمایش داده نمی‌شود (Flash of Invisible Text – FOIT) یا ابتدا با فونت پیش‌فرض سیستم نشان داده می‌شود و بعد از لود فونت ناگهان شکل حروف تغییر می‌کند (Flash of Unstyled Text – FOUT). در هر دو حالت، وقتی فونت اصلی اعمال می‌شود ممکن است اندازه و ارتفاع حروف نسبت به فونت اولیه فرق کند و این تغییر اندازه سطرها، بقیه محتوا را جابه‌جا کند. مخصوصاً اگر فونت جایگزین (fallback) مناسب انتخاب نشده باشد، اختلاف می‌تواند زیاد باشد. این هم عامل رایج دیگری در ناپایداری چیدمان است

• تبلیغات، iframeها و ویجت‌های تعبیه‌شده بدون فضای رزرو:

عناصر شخص ثالث مانند تبلیغات بنری، ویدیوهای جاسازی‌شده (embed) یا iframeهای شبکه‌های اجتماعی اغلب ابعاد نامشخص یا متغیری دارند. مثلاً شبکه تبلیغاتی ممکن است در یک جایگاه تبلیغاتی، گاهی بنر 100px ارتفاع بدهد و گاهی 300px. اگر ما از قبل فضایی برای بزرگ‌ترین حالت در نظر نگیریم، آن المان هر وقت لود شود محتوا را هل می‌دهد و CLS ایجاد می‌کند. ویجت‌های embed (مثل توییت‌های توییتر، نقشه‌های گوگل، ویدیوهای یوتیوب) نیز چون قبل از لود نمی‌دانند چقدر جا می‌گیرند، می‌توانند موجب پرش محتوا شوند. در کل هر محتوایی که بعد از بارگذاری اولیه از خارج بیاید (تبلیغ، iframe، چت‌بات و غیره) اگر بدون جاگذاری مناسب اضافه شود، مشکل‌ساز خواهد بود.

• محتوای پویا که بدون تعامل کاربر اضافه می‌شود:

• این مورد شبیه قبلی است با این تفاوت که ممکن است محتوای خود سایت باشد. مثلا تصور کنید وقتی کاربر به پایین صفحه اسکرول می‌کند، سایت به طور خودکار بخش‌های جدیدی از مقاله یا محصولات بیشتر را بارگذاری می‌کند (بی‌آنکه کاربر دکمه “نمایش بیشتر” بزند). یا وقتی کاربر هنوز در حال خواندن است، یک نوار اطلاع‌رسانی (مثلاً “کوکی‌ها را بپذیرید” یا خبرنامه) بالای صفحه ظاهر شود. این پاپ‌آپ‌های داخلی صفحه اگر ناگهانی بیایند، محتوای در حال نمایش را هل می‌دهند و بسیار آزاردهنده‌اند از آنجا که اینها بدون اقدام کاربر رخ می‌دهند، کاملاً غیرمنتظره بوده و مستقیماً CLS را بالا می‌برند. حتی در حین تعامل هم اگر نتیجه دیر ظاهر شود (مثلاً کاربر روی تب کلیک کند اما تب جدید با تأخیر محتوا را لود و اضافه کند)، باز هم مشکل ایجاد می‌کند.

البته عوامل دیگری هم می‌توانند دخیل باشند (مثلاً یک اسکریپت که با تاخیر CSS یک باکس را تغییر اندازه می‌دهد، یا عدم استفاده از مکان‌نما/Scroll Anchoring در مرورگرهای قدیمی و …)، ولی موارد بالا شایع‌ترین هستند. خبر خوب این که برای همه‌ی این مشکلات، راه‌حل‌های ساده‌ای وجود دارد که در ادامه بررسی می‌کنیم.

چگونه CLS را اندازه‌گیری و عیب‌یابی کنیم؟

• Lighthouse:

لایت‌هاوس (که در DevTools کروم و ابزارهای آنلاین مثل PageSpeed Insights در دسترس است) یکی از بهترین راه‌ها برای تست CLS است. در هر گزارش Lighthouse، CLS یکی از ۵ متریک اصلی بالای صفحه گزارش است. اگر صفحه شما CLS بالایی داشته باشد، Lighthouse در بخش Diagnostics هشداری مثل “Avoid large layout shifts” به همراه جزئیات هر تغییر چیدمان خواهد داد. نسخه‌های جدید Lighthouse از تعریف به‌روز CLS استفاده می‌کنند و حتی فیلم‌نواری (filmstrip) از لحظات بروز تغییرات ارائه می‌کنند تا بفهمید پرش‌ها کجا رخ داده‌اند . PageSpeed Insights نیز بر پایه Lighthouse همین اطلاعات را (به علاوه داده‌های میدانی) به شما می‌دهد.

• Chrome DevTools:

ابزار توسعه‌دهنده کروم امکانات خوبی برای شکار CLS دارد. در تب Performance می‌توانید یک ضبط (Record) از عملکرد صفحه بگیرید؛ Chrome هر رخداد Layout Shift را ثبت می‌کند. همچنین در منوی سه‌نقطه DevTools > More tools گزینه Animations را باز کنید؛ در پانل Animations می‌توانید تیک “Layout Shift Regions” را بزنید. حالا هر بخش از صفحه که هنگام اجرا جابه‌جا شود با یک کادر آبی کمرنگ هایلایت می‌شود

. این بسیار کمک می‌کند بفهمید کدام المان‌ها حرکت کرده‌اند. DevTools اخیراً در تب Performance یک بخش “Layout Shift Culprits” هم اضافه کرده که مستقیماً المان‌های مسئول CLS را فهرست می‌کند. به طور خلاصه، Chrome DevTools هم برای شبیه‌سازی پرش‌ها و هم برای شناسایی عامل آنها ابزارهای مفیدی در اختیار شما می‌گذارد.

DebugBear: دباک‌بیر یک سرویس مانیتورینگ سرعت وب است که هم تست‌های آزمایشگاهی انجام می‌دهد و هم داده‌های واقعی کاربران (RUM) را ارائه می‌کند. در تست‌های DebugBear می‌توانید مقدار CLS را در تب Overview مشاهده کنید و حتی جزئیات تمام رخدادهای Layout Shift را ببینید. مزیت DebugBear این است که به طور خودکار توصیه‌هایی برای بهبود CLS می‌دهد و می‌تواند روند امتیازهای شما را در طول زمان دنبال کند. اگر به دنبال ابزاری هستید که مدام سایتتان را چک کند و Core Web Vitals را زیر نظر بگیرد، DebugBear گزینه خوبی است. (البته این یک سرویس پولی است، اما نسخه آزمایشی رایگان دارد.)

• اسکریپت‌ها و کتابخانه‌های اندازه‌گیری:

برای تست برنامه‌نویسی، می‌توانید از API مرورگر برای دریافت CLS استفاده کنید. Layout Instability API در جاوااسکریپت امکان گوش دادن به رخدادهای layout-shift را می‌دهد. گوگل نیز یک کتابخانه به نام Web Vitals JS ارائه کرده که به سادگی CLS و دیگر وب وایتال‌ها را در کد شما اندازه می‌گیرد. این کتابخانه را می‌توانید در سایت خود قرار دهید تا مثلاً CLS هر کاربر را در Google Analytics یا سرور خودتان گزارش کنید. ابزارهای دیگری مانند Chrome Web Vitals Extension (افزونه کروم) نیز وجود دارند که با یک نشانگر کوچک در مرورگر، مقادیر LCP/FID/CLS را در لحظه نمایش می‌دهند.

ابزارها و داده‌های میدانی (Field) برای CLS

• گزارش Core Web Vitals در سرچ کنسول:

بهترین منبع داده‌های میدانی برای CLS، گزارش «تجربه کاربر» یا همان Core Web Vitals در Google Search Console است. این گزارش بر اساس دیتابیس کروم (Chrome User Experience Report – CrUX) تهیه می‌شود که اطلاعات عملکرد واقعی کاربران را به صورت ناشناس جمع‌آوری می‌کند .

در این گزارش، URLهای سایت شما به گروه‌های «خوب»، «نیاز به بهبود» و «ضعیف» بر اساس CLS (و LCP و INP) تقسیم می‌شوند. همان‌طور که گفتیم معیار گوگل این است که حداقل 75% از بازدیدها CLS ≤ 0.1 داشته باشند تا یک صفحه را خوب در نظر بگیرد .

سرچ کنسول برای هر گروه صفحه، نمونه URLهایی را لیست می‌کند و بدترین مقدار CLS مشاهده‌شده (در صدک 75) را نشان می‌دهد. شما می‌توانید روی هر مشکل کلیک کنید و جزئیات صفحات متأثر را ببینید. مثلا ممکن است ببینید تمام صفحات دسته “مقالات وبلاگ” در موبایل CLS بدی داشته‌اند که شاید به خاطر یک بنر تبلیغاتی مشترک باشد. این بینش به شما کمک می‌کند مشکلات را اولویت‌بندی و رفع کنید. توجه داشته باشید که داده‌های این گزارش مربوط به 28 روز گذشته است، بنابراین پس از اعمال تغییرات، مدتی طول می‌کشد تا بهبود CLS در این گزارش منعکس شود.

• PageSpeed Insights و CrUX:

• ابزار PageSpeed Insights گوگل ترکیبی از داده آزمایشگاهی (Lighthouse) و میدانی (CrUX) را برای یک URL مشخص نمایش می‌دهد. در بخش Field Data آن، مقدار (واقعی) CLS برای دسکتاپ و موبایل آمده که معمولاً همان مقداری است که سرچ کنسول گزارش می‌کند (صدک 75) . اگر می‌خواهید داده میدانی یک URL خاص را ببینید، این ابزار مفید است. همچنین اگر توسعه‌دهنده کنجکاوی هستید، می‌توانید از BigQuery یا API CrUX مستقیماً آمار CLS سایت خود را استخراج کنید (البته این پیشرفته‌تر است).

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