CLS چیست و چگونه از جابه جایی چیدمان جلوگیری کنیم؟

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

یا وارد صفحه محصولی می شوید، عنوان و دکمه خرید را می بینید و چند لحظه بعد با لود شدن تصویر محصول، همه عناصر صفحه ناگهان جابه جا می شوند.

این اتفاق ها نمونه هایی از Layout Shift هستند؛ یعنی تغییر ناگهانی موقعیت عناصر قابل مشاهده صفحه بدون اینکه کاربر انتظار آن را داشته باشد.

CLS یا Cumulative Layout Shift یکی از معیارهای Core Web Vitals است که پایداری بصری صفحه را اندازه گیری می کند و نشان می دهد کاربران تا چه اندازه با جابه جایی غیرمنتظره عناصر مواجه می شوند.

CLS در کنار LCP و INP یکی از سه معیار اصلی Core Web Vitals است. LCP بیشتر به سرعت نمایش محتوای اصلی مربوط می شود، INP پاسخ گویی صفحه به تعاملات را می سنجد و CLS روی Visual Stability یا ثبات بصری تمرکز دارد.

در این مقاله می بینیم CLS دقیقاً چگونه محاسبه می شود، چه عددی برای آن مناسب است، چه عواملی باعث جابه جایی چیدمان می شوند و چگونه می توان علت CLS ضعیف را پیدا و برطرف کرد.

CLS چیست؟

CLS مخفف Cumulative Layout Shift است و میزان جابه جایی غیرمنتظره عناصر قابل مشاهده صفحه را اندازه گیری می کند.

نکته مهم در این تعریف کلمه «غیرمنتظره» است.

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

برای مثال، تصور کنید متن زیر روی صفحه قرار دارد:

«برای ثبت سفارش روی دکمه ادامه کلیک کنید.»

کاربر انگشت خود را روی دکمه «ادامه» می برد، اما در همان لحظه یک تصویر بالاتر از دکمه بارگذاری می شود. دکمه پایین می رود و کاربر ناخواسته روی گزینه دیگری کلیک می کند.

CLS برای کمی سازی چنین بی ثباتی هایی طراحی شده است.

برخلاف LCP و INP، مقدار CLS برحسب ثانیه یا میلی ثانیه نیست. CLS یک عدد بدون واحد است که براساس میزان فضای جابه جا شده و فاصله ای که عناصر حرکت کرده اند محاسبه می شود.

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

براساس معیار فعلی Core Web Vitals:

برای ارزیابی تجربه اکثر کاربران، توصیه می شود مقدار مناسب CLS در صدک ۷۵ بازدیدها حفظ شود و موبایل و دسکتاپ نیز جداگانه بررسی شوند.

بنابراین اینکه در یک بار اجرای Lighthouse مقدار CLS برابر صفر باشد، به تنهایی ثابت نمی کند کاربران واقعی هم همیشه صفحه ای بدون جابه جایی تجربه می کنند.

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

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

برای فهم بهتر CLS باید ابتدا یک Layout Shift منفرد را در نظر بگیریم.

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

به شکل ساده:

Layout Shift Score = Impact Fraction × Distance Fraction

Impact Fraction نشان می دهد چه سهمی از Viewport تحت تأثیر عنصر جابه جا شده قرار گرفته است.

Distance Fraction نیز میزان حرکت عنصر را نسبت به ابعاد Viewport در نظر می گیرد.

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

اما CLS فعلی صرفاً مجموع تمام Layout Shiftهای طول عمر صفحه نیست.

مرورگر Layout Shiftهایی را که در فاصله زمانی نزدیک به هم اتفاق افتاده اند در Session Windowها گروه بندی می کند. یک Session Window می تواند حداکثر پنج ثانیه طول داشته باشد و فاصله میان دو Shift متوالی در آن کمتر از یک ثانیه است.

در نهایت بزرگ ترین Burst یا Session Window از Layout Shiftهای غیرمنتظره، مبنای CLS صفحه قرار می گیرد.

این موضوع به خصوص برای صفحات طولانی اهمیت دارد، چون باعث می شود صرفاً طولانی بودن زمان حضور کاربر در صفحه به صورت نامحدود CLS را افزایش ندهد.

آیا هر جابه جایی صفحه روی CLS اثر دارد؟

نه.

CLS قرار نیست هر نوع تغییر رابط کاربری را جریمه کند. مسئله اصلی جابه جایی غیرمنتظره است.

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

Layout Shiftهایی که در فاصله ۵۰۰ میلی ثانیه ای بعد از برخی تعاملات مستقیم کاربر رخ می دهند می توانند با hadRecentInput مشخص شوند و از محاسبه CLS کنار گذاشته شوند.

اما نباید از این قاعده نتیجه گرفت که هر جابه جایی بعد از تعامل قابل قبول است.

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

راه بهتر این است که از ابتدا فضای موردنیاز را رزرو کنید یا وضعیت Loading مشخصی نمایش دهید.

چرا CLS سایت بالا می رود؟

CLS ضعیف معمولاً زمانی ایجاد می شود که مرورگر در Layout اولیه نمی داند یک عنصر در نهایت چه مقدار فضا نیاز خواهد داشت.

صفحه ابتدا بدون آن فضا Render می شود و وقتی منبع موردنظر Load یا محتوای جدید اضافه شد، مرورگر مجبور می شود عناصر موجود را جابه جا کند.

تصاویر بدون Width و Height

یکی از رایج ترین دلایل CLS، تصویرهایی هستند که ابعاد آن ها برای مرورگر مشخص نشده است.

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

نتیجه چیست؟

تمام محتوای زیر تصویر پایین می رود.

بهتر است ابعاد واقعی تصویر در HTML مشخص شوند:

<img src="image.webp" width="800" height="450" alt="...">

وجود width و height به مرورگر اجازه می دهد Aspect Ratio را قبل از دانلود کامل تصویر تشخیص دهد و فضای مناسب را از ابتدا رزرو کند.

در طراحی Responsive همچنان می توان با CSS اندازه تصویر را کنترل کرد:

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

مشخص کردن Width و Height به این معنی نیست که تصویر باید روی تمام دستگاه ها دقیقاً با همان اندازه نمایش داده شود؛ هدف اصلی این است که مرورگر نسبت ابعاد را از ابتدا بشناسد.

تبلیغات، Embedها و iframeهای بدون فضای رزروشده

تبلیغات یکی دیگر از منابع مهم Layout Shift هستند.

فرض کنید وسط یک مقاله جایگاهی برای تبلیغ وجود دارد، اما ارتفاع آن تا زمان دریافت تبلیغ صفر است. وقتی Ad Network تبلیغ ۲۵۰ پیکسلی را Load می کند، ناگهان تمام محتوای پایین صفحه جابه جا می شود.

همین اتفاق می تواند برای مواردی مانند ویدئوی Embed شده، Google Maps، پست شبکه اجتماعی یا iframeهای مختلف رخ دهد.

راه اصلی، رزرو فضای تقریبی یا مشخص برای عنصر قبل از Load شدن آن است.

برای مثال می توان برای Container از min-height یا aspect-ratio استفاده کرد.

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

اضافه شدن محتوای Dynamic بالای محتوای موجود

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

برای مثال:

• بنر تخفیف ناگهان بالای Header ظاهر شود.
• فرم Newsletter بالای متن Insert شود.
• پیام Cookie کل صفحه را پایین هل دهد.
• Notification جدید در بالای محتوا اضافه شود.

اگر چنین عناصری قرار است نمایش داده شوند، بهتر است فضای آن ها از ابتدا رزرو شود یا در شرایط مناسب به صورت Overlay نمایش داده شوند تا جریان Document را جابه جا نکنند.

Web Fontها

فونت ها نیز می توانند باعث Layout Shift شوند.

گاهی مرورگر ابتدا متن را با یک Font جایگزین نمایش می دهد و بعد از دانلود Web Font، فونت اصلی را جایگزین می کند.

اگر عرض حروف، ارتفاع خط یا سایر Metricهای دو فونت متفاوت باشند، طول سطرها تغییر می کند و ممکن است پاراگراف ها، دکمه ها و بخش های پایین صفحه جابه جا شوند.

برای کاهش این مشکل می توان فونت های ضروری را زودتر Load کرد، Fallback مناسب تری انتخاب کرد و اختلاف Metricهای فونت جایگزین و اصلی را کاهش داد.

ویژگی هایی مانند size-adjust و Font Metric Overrides نیز در پروژه هایی که کنترل فنی بیشتری دارند می توانند مفید باشند.

Animationهایی که Layout را تغییر می دهند

هر انیمیشنی CLS ایجاد نمی کند.

مشکل زمانی بیشتر می شود که برای حرکت Element از Propertyهایی استفاده شود که Layout صفحه را تغییر می دهند؛ مانند تغییر top، left یا بعضی ابعاد.

در بسیاری از سناریوها استفاده از transform: translate() برای حرکت و transform: scale() برای تغییر اندازه گزینه مناسب تری است، چون تغییرات مبتنی بر Transform می توانند بدون ایجاد Layout Shift اجرا شوند.

البته انتخاب نوع Animation فقط مسئله CLS نیست و باید تجربه کاربری و Accessibility نیز در نظر گرفته شود.

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

بهتر است بررسی CLS را با داده کاربران واقعی شروع کنید و بعد برای پیدا کردن علت فنی سراغ ابزارهای Lab بروید.

Search Console

گزارش Core Web Vitals در Google Search Console به شما نشان می دهد چه گروه هایی از URLها از نظر CLS، LCP یا INP وضعیت Good، Needs Improvement یا Poor دارند.

Search Console برای تشخیص دامنه مشکل مناسب است، اما معمولاً نمی گوید دقیقاً کدام تصویر یا Element باعث جابه جایی شده است.

PageSpeed Insights

PageSpeed Insights می تواند داده واقعی کاربران را از Chrome UX Report یا CrUX نشان دهد.

این اطلاعات به خصوص برای مقایسه وضعیت واقعی سایت با تست های Local مفید است.

اگر Field CLS بالا ولی نتیجه Lab پایین باشد، احتمال دارد جابه جایی بعد از Load اولیه اتفاق بیفتد؛ برای مثال هنگام Scroll، نمایش تبلیغ یا بارگذاری یک Component دیرهنگام.

Chrome DevTools

برای پیدا کردن عنصر مشکل دار، Performance Panel در Chrome DevTools بسیار مفید است.

در Trace می توانید Layout Shiftها را مشاهده کنید و ببینید کدام Elementها هنگام Shift جابه جا شده اند.

این تفاوت مهم است:

عنصر جابه جا شده الزاماً عامل ایجاد CLS نیست.

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

پس هنگام Debug فقط دنبال Element متحرک نباشید؛ ببینید چه چیزی باعث حرکت آن شده است.

Lighthouse

Lighthouse می تواند Layout Shiftهایی را که در محیط Lab مشاهده می کند گزارش دهد، اما معمولاً یک بار Load مصنوعی صفحه را بررسی می کند.

CLS واقعی می تواند در تمام طول حضور کاربر روی صفحه ایجاد شود.

بنابراین کم بودن CLS در Lighthouse لزوماً به این معنی نیست که CLS واقعی کاربران هم پایین است. ابزارهای Field و Lab باید مکمل یکدیگر باشند.

چگونه CLS را بهتر کنیم؟

روش بهبود CLS به علت آن بستگی دارد. صرفاً دیدن عدد بالا و اجرای چند Optimization عمومی معمولاً بهترین مسیر نیست.

ابتدا باید مشخص شود چه عنصری جابه جا می شود و چه چیزی باعث این حرکت شده است.

برای تصاویر و ویدئوها از ابتدا فضا رزرو کنید

برای تصاویر، width و height را مشخص کنید یا از aspect-ratio مناسب استفاده کنید.

همین منطق برای Video Player، Thumbnail و سایر Media Elementها هم صدق می کند.

مرورگر باید پیش از دانلود کامل فایل بداند چه فضایی باید برای آن کنار بگذارد.

برای Ads و Embedها Placeholder داشته باشید

جای تبلیغ یا Widget خارجی نباید در ابتدا ارتفاع صفر داشته باشد و بعد ناگهان باز شود.

یک Container با حداقل ارتفاع مناسب یا Aspect Ratio مشخص ایجاد کنید.

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

در بعضی شرایط ممکن است کمی فضای خالی باقی بماند، اما این Trade-off می تواند از جابه جایی آزاردهنده کل محتوا بهتر باشد.

محتوای جدید را بدون برنامه بالای صفحه Insert نکنید

اگر Banner، Alert یا Component جدیدی دارید که بعد از Load باید ظاهر شود، قبل از قرار دادن آن بالای محتوای موجود بررسی کنید چه تأثیری روی Layout می گذارد.

در بسیاری از موارد می توان فضای آن را از ابتدا رزرو کرد یا آن را به شکل Overlay نمایش داد.

Lazy Loading را با رزرو فضا ترکیب کنید

Lazy Loading به خودی خود باعث CLS نمی شود.

مشکل زمانی ایجاد می شود که Element به صورت Lazy Load دریافت شود اما پیش از دانلود هیچ فضایی برای آن وجود نداشته باشد.

بنابراین Lazy Loading تصاویر پایین صفحه همچنان می تواند انتخاب مناسبی باشد، به شرط آنکه مرورگر ابعاد Element را از ابتدا بشناسد.

فونت ها را هدفمند مدیریت کنید

فونت هایی را که برای نمایش اولیه محتوا ضروری هستند زودتر در دسترس مرورگر قرار دهید و Fallbackهایی انتخاب کنید که از نظر Metrics بیش از حد با فونت اصلی متفاوت نباشند.

هدف فقط سریع تر شدن دانلود فونت نیست؛ باید تغییر ابعاد متن هنگام Font Swap را هم کاهش دهید.

Animation را بدون Reflow غیرضروری اجرا کنید

برای جابه جایی بصری Elementها، در صورت مناسب بودن از transform استفاده کنید و از Animation بی دلیل Propertyهایی که Layout را دوباره محاسبه می کنند پرهیز کنید.

هدف این نیست که تمام Animationها حذف شوند؛ هدف این است که حرکت عمدی رابط کاربری باعث بی ثباتی غیرمنتظره Layout نشود.

یک سناریوی عملی برای رفع CLS

فرض کنیم یک سایت خبری داریم و PageSpeed Insights نشان می دهد CLS کاربران موبایل ضعیف است.

اما وقتی صفحه را روی سیستم خودمان باز می کنیم، ظاهراً مشکلی نمی بینیم.

در DevTools و داده کاربران واقعی متوجه می شویم سه اتفاق رخ می دهد:

تصویر اصلی مقاله در HTML Width و Height ندارد و بعد از Load متن را پایین می برد.

یک Ad Slot وسط مقاله با ارتفاع صفر شروع می شود و پس از دریافت تبلیغ ۲۸۰ پیکسل فضا ایجاد می کند.

فونت اصلی نیز کمی دیر Load می شود و به دلیل تفاوت زیاد با Fallback باعث تغییر Line Wrap تیتر می شود.

در این سناریوی فرضی، یک «راه حل CLS» واحد وجود ندارد.

برای تصویر ابعاد مشخص می کنیم، برای تبلیغ فضای اولیه رزرو می کنیم و Font Loading و Fallback را اصلاح می کنیم.

بعد دوباره Page را در DevTools آزمایش می کنیم و در ادامه Field Data را زیر نظر می گیریم.

قاعده ای که از این مثال می توان گرفت این است:

برای کاهش CLS ابتدا منبع جابه جایی را پیدا کنید؛ سپس همان علت را اصلاح کنید، نه صرفاً عدد گزارش را.

تفاوت CLS با LCP و INP چیست؟

هر سه معیار بخشی متفاوت از تجربه کاربری را اندازه گیری می کنند.

LCP می پرسد محتوای اصلی صفحه چه زمانی برای کاربر قابل مشاهده می شود.

INP می پرسد صفحه بعد از تعامل کاربر با چه سرعتی می تواند پاسخ بصری بعدی را ارائه کند.

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

بنابراین ممکن است یک سایت LCP خوبی داشته باشد و محتوای اصلی سریع ظاهر شود، اما همان محتوا بعداً جابه جا شود و CLS ضعیفی ایجاد کند.

یا ممکن است CLS تقریباً صفر باشد، اما کلیک روی منو و دکمه ها با تأخیر پاسخ داده شود؛ در این حالت مسئله بیشتر به INP مربوط است.

این معیارها مکمل یکدیگرند، نه جایگزین یکدیگر.

آیا CLS روی SEO تأثیر دارد؟

CLS یکی از Core Web Vitals است و Google اعلام کرده سیستم های Ranking از Core Web Vitals استفاده می کنند. با این حال، داشتن CLS خوب تضمین نمی کند یک صفحه رتبه بالاتری بگیرد. Google صراحتاً می گوید داشتن نتایج خوب در گزارش هایی مانند Core Web Vitals به معنی تضمین حضور در رتبه های بالای Search نیست.

در سئو تکنیکال، بهتر است Core Web Vitals را به عنوان بخشی از کیفیت فنی و تجربه صفحه ببینیم، نه یک سیستم امتیازدهی که با رسیدن به عدد سبز مستقیماً Ranking افزایش پیدا کند.

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

اشتباهات رایج در بهینه سازی CLS

یکی از اشتباهات رایج این است که فقط Page Load اولیه بررسی شود. Layout Shift می تواند چند ثانیه بعد، هنگام Scroll یا پس از Load شدن محتوای Dynamic رخ دهد.

اشتباه دیگر این است که هر حرکت صفحه CLS در نظر گرفته شود. تغییرات مورد انتظار و مرتبط با تعامل مستقیم کاربر شرایط متفاوتی دارند.

از طرف دیگر، حذف Lazy Loading صرفاً به دلیل CLS معمولاً تصمیم دقیقی نیست. مشکل اصلی اغلب نبود فضای رزروشده است، نه خود Lazy Loading.

همچنین مشخص کردن یک ارتفاع ثابت تصادفی برای همه تصاویر یا تبلیغات می تواند مشکلات Responsive جدیدی ایجاد کند. فضای رزروشده باید با Aspect Ratio و طراحی واقعی Component سازگار باشد.

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

جمع بندی

CLS یا Cumulative Layout Shift معیار ثبات بصری صفحه است و نشان می دهد کاربران با چه میزان جابه جایی غیرمنتظره در محتوای قابل مشاهده روبه رو می شوند.

برای تجربه مناسب، هدف فعلی Core Web Vitals CLS برابر ۰.۱ یا کمتر در صدک ۷۵ بازدیدها است.

اما برای رسیدن به این عدد نباید از یک Checklist تصادفی شروع کرد.

ابتدا مشخص کنید Layout Shift کجا و در چه شرایطی اتفاق می افتد. سپس علت آن را پیدا کنید: تصویر بدون ابعاد، تبلیغ بدون فضای رزروشده، محتوای Dynamic، Font Swap یا Animation نامناسب.

پس از آن همان عامل را اصلاح و نتیجه را هم در محیط Lab و هم با داده کاربران واقعی بررسی کنید.

قاعده عملی ساده است:

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