CLS Explained: Cumulative Layout Shift
Sahifa tez yuklanishi mumkin, lekin baribir buzilgandek taassurot qoldiradi. Siz matnni o‘qiy boshlaysiz, rasm paydo bo‘ladi, matn birdan pastga siljiydi va bosmoqchi bo‘lgan tugmangiz boshqa joyga ko‘chib qoladi. Cumulative Layout Shift (CLS) aynan shunday vizual beqarorlikni o‘lchaydi.
CLS — Largest Contentful Paint (LCP) va Interaction to Next Paint (INP) bilan birga Google’ning uchta Core Web Vitals ko‘rsatkichidan biri. Boshqa ikki metrikadan farqli ravishda, CLS millisekundlarda o‘lchanmaydi. U ko‘rinib turgan kontent qanchalik kutilmaganda siljiganini va bu siljish qanchalik sezilarli bo‘lganini ifodalovchi o‘lchov birligisiz qiymat beradi. (web.dev)
CLS nima?
Cumulative Layout Shift veb-sahifaning vizual barqarorligini ko‘rinib turgan kontentning kutilmagan siljishlarini o‘lchash orqali baholaydi.
Layout shift — ko‘rinib turgan element ikki render qilingan frame orasida boshlang‘ich joylashuvini o‘zgartirgan holat. CLS kutilmagan siljishlarni session windows deb ataladigan qisqa guruhlarga birlashtiradi va umumiy shift score eng katta bo‘lgan session window’ni hisobga oladi. (web.dev)
Oddiy misol: brauzer maqola sarlavhasi va matnini avval render qiladi, keyin esa tepada o‘lchami oldindan ajratilmagan rasm yuklanadi. Rasm joy egallaydi, maqolani pastga suradi va foydalanuvchi o‘qiyotgan joyini yana topishga majbur bo‘ladi.
Bu siljish CLS’ga ta’sir qiladi.
CLS bahosi
Google’ning amaldagi chegaralari:
| CLS | Baho |
|---|---|
| 0.10 yoki past | Yaxshi |
| 0.10 dan yuqori, 0.25 gacha | Yaxshilash kerak |
| 0.25 dan yuqori | Yomon |
Core Web Vitals baholashida Google sahifa tashriflarining 75-percentiliga qarashni va mobile hamda desktop tashriflarni alohida baholashni tavsiya qiladi. Amalda bu tashriflarning kamida 75 foizida CLS 0.10 yoki undan past bo‘lishi kerakligini anglatadi.
CLS o‘lchov birligiga ega emas. 0.1 qiymati 0.1 soniya degani emas. U kutilmagan vizual siljishlarning umumiy jiddiyligini ifodalaydi.
CLS nima uchun muhim?
Layout beqarorligi usability’ga bevosita ta’sir qiladi.
Siljish sabab foydalanuvchi matnda qayerda qolganini yo‘qotishi, forma elementi undan foydalanayotgan paytda joyini o‘zgartirishi yoki foydalanuvchi bosmoqchi bo‘lgan tugma o‘rniga tasodifan boshqa tugmani bosishi mumkin. Muammo ayniqsa sekin tarmoqlarda seziladi, chunki rasmlar, reklamalar, fontlar, API javoblari va third-party kontent local development’dagidan kechroq yuklanishi mumkin. (web.dev)
CLS qidiruv natijalari uchun ham ahamiyatli. Google Core Web Vitals’ni ranking tizimlarida ishlatiladigan signallardan biri sifatida ko‘rsatadi va Search hamda user experience uchun yaxshi Core Web Vitals natijalariga erishishni tavsiya qiladi. Biroq yaxshi CLS yuqoriroq ranking’ni kafolatlamaydi. Google ko‘plab signallarni hisobga oladi va Core Web Vitals page experience’ning faqat bir qismi hisoblanadi. (developers.google.com)
INTERNAL LINK: Core Web Vitals Explained
CLS qanday ishlaydi?
CLS alohida layout shift score’lardan boshlanadi.
Har bir tegishli shift uchun brauzer ikkita omilni baholaydi:
layout shift score = impact fraction × distance fraction
Impact fraction beqaror elementlar siljishdan oldin va keyin viewport’ning qanchalik katta qismini egallaganini ko‘rsatadi.
Distance fraction esa eng ko‘p siljigan beqaror element viewport’ning eng katta o‘lchamiga nisbatan qanchalik uzoqqa ko‘chganini o‘lchaydi. (web.dev)
Masalan, siljigan element viewport’ning 75 foiziga ta’sir qilsa va viewport’ning eng katta o‘lchamining 25 foiziga teng masofaga ko‘chsa:
0.75 × 0.25 = 0.1875
Bu hodisa uchun layout shift score 0.1875 bo‘ladi.
Session Windows
Hozirgi CLS sahifa mavjud bo‘lgan butun vaqt davomida yuz bergan barcha layout shift’larni oddiygina qo‘shib chiqmaydi.
Alohida kutilmagan shift’lar session windows ichiga birlashtiriladi. Bitta session window ichidagi shift’lar orasidagi vaqt bir soniyadan kam bo‘lishi kerak va session window ko‘pi bilan besh soniya davom etishi mumkin.
Sahifaning CLS qiymati eng katta session window ichidagi umumiy score hisoblanadi. (web.dev)
Bu yondashuv single-page applications va infinite-scroll interfeyslar kabi uzoq vaqt ochiq turadigan sahifalarni foydalanuvchi ularni ko‘proq vaqt ochiq qoldirgani uchungina avtomatik ravishda yomon baholashning oldini oladi.
Kutilgan siljishlar
Har qanday harakat CLS’ga ta’sir qilmaydi.
Click, tap yoki keypress kabi aniq foydalanuvchi harakatidan bevosita kelib chiqqan siljish, agar u shu harakatdan keyin 500 millisekund ichida sodir bo‘lsa, hisobga olinmasligi mumkin. Layout Instability API bu holatni hadRecentInput xususiyati orqali ko‘rsatadi. (web.dev)
Masalan, foydalanuvchi bosgandan keyin accordion darhol ochilsa, bu odatda kutilgan harakat hisoblanadi.
Lekin scrolling boshqacha ishlaydi. Scrolling kabi uzluksiz interaction’lar shu usulda hisobdan chiqarilmaydi. Agar lazy-loaded kontent foydalanuvchi scroll qilayotgan paytda mavjud kontentni birdan pastga sursa, bu siljish CLS’ga ta’sir qilishi mumkin.
CLS’ning asosiy sabablari
Eng ko‘p uchraydigan sabablar odatda juda oddiy.
O‘lchami ko‘rsatilmagan rasmlar
O‘lchami oldindan ma’lum bo‘lmagan rasm dastlab juda kam joy egallashi yoki umuman joy egallamasligi mumkin. Rasm yuklangach, brauzer uning o‘lchamini aniqlaydi va atrofdagi kontentni siljitadi.
HTML’da kerakli joyni oldindan ajrating:
<img
src="product.jpg"
width="1200"
height="800"
alt="Product"
>
Responsive CSS rasm o‘lchamini baribir moslashtira oladi:
img {
width: 100%;
height: auto;
}
Zamonaviy brauzerlar width va height atributlari orqali rasm to‘liq yuklanishidan oldin uning aspect ratio’sini aniqlashi mumkin. (web.dev)
Reklama va embed’lar
Reklamalar, video embed’lar, xaritalar, social widget’lar va iframe’lar ko‘pincha atrofdagi kontentdan keyin yuklanadi.
Agar ularning container’i dastlab balandlikka ega bo‘lmasa, kontent paydo bo‘lganda pastdagi barcha elementlar siljishi mumkin.
Joyni oldindan ajrating:
.video-wrapper {
aspect-ratio: 16 / 9;
}
Balandligi o‘zgaruvchan kontent uchun mos min-height yoki placeholder siljishni kamaytirishi mumkin. Reklama chiqmagan holatda rezerv qilingan joyni olib tashlashning o‘zi ham yangi layout shift keltirib chiqarishi mumkin, shuning uchun placeholder’larni ehtiyotkorlik bilan loyihalash kerak. (web.dev)
Dinamik kontent
Cookie bildirishnomalari, promo bannerlar, alert’lar, tavsiyalar va asinxron yuklanadigan komponentlar foydalanuvchi allaqachon ko‘rib turgan kontentning yuqorisiga qo‘shilsa, katta siljishlarga sabab bo‘lishi mumkin.
Yaxshiroq yechim — joyni oldindan ajratish yoki mos holatlarda komponentni document flow ichiga qo‘shish o‘rniga overlay sifatida ko‘rsatish.
Web Fonts
Fallback font va yakuniy web font belgilar kengligi, line height yoki boshqa metrikalarda farq qilishi mumkin. Asosiy font yuklanganda matn satrlari boshqacha o‘raladi va atrofdagi kontent siljishi mumkin.
Yechimlar orasida mosroq fallback font tanlash, muhim fontlarni ertaroq yuklash, font-display’dan to‘g‘ri foydalanish hamda fallback font metrikalarini size-adjust, ascent-override, descent-override va line-gap-override kabi xususiyatlar orqali moslashtirish bor. (web.dev)
Layout’ga ta’sir qiladigan animatsiyalar
top, left, width yoki height kabi xususiyatlarni animatsiya qilish layout’ni o‘zgartirishi mumkin.
Imkon bo‘lsa, compositor uchun qulayroq transform’lardan foydalaning:
.card {
transform: translateY(20px);
}
buning o‘rniga:
.card {
top: 20px;
}
transform: translate() yoki transform: scale() elementni vizual ravishda siljitishi mumkin va shu turdagi layout shift’ni keltirib chiqarmaydi. (web.dev)
CLS’ni qanday o‘lchash kerak?
Avvalo field data’dan boshlang.
Chrome UX Report (CrUX) CLS’ni ham o‘z ichiga olgan, real foydalanuvchilardan yig‘ilgan agregat Core Web Vitals ma’lumotlarini taqdim etadi. Yetarli ma’lumot mavjud bo‘lsa, PageSpeed Insights CrUX field data’ni ko‘rsatishi mumkin, Search Console esa sahifalarni Core Web Vitals report orqali guruhlaydi. CrUX CLS’ni 75-percentilda ko‘rsatadi va uni o‘lchov birligisiz metrika sifatida baholaydi. (developer.chrome.com)
Keyin muammoni tahlil qilish uchun lab tools’dan foydalaning.
Chrome DevTools’dagi Performance panel individual layout shift’larni ko‘rsatadi va ularni cluster’larga birlashtiradi. Shift score’lar, ta’sirlangan elementlar, timing, screenshot’lar va ehtimoliy sabablarni ko‘rish mumkin. Chrome’dagi Rendering vositalari ham layout-shift hududlarini vizual tarzda ajratib ko‘rsatishi mumkin. (developer.chrome.com)
Foydali workflow:
Field CLS yomon → sahifani qayta yaratish → eng katta shift cluster’ni topish → siljigan elementlarni tekshirish → siljishga sabab bo‘lgan elementni aniqlash → tuzatish → qayta o‘lchash.
Siljigan elementning o‘zi muammo sababi deb o‘ylamang. Masalan, paragraph uning yuqorisidagi reklama, rasm, banner yoki boshqa komponent o‘lchamini o‘zgartirgani uchun siljishi mumkin. (web.dev)
Lab CLS va Field CLS
Debugging’da keng tarqalgan xatolardan biri — Lighthouse’dagi CLS bilan real foydalanuvchilardagi CLS aynan bir xil bo‘lishini kutish.
Ular turli holatlarni o‘lchaydi.
Oddiy Lighthouse testi asosan sahifaning dastlabki yuklanishini kuzatadi. Real foydalanuvchilar esa scrolling qilishi, menyularni ochishi, qo‘shimcha mahsulotlarni yuklashi, route change’larni ishga tushirishi yoki sahifani bir necha daqiqa ochiq qoldirishi mumkin. Shu sababli keyinroq yuz beradigan kutilmagan siljishlar CrUX’da ko‘rinishi mumkin, oddiy Lighthouse load testi esa barqaror natija ko‘rsatishi mumkin. (web.dev)
Agar lab CLS past, field CLS esa yuqori bo‘lsa, page load’dan keyingi interaction va scrolling behavior’ni tekshiring.
INTERNAL LINK: Lab Data vs Field Data
CLS debugging
Murakkab holatlarda Chromium Layout Instability API orqali layout shift’lar haqida ma’lumot beradi:
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
if (!entry.hadRecentInput) {
console.log('Layout shift:', entry.value, entry.sources);
}
}
}).observe({
type: 'layout-shift',
buffered: true
});
Bu individual shift’larni debugging qilish uchun foydali, lekin CLS metrikasining to‘liq implementatsiyasi emas. CLS’ni to‘g‘ri hisoblash uchun shift’larni session windows ichiga guruhlash va qo‘shimcha lifecycle holatlarini hisobga olish kerak. Production Real User Monitoring uchun to‘liq metrikani o‘zingiz qayta implementatsiya qilishdan ko‘ra web-vitals kutubxonasidan foydalanish odatda xavfsizroq. (web.dev)
Keng tarqalgan noto‘g‘ri tushunchalar
“CLS yuklanish tezligini o‘lchaydi.” Yo‘q. CLS vizual barqarorlikni o‘lchaydi. Sahifa tez yuklanishi mumkin, lekin CLS juda yomon bo‘lishi mumkin.
“Har qanday siljish CLS’ni oshiradi.” Yo‘q. CLS kutilmagan layout shift’larni hisobga oladi. Foydalanuvchining aniq interaction’i bilan bevosita bog‘liq ayrim shift’lar hisobdan chiqariladi.
“Lighthouse’da CLS 0 bo‘lsa, foydalanuvchilarda ham CLS 0 bo‘ladi.” Shart emas. Post-load shift’lar field data’da ko‘rinishi mumkin, lekin oddiy synthetic page-load testida umuman yuz bermasligi mumkin.
“Siljigan element muammoning sababidir.” Har doim ham emas. Uni boshqa element surib yuborgan bo‘lishi mumkin.
SeoNest tavsiyasi
CLS’ga development tugagandan keyin yaxshilanadigan oddiy score sifatida emas, layout architecture muammosi sifatida qarang.
Media va third-party komponentlar uchun joyni ular yuklanishidan oldin ajrating. Asinxron UI’ni shunday loyihalangki, kontent yuklanishi mavjud elementlarni kutilmaganda siljitmasin. Sahifalarni faqat initial load vaqtida emas, real network sharoiti va foydalanuvchi flow’lari bilan ham test qiling.
Production saytlar uchun field monitoring va DevTools debugging’ni birga ishlating. Field data sizga real foydalanuvchilar beqarorlikka duch kelayotganini ko‘rsatadi; diagnostika vositalari esa nega bunday bo‘layotganini aniqlashga yordam beradi.
FAQ
CLS Core Web Vitals tarkibiga kiradimi?
Ha. CLS — vizual barqarorlikni o‘lchaydigan Core Web Vital. Qolgan amaldagi Core Web Vitals — loading performance uchun LCP va responsiveness uchun INP. (developers.google.com)
Qanday CLS yaxshi hisoblanadi?
Sahifa tashriflarining 75-percentilida 0.10 yoki undan past CLS yaxshi hisoblanadi. (web.dev)
CLS soniyalarda o‘lchanadimi?
Yo‘q. CLS o‘lchov birligisiz score hisoblanadi.
Lazy loading CLS’ni yomonlashtirishi mumkinmi?
Lazy loading’ning o‘zi muammo bo‘lishi shart emas. CLS lazy-loaded kontent uchun oldindan yetarli joy ajratilmaganida yuz beradi.
CLS sahifa yuklangandan keyin ham yuz berishi mumkinmi?
Ha. Kutilmagan shift’lar scrolling, dynamic content update, SPA transition yoki boshqa post-load holatlarida ham yuz berishi mumkin. Shu sababli field CLS Lighthouse CLS’dan yuqori bo‘lishi mumkin. (web.dev)
Yakuniy xulosa
CLS oddiy savolga javob beradi: sahifa foydalanuvchi kutgan joyida qoladimi?
Yaxshi CLS uchun sahifani butunlay statik qilish shart emas. Zamonaviy interfeyslar kontentni dinamik yuklashi, elementlarni animatsiya qilishi va foydalanuvchi harakatlariga javob berishi mumkin. Asosiy tamoyil — oldindan bashorat qilinadigan xatti-harakat: kontent kelishidan oldin joy ajrating, mavjud kontentni kutilmaganda siljitmang va natijani real foydalanuvchi ma’lumotlari bilan tekshiring.
Layout boshidan barqaror qilib qurilsa, yaxshi CLS odatda tabiiy natija bo‘ladi.
Sources
- web.dev — Cumulative Layout Shift (CLS). Last updated April 12, 2023. Cumulative Layout Shift (CLS) (web.dev)
- web.dev — Optimize Cumulative Layout Shift. Published May 5, 2020; updated February 7, 2025. Optimize Cumulative Layout Shift (web.dev)
- web.dev — Debug layout shifts. Published March 11, 2021; updated February 7, 2025. Debug layout shifts (web.dev)
- Google Search Central — Understanding Core Web Vitals and Google search results. Last updated December 10, 2025. Google Search Central Core Web Vitals documentation (developers.google.com)
- Chrome for Developers — Chrome UX Report: Metrics. Published June 23, 2022; updated September 15, 2026. Chrome UX Report Metrics (developer.chrome.com)
- Chrome for Developers — Performance features reference. Chrome DevTools Performance reference (developer.chrome.com)
