आपकी साइट धीमी क्यों है
लगभग हर धीमी साइट के पीछे मुट्ठीभर कारण, यह साबित करने का तरीका कि आपके पास कौन सा है, और वह क्रम जो वास्तविक फील्ड डेटा को आगे बढ़ाता है।
← Guides All guides in this topic
अनुमान लगाने से पहले मापें
अगर आप DevTools खोलते हैं, तीन प्लगइन बदलते हैं, और फील्ड डेटा देखे बिना फिर से तैनात करते हैं, तो आप अतिरिक्त चरणों के साथ अनुमान लगा रहे हैं। धीमापन एक विज़िटर अनुभव है। कोड को छूने से पहले वास्तविक उपयोगकर्ताओं के संख्याओं के साथ इसे साबित करें।
Chrome UX Report फील्ड डेटा के साथ PageSpeed Insights या Search Console Core Web Vitals में शुरुआत करें। आप मोबाइल पर Largest Contentful Paint, Interaction to Next Paint, और Cumulative Layout Shift के लिए 75वें प्रतिशतक चाहते हैं। Lighthouse के लैब स्कोर एकल पृष्ठ लोड को डिबग करने के लिए उपयोगी हैं। ये वह मीट्रिक नहीं हैं जो Google रैंकिंग के लिए उपयोग करता है या वह मीट्रिक जो आपके खरीदार ट्रेन Wi-Fi कनेक्शन पर महसूस करते हैं।
पहले दस मिनटों में क्या कैप्चर करें
धीमे पृष्ठ का URL। डिवाइस क्लास (पहले फोन)। समस्या पहली विज़िट की है या दोहराई गई विज़िट की। क्या लॉगिन किए गए पृष्ठ सार्वजनिक होमपेज से भिन्न हैं। TTFB अगर आप इसे देख सकें। डायग्नोस्टिक्स पैनल से LCP एलिमेंट का नाम। वह छोटी सूची आमतौर पर किसी को फ्रेमवर्क पर बहस करने से पहले सही दिशा की ओर इशारा करती है।
मुख्य निष्कर्ष: फील्ड डेटा तय करता है कि साइट धीमी है या नहीं। लैब डेटा आपको लीवर खोजने में मदद करता है। कभी भी उस क्रम को उल्टा न करें।
Front end या server?
अगर पृष्ठ किसी भी सामग्री के दिखाई देने से पहले धीमा है, तो यह आमतौर पर सर्वर है: उच्च time to first byte, एक अनकैश्ड डेटाबेस क्वेरी, PHP या Node हर अनुरोध पर रेंडरिंग, या एक साधारण रूप से कमजोर होस्ट। अगर सामग्री दिखाई देती है फिर हिचकी, ठहरता है, या शिफ्ट होता है, तो यह फ्रंट-एंड है: छवियां, स्क्रिप्ट, फॉन्ट, और लेआउट।
एक उपयोगी विभाजन: लगभग 0.8 सेकंड के तहत TTFB का मतलब है कि उत्पत्ति ज्यादातर महत्वपूर्ण पथ से बाहर है। मार्केटेड पृष्ठ पर 1.2 सेकंड से ऊपर, होस्टिंग, कैश, या सर्वर रेंडर लागत को ठीक करें इससे पहले कि आप छवि कोडेक्स पर जुनून करें। बड़ी साइटों के लिए निदान के लिए Core Web Vitals चेकलिस्ट और इस साइट पर LCP, INP, CLS फिक्स गाइड में अपना खुद का प्लेबुक मिलता है।
| Symptom | Likely lane | First check |
|---|---|---|
| Blank screen, then everything | Server / TTFB | Host, cache hit rate, SSR cost |
| Hero late, rest fine | Front-end LCP | Hero image size, preload, CDN |
| Taps feel sticky | Front-end INP | JS weight, long tasks, third parties |
| Page jumps while loading | Front-end CLS | Image dimensions, font swap, ads |
मुख्य निष्कर्ष: पहले दिशा का नाम बताएं। सर्वर कार्य और फ्रंट-एंड कार्य को अलग लोग और अलग उपकरण चाहिए।
छह आम संदिग्ध
जिस क्रम में मैं कमर्शियल साइट्स पर असल समस्या देखता हूँ:
1. ओवरसाइज़्ड हीरो मीडिया
एक 2MB PNG या अनक्रॉप्ड CMS अपलोड जो LCP एलिमेंट है। समाधान: सही साइज़, आधुनिक फॉर्मेट (WebP या AVIF), width और height एट्रिब्यूट्स, असली LCP URL को प्रीलोड करें, CDN से सर्व करें। एक अच्छी हीरो फिक्स अक्सर दस माइक्रो-ट्वीक्स से बेहतर होती है।
2. JavaScript जिसकी आपको पहली पेंट पर जरूरत नहीं है
टैग मैनेजर्स, चैट विजेट्स, A/B टूल्स, अनुपयोगी फ्रेमवर्क हाइड्रेशन, और "बस यूँही" क्लाइंट कंपोनेंट्स। समाधान: थर्ड पार्टीज़ को defer या remove करें, मार्केटिंग रूट्स पर कम JS शिप करें, इंटरएक्टिविटी आइलैंड्स को छोटा रखें।
3. होस्टिंग और कैश मिसेस
शेयर्ड होस्ट्स, बिना पेज कैश के कोल्ड WordPress, हर पब्लिक URL पर Next.js SSR, या ISR पैटर्न्स जो हर डिप्लॉय पर दुनिया को रीबिल्ड करते हैं। समाधान: WordPress के लिए मैनेज्ड होस्टिंग या एज कैश, ऐप फ्रेमवर्क्स के लिए स्टेटिक या ISR एक समझदारी भरी रीवेलिडेट पॉलिसी के साथ।
4. रेंडर-ब्लॉकिंग फॉन्ट्स और CSS
एक डिस्प्ले फॉन्ट के पाँच वेट्स, थर्ड-पार्टी CSS फाइल से इंपोर्ट किए गए, टेक्स्ट को ब्लॉक कर रहे हैं। समाधान: subset करें, self-host करें, font-display swap या optional सेट करें, above-the-fold के लिए क्रिटिकल CSS।
5. अनबाउंडेड थर्ड पार्टीज़
पिक्सेल जो अधिक पिक्सेल इंजेक्ट करते हैं। समाधान: इंटरैक्शन के बाद या फ़ॉलो समय पर लोड करें, कुछ भी हटाएं जो रूपांतरण परीक्षण में अपनी जगह अर्जित नहीं करता।
6. देर से सामग्री से लेआउट शिफ्ट
विज्ञापन, एम्बेड और आरक्षित स्थान के बिना छवियां। समाधान: aspect-ratio बॉक्स, आरक्षित स्लॉट, मौजूदा सामग्री के ऊपर UI इंजेक्ट न करें।
मुख्य बात: अधिकांश "फ्रेमवर्क धीमा है" शिकायतें इन छह में से एक हैं जो फ्रेमवर्क का भेष धारण कर रही हैं।
सबसे बड़ी चीज़ को पहले ठीक करें
सब कुछ एक साथ अनुकूलित न करें। अपने फील्ड या लैब डायग्नोस्टिक्स में LCP प्रविष्टि खोलें, वह तत्व खोजें जो LCP है (आमतौर पर हीरो छवि या हेडलाइन), और उस एक चीज को तेज़ करें: सही आकार, प्रीलोड किया गया, CDN से परोसा गया। फिर से मापें। फिर महत्वपूर्ण पथ पर चलने वाली JavaScript को काटें। फिर से मापें।
मार्केटिंग साइट के लिए व्यावहारिक क्रम: LCP तत्व, फिर तीसरे पक्ष की JS, फिर फ़ॉन्ट लोडिंग, फिर कैश और TTFB, फिर CLS सफाई, फिर सूक्ष्म अनुकूलन। पहले दो के बाद रुकने से अक्सर एक वाणिज्यिक साइट को CWV बैंड में पास करने योग्य बना दिया जाता है।
WordPress नोट: एक प्लगइन आहार और प्रबंधित होस्टिंग पर एक वास्तविक पेज कैश एजेंसियां जितना मानती हैं उससे अधिक बार एक थीम रीराइट को हराते हैं। Next.js और Astro नोट: ब्रोशर को SSR न करें। सार्वजनिक पृष्ठों के लिए स्टेटिक या कैश्ड HTML; प्रमाणित उत्पाद सतहों के लिए सर्वर कार्य को आरक्षित करें। विवरण Next.js बनाम Astro बनाम WordPress गाइड में हैं।
मुख्य बात: एक मापा गया LCP जीत सप्ताह भर के अनुमानपूर्ण रीफ़ैक्टर को हराता है।
स्टैक-विशिष्ट विफलता मोड
WordPress
पेज बिल्डर हर पेज पर सभी विजेट CSS भेज रहे हैं। कैश न किए गए WooCommerce टेम्पलेट। भारी related-posts क्वेरी। ऑटोलोड विकल्प टेबल जो वर्षों से बढ़ते गए। समाधान पथ: HTML को edge पर कैश करें, प्लगइन कम करें, बिल्डर के fold के नीचे वाले सेक्शन को lazy-load करें, डेटाबेस autoload ब्लोट को ठीक करें।
Next.js
क्लाइंट कंपोनेंट पूरे पेज को wrap कर रहे हैं। sequential awaits की वॉटरफॉल। गलत loader के जरिए इमेज। ISR या SSR उन पेजों पर जो कभी personalize नहीं होते। समाधान पथ: डिफ़ॉल्ट रूप से Server Components, जहां संभव हो static, हर route पर JS bundle को audit करें।
Astro और अन्य static stacks
आमतौर पर fast होते हैं जब तक आप किसी प्रोडक्ट ऐप के आकार का SPA island दोबारा न ले आएं, या किसी विशाल CMS मीडिया को hotlink न करें। समाधान पथ: islands को छोटा रखें, पाइपलाइन में इमेज को process करें, static साइट में WordPress की आदतें न जोड़ें।
मुख्य बात: समाधान को स्टैक से मेल खिलाएं। Replatforming शायद ही कभी पहला performance कदम है।
अच्छा क्या दिखता है
मोबाइल पर 75th percentile में वास्तविक विजिटर पर मापे गए लक्ष्य: Largest Contentful Paint 2.5 सेकंड से कम, Interaction to Next Paint 200 मिलीसेकंड से कम, Cumulative Layout Shift 0.1 से कम। समय-से-पहली-बाइट को लगभग 0.8 सेकंड से कम रखें ताकि सर्वर critical path से बाहर रहे।
इन्हें हिट करें और साइट किसी भी तरह slow नहीं है जिसे विजिटर या Google दंडित करेंगे, भले ही कोई synthetic vanity score क्या कहे। इससे अधिक कुछ भी polish है। किसी perfect Lighthouse screenshot का पीछा करने की बजाय प्रोडक्ट ship करें।
अगर आप इस काम का checklist फॉर्म चाहते हैं, Core Web Vitals checklist का इस्तेमाल करें। अगर आपको प्रति-metric सर्जरी चाहिए, LCP, INP, और CLS fix guide का इस्तेमाल करें। अगर बिजनेस केस एक rebuild है, तो redesign deck की बजाय performance pillar से शुरुआत करें।
मुख्य बात: Passing field CWV "क्या यह slow है?" का finish line है, एक perfect Lighthouse screenshot नहीं।
DIY कब छोड़ें और मदद कब लें
DIY काफी है जब LCP element स्पष्ट हो, third parties कम हों, और आप hosting को नियंत्रित करते हों। मदद लाएँ जब field data दो ईमानदार fix cycles के बाद भी red रहे, जब stack एक hybrid हो जिसे team में कोई नहीं समझता, या जब revenue pages एक हफ्ता और speculative changes नहीं झेल सकते।
किसी बाहरी व्यक्ति के लिए एक उपयोगी brief: तीन URLs जो मायने रखते हैं, field screenshots, LCP element के नाम, host और CDN, और उन tags की सूची जिन्हें आप हटा नहीं सकते। यह पैकेज एक अस्पष्ट "site slow है" को एक-sprint की जॉब में बदल देता है।
अगर बातचीत एक पूरे redesign में बदल जाए, तो रुकें। Performance work और redesign work तब तक अच्छी तरह काम नहीं करते जब तक redesign का एक स्पष्ट CWV budget न हो। जब business अभी भी मौजूदा templates पर निर्भर हो तो पहले उन्हें ठीक करें।
मुख्य बात: दो असफल fix cycles या कोई स्पष्ट owner नहीं होना — यह DIY और paid performance pass के बीच की लाइन है।