मुख्य सामग्री पर जाएँ
URL → Server speed report

Website Speed Test – सर्वर रिस्पॉन्स और TTFB जाँचें

मापें कि किसी वेबसाइट का सर्वर कितनी तेज़ी से जवाब देता है: time to first byte, डाउनलोड टाइम, redirect, पेज साइज़, कंप्रेशन और कैशिंग, साफ़ A–F ग्रेड के साथ।

टूल के बटन और संदेश अभी अंग्रेज़ी में हैं। टूल का काम करने का तरीका अंग्रेज़ी पेज जैसा ही है।

इस टूल के बारे में

वेबसाइट स्पीड और सर्वर रिस्पॉन्स टेस्टर के बारे में

वेबसाइट स्पीड और सर्वर रिस्पॉन्स टेस्टर किसी भी सार्वजनिक पेज का HTML हमारे सर्वर से डाउनलोड करता है और मापता है कि क्या होता है: सर्वर को पहला byte भेजने में कितना समय लगता है (TTFB), पूरा HTML आने में कितना समय लगता है, रास्ते में कितने redirect होते हैं और वे कितना समय जोड़ते हैं, कंप्रेशन से पहले और बाद में HTML का साइज़, gzip या Brotli कंप्रेशन इस्तेमाल होता है या नहीं, कौन सा Cache-Control हेडर भेजा जाता है, और पेज कितनी स्क्रिप्ट, स्टाइलशीट और इमेज का हवाला देता है। A से F तक का ग्रेड छह आसान जाँचों से बनता है, जो हर नतीजे के साथ दिखाई जाती हैं, ताकि आप ठीक-ठीक देख सकें कि साइट को वह स्कोर क्यों मिला। यह टेस्ट सर्वर की स्पीड मापता है, यानी वह हिस्सा जो आपकी होस्टिंग पर आपके नियंत्रण में है। यह इमेज लोड नहीं करता और JavaScript नहीं चलाता, इसलिए यह Lighthouse स्कोर नहीं है; LCP, CLS और INP जैसे पूरे ब्राउज़र मेट्रिक के लिए नतीजे में सीधे Google PageSpeed Insights का लिंक है, या आप हमारा Core Web Vitals Checker इस्तेमाल कर सकते हैं। हर नतीजा redirect के बाद का आख़िरी पता दिखाता है, ताकि आप पक्का कर सकें कि जवाब उसी पेज ने दिया जिसे आप टेस्ट करना चाहते थे। क्योंकि टेस्ट HTML के एक डाउनलोड को मापता है, यह होस्टिंग, कैशिंग और CDN सेटिंग की तुलना करने का तेज़ तरीक़ा है: एक चीज़ बदलें, टेस्ट फिर चलाएँ, और सर्वर रिस्पॉन्स टाइम की तुलना करें।

वेबसाइट की सर्वर स्पीड और TTFB जाँचने वाले टूल का चित्र

सर्वर स्पीड कब टेस्ट करें

पता करें कि रुकावट सर्वर में तो नहीं

पहली बार धीमा लोड

अगर किसी पेज पर कुछ भी दिखने में बहुत समय लगता है, तो आम तौर पर वजह धीमा TTFB होता है।

उदाहरण2,400 ms का TTFB धीमे सर्वर-साइड कोड, न मौजूद पेज कैश या ज़्यादा लोड वाले डेटाबेस की ओर इशारा करता है।

होस्टिंग या प्लगइन बदलने के बाद

किसी बदलाव से पहले और बाद में TTFB और पेज साइज़ की तुलना करें।

उदाहरणकैशिंग प्लगइन चालू करने से पहले और बाद में होमपेज टेस्ट करें और TTFB की तुलना करें।

बहुत ज़्यादा redirect

http → https → www → आख़िरी पेज जैसी चेन हर क़दम पर एक round trip जोड़ती है।

उदाहरणटेस्ट दिखाता है कि 3 redirect 420 ms जोड़ रहे हैं; अपने लिंक आख़िरी URL पर अपडेट करें।

वेब होस्ट चुनना

होस्ट बदलने से पहले अलग-अलग होस्ट पर चल रही साइटों के सर्वर रिस्पॉन्स टाइम की तुलना करें।

उदाहरणअलग-अलग प्लान पर दो डेमो साइटें 180 ms और 950 ms का TTFB देती हैं, जो साफ़ बताता है कि कौन सा होस्ट धीमा है।

CDN या कैश प्लगइन जाँचना

रिस्पॉन्स टाइम की तुलना करके पक्का करें कि कैशिंग सच में काम कर रही है।

उदाहरणपेज कैशिंग चालू करने के बाद दूसरे रन पर TTFB 1.2 s से घटकर 90 ms हो जाता है।

ज़्यादा स्क्रिप्ट पहचानना

ज़्यादा स्क्रिप्ट गिनती अक्सर बहुत सारे प्लगइन या ट्रैकिंग टैग की ओर इशारा करती है।

उदाहरणरिसोर्स गिनती 34 बाहरी स्क्रिप्ट दिखाती है, इसलिए टीम जाँचती है कि कौन से ट्रैकिंग टैग अब भी ज़रूरी हैं।

नतीजों पर कैसे काम करें

वे सुधार जो आम तौर पर सबसे ज़्यादा मायने रखते हैं

600 ms से ज़्यादा TTFB

पेज कैशिंग जोड़ें, CDN इस्तेमाल करें, या ज़्यादा लोड वाले सर्वर को अपग्रेड करें। WordPress के लिए कैशिंग प्लगइन आम तौर पर सबसे ज़्यादा मदद करता है।

कंप्रेशन नहीं है

अपने वेब सर्वर या CDN में gzip या Brotli चालू करें। यह आम तौर पर HTML को 70–90% छोटा कर देता है।

एक से ज़्यादा redirect

सीधे आख़िरी URL पर लिंक करें, और http:// और non-www को एक ही क़दम में सीधे आख़िरी पते पर redirect करें।

LCP, CLS और INP चाहिए?

इनके लिए असली ब्राउज़र चाहिए। Google का डेटा देखने के लिए Core Web Vitals Checker इस्तेमाल करें।

Core Web Vitals Checker खोलें

पेज कैशिंग चालू करें

WordPress पर ज़्यादातर धीमा TTFB हर विज़िट पर पूरा पेज बनाने से आता है। पेज कैश उसकी जगह पहले से तैयार कॉपी भेजता है।

टेस्ट दो बार चलाएँ

पहली रिक्वेस्ट ठंडे कैश या सर्वर को जगा सकती है। ज़्यादातर विज़िटर को मिलने वाली स्पीड देखने के लिए दूसरे रन से तुलना करें।