मुफ़्त परफ़ॉर्मेंस टूल

वेबसाइट स्पीड टेस्ट

हम आपके पेज को धीमे 4G कनेक्शन पर एक मिड-रेंज फ़ोन की तरह लोड करते हैं, मापते हैं कि मुख्य कंटेंट कितनी जल्दी दिखता है और पेज कितना उछलता है, और दिखाते हैं कि उसे भारी क्या बनाता है। जब Google के पास आपकी साइट का रियल-यूज़र डेटा होता है, तो आप उसे भी देखते हैं।

मुफ़्त। आम तौर पर एक मिनट से कम में पूरा हो जाता है।

यह टूल क्या जांचता है

  • धीमे 4G पर एक फ़ोन

    पेज Chromium में Moto G Power जैसे फ़ोन (412 × 823) की तरह लोड होता है, 150 ms लेटेंसी, लगभग 1.6 Mbps डाउनलोड और 750 Kbps अपलोड, और 4× धीमे CPU के साथ। Lighthouse मोबाइल टेस्ट के लिए यही प्रोफ़ाइल इस्तेमाल करता है।

  • Largest Contentful Paint

    पहली स्क्रीन की सबसे बड़ी इमेज या टेक्स्ट ब्लॉक कब रेंडर होना पूरा हुआ, और वह कौन-सा एलिमेंट था।

  • Cumulative Layout Shift

    पेज लोड होते समय दिखने वाला कंटेंट कितना अचानक अपनी जगह से खिसका।

  • Total Blocking Time

    स्क्रिप्ट ने ब्राउज़र को कितनी देर तक इतना व्यस्त रखा कि वह किसी टैप का जवाब न दे सके: हर लंबे टास्क का 50 ms से ऊपर का हिस्सा, जोड़कर। लैब में यह Interaction to Next Paint की जगह इस्तेमाल होने वाला माप है।

  • पेज क्या डाउनलोड करता है

    कुल बाइट और रिक्वेस्ट, जिन्हें इमेज, स्क्रिप्ट, CSS और फ़ॉन्ट में बाँटा जाता है, और थर्ड-पार्टी से आने वाला हिस्सा।

  • भारी इमेज और रेंडर-ब्लॉकिंग फ़ाइलें

    150 KB से बड़ी इमेज या वे इमेज जो दिखाई जाने वाली जगह से कहीं ज़्यादा चौड़ी हैं, और वे CSS और स्क्रिप्ट फ़ाइलें जो पहले रेंडर को रोकती हैं।

  • Chrome से रियल-यूज़र डेटा

    फ़ोन पर आपके ओरिजिन के लिए 75वें पर्सेंटाइल पर Google की Chrome UX Report: LCP, INP और CLS, जब Google के पास साइट का पर्याप्त ट्रैफ़िक हो।

यह क्या नहीं जांच सकता

  • हर बार एक जैसे नंबर नहीं दे सकता। लैब नतीजे नेटवर्क, सर्वर लोड और थर्ड-पार्टी स्क्रिप्ट के साथ बदलते रहते हैं, इसलिए किसी एक रन के बजाय रुझानों की तुलना करें।
  • PageSpeed Insights से बिल्कुल मेल नहीं खा सकता। दोनों मिलती-जुलती फ़ोन प्रोफ़ाइल इस्तेमाल करते हैं, लेकिन अलग-अलग मशीनों और नेटवर्क पर चलते हैं।
  • लैब में INP नहीं माप सकता। INP के लिए असली इंटरैक्शन चाहिए, इसलिए लैब टेस्ट TBT दिखाता है, और फ़ील्ड डेटा उपलब्ध होने पर INP दिखाता है।
  • हर साइट का फ़ील्ड डेटा नहीं दिखा सकता। Chrome UX Report पिछले 28 दिनों को कवर करती है, और केवल उन ओरिजिन को जिन पर पर्याप्त Chrome ट्रैफ़िक हो।
  • आपके डाले गए एक पेज से ज़्यादा टेस्ट नहीं कर सकता। पेड परफ़ॉर्मेंस सुधार रिपोर्ट 3 मुख्य पेज टेस्ट करती है और कारणों को सुधारों के साथ प्राथमिकता के क्रम में रखती है।

यह क्यों ज़रूरी है

जो पेज ऑफ़िस के Wi-Fi और तेज़ लैपटॉप पर तुरंत खुलता लगता है, वह कमज़ोर सिग्नल वाले मिड-रेंज फ़ोन पर कई सेकंड ले सकता है। यह टेस्ट यही स्थिति दोहराता है, क्योंकि भारी इमेज और स्क्रिप्ट सबसे ज़्यादा नुकसान यहीं करती हैं।

Core Web Vitals उसी अनुभव को मापने के लिए Google के पैमाने हैं: लोडिंग (LCP), रिस्पॉन्सिवनेस (INP) और विज़ुअल स्टेबिलिटी (CLS)। Google इन्हें रैंकिंग में इस्तेमाल करता है, लेकिन कहता है कि अच्छा पेज अनुभव प्रासंगिक कंटेंट से ज़्यादा भारी नहीं पड़ता। इनका बड़ा असर लोगों पर होता है: धीमा या उछलता पेज विज़िटर को कुछ भी पढ़ने से पहले ही खो देता है।

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

नतीजों को कैसे समझें

Largest Contentful Paint (LCP)
2.5 s से कम हो तो अच्छा, 4 s से ज़्यादा हो तो ख़राब। अगर LCP एलिमेंट एक इमेज है, तो उसका साइज़ और लोडिंग प्राथमिकता सबसे अहम हैं; अगर वह टेक्स्ट है, तो वेब फ़ॉन्ट और रेंडर-ब्लॉकिंग CSS देखें।
Cumulative Layout Shift (CLS)
0.1 से कम हो तो अच्छा, 0.25 से ज़्यादा हो तो ख़राब। बिना इकाई वाला एक स्कोर, जो यह जोड़ता है कि स्क्रीन का कितना हिस्सा खिसका और कितनी दूर।
Total Blocking Time (TBT)
200 ms से कम हो तो अच्छा, 600 ms से ज़्यादा हो तो ख़राब। ज़्यादा TBT का मतलब है कि असली यूज़र के टैप पर जवाब धीमा मिलने की संभावना है।
बाइट और रिक्वेस्ट
कोई आधिकारिक सीमा नहीं है; देखें कि किस प्रकार का हिस्सा सबसे ज़्यादा है। आमतौर पर इमेज का हिस्सा सबसे बड़ा होता है, और थर्ड-पार्टी का बड़ा हिस्सा ऐप, टैग और विजेट की ओर इशारा करता है।
भारी इमेज
150 KB से बड़ी हर इमेज, या जो दिखाए जाने से कहीं ज़्यादा चौड़ी डाउनलोड होती है, उसकी फ़ाइल साइज़ और डाइमेंशन के साथ।
रेंडर-ब्लॉकिंग फ़ाइलें (Render-blocking files)
CSS और सिंक्रोनस स्क्रिप्ट, जिन्हें ब्राउज़र को कुछ भी दिखाने से पहले डाउनलोड करना ज़रूरी है।
फ़ील्ड डेटा (75वाँ पर्सेंटाइल)
पिछले 28 दिनों में फ़ोन पर असली Chrome यूज़र। 75वें पर्सेंटाइल का मतलब है कि हर चार में से तीन पेज लोड कम से कम इतने तेज़ थे। INP 200 ms से कम हो तो अच्छा और 500 ms से ज़्यादा हो तो ख़राब है।
कोई फ़ील्ड डेटा नहीं
Google के पास आपके ओरिजिन के लिए पर्याप्त Chrome ट्रैफ़िक नहीं है। इससे आपकी स्पीड के बारे में कुछ पता नहीं चलता; लैब नतीजों पर भरोसा करें।

सबसे आम समस्याओं को कैसे ठीक करें

  • धीमी LCP इमेज

    हीरो इमेज को उसी साइज़ में दें जिसमें वह दिखाई जाती है, srcset के साथ, WebP या AVIF में। उसे lazy-load न करें, fetchpriority="high" जोड़ें, और उसे किसी स्क्रिप्ट या CSS बैकग्राउंड से लोड करने के बजाय HTML में img एलिमेंट के रूप में रखें।

  • लोड होते समय उछलने वाला कंटेंट

    इमेज, वीडियो और एम्बेड को width और height एट्रिब्यूट या CSS aspect-ratio दें। बैनर, कुकी नोटिस और विज्ञापनों के लिए जगह पहले से छोड़ें, या उन्हें ऐसे ओवरले के रूप में दिखाएँ जो कंटेंट को नीचे न धकेलें। वेब फ़ॉन्ट के लिए font-display: optional इस्तेमाल करें, या मिलते-जुलते साइज़ वाला फ़ॉलबैक फ़ॉन्ट।

  • ज़्यादा Total Blocking Time

    सबसे पहले वे ऐप, टैग और प्लगइन हटाएँ जिन्हें आप अब इस्तेमाल नहीं करते; उनकी स्क्रिप्ट अक्सर इस्तेमाल बंद करने के बाद भी बनी रहती हैं। चैट, रिव्यू और एनालिटिक्स को defer के साथ या पेज के इंटरैक्टिव होने के बाद लोड करें। Shopify पर Online Store › Themes › Customize › App embeds जाँचें।

  • रेंडर-ब्लॉकिंग CSS और स्क्रिप्ट

    जिन स्क्रिप्ट को पहले पेंट से पहले चलने की ज़रूरत नहीं है, उनमें defer जोड़ें, पहली स्क्रीन के लिए ज़रूरी थोड़ी-सी CSS को इनलाइन करें, और उन फ़ीचर की स्टाइलशीट हटाएँ जिन्हें पेज इस्तेमाल नहीं करता।

  • बहुत भारी इमेज

    इमेज अपलोड करने से पहले उनका साइज़ छोटा करें (पूरी चौड़ाई वाले बैनर के लिए लगभग 2000 px चौड़ाई काफ़ी है) और उन्हें कंप्रेस करें। जब थीम माँगती है, तो Shopify और WordPress अपने आप छोटे वर्ज़न दे सकते हैं, इसलिए जाँचें कि आपकी थीम रिस्पॉन्सिव इमेज साइज़ इस्तेमाल करती है।

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

मेरे नतीजे PageSpeed Insights से अलग क्यों हैं?

लैब टेस्ट मशीन, नेटवर्क और उस पल पर निर्भर करते हैं। PageSpeed Insights Google के सर्वर पर Lighthouse चलाता है और धीमे कनेक्शन को सिम्युलेट करता है, जबकि हम थ्रॉटलिंग को एक असली ब्राउज़र में लागू करते हैं। मिलती-जुलती रेंज की उम्मीद करें, बिल्कुल एक जैसे नंबरों की नहीं।

अच्छा LCP कितना होता है?

web.dev के अनुसार, कम से कम 75% पेज लोड के लिए 2.5 सेकंड या उससे कम। 4 सेकंड से ज़्यादा ख़राब है।

मेरी साइट का रियल-यूज़र डेटा क्यों नहीं है?

Chrome UX Report में केवल वे ओरिजिन शामिल होते हैं जो सार्वजनिक रूप से खोजे जा सकते हैं और जिन पर उपयोग के आँकड़े शेयर करने वाले Chrome यूज़र पर्याप्त संख्या में आते हैं। कई छोटी साइटें उस स्तर तक नहीं पहुँचतीं; लैब टेस्ट फिर भी दिखाता है कि क्या ठीक करना है।

डेस्कटॉप के बजाय धीमे फ़ोन पर टेस्ट क्यों?

क्योंकि समस्याएँ सबसे पहले वहीं दिखती हैं। तेज़ लैपटॉप उन भारी इमेज और स्क्रिप्ट को छिपा देता है जो मिड-रेंज फ़ोन पर कई सेकंड ले लेती हैं, और Lighthouse अपने मोबाइल टेस्ट के लिए यही फ़ोन प्रोफ़ाइल इस्तेमाल करता है।

First Input Delay का क्या हुआ?

मार्च 2024 में Interaction to Next Paint (INP) ने Core Web Vital के रूप में First Input Delay की जगह ले ली। INP पूरी विज़िट के दौरान होने वाले इंटरैक्शन की देरी को देखता है, केवल पहले इंटरैक्शन को नहीं।

स्रोत

संबंधित टूल

परफ़ॉर्मेंस सुधार रिपोर्ट ($55, एक बार का भुगतान) पूरे मुफ़्त स्कैन से शुरू होती है और उसमें और पेज, हर नतीजे के लिए करने वाला बदलाव, एक PDF और आपके सुधारों की पुष्टि के लिए री-टेस्ट जोड़ती है।

परफ़ॉर्मेंस सुधार रिपोर्ट के बारे में