فهرست مطالب
وقتی میخواهید روی دکمهای بزنید و همان لحظه تصویر بالای آن بارگذاری میشود، دکمه زیر انگشتتان جابهجا میشود. CLS یا Cumulative Layout Shift عددی برای سنجش همین بیثباتی دیداریِ ناخواسته است؛ نه سرعت دانلود صفحه. در این آموزش با Chrome DevTools منشأ پرش را پیدا میکنید، سه علت رایج را اصلاح میکنید و یاد میگیرید چرا عدد آزمایش روی لپتاپ ممکن است با تجربهٔ کاربران واقعی یکی نباشد.
اگر با Gemini Canvas اپ یا صفحه میسازید، پیشنمایش زیبا را پایان کار ندانید؛ بعد از بارگذاری تصویر و فونت هم صفحه را آزمایش کنید. همین مسئله برای خروجی Claude Artifacts و شیوهٔ ساخت آن صدق میکند: ساخت رابط سریع است، اما پایدار ماندن چیدمان مسئولیت مرحلهٔ آزمون است.
CLS چیست و چرا باید به آن اهمیت داد؟
CLS مقدار پرشهای غیرمنتظرهٔ اجزای قابلدیدن صفحه را در طول عمر صفحه خلاصه میکند. اگر متن مقاله پایین برود چون تصویر بدون جای رزروشده ناگهان ظاهر شده، احتمالاً سهمی در CLS دارد. حرکت عمدی و فوری پس از کلیک کاربر معمولاً مثل پرش ناخواسته شمرده نمیشود؛ بااینحال، حرکت دیرهنگام پس از تعامل یا جابهجایی هنگام اسکرول ممکن است در اندازهگیری وارد شود.
راهنمای گوگل میگوید برای تجربهٔ خوب، CLS باید ۰٫۱ یا کمتر در دستکم ۷۵ درصد بازدیدها باشد. این یک عدد بدون واحد است، نه ثانیه و نه درصد. اهمیتش پیش از سئو کاملاً انسانی است: خواننده جای خطی را که میخواند گم میکند یا روی دکمهٔ اشتباه میزند. گوگل Core Web Vitals را در سامانههای رتبهبندی لحاظ میکند، اما نمرهٔ خوب بهتنهایی تضمین رتبهٔ بالا نیست.
پیشنیازها و یک صفحهٔ آزمایشی
به نسخهٔ بهروز Chrome، نشانی صفحهای که میخواهید بسنجید و دسترسی به DevTools نیاز دارید. برای رفع اشکال، بهتر است به کد یا پنل مدیریت سایت هم دسترسی داشته باشید؛ بدون آن هنوز میتوانید علت را تشخیص دهید، ولی اصلاح نهایی در اختیار مالک سایت است. ابتدا یک صفحهٔ مقاله با تصویر شاخص، متن و احتمالاً بنر یا تبلیغ انتخاب کنید؛ صفحهٔ اصلی همیشه نمایندهٔ تجربهٔ مقاله نیست.
دو حالت را جداگانه امتحان کنید: بارگذاری از ابتدا، و رفتاری که پس از بارگذاری رخ میدهد، مثل اسکرول یا باز شدن بنر. پنجره را یکبار با عرض موبایل و یکبار با عرض دسکتاپ بررسی کنید. اگر ابزار حریم خصوصی یا افزونهای محتوا را حذف میکند، اثر آن را یادداشت کنید تا نتیجهٔ شخصی خود را با همهٔ کاربران یکی ندانید.
گام ۱: اختلاف آزمایش و کاربران واقعی را ببینید
نشانی صفحه را در PageSpeed Insights وارد کنید و بخش موبایل را نگاه کنید. قسمت تجربهٔ کاربران واقعی، اگر دادهٔ کافی برای URL یا مبدأ موجود باشد، از دادههای Chrome UX Report استفاده میکند؛ بخش تشخیص عملکرد، اجرای آزمایشگاهی Lighthouse است. دقت کنید دادهٔ نمایشدادهشده مخصوص همان URL است یا کل مبدأ؛ اگر دادهٔ URL کافی نباشد، نتیجهٔ مبدأ را نباید به یک مقالهٔ خاص نسبت داد.
عددها اگر فرق داشتند، فوراً یکی را غلط فرض نکنید. آزمایش عادی بیشتر بارگذاری اولیه را میبیند، ولی بازدید واقعی میتواند اسکرول، بنر تأخیری و تعاملهای بعدی را هم شامل شود. نتیجهٔ مورد انتظار این گام یک یادداشت ساده است: CLS میدانی و آزمایشگاهی، موبایل یا دسکتاپ، و اینکه دادهٔ میدانی مربوط به URL بوده یا مبدأ. اگر دادهٔ میدانی ندارید، همین را ثبت کنید و سراغ آزمون محلی بروید؛ عدد را حدس نزنید.
گام ۲: پرش را در Live Metrics بازسازی کنید
صفحه را در Chrome باز کنید و DevTools را با منوی مرورگر یا کلیدهای میانبر باز کنید. تب Performance در نسخههای جاری صفحهٔ Live Metrics را نشان میدهد: کنار LCP و INP، مقدار CLS محلی را میبینید. اگر تب پیدا نشد، از منوی سهنقطهٔ DevTools یا فهرست تبهای پنهان آن را باز کنید. نام و جای دقیق گزینهها ممکن است در نسخههای بعدی تغییر کند؛ مستندات جاری Chrome مرجع است.
صفحه را تازهسازی کنید، سپس آرام اسکرول کنید و همان کاری را انجام دهید که پرش را ایجاد میکند. به فهرست Layout shifts و زمان تغییر عدد نگاه کنید. اگر بنری پس از چند ثانیه باز میشود، تا ظاهر شدنش صبر کنید؛ آزمونی که بلافاصله پس از بارگذاری تمام شود آن را از دست میدهد. نتیجهٔ این گام باید یک رفتار بازتولیدپذیر باشد، مثل «بعد از نمایش تصویر دوم، پاراگراف سوم پایین میرود»؛ صرفاً یک عدد قرمز برای رفع اشکال کافی نیست.
گام ۳: با ضبط Performance مقصر را پیدا کنید
در پنل Performance برای پرش هنگام بارگذاری، گزینهٔ Record and reload را بزنید. برای پرش پس از بارگذاری، ضبط معمولی را آغاز کنید، همان اسکرول یا تعامل را تکرار کنید و ضبط را متوقف کنید. در ردگیریِ بهدستآمده، نوار Layout shifts و نشانهای بنفش را پیدا کنید؛ با انتخاب هر مورد، زمان، امتیاز جابهجایی و عناصر جابهجا شده در بخش خلاصه دیده میشوند. بخش Layout shift culprits در Insights هم ممکن است علتهای محتمل را پیشنهاد کند.
اینجا یک دام مهم وجود دارد: عنصری که در فهرست «جابهجا شده» میبینید لزوماً علت نیست. مثلاً پاراگراف پایین تصویر جابهجا شده، اما مقصر تصویر بیابعادی است که بالاتر از آن فضای تازه گرفته است. در نمونهٔ رسمی web.dev که تصویر جلد از آن گرفته شده، ردگیری مقدار ۰٫۳۳ را نشان میدهد و Insight به تصویرهای بدون ابعاد اشاره میکند؛ این عدد فقط مربوط به همان نمونه است، نه سایت شما. از روی زمان پرش، عنصرهای بالادست را هم بررسی کنید.
گام ۴: برای تصویر و ویدئو از پیش جا نگه دارید
اگر تصویر شاخص، عکس داخل مقاله یا ویدئوی جاسازیشده پس از آمدن متن جا باز میکند، باید نسبت عرض به ارتفاع آن پیش از دریافت فایل برای مرورگر معلوم باشد. برای تصویر، ابعاد واقعی را در ویژگیهای width و height عنصر ثبت کنید و در طراحی واکنشگرا اجازه دهید عرض با ظرف صفحه هماهنگ شود و ارتفاع متناسب بماند. این کار تصویر را لزوماً با همان اندازهٔ ثابت نمایش نمیدهد؛ به مرورگر میگوید پیش از بارگذاری چه نسبتی از فضا رزرو کند.
برای ویدئو، iframe و کارت دارای تصویر، ظرفی با نسبت ابعاد پایدار در نظر بگیرید. در صفحهٔ مقاله این نکته بهویژه دربارهٔ تصویر جلد و عکسهای میان متن مهم است: اگر نخست متن رندر شود و بعد رسانه وارد جریان صفحه شود، خواننده جای خود را گم میکند. پس از اصلاح، همان مسیر گام سوم را دوباره ضبط کنید؛ انتظار دارید پرش مرتبط با رسانه از ردگیری حذف شود یا کوچکتر شود، نه اینکه صرفاً تصویر زودتر دیده شود.
گام ۵: جای بنر و محتوای پویا را از ابتدا مشخص کنید
بنر رضایت، تبلیغ، پیشنهاد عضویت و نتیجهٔ فراخوانی API ممکن است پس از رندر اولیه بالای متن قرار بگیرند. اگر حضورشان قابل پیشبینی است، برایشان فضای کافی یا یک جاینگهدار در همان محل رزرو کنید. اگر بنر باید روی صفحه ظاهر شود، طراحی همپوشان را با دقت بررسی کنید تا محتوای اصلی را به پایین هل ندهد؛ همپوشانی نیز نباید دکمهها را بپوشاند یا دسترسپذیری را خراب کند.
برای محتوای نامشخص، اندازهٔ تقریبی واقعبینانه انتخاب کنید و نتیجهٔ نهایی را در همان ظرف جایگزین کنید. ارتفاع ثابتِ بسیار بزرگ شاید CLS را کم کند، ولی فضای سفید بیفایده میسازد؛ معیار فقط یک عدد نیست. پس از تغییر، بارگذاری کند، موبایل و حالت خطای API را هم امتحان کنید. اگر داده هرگز نرسید، جاینگهدار نباید برای همیشه صفحه را اشغال کند.
گام ۶: فونت فارسی و تغییر اندازهٔ متن را بررسی کنید
گاهی تصویر مقصر نیست: فونت جایگزین ابتدا متن را با عرضی متفاوت میچیند و بعد فونت وب بارگذاری میشود. در متن فارسیِ طولانی، همین اختلاف میتواند چند خط و در نتیجه جای تصویرها یا تیترهای پایین صفحه را تغییر دهد. در ردگیری، زمان بارگذاری فونت و لحظهٔ پرش را مقایسه کنید و یک بار با سرعت شبکهٔ پایینتر آزمون بگیرید. اگر همزمانی روشن بود، فونت جایگزین نزدیکتر، بارگذاری زودتر فونت ضروری و تنظیمات فونت مناسب را بررسی کنید.
از پنهان کردن تمام متن تا آمدن فونت بهعنوان راهحل عمومی استفاده نکنید؛ ممکن است خواندن را عقب بیندازد. مستندات web.dev دربارهٔ گزینههایی مانند font-display و تنظیم معیارهای فونت جایگزین توضیح میدهد، اما انتخاب مناسب به قلم و طراحی شما وابسته است. نتیجه را با چند پاراگراف واقعی فارسی و تیترهای بلند بسنجید، نه فقط با یک جملهٔ لاتین نمونه.
جدول تشخیص: هر ابزار چه چیزی را نشان میدهد؟
ابزار | چه میبینید؟ | برای چه زمانی مفید است؟ | محدودیت مهم |
|---|---|---|---|
PageSpeed Insights، دادهٔ میدانی | تجربهٔ کاربران واقعی، در صورت وجود داده | اولویتبندی URL یا مبدأ | علت دقیق یک پرش را همیشه نشان نمیدهد |
PageSpeed Insights، آزمایشگاهی | اجرای کنترلشدهٔ بارگذاری | یافتن مشکل اولیهٔ قابلبازتولید | ممکن است پرش پس از اسکرول را نبیند |
Chrome DevTools، Live Metrics | تغییر CLS هنگام کار خودتان با صفحه | بازسازی پرش تعاملی یا تأخیری | یک اجرای محلی نمایندهٔ همهٔ کاربران نیست |
Chrome DevTools، Performance trace | زمان، عناصر جابهجا شده و سرنخ علت | رسیدن از علامت به عنصر و اصلاح | عنصر جابهجا شده ممکن است مقصر اصلی نباشد |
جدول برای انتخاب ابزار است، نه مقایسهٔ امتیاز سایت. اگر فقط دادهٔ میدانی بد است، سراغ مسیرهای پس از بارگذاری و دستگاههای متفاوت بروید. اگر آزمایش و میدان هر دو بدند، بارگذاری اولیهٔ همان قالب صفحه نقطهٔ شروع مناسبی است.
گام ۷: اصلاح را در همان شرایط دوباره بسنجید
قبل و بعد را با همان URL، عرض صفحه و مسیر تعامل مقایسه کنید. یک بار تغییر ممکن است پرش را فقط به نقطهٔ دیگری منتقل کند؛ بنابراین هم عدد CLS و هم ردگیری عناصر را ببینید. برای تأیید، صفحه را چند بار با شبکهٔ کندتر و با محتوای متفاوت آزمایش کنید؛ بهخصوص مقالهای که تصویر بیشتر یا عنوان بلندتری دارد.
دادهٔ میدانی PageSpeed Insights بلافاصله پس از انتشار تغییر بهروز نمیشود. پس از انتشار، گزارشهای کاربران واقعی را در بازهٔ بعدی دوباره بررسی کنید و مراقب باشید دادهٔ مبدأ را به یک URL خاص نسبت ندهید. تا آن زمان، آزمون محلی شاهد خوبی برای برطرفشدن همان علت است، نه تضمین بهبود همهٔ بازدیدها.
نکتهٔ عملی برای سایتهای فارسی
چیدمان راستبهچپ و فونت فارسی مشکل CLS را ذاتاً متفاوت نمیکند، اما خطای فونت جایگزین یا طول عنوانها را نمایانتر میسازد. برای سایت مقالهای، سه صفحه را بهعنوان نمونه نگه دارید: مقالهٔ کوتاه بدون تصویر میانی، مقالهٔ بلند با چند تصویر و صفحهای با بنر یا عنصر پویا. هر سه را روی موبایل و دسکتاپ با همان مسیر گامهای بالا بسنجید و علت هر پرش را کنار تغییر اعمالشده ثبت کنید.
اگر خروجی صفحه را با ابزارهای هوش مصنوعی ساختهاید، از مدل نخواهید صرفاً «CLS را صفر کند»؛ زمان پرش، عنصر بالادست و رفتار مورد انتظار را بهطور دقیق به آن بدهید. سپس تغییر تولیدشده را خودتان در DevTools تأیید کنید. برای دسترسی به Chrome DevTools در مرورگر هزینهٔ اشتراک جداگانهای مطرح نیست، اما شرایط دسترسی به سرویسهای جانبی و دادهٔ میدانی را نباید برای همهٔ مناطق یکسان فرض کرد.
جمعبندی
رفع CLS با دیدن عدد شروع میشود، نه با دستکاری تصادفی CSS. اول تفاوت دادهٔ میدانی و آزمایشگاهی را بفهمید، سپس پرش را در Live Metrics بازسازی و در ردگیری Performance علت بالادست را پیدا کنید. رزرو فضا برای رسانه، جاینگهدار درست برای محتوای پویا و بررسی فونت معمولاً نخستین اصلاحهای قابلآزمایشاند. هدف نهایی این است که متن و دکمه هنگام خواندن زیر دست کاربر حرکت نکنند؛ نمرهٔ بهتر نتیجهٔ سنجش همین تجربه است، نه وعدهٔ رتبهٔ بالاتر.
پرسشهای پرتکرار
CLS خوب چند است؟
راهنمای گوگل مقدار ۰٫۱ یا کمتر را در دستکم ۷۵ درصد بازدیدها هدف تجربهٔ خوب میداند. یک نتیجهٔ محلی خوب، اثبات نمیکند همهٔ کاربران همین عدد را میبینند.
چرا CLS در Lighthouse صفر ولی در PageSpeed Insights بالاست؟
ممکن است پرش پس از بارگذاری، هنگام اسکرول یا نمایش محتوای تأخیری رخ دهد؛ اجرای معمول Lighthouse آن را نبیند. ابتدا مطمئن شوید دادهٔ میدانی مربوط به همان URL است یا کل مبدأ، سپس آن رفتار را در Live Metrics بازسازی کنید.
آیا تصویر WebP هم باعث پرش میشود؟
بله. کمحجم بودن فایل با رزرو فضا تفاوت دارد؛ اگر مرورگر پیش از بارگذاری نسبت ابعاد تصویر را نداند، تصویر WebP هم میتواند چیدمان را جابهجا کند.
کدام عنصر را اصلاح کنم؛ عنصری که حرکت کرده یا عنصر بالای آن؟
اغلب باید علت بالادست را پیدا کنید. پاراگراف جابهجا شده ممکن است فقط قربانی تصویر یا بنری باشد که دیرتر فضای صفحه را گرفته است.
آیا رفع CLS رتبهٔ گوگل را تضمین میکند؟
خیر. گوگل معیارهای تجربهٔ صفحه را لحاظ میکند، اما خودش تصریح میکند نمرهٔ خوب Core Web Vitals تضمین رتبهٔ برتر نیست؛ کیفیت و تناسب محتوا همچنان اهمیت دارد.
بدون دسترسی به کد سایت هم میتوانم عیب را پیدا کنم؟
بله، DevTools و PageSpeed Insights برای تشخیص در دسترساند. برای اصلاح پایدار معمولاً باید کد، قالب یا تنظیمات رسانه و بنر را تغییر دهید و بعد دوباره بسنجید.
منابع
Optimize Cumulative Layout Shift — web.dev، نوشتهٔ Addy Osmani و Barry Pollard، بهروزرسانی ۷ فوریهٔ ۲۰۲۵.
Performance features reference — Chrome for Developers، بهروزرسانی ۳ آوریل ۲۰۲۵.
Discover issues with rendering performance — Chrome for Developers.
Understanding Google Page Experience — Google Search Central.
تصویر جلد: اسکرینشات واقعی پنل Performance و Layout shifts از راهنمای web.dev، منتشرشده توسط Google، مجوز CC BY 4.0 طبق اعلام انتهای همان صفحه؛ برای جلد برش و تغییر اندازه شده است. عدد ۰٫۳۳ در تصویر فقط مثال همان صفحه است.
برای تازهترین بهروزرسانی امنیتی مرورگر کروم: کروم ۱۵۴ و ۱۰۸ وصله امنیتی گوگل.
