آوین آویسا – خدمات سئو | فروشگاه اختصاصی | بلاک چین و رمزارزها
  • صفحه اصلی
  • خدمات ما
    • خدمات فروشگاه اختصاصی
    • خدمات سئو
    • خدمات بلاک‌چین و رمزارزها
    • خدمات ربات معامله‌گر
  • آخرین پروژه‌ها
  • وبلاگ
  • تازه های تکنولوژی
  • درباره ما
  • تماس با ما
  • English
آوین آویسا – خدمات سئو | فروشگاه اختصاصی | بلاک چین و رمزارزها

معیار تغییر تجمعی چیدمان (CLS) چیست؟

خانه / صفحه وبلاگ / سئو / معیار تغییر تجمعی چیدمان (CLS) چیست؟

معیار تغییر تجمعی چیدمان (CLS) چیست؟

توسط نویسنده آوین آویسا درسئو

آیا تا به حال مقاله‌ای را به صورت آنلاین خوانده‌اید که ناگهان چیزی در صفحه تغییر کند؟ بدون هشدار، متن حرکت می‌کند و مکان مطلبی که در حال مطالعه بودید، تغییر می‌کند. یا حتی بدتر: شما در حال ضربه زدن روی یک پیوند یا یک دکمه هستید، اما بلافاصله قبل از فرود آمدن انگشت خود – BOOM – پیوند حرکت می‌کند، و در آخر بر روی چیز دیگری کلیک می‌کنید! معیار تغییر تجمعی چیدمان (CLS) به ما کمک می‌کند تا این مشکل را بررسی و حل نماییم.

بیشتر اوقات این نوع تجربه ها فقط آزاردهنده هستند، اما در بعضی موارد می‌توانند آسیب واقعی ایجاد کنند.

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

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

معیار تغییر تجمعی چیدمان (CLS) به شما کمک می‌کند تا با اندازه‌گیری میزان بروز آن برای کاربران واقعی این مشکل را برطرف کنید.

معیار تغییر تجمعی چیدمان (CLS) چیست؟

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

هر زمان که عنصر قابل رویت موقعیت خود را از یک قاب ارائه شده به قاب دیگر تغییر می‌دهد، تغییر طرح‌بندی رخ می‌دهد.

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

بزرگترین شیفت پنجره جلسه‌ای با حداکثر نمره تجمعی از همه تغییرات طرح‌بندی در آن پنجره است.

امتیاز مناسب برای معیار تغییر تجمعی چیدمان (CLS) چیست؟

برای ارائه یک تجربه کاربری خوب، سایت‌ها باید تلاش کنند که نمره ۰.۱ یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای بیشتر کاربران، یک آستانه خوب برای اندازه‌گیری، رسیدن به این آستانه در ۷۵ درصد بار بارگیری صفحه است که در دستگاه‌های تلفن همراه و دسکتاپ اتفاق می‌افتد.

جزییات تغییرات چیدمان

شیفت‌های چیدمان توسط Layout Instability API تعریف می‌شوند، که گزارشات ورودی layout-shift را گزارش می‌دهد، هرگاه عنصری که در ویوپورت قابل مشاهده است، موقعیت آغازین خود را تغییر دهد. چنین عناصری، عناصر ناپایدار محسوب می‌شوند.

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

امتیاز تغییر چیدمان

برای محاسبه نمره تغییر طرح، مرورگر به اندازه Viewport و حرکت عناصر ناپایدار در Viewport بین دو فریم ارائه شده نگاه می‌کند. نمره تغییر طرح نتیجه ضرب دو اندازه‌گیری از آن حرکت است: نسبت تأثیر و نسبت فاصله (هر دو در زیر تعریف شده اند).

1
<span style="font-family: Liberation Mono, serif; color: #000000;"><span lang="en-US"><code class="western"><span lang="fa-IR">layout shift score = impact fraction * distance fraction</span></code></span></span>

نسبت تاثیر

نسبت تاثیر چگونگی تأثیر عناصر ناپایدار بر فضای نمای بین دو قاب را اندازه می‌گیرد.

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

در تصویر بالا عنصری وجود دارد که نیمی از نمای در یک قاب را اشغال می‌کند. سپس، در فریم بعدی، عنصر 25٪ از ارتفاع viewport به سمت پایین حرکت می‌کند. مستطیل قرمز نشانگر اجتماع ناحیه قابل مشاهده عنصر در هر دو قاب است که در این حالت 75٪ کل viewport است، بنابراین نسبت تأثیر آن 0.75 است.

نسبت فاصله

قسمت دیگر معادله نمره تغییر طرح، فاصله‌ای را که عناصر ناپایدار نسبت به viewport حرکت کرده‌اند را اندازه‌گیری می‌کند. نسبت فاصله بزرگترین مسیری است که هر عنصر ناپایداری در قاب حرکت کرده است (به صورت افقی یا عمودی) تقسیم بر بزرگترین بعد viewport (عرض یا ارتفاع، هر کدام که بیشتر باشد).

مثال ۱:

 

در مثال بالا، بزرگترین بعد viewport ارتفاع است و عنصر ناپایدار ۲۵٪ از ارتفاع viewport حرکت کرده است که نسبت فاصله را ۰.۲۵ می‌کند. بنابراین، در این مثال نسبت ضربه ۰.۷۵ و نسبت فاصله ۰.۲۵ است، بنابراین نمره تغییر طرح ۰.۷۵ * ۰.۲۵ = ۰.۱۸۷۵ است.

مثال ۲:

مثال بعدی نشان می‌دهد که چگونه افزودن محتوا به یک عنصر موجود روی امتیاز تغییر طرح تأثیر می‌گذارد:

دکمه “Click Me!” در انتهای جعبه خاکستری با متن سیاه اضافه شده است، که جعبه سبز با متن سفید را به پایین (و تا حدی خارج از نمای نمایشگر) حرکت می‌دهد.

در این مثال، جعبه خاکستری تغییر اندازه می‌دهد، اما موقعیت آغازین آن تغییر نمی‌کند بنابراین عنصر ناپایداری نیست.

دکمه “Click Me!” قبلا در DOM نبود، بنابراین موقعیت آغازین آن نیز تغییر نمی‌کند.

موقعیت آغازین جعبه سبز تغییر می‌کند، اما از آنجایی که قسمتی از قسمت دید خارج شده است، هنگام محاسبه نسبت ضربه، منطقه پنهان‌شده در نظر گرفته نمی‌شود. اجتماع نواحی قابل‌مشاهده برای جعبه سبز در هر دو قاب (با مستطیل قرمز نشان داده شده است) همان مساحت جعبه سبز در قاب اول است – ۵۰٪ viewport. نسبت ضربه ۰.۵ است.

نسبت فاصله با فلش بنفش نشان داده شده است. جعبه سبز حدود ۱۴٪ از viewport به سمت پایین حرکت کرده بنابراین کسر فاصله ۰.۱۴ است.

نمره تغییر طرح ۰.۱۴ *۰.۵ = ۰.۰۷ است.

مثال ۳:

مثال بعدی چندین عنصر ناپایدار را نشان می‌دهد:

در اولین قاب بالا، چهار نتیجه درخواست API برای حیوانات وجود دارد که به ترتیب حروف الفبا مرتب شده‌اند. در فریم دوم، نتایج بیشتری به لیست مرتب‌شده اضافه می‌شوند.

اولین مورد در لیست (“Cat“) موقعیت آغازین خود را بین قاب‌ها تغییر نمی‌دهد، بنابراین پایدار است. به همین ترتیب، موارد جدید اضافه شده به لیست قبلاً در DOM نبودند، بنابراین موقعیت‌های آغازین آن‌ها نیز تغییر نمی‌کند. اما مواردی با برچسب “Dog” ،“Horse” و “Zebra” همه موقعیت‌های آغازین خود را تغییر می‌دهند و آن‌ها را به عناصر ناپایدار تبدیل می‌‌شوند.

مجدداً، مستطیل‌های قرمز نشان‌دهنده اجتماع این سه عنصر ناپایدار در مناطق قبل و بعد از آن است که در این حالت حدود ۳۸٪ viewport (نسبت تأثیر ۰.۳۸) است.

پیکان‌ها فاصله‌هایی را نشان می‌دهند که عناصر ناپایدار از موقعیت آغازین خود حرکت کرده‌اند. عنصر “Zebra” ، که با پیکان آبی نشان داده شده است، با حدود ۳۰٪ حرکت در ارتفاع viewport، بیشترین حرکت را داشته است. در نتیجه، نسبت فاصله در این مثال ۰.۳ است.

نمره تغییر طرح ۰.۳ * ۰.۳۸ = ۰.۱۱۷۲ است.

تغییرات چیدمان قابل‌پیش‌بینی در مقابل غیرقابل‌ پیش‌‌بینی

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

چیدمانی که توسط کاربر تغییر می‌کند

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

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

شیفت‌های چیدمانی که در فاصله 500 میلی ثانیه از ورودی کاربر رخ می‌دهد، دارای پرچم hadRecentInput می‌باشد، بنابراین می‌توان آن‌ها را از محاسبات خارج کرد.

انیمیشن و انتقال

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

ویژگی transform در CSS به شما امکان می‌دهد تا عناصر را جابجا کنید بدون اینکه تغییراتی در طرح ایجاد کنید:

  • به جای تغییر خصوصیات ارتفاع و عرض، از transform: scale () استفاده کنید.

  • برای جابجایی عناصر به اطراف، از تغییر خصوصیات بالا، راست، پایین یا چپ خودداری کنید و به جای آن از transform: translate () استفاده کنید.

تغییر تجمعی چیدمان (CLS) چگونه اندازه‌گیری می‌شود؟

CLS را می‌توان در آزمایشگاه یا به طور عملیاتی اندازه‌گیری کرد. ابزارهای زیر در دسترس هستند:

ابزار عملیاتی:

  • Chrome User Experience Report

  • PageSpeed Insights

  • Search Console (Core Web Vitals report)

  • web-vitals JavaScript library

ابزار آزمایشگاهی:

  • Chrome DevTools

  • Lighthouse

  • WebPageTest

اندازه‌گیری CLS در جاوااسکریپت

برای اندازه‌گیری CLS در JavaScript، می توانید از Layout Instability API استفاده کنید. مثال زیر نحوه ایجاد یک PerformanceObserver را نشان می‌دهد که ورودی‌های غیر منتظره layout-shift را گوش می‌دهد، آن‌ها را در جلسات گروه‌بندی می‌کند و هر زمان تغییر کند حداکثر مقدار جلسه را ثبت می‌کند.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
let clsValue = 0;
let clsEntries = [];
let sessionValue = 0;
let sessionEntries = [];
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    // Only count layout shifts without recent user input.
    if (!entry.hadRecentInput) {
      const firstSessionEntry = sessionEntries[0];
      const lastSessionEntry = sessionEntries[sessionEntries.length - 1];
      // If the entry occurred less than 1 second after the previous entry and
      // less than 5 seconds after the first entry in the session, include the
      // entry in the current session. Otherwise, start a new session.
      if (sessionValue &&
          entry.startTime - lastSessionEntry.startTime < 1000 &&
          entry.startTime - firstSessionEntry.startTime < 5000) {
        sessionValue += entry.value;
        sessionEntries.push(entry);
      } else {
        sessionValue = entry.value;
        sessionEntries = [entry];
      }
      // If the current session value is larger than the current CLS value,
      // update CLS and the entries contributing to it.
      if (sessionValue > clsValue) {
        clsValue = sessionValue;
        clsEntries = sessionEntries;
        // Log the updated value (and its entries) to the console.
        console.log('CLS:', clsValue, clsEntries)
      }
    }
  }
}).observe({type: 'layout-shift', buffered: true});

در بیشتر موارد، مقدار فعلی CLS در زمان بارگیری صفحه، مقدار نهایی CLS برای آن صفحه است، اما چند استثنا مهم وجود دارد:

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

تفاوت‌های بین معیار و API
  • اگر صفحه‌ای در پس‌زمینه بارگیری می شود یا قبل از اینکه مرورگر هر محتوایی را ارائه کند، پس‌زمینه دارد، نباید هیچ مقدار CLS را گزارش کند.

  • هنگام بازگرداندن صفحه از کش بک/ فرانت، مقدار CLS آن باید به صفر برسد زیرا کاربران این کار را به عنوان یک بازدید متمایز از صفحه تجربه می‌کنند.

  • API، ورودی‌هایی را که درون iframes رخ می‌دهند گزارش نمی‌کند، اما برای اندازه‌گیری صحیح CLS باید آنها را در نظر بگیرید. فریم‌های فرعی می‌توانند با استفاده از API ورودی‌های layout-shift خود را برای تجمیع در فریم والد گزارش دهند.

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

  • کاربران ممکن است یک تب را برای مدت زمان طولانی – روزها، هفته‌ها، ماه‌ها – باز نگه دارند. در واقع، یک کاربر ممکن است هرگز یک تب را نبندد.

  • در سیستم عامل‌های تلفن همراه، مرورگرها معمولاً برگشت بارگیری صفحه را برای تب‌های پس‌زمینه اجرا نمی‌کنند، بنابراین گزارش نمره “نهایی” دشوار است.

برای رسیدگی به چنین مواردی، CLS باید هر زمان که یک صفحه پس‌زمینه است هم گزارش شود – علاوه بر هر زمان بارگیری آن (رویداد visibilitychange هر دو سناریو را پوشش می‌دهد). سپس سیستم‌های تحلیلی دریافت‌کننده این داده‌ها باید مقدار CLS نهایی را در قسمت بک‌اند محاسبه کنند.

توسعه‌دهندگان به جای اینکه همه این تفاوت‌های ظریف را بخاطر بسپارند، می‌توانند برای اندازه‌گیری CLS از کتابخانه جاوا اسکریپت web-vitals استفاده کنند که این اختلافات را برای شما کنترل می‌کند (در صورت امکان).

1
2
3
4
import {getCLS} from 'web-vitals';
// Measure and log CLS in all situations
// where it needs to be reported.
getCLS(console.log);

نحوه بهینه‌سازی CLS

درمقاله جداگانه با جزییات تمام نحوه بهینه‌سازی CLS شرح داده شده است.

منبع:

https://web.dev/cls/

CLSCore Web Vitals
  • بهینه سازی بزرگترین عنصر محتوا (LCP)
    قبلی نوشتهبهینه سازی بزرگترین عنصر محتوا (LCP)
  • بعدی نوشتهمعیار تأخیر ورودی اول (FID) چیست؟
    بهینه سازی بزرگترین عنصر محتوا (LCP)

دیدگاهتان را بنویسید (لغو پاسخ)

آدرس ایمیل شما منتشر نخواهد شد. فیلدهای مورد نیاز علامت گذاری شده اند *

*
*

Copy