بیاموزید که چگونه از تغییرات ناگهانی چیدمان برای بهبود تجربه کاربر جلوگیری کنید
تاریخ انتشار: 5 می 2020، آخرین به روز رسانی: 7 فوریه 2025
تغییر چیدمان تجمعی (CLS) یکی از سه معیار اصلی Web Vitals است. بیثباتی محتوا را با ترکیب میزان جابهجایی محتوای قابل مشاهده در نما با فاصلهای که عناصر تحت تأثیر قرار گرفتهاند، اندازهگیری میکند.
تغییر چیدمان می تواند حواس کاربران را پرت کند. تصور کنید زمانی که به طور ناگهانی عناصر در سراسر صفحه جابه جا می شوند، شروع به خواندن مقاله ای کرده اید و شما را پرت می کنند و از شما می خواهند که دوباره مکان خود را پیدا کنید. این امر در وب بسیار رایج است، از جمله هنگام خواندن اخبار، یا تلاش برای کلیک بر روی دکمههای «جستجو» یا «افزودن به سبد خرید». چنین تجربیاتی از نظر بصری خسته کننده و خسته کننده هستند. آنها اغلب زمانی ایجاد می شوند که عناصر قابل مشاهده مجبور به جابجایی شوند زیرا عنصر دیگری به طور ناگهانی به صفحه اضافه شده یا اندازه آن تغییر کرده است.
برای ارائه یک تجربه کاربری خوب، سایت ها باید تلاش کنند تا حداقل 75 درصد از بازدیدهای صفحه، CLS 0.1 یا کمتر داشته باشند.
برخلاف سایر Core Web Vitals که مقادیر مبتنی بر زمان هستند که در ثانیه یا میلی ثانیه اندازهگیری میشوند، امتیاز CLS یک مقدار بدون واحد است که بر اساس محاسبه میزان جابهجایی محتوا و میزان فاصله است.
در این راهنما، بهینه سازی علل رایج تغییر چیدمان را پوشش خواهیم داد.
شایع ترین علل CLS ضعیف عبارتند از:
- تصاویر بدون ابعاد
- تبلیغات، جاسازیها و آیفریمهای بدون ابعاد.
- محتوای تزریقی پویا مانند تبلیغات، جاسازیها و آیفریمهای بدون ابعاد.
- فونت های وب
دلایل تغییر چیدمان را درک کنید
قبل از شروع به دنبال راه حل برای مسائل رایج CLS، مهم است که امتیاز CLS خود را درک کنید و این تغییرات از کجا می آیند.
CLS در ابزار آزمایشگاهی در مقابل میدان
شنیدن اینکه برنامهنویسان فکر میکنند CLS اندازهگیری شده توسط گزارش Chrome UX (CrUX) نادرست است، بسیار رایج است، زیرا با CLS که با استفاده از ابزار توسعه کروم یا سایر ابزارهای آزمایشگاهی اندازهگیری میکنند مطابقت ندارد. ابزارهای آزمایشگاه عملکرد وب مانند Lighthouse ممکن است CLS کامل یک صفحه را نشان ندهند، زیرا معمولاً بارگذاری اولیه صفحه را برای اندازهگیری برخی معیارهای عملکرد وب و ارائه برخی راهنماییها انجام میدهند (اگرچه جریانهای کاربر Lighthouse به شما امکان میدهد فراتر از ممیزی بار پیشفرض صفحه اندازهگیری کنید).
CrUX مجموعه داده رسمی برنامه Web Vitals است و برای آن، CLS در تمام طول عمر صفحه اندازه گیری می شود و نه فقط در زمان بارگذاری اولیه صفحه که ابزارهای آزمایشگاهی معمولاً اندازه گیری می کنند.
تغییر چیدمان در حین بارگذاری صفحه بسیار رایج است، زیرا تمام منابع لازم برای رندر اولیه صفحه واکشی میشوند، اما تغییر طرحبندی نیز میتواند پس از بارگذاری اولیه اتفاق بیفتد. بسیاری از جابجاییهای پس از بارگذاری ممکن است در نتیجه تعامل کاربر رخ دهند و بنابراین از امتیاز CLS حذف میشوند، زیرا تغییرات مورد انتظار آنها وجود دارد - تا زمانی که در عرض 500 میلیثانیه از آن تعامل رخ دهند.
با این حال، سایر تغییرات پس از بارگیری که توسط کاربر غیرمنتظره هستند، ممکن است در مواردی که هیچ تعامل واجد شرایطی وجود نداشته باشد، لحاظ شوند - به عنوان مثال، اگر بیشتر در صفحه پیمایش کنید و محتوای بارگذاری شده با تنبلی بارگیری شود و این باعث جابجایی شود. سایر علل متداول CLS پس از بارگذاری، در تعاملات انتقال است، به عنوان مثال در برنامه های یک صفحه، که بیش از مهلت 500 میلی ثانیه طول می کشد.
PageSpeed Insights هم CLS درک شده توسط کاربر را از یک URL در بخش "کشف آنچه کاربران واقعی شما تجربه می کنند" و هم CLS بارگیری مبتنی بر آزمایشگاه را در بخش "تشخیص مشکلات عملکرد" نشان می دهد. تفاوت بین این مقادیر احتمالاً نتیجه CLS پس از بارگذاری است.
![PageSpeed Insights دادههای سطح URL را نشان میدهد که CLS کاربر واقعی را برجسته میکند که به طور قابلتوجهی بزرگتر از Lighthouse CLS است.](https://web.developers.google.cn/static/articles/optimize-cls/image/screenshot-pagespeed-ins-1b9715cccc402.png?hl=fa)
مشکلات بار CLS را شناسایی کنید
هنگامی که امتیازات CrUX و Lighthouse CLS از PageSpeed Insights به طور گسترده تراز هستند، این معمولاً نشان می دهد که یک مشکل بار CLS وجود دارد که توسط Lighthouse شناسایی شده است. در این مورد Lighthouse با دو ممیزی کمک می کند تا اطلاعات بیشتری در مورد تصاویری که به دلیل عرض و ارتفاع از دست رفته باعث ایجاد CLS می شوند ارائه دهد و همچنین تمام عناصری را که برای بارگذاری صفحه جابه جا شده اند همراه با سهم CLS آنها فهرست می کند. با فیلتر کردن ممیزی های CLS می توانید این ممیزی ها را مشاهده کنید:
![اسکرین شات Lighthouse که ممیزی های CLS را نشان می دهد که اطلاعات بیشتری را برای کمک به شناسایی و رسیدگی به مشکلات CLS ارائه می دهد](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-screenshot-sho-1c6eeefdc4b1b.png?hl=fa)
پانل عملکرد در DevTools اطلاعات زیادی در مورد تغییرات طرح ارائه می دهد:
![سوابق Layout Shift در پانل عملکرد Chrome DevTools نمایش داده می شود.](https://web.developers.google.cn/static/articles/optimize-cls/image/devtools-cls-debugging.png?hl=fa)
Layout Shift
نشان می دهد. با کلیک بر روی الماس ها، انیمیشنی از تغییر و جزئیات در پانل خلاصه نمایش داده می شود.تغییرات چیدمان در مسیر تغییر چیدمان هایلایت می شوند. خط بنفش به گروههای شیفتی تبدیل میشود که الماسها تغییرات فردی را در آن خوشه نشان میدهند. اندازه الماس متناسب با اندازه شیفت است که به شما امکان می دهد تا در بزرگترین جابجایی ها دقت کنید.
با کلیک بر روی یک شیفت، یک پاپ آپ با انیمیشنی از تغییر نمایش داده می شود و تغییر عناصر به رنگ بنفش برجسته می شود.
علاوه بر این، نمای خلاصه برای رکورد Layout Shift
شامل زمان شروع، امتیاز تغییر و همچنین عناصر جابجا شده است. این به ویژه برای دریافت جزئیات بیشتر در مورد مسائل بارگذاری CLS مفید است زیرا به راحتی با نمایه عملکرد بارگذاری مجدد تکرار می شود.
این همچنین به بینش عاملان تغییر چیدمان که در پانل Insights در سمت چپ نمایش داده شده است، پیوند میخورد، که کل CLS را در بالا و همچنین دلایل احتمالی تغییر طرحبندی را نشان میدهد.
مشکلات CLS پس از بارگذاری را شناسایی کنید
اختلاف بین نمرات CrUX و Lighthouse CLS اغلب نشان دهنده CLS پس از بارگذاری است. ردیابی این تغییرات بدون داده های میدانی می تواند دشوار باشد. برای اطلاعات در مورد جمع آوری داده های فیلد، به اندازه گیری عناصر CLS در فیلد مراجعه کنید.
نمای سنجههای زنده پانل عملکرد به شما امکان میدهد با صفحه تعامل داشته باشید و امتیاز CLS را کنترل کنید تا تعاملاتی را که باعث تغییر در طرحبندی بزرگ میشوند شناسایی کنید.
![سوابق Layout Shift در صفحه معیارهای زنده پانل عملکرد Chrome DevTools نمایش داده می شود.](https://web.developers.google.cn/static/articles/optimize-cls/image/live-metrics-cls.png?hl=fa)
به عنوان جایگزینی برای استفاده از DevTools، میتوانید صفحه وب خود را در حین ضبط تغییرات طرحبندی با استفاده از یک مشاهدهکننده عملکرد که در کنسول جایگذاری شده است، مرور کنید.
پس از راهاندازی نظارت شیفت، میتوانید سعی کنید مشکلات CLS پس از بارگذاری را تکرار کنید. CLS اغلب زمانی اتفاق میافتد که کاربر در یک صفحه پیمایش میکند، زمانی که محتوای بارگذاریشده با تنبلی بهطور کامل بدون فضایی که برای آن در نظر گرفته شده بارگیری میشود. جابجایی محتوا زمانی که کاربر نشانگر را روی آن نگه می دارد یکی دیگر از دلایل رایج CLS پس از بارگذاری است. هرگونه تغییر محتوا در طول هر یک از این تعاملات غیرمنتظره محسوب می شود، حتی اگر در عرض 500 میلی ثانیه اتفاق بیفتد.
برای اطلاعات بیشتر، Debug layout shifts را ببینید.
پس از اینکه علل رایج CLS را شناسایی کردید، حالت جریان کاربر در بازه زمانی Lighthouse نیز میتواند برای اطمینان از عدم پسرفت جریانهای کاربر معمولی با معرفی تغییرات طرح استفاده شود.
عناصر CLS را در میدان اندازه گیری کنید
نظارت بر CLS در این زمینه میتواند در تعیین شرایطی که CLS در چه شرایطی اتفاق میافتد و محدود کردن علل احتمالی آن بسیار ارزشمند باشد. مانند بسیاری از ابزارهای آزمایشگاهی، ابزارهای میدانی فقط عناصری را که جابجا شده اند اندازه گیری می کنند، اما معمولاً اطلاعات کافی برای شناسایی علت ارائه می دهند. همچنین میتوانید از اندازهگیریهای میدانی CLS برای تعیین اینکه کدام مشکلات بالاترین اولویت را برای رفع کردن دارند، استفاده کنید.
کتابخانه web-vitals
دارای توابع انتساب است که به شما امکان می دهد این اطلاعات اضافی را جمع آوری کنید. برای اطلاعات بیشتر، به عملکرد اشکال زدایی در فیلد مراجعه کنید. سایر ارائه دهندگان RUM نیز به طور مشابه شروع به جمع آوری و ارائه این داده ها کرده اند.
علل شایع CLS
هنگامی که علل CLS را شناسایی کردید، می توانید کار را برای رفع مشکلات شروع کنید. در این بخش ما برخی از دلایل رایج CLS را نشان خواهیم داد و برای جلوگیری از آنها چه کاری می توانید انجام دهید.
تصاویر بدون ابعاد
همیشه ویژگی های اندازه width
و height
را در تصاویر و عناصر ویدیوی خود قرار دهید. همچنین، فضای مورد نیاز را با aspect-ratio
CSS یا موارد مشابه رزرو کنید. این رویکرد تضمین میکند که مرورگر میتواند در حین بارگذاری تصویر، فضای صحیحی را در سند اختصاص دهد.
![گزارش فانوس دریایی که تاثیر قبل و بعد از تغییر چیدمان تجمعی را پس از تنظیم ابعاد روی تصاویر نشان می دهد.](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-report-showing-9556bbb060b37.png?hl=fa)
تاریخچه صفات width
و height
در تصاویر
در روزهای اولیه وب، توسعهدهندگان ویژگیهای width
و height
را به برچسبهای <img>
خود اضافه میکردند تا اطمینان حاصل کنند که قبل از شروع مرورگر واکشی تصاویر، فضای کافی در صفحه اختصاص داده شده است. این امر جریان مجدد و طرح بندی مجدد را به حداقل می رساند.
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
width
و height
در این مثال شامل واحد نمی شود. این ابعاد "پیکسل" تضمین می کند که مرورگر یک منطقه 640x360 را در طرح بندی صفحه رزرو کرده است. بدون در نظر گرفتن اینکه آیا ابعاد واقعی با آن مطابقت دارند یا خیر، تصویر کشیده می شود تا با این فضا مطابقت داشته باشد.
هنگامی که طراحی وب ریسپانسیو معرفی شد، توسعه دهندگان شروع به حذف width
و height
کردند و به جای آن شروع به استفاده از CSS برای تغییر اندازه تصاویر کردند:
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
با این حال، چون اندازه تصویر مشخص نشده است، تا زمانی که مرورگر شروع به دانلود آن نکند و نتواند ابعاد آن را تعیین کند، نمی توان فضایی را برای آن اختصاص داد. با بارگیری تصاویر، متن به سمت پایین صفحه جابهجا میشود تا فضایی برای آنها ایجاد کند و تجربهای گیجکننده و خستهکننده ایجاد کند.
این همان جایی است که نسبت تصویر وارد می شود. نسبت تصویر، نسبت عرض آن به ارتفاع آن است. معمول است که این عدد را به صورت دو عدد که با دو نقطه از هم جدا شده اند مشاهده کنید (مثلاً 16:9 یا 4:3). برای نسبت تصویر x:y، تصویر x واحد عرض و y واحد بالا است.
یعنی اگر یکی از ابعاد را بدانیم، دیگری را می توان تعیین کرد. برای نسبت تصویر 16:9:
- اگر puppy.jpg دارای ارتفاع 360 پیکسل باشد، عرض آن 360 x (16/9) = 640 پیکسل است.
- اگر puppy.jpg دارای عرض 640 پیکسل باشد، ارتفاع آن 640 x (9/16) = 360 پیکسل است.
دانستن نسبت تصویر برای یک تصویر به مرورگر اجازه می دهد تا فضای کافی برای ارتفاع و منطقه مربوطه را محاسبه و رزرو کند.
بهترین روش مدرن برای تنظیم ابعاد تصویر
از آنجایی که مرورگرهای مدرن نسبت ابعاد پیشفرض تصاویر را بر اساس ویژگیهای 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;
}
Safari با استفاده از یک منبع سبک 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 شما افزایش یابد.
تبلیغات یکی از بزرگترین کمککنندهها در تغییر طرحبندی در وب هستند. شبکه های تبلیغاتی و ناشران اغلب از اندازه های تبلیغاتی پویا پشتیبانی می کنند. اندازه تبلیغات به دلیل نرخ کلیک بالاتر و تبلیغات بیشتر در حراج، عملکرد و درآمد را افزایش می دهد. متأسفانه، به دلیل اینکه تبلیغات محتوای قابل مشاهدهای را که در صفحه مشاهده میکنید، تحت فشار قرار میدهند، این میتواند منجر به تجربه کاربری کمتر از حد مطلوبی شود.
ویجتهای قابل جاسازی به شما این امکان را میدهند که محتوای وب قابل حمل مانند ویدیوهای YouTube، نقشههای Google Maps و پستهای رسانههای اجتماعی را در صفحه خود قرار دهید. با این حال، این ویجت ها اغلب قبل از بارگیری از حجم محتوای خود آگاه نیستند. در نتیجه، پلتفرمهایی که جاسازیها را ارائه میکنند، همیشه فضایی را برای ویجتهای خود رزرو نمیکنند، که باعث میشود در نهایت هنگام بارگذاری، چیدمان تغییر کند.
تکنیک های مقابله با اینها همه مشابه هستند. تفاوت های عمده این است که چقدر بر محتوایی که درج می شود کنترل دارید. اگر این مورد توسط شخص ثالثی مانند یک شریک تبلیغاتی درج شود، ممکن است اندازه دقیق محتوایی که درج میشود را ندانید، و همچنین نتوانید تغییرات طرحبندی که در آن جاسازیها اتفاق میافتد را کنترل کنید.
برای مطالبی که دیر بارگذاری می شوند فضا را رزرو کنید
هنگام قرار دادن محتوای با بارگذاری دیرهنگام در جریان محتوا، با رزرو فضا برای آنها در طرح اولیه، می توان از تغییرات طرح بندی جلوگیری کرد.
یک روش اضافه کردن یک قانون CSS min-height
برای رزرو فضا یا - برای مثال برای محتوای واکنشگرا مانند تبلیغات - استفاده از ویژگی CSS aspect-ratio
به روشی مشابه با روشی که مرورگرها به طور خودکار از آن برای تصاویر با ابعاد ارائه شده استفاده میکنند، است.
ممکن است لازم باشد تفاوتهای ظریف در اندازه آگهی یا مکاننما در فاکتورهای فرم را با استفاده از پرسوجوهای رسانه در نظر بگیرید.
برای محتوایی که ممکن است ارتفاع ثابتی نداشته باشد، مانند تبلیغات، ممکن است نتوانید مقدار دقیق فضای مورد نیاز برای حذف کامل تغییر چیدمان را رزرو کنید. اگر تبلیغ کوچکتری ارائه شود، ناشر میتواند برای جلوگیری از تغییرات طرحبندی، محفظه بزرگتری را استایل کند، یا بر اساس دادههای تاریخی، محتملترین اندازه را برای جایگاه آگهی انتخاب کند. نقطه ضعف این روش این است که مقدار فضای خالی صفحه را افزایش می دهد.
در عوض میتوانید اندازه اولیه را روی کوچکترین اندازهای که استفاده میشود تنظیم کنید و مقداری تغییر را برای محتوای بزرگتر بپذیرید. استفاده از min-height
، همانطور که قبلاً پیشنهاد شد، به عنصر والد اجازه میدهد تا در صورت لزوم رشد کند و در عین حال تأثیر تغییرات طرحبندی را در مقایسه با اندازه پیشفرض 0px یک عنصر خالی کاهش میدهد.
اگر مثلاً هیچ تبلیغی برگردانده نشد، سعی کنید با نشان دادن یک مکان نگهدار از جمع شدن فضای رزرو شده جلوگیری کنید. حذف فضای در نظر گرفته شده برای عناصر می تواند به اندازه درج محتوا باعث ایجاد CLS شود.
محتوای دیر بارگذاری شده را در قسمت پایین تر در قسمت دید قرار دهید
محتوای تزریق شده به صورت دینامیکی نزدیک به بالای درگاه نمایش معمولاً باعث تغییرات بیشتر در طرحبندی نسبت به محتوای تزریق شده در پایینتر در نمای دید میشود. با این حال، تزریق محتوا در هر نقطه از viewport همچنان باعث ایجاد تغییراتی می شود. اگر نمی توانید فضایی را برای محتوای تزریقی رزرو کنید، توصیه می کنیم آن را بعداً در صفحه قرار دهید تا تأثیر آن بر CLS آن کاهش یابد.
از درج محتوای جدید بدون تعامل کاربر خودداری کنید
احتمالاً به دلیل UI که هنگام بارگذاری یک سایت در بالا یا پایین ویوپورت ظاهر میشود، تغییرات طرحبندی را تجربه کردهاید. مشابه تبلیغات، اغلب در مورد بنرها و فرم هایی که بقیه محتوای صفحه را تغییر می دهند، این اتفاق می افتد:
اگر نیاز به نمایش این نوع امکانات رابط کاربری دارید، از قبل فضای کافی را در ویوپورت برای آن رزرو کنید (مثلاً با استفاده از یک مکان نگهدار یا اسکلت UI) تا وقتی بارگذاری میشود، باعث جابهجایی شگفتآور محتوای صفحه نشود. از طرف دیگر، با پوشاندن محتوایی که منطقی است، اطمینان حاصل کنید که عنصر بخشی از جریان سند نیست. برای توصیههای بیشتر در مورد این نوع مؤلفهها، پست «بهترین شیوهها برای اطلاعیههای کوکی» را ببینید.
در برخی موارد افزودن محتوا به صورت پویا بخش مهمی از تجربه کاربر است. به عنوان مثال، هنگام بارگیری محصولات بیشتر در لیستی از موارد یا هنگام به روز رسانی محتوای فید زنده. چندین راه برای جلوگیری از تغییرات غیرمنتظره چیدمان در این موارد وجود دارد:
- محتوای قدیمی را با محتوای جدید در یک ظرف با اندازه ثابت جایگزین کنید یا از چرخ فلک استفاده کنید و محتوای قدیمی را پس از انتقال حذف کنید. به خاطر داشته باشید که برای جلوگیری از کلیکها یا ضربههای تصادفی هنگام ورود محتوای جدید، پیوندها و کنترلها را تا زمانی که انتقال کامل نشده است، غیرفعال کنید.
- از کاربر بخواهید بارگذاری محتوای جدید را آغاز کند تا از این تغییر غافلگیر نشوند (مثلاً با دکمه «بارگذاری بیشتر» یا «بازخوانی»). توصیه میشود قبل از تعامل با کاربر، محتوا را از قبل واکشی کنید تا فوراً نمایش داده شود. به عنوان یادآوری، تغییرات طرحبندی که در عرض 500 میلیثانیه از ورودی کاربر رخ میدهند، در CLS محاسبه نمیشوند.
- یکپارچه محتوا را خارج از صفحه بارگیری کنید و یک اعلان به کاربر مبنی بر در دسترس بودن آن قرار دهید (به عنوان مثال، با دکمه "پیمایش به بالا").
![نمونه هایی از بارگیری محتوای پویا بدون ایجاد تغییرات غیرمنتظره طرح بندی از توییتر و وب سایت Chloé](https://web.developers.google.cn/static/articles/optimize-cls/image/examples-dynamic-content-4d11ddda2fa94.png?hl=fa)
انیمیشن ها
تغییرات در مقادیر ویژگی CSS می تواند مرورگر را ملزم کند که به این تغییرات واکنش نشان دهد. برخی از مقادیر، مانند box-shadow
و box-sizing
، طرحبندی مجدد، رنگ و ترکیب را فعال میکنند. تغییر ویژگیهای top
و left
نیز باعث تغییر طرحبندی میشود، حتی زمانی که عنصر در حال جابجایی روی لایه خودش باشد. از انیمیشن سازی با استفاده از این ویژگی ها خودداری کنید.
سایر ویژگی های CSS را می توان بدون ایجاد طرح بندی مجدد تغییر داد. اینها شامل استفاده از انیمیشن های transform
برای ترجمه، مقیاس، چرخش یا انحراف عناصر است.
انیمیشنهای ترکیبی با استفاده از translate
نمیتوانند بر عناصر دیگر تأثیر بگذارند، بنابراین در CLS به حساب نمیآیند. انیمیشن های غیر ترکیبی نیز باعث طرح بندی مجدد نمی شوند. برای اطلاعات بیشتر در مورد اینکه کدام ویژگیهای CSS باعث تغییر طرحبندی میشوند، به انیمیشنهای با عملکرد بالا مراجعه کنید.
فونت های وب
دانلود و ارائه فونت های وب معمولاً به یکی از دو روش قبل از دانلود فونت وب انجام می شود:
- فونت بازگشتی با فونت وب جایگزین میشود و فلش متن بدون سبک (FOUT) را به همراه دارد.
- متن "نامرئی" با استفاده از فونت بازگشتی نمایش داده می شود تا زمانی که یک فونت وب در دسترس باشد و متن قابل مشاهده باشد (FOIT—فلش متن نامرئی).
هر دو رویکرد می توانند باعث تغییر طرح شوند . حتی اگر متن نامرئی باشد، باز هم با استفاده از فونت بازگشتی تنظیم میشود، بنابراین وقتی فونت وب بارگیری میشود، بلوک متن و محتوای اطراف به همان روشی که برای فونت قابل مشاهده است تغییر میکند.
ابزارهای زیر می توانند به شما کمک کنند تا جابجایی متن را به حداقل برسانید:
-
font-display: optional
میتواند از طرحبندی مجدد جلوگیری کند، زیرا فونت وب تنها در صورتی استفاده میشود که در زمان طرحبندی اولیه در دسترس باشد. - اطمینان حاصل کنید که از فونت بازگشتی مناسب استفاده شده است. به عنوان مثال، با استفاده از
font-family: "Google Sans", sans-serif;
اطمینان حاصل می کند که فونتsans-serif
مرورگر هنگام بارگیری"Google Sans"
استفاده می شود. مشخص نکردن فونت بازگشتی فقط با استفادهfont-family: "Google Sans"
به این معنی است که از فونت پیشفرض استفاده میشود، که در Chrome «Times» است - یک فونت سریف که با فونت پیشفرضsans-serif
مطابقت دارد. - با استفاده از APIهای جدید
size-adjust
،ascent-override
descent-override
و نادیدهline-gap-override
تفاوت اندازه بین فونت بازگشتی و فونت وب را به حداقل برسانید همانطور که در پست جایگزین فونت بهبود یافته توضیح داده شده است. - Font Loading API می تواند زمان دریافت فونت های لازم را کاهش دهد.
- با استفاده از
<link rel=preload>
فونت های مهم وب را در اسرع وقت بارگیری کنید. یک فونت از پیش بارگذاری شده شانس بیشتری برای مطابقت با اولین رنگ خواهد داشت، در این صورت هیچ تغییری در طرح وجود ندارد.
بهترین روشها برای فونتها را برای سایر بهترین شیوههای فونت بخوانید.
با اطمینان از واجد شرایط بودن صفحات برای bfcache، CLS را کاهش دهید
یک تکنیک بسیار موثر برای پایین نگه داشتن امتیازات CLS این است که مطمئن شوید صفحات وب شما واجد شرایط کش عقب و جلو (bfcache) هستند.
bfcache صفحات را برای مدت کوتاهی پس از ناوبری در مرورگرها در حافظه نگه می دارد، بنابراین اگر به آنها بازگردید، دقیقاً همانطور که آنها را ترک کرده اید بازیابی می شوند. این بدان معنی است که صفحه کاملاً بارگذاری شده فوراً در دسترس است - بدون هیچ گونه تغییری که ممکن است به طور معمول در حین بارگذاری به دلیل هر یک از دلایل ذکر شده قبلاً مشاهده شود.
در حالی که این به طور بالقوه هنوز به این معنی است که بارگذاری اولیه صفحه با تغییرات طرحبندی مواجه میشود، وقتی کاربر به صفحات بازمیگردد، تغییرات طرحبندی یکسانی را مکرراً مشاهده نمیکند. شما همیشه باید سعی کنید از جابجایی ها حتی در بار اولیه اجتناب کنید، اما در جایی که حل کامل آن مشکل تر است، حداقل می توانید با اجتناب از آنها در هر مسیریابی bfcache، تأثیر آن را کاهش دهید.
پیمایش عقب و جلو در بسیاری از سایت ها رایج است. به عنوان مثال، بازگشت به صفحه محتوا، یا صفحه دسته بندی، یا نتایج جستجو.
هنگامی که این مورد در کروم عرضه شد ، شاهد پیشرفت های قابل توجهی در CLS بودیم.
bfcache به طور پیشفرض توسط همه مرورگرها استفاده میشود، اما برخی از سایتها به دلایل مختلف واجد شرایط استفاده از bfcache نیستند. راهنمای bfcache را برای جزئیات بیشتر در مورد نحوه آزمایش و شناسایی هر گونه مشکلی که مانع استفاده از bfcache می شود را بخوانید تا مطمئن شوید که از این ویژگی برای کمک به امتیاز کلی CLS برای سایت خود استفاده کامل می کنید.
نتیجه گیری
تعدادی تکنیک برای شناسایی و بهبود CLS وجود دارد که قبلاً در این راهنما توضیح داده شد. امکاناتی در Core Web Vitals تعبیه شده است، بنابراین حتی اگر نمی توانید CLS را به طور کامل حذف کنید، استفاده از برخی از این تکنیک ها به شما امکان می دهد تأثیر را کاهش دهید. امیدواریم که این به شما امکان می دهد تا در آن محدودیت ها بمانید و تجربه بهتری برای کاربران وب سایت خود ایجاد کنید.
،بیاموزید که چگونه از تغییرات ناگهانی چیدمان برای بهبود تجربه کاربر جلوگیری کنید
تاریخ انتشار: 5 می 2020، آخرین به روز رسانی: 7 فوریه 2025
تغییر چیدمان تجمعی (CLS) یکی از سه معیار اصلی Web Vitals است. بیثباتی محتوا را با ترکیب میزان جابهجایی محتوای قابل مشاهده در نما با فاصلهای که عناصر تحت تأثیر قرار گرفتهاند، اندازهگیری میکند.
تغییر چیدمان می تواند حواس کاربران را پرت کند. تصور کنید زمانی که به طور ناگهانی عناصر در سراسر صفحه جابه جا می شوند، شروع به خواندن مقاله ای کرده اید و شما را پرت می کنند و از شما می خواهند که دوباره مکان خود را پیدا کنید. این امر در وب بسیار رایج است، از جمله هنگام خواندن اخبار، یا تلاش برای کلیک بر روی دکمههای «جستجو» یا «افزودن به سبد خرید». چنین تجربیاتی از نظر بصری خسته کننده و خسته کننده هستند. آنها اغلب زمانی ایجاد می شوند که عناصر قابل مشاهده مجبور به جابجایی شوند زیرا عنصر دیگری به طور ناگهانی به صفحه اضافه شده یا اندازه آن تغییر کرده است.
برای ارائه یک تجربه کاربری خوب، سایت ها باید تلاش کنند تا حداقل 75 درصد از بازدیدهای صفحه، CLS 0.1 یا کمتر داشته باشند.
برخلاف سایر Core Web Vitals که مقادیر مبتنی بر زمان هستند که در ثانیه یا میلی ثانیه اندازهگیری میشوند، امتیاز CLS یک مقدار بدون واحد است که بر اساس محاسبه میزان جابهجایی محتوا و میزان فاصله است.
در این راهنما، بهینه سازی علل رایج تغییر چیدمان را پوشش خواهیم داد.
شایع ترین علل CLS ضعیف عبارتند از:
- تصاویر بدون ابعاد
- تبلیغات، جاسازیها و آیفریمهای بدون ابعاد.
- محتوای تزریقی پویا مانند تبلیغات، جاسازیها و آیفریمهای بدون ابعاد.
- فونت های وب
دلایل تغییر چیدمان را درک کنید
قبل از شروع به دنبال راه حل برای مسائل رایج CLS، مهم است که امتیاز CLS خود را درک کنید و این تغییرات از کجا می آیند.
CLS در ابزار آزمایشگاهی در مقابل میدان
شنیدن اینکه برنامهنویسان فکر میکنند CLS اندازهگیری شده توسط گزارش Chrome UX (CrUX) نادرست است، بسیار رایج است، زیرا با CLS که با استفاده از ابزار توسعه کروم یا سایر ابزارهای آزمایشگاهی اندازهگیری میکنند مطابقت ندارد. ابزارهای آزمایشگاه عملکرد وب مانند Lighthouse ممکن است CLS کامل یک صفحه را نشان ندهند، زیرا معمولاً بارگذاری اولیه صفحه را برای اندازهگیری برخی معیارهای عملکرد وب و ارائه برخی راهنماییها انجام میدهند (اگرچه جریانهای کاربر Lighthouse به شما امکان میدهد فراتر از ممیزی بار پیشفرض صفحه اندازهگیری کنید).
CrUX مجموعه داده رسمی برنامه Web Vitals است و برای آن، CLS در تمام طول عمر صفحه اندازه گیری می شود و نه فقط در زمان بارگذاری اولیه صفحه که ابزارهای آزمایشگاهی معمولاً اندازه گیری می کنند.
تغییر چیدمان در حین بارگذاری صفحه بسیار رایج است، زیرا تمام منابع لازم برای رندر اولیه صفحه واکشی میشوند، اما تغییر طرحبندی نیز میتواند پس از بارگذاری اولیه اتفاق بیفتد. بسیاری از جابجاییهای پس از بارگذاری ممکن است در نتیجه تعامل کاربر رخ دهند و بنابراین از امتیاز CLS حذف میشوند، زیرا تغییرات مورد انتظار آنها وجود دارد - تا زمانی که در عرض 500 میلیثانیه از آن تعامل رخ دهند.
با این حال، سایر تغییرات پس از بارگیری که توسط کاربر غیرمنتظره هستند، ممکن است در مواردی که هیچ تعامل واجد شرایطی وجود نداشته باشد، لحاظ شوند - به عنوان مثال، اگر بیشتر در صفحه پیمایش کنید و محتوای بارگذاری شده با تنبلی بارگیری شود و این باعث جابجایی شود. سایر علل متداول CLS پس از بارگذاری، در تعاملات انتقال است، به عنوان مثال در برنامه های یک صفحه، که بیش از مهلت 500 میلی ثانیه طول می کشد.
PageSpeed Insights هم CLS درک شده توسط کاربر را از یک URL در بخش "کشف آنچه کاربران واقعی شما تجربه می کنند" و هم CLS بارگیری مبتنی بر آزمایشگاه را در بخش "تشخیص مشکلات عملکرد" نشان می دهد. تفاوت بین این مقادیر احتمالاً نتیجه CLS پس از بارگذاری است.
![PageSpeed Insights دادههای سطح URL را نشان میدهد که CLS کاربر واقعی را برجسته میکند که به طور قابلتوجهی بزرگتر از Lighthouse CLS است.](https://web.developers.google.cn/static/articles/optimize-cls/image/screenshot-pagespeed-ins-1b9715cccc402.png?hl=fa)
مشکلات بار CLS را شناسایی کنید
هنگامی که امتیازات CrUX و Lighthouse CLS از PageSpeed Insights به طور گسترده تراز هستند، این معمولاً نشان می دهد که یک مشکل بار CLS وجود دارد که توسط Lighthouse شناسایی شده است. در این مورد Lighthouse با دو ممیزی کمک می کند تا اطلاعات بیشتری در مورد تصاویری که به دلیل عرض و ارتفاع از دست رفته باعث ایجاد CLS می شوند ارائه دهد و همچنین تمام عناصری را که برای بارگذاری صفحه جابه جا شده اند همراه با سهم CLS آنها فهرست می کند. با فیلتر کردن ممیزی های CLS می توانید این ممیزی ها را مشاهده کنید:
![اسکرین شات Lighthouse که ممیزی های CLS را نشان می دهد که اطلاعات بیشتری را برای کمک به شناسایی و رسیدگی به مشکلات CLS ارائه می دهد](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-screenshot-sho-1c6eeefdc4b1b.png?hl=fa)
پانل عملکرد در DevTools اطلاعات زیادی در مورد تغییرات طرح ارائه می دهد:
![سوابق Layout Shift در پانل عملکرد Chrome DevTools نمایش داده می شود.](https://web.developers.google.cn/static/articles/optimize-cls/image/devtools-cls-debugging.png?hl=fa)
Layout Shift
نشان می دهد. با کلیک بر روی الماس ها، انیمیشنی از تغییر و جزئیات در پانل خلاصه نمایش داده می شود.تغییرات چیدمان در مسیر تغییر چیدمان هایلایت می شوند. خط بنفش به گروههای شیفتی تبدیل میشود که الماسها تغییرات فردی را در آن خوشه نشان میدهند. اندازه الماس متناسب با اندازه شیفت است که به شما امکان می دهد تا در بزرگترین جابجایی ها دقت کنید.
با کلیک بر روی یک شیفت، یک پاپ آپ با انیمیشنی از تغییر نمایش داده می شود و تغییر عناصر به رنگ بنفش برجسته می شود.
علاوه بر این، نمای خلاصه برای رکورد Layout Shift
شامل زمان شروع، امتیاز تغییر و همچنین عناصر جابجا شده است. این به ویژه برای دریافت جزئیات بیشتر در مورد مسائل بارگذاری CLS مفید است زیرا به راحتی با نمایه عملکرد بارگذاری مجدد تکرار می شود.
این همچنین به بینش عاملان تغییر چیدمان که در پانل Insights در سمت چپ نمایش داده شده است، پیوند میخورد، که کل CLS را در بالا و همچنین دلایل احتمالی تغییر طرحبندی را نشان میدهد.
مشکلات CLS پس از بارگذاری را شناسایی کنید
اختلاف بین نمرات CrUX و Lighthouse CLS اغلب نشان دهنده CLS پس از بارگذاری است. ردیابی این تغییرات بدون داده های میدانی می تواند دشوار باشد. برای اطلاعات در مورد جمع آوری داده های میدانی ، به اندازه گیری عناصر CLS در این زمینه مراجعه کنید.
نمای معیارهای زنده از پانل عملکرد به شما امکان می دهد با صفحه تعامل داشته باشید و نمره CLS را رصد کنید تا تعامل ایجاد شود و باعث ایجاد گزینه های بزرگ شود.
![سوابق تغییر طرح در صفحه نمایش معیارهای زنده پانل عملکرد Chrome Devtools نمایش داده می شود.](https://web.developers.google.cn/static/articles/optimize-cls/image/live-metrics-cls.png?hl=fa)
به عنوان جایگزینی برای استفاده از DevTools ، می توانید هنگام ضبط شیفت های طرح با استفاده از یک Observer Performance که درون کنسول قرار دارد ، صفحه وب خود را مرور کنید.
بعد از تنظیم نظارت شیفت ، می توانید سعی کنید هرگونه مشکل CLS پس از بار را تکرار کنید. CLS اغلب در حالی که کاربر از طریق یک صفحه حرکت می کند ، اتفاق می افتد ، هنگامی که محتوای بارگذاری شده با تنبلی کاملاً بدون فضا برای آن رزرو می شود. تغییر محتوا هنگامی که کاربر نشانگر را بر روی آن نگه می دارد ، یکی دیگر از علت های مشترک CLS پس از بار است. هر تغییر محتوا در طول هر یک از این تعامل ها غیر منتظره است ، حتی اگر در 500 میلی ثانیه اتفاق بیفتد.
برای اطلاعات بیشتر ، به تغییرات طرح اشکال زدایی مراجعه کنید.
پس از شناسایی هرگونه دلایل مشترک CLS ، می توان از حالت جریان کاربری Timespans از فانوس دریایی نیز استفاده کرد تا اطمینان حاصل شود که جریان های معمولی کاربر با معرفی شیفت های طرح ، از بین نمی روند.
عناصر CLS را در این زمینه اندازه گیری کنید
نظارت بر CL در این زمینه می تواند در تعیین شرایط CLS در چه شرایطی اتفاق بیفتد و دلایل احتمالی را کاهش دهد. مانند اکثر ابزارهای آزمایشگاهی ، ابزارهای میدانی فقط عناصری را که تغییر می دهند اندازه گیری می کنند ، اما معمولاً اطلاعات کافی را برای شناسایی علت فراهم می کند. همچنین می توانید از اندازه گیری های میدانی CLS استفاده کنید تا مشخص کنید کدام مسائل بالاترین اولویت برای رفع هستند.
کتابخانه web-vitals
دارای عملکردهای انتساب است که به شما امکان می دهد این اطلاعات اضافی را جمع آوری کنید. برای اطلاعات بیشتر ، به عملکرد اشکال زدایی در این زمینه مراجعه کنید. سایر ارائه دهندگان رم نیز جمع آوری و ارائه این داده ها را به طور مشابه آغاز کرده اند.
دلایل شایع CLS
پس از شناسایی علل CLS ، می توانید کار خود را برای رفع مشکلات شروع کنید. در این بخش برخی از دلایل متداول برای CLS را نشان خواهیم داد ، و آنچه می توانید برای جلوگیری از آنها انجام دهید.
تصاویر بدون ابعاد
همیشه ویژگی های width
و height
را در تصاویر و عناصر ویدیویی خود قرار دهید. از طرف دیگر ، فضای مورد نیاز را با aspect-ratio
یا مشابه رزرو کنید. این رویکرد تضمین می کند که مرورگر می تواند در حالی که تصویر در حال بارگیری است ، مقدار صحیح فضای موجود در سند را اختصاص دهد.
![گزارش فانوس دریایی که نشان دهنده ضربه قبل/بعد از تغییر در طرح چیدمان تجمعی پس از تنظیم ابعاد بر روی تصاویر است](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-report-showing-9556bbb060b37.png?hl=fa)
تاریخچه ویژگی های width
و height
در تصاویر
در اوایل وب ، توسعه دهندگان ویژگی های width
و height
را به برچسب های <img>
خود اضافه می کنند تا اطمینان حاصل شود که فضای کافی در صفحه اختصاص داده شده است قبل از اینکه مرورگر شروع به واکشی تصاویر کند. این می تواند بازتاب و دوباره لایه را به حداقل برساند.
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
width
و height
در این مثال شامل واحدها نیست. این ابعاد "پیکسل" تضمین می کند که مرورگر یک منطقه 640x360 را در طرح صفحه رزرو کند. بدون توجه به اینکه ابعاد واقعی با آن مطابقت داشته باشد ، این تصویر به سمت متناسب با این فضا کشیده می شود.
هنگامی که طراحی وب پاسخگو معرفی شد ، توسعه دهندگان شروع به حذف width
و height
کردند و به جای آن ، استفاده از CSS را برای تغییر اندازه تصاویر شروع کردند:
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
با این حال ، از آنجا که اندازه تصویر مشخص نشده است ، تا زمانی که مرورگر شروع به بارگیری آن کند ، فضا را برای آن اختصاص نمی دهد و می تواند ابعاد آن را تعیین کند. با بارگیری تصاویر ، متن صفحه را تغییر می دهد تا جایی برای آنها ایجاد شود و یک تجربه کاربر گیج کننده و ناامید کننده ایجاد کند.
این جایی است که نسبت ابعاد وارد می شود. نسبت ابعاد یک تصویر نسبت عرض آن به ارتفاع آن است. معمول است که این را به عنوان دو عدد از هم جدا شده توسط یک روده بزرگ بیان کند (به عنوان مثال ، 16: 9 یا 4: 3). برای نسبت X: Y Aspect ، تصویر واحدهای X گسترده و واحدهای y بالا است.
این بدان معناست که اگر یکی از ابعاد را بدانیم ، دیگری قابل تعیین است. برای نسبت ابعاد 16: 9:
- اگر Puppy.jpg دارای ارتفاع 360px باشد ، عرض 360 x (16 /9) = 640px است
- اگر puppy.jpg دارای عرض 640px باشد ، ارتفاع 640 x (9 /16) = 360px است
دانستن نسبت ابعاد برای یک تصویر به مرورگر اجازه می دهد تا فضای کافی را برای ارتفاع و منطقه مرتبط محاسبه و رزرو کند.
بهترین روش مدرن برای تنظیم ابعاد تصویر
از آنجا که مرورگرهای مدرن نسبت پیش فرض ابعاد تصاویر را بر اساس ویژگی های 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 پردازش می شود ، نه با یک برگه سبک پیش فرض کاربر ( این پست را برای شیرجه عمیق به دلیل آن مراجعه کنید) ، بنابراین مقدار کمی متفاوت نمایش داده می شود. به عنوان مثال ، Chrome آن را مانند این در بخش سبک های پانل عنصر نمایش می دهد:
img[Attributes Style] {
aspect-ratio: auto 640 / 360;
}
سافاری با استفاده از منبع سبک HTML به طور مشابه رفتار می کند. Firefox این aspect-ratio
محاسبه شده را به هیچ وجه در صفحه بازرس خود نمایش نمی دهد ، اما از آن برای طرح استفاده می کند.
قسمت auto
کد قبلی مهم است ، زیرا باعث می شود ابعاد تصویر پس از بارگیری تصویر ، نسبت ابعاد پیش فرض را نادیده بگیرند. اگر ابعاد تصویر متفاوت باشد ، این هنوز هم باعث تغییر برخی از چیدمان ها پس از بارهای تصویر می شود ، اما این تضمین می کند که نسبت ابعاد تصویر هنوز در دسترس است ، در صورت عدم استفاده HTML. حتی اگر نسبت ابعاد واقعی با پیش فرض متفاوت باشد ، هنوز هم باعث تغییر چیدمان کمتر از اندازه پیش فرض 0x0 یک تصویر بدون ابعاد ارائه شده است.
برای یک جابجایی عمیق به نسبت ابعاد با تفکر بیشتر در مورد تصاویر پاسخگو ، به بارگیری صفحه بدون Jank با نسبت ابعاد رسانه مراجعه کنید.
اگر تصویر شما در یک ظرف است ، می توانید از 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>
Chrome ، Firefox و Safari اکنون از تنظیم 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>
تبلیغات ، تعبیه ها و سایر محتوای با بارگذاری دیررس
تصاویر تنها نوع محتوا نیستند که می توانند باعث تغییر طرح شوند. تبلیغات ، تعبیه ها ، Iframes و سایر محتوای تزریق شده پویا همه می توانند باعث شوند که محتوا پس از تغییر آنها ظاهر شود و CLS شما را افزایش دهد.
تبلیغات یکی از بزرگترین مشارکت کنندگان در تغییر طرح در وب است. شبکه های تبلیغاتی و ناشران اغلب از اندازه تبلیغات پویا پشتیبانی می کنند. اندازه تبلیغات به دلیل نرخ کلیک بالاتر و تبلیغات بیشتر در حراج ، عملکرد و درآمد را افزایش می دهد. متأسفانه ، این می تواند به دلیل تبلیغاتی که محتوای قابل مشاهده ای را که در صفحه مشاهده می کنید ، به یک تجربه کاربر زیر حد متوسط منجر شود.
ویجت های جاسازی شده به شما امکان می دهند محتوای وب قابل حمل را در صفحه خود ، مانند فیلم های YouTube ، نقشه های Google Maps و پست های رسانه های اجتماعی قرار دهید. با این حال ، این ابزارک ها غالباً قبل از بارگذاری میزان محتوای آنها چقدر بزرگ هستند. در نتیجه ، سیستم عامل های ارائه دهنده جاسازی شده همیشه فضای ویجت های خود را ذخیره نمی کنند ، که باعث می شود در هنگام بارگیری ، تغییر طرح ایجاد شود.
تکنیک های مقابله با اینها همه مشابه است. تفاوت های عمده این است که چقدر کنترل شما نسبت به محتوایی که درج می شوند وجود دارد. اگر این شخص توسط شخص ثالث مانند شریک تبلیغاتی درج شده باشد ، ممکن است اندازه دقیق محتوا را که درج می شوند ، نمی دانید ، و همچنین قادر به کنترل هرگونه تغییر طرح در آن تعبیه ها نیستید.
فضای ذخیره برای محتوای بارگذاری دیرهنگام
هنگام قرار دادن محتوای بارگذاری دیرهنگام در جریان محتوا ، با رزرو فضای برای آنها در طرح اولیه می توان از تغییر طرح جلوگیری کرد.
یک رویکرد اضافه کردن یک قانون CSS min-height
برای رزرو فضا یا-برای محتوای پاسخگو مانند تبلیغات ، به عنوان مثال-از خاصیت CSS aspect-ratio
به روشی مشابه با روشی که مرورگرها به طور خودکار از این برای تصاویر با ابعاد ارائه شده استفاده می کنند.
ممکن است شما نیاز به تفاوت های ظریف در اندازه های AD یا مکان نگهدارنده در بین فاکتورهای فرم با استفاده از نمایش داده های رسانه ای داشته باشید.
برای محتوایی که ممکن است ارتفاع ثابت نداشته باشد ، مانند تبلیغات ، ممکن است نتوانید مقدار دقیقی از فضای مورد نیاز برای از بین بردن تغییر طرح را به طور کامل رزرو کنید. اگر یک آگهی کوچکتر ارائه شود ، یک ناشر می تواند یک ظرف بزرگتر را برای جلوگیری از شیفت های چیدمان سبک کند ، یا محتمل ترین اندازه را برای شکاف AD بر اساس داده های تاریخی انتخاب کند. نکته منفی این روش این است که میزان فضای خالی در صفحه را افزایش می دهد.
در عوض می توانید اندازه اولیه را روی کوچکترین اندازه مورد استفاده قرار دهید و برای محتوای بزرگتر سطح تغییر را بپذیرید. با استفاده از min-height
، همانطور که قبلاً پیشنهاد شد ، به عنصر والدین اجازه می دهد تا ضمن کاهش تأثیر شیفت های طرح ، در مقایسه با اندازه پیش فرض 0px یک عنصر خالی ، رشد کند.
سعی کنید با نشان دادن یک مکان نگهدارنده ، اگر به عنوان مثال ، هیچ تبلیغی برگردانده شود ، از سقوط فضای محفوظ خودداری کنید. از بین بردن فضای کنار عناصر می تواند به همان اندازه CLS به عنوان درج محتوا ایجاد کند.
محتوای بارگذاری دیر هنگام را در نمای قرار دهید
محتوای تزریقی پویا نزدیک به بالای دیدگاه معمولاً باعث تغییر چیدمان بیشتر از محتوای تزریق شده در نمای پایین می شود. با این حال ، تزریق محتوا در هر نقطه از دیدگاه هنوز هم باعث تغییر می شود. اگر نمی توانید فضایی را برای محتوای تزریق شده رزرو کنید ، توصیه می کنیم بعداً آن را در صفحه قرار دهید تا تأثیر آن در CLS آن کاهش یابد.
از قرار دادن محتوای جدید بدون تعامل کاربر خودداری کنید
شما احتمالاً هنگام تلاش برای بارگیری یک سایت ، به دلیل UI که در قسمت بالا یا پایین منظره قرار دارد ، شیفت های چیدمان را تجربه کرده اید. مشابه تبلیغات ، این اغلب با آگهی ها و فرم هایی که بقیه محتوای صفحه را تغییر می دهد اتفاق می افتد:
اگر نیاز به نمایش این نوع از هزینه های UI دارید ، از قبل فضای کافی را در نمای آن رزرو کنید (به عنوان مثال ، با استفاده از یک مکان یا یک یاب یا اسکلت اسکلتی) به گونه ای که هنگام بارگیری ، باعث نمی شود که محتوا در صفحه به طرز شگفت انگیزی تغییر کند. از طرف دیگر ، اطمینان حاصل کنید که عنصر با پوشش محتوا در جایی که این امر منطقی باشد ، بخشی از جریان سند نیست. برای توصیه های بیشتر در مورد این نوع قطعات ، بهترین روش های مربوط به اطلاعیه های کوکی را مشاهده کنید.
در بعضی موارد اضافه کردن محتوا به صورت پویا بخش مهمی از تجربه کاربر است. به عنوان مثال ، هنگام بارگیری محصولات بیشتر در لیستی از موارد یا هنگام به روزرسانی محتوای فید زنده. روش های مختلفی برای جلوگیری از تغییر طرح های غیر منتظره در این موارد وجود دارد:
- محتوای قدیمی را با محتوای جدید در یک ظرف اندازه ثابت جایگزین کنید یا از چرخ فلک استفاده کرده و محتوای قدیمی را پس از انتقال حذف کنید. به یاد داشته باشید تا زمانی که انتقال به اتمام برسد ، هرگونه پیوند و کنترل را غیرفعال کنید تا در حالی که محتوای جدید وارد می شود ، از کلیک یا شیرهای تصادفی جلوگیری کنید.
- از کاربر بخواهید بار محتوای جدید را آغاز کند ، بنابراین از تغییر (به عنوان مثال با دکمه "بار بیشتر" یا "تازه کردن") تعجب نمی کنند. توصیه می شود قبل از تعامل کاربر ، محتوا را ترجیح دهید تا بلافاصله نشان داده شود. به عنوان یک یادآوری ، تغییر چیدمان که در 500 میلی ثانیه از ورودی کاربر رخ می دهد ، به سمت CLS شمرده نمی شوند.
- یکپارچه محتوای خارج از صفحه را بارگذاری کرده و یک اطلاعیه را به کاربر در دسترس قرار دهید (به عنوان مثال ، با دکمه "پیمایش به بالا").
![نمونه هایی از بارگیری محتوای پویا بدون ایجاد تغییر طرح های غیر منتظره از توییتر و وب سایت Chloé](https://web.developers.google.cn/static/articles/optimize-cls/image/examples-dynamic-content-4d11ddda2fa94.png?hl=fa)
انیمیشن ها
تغییرات در مقادیر خاصیت CSS می تواند به مرورگر نیاز داشته باشد تا در برابر این تغییرات واکنش نشان دهد. برخی از مقادیر ، مانند box-shadow
و box-sizing
، ساخت مجدد ، رنگ و کامپوزیت. تغییر خصوصیات top
و left
نیز باعث تغییر چیدمان می شود ، حتی در صورت جابجایی عنصر در لایه خود قرار دارد. از انیمیشن با استفاده از این خصوصیات خودداری کنید.
سایر خصوصیات CSS بدون ایجاد مجدد در لایه ها قابل تغییر است. این موارد شامل استفاده از انیمیشن های transform
برای ترجمه ، مقیاس ، چرخش یا عناصر پوستی است.
انیمیشن های ترکیبی با استفاده از translate
نمی توانند عناصر دیگر را تحت تأثیر قرار دهند ، بنابراین به CLS حساب نکنید. انیمیشن های بدون ترکیب نیز باعث ایجاد مجدد مجدد نمی شوند. برای کسب اطلاعات بیشتر در مورد اینکه کدام خصوصیات CSS باعث تغییر در طرح بندی می شود ، به انیمیشن های با کارایی بالا مراجعه کنید.
فونت های وب
بارگیری و ارائه فونت های وب معمولاً قبل از بارگیری فونت وب به یکی از دو روش انجام می شود:
- فونت Fallback با فونت وب تعویض می شود و باعث ایجاد فلاش متن بی نظیر (FOUT) می شود.
- متن "نامرئی" با استفاده از فونت برگشتی تا زمانی که یک فونت وب در دسترس نباشد و متن قابل مشاهده باشد نمایش داده می شود (Foit - Flash of Invisible Text).
هر دو روش می توانند باعث تغییر طرح شوند . حتی اگر متن نامرئی باشد ، هنوز هم با استفاده از فونت برگشتی گذاشته شده است ، بنابراین وقتی فونت وب بارگیری می شود ، بلوک متن و محتوای اطراف آن به همان روشی که برای فونت قابل مشاهده تغییر می کند تغییر می کند.
ابزارهای زیر می توانند به شما در تغییر متن کمک کنند:
-
font-display: optional
می تواند از یک لایه مجدد جلوگیری کند زیرا از فونت وب فقط در صورت استفاده از زمان طرح اولیه استفاده می شود. - اطمینان حاصل کنید که از فونت برگشتی مناسب استفاده شده است. به عنوان مثال ، با استفاده از
font-family: "Google Sans", sans-serif;
اطمینان حاصل می کند که از فونت برگشتیsans-serif
در هنگام بارگیری"Google Sans"
استفاده می شود. مشخص کردن یک قلم برگشتی با استفادهfont-family: "Google Sans"
به معنای استفاده از قلم پیش فرض است ، که در Chrome "Times" است-یک قلم Serif که یک مسابقه بدتر از قلم پیش فرضsans-serif
است. - اختلافات اندازه بین فونت برگشتی و فونت وب را با استفاده از API های جدید
size-adjust
،ascent-override
،descent-override
وline-gap-override
به عنوان مفصل در پست های فونت بهبود یافته به حداقل برسانید. - API بارگیری قلم می تواند مدت زمان لازم برای گرفتن فونت های لازم را کاهش دهد.
- فونت های وب بحرانی را در اسرع وقت با استفاده از
<link rel=preload>
بارگذاری کنید. یک قلم از پیش بارگذاری شده شانس بالاتری برای دیدار با رنگ اول خواهد داشت ، در این صورت هیچ گونه تغییر طرح وجود ندارد.
بهترین شیوه ها را برای فونت ها برای سایر بهترین شیوه های فونت بخوانید.
با اطمینان از صفحات واجد شرایط برای bfcache ، CLS را کاهش دهید
یک تکنیک بسیار مؤثر برای پایین نگه داشتن نمرات CLS این است که اطمینان حاصل کنید که صفحات وب شما واجد شرایط برای حافظه نهان عقب/رو به جلو (BFCACHE) هستند.
BFCACHE بعد از اینکه به آنجا بروید ، صفحات را در حافظه مرورگرها برای مدت کوتاهی نگه می دارد ، بنابراین اگر به آنها برگردید ، دقیقاً همانطور که آنها را ترک کردید ، آنها را ترمیم می کنند. این بدان معناست که صفحه کاملاً بارگذاری شده فوراً در دسترس است - بدون هرگونه شیفتی که ممکن است به طور معمول در هنگام بار مشاهده شود به دلایلی که قبلاً گفته شد.
در حالی که این کار به طور بالقوه هنوز به معنای تغییر بار در صفحه است ، وقتی کاربر از طریق صفحات برمی گردد ، آنها به طور مکرر تغییر می کنند. شما همیشه باید هدف خود را برای جلوگیری از شیفت حتی در بار اولیه انجام دهید ، اما جایی که برای حل و فصل کامل آن مشکل تر است ، حداقل می توانید با جلوگیری از آنها در هرگونه ناوبری BFCache ، تأثیر را کاهش دهید.
ناوبری های عقب و رو به جلو در بسیاری از سایت ها رایج است. به عنوان مثال ، بازگشت به یک صفحه محتوا ، یا یک صفحه دسته یا نتایج جستجو.
وقتی این کار به کروم منتقل شد ، ما شاهد پیشرفت های قابل توجهی در CLS بودیم.
BFCACHE به طور پیش فرض توسط همه مرورگرها استفاده می شود ، اما برخی از سایت ها به دلایل مختلف واجد شرایط برای BFCache نیستند. برای اطلاعات بیشتر در مورد نحوه آزمایش و شناسایی هرگونه مشکل جلوگیری از استفاده از BFCache ، راهنمای BFCache را بخوانید تا اطمینان حاصل کنید که از این ویژگی استفاده می کنید تا به نمره کلی CLS خود برای سایت خود کمک کنید.
نتیجه گیری
تعدادی از تکنیک ها برای شناسایی و بهبود CLS به عنوان مفصل در این راهنما وجود دارد. کمک هزینه هایی در زمینه های اصلی وب وجود دارد ، بنابراین حتی اگر نتوانید CLS را به طور کامل از بین ببرید ، استفاده از برخی از این تکنیک ها باید به شما امکان کاهش تأثیر را بدهد. این امیدوارم که به شما امکان دهد در این محدوده بمانید و تجربه بهتری را برای کاربران وب سایت خود ایجاد کنید.
،بیاموزید که چگونه از تغییر ناگهانی طرح برای بهبود تجربه کاربر جلوگیری کنید
منتشر شده: 5 مه 2020 ، آخرین به روز شده: 7 فوریه 2025
تغییر چیدمان تجمعی (CLS) یکی از سه معیار اصلی وب ویتامان است. این ناپایداری محتوا را با ترکیب میزان تغییر محتوای قابل مشاهده در نمای با فاصله ای که عناصر آسیب دیده جابجا کرده اند ، اندازه گیری می کند.
شیفت های چیدمان می تواند برای کاربران منحرف کننده باشد. تصور کنید که وقتی همه عناصر ناگهانی در اطراف صفحه تغییر می کنند ، خواندن مقاله ای را شروع کرده اید ، شما را دور می کنند و شما را ملزم به یافتن مکان خود می کنند. این در وب بسیار رایج است ، از جمله هنگام خواندن اخبار ، یا تلاش برای کلیک بر روی آن دکمه های "جستجو" یا "افزودن به سبد خرید". چنین تجربیاتی از لحاظ بصری خسته کننده و ناامید کننده است. آنها غالباً هنگامی ایجاد می شوند که عناصر قابل مشاهده مجبور به حرکت شوند زیرا به طور ناگهانی عنصر دیگری به صفحه اضافه شده یا تغییر اندازه داده می شود.
برای ارائه یک تجربه خوب کاربر ، سایت ها باید حداقل 75 ٪ از بازدید از صفحه ، CLS 0.1 یا کمتر داشته باشند.
بر خلاف سایر ویتامین های اصلی وب ، که مقادیر مبتنی بر زمان در ثانیه یا میلی ثانیه اندازه گیری می شوند ، نمره CLS یک مقدار بدون واحد است که براساس محاسبه میزان تغییر محتوا و تا چه اندازه است.
در این راهنما ، ما بهینه سازی دلایل متداول تغییر طرح را پوشش خواهیم داد.
شایع ترین دلایل CLS فقیر عبارتند از:
- تصاویر بدون ابعاد
- تبلیغات، جاسازیها و آیفریمهای بدون ابعاد.
- محتوای پویا تزریق شده مانند تبلیغات ، تعبیه ها و Iframes بدون ابعاد.
- فونت های وب
دلایل تغییر چیدمان را درک کنید
قبل از اینکه به دنبال راه حل های مربوط به مسائل CLS مشترک باشید ، مهم است که نمره CLS خود را درک کنید و شیفت ها از کجا به وجود می آیند.
CLS در ابزار آزمایشگاه در مقابل زمینه
معمول است که بشنوند توسعه دهندگان فکر می کنند CLS اندازه گیری شده توسط گزارش Chrome UX (CRUX) نادرست است زیرا با CLS که اندازه آنها را با استفاده از Devtools Chrome یا سایر ابزارهای آزمایشگاهی اندازه گیری نمی کند ، مطابقت ندارد. ابزارهای آزمایشگاهی عملکرد وب مانند Lighthouse ممکن است CLS کامل یک صفحه را نشان ندهد ، زیرا آنها به طور معمول یک بار اساسی از صفحه را برای اندازه گیری برخی از معیارهای عملکرد وب انجام می دهند و راهنمایی هایی را ارائه می دهند (هرچند جریان کاربر Lighthouse به شما امکان می دهد تا فراتر از حسابرسی بار صفحه پیش فرض اندازه گیری کنید).
CRUX مجموعه داده رسمی برنامه وب ویتامان است و برای آن ، CLS در طول عمر کامل صفحه اندازه گیری می شود و نه فقط در زمان بار اولیه صفحه که ابزارهای آزمایشگاهی به طور معمول اندازه گیری می کنند.
تغییر چیدمان در هنگام بار صفحه بسیار متداول است ، زیرا تمام منابع لازم برای ارائه در ابتدا صفحه به دست می آیند ، اما تغییر طرح نیز می تواند پس از بار اولیه اتفاق بیفتد. بسیاری از شیفت های پس از بار ممکن است به عنوان نتیجه تعامل کاربر رخ دهد و بنابراین از نمره CLS خارج می شود زیرا انتظار می رود شیفت ها-تا زمانی که در 500 میلی ثانیه از آن تعامل اتفاق بیفتد.
با این حال ، سایر شیفت های پس از بار که توسط کاربر غیر منتظره هستند ممکن است در جایی باشد که هیچ تعامل واجد شرایط وجود ندارد-برای مثال ، اگر در طول صفحه بیشتر پیمایش کنید و محتوای تنبل بارگذاری شده بارگیری شود و باعث تغییر می شود. سایر دلایل متداول CL های پس از بار در تعامل انتقال است ، به عنوان مثال در برنامه های تک صفحه ای که بیشتر از دوره GRACE 500 میلی ثانیه طول می کشد.
Pagespeed Insights هر دو CL های درک شده کاربر را از یک URL در بخش "کشف آنچه کاربران واقعی شما تجربه می کنند" را نشان می دهد ، و CL های بار مبتنی بر آزمایشگاه را در بخش "تشخیص عملکرد عملکرد" خود نشان می دهد. تفاوت بین این مقادیر احتمالاً نتیجه CLS پس از بار است.
![بینش های Pagespeed که داده های سطح URL را نشان می دهد که CLS کاربر واقعی را برجسته می کند که به طور قابل توجهی بزرگتر از CLS Lighthouse است](https://web.developers.google.cn/static/articles/optimize-cls/image/screenshot-pagespeed-ins-1b9715cccc402.png?hl=fa)
مسائل CLS LOAD را شناسایی کنید
هنگامی که نمرات CLS CRUX و Lighthouse CLS به طور گسترده ای تراز می شوند ، این معمولاً نشان می دهد که یک مسئله بار CLS وجود دارد که توسط فانوس دریایی تشخیص داده شده است. در این حالت Lighthouse به دو ممیزی کمک می کند تا اطلاعات بیشتری در مورد تصاویر ایجاد شده به دلیل عرض و ارتفاع از دست رفته ارائه دهند ، و همچنین تمام عناصر تغییر یافته برای بار صفحه را به همراه سهم CLS خود ذکر کنید. این ممیزی ها را می توانید با فیلتر کردن در حسابرسی CLS مشاهده کنید:
![تصویر فانوس دریایی که حسابرسی CLS را نشان می دهد و اطلاعات بیشتری را برای کمک به شما در شناسایی و رسیدگی به مشکلات CLS ارائه می دهد](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-screenshot-sho-1c6eeefdc4b1b.png?hl=fa)
پانل عملکرد در DevTools اطلاعات زیادی در مورد شیفت های چیدمان ارائه می دهد:
![سوابق تغییر چیدمان در پانل عملکرد Chrome DevTools نمایش داده می شود.](https://web.developers.google.cn/static/articles/optimize-cls/image/devtools-cls-debugging.png?hl=fa)
Layout Shift
نشان می دهند. با کلیک بر روی Diamonds ، انیمیشن تغییر و جزئیات در پانل خلاصه را نشان می دهد.شیفت های چیدمان در مسیر شیفت طرح ها برجسته می شوند. گروه های خط بنفش به خوشه های شیفت تغییر می کنند و الماس نشان می دهد که تغییرات فردی در آن خوشه را نشان می دهد. اندازه الماس متناسب با اندازه تغییر است که به شما امکان می دهد در بزرگترین شیفت ها سنگ زنی کنید.
با کلیک بر روی یک شیفت ، پاپ را با یک انیمیشن از تغییر نشان می دهد و عناصر تغییر رنگ بنفش را برجسته می کند.
علاوه بر این ، نمای خلاصه برای رکورد Layout Shift
شامل زمان شروع ، نمره تغییر و همچنین عناصر تغییر یافته است. این امر به ویژه برای به دست آوردن جزئیات بیشتر در مورد مسائل Load CLS مفید است زیرا این کار به راحتی با مشخصات عملکرد بارگیری مجدد تکرار می شود.
این همچنین به Culprits Insight Culprits Insight در سمت چپ نشان داده شده است ، که کل CL ها را در بالا نشان می دهد ، و همچنین دلایل ممکن برای تغییر طرح.
مسائل CLS پس از بار را شناسایی کنید
اختلاف بین نمرات CLS CRUX و Lighthouse اغلب نشانگر CLS پس از بار است. این شیفت ها برای ردیابی بدون داده های میدانی می توانند مشکل باشند. برای اطلاعات در مورد جمع آوری داده های میدانی ، به اندازه گیری عناصر CLS در این زمینه مراجعه کنید.
نمای معیارهای زنده از پانل عملکرد به شما امکان می دهد با صفحه تعامل داشته باشید و نمره CLS را رصد کنید تا تعامل ایجاد شود و باعث ایجاد گزینه های بزرگ شود.
![سوابق تغییر طرح در صفحه نمایش معیارهای زنده پانل عملکرد Chrome Devtools نمایش داده می شود.](https://web.developers.google.cn/static/articles/optimize-cls/image/live-metrics-cls.png?hl=fa)
به عنوان جایگزینی برای استفاده از DevTools ، می توانید هنگام ضبط شیفت های طرح با استفاده از یک Observer Performance که درون کنسول قرار دارد ، صفحه وب خود را مرور کنید.
بعد از تنظیم نظارت شیفت ، می توانید سعی کنید هرگونه مشکل CLS پس از بار را تکرار کنید. CLS اغلب در حالی که کاربر از طریق یک صفحه حرکت می کند ، اتفاق می افتد ، هنگامی که محتوای بارگذاری شده با تنبلی کاملاً بدون فضا برای آن رزرو می شود. تغییر محتوا هنگامی که کاربر نشانگر را بر روی آن نگه می دارد ، یکی دیگر از علت های مشترک CLS پس از بار است. هر تغییر محتوا در طول هر یک از این تعامل ها غیر منتظره است ، حتی اگر در 500 میلی ثانیه اتفاق بیفتد.
برای اطلاعات بیشتر ، به تغییرات طرح اشکال زدایی مراجعه کنید.
پس از شناسایی هرگونه دلایل مشترک CLS ، می توان از حالت جریان کاربری Timespans از فانوس دریایی نیز استفاده کرد تا اطمینان حاصل شود که جریان های معمولی کاربر با معرفی شیفت های طرح ، از بین نمی روند.
عناصر CLS را در این زمینه اندازه گیری کنید
نظارت بر CL در این زمینه می تواند در تعیین شرایط CLS در چه شرایطی اتفاق بیفتد و دلایل احتمالی را کاهش دهد. مانند اکثر ابزارهای آزمایشگاهی ، ابزارهای میدانی فقط عناصری را که تغییر می دهند اندازه گیری می کنند ، اما معمولاً اطلاعات کافی را برای شناسایی علت فراهم می کند. همچنین می توانید از اندازه گیری های میدانی CLS استفاده کنید تا مشخص کنید کدام مسائل بالاترین اولویت برای رفع هستند.
کتابخانه web-vitals
دارای عملکردهای انتساب است که به شما امکان می دهد این اطلاعات اضافی را جمع آوری کنید. برای اطلاعات بیشتر ، به عملکرد اشکال زدایی در این زمینه مراجعه کنید. سایر ارائه دهندگان رم نیز جمع آوری و ارائه این داده ها را به طور مشابه آغاز کرده اند.
دلایل شایع CLS
پس از شناسایی علل CLS ، می توانید کار خود را برای رفع مشکلات شروع کنید. در این بخش برخی از دلایل متداول برای CLS را نشان خواهیم داد ، و آنچه می توانید برای جلوگیری از آنها انجام دهید.
تصاویر بدون ابعاد
همیشه ویژگی های width
و height
را در تصاویر و عناصر ویدیویی خود قرار دهید. از طرف دیگر ، فضای مورد نیاز را با aspect-ratio
یا مشابه رزرو کنید. این رویکرد تضمین می کند که مرورگر می تواند در حالی که تصویر در حال بارگیری است ، مقدار صحیح فضای موجود در سند را اختصاص دهد.
![گزارش فانوس دریایی که نشان دهنده ضربه قبل/بعد از تغییر در طرح چیدمان تجمعی پس از تنظیم ابعاد بر روی تصاویر است](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-report-showing-9556bbb060b37.png?hl=fa)
تاریخچه ویژگی های width
و height
در تصاویر
در اوایل وب ، توسعه دهندگان ویژگی های width
و height
را به برچسب های <img>
خود اضافه می کنند تا اطمینان حاصل شود که فضای کافی در صفحه اختصاص داده شده است قبل از اینکه مرورگر شروع به واکشی تصاویر کند. این می تواند بازتاب و دوباره لایه را به حداقل برساند.
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
width
و height
در این مثال شامل واحدها نیست. این ابعاد "پیکسل" تضمین می کند که مرورگر یک منطقه 640x360 را در طرح صفحه رزرو کند. بدون توجه به اینکه ابعاد واقعی با آن مطابقت داشته باشد ، این تصویر به سمت متناسب با این فضا کشیده می شود.
هنگامی که طراحی وب پاسخگو معرفی شد ، توسعه دهندگان شروع به حذف width
و height
کردند و به جای آن ، استفاده از CSS را برای تغییر اندازه تصاویر شروع کردند:
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
با این حال ، از آنجا که اندازه تصویر مشخص نشده است ، تا زمانی که مرورگر شروع به بارگیری آن کند ، فضا را برای آن اختصاص نمی دهد و می تواند ابعاد آن را تعیین کند. با بارگیری تصاویر ، متن صفحه را تغییر می دهد تا جایی برای آنها ایجاد شود و یک تجربه کاربر گیج کننده و ناامید کننده ایجاد کند.
این جایی است که نسبت ابعاد وارد می شود. نسبت ابعاد یک تصویر نسبت عرض آن به ارتفاع آن است. معمول است که این را به عنوان دو عدد از هم جدا شده توسط یک روده بزرگ بیان کند (به عنوان مثال ، 16: 9 یا 4: 3). برای نسبت X: Y Aspect ، تصویر واحدهای X گسترده و واحدهای y بالا است.
این بدان معناست که اگر یکی از ابعاد را بدانیم ، دیگری قابل تعیین است. برای نسبت ابعاد 16: 9:
- اگر Puppy.jpg دارای ارتفاع 360px باشد ، عرض 360 x (16 /9) = 640px است
- اگر puppy.jpg دارای عرض 640px باشد ، ارتفاع 640 x (9 /16) = 360px است
دانستن نسبت ابعاد برای یک تصویر به مرورگر اجازه می دهد تا فضای کافی را برای ارتفاع و منطقه مرتبط محاسبه و رزرو کند.
بهترین روش مدرن برای تنظیم ابعاد تصویر
از آنجا که مرورگرهای مدرن نسبت پیش فرض ابعاد تصاویر را بر اساس ویژگی های 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 پردازش می شود ، نه با یک برگه سبک پیش فرض کاربر ( این پست را برای شیرجه عمیق به دلیل آن مراجعه کنید) ، بنابراین مقدار کمی متفاوت نمایش داده می شود. به عنوان مثال ، Chrome آن را مانند این در بخش سبک های پانل عنصر نمایش می دهد:
img[Attributes Style] {
aspect-ratio: auto 640 / 360;
}
سافاری با استفاده از منبع سبک HTML به طور مشابه رفتار می کند. Firefox این aspect-ratio
محاسبه شده را به هیچ وجه در صفحه بازرس خود نمایش نمی دهد ، اما از آن برای طرح استفاده می کند.
قسمت auto
کد قبلی مهم است ، زیرا باعث می شود ابعاد تصویر پس از بارگیری تصویر ، نسبت ابعاد پیش فرض را نادیده بگیرند. اگر ابعاد تصویر متفاوت باشد ، این هنوز هم باعث تغییر برخی از چیدمان ها پس از بارهای تصویر می شود ، اما این تضمین می کند که نسبت ابعاد تصویر هنوز در دسترس است ، در صورت عدم استفاده HTML. حتی اگر نسبت ابعاد واقعی با پیش فرض متفاوت باشد ، هنوز هم باعث تغییر چیدمان کمتر از اندازه پیش فرض 0x0 یک تصویر بدون ابعاد ارائه شده است.
برای یک جابجایی عمیق به نسبت ابعاد با تفکر بیشتر در مورد تصاویر پاسخگو ، به بارگیری صفحه بدون Jank با نسبت ابعاد رسانه مراجعه کنید.
If your image is in a container, you can use CSS to resize the image to the width of the container. We set height: auto;
to avoid using a fixed value for the image height.
img {
height: auto;
width: 100%;
}
What about responsive images?
When working with responsive images , srcset
defines the images you allow the browser to select between and what size each image is. To ensure <img>
width and height attributes can be set, each image should use the same aspect ratio.
<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"
/>
Your images' aspect ratios can also change depending on your art direction . For example, you may want to include a cropped shot of an image for narrow viewports, and display the full image on desktop:
<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>
Chrome, Firefox, and Safari now support setting width
and height
on the <source>
elements within a given <picture>
element:
<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>
Ads, embeds, and other late-loaded content
Images aren't the only type of content that can cause layout shifts. Ads, embeds, iframes, and other dynamically injected content can all cause content appearing after them to shift down, increasing your CLS.
Ads are one of the largest contributors to layout shifts on the web. Ad networks and publishers often support dynamic ad sizes. Ad sizes increase performance and revenue due to higher click rates and more ads competing in the auction. Unfortunately, this can lead to a suboptimal user experience due to ads pushing visible content you're viewing down the page.
Embeddable widgets allow you to include portable web content on your page, such as videos from YouTube, maps from Google Maps, and social media posts. However, these widgets often aren't aware of how large their contents are before they load. As a result, platforms offering embeds don't always reserve space for their widgets, which causes layout shifts when they finally load.
The techniques for dealing with these are all similar. The major differences are how much control you have over the content that will be inserted. If this is inserted by a third-party like an ad partner, you may not know the exact size of content that will be inserted, nor be able to control any layout shifts happening within those embeds.
Reserve space for late-loading content
When placing late-loading content in the content flow, layout shifts can be avoided by reserving the space for them in the initial layout.
One approach is to add a min-height
CSS rule to reserve space or—for responsive content such as ads, for example—use the aspect-ratio
CSS property in a similar manner to the way browsers automatically use this for images with dimensions provided.
You may need to account for subtle differences in ad or placeholder sizes across form factors using media queries.
For content that may not have a fixed height, like ads, you might not be able to reserve the exact amount of space needed to eliminate the layout shift entirely. If a smaller ad is served, a publisher can style a larger container to avoid layout shifts, or choose the most likely size for the ad slot based on historical data. The downside to this approach is that it increases the amount of blank space on the page.
You can instead set the initial size to the smallest size that will be used, and accept some level of shift for larger content. Using min-height
, as suggested previously, allows the parent element to grow as necessary while reducing the impact of layout shifts, compared to the 0px default size of an empty element.
Try to avoid collapsing the reserved space by showing a placeholder if, for example, no ad is returned. Removing the space set aside for elements can cause just as much CLS as inserting content.
Place late-loading content lower in the viewport
Dynamically injected content closer to the top of the viewport usually causes greater layout shifts than content injected lower in the viewport. However, injecting content anywhere in the viewport still causes some shift. If you can't reserve space for injected content, we recommend placing it later on the page to reduce the impact on its CLS.
Avoid inserting new content without a user interaction
You've probably experienced layout shifts due to UI that pops-in at the top or bottom of the viewport when you're trying to load a site. Similar to ads, this often happens with banners and forms that shift the rest of the page's content:
If you need to display these types of UI affordances, reserve sufficient space in the viewport for it in advance (for example, using a placeholder or skeleton UI) so that when it loads, it does not cause content in the page to surprisingly shift around. Alternatively, ensure the element is not part of the document flow by overlaying the content where this makes sense. See the Best practices for cookie notices post for more recommendations on these types of components.
In some cases adding content dynamically is an important part of user experience. For example, when loading more products to a list of items or when updating live feed content. There are several ways to avoid unexpected layout shifts in those cases:
- Replace the old content with the new content within a fixed size container or use a carousel and remove the old content after the transition. Remember to disable any links and controls until the transition has completed to prevent accidental clicks or taps while the new content is coming in.
- Have the user initiate the load of new content, so they are not surprised by the shift (for example with a "Load more" or "Refresh" button). It's recommended to prefetch the content before the user interaction so that it shows up immediately. As a reminder, layout shifts that occur within 500 milliseconds of user input are not counted towards CLS.
- Seamlessly load the content offscreen and overlay a notice to the user that it's available (for example, with a "Scroll to top" button).
![Examples of dynamic content loading without causing unexpected layout shifts from Twitter and the Chloé website](https://web.developers.google.cn/static/articles/optimize-cls/image/examples-dynamic-content-4d11ddda2fa94.png?hl=fa)
انیمیشن ها
Changes to CSS property values can require the browser to react to these changes. Some values, such as box-shadow
and box-sizing
, trigger re-layout, paint, and composite. Changing the top
and left
properties also cause layout shifts, even when the element being moved is on its own layer. Avoid animating using these properties.
Other CSS properties can be changed without triggering re-layouts. These include using transform
animations to translate, scale, rotate, or skew elements.
Composited animations using translate
can't impact other elements, and so don't count toward CLS. Non-composited animations also don't cause re-layout. To learn more about which CSS properties trigger layout shifts, see High-performance animations .
فونت های وب
Downloading and rendering web fonts is typically handled in one of two ways before the web font is downloaded:
- The fallback font is swapped with the web font, incurring a Flash of Unstyled Text (FOUT).
- "Invisible" text is displayed using the fallback font until a web font is available and the text is made visible (FOIT—flash of invisible text).
Both approaches can cause layout shifts . Even if the text is invisible, it's still laid out using the fallback font, so when the web font loads, the text block and the surrounding content shift in the same way as for the visible font.
The following tools can help you minimize shifting of text:
-
font-display: optional
can avoid a re-layout as the web font is only used if it is available by the time of initial layout. - Ensure the appropriate fallback font is used. For example, using
font-family: "Google Sans", sans-serif;
will ensure the browser'ssans-serif
fallback font is used while"Google Sans"
is loaded. Not specifying a fallback font using justfont-family: "Google Sans"
will mean the default font is used, which on Chrome is "Times"—a serif font which is a worse match than the defaultsans-serif
font. - Minimize the size differences between the fallback font and the web font using the new
size-adjust
,ascent-override
,descent-override
, andline-gap-override
APIs as detailed in the Improved font fallbacks post. - The Font Loading API can reduce the time it takes to get necessary fonts.
- Load critical web fonts as early as possible using
<link rel=preload>
. A preloaded font will have a higher chance to meet the first paint, in which case there's no layout shifting.
Read Best practices for fonts for other font best practices.
Reduce CLS by ensuring pages are eligible for the bfcache
A highly effective technique for keeping CLS scores low is to ensure your web pages are eligible for the back/forward cache (bfcache).
The bfcache keeps pages in browsers memory for a short period after you navigate away so if you return to them, then they will be restored exactly as you left them. This means the fully loaded page is instantly available—without any shifts which may be normally seen during load due to any of the reasons given earlier.
While this does potentially still mean the initial page load encounters layout shifts, when a user goes back through pages they are not seeing the same layout shifts repeatedly. You should always aim to avoid the shifts even on the initial load, but where that is more tricky to resolve fully, you can at least reduce the impact by avoiding them on any bfcache navigations.
Back and forward navigations are common on many sites. For example, returning to a contents page, or a category page, or search results.
When this was rolled out to Chrome , we saw noticeable improvements in CLS .
The bfcache is used by default by all browsers, but some sites are ineligible for the bfcache due to a variety of reasons. Read the bfcache guide for more details on how to test and identify any issues preventing bfcache usage to ensure you are making full use of this feature to help your overall CLS score for your site.
نتیجه گیری
There are a number of techniques to identify and improve CLS as detailed earlier in this guide. There are allowances built into Core Web Vitals, so even if you cannot eliminate CLS completely, using some of these techniques should allow you to reduce the impact. This will hopefully allow you to stay within those limits, creating a better experience for your website's users.