Site speed और conversion rate drop: वह बदलाव कैसे खोजें जिसने वेबसाइट धीमी की
Site speed से conversion rate drop तब होता है जब कोई release, नया script या भारी पेज वेबसाइट को धीमा कर देता है और कम visitors खरीदारी या फ़ॉर्म पूरा करते हैं। इसे पक्का करने के लिए LCP और INP का field data देखें, धीमापन शुरू होने की तारीख निकालें और उसे उसी दिन के बदलाव से मिलाएं।
क्या धीमी वेबसाइट से conversion rate गिर सकता है?
हां, लेकिन धीमापन तभी वजह है जब वह गिरावट से पहले शुरू हुआ हो और उन्हीं पेज और devices पर असर डाले जहां कन्वर्ज़न गिरे। Speed की समस्या अक्सर अकेले नहीं आती। जिस release ने पेज भारी किए, उसी ने कई बार layout, फ़ॉर्म या ट्रैकिंग भी बदल दी होती है।
Speed इसलिए मायने रखती है क्योंकि जो visitor मुख्य content का इंतज़ार करता है, या बटन दबाता है और कुछ नहीं होता, वह checkout या lead फ़ॉर्म तक पहुंचने से पहले ही चला जाता है। Google इन पलों को तीन Core Web Vitals से मापता है: लोडिंग के लिए Largest Contentful Paint (LCP), responsiveness के लिए Interaction to Next Paint (INP) और visual stability के लिए Cumulative Layout Shift (CLS)।
यह लेख हर सेकंड की देरी पर खोई बिक्री का कोई आंकड़ा नहीं देता। छपे हुए आंकड़े हर साइट पर अलग होते हैं और अक्सर vendors की studies से आते हैं। आप अपने data से यह दिखा सकते हैं कि एक तय तारीख वाले बदलाव ने पेज धीमे किए और उसी समय उन्हीं पेज पर कन्वर्ज़न गिरे। किसी भी गिरावट का पूरा तरीका जानने के लिए देखें क्लाइंट को कन्वर्ज़न drop कैसे समझाएं।
कौन से बदलाव आमतौर पर वेबसाइट को धीमा करते हैं?
ज़्यादातर speed regression किसी के publish किए गए बदलाव से आते हैं, Google या hosting से नहीं। आम तौर पर शक नए scripts, भारी media और code releases पर जाता है।
| बदलाव | पेज कैसे धीमा होता है | कहां देखें |
|---|---|---|
| Google Tag Manager में नया tag या pixel | ज़्यादा JavaScript main thread और bandwidth के लिए होड़ करता है, जिससे INP और LCP बिगड़ते हैं | GTM की version history |
| Inline library वाला Custom HTML tag | Code लगभग बिना रोक-टोक चलता है और tools दोष tag manager पर डालते हैं, tag पर नहीं | GTM container, browser के performance tools |
| Chat widget, A/B testing या heatmap script | हर पेज पर चलता है, अक्सर मुख्य content से पहले | Release notes, vendor का dashboard |
| नई hero image, video या slider | LCP element बड़ा होता है और पहला render देर से होता है | CMS history, deploy log |
| Theme, plugin या app update | हर template पर ज़्यादा CSS और JavaScript | CMS या platform का update log |
| Cookie banner या consent में बदलाव | Banner खुद LCP element बन सकता है या layout खिसका सकता है | Consent platform की settings, GTM |
| Hosting, CDN या cache में बदलाव | हर पेज पर server का जवाब धीमा | Hosting और CDN के logs |
Tags पर Google की guide बताती है कि main thread का समय tag manager और tags के JavaScript को evaluate और execute करने में जाता है। इसके लेखक बड़े containers और खराब INP के बीच correlation भी बताते हैं। Duplicate tags, जैसे HTML में hardcoded pixel जो GTM से दोबारा भी लगता है, बिना नया data दिए पेज भारी करते हैं। अगर किसी tag पर शक है, तो GTM version history से शुरू करें।
यह भी पढ़ें: Consent mode से कन्वर्ज़न में गिरावट: कैसे साबित करें कि बैनर ही वजह है · मार्केटिंग चेंज लॉग: यह क्या है और इसे कैसे रखें
कैसे जांचें कि वेबसाइट सच में धीमी हुई है?
शक वाले बदलाव से पहले और बाद का असली users का field data मिलाएं और lab tests सिर्फ़ वजह ढूंढने के लिए इस्तेमाल करें। Lighthouse का एक score सबूत नहीं है। Google खुद कहता है कि network, hardware और resources की होड़ की वजह से lab नतीजे हर run में बदलते हैं।
| मेट्रिक | क्या मापता है | Good | Poor |
|---|---|---|---|
| LCP | मुख्य content की लोडिंग | 2.5 s या कम | 4 s से ज़्यादा |
| INP | Tap, click और key press पर जवाब | 200 ms या कम | 500 ms से ज़्यादा |
| CLS | Layout का अचानक खिसकना | 0.1 या कम | 0.25 से ज़्यादा |
Google हर मेट्रिक को page views के 75th percentile पर आंकता है। ज़्यादातर मामलों में तीन tools काफ़ी हैं:
- PageSpeed Insights पिछले 28 दिनों का Chrome UX Report field data दिखाता है, URL level पर या URL का data कम हो तो origin level पर, साथ में Lighthouse lab test भी।
- Search Console की Core Web Vitals report मिलते-जुलते URLs को groups में रखती है और दिखाती है कि पिछले 28 दिनों में कितने good, needs improvement या poor हैं। जिन groups का data कम है, वे report में नहीं आते।
- आपका अपना real-user monitoring, अगर है, तो वही अकेला source है जो release वाले दिन रोज़ का उछाल दिखाता है।
तारीख निकालने में 28 दिन की window अहम है। PageSpeed Insights हर दिन पिछले 28 दिनों को जोड़ता है, इसलिए मंगलवार को शुरू हुआ धीमापन अगले हफ़्तों में धीरे-धीरे चढ़ती लाइन जैसा दिखता है, एक सीढ़ी जैसा नहीं। जिस तारीख पर लाइन मुड़ना शुरू करती है उसे पढ़ें और पुराने और नए version के lab tests से पक्का करें।
कैसे isolate करें कि किस बदलाव से वेबसाइट धीमी हुई और कन्वर्ज़न गिरे?
गिरावट से पहले वाले हफ़्ते के सारे बदलाव एक टाइमलाइन पर रखें, पहले ट्रैकिंग की गड़बड़ी को खारिज करें और फिर धीमे हुए पेज पर speed वाली hypothesis test करें। मापे गए कन्वर्ज़न टूटे हुए tag से भी गिर सकते हैं, इसलिए speed को दोष देने से पहले देखें कि नए version पर conversion tag अब भी fire हो रहा है।
- लिखें कि कन्वर्ज़न किस दिन गिरे और कहां: mobile checkout, एक लैंडिंग पेज या पूरी साइट।
- पिछले 7 से 14 दिनों के हर बदलाव की सूची बनाएं: releases, theme या plugin updates, GTM versions, नए scripts और consent बदलाव, साथ में ads के बदलाव जैसे bids, बजट और final URLs।
- उन बदलावों पर निशान लगाएं जिन्होंने गिरे हुए पेज को छुआ। हर पेज पर नया script और सिर्फ़ mobile checkout में गिरावट, mobile responsiveness की ओर इशारा करते हैं।
- पेज के पुराने और नए version का lab test करें और वह script या file खोजें जो सबसे ज़्यादा समय जोड़ती है।
उदाहरण: जयपुर का एक online furniture store पूछता है कि मंगलवार को mobile sales क्यों गिरी जबकि desktop ठीक रहा। बदलावों को एक लाइन में रखने पर दिखता है कि शुक्रवार को GTM में chat tag जुड़ा, शनिवार को product pages पर नया hero video लगा और ads में कोई बदलाव नहीं हुआ। Lab tests बताते हैं कि video अब LCP element है और पुरानी image से काफ़ी देर से लोड होता है। Team video की जगह static image लगाती है और अगले हफ़्ते mobile sales फिर से करीब ₹1,50,000 प्रति दिन पर लौट आती है। नाम और आंकड़े सिर्फ़ उदाहरण हैं।
- शुक्रGTMChat tag जोड़ा गया
- शनिWebsiteProduct pages पर hero video
- सोमGoogle Adsकोई बदलाव नहीं
- मंगलMobile sales गिरी
हर बदलाव एक टाइमलाइन पर हो तो आप देख लेते कि video गिरावट से तीन दिन पहले live हुआ, उसी template पर जहां mobile sales गिरी। Changeline में आप हर release, tag और consent बदलाव को तारीख, owner और वजह के साथ लॉग कर सकते हैं, और Google Ads के बदलाव अपने आप import होते हैं। इसलिए सवाल आने पर step 2 की सूची पहले से तैयार रहती है।
कैसे साबित करें कि कन्वर्ज़न धीमेपन से ही गिरे, किसी और वजह से नहीं?
आप यह दिखाकर साबित करते हैं कि तीन बातें मेल खाती हैं: धीमापन बदलाव के साथ शुरू हुआ, कन्वर्ज़न सिर्फ़ प्रभावित पेज और devices पर गिरे, और बदलाव हटाने या ठीक करने पर वापस आए।
- ट्रैकिंग fire हो रही है, जांचें
- Field data में धीमेपन की तारीख
- प्रभावित और बाकी पेज मिलाएं
- बदलाव हटाएं या ठीक करें
- कन्वर्ज़न की वापसी देखें
- Device और पेज के हिसाब से बांटें। अगर desktop का conversion rate टिका रहा, mobile का गिरा और धीमापन ज़्यादातर mobile पर है, तो यह सबूत है। हर device और हर पेज पर गिरावट किसी और वजह की ओर इशारा करती है।
- Traffic mix देखें। नया कैंपेन, audience या बजट उसी दिन कम तैयार visitors ला सकता है। Speed को दोष देने से पहले source के हिसाब से conversion rate देखें। बाकी वजहें conversion rate क्यों गिरता है में हैं।
- Control group रखें। जिन पेज पर नया script या file नहीं लगी, वे आपका control group हैं। अगर वे स्थिर रहे, तो बदलाव ही ज़्यादा संभावित वजह है।
- हटाएं और देखें। Script हटाना या release को rollback करना सबसे साफ़ test है। Rollback को भी अलग बदलाव के रूप में लॉग करें, ताकि वापसी की तारीख भी दर्ज रहे।
सबूत लिखकर रखें: बदलाव, तारीख, पहले और बाद के lab measurements, और प्रभावित व बाकी पेज का conversion rate। क्लाइंट या मैनेजर यही मांगेंगे, और इससे एक महीने बाद वही बहस फिर शुरू नहीं होती।
Speed regression को दोबारा आने से कैसे रोकें?
हर release और हर नए tag में speed की जांच शामिल करें, और रिकॉर्ड रखें कि क्या कब live हुआ। ज़्यादातर regressions इसलिए लौटते हैं क्योंकि कोई script फिर से जोड़ देता है या किसी को याद नहीं रहता कि उसे क्यों हटाया गया था।
चेकलिस्ट
- हर release से पहले और बाद में मुख्य templates का lab test करें
- GTM के हर नए tag का साइज़ और लोड होने की जगह जांचें
- बेकार tags को block करने की जगह pause या delete करें
- HTML में hardcoded duplicate tags हटाएं
- हर हफ़्ते PageSpeed Insights का field data देखें
- हर release, tag और consent बदलाव तारीख और owner के साथ लॉग करें
Google सलाह देता है कि बेकार tags को trigger exception से block करने की जगह pause या remove करें, क्योंकि block किया गया tag container में अपना code साथ ले जाता रहता है। एक साझा मार्केटिंग चेंज लॉग developers और marketers को देखने के लिए एक ही रिकॉर्ड देता है, और website change log साइट वाले हिस्से को विस्तार से बताता है।
हर साइट रिलीज़ को ट्रैफ़िक गिरावट के ठीक साथ देखें
Changeline आपकी टीम के बदलाव, इम्पोर्ट किए गए Google Ads बदलाव और वेबसाइट, ट्रैकिंग व CRM के बदलाव, हर क्लाइंट के लिए एक टाइमलाइन पर रखता है।
Free प्लान: 1 प्रोजेक्ट, 2 एडिटर, 15 दिन की हिस्ट्री। कार्ड की ज़रूरत नहीं।
अक्सर पूछे जाने वाले सवाल
PageSpeed Insights में speed regression दिखने में कितना समय लगता है?
PageSpeed Insights का field data पिछले 28 दिनों का होता है और रोज़ अपडेट होता है, इसलिए आज शुरू हुआ धीमापन अगले हफ़्तों में धीरे-धीरे आंकड़े बदलता है। Real-user monitoring या पुराने और नए पेज के lab tests उसी दिन बदलाव दिखा देते हैं।
क्या Google Tag Manager मेरी वेबसाइट धीमी कर सकता है?
हां। Tags main thread पर JavaScript चलाते हैं और पेज लोड होते समय bandwidth के लिए होड़ करते हैं, जिससे INP और LCP बिगड़ सकते हैं। Custom HTML tags और duplicate tags आम वजहें हैं। Container version publish करने से पहले नए tags जांचें और जो tags काम के नहीं, उन्हें हटा दें।
क्या Lighthouse का कम score साबित करता है कि गिरावट speed से हुई?
नहीं। Lighthouse एक device और एक network पर लोडिंग simulate करता है, और score हर run में बदलता है। इससे यह पता लगाएं कि कौन सी file या script भारी हुई, फिर field data, पेज और device segments और rollback test से कन्वर्ज़न से उसका रिश्ता दिखाएं।
Release के बाद सिर्फ़ mobile पर कन्वर्ज़न क्यों गिरे?
अतिरिक्त JavaScript या भारी hero element अक्सर सबसे पहले mobile visitors पर असर डालता है। Mobile और desktop के LCP और INP मिलाएं, देखें कि release ने उन templates में scripts या media जोड़े या नहीं जहां mobile गिरा, और पक्का करें कि conversion tag अब भी fire हो रहा है।
वेबसाइट पर नया script जोड़ते समय क्या लॉग करना चाहिए?
Script किस तारीख और समय पर live हुआ, किन पेज पर लोड होता है, किसने जोड़ा, कौन सा tool इस्तेमाल हुआ (GTM, theme या plugin), वजह क्या थी और उसे कैसे हटाएं। इस रिकॉर्ड से बाद में होने वाला धीमापन या गिरावट दिनों की जगह मिनटों में उस script से जुड़ जाती है।