आप अपनी ही वेबसाइट के किसी लिंक पर क्लिक करते हैं और इंतज़ार करते हैं। टैब पर spinner घूमता है, स्क्रीन ख़ाली रहती है, और एक-दो सेकंड तक कुछ होता ही नहीं लगता। फिर पेज एक साथ दिख जाता है और उसके बाद तेज़ी से लोड होता है। यह इमेज की वजह से नहीं है, और स्क्रिप्ट की वजह से भी नहीं। पेज शुरू होने से पहले ही धीमा है, क्योंकि सर्वर जवाब देने में समय ले रहा है।
इस इंतज़ार का एक नाम है: Time to First Byte, या TTFB। यह विज़िटर के बाक़ी पूरे अनुभव की नींव है, और यह परफ़ॉर्मेंस की सबसे आसानी से ठीक होने वाली समस्याओं में से भी एक है। यह चेकलिस्ट बताती है कि सर्वर जवाब देने में धीमा क्यों होता है और कौन से व्यावहारिक सुधार इसे घटाते हैं।
TTFB असल में क्या मापता है
TTFB, ब्राउज़र के पेज माँगने और रिस्पॉन्स का पहला byte पाने के बीच का समय है। इसमें शामिल हैं:
- कनेक्शन सेटअप: डोमेन खोजना, सर्वर से जुड़ना और HTTPS तय करना।
- Redirects, अगर आपका माँगा पता ब्राउज़र को पहले कहीं और भेजता है।
- सर्वर की प्रोसेसिंग: पेज बनाने में सर्वर का लगाया समय, जिसमें अक्सर कोड और डेटाबेस queries चलती हैं।
- नेटवर्क पर वापस आता पहला डेटा।
पहला byte आने तक स्क्रीन पर कुछ भी नहीं दिख सकता। इसीलिए धीमा TTFB Google के Core Web Vitals में से एक, Largest Contentful Paint को नीचे खींचता है, पेज का बाक़ी हिस्सा कितना भी अच्छी तरह ऑप्टिमाइज़ हो; Core Web Vitals पर हमारी गाइड बताती है कि दोनों कैसे जुड़े हैं।
अच्छा TTFB कितना होता है?
व्यावहारिक लक्ष्य के रूप में अपने पेजों के लिए 600 ms से कम रखें, और अच्छी तरह कॉन्फ़िगर किए सर्वर या CDN से भेजे गए cache पेजों के लिए लगभग 200 ms से कम। Google का Core Web Vitals दिशानिर्देश असली यूज़र्स के लिए, 75वें percentile पर मापकर, लगभग 0.8 सेकंड को अच्छा मानता है।
इसे सही तरह कैसे मापें
अपने लैपटॉप से मापने में आपका कनेक्शन और आपका कंप्यूटर जो कुछ और कर रहा है, वह भी मिल जाता है। Website Speed Tester हमारे सर्वर से पेज का HTML डाउनलोड करता है और सर्वर रिस्पॉन्स टाइम, पूरे HTML का डाउनलोड टाइम, redirects की संख्या और वे कितना समय जोड़ते हैं, कंप्रेशन से पहले और बाद में HTML का साइज़, कंप्रेशन का तरीक़ा, और Cache-Control हेडर बताता है। यह छह साफ़ लिखी जाँचों से नतीजे को A से F तक ग्रेड करता है, ताकि आप ठीक-ठीक देख सकें कि क्या ठीक करना है।
भरोसेमंद माप के लिए दो सुझाव:
- टेस्ट दो बार चलाएँ। पहली रिक्वेस्ट ठंडे cache से टकरा सकती है या सोए हुए सर्वर को जगा सकती है। दूसरा नतीजा उसके ज़्यादा क़रीब है जो ज़्यादातर विज़िटर को मिलता है।
- सिर्फ़ होमपेज नहीं, और पेज भी टेस्ट करें। प्रोडक्ट, कैटेगरी और लेख वाले पेज अक्सर अलग टेम्पलेट और अलग मात्रा में डेटाबेस का काम इस्तेमाल करते हैं।
चेकलिस्ट
1. पेज कैशिंग चालू करें
ज़्यादातर डायनामिक साइटों पर, ख़ास तौर पर WordPress पर, सर्वर हर विज़िट पर हर पेज शुरू से बनाता है: PHP चलाना, डेटाबेस से query करना, HTML जोड़ना। पेज cache तैयार HTML रख लेता है और अगले विज़िटर को तुरंत भेज देता है।
यह आम तौर पर सबसे बड़ा उपलब्ध सुधार है। cache का TTFB को एक सेकंड से काफ़ी ज़्यादा से घटाकर उसके छोटे-से हिस्से तक ले आना आम बात है। ज़्यादातर WordPress होस्ट बिल्ट-इन कैशिंग देते हैं, और कैशिंग प्लगइन भी आसानी से मिलते हैं। बस उन पेजों को बाहर रखना याद रखें जिन्हें निजी रहना चाहिए, जैसे cart, checkout और अकाउंट वाले हिस्से।
2. ग़ैर-ज़रूरी redirects हटाएँ
हर redirect असली पेज शुरू होने से पहले एक पूरा round trip जोड़ता है। http://example.com टाइप करने वाला विज़िटर कुछ भी लोड होने से पहले https://example.com और फिर https://www.example.com से गुज़र सकता है। अपने आम प्रवेश पतों को Redirect Checker से जाँचें और पक्का करें कि हर एक एक ही क़दम में अपनी मंज़िल तक पहुँचे। 301 बनाम 302 redirects पर हमारी गाइड बताती है कि चेन को कैसे छोटा करें।
3. कंप्रेशन चालू करें
Gzip या Brotli कंप्रेशन आम तौर पर HTML को 70 से 90 प्रतिशत छोटा कर देता है, इसलिए वह काफ़ी तेज़ी से पहुँचता है। यह आम तौर पर आपके होस्टिंग पैनल, सर्वर कॉन्फ़िगरेशन या CDN में एक सेटिंग होती है। स्पीड टेस्ट दिखाता है कि कंप्रेशन चालू है या नहीं।
4. CDN इस्तेमाल करें
Content delivery network आपकी साइट को हर विज़िटर के पास की जगहों से भेजता है। पूरे पेज cache किए बिना भी यह कनेक्शन सेटअप छोटा कर सकता है, और edge पर पूरे पेज की कैशिंग के साथ, आपके सर्वर से दूर के विज़िटर के लिए रिस्पॉन्स टाइम नाटकीय रूप से घट सकता है। यह देखने के लिए कि आपकी साइट दुनिया के अलग-अलग हिस्सों से कैसा प्रदर्शन करती है, Ping & Uptime Checker से 30 से ज़्यादा देशों से HTTP जाँच चलाएँ।
5. हर पेज का काम घटाएँ
अगर पेज cache नहीं हो सकते, तो उन्हें बनाना सस्ता करें:
- ग़ैर-ज़रूरी प्लगइन बंद करें। हर प्लगइन ऐसा कोड जोड़ सकता है जो हर रिक्वेस्ट पर चलता है।
- धीमी डेटाबेस queries ढूँढें, जो अक्सर related-posts विजेट, जटिल फ़िल्टर या फूली हुई options टेबल से आती हैं।
- अगर आपका होस्ट सपोर्ट करता है तो object caching (जैसे Redis या Memcached) इस्तेमाल करें, ताकि बार-बार आने वाले डेटाबेस नतीजे मेमोरी में रहें।
- PHP को मौजूदा वर्ज़न पर अपडेट करें। नए वर्ज़न वही कोड काफ़ी तेज़ी से चलाते हैं।
6. अपनी होस्टिंग जाँचें
अगर आप ऊपर का सब कर चुके हैं और TTFB अब भी ज़्यादा है, तो हो सकता है सर्वर ख़ुद कमज़ोर हो या उस पर भीड़ हो। बहुत सस्ती shared होस्टिंग एक ही मशीन पर सैकड़ों साइटें रख सकती है। ध्यान देने वाले संकेत: रिस्पॉन्स टाइम जो दिन भर बेतहाशा बदलता है, या जो cache पेजों के लिए भी धीमा रहता है। बेहतर प्लान या होस्ट पर जाना सही फ़ैसला हो सकता है।
7. समझदारी से cache हेडर सेट करें
Cache-Control हेडर ब्राउज़र और CDN को बताता है कि वे रिस्पॉन्स की कॉपी कितनी देर रख सकते हैं। हर चीज़ पर no-store या no-cache के साथ भेजे गए पेज हर बार सर्वर तक पूरा चक्कर लगवाते हैं, दोबारा आने वाले विज़िटर के लिए भी। इमेज, CSS और JavaScript जैसी स्टैटिक फ़ाइलें आम तौर पर लंबे समय तक cache की जा सकती हैं, जबकि HTML पेज अक्सर थोड़ी देर cache या revalidate किए जा सकते हैं। स्पीड टेस्ट आपके पेज का भेजा हेडर दिखाता है, ताकि आप पक्का कर सकें कि आपका कैशिंग सेटअप वही कर रहा है जो आप चाहते थे।
8. सही सर्वर लोकेशन चुनें
भौतिक दूरी ऐसी देरी जोड़ती है जिससे बचा नहीं जा सकता। अगर आपके ज़्यादातर विज़िटर भारत में हैं, तो अमेरिका का सर्वर हर रिक्वेस्ट में latency जोड़ता है। अपनी साइट, या कम से कम अपना CDN edge, अपने दर्शकों के पास होस्ट करें।
काम का एक व्यावहारिक क्रम
| क़दम | मेहनत | आम असर |
|---|---|---|
| पेज कैशिंग | कम | बहुत ज़्यादा |
| redirect के क़दम हटाना | कम | मध्यम |
| कंप्रेशन | कम | मध्यम |
| CDN | कम से मध्यम | मध्यम से ज़्यादा |
| प्लगइन और query की सफ़ाई | मध्यम | मध्यम |
| PHP अपग्रेड | कम से मध्यम | मध्यम |
| बेहतर होस्टिंग | मध्यम | ज़्यादा, अगर रुकावट होस्टिंग है |
जब साइट सिर्फ़ कभी-कभी धीमी हो
अगर आपकी साइट ज़्यादातर समय तेज़ है लेकिन कभी-कभी रेंगती है या time out हो जाती है, तो वजह आम तौर पर संसाधनों की सीमा होती है: ट्रैफ़िक में उछाल, बैकअप या शेड्यूल किए कामों जैसे बैकग्राउंड काम, या उसी सर्वर पर दूसरी साइटें। जाँचें कि धीमे दौर बैकअप या cron jobs के साथ मेल खाते हैं या नहीं, और क्या आपका होस्ट CPU या मेमोरी की सीमा पार होने की जानकारी देता है। अगर साइट कभी-कभी पूरी तरह फ़ेल हो जाती है, तो आपकी वेबसाइट बंद है या सिर्फ़ आपके लिए पर हमारी गाइड लोकल समस्या और असली outage में फ़र्क़ करने में मदद करती है।
पहले byte से तेज़
विज़िटर आपका सर्वर कभी नहीं देखते। वे बस पेज दिखने से पहले का ठहराव महसूस करते हैं, और हर बार उसे नोटिस करते हैं। अपने मुख्य पेजों को Website Speed Tester से टेस्ट करें, चेकलिस्ट पर ऊपर से काम करें, और हर बदलाव के बाद फिर टेस्ट करें। कुछ ख़ास सुधार, आम तौर पर कैशिंग से शुरू करके, अक्सर आपकी पूरी साइट को तेज़ महसूस कराने के लिए काफ़ी होते हैं।
