वेबसाइट की गति और कोर वेब वाइटल्स: एक संपूर्ण गाइड

कोर वेब वाइटल्स का साधारण भाषा में क्या मतलब है

आइए आवश्यकताओं से शुरू करते हैं।कोर वेब वाइटल्स तीन मैट्रिक्स हैं जो Google यह मापने के लिए उपयोग करता है कि एक पृष्ठ वास्तव में एक वास्तविक मानव की नजरों में कैसे लोड होता है, न कि एक रोबोट। वे तीन सरल प्रश्नों का उत्तर देते हैं: क्या मुख्य सामग्री जल्दी दिखाई दी, क्या साइट आपकी क्रिया पर जल्दी प्रतिक्रिया दी, और क्या लेआउट आपकी उंगली के नीचे स्थिर रहा।

LCP — मुख्य सामग्री कितनी तेजी से दिखाई देती है

LCP (Largest Contentful Paint) वह क्षण है जब सबसे बड़ा दृश्य तत्व रेंडरिंग समाप्त करता है: आमतौर पर एक हीरो इमेज, एक शीर्षक, या एक बड़ा बैनर। एक आगंतुक उस पृष्ठ को लोडेड मानता है जब वह ब्लॉक दिखाई देता है, न कि जब अंतिम फुटर स्क्रिप्ट आती है। 2026 में एक ठोस लक्ष्य लगभग 2.5 सेकंड है एक सामान्य मोबाइल कनेक्शन पर।

INP — साइट कितनी तेजी से प्रतिक्रिया देती है

INP (Interaction to Next Paint)पुराने FID को बदल दिया गया और प्रतिक्रियाशीलता को मापता है: आप एक बटन पर टैप करते हैं, एक मेनू खोलते हैं, टाइप करना शुरू करते हैं — और कितने मिलीसेकंड बीतते हैं जब तक इंटरफेस स्पष्ट रूप से प्रतिक्रिया नहीं करता। यदि क्लिक के बाद आधे सेकंड तक कुछ नहीं होता है, तो मस्तिष्क यह मान लेता है कि साइट फ्रीज़ हो गई। एक आरामदायक सीमा 200 मिलीसेकंड से कम है।

CLS — लेआउट कितना स्थिर है

CLS (Cumulative Layout Shift)सबसे परेशान करने वाली बग को पकड़ता है: आप एक बटन पर निशाना लगाते हैं, उसके ऊपर एक छवि या बैनर लोड होता है, सब कुछ नीचे कूदता है, और आप गलत चीज़ पर क्लिक करते हैं। यह लेआउट का एक संचयी परिवर्तन है, और शून्य के करीब होने पर साइट अधिक व्यवस्थित लगती है। एक स्वस्थ मान 0.1 से कम है।

एक सरल सूत्र याद रखें: LCP देखना है, INP टैप करना है, CLS कूदने के बारे में है. Google इन तीनों को वास्तविक Chrome उपयोगकर्ताओं से एकत्र करता है और उन्हें रैंकिंग के लिए पृष्ठ गुणवत्ता संकेत के एक भाग के रूप में मानता है।

क्यों गति SEO और रूपांतरण को प्रभावित करती है

हम स्पष्ट रहें: एक धीमी साइट दरवाजे पर पैसे खोती है, इससे पहले कि आगंतुक एक शब्द भी पढ़े। प्रतीक्षा का हर अतिरिक्त सेकंड उन लोगों के हिस्से को बढ़ाता है जो टैब बंद करते हैं और तुरंत खुलने वाले प्रतिस्पर्धी के लिए चले जाते हैं।

गति और खोज रैंकिंग

कोर वेब वाइटल्स एक आधिकारिक रैंकिंग कारक हैं। इसका मतलब यह नहीं है कि एक तेज़ लेकिन खाली पृष्ठ एक धीमे लेकिन विशेषज्ञ पृष्ठ को हरा देता है: सामग्री अभी भी पहले आती है। लेकिन जब दो टुकड़े गुणवत्ता में करीब होते हैं, तो गति वह टाई-ब्रेकर बन जाती है जो आपको ऊंचा उठाती है। एक तेज़ साइट को भी अधिक गहराई से क्रॉल किया जाता है — समान क्रॉल बजट पर, बॉट आपके अधिक पृष्ठों तक पहुँचता है।

गति और पैसा

व्यावसायिक परियोजनाओं पर, वेबसाइट की गति और राजस्व के बीच का संबंध स्पष्ट है। पहले स्क्रीन को तेज करना चेकआउट और फॉर्म रूपांतरण को स्पष्ट रूप से बढ़ाता है, आपकी अधिग्रहण लागत को कम करता है (आप लोडिंग स्क्रीन पर अपने आधे भुगतान किए गए ट्रैफ़िक को खोना बंद कर देते हैं), और यह बढ़ाता है कि लोग कितनी गहराई से ब्राउज़ करते हैं। हमने यह बार-बार अपने विकास और अनुकूलन कार्य: तकनीकी प्रदर्शन एक और विज्ञापन अभियान की तुलना में तेजी से लाभ देता है।

यहां एक प्रतिष्ठा परत भी है। एक धीमी साइट को अवचेतन रूप से अविश्वसनीय के रूप में पढ़ा जाता है: यदि यहां सब कुछ रुकता है, तो क्या मैं इसे अपने भुगतान के लिए भरोसा कर सकता हूँ? गति आपके ब्रांड का पहला हाथ मिलाना है, और इसे आत्मविश्वास से भरा होना चाहिए।

गति को मापने का तरीका: प्रयोगशाला बनाम क्षेत्र

किसी भी चीज़ को ठीक करने से पहले, ईमानदारी से मापें। और यहां दो मौलिक रूप से अलग प्रकार के डेटा को अलग करना महत्वपूर्ण है, क्योंकि लोग लगातार उन्हें भ्रमित करते हैं।

लैब डेटा

लैब माप एक उपकरण द्वारा नियंत्रित परिस्थितियों में लिए जाते हैं: एक निश्चित कनेक्शन, एक परिभाषित उपकरण, एक साफ वातावरण। यह है लाइटहाउस (Chrome DevTools में निर्मित) और PageSpeed Insights का लैब सेक्शन। इसका लाभ यह है कि यह दोहराने योग्य है: आप कोड बदलते हैं और तुरंत देखते हैं कि क्या चीजें सुधरीं। इसका नुकसान यह है कि यह एक अनुकरण है, असली लोग नहीं।

फील्ड डेटा

फील्ड डेटा वास्तविक Chrome उपयोगकर्ताओं (CrUX डेटा सेट) से एकत्रित मेट्रिक्स हैं। ये वही हैं जो Google रैंकिंग के लिए उपयोग करता है। ये दिखाते हैं कि साइट असली उपकरणों, असली नेटवर्कों और असली भूगोल पर कैसे व्यवहार करती है। फील्ड नंबर 75वें पर्सेंटाइल पर मापे जाते हैं: लक्ष्य यह है कि साइट औसत पर तेज न हो बल्कि दर्शकों के तीन चौथाई के लिए।

एक व्यावहारिक माप आदेश

1. अपने प्रमुख टेम्पलेट्स (होम, श्रेणी, उत्पाद, फॉर्म) को PageSpeed Insights के माध्यम से चलाएं - मोबाइल और डेस्कटॉप के लिए अलग-अलग।
2. यदि वे मौजूद हैं तो पहले फील्ड कोर वेब वाइटल्स पर ध्यान दें; डिबगिंग टूल के रूप में लैब स्कोर का उपयोग करें।
3. डेवटूल्स में परफॉर्मेंस टैब खोलें और पता करें कि कौन सा तत्व LCP को चलाता है और कौन से स्क्रिप्ट मुख्य थ्रेड को ब्लॉक करते हैं।

स्वर्ण नियम: फील्ड द्वारा ऑप्टिमाइज़ करें, लैब द्वारा डिबग करें. लाइटहाउस में एक सुंदर सौ का पीछा करना बिना असली उपयोगकर्ताओं की परवाह किए एक स्क्रीनशॉट के लिए किया गया काम है, व्यवसाय के लिए नहीं।

LCP: यह क्या कवर करता है और इसे कैसे सुधारें

LCP आमतौर पर वही होता है जिसका मतलब लोग जब कहते हैं कि साइट लोड होने में बहुत समय लेती है। इसे सुधारने का मतलब है मुख्य पहले स्क्रीन तत्व को जल्दी दिखाना। आइए इसे भागों में विभाजित करें।

LCP किससे बना है

LCP में चार सामग्री होती हैं: सर्वर प्रतिक्रिया समय (TTFB), संसाधन लोड होने से पहले की देरी, संसाधन का लोड समय, और रेंडर समय। इनमें से कोई भी बाधा बन सकता है, इसलिए उपचार निदान से शुरू होता है, अनुमान से नहीं।

LCP को वास्तव में क्या तेज करता है

• एक तेज सर्वर प्रतिक्रिया।TTFB को कम रखें: सर्वर-साइड कैशिंग, उचित होस्टिंग, और पहले स्क्रीन को उत्पन्न करने में कुछ भारी डेटाबेस क्वेरी।
• मुख्य संसाधन के लिए प्राथमिकता।LCP छवि या शीर्षक फ़ॉन्ट को उच्च प्राथमिकता (प्रीलोड) के साथ लोड होना चाहिए, सामान्य कतार में नहीं।
• पहली स्क्रीन के लिए कोई लेज़ी लोडिंग नहीं।एक क्लासिक गलती शीर्ष बैनर पर लेज़ी-लोड डालना है। लेज़ी लोडिंग को फोल्ड के नीचे जो है उसके लिए बचाएं।
• एक हल्का, सही ढंग से संकुचित LCP तत्व।एक विशाल 2 MB PNG हीरो तेज़ सर्वर पर भी मेट्रिक को बर्बाद कर देगा।

रेंडर-ब्लॉकिंग पर एक शब्द। यदि ब्राउज़र को पहले स्क्रीन को दिखाने से पहले भारी CSS और JavaScript डाउनलोड और चलाना पड़ता है, तो LCP ठीक उसी समय से देरी हो जाती है। यही कारण है कि महत्वपूर्ण CSS इनलाइन होती है जबकि द्वितीयक स्क्रिप्ट को नीचे धकेल दिया जाता है और स्थगित किया जाता है।

INP और CLS: प्रतिक्रियाशीलता और स्थिरता

यदि LCP देखने के बारे में है, तो INP और CLS लोडिंग के बाद गुणवत्ता की भावना के बारे में हैं। इन्हें अक्सर कम आंका जाता है, और यह एक गलती है: ये वही हैं जो एक साइट को सावधानीपूर्वक निर्मित महसूस कराते हैं।

INP को कैसे सुधारें

खराब INP लगभग हमेशा इसका मतलब है कि ब्राउज़र का मुख्य थ्रेड भारी JavaScript के साथ व्यस्त है। उपयोगकर्ता टैप करता है - लेकिन उस क्षण थ्रेड एनालिटिक्स को संसाधित कर रहा है, एक स्लाइडर चला रहा है, या एक विजेट को रेंडर कर रहा है, और प्रतिक्रिया में देरी होती है। जो मदद करता है:

• लंबे कार्यों को छोटे कार्यों में तोड़ें, ब्राउज़र को क्लिक संभालने के लिए विराम देते हुए।
• तीसरे पक्ष की स्क्रिप्ट को हटा दें या स्थगित करें जो पृष्ठभूमि में काम कर रही हैं।
• हर मूव और कीस्ट्रोक पर भारी हैंडलर्स से बचें।
• वैकल्पिक गणना को इंटरैक्शन के क्षण से बाहर ले जाएं।

लेआउट शिफ्ट्स (CLS) को कैसे हटाएं

CLS को मार्कअप अनुशासन से ठीक किया जाता है। मुख्य नियम:

1. छवियों और वीडियो पर हमेशा चौड़ाई और ऊँचाई (या अनुपात) सेट करें ताकि पहले से ही स्थान आरक्षित हो सके।
2. बैनर, विजेट और विज्ञापन स्लॉट के लिए स्थान आरक्षित करें, बजाय इसके कि जब वे प्रकट हों तो सामग्री को धकेलने दें।
3. फॉन्ट लोड करें ताकि सिस्टम फॉन्ट को कस्टम फॉन्ट के लिए बदलने से टेक्स्ट न हिले (सही फॉन्ट-डिस्प्ले और फॉलबैक मैट्रिक्स)।
4. कभी भी उपयोगकर्ता जो पहले से देख रहा है उसके ऊपर सामग्री न डालें - केवल इसके नीचे।

भुगतान और फॉर्म एक विशेष दर्द बिंदु हैं। हमारे Payora भुगतान सेवा परियोजना में हमने पहले स्क्रीन की स्थिरता को विशेष रूप से ध्यान से देखा: जब पैसे की बात आती है, तो एक कूदता हुआ लेआउट और धीमी बटन प्रतिक्रिया सीधे विश्वास और पूर्ण लेनदेन की संख्या को कम कर देती है।

धीरे साइट के सबसे बड़े कारण

अच्छी खबर: धीमी साइटों के पीछे कुछ कारण होते हैं, और वे आश्चर्यजनक रूप से सामान्य होते हैं। दस में से नौ मामलों में, इस सूची में से कोई एक दोषी होता है।

भारी चित्र

पृष्ठ आकार का पूर्ण भारी वजन। पूर्ण-रिज़ॉल्यूशन फ़ोटो, मल्टी-मेगाबाइट PNG स्क्रीनशॉट, चित्र जिन्हें ब्राउज़र छोटे आकार में संकुचित करता है लेकिन पूर्ण रूप से डाउनलोड करता है। अक्सर चित्र LCP तत्व भी होता है, इसलिए यह एक डबल हिट है।

फॉन्ट

भारी प्रारूपों में कई वजन, एक बाहरी डोमेन से लोड किए गए, बिना प्रीलोड के - और पाठ या तो झपकता है या देर से प्रकट होता है, जैसे-जैसे यह जाता है लेआउट को धकेलता है।

ब्लॉकिंग CSS और JavaScript

विशाल बंडल जिन्हें पहले पेंट से पहले डाउनलोड और निष्पादित किया जाना चाहिए। भारी ढांचे विशेष रूप से बर्बाद होते हैं जहां कुछ पंक्तियों का कोड काम कर सकता है।

तीसरे पक्ष के स्क्रिप्ट

चैट, पिक्सेल, दर्जन भर एनालिटिक्स टैग, सामाजिक विजेट, A/B परीक्षण। प्रत्येक अपने आप में हल्का होता है, लेकिन एक साथ वे मुख्य धागे को खा जाते हैं और INP को बर्बाद कर देते हैं। यह सबसे कम आंका गया श्रेणी है।

धीमा होस्टिंग और उच्च TTFB

यदि सर्वर उत्तर देने से पहले एक सेकंड के लिए सोचता है, तो कोई भी फ्रंट-एंड जादू इसे पूरी तरह से छिपा नहीं सकता। सस्ता ओवरलोडेड होस्टिंग, कोई सर्वर कैश, भारी डेटाबेस क्वेरीज़ - ये सभी LCP के आधार पर हैं।

व्यावहारिक takeaway: एक साथ सब कुछ ठीक करने के लिए जल्दी न करें। पहले मापें, अपनी हानि का मुख्य स्रोत खोजें - और उस पर ध्यान केंद्रित करें।

छवि अनुकूलन: प्रारूप और लेज़ी लोडिंग

चूंकि चित्र भारी होते हैं, गति अनुकूलन लगभग हमेशा वहीं से शुरू होता है। यह सबसे तेज़, सबसे स्पष्ट जीत है जिसमें सबसे कम जोखिम होता है।

आधुनिक प्रारूप

पर जाएं WebP, और जहाँ संभव हो वहाँ AVIF। तुलनीय गुणवत्ता पर, ये पारंपरिक JPEG और PNG की तुलना में स्पष्ट रूप से कम वजन के होते हैं। आइकनों और सरल ग्राफिक्स के लिए उपयोग करें SVG: यह वेक्टर है, वजन रहित है, और किसी भी स्क्रीन पर पूरी तरह से स्पष्ट है।

सही आकार और प्रतिक्रियाशीलता

कभी भी किसी छवि को उसके वास्तविक प्रदर्शन से चौड़ा न करें। कई आकार तैयार करें और उन्हें srcset के माध्यम से वायर करें ताकि एक फोन एक संकुचित संस्करण प्राप्त करे और एक डेस्कटॉप एक बड़ा संस्करण। 4000-पिक्सेल हीरो को 800-पिक्सेल कंटेनर में रखना बर्बाद किए गए मेगाबाइट और सेकंड हैं।

आलसी लोडिंग - लेकिन समझदारी से

• जोड़ें loading="lazy"पहले स्क्रीन के नीचे की छवियों के लिए ताकि वे प्रारंभिक पेंट में हस्तक्षेप न करें।
• लेकिन पहले स्क्रीन LCP छवि को तुरंत और प्राथमिकता के साथ लोड करें - आलसी लोडिंग यहाँ केवल नुकसान करती है।
• हमेशा आयाम सेट करें ताकि आलसी लोडिंग लेआउट शिफ्ट न करे (वही CLS)।

और संकुचन को न भूलें। अच्छे ऑप्टिमाइज़र के माध्यम से संपत्तियों को चलाने से अक्सर 40–70% वजन कम होता है बिना किसी दृश्य गुणवत्ता हानि के। सामग्री साइटों के लिए ये सचमुच मुफ्त सेकंड हैं।

फॉन्ट, महत्वपूर्ण CSS और अतिरिक्त जावास्क्रिप्ट

छवियों के बाद, दूसरा सबसे महत्वपूर्ण क्षेत्र वह कोड है जिसे ब्राउज़र पृष्ठ दिखाने से पहले संसाधित करना चाहिए। अधिकांश रेंडर-ब्लॉकिंग समस्याएँ यहाँ छिपी होती हैं।

फॉन्ट

• वजन की न्यूनतम संख्या रखें - दो अक्सर पर्याप्त होते हैं।
• woff2 का उपयोग करें और फ़ॉन्ट्स को अपने स्वयं के डोमेन से प्रदान करें।
• प्रमुख पहले-स्क्रीन फ़ॉन्ट को प्रीलोड करें।
• font-display: swap सेट करें ताकि पाठ तुरंत पढ़ने योग्य हो जाए बजाय इसके कि फ़ॉन्ट के लिए इंतज़ार करें।

महत्वपूर्ण CSS

विचार सरल है: पहले स्क्रीन के लिए आवश्यक शैलियाँ HTML में सीधे इनलाइन होती हैं, और बाकी CSS बाद में लोड होती है। इस तरह ब्राउज़र बिना पूरे स्टाइलशीट के इंतज़ार किए पृष्ठ के शीर्ष को पेंट करता है। मृत नियमों को भी हटा दें - वर्षों में एक साइट इनमें से बहुत सारे जमा कर लेती है।

कम JavaScript

सबसे ईमानदार ऑप्टिमाइजेशन यह है कि आप जो बिना कर सकते हैं उसे न लोड करें। जांचें कि क्या आप कुछ प्रभावों के लिए एक भारी ढांचे को खींच रहे हैं। द्वितीयक स्क्रिप्ट को स्थगित करें डिफर और ऐसिंक्रोनस, बंडल को विभाजित करें, और मांग पर कोड लोड करें। तीसरे पक्ष के विजेट का अलग से ऑडिट करें: हर चैट, पिक्सेल, और टैग को प्रदर्शन बजट में अपनी जगह को सही ठहराना चाहिए। हमने इस पर चर्चा की कि यह बहुभाषी साइटों के साथ कैसे मेल खाता है बिना पृष्ठ को भारी किए हमारे लेख में बहुभाषी साइट और SEO.

कैशिंग, CDN, HTTP/2 और होस्टिंग

फ्रंट-एंड ऑप्टिमाइजेशन एक सीमा पर पहुंच जाता है यदि आधार - सर्वर और डिलीवरी - धीमी है। ये आइटम एक बार में हर पृष्ठ पर लाभ देते हैं।

कैशिंग

यह दो स्तरों पर काम करता है।सर्वर कैशभारी पृष्ठ को बार-बार पुनः उत्पन्न करने से बचता है और सीधे TTFB को कम करता है।ब्राउज़र कैश (स्थिर संपत्तियों के लिए सही Cache-Control हेडर) का मतलब है कि लौटने पर छवियाँ, फ़ॉन्ट और स्क्रिप्ट फिर से डाउनलोड नहीं की जाती हैं।

CDN

एक सामग्री वितरण नेटवर्क भौगोलिक रूप से उपयोगकर्ता के निकटतम सर्वर से स्थिर संपत्तियों की सेवा करता है। जितना दूर आपका दर्शक मूल से है, प्रभाव उतना ही मजबूत होता है: विलंबता कम होती है और पहला बाइट तेजी से आता है।

HTTP/2, HTTP/3 और संपीड़न

• एक आधुनिक प्रोटोकॉल (HTTP/2 या HTTP/3) सक्षम करें - यह समानांतर में दर्जनों छोटे फ़ाइलों को अधिक कुशलता से लोड करता है।
• सर्वर पर पाठ संसाधनों (Brotli या gzip) का संकुचन सक्षम करें।
• HTML, CSS, और JS को मिनिफाई करें,Whitespace और टिप्पणियों को हटाते हुए।

होस्टिंग और TTFB

एक उपयुक्त सर्वर कोई विलासिता नहीं है बल्कि एक आधारभूत आवश्यकता है। व्यस्त 24freelance मार्केटप्लेस प्रोजेक्ट पर हम ठीक सर्वर स्तर पर पहुंचे: कैशिंग और क्वेरी ऑप्टिमाइजेशन के बिना पहला बाइट क्रॉल हुआ, और कोई भी छवि कार्य लक्षित संख्याओं तक नहीं पहुंचा जब तक कि हमने बैकएंड को व्यवस्थित नहीं किया।

मोबाइल उपकरणों पर गति

2026 का एक महत्वपूर्ण सत्य: Google आपकी साइट का मूल्यांकन मुख्य रूप से इसके मोबाइल संस्करण द्वारा करता है, और अधिकांश ट्रैफ़िक फोन से आता है। और एक फोन का मतलब है एक कमजोर प्रोसेसर, एक कम स्थिर नेटवर्क, और उपयोगकर्ता से कम धैर्य।

क्यों मोबाइल अधिक कठोर है

जो एक शक्तिशाली लैपटॉप पर तुरंत चलता है, वह एक औसत स्मार्टफोन पर कई बार अधिक समय लेता है। भारी JavaScript मोबाइल पर INP को विशेष रूप से कठिन प्रभावित करता है क्योंकि प्रोसेसर कमजोर होता है और प्रत्येक कार्य को पूरा करने में अधिक समय लेता है।

क्या करें

• एक थ्रॉटल्ड डिवाइस और धीमी नेटवर्क अनुकरण के साथ परीक्षण करें, केवल अपने प्रमुख डिवाइस पर नहीं।
• नियंत्रणों को इतना बड़ा बनाएं कि आकस्मिक टैप और शिफ्ट से बचने के लिए पहले से जगह सुरक्षित रखें।
• तीसरे पक्ष के स्क्रिप्ट को विशेष रूप से कठिनाई से काटें - मोबाइल पर उनकी लागत कई गुना अधिक होती है।
• छवियों को मोबाइल आकार में परोसें, न कि ब्राउज़र द्वारा संकुचित डेस्कटॉप आकार में।

अच्छी खबर: यदि एक साइट औसत फोन पर एक औसत नेटवर्क पर तेजी से चलती है, तो यह लगभग निश्चित रूप से डेस्कटॉप पर भी तेज होगी। इसलिए सबसे खराब वास्तविक परिदृश्य के लिए अनुकूलित करें, न कि अपने कार्य मॉनिटर के लिए।

निगरानी और निरंतर नियंत्रण

गति एक एकल परियोजना नहीं है बल्कि एक प्रकार की स्वच्छता है। एक साइट जीवित रहती है: सामग्री जोड़ी जाती है, नए विजेट और बैनर आते हैं, कोड अपडेट होता है - और प्रदर्शन धीरे-धीरे बिगड़ता है। निगरानी के बिना, आप बिक्री में गिरावट से समस्या के बारे में सीखते हैं, रिपोर्ट से नहीं।

नब्ज पर उंगली कैसे रखें

• गूगल सर्च कंसोल में फील्ड कोर वेब वाइटल्स को नियमित रूप से जांचें - यह आपके दर्शकों के लिए वास्तविक प्रवृत्ति दिखाता है।
• मुख्य टेम्पलेट्स के स्वचालित जांच सेट करें ताकि रिलीज के तुरंत बाद रिग्रेशन को पकड़ सकें, एक महीने बाद नहीं।
• एक प्रदर्शन बजट निर्धारित करें - एक पृष्ठ-भार और स्क्रिप्ट-गिनती की सीमा जिसे टीम पार नहीं कर सकती।
• हर नए तीसरे पक्ष की स्क्रिप्ट को एक अलग निर्णय के रूप में मानें: यह व्यवसाय को क्या देती है और इसकी गति में क्या लागत है।

इस पर कौन नज़र रखता है

व्यवहार में, एक व्यक्ति को गति के लिए जिम्मेदार बनाना मददगार होता है - अन्यथा, मेट्रिक किसी का नहीं होता और पहले गिरता है। यदि आपकी टीम में ऐसा कोई व्यक्ति नहीं है, तो भूमिका को आउटसोर्स किया जा सकता है: हम, उदाहरण के लिए, आवधिक ऑडिट और प्रदर्शन समर्थन लेते हैं, जिसे व्यवस्थित करना सबसे आसान है हमारे संपर्क फ़ॉर्म के माध्यम से.

मुख्य विचार: हर बड़े बदलाव से पहले और बाद में मापें। यह दावा कि चीजें तेज़ हो गईं, को साबित किया जाना चाहिए, केवल महसूस नहीं किया जाना चाहिए।

एक व्यावहारिक साइट गति चेकलिस्ट

आइए सब कुछ एक लागू सूची में इकट्ठा करें। इसे शीर्ष से नीचे तक काम करें - आइटम प्रभाव-से-प्रयास अनुपात के अनुसार लगभग क्रमबद्ध हैं। आपको एक बार में सब कुछ करने की आवश्यकता नहीं है, लेकिन प्रत्येक बिंदु की समीक्षा करना सार्थक है।

मापें और प्राथमिकता दें

1. PageSpeed Insights (मोबाइल और डेस्कटॉप) में अपने प्रमुख टेम्पलेट्स को मापें और वर्तमान Core Web Vitals को रिकॉर्ड करें।
2. प्रत्येक महत्वपूर्ण टेम्पलेट का LCP तत्व और इसका मुख्य बाधा खोजें।

छवियाँ

1. छवियों को WebP या AVIF में और आइकनों को SVG में परिवर्तित करें।
2. srcset के माध्यम से उत्तरदायी आकार प्रदान करें, कभी भी कंटेनर से बड़े नहीं।
3. पहले स्क्रीन के नीचे लेज़ी लोडिंग सक्षम करें; LCP छवि को प्राथमिकता के साथ लोड करें।
4. छवि आयाम सेट करें ताकि कोई लेआउट शिफ्ट न हो।

कोड और फ़ॉन्ट

1. महत्वपूर्ण CSS को इनलाइन करें और बाकी को बाद में लोड करें।
2. फ़ॉन्ट वजन कम करें, प्रीलोड जोड़ें और font-display: swap करें।
3. defer/async के साथ स्क्रिप्ट को स्थगित करें और अप्रयुक्त CSS और JS को हटा दें।
4. तीसरे पक्ष के विजेट का ऑडिट करें और किसी भी अनावश्यक चीज़ को हटा दें।

सर्वर और डिलीवरी

1. सर्वर कैशिंग सक्षम करें और TTFB को कम करें।
2. स्थिर संपत्तियों के लिए ब्राउज़र कैशिंग सेट करें और Brotli/gzip संकुचन करें।
3. एक CDN और एक आधुनिक प्रोटोकॉल, HTTP/2 या HTTP/3 जोड़ें।
4. HTML, CSS, और JS को संकुचित करें।

नियंत्रण

1. एक थ्रॉटल किए गए मोबाइल-डिवाइस अनुकरण पर परिणाम की पुष्टि करें।
2. फील्ड-मैट्रिक निगरानी और एक प्रदर्शन बजट सेट करें।
3. पुनः मापें पहले और बाद में — जीत को संख्याओं में रिकॉर्ड करें।

इस चेकलिस्ट के माध्यम से ईमानदारी से काम करें और आपको न केवल एक सुंदर स्कोर मिलेगा बल्कि एक तेज, अधिक स्थिर और अधिक लाभदायक साइट भी मिलेगी। और अंत में, यही बात है।

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