بیاموزید که چگونه از تغییرات ناگهانی طرحبندی برای بهبود تجربه کاربری جلوگیری کنید
منتشر شده: ۵ مه ۲۰۲۰، آخرین بهروزرسانی: ۷ فوریه ۲۰۲۵
تغییر چیدمان تجمعی (CLS) یکی از سه معیار Core Web Vitals است. این معیار، ناپایداری محتوا را با ترکیب میزان تغییر محتوای قابل مشاهده در نمای دید با فاصلهای که عناصر تحت تأثیر جابجا شدهاند، اندازهگیری میکند.
تغییر چیدمان میتواند برای کاربران حواسپرتی ایجاد کند. تصور کنید که شروع به خواندن مقالهای کردهاید که ناگهان همه عناصر در صفحه تغییر میکنند، شما را گیج میکنند و شما را مجبور میکنند دوباره جای خود را پیدا کنید. این اتفاق در وب بسیار رایج است، از جمله هنگام خواندن اخبار یا تلاش برای کلیک بر روی دکمههای «جستجو» یا «افزودن به سبد خرید». چنین تجربیاتی از نظر بصری ناخوشایند و ناامیدکننده هستند. آنها اغلب زمانی ایجاد میشوند که عناصر قابل مشاهده مجبور به حرکت میشوند زیرا عنصر دیگری به طور ناگهانی به صفحه اضافه شده یا تغییر اندازه داده شده است.
برای ارائه یک تجربه کاربری خوب، سایتها باید تلاش کنند تا حداقل در ۷۵٪ از بازدیدهای صفحه، CLS برابر با ۰.۱ یا کمتر داشته باشند.
برخلاف سایر Core Web Vitals که مقادیر مبتنی بر زمان هستند و بر حسب ثانیه یا میلیثانیه اندازهگیری میشوند، امتیاز CLS یک مقدار بدون واحد است که بر اساس محاسبه میزان و فاصله تغییر محتوا محاسبه میشود.
در این راهنما، به بررسی علل رایج بهینهسازی تغییرات طرحبندی خواهیم پرداخت.
شایعترین علل CLS ضعیف عبارتند از:
- تصاویر بدون ابعاد.
- تبلیغات، جاسازیها و آیفریمهای بدون ابعاد.
- محتوای تزریقشدهی پویا مانند تبلیغات، جاسازیها و آیفریمها بدون ابعاد.
- فونتهای وب.
دلایل تغییر چیدمان را درک کنید
قبل از اینکه به دنبال راهحلهایی برای مشکلات رایج CLS باشید، مهم است که نمره CLS خود و منشأ تغییرات را درک کنید.
CLS در ابزارهای آزمایشگاهی در مقابل میدانی
معمولاً از توسعهدهندگان میشنویم که فکر میکنند CLS اندازهگیری شده توسط گزارش UX کروم (CrUX) نادرست است، زیرا با CLS اندازهگیری شده توسط آنها با استفاده از Chrome DevTools یا سایر ابزارهای آزمایشگاهی مطابقت ندارد. ابزارهای آزمایشگاهی عملکرد وب مانند Lighthouse ممکن است CLS کامل یک صفحه را نشان ندهند، زیرا آنها معمولاً بارگذاری اولیه صفحه را برای اندازهگیری برخی از معیارهای عملکرد وب و ارائه برخی راهنماییها انجام میدهند (اگرچه جریانهای کاربری Lighthouse به شما امکان میدهند فراتر از ممیزی بارگذاری صفحه پیشفرض را اندازهگیری کنید).
CrUX مجموعه دادههای گوگل از برنامه Web Vitals است و به همین دلیل، CLS در طول کل عمر صفحه اندازهگیری میشود و نه فقط در طول بارگذاری اولیه صفحه که معمولاً ابزارهای آزمایشگاهی اندازهگیری میکنند.
تغییرات طرحبندی در طول بارگذاری صفحه بسیار رایج هستند، زیرا تمام منابع لازم برای رندر اولیه صفحه دریافت میشوند، اما تغییرات طرحبندی میتوانند پس از بارگذاری اولیه نیز رخ دهند. بسیاری از تغییرات پس از بارگذاری ممکن است در نتیجه تعامل کاربر رخ دهند و بنابراین از امتیاز CLS حذف میشوند زیرا تغییرات مورد انتظار هستند - البته تا زمانی که در عرض ۵۰۰ میلیثانیه از آن تعامل رخ دهند.
با این حال، سایر تغییرات پس از بارگذاری که برای کاربر غیرمنتظره هستند، ممکن است در جایی که هیچ تعامل واجد شرایطی وجود نداشته باشد، لحاظ شوند - برای مثال، اگر در طول صفحه بیشتر اسکرول کنید و محتوای بارگذاری شده با تأخیر بارگذاری شود و این باعث تغییرات شود. سایر علل رایج CLS پس از بارگذاری، مربوط به تعاملات انتقالها است، به عنوان مثال در برنامههای تک صفحهای که بیش از دوره مجاز ۵۰۰ میلیثانیه طول میکشند.
PageSpeed Insights هم CLS درک شده توسط کاربر از یک URL را در بخش "کشف آنچه کاربران واقعی شما تجربه میکنند" و هم CLS بارگذاری مبتنی بر آزمایشگاه را در بخش "تشخیص مشکلات عملکرد" نشان میدهد. تفاوت بین این مقادیر احتمالاً نتیجه CLS پس از بارگذاری است.

شناسایی مشکلات بارگذاری CLS
وقتی نمرات CrUX و Lighthouse CLS از PageSpeed Insights به طور کلی همسو باشند، معمولاً نشان میدهد که یک مشکل CLS بار وجود دارد که توسط Lighthouse شناسایی شده است. در این حالت، Lighthouse با دو ممیزی به ارائه اطلاعات بیشتر در مورد تصاویری که به دلیل عرض و ارتفاع کم باعث CLS میشوند، کمک میکند و همچنین تمام عناصری را که برای بارگذاری صفحه تغییر کردهاند به همراه سهم CLS آنها فهرست میکند. میتوانید این ممیزیها را با فیلتر کردن ممیزیهای CLS مشاهده کنید:

پنل Performance در DevTools اطلاعات زیادی در مورد تغییرات طرحبندی ارائه میدهد:

Layout Shift نمایش میدهند. کلیک بر روی لوزیها، انیمیشنی از تغییر و جزئیات را در پنل Summary نشان میدهد.شیفتهای طرحبندی در مسیر شیفتهای طرحبندی برجسته شدهاند. خط بنفش شیفتها را در خوشههای شیفت گروهبندی میکند که الماسها شیفتهای جداگانه را در آن خوشه نشان میدهند. اندازه الماس متناسب با اندازه شیفت است و به شما این امکان را میدهد که روی بزرگترین شیفتها تمرکز کنید.
با کلیک بر روی یک شیفت، یک پنجره پاپآپ با انیمیشنی از شیفت نمایش داده میشود و عناصر در حال تغییر را با رنگ بنفش هایلایت میکند.
علاوه بر این، نمای خلاصه برای یک رکورد Layout Shift شامل زمان شروع، امتیاز تغییر و همچنین عناصر تغییر یافته است. این امر به ویژه برای دریافت جزئیات بیشتر در مورد مشکلات بارگذاری CLS مفید است زیرا این امر به راحتی با یک پروفایل عملکرد بارگذاری مجدد قابل تکرار است.
این همچنین به بینش مقصران تغییر طرحبندی که در پنل Insights در سمت چپ نمایش داده میشود، پیوند دارد که کل CLS را در بالا و همچنین دلایل احتمالی تغییر طرحبندی نشان میدهد.
مشکلات CLS پس از بارگذاری را شناسایی کنید
اختلاف بین نمرات CrUX و Lighthouse CLS اغلب نشاندهنده CLS پس از بارگذاری است. ردیابی این تغییرات بدون دادههای میدانی میتواند دشوار باشد. برای اطلاعات در مورد جمعآوری دادههای میدانی، به بخش اندازهگیری عناصر CLS در میدان مراجعه کنید.
نمای زندهی معیارهای پنل عملکرد به شما امکان میدهد با صفحه تعامل داشته باشید و امتیاز CLS را رصد کنید تا تعاملاتی را که باعث تغییرات بزرگ در طرحبندی میشوند، شناسایی کنید.

به عنوان جایگزینی برای استفاده از DevTools، میتوانید صفحه وب خود را مرور کنید و همزمان تغییرات طرحبندی را با استفاده از یک Performance Observer که در کنسول پیست شده است، ضبط کنید .
پس از تنظیم نظارت بر شیفت، میتوانید سعی کنید هرگونه مشکل CLS پس از بارگذاری را تکرار کنید. CLS اغلب زمانی اتفاق میافتد که کاربر در صفحه اسکرول میکند، زمانی که محتوای بارگذاریشده با تنبلی بهطور کامل و بدون فضای اختصاصیافته برای آن بارگذاری میشود. تغییر محتوا زمانی که کاربر اشارهگر را روی آن نگه میدارد، یکی دیگر از دلایل رایج CLS پس از بارگذاری است. هرگونه تغییر محتوا در طول هر یک از این تعاملات، حتی اگر در عرض ۵۰۰ میلیثانیه اتفاق بیفتد، غیرمنتظره محسوب میشود.
برای اطلاعات بیشتر، به بخش «تغییرات طرحبندی اشکالزدایی» مراجعه کنید.
پس از اینکه علل رایج CLS را شناسایی کردید، میتوانید از حالت جریان کاربر در Lighthouse با نام timepans نیز استفاده کنید تا با معرفی تغییرات طرحبندی، از پسرفت جریانهای کاربری معمول اطمینان حاصل شود.
اندازهگیری عناصر CLS در محل
نظارت بر CLS در محل میتواند در تعیین شرایطی که CLS در آن اتفاق میافتد و محدود کردن علل احتمالی، بسیار ارزشمند باشد. مانند اکثر ابزارهای آزمایشگاهی، ابزارهای میدانی فقط عناصری را که تغییر مکان دادهاند اندازهگیری میکنند، اما معمولاً اطلاعات کافی برای شناسایی علت ارائه میدهند. همچنین میتوانید از اندازهگیریهای میدانی CLS برای تعیین اینکه کدام مشکلات بالاترین اولویت را برای رفع دارند، استفاده کنید.
کتابخانهی web-vitals دارای توابع انتساب است که به شما امکان میدهد این اطلاعات اضافی را جمعآوری کنید. برای اطلاعات بیشتر، به بخش اشکالزدایی عملکرد در این زمینه مراجعه کنید. سایر ارائهدهندگان RUM نیز شروع به جمعآوری و ارائهی مشابه این دادهها کردهاند.
علل شایع CLS
پس از شناسایی علل CLS، میتوانید شروع به رفع مشکلات کنید. در این بخش، برخی از دلایل رایج CLS و آنچه میتوانید برای جلوگیری از آنها انجام دهید را نشان خواهیم داد.
تصاویر بدون ابعاد
همیشه ویژگیهای اندازه width و height را در تصاویر و عناصر ویدیویی خود لحاظ کنید. روش دیگر، رزرو فضای مورد نیاز با aspect-ratio CSS یا موارد مشابه است. این رویکرد تضمین میکند که مرورگر میتواند در حین بارگذاری تصویر، مقدار صحیح فضا را در سند اختصاص دهد.

تاریخچه ویژگیهای width و height در تصاویر
در روزهای اولیه وب، توسعهدهندگان ویژگیهای width و height را به تگهای <img> خود اضافه میکردند تا مطمئن شوند فضای کافی در صفحه قبل از اینکه مرورگر شروع به دریافت تصاویر کند، اختصاص داده شده است. این کار باعث به حداقل رساندن reflow و relayout میشد.
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
width و height در این مثال شامل واحد نمیشوند. این ابعاد «پیکسلی» تضمین میکنند که مرورگر یک ناحیه ۶۴۰x۳۶۰ را در طرحبندی صفحه رزرو میکند. تصویر صرف نظر از اینکه ابعاد واقعی با آن مطابقت داشته باشد یا خیر، کشیده میشود تا در این فضا جا شود.
وقتی طراحی وب واکنشگرا (Responsive Web Design) معرفی شد، توسعهدهندگان شروع به حذف width و height کردند و به جای آن از CSS برای تغییر اندازه تصاویر استفاده کردند:
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
با این حال، از آنجا که اندازه تصویر مشخص نشده است، تا زمانی که مرورگر شروع به دانلود آن نکند و ابعاد آن را تعیین نکند، نمیتوان فضایی برای آن اختصاص داد. با بارگذاری تصاویر، متن به پایین صفحه منتقل میشود تا برای آنها جا باز کند و این باعث ایجاد یک تجربه کاربری گیجکننده و ناامیدکننده میشود.
اینجاست که نسبت ابعاد تصویر مطرح میشود. نسبت ابعاد یک تصویر، نسبت عرض به ارتفاع آن است. معمولاً این نسبت به صورت دو عدد که با علامت دونقطه از هم جدا شدهاند، نمایش داده میشود (مثلاً ۱۶:۹ یا ۴:۳). برای نسبت ابعاد x:y، تصویر x واحد عرض و y واحد ارتفاع دارد.
این یعنی اگر یکی از ابعاد را بدانیم، دیگری را میتوانیم تعیین کنیم. برای نسبت تصویر ۱۶:۹:
- اگر puppy.jpg ارتفاعی برابر با ۳۶۰ پیکسل داشته باشد، عرض آن برابر با ۳۶۰ در (۱۶ / ۹) = ۶۴۰ پیکسل خواهد بود.
- اگر puppy.jpg دارای عرض ۶۴۰ پیکسل باشد، ارتفاع آن ۶۴۰ × (۹ / ۱۶) = ۳۶۰ پیکسل است.
دانستن نسبت ابعاد یک تصویر به مرورگر اجازه میدهد تا فضای کافی برای ارتفاع و مساحت مربوطه را محاسبه و رزرو کند.
بهترین روشهای مدرن برای تنظیم ابعاد تصویر
از آنجا که مرورگرهای مدرن نسبت ابعاد پیشفرض تصاویر را بر اساس ویژگیهای width و height تصویر تنظیم میکنند، میتوانید با تنظیم این ویژگیها روی تصویر و گنجاندن CSS قبلی در شیوهنامه خود، از تغییر طرحبندی جلوگیری کنید.
<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
سپس همه مرورگرها بر اساس ویژگیهای width و height موجود عنصر ، نسبت ابعاد پیشفرض را اضافه میکنند.
این تابع، نسبت ابعاد را بر اساس ویژگیهای width و height ، قبل از بارگذاری تصویر محاسبه میکند. این اطلاعات را در همان ابتدای محاسبه طرحبندی ارائه میدهد. به محض اینکه به یک تصویر گفته شود که عرض مشخصی داشته باشد (برای مثال width: 100% )، از نسبت ابعاد برای محاسبه ارتفاع استفاده میشود.
این مقدار aspect-ratio توسط مرورگرهای اصلی هنگام پردازش HTML محاسبه میشود، نه با یک برگه سبک پیشفرض عامل کاربر ( برای بررسی عمیقتر دلیل آن به این پست مراجعه کنید)، بنابراین مقدار کمی متفاوت نمایش داده میشود. به عنوان مثال، کروم آن را به این شکل در بخش Styles از پنل Element نمایش میدهد:
img[Attributes Style] {
aspect-ratio: auto 640 / 360;
}
سافاری نیز به طور مشابه رفتار میکند و از منبع سبک HTML Attributes استفاده میکند. فایرفاکس این aspect-ratio محاسبه شده را به هیچ وجه در پنل Inspector خود نمایش نمیدهد، اما از آن برای طرحبندی استفاده میکند.
بخش auto کد قبلی مهم است، زیرا باعث میشود ابعاد تصویر پس از دانلود تصویر، نسبت ابعاد پیشفرض را نادیده بگیرد. اگر ابعاد تصویر متفاوت باشد، این امر همچنان باعث تغییر طرحبندی پس از بارگذاری تصویر میشود، اما این تضمین میکند که نسبت ابعاد تصویر، در صورت نادرست بودن HTML، همچنان هنگام در دسترس قرار گرفتن، استفاده میشود. حتی اگر نسبت ابعاد واقعی با پیشفرض متفاوت باشد، باز هم باعث تغییر طرحبندی کمتری نسبت به اندازه پیشفرض 0x0 یک تصویر بدون ابعاد ارائه شده میشود.
برای بررسی عمیق و فوقالعاده نسبت ابعاد و تفکر بیشتر در مورد تصاویر واکنشگرا، به بارگذاری بدون دردسر صفحه با نسبت ابعاد رسانه مراجعه کنید.
اگر تصویر شما در یک ظرف قرار دارد، میتوانید از CSS برای تغییر اندازه تصویر به اندازه عرض ظرف استفاده کنید. ما height: auto; را برای جلوگیری از استفاده از مقدار ثابت برای ارتفاع تصویر تنظیم میکنیم.
img {
height: auto;
width: 100%;
}
در مورد تصاویر واکنشگرا چطور؟
هنگام کار با تصاویر واکنشگرا ، srcset تصاویری را که به مرورگر اجازه میدهید بین آنها انتخاب کند و اندازه هر تصویر را تعریف میکند. برای اطمینان از اینکه ویژگیهای عرض و ارتفاع <img> قابل تنظیم هستند، هر تصویر باید از نسبت ابعاد یکسانی استفاده کند.
<img
width="1000"
height="1000"
src="puppy-1000.jpg"
srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
alt="Puppy with balloons"
/>
نسبت ابعاد تصاویر شما نیز میتواند بسته به جهت هنری شما تغییر کند. برای مثال، ممکن است بخواهید یک عکس برش خورده از یک تصویر را برای نماهای باریک درج کنید و تصویر کامل را در دسکتاپ نمایش دهید:
<picture>
<source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
<source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
<img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>
کروم، فایرفاکس و سافاری اکنون از تنظیم width و height روی عناصر <source> درون یک عنصر <picture> پشتیبانی میکنند:
<picture>
<source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
<source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
<img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>
تبلیغات، جاسازیها و سایر محتوای دیر بارگذاری شده
تصاویر تنها نوع محتوایی نیستند که میتوانند باعث تغییر طرحبندی شوند. تبلیغات، جاسازیها، iframeها و سایر محتوای تزریقشدهی پویا، همگی میتوانند باعث شوند محتوایی که پس از آنها ظاهر میشود، به سمت پایین تغییر مکان دهد و CLS شما را افزایش دهد.
تبلیغات یکی از بزرگترین عوامل تغییر طرحبندی در وب هستند. شبکههای تبلیغاتی و ناشران اغلب از اندازههای پویای تبلیغات پشتیبانی میکنند. اندازههای تبلیغات به دلیل نرخ کلیک بالاتر و تبلیغات بیشتر در مزایده، عملکرد و درآمد را افزایش میدهند. متأسفانه، این امر میتواند به دلیل اینکه تبلیغات، محتوای قابل مشاهدهای را که در حال مشاهده آن هستید، به پایین صفحه هل میدهند، منجر به یک تجربه کاربری نامطلوب شود.
ویجتهای قابل جاسازی به شما این امکان را میدهند که محتوای وب قابل حمل، مانند ویدیوها از یوتیوب، نقشههای گوگل مپ و پستهای رسانههای اجتماعی را در صفحه خود قرار دهید. با این حال، این ویجتها اغلب قبل از بارگذاری از حجم محتوای خود آگاه نیستند. در نتیجه، پلتفرمهایی که قابلیت جاسازی دارند، همیشه فضایی را برای ویجتهای خود رزرو نمیکنند، که باعث میشود هنگام بارگذاری نهایی، طرحبندی تغییر کند.
تکنیکهای برخورد با این موارد همگی مشابه هستند. تفاوتهای اصلی در میزان کنترل شما بر محتوایی است که قرار است درج شود. اگر این محتوا توسط شخص ثالثی مانند یک شریک تبلیغاتی درج شود، ممکن است اندازه دقیق محتوایی که قرار است درج شود را ندانید و همچنین قادر به کنترل تغییرات طرحبندی در آن جاسازیها نباشید.
برای محتوایی که دیر بارگذاری میشوند، فضا رزرو کنید
هنگام قرار دادن محتوای دیرهنگام در جریان محتوا، میتوان با رزرو فضا برای تغییرات طرحبندی در طرحبندی اولیه، از آنها جلوگیری کرد.
یک رویکرد این است که یک قانون CSS min-height برای رزرو فضا اضافه کنید یا - برای محتوای واکنشگرا مانند تبلیغات، به عنوان مثال - از ویژگی CSS aspect-ratio به روشی مشابه روشی که مرورگرها به طور خودکار از این برای تصاویر با ابعاد ارائه شده استفاده میکنند، استفاده کنید.
ممکن است لازم باشد با استفاده از کوئریهای رسانهای، تفاوتهای ظریف در اندازههای تبلیغ یا جانگهدار را در فرمفاکتورها در نظر بگیرید.
برای محتوایی که ممکن است ارتفاع ثابتی نداشته باشد، مانند تبلیغات، ممکن است نتوانید مقدار دقیق فضای مورد نیاز برای حذف کامل تغییر طرحبندی را رزرو کنید. اگر یک تبلیغ کوچکتر ارائه شود، ناشر میتواند برای جلوگیری از تغییر طرحبندی، یک ظرف بزرگتر طراحی کند، یا بر اساس دادههای تاریخی، محتملترین اندازه را برای جایگاه تبلیغ انتخاب کند. نکته منفی این رویکرد این است که میزان فضای خالی در صفحه را افزایش میدهد.
در عوض میتوانید اندازه اولیه را روی کوچکترین اندازهای که استفاده خواهد شد تنظیم کنید و برای محتوای بزرگتر، مقداری تغییر مکان را بپذیرید. استفاده از min-height ، همانطور که قبلاً پیشنهاد شد، به عنصر والد اجازه میدهد تا در صورت لزوم بزرگ شود و در عین حال تأثیر تغییر مکان طرح را کاهش میدهد، در مقایسه با اندازه پیشفرض 0px برای یک عنصر خالی.
سعی کنید با نمایش یک placeholder از بهم ریختن فضای رزرو شده جلوگیری کنید، مثلاً اگر هیچ تبلیغی نمایش داده نشد. حذف فضای اختصاص داده شده برای عناصر میتواند به اندازه درج محتوا باعث CLS شود.
محتوای دیر بارگذاری شده را در قسمت پایینتری از پنجره نمایش قرار دهید
محتوای تزریقشدهی پویا که به بالای صفحهی نمایش نزدیکتر است، معمولاً باعث تغییر طرحبندی بیشتری نسبت به محتوای تزریقشده در پایین صفحهی نمایش میشود. با این حال، تزریق محتوا در هر کجای صفحهی نمایش همچنان باعث تغییر میشود. اگر نمیتوانید برای محتوای تزریقشده فضا رزرو کنید، توصیه میکنیم آن را در قسمت پایینتری از صفحه قرار دهید تا تأثیر آن بر CLS کاهش یابد.
از درج محتوای جدید بدون تعامل با کاربر خودداری کنید
احتمالاً هنگام بارگذاری یک سایت، به دلیل ظاهر شدن ناگهانی رابط کاربری در بالا یا پایین صفحه نمایش، شاهد تغییر طرحبندی بودهاید. مشابه تبلیغات، این اتفاق اغلب برای بنرها و فرمهایی میافتد که بقیه محتوای صفحه را تغییر میدهند:
اگر نیاز به نمایش این نوع از رابطهای کاربری دارید، از قبل فضای کافی در پنجره نمایش را برای آن در نظر بگیرید (مثلاً با استفاده از یک نگهدارنده یا اسکلت رابط کاربری) تا هنگام بارگذاری، باعث نشود محتوای صفحه به طور شگفتآوری تغییر کند. از طرف دیگر، میتوانید با قرار دادن محتوا روی آن در جایی که منطقی است، مطمئن شوید که عنصر بخشی از جریان سند نیست. برای توصیههای بیشتر در مورد این نوع اجزا، به پست « بهترین شیوهها برای اعلانهای کوکی» مراجعه کنید.
در برخی موارد، اضافه کردن محتوا به صورت پویا بخش مهمی از تجربه کاربری است. به عنوان مثال، هنگام بارگذاری محصولات بیشتر به لیستی از اقلام یا هنگام بهروزرسانی محتوای فید زنده. در این موارد، چندین راه برای جلوگیری از تغییرات غیرمنتظره طرحبندی وجود دارد:
- محتوای قدیمی را با محتوای جدید در یک کانتینر با اندازه ثابت جایگزین کنید یا از یک چرخ فلک استفاده کنید و محتوای قدیمی را پس از انتقال حذف کنید. به یاد داشته باشید که تا زمان اتمام انتقال، هرگونه لینک و کنترل را غیرفعال کنید تا از کلیکها یا لمسهای تصادفی هنگام ورود محتوای جدید جلوگیری شود.
- از کاربر بخواهید بارگذاری محتوای جدید را آغاز کند تا از تغییر غافلگیر نشود (برای مثال با دکمه "بارگذاری بیشتر" یا "بهروزرسانی"). توصیه میشود قبل از تعامل کاربر، محتوا را پیشواکشی کنید تا بلافاصله نمایش داده شود. به عنوان یادآوری، تغییرات طرحبندی که در عرض ۵۰۰ میلیثانیه از ورودی کاربر رخ میدهند، در CLS محاسبه نمیشوند.
- محتوا را به طور یکپارچه در خارج از صفحه بارگذاری کنید و به کاربر اطلاع دهید که محتوا در دسترس است (برای مثال، با دکمه «به بالا بروید»).

انیمیشنها
تغییرات در مقادیر ویژگیهای CSS میتواند مرورگر را ملزم به واکنش به این تغییرات کند. برخی از مقادیر، مانند box-shadow و box-sizing ، باعث تغییر طرحبندی، رنگآمیزی و ترکیب میشوند. تغییر ویژگیهای top و left نیز باعث تغییر طرحبندی میشوند، حتی زمانی که عنصری که جابجا میشود در لایه خودش باشد. از متحرکسازی با استفاده از این ویژگیها خودداری کنید.
سایر ویژگیهای CSS را میتوان بدون ایجاد تغییر در طرحبندی تغییر داد. این موارد شامل استفاده از انیمیشنهای transform برای انتقال، مقیاسبندی، چرخش یا کج کردن عناصر است.
انیمیشنهای ترکیبی که از translate استفاده میکنند نمیتوانند روی عناصر دیگر تأثیر بگذارند و بنابراین در CLS محاسبه نمیشوند. انیمیشنهای غیرترکیبی نیز باعث تغییر طرحبندی نمیشوند. برای کسب اطلاعات بیشتر در مورد اینکه کدام ویژگیهای CSS باعث تغییر طرحبندی میشوند، به انیمیشنهای با کارایی بالا مراجعه کنید.
فونتهای وب
دانلود و رندر فونتهای وب معمولاً قبل از دانلود فونت وب به یکی از دو روش زیر انجام میشود:
- فونت جایگزین با فونت وب عوض میشود و باعث ایجاد خطای Flash of Unstyled Text (FOUT) میشود.
- متن «نامرئی» با استفاده از فونت جایگزین نمایش داده میشود تا زمانی که یک فونت وب در دسترس قرار گیرد و متن قابل مشاهده شود (FOIT - فلش متن نامرئی).
هر دو رویکرد میتوانند باعث تغییر طرحبندی شوند . حتی اگر متن نامرئی باشد، همچنان با استفاده از فونت جایگزین طرحبندی میشود، بنابراین وقتی فونت وب بارگذاری میشود، بلوک متن و محتوای اطراف آن به همان روشی که برای فونت قابل مشاهده تغییر میکند، تغییر میکنند.
ابزارهای زیر میتوانند به شما در به حداقل رساندن تغییر متن کمک کنند:
-
font-display: optionalمیتواند از طرحبندی مجدد جلوگیری کند زیرا فونت وب فقط در صورتی استفاده میشود که در زمان طرحبندی اولیه در دسترس باشد. - مطمئن شوید که از فونت جایگزین مناسب استفاده میشود. برای مثال، استفاده از
font-family: "Google Sans", sans-serif;تضمین میکند که فونت جایگزینsans-serifمرورگر هنگام بارگذاری"Google Sans"استفاده شود. عدم تعیین فونت جایگزین با استفاده ازfont-family: "Google Sans"به این معنی است که از فونت پیشفرض استفاده میشود، که در کروم "Times" است - یک فونت سریف که تطابق بدتری با فونت پیشفرضsans-serifدارد. - اختلاف اندازه بین فونت جایگزین و فونت وب را با استفاده از APIهای جدید
size-adjust،ascent-override،descent-overrideوline-gap-overrideهمانطور که در پست Improved font fallbacks توضیح داده شده است، به حداقل برسانید. - API بارگذاری فونت میتواند زمان لازم برای دریافت فونتهای لازم را کاهش دهد.
- فونتهای وب حیاتی را در اسرع وقت با استفاده از
<link rel=preload>بارگذاری کنید. یک فونت از پیش بارگذاری شده شانس بیشتری برای رسیدن به اولین رنگ خواهد داشت، که در این صورت هیچ تغییری در طرحبندی ایجاد نمیشود.
برای سایر بهترین شیوههای فونت، بهترین شیوهها برای فونتها را بخوانید.
با اطمینان از واجد شرایط بودن صفحات برای bfcache، CLS را کاهش دهید.
یک تکنیک بسیار مؤثر برای پایین نگه داشتن نمرات CLS، اطمینان از واجد شرایط بودن صفحات وب شما برای حافظه پنهان back/forward (bfcache) است.
bfcache صفحات را برای مدت کوتاهی پس از اینکه شما از آنها دور میشوید، در حافظه مرورگر نگه میدارد، بنابراین اگر دوباره به آنها مراجعه کنید، دقیقاً همانطور که آنها را ترک کردهاید، بازیابی میشوند. این بدان معناست که صفحه کاملاً بارگذاری شده فوراً در دسترس است - بدون هیچ تغییری که معمولاً ممکن است در حین بارگذاری به هر یک از دلایلی که قبلاً ذکر شد، مشاهده شود.
اگرچه این به طور بالقوه هنوز به این معنی است که بارگذاری اولیه صفحه با تغییرات طرحبندی مواجه میشود، اما وقتی کاربر به صفحات قبلی برمیگردد، تغییرات طرحبندی یکسانی را به طور مکرر نمیبیند. شما همیشه باید سعی کنید حتی در بارگذاری اولیه از تغییرات جلوگیری کنید، اما در جایی که حل کامل این مشکل دشوارتر است، حداقل میتوانید با اجتناب از آنها در هرگونه ناوبری bfcache، تأثیر آن را کاهش دهید.
پیمایشهای رو به عقب و جلو در بسیاری از سایتها رایج هستند. برای مثال، بازگشت به صفحه محتوا، یا صفحه دستهبندی، یا نتایج جستجو.
وقتی این قابلیت برای کروم منتشر شد ، شاهد بهبودهای قابل توجهی در CLS بودیم.
bfcache به طور پیشفرض توسط همه مرورگرها استفاده میشود، اما برخی سایتها به دلایل مختلف واجد شرایط bfcache نیستند. برای جزئیات بیشتر در مورد نحوه آزمایش و شناسایی هرگونه مشکلی که مانع استفاده از bfcache میشود ، راهنمای bfcache را مطالعه کنید تا مطمئن شوید که از این ویژگی به طور کامل استفاده میکنید تا به امتیاز کلی CLS سایت خود کمک کنید.
نتیجهگیری
همانطور که قبلاً در این راهنما توضیح داده شده است، تعدادی تکنیک برای شناسایی و بهبود CLS وجود دارد. در Core Web Vitals محدودیتهایی وجود دارد، بنابراین حتی اگر نمیتوانید CLS را به طور کامل حذف کنید، استفاده از برخی از این تکنیکها باید به شما امکان دهد تا تأثیر آن را کاهش دهید. امیدواریم این به شما امکان دهد تا در این محدوده بمانید و تجربه بهتری را برای کاربران وبسایت خود ایجاد کنید.