अपनी वेबसाइट को तेज़ कैसे बनाएं: एक व्यावहारिक चेकलिस्ट
वेबसाइट को तेज़ बनाने के लिए पहले PageSpeed Insights से उसे मापें, फिर वह सबसे बड़ा कारण ठीक करें जो वह बताता है: आम तौर पर बहुत बड़ी इमेज, बहुत ज़्यादा JavaScript, भारी फ़ॉन्ट या थर्ड-पार्टी स्क्रिप्ट। Google के Core Web Vitals के “अच्छे” लक्ष्यों का लक्ष्य रखें: मुख्य कंटेंट 2.5 सेकंड में दिखे, टैप का जवाब 200 मिलीसेकंड में मिले, और लेआउट लगभग न हिले। ज़्यादातर साइटें यह कुछ बदलावों से हासिल कर लेती हैं, पूरी दोबारा लिखने से नहीं।
कुछ भी बदलने से पहले मापें
अंदाज़े से काम करना समय बर्बाद करता है। दो मुफ़्त टूल लगभग सबके काम आते हैं:
- PageSpeed Insights (pagespeed.web.dev) — कोई लाइव URL डालें। यह असली Chrome यूज़र का फ़ील्ड डेटा (अगर आपकी साइट पर पर्याप्त ट्रैफ़िक है) और सिमुलेटेड लोड से लैब डेटा दिखाता है, साथ में खास समस्याओं की सूची।
- Chrome DevTools में Lighthouse — वही लैब टेस्ट, किसी भी ऐसे पेज पर जिसे आप खोल सकते हैं, प्रीव्यू सहित। मोबाइल मोड में टेस्ट करें; धीमे नेटवर्क वाले फ़ोन पर ही समस्याएं साफ़ दिखती हैं।
जो संख्याएं मायने रखती हैं वे Google के Core Web Vitals हैं। सितंबर 2026 तक, web.dev पर Google का दस्तावेज़ ये “अच्छे” सीमा-मान देता है, जो पेज लोड के 75वें पर्सेंटाइल पर मापे जाते हैं:
| मेट्रिक | यह क्या मापता है | अच्छा |
|---|---|---|
| Largest Contentful Paint (LCP) | मुख्य कंटेंट (हीरो इमेज, हेडलाइन) कितनी जल्दी दिखता है | 2.5 सेकंड या कम |
| Interaction to Next Paint (INP) | क्लिक, टैप और टाइपिंग पर पेज कितनी जल्दी प्रतिक्रिया देता है | 200 मिलीसेकंड या कम |
| Cumulative Layout Shift (CLS) | लोड होते समय लेआउट कितना हिलता है | 0.1 या कम |
INP ने 2024 में पुराने First Input Delay मेट्रिक की जगह ली। अगर कोई टूल अब भी FID दिखाता है, तो वह पुराना है।
अपनी शुरुआती संख्याएं लिख लें। हर बदलाव के बाद दोबारा टेस्ट करें, ताकि पता रहे कि क्या मदद कर रहा है।
समय कहां जाता है: विकल्प और ट्रेड-ऑफ़
हर आम कारण का एक हल है, और हर हल की एक कीमत है। सबसे ऊपर वाले से शुरू करें — वे सबसे सस्ते और सबसे आम हैं।
| कारण | आम हल | ट्रेड-ऑफ़ |
|---|---|---|
| बड़ी इमेज | दिखने वाले आकार तक छोटा करें, कंप्रेस करें, WebP या AVIF इस्तेमाल करें | ज़्यादा कंप्रेस हो तो थोड़ी गुणवत्ता कम |
| इमेज गलत क्रम में लोड होना | फ़ోल्ड के नीचे की इमेज लेज़ी-लोड करें; हीरो इमेज को उच्च प्राथमिकता दें | कोई नहीं, अगर हीरो लेज़ी-लोड नहीं है |
| बहुत ज़्यादा JavaScript | हर पेज के लिए कोड बांटें, इस्तेमाल न होने वाली लाइब्रेरी हटाएं | कुछ रीफ़ैक्टरिंग |
| सिर्फ़ क्लाइंट पर रेंडरिंग | सार्वजनिक पेजों को प्री-रेंडर या सर्वर-रेंडर करें | ज़्यादा बिल्ड या सर्वर सेटअप |
| वेब फ़ॉन्ट | कम फ़ैमिली और वज़न, मुख्य फ़ॉन्ट को प्रीलोड करें, font-display: swap | टाइपोग्राफ़ी की विविधता कम |
| थर्ड-पार्टी स्क्रिप्ट | इस्तेमाल न होने वाली हटाएं, बाकी को पेज के बाद लोड करें | कोई विजेट या ट्रैकर खोना |
| धीमा सर्वर रिस्पॉन्स | कैशिंग, CDN, कंटेंट पेजों के लिए स्टैटिक होस्टिंग | कैश इनवैलिडेशन पर सोचना होगा |
इमेज
इमेज सबसे आम समस्या है और ठीक करने में सबसे आसान। 800 पिक्सल चौड़ी दिखाई जाने वाली 4,000 पिक्सल की फ़ोटो हर विज़िटर को उससे पांच गुना ज़्यादा डाउनलोड करने पर मजबूर करती है जितना वह देखता है।
- इमेज को उसी आकार में परोसें जिसमें वह दिखती है, फ़ोन और डेस्कटॉप के लिए रिस्पॉन्सिव
srcsetआकारों के साथ। - आधुनिक फ़ॉर्मेट (WebP या AVIF) और समझदार कंप्रेशन इस्तेमाल करें।
- हर इमेज पर
widthऔरheightसेट करें ताकि ब्राउज़र जगह पहले से रिज़र्व कर सके। अकेले इससे ज़्यादातर लेआउट शिफ़्ट ठीक हो जाता है। - फ़ोल्ड के नीचे की इमेज को
loading="lazy"से लेज़ी-लोड करें। - पेज के ऊपर की मुख्य इमेज को कभी लेज़ी-लोड न करें। Google का LCP मार्गदर्शन इस पर सीधा है: LCP इमेज को लेज़ी-लोड करने से वह हमेशा देर से आती है। उसके बजाय
fetchpriority="high"दें।
JavaScript
कई AI से बनी साइटें सिंगल-पेज ऐप (SPA) होती हैं: ब्राउज़र एक JavaScript बंडल डाउनलोड करता है और फिर पेज बनाता है। बंडल जितना बड़ा, खाली स्क्रीन उतनी लंबी। प्रयास के क्रम में हल:
- जो इस्तेमाल नहीं होता उसे हटाएं। डिपेंडेंसी की सूची मांगें और ऐसी लाइब्रेरी काटें जो एक बार जोड़ी गई और भुला दी गई — एक तारीख के लिए पूरी डेट लाइब्रेरी, या पांच आइकन के लिए पूरा आइकन पैक।
- रूट के हिसाब से बांटें। एडमिन डैशबोर्ड का कोड तभी लोड करें जब कोई उसे खोले, होम पेज पर नहीं।
- सार्वजनिक पेजों को प्री-रेंडर करें। जो मार्केटिंग पेज असली HTML के रूप में आता है, वह किसी भी JavaScript चलने से पहले दिखता है। इससे सर्च इंजन को भी मदद मिलती है; देखें AI से बनी वेबसाइटों के लिए SEO।
धीमा INP आम तौर पर मतलब होता है कि एक लंबा टास्क पेज को रोक रहा है — हर कीस्ट्रोक पर एक बड़ी लिस्ट फ़िल्टर करना, या एक सेल बदलने पर पूरी टेबल दोबारा रेंडर करना। Chrome DevTools का Performance पैनल दिखाता है कि कौन सा।
फ़ॉन्ट
हर फ़ॉन्ट फ़ैमिली और वज़न एक और फ़ाइल है। दो फ़ैमिली और तीन-चार वज़न आम तौर पर काफ़ी होते हैं। फ़ोल्ड के ऊपर इस्तेमाल होने वाला फ़ॉन्ट प्रीलोड करें, font-display: swap इस्तेमाल करें ताकि टेक्स्ट तुरंत दिखे, और अगर बाहरी फ़ॉन्ट सेवा आपके विज़िटर के लिए धीमी है तो फ़ॉन्ट खुद होस्ट करें।
थर्ड-पार्टी स्क्रिप्ट
चैट विजेट, एनालिटिक्स, हीटमैप, विज्ञापन पिक्सल, एम्बेड किए गए वीडियो और सोशल फ़ीड, ये सब दूसरे सर्वरों से कोड लोड करते हैं। हर एक छोटा लगता है; मिलकर अक्सर पेज का सबसे धीमा हिस्सा बन जाते हैं। वही रखें जिन्हें आप सचमुच देखते हैं। बाकी को पेज इंटरेक्टिव होने के बाद लोड करें, और भारी एम्बेड (YouTube प्लेयर, नक्शा) की जगह हल्का प्रीव्यू लगाएं जो क्लिक पर असली चीज़ लोड करे।
सर्वर रिस्पॉन्स
टाइम टू फ़र्स्ट बाइट (TTFB) — सर्वर को जवाब शुरू करने में कितना समय लगता है — हर दूसरे मेट्रिक की नींव है। CDN (आपके विज़िटर के पास के सर्वरों का नेटवर्क; देखें CDN क्या है) से परोसे गए स्टैटिक पेज लगभग हर जगह तेज़ होते हैं। हर अनुरोध पर सर्वर द्वारा बनाए गए पेज उस सर्वर और उसके डेटाबेस पर निर्भर करते हैं। दोहराए गए काम के लिए कैशिंग और धीमी क्वेरी के लिए डेटाबेस इंडेक्स जोड़ना आम हल हैं।
जो प्रॉम्प्ट काम करते हैं
खास रहें: पेज, मेट्रिक और बाधा का नाम लें। अगर PageSpeed Insights के नतीजे हैं, तो उन्हें चिपकाएं।
PageSpeed Insights मोबाइल पर होम पेज का LCP 4.8 सेकंड बता रहा है, और LCP एलिमेंट हीरो इमेज है। हीरो इमेज का आकार बदलो और उसे WebP में बदलो, रिस्पॉन्सिव साइज़ परोसो, width और height सेट करो, उसे fetchpriority="high" दो और सुनिश्चित करो कि वह लेज़ी-लोड न हो। फ़ोल्ड के नीचे की हर इमेज लेज़ी-लोड करो। डिज़ाइन मत बदलो।
इस ऐप की डिपेंडेंसी का ऑडिट करो। हर पैकेज, उसका उपयोग और बंडल में लगभग कितना जोड़ता है, यह सूचीबद्ध करो। जो इस्तेमाल नहीं होते उन्हें हटाओ, और /admin और /settings रूट को अलग चंक में बांटो जो सिर्फ़ तब लोड हों जब उन्हें खोला जाए।
/products पर सर्च बॉक्स सुस्त लगता है। फ़िल्टर को debounce करो, हर कीस्ट्रोक पर पूरी लिस्ट दोबारा रेंडर करने से बचो, और अगर लिस्ट में 200 से ज़्यादा आइटम हैं तो उसे पेजिनेट या virtualise करो।
चरण दर चरण
- लाइव पेज को PageSpeed Insights पर मोबाइल में टेस्ट करें। LCP, INP और CLS, और सूचीबद्ध शीर्ष तीन समस्याएं नोट करें।
- पहले इमेज ठीक करें: आकार, फ़ॉर्मेट, डाइमेंशन, फ़ोल्ड के नीचे लेज़ी लोडिंग, हीरो को प्राथमिकता।
- वे थर्ड-पार्टी स्क्रिप्ट हटाएं जो आप इस्तेमाल नहीं करते, और बाकी को टालें।
- फ़ॉन्ट कम करें उतने पर जितना डिज़ाइन को चाहिए।
- JavaScript घटाएं: इस्तेमाल न होने वाले पैकेज हटाएं, रूट के हिसाब से बांटें।
- सार्वजनिक पेजों को प्री-रेंडर करें अगर वे अब भी क्लाइंट पर रेंडर होते हैं और LCP अब भी धीमा है।
- सर्वर जांचें: कैशिंग, डेटाबेस इंडेक्स, जो कंटेंट शायद ही बदलता है उसके लिए स्टैटिक होस्टिंग।
- फिर से प्रकाशित करें और दोबारा टेस्ट करें। PageSpeed Insights का फ़ील्ड डेटा आने वाले हफ़्तों में असली विज़िट के साथ अपडेट होता है, इसलिए शुरुआती नतीजों को लैब डेटा से आंकें।
आम गलतियां
- सिर्फ़ तेज़ लैपटॉप पर टेस्ट करना। आपके विज़िटर मध्यम श्रेणी के फ़ोन और कमज़ोर मोबाइल डेटा पर हैं। मोबाइल मोड में टेस्ट करें।
- परफ़ेक्ट 100 के पीछे भागना। लैब स्कोर एक मार्गदर्शक है। एक बार Core Web Vitals अच्छी सीमा में आ जाएं, तो कंटेंट और उपयोगिता आखिरी कुछ अंकों से ज़्यादा मायने रखते हैं।
- सब कुछ लेज़ी-लोड करना, हीरो इमेज सहित। इससे LCP और बिगड़ता है।
- ऊपर से स्पीड प्लगइन या लाइब्रेरी जोड़ना। वज़न हटाना लगभग हमेशा उसे संभालने के लिए नया कोड जोड़ने से बेहतर है।
- लाइव साइट के बजाय प्रीव्यू को ऑप्टिमाइज़ करना। डेवलपमेंट प्रीव्यू बिना ऑप्टिमाइज़ेशन वाले बिल्ड चलाते हैं। प्रकाशित URL को मापें।
- स्पीड को एक बार ठीक करना। हर नया विजेट, इमेज और फ़ीचर वज़न जोड़ता है। बड़े बदलावों के बाद दोबारा टेस्ट करें।
स्पीड चेकलिस्ट
- मोबाइल पर LCP ≤ 2.5 सेकंड, INP ≤ 200 ms, CLS ≤ 0.1
- इमेज का आकार बदला गया, कंप्रेस की गई, आधुनिक फ़ॉर्मेट में, width और height के साथ
- हीरो इमेज लेज़ी-लोड नहीं; फ़ोल्ड के नीचे की इमेज लेज़ी-लोड
- कोई इस्तेमाल न होने वाली JavaScript लाइब्रेरी नहीं; भारी रूट अलग किए गए
- दो या उससे कम फ़ॉन्ट फ़ैमिली, मुख्य फ़ॉन्ट प्रीलोड
- सिर्फ़ वे थर्ड-पार्टी स्क्रिप्ट जो आप सचमुच इस्तेमाल करते हैं, देर से लोड
- सार्वजनिक पेज जहां संभव हो प्री-रेंडर या स्टैटिक
- प्रकाशित करने के बाद लाइव URL पर दोबारा टेस्ट
स्पीड और मोबाइल लेआउट साथ चलते हैं; देखें वेबसाइट को मोबाइल-रिस्पॉन्सिव कैसे बनाएं। लॉन्च से पहले की पूरी जांच के लिए, AI प्रोटोटाइप को प्रोडक्शन तक कैसे ले जाएं बाकी बातें कवर करता है।
Mythex पर स्पीड
Mythex पर आप ये बदलाव चैट में मांगकर करते हैं, या Pro पर कोड एडिटर में। Preview चूंकि डेवलपमेंट सर्वर चलाता है, इसलिए प्रकाशित URL जांचें, Preview नहीं। स्टैटिक फ़्रंट एंड प्रकाशित होने पर स्टैटिक साइट के रूप में डिप्लॉय होते हैं (स्टैटिक वेबसाइट), जो कंटेंट पेजों के लिए ठीक है। सर्वर वाली ऐप स्केल टू ज़ीरो होती हैं: खाली रहने पर सो जाती हैं और अगली विज़िट पर जाग जाती हैं, इसलिए शांत अवधि के बाद पहला अनुरोध धीमा होता है, और जुड़ा डेटाबेस 5 मिनट के निष्क्रिय रहने के बाद सो जाता है (होस्टिंग सीमाएं)। अगर कोई सार्वजनिक पेज सिर्फ़ पहली विज़िट पर धीमा है, तो यही संभवतः कारण है। मार्केटिंग पेजों को स्टैटिक रखने से मदद मिलती है। बदलावों के बाद फिर से प्रकाशित करें और हार्ड-रिफ़्रेश करें।
सवाल
पेज लोड होने का अच्छा समय कितना है?
Google के Core Web Vitals सबसे साफ़ लक्ष्य देते हैं: मुख्य कंटेंट 2.5 सेकंड के भीतर दिखना चाहिए (LCP), पेज इनपुट पर 200 मिलीसेकंड के भीतर प्रतिक्रिया दे (INP), और लेआउट शिफ़्ट 0.1 या उससे कम रहे (CLS)। ये असली विज़िट के 75वें पर्सेंटाइल पर मापे जाते हैं।
क्या वेबसाइट की स्पीड SEO को प्रभावित करती है?
हां, थोड़ा। Google Core Web Vitals सहित पेज अनुभव के संकेतों का इस्तेमाल करता है, लेकिन प्रासंगिक कंटेंट कहीं ज़्यादा मायने रखता है। स्पीड का असर विज़िटर पर कहीं ज़्यादा होता है, क्योंकि वे धीमे पेज पर कुछ पढ़ने से पहले ही चले जाते हैं।
मेरा PageSpeed Insights स्कोर हर बार अलग क्यों आता है?
लैब स्कोर एक ही सिमुलेटेड लोड से आता है, इसलिए नेटवर्क और सर्वर का समय हर बार अलग होता है। इसे कुछ बार चलाएं और रुझान देखें, और फ़ील्ड डेटा वाले सेक्शन को ज़्यादा वज़न दें, जो असली Chrome यूज़र से आता है।
ज़्यादातर वेबसाइट को सबसे ज़्यादा क्या धीमा करता है?
आम तौर पर बहुत बड़ी इमेज, बहुत ज़्यादा JavaScript, वेब फ़ॉन्ट, और चैट विजेट, विज्ञापन पिक्सल या एम्बेड जैसी थर्ड-पार्टी स्क्रिप्ट। धीमा सर्वर रिस्पॉन्स या कोल्ड-स्टार्ट होने वाला बैकएंड इन सबमें और जोड़ देता है।