Core Web Vitals: गति और अनुभव को अनुकूलित करें
8 min
Core Web Vitals (LCP, INP, CLS) Google के आधिकारिक रैंकिंग कारक हैं। 2.5 सेकंड से कम LCP, 200 ms से कम INP और 0.1 से कम CLS 'अच्छे' स्कोर की सीमाएं हैं। पहली प्राथमिकता: इमेज अनुकूलित करें और गैर-जरूरी JavaScript को स्थगित करें।
2021 से Google ने Core Web Vitals को अपने रैंकिंग एल्गोरिदम में शामिल किया है। 2026 में, ये मेट्रिक्स केवल पोजीशन ही नहीं, बल्कि मोबाइल rich results की पात्रता भी तय करती हैं। इन्हें कैसे नियंत्रित करें, यहां जानें।
तीन मेट्रिक्स जो वास्तव में मायने रखती हैं
Google ने वास्तविक उपयोगकर्ता अनुभव मापने के लिए तीन संकेत चुने हैं: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) और CLS (Cumulative Layout Shift)। प्रत्येक कथित गुणवत्ता के एक अलग पहलू को मापता है।
INP ने मार्च 2024 में FID की जगह ली; यह पेज पर सभी इंटरैक्शन की वैश्विक प्रतिक्रियाशीलता मापता है, जबकि FID केवल पहले क्लिक को ही कैप्चर करता था।
- LCP: सबसे बड़े दृश्यमान तत्व के रेंडर होने तक का समय। अच्छी सीमा: 2.5 सेकंड से कम।
- INP: कीबोर्ड/माउस/टच इंटरैक्शन की प्रतिक्रिया देरी। अच्छी सीमा: 200 ms से कम।
- CLS: पेज लेआउट की दृश्य अस्थिरता। अच्छी सीमा: 0.1 से कम।
खराब प्रदर्शन के सामान्य कारण
खराब LCP अक्सर बिना प्रीलोड की गई हीरो इमेज, धीमे सर्वर या क्लाइंट-साइड रेंडरिंग (SSR अनुपस्थित) से आता है। मुख्य इमेज को टार्गेट करने वाला <link rel='preload'> टैग अक्सर इस स्कोर को 30 से 50% तक कम करता है।
CLS लगभग हमेशा स्पष्ट आयामों के बिना इमेज, लोडिंग के बाद दिखने वाले वेब फ़ॉन्ट या पेज के शीर्ष पर डायनामिक रूप से इंजेक्ट किए गए बैनर के कारण होता है।
INP के मुख्य दोषी तृतीय-पक्ष स्क्रिप्ट हैं (analytics, chat, विज्ञापन) जो मुख्य थ्रेड को ब्लॉक करती हैं और क्लिक प्रतिक्रिया में देरी करती हैं।
तीनों मेट्रिक्स पर 'अच्छी' सीमाएं प्राप्त करने वाले पेज 'खराब' श्रेणी के पेजों की तुलना में 15 से 25% कम बाउंस दर दिखाते हैं।
वेब उपयोगकर्ता अनुभव पर 2025-2026 क्षेत्रीय अध्ययन
प्राथमिकता क्रम में कार्य योजना
लैब डेटा के बजाय Google Search Console (पेज अनुभव रिपोर्ट) में अपने फील्ड डेटा को मापने से शुरू करें: केवल CrUX डेटा रैंकिंग को प्रभावित करता है।
प्राथमिकता वाले पेज पहचानने के बाद, इस क्रम में कार्य करें: इमेज संपीड़न और आकार, लंबी अवधि के ब्राउज़र कैश की सक्रियता, फिर तृतीय-पक्ष स्क्रिप्ट का ऑडिट और स्थगन।
- अनुकूली srcset के साथ WebP या AVIF फॉर्मेट में इमेज परोसें।
- TTFB कम करने के लिए सर्वर पर Brotli कम्प्रेशन और CDN सक्रिय करें।
- font-display: swap का उपयोग करें और मुख्य फ़ॉन्ट को प्रीलोड करें।
- प्रत्येक तृतीय-पक्ष स्क्रिप्ट का ऑडिट करें और इसे defer या async मोड में लोड करें।
निरंतर निगरानी
Core Web Vitals प्रत्येक डिप्लॉयमेंट के साथ बदलती हैं। प्रोडक्शन से पहले किसी भी regression का पता लगाने के लिए अपने deployment pipeline में Lighthouse CI एकीकृत करें।
किसी URL के 'सुधार की जरूरत' या 'खराब' क्षेत्र में जाते ही सूचित होने के लिए Search Console या CrUX API के माध्यम से अलर्ट कॉन्फ़िगर करें।
FAQ
क्या Core Web Vitals एक प्रमुख रैंकिंग कारक हैं?
Google उन्हें सामग्री प्रासंगिकता की तुलना में 'हल्का रैंकिंग संकेत' बताता है। वे समकक्ष गुणवत्ता के दो पेजों के बीच अंतर कर सकते हैं, लेकिन वे कभी भी कमजोर सामग्री की भरपाई नहीं करेंगे।
क्या मोबाइल या desktop पर मापना चाहिए?
Google मोबाइल-फर्स्ट इंडेक्सिंग के तहत मुख्यतः मोबाइल डेटा का उपयोग करता है। मोबाइल पर ध्यान केंद्रित करें, भले ही आपका ट्रैफिक मुख्यतः desktop से हो।
क्या PageSpeed Insights Core Web Vitals ऑडिट के लिए पर्याप्त है?
PageSpeed Insights लैब डेटा (सिमुलेशन) और फील्ड CrUX डेटा दोनों दिखाता है यदि ट्रैफिक पर्याप्त है। एक संपूर्ण ऑडिट के लिए, इसे Search Console और Chrome Web Vitals एक्सटेंशन के साथ संयोजित करें।
सुधार के बाद पोजीशन पर प्रभाव देखने में कितना समय लगता है?
Google हर महीने अपना CrUX डेटा अपडेट करता है। आज किए गए सुधार आमतौर पर चार से आठ सप्ताह में रैंकिंग में दिखते हैं।