cumulative layout shift: मोबाइल पर CLS ढूँढें और ठीक करें

cumulative layout shift (CLS) नापता है कि पेज खुला रहने के दौरान दिखने वाला content कितना अनचाहे तरीके से खिसका। visits के 75वें percentile पर 0.1 या उससे कम अच्छा है (web.dev, अप्रैल 2023)। 0.25 से ऊपर खराब है। फ़ोन पर आम कारण हैं: बिना आयाम वाली images, बिना जगह छोड़े लगे ads और embeds, ऊपर से डाले गए banners और cookie notices, देर से आने वाले web fonts, और layout को हिलाने वाले animations। DevTools में खिसका element ढूँढें, फिर उसके लोड होने से पहले उसकी जगह रिज़र्व करें।

cumulative layout shift क्या है

CLS पेज के जीवनकाल में layout shifts का सबसे बड़ा गुच्छा है, सभी shifts का योग नहीं। हर shift का स्कोर impact fraction गुणा distance fraction होता है। impact fraction वह हिस्सा है जो खिसके हुए elements viewport का घेरते हैं, और distance fraction वह अधिकतम दूरी है जितनी कोई element खिसकी, viewport की सबसे बड़ी भुजा से भाग देकर। एक सेकंड से कम के अंतर वाले shifts को अधिकतम 5 सेकंड की session window में समूहित किया जाता है, और CLS वह window है जिसका स्कोर सबसे ज़्यादा हो (web.dev)। उपयोगकर्ता के input के 500 ms के भीतर शुरू होने वाले shifts बाहर रखे जाते हैं (web.dev, Optimize CLS, फ़रवरी 2025)।

ये Google द्वारा तय “अच्छे स्कोर” की सीमाएँ हैं, और web.dev सलाह देता है कि mobile और desktop का 75वाँ percentile अलग-अलग देखें।

फ़ोन पर CLS क्यों कठिन है

वही खिसकना छोटी स्क्रीन पर ऊँचा स्कोर देता है, क्योंकि दोनों fractions viewport के सापेक्ष नापे जाते हैं, और फ़ोन की सबसे बड़ी भुजा छोटी होती है। ऊपर के सूत्र से एक उदाहरण: मान लीजिए 390 × 844 px के viewport में, जो content से भरा है, पेज के ऊपर 80 px ऊँचा cookie banner आता है और सब कुछ नीचे धकेल देता है। viewport का लगभग पूरा क्षेत्र प्रभावित है, इसलिए impact fraction लगभग 1.0 है, और distance fraction 80 / 844 = 0.095 है। स्कोर लगभग 0.095 है, यानी 0.1 की सीमा से बस एक banner दूर। यह एक समझाने वाला उदाहरण है, और यह मानता है कि content viewport को भरता है।

कारण desktop जैसे ही हैं, बस छोटे क्षेत्र पर स्कोर होते हैं। web.dev बताता है कि ads के आकार अलग-अलग device types पर अलग हो सकते हैं, इसलिए desktop आकार के लिए रिज़र्व की गई जगह फ़ोन पर गलत हो सकती है।

CLS सभी browsers में नहीं नापा जाता। web-vitals library onCLS() को केवल Chromium में बताती है, जबकि उसके बाकी functions Firefox और Safari में भी चलते हैं (web-vitals README)। web-features 3.44.0 (अक्टूबर 2026) भी Layout Instability API को केवल Chrome और Edge में दिखाता है। इसलिए उस library से field में जमा किया गया CLS Chromium browsers को कवर करता है, और iPhone पर Safari से आई visit उसके ज़रिए कोई CLS रिपोर्ट नहीं करती।

मोबाइल पर क्या खिसकता है और उसे कैसे ठीक करें

हर कारण का एक सुधार है जो सामग्री आने से पहले जगह रिज़र्व करता है। web.dev की CLS optimization गाइड (फ़रवरी 2025) के अनुसार:

images और videos

हर image पर उसका मूल आकार दें, ताकि फ़ाइल आने से पहले browser box रिज़र्व कर सके:

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

img {
  height: auto;
  width: 100%;
}

responsive images के लिए web.dev कहता है कि srcset के सभी candidates में एक जैसा aspect ratio रखें, और <picture> के लिए हर <source> और <img> पर width और height दें। नया image format केवल फ़ाइल का आकार बदलता है, इसलिए यह समस्या हल नहीं करता; <picture> का pattern WebP vs AVIF में है। aspect-ratio मार्च 2024 से व्यापक रूप से उपलब्ध Baseline है (web-features 3.44.0)।

ads, embeds और banners

अपेक्षित सबसे छोटे आकार के हिसाब से slot की जगह रिज़र्व करें, और जहाँ फ़ोन पर आकार अलग हो वहाँ media query लगाएँ:

.ad-slot { min-height: 250px; }
@media (min-width: 768px) {
  .ad-slot { min-height: 90px; }
}

दो ऊँचाइयाँ उदाहरण हैं; अपने ad आकार इस्तेमाल करें। web.dev तीन सुझाव देता है: अपेक्षित सबसे छोटे आकार को न्यूनतम मानें; कोई ad न आए तो जगह सिकोड़ने के बजाय placeholder दिखाएँ; और देर से लोड होने वाला content viewport में नीचे रखें, क्योंकि ऊपर के पास डाला गया content बड़े shifts करता है। cookie notice के लिए उसे overlay बनाएँ, या पहली paint से उसकी ऊँचाई रिज़र्व करें, न कि तब पेज नीचे धकेलें जब कोई script उसे दिखाने का फ़ैसला करे।

web fonts

web.dev के अनुसार, दोनों तरह की flashes, invisible text और unstyled text, shifts पैदा कर सकती हैं, क्योंकि invisible text भी fallback font से layout होता है। web.dev font-display: optional, पास का fallback font, आकार-मेल वाले fallback metrics और ज़रूरी fonts का preload सुझाता है। values, preload और fallback का कोड font-display swap गाइड में है।

animations और back button

transform से animate करें, क्योंकि वह layout trigger नहीं करता; web.dev बताता है कि composited translate animations CLS में नहीं गिने जाते। पेजों को back/forward cache के योग्य भी बनाएँ, क्योंकि restore हुआ पेज वैसा ही दिखता है जैसा उपयोगकर्ता उसे छोड़ गया था, बार-बार load होने वाले shifts के बिना। यह पहले load में मदद नहीं करता।

layout shifts कैसे ढूँढें

lab tools से element पहचानें, और field data से देखें कि असली उपयोगकर्ताओं को यह हो रहा है या नहीं। web.dev ये रास्ते बताता है:

1. PageSpeed Insights: field CLS (Chrome UX Report से) की तुलना Lighthouse के lab CLS से करें। बड़ा अंतर आम तौर पर load के बाद के shifts की ओर इशारा करता है, जिन्हें lab run नहीं देखता।
2. Lighthouse: इसके audits खिसके elements और उनका योगदान सूचीबद्ध करते हैं, पर अक्सर प्रभावित element दिखाते हैं, मूल कारण नहीं।
3. DevTools का Performance panel: trace रिकॉर्ड करें और Layout shifts track खोलें। बैंगनी पट्टियाँ shift गुच्छों को दिखाती हैं, बड़ा हीरा बड़े shift को, और Summary में शुरू होने का समय, स्कोर और खिसके elements दिखते हैं। Layout shift culprits insight कुल CLS और संभावित कारण सूचीबद्ध करता है (web.dev)।

असली visitors के लिए कौन सा element खिसका, यह जानने के लिए web-vitals का attribution build जोड़ें, जो सबसे बड़े shift का target, समय और मान रिपोर्ट करता है:

import {onCLS} from 'web-vitals/attribution';

onCLS(({value, rating, attribution}) => {
  console.log(rating, value, {
    target: attribution.largestShiftTarget,
    time: attribution.largestShiftTime,
    score: attribution.largestShiftValue,
  });
});

web.dev के अनुसार iframe के भीतर के shifts web APIs से नहीं नापे जा सकते, पर वे Chrome UX Report में दिखते हैं। Lighthouse और दूसरे tools कैसे चलाएँ, यह Lighthouse मोबाइल audit गाइड और मोबाइल पेज स्पीड टेस्ट गाइड में है।

फ़ोन-आकार पर layout जाँचें

desktop और फ़ोन के बीच अलग layout फ़ोन की चौड़ाई पर सबसे आसानी से पकड़ में आता है। Mobile View Extension tab को फ़ोन के user agent, screen size और pixel ratio के साथ दोबारा लोड करता है, इसलिए आप पेज का mobile version देख सकते हैं और लोड होते समय क्या हिलता है, यह देख सकते हैं। यह CLS या किसी speed metric को नहीं नापता, और आपके desktop connection पर चलता है, इसलिए धीमे फ़ोन पर पेज को हिलाने वाला banner या ad यहाँ इतनी तेज़ी से लोड हो सकता है कि दिखे ही नहीं। ऊपर के tools से पुष्टि करें। पेज फ़ोन पर अलग दिखने के दूसरे कारणों के लिए वेबसाइट मोबाइल पर अलग क्यों दिखती है देखें।

अक्सर पूछे जाने वाले सवाल

CLS का अच्छा स्कोर क्या है?

0.1 या उससे कम अच्छा है, और 0.25 से ऊपर खराब है। यह पेज लोड के 75वें percentile पर नापा जाता है (web.dev, अप्रैल 2023)। 0.1 और 0.25 के बीच की सीमा को सुधार की ज़रूरत है।

फ़ोन पर layout shift के कारण क्या हैं?

बिना आयाम वाली images और videos, बिना जगह रिज़र्व किए ads, embeds और iframes, डाले गए banners और cookie notices, ऐसे web fonts जो fallback से बड़े या छोटे दिखते हैं, और layout properties बदलने वाले animations। वही हरकत फ़ोन पर ज़्यादा स्कोर देती है, क्योंकि अनुपात छोटे viewport के सापेक्ष नापे जाते हैं।

CLS का कारण कैसे ढूँढूँ?

DevTools के Performance panel में trace रिकॉर्ड करें और Layout shifts track खोलें, फिर Summary में खिसके elements देखें। असली visitors के लिए web-vitals का attribution build इस्तेमाल करें, ताकि वह largestShiftTarget रिपोर्ट करे।

क्या CLS SEO को प्रभावित करता है?

Google कहता है कि Search में सफलता के लिए अच्छे Core Web Vitals सुझाए जाते हैं, और वे उस चीज़ से मेल खाते हैं जिसे उसके core ranking systems पुरस्कृत करना चाहते हैं; पर वह इन्हें सीधा ranking factor नहीं कहता (Google Search Central, दिसंबर 2025 अपडेट)। सीधा असर उन visitors पर पड़ता है जो पेज कूदने पर अपनी जगह खो देते हैं।