क्रॉस-फ़ंक्शनल तरीके से वेबसाइट की स्पीड को ठीक करना

अन्य विभाग, आपकी वेबसाइट की स्पीड के ऑप्टिमाइज़ेशन प्रोजेक्ट को ज़्यादा कामयाब बनाने में किस तरह मदद कर सकते हैं.

लीना हैनसन

साइट की स्पीड से जुड़ी एक आम ग़लतफ़हमी यह है कि इसकी ज़िम्मेदारी सिर्फ़ डेवलपमेंट टीम की होती है. सच्चाई यह है कि तेज़ी से लोड होने वाली साइट को कई विभागों से मदद की ज़रूरत होती है. डेवलपर शायद ही कभी समस्याओं को अकेले सुलझा सकते हैं. इस बात से कोई फ़र्क़ नहीं पड़ता कि वे कितने काबिल हैं. तो आप अपने साथ काम करने वालों के साथ मिलकर रफ़्तार कैसे ठीक करते हैं? इस लेख में बताया गया है कि वेब डेवलपर के तौर पर, अपनी कंपनी को अपनी साइट की स्पीड को प्राथमिकता देने, ऑप्टिमाइज़ करते समय अलग-अलग डिपार्टमेंट से मदद लेने, और अपने ऑप्टिमाइज़ेशन प्रोजेक्ट की सफलता के बारे में जागरूक बनाने के लिए क्या किया जा सकता है.

ध्यान दें: इस गाइड में ई-कॉमर्स (खास तौर पर कारोबार के हिस्सेदारों वाले सेक्शन) पर थोड़ा सा फ़ोकस किया गया है. हालांकि, कुछ दिशा-निर्देश सामान्य तौर पर दिए गए हैं, जो मोबाइल कन्वर्ज़न को बेहतर बनाने के लिए, किसी भी वेबसाइट के लिए मददगार साबित हो सकते हैं.

अपने कारोबार के हिस्सेदारों की मदद से, कारोबार की स्पीड को ठीक करें

कई कंपनियां उपभोक्ता व्यवहार में आड़ वाले बदलाव देख रही हैं. दुकानों के बजाय डिजिटल प्लैटफ़ॉर्म पर खरीदारी करने वालों की संख्या में बढ़ोतरी से पता चलता है कि कंपनियों को जल्द से जल्द बदलाव करना होगा या आय में कमी आने का जोखिम होगा. यह काम पूरा करने के लिए, संगठन की नई प्रक्रियाओं और मानसिकता के साथ-साथ हिस्सेदारों से मज़बूत खरीदारी की ज़रूरत होगी.

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

कंपनियों को अपने आप व्यवस्थित करने का तरीका कई स्तरों में बदलने की ज़रूरत होगी. सबसे पहले, रेवेन्यू में हो सकने वाली बढ़ोतरी से, स्पीड प्रोजेक्ट का काम करना तब मुश्किल होगा, जब डेवलपर को इस पर काम करने का समय न मिले. संसाधनों का बंटवारा सही जगह पर होना चाहिए. अगर हिस्सेदार और एक्ज़ीक्यूटिव बताते हैं कि यह प्राथमिकता वाला प्रोजेक्ट है, तो मार्केटिंग और वेब डिज़ाइनर जैसे अन्य डिपार्टमेंट के साथ मिलकर काम करना अक्सर आसान हो जाता है.

काम करने के इस स्तर के अलावा, हिस्सेदारों के लिए यह समझना भी ज़रूरी है कि इस समय दो बदलाव हो रहे हैं:

• भले ही आपकी बिक्री का एक बड़ा हिस्सा दुकानों से आता हो, लेकिन ज़्यादातर खरीदार स्टोर में खरीदारी करने से पहले आपकी साइट जैसे डिजिटल प्लैटफ़ॉर्म का इस्तेमाल करेंगे. अगर साइट पर आने वाले लोगों को अच्छा उपयोगकर्ता अनुभव नहीं मिलता है, तो दुकानों से होने वाली आय पर भी असर पड़ेगा. साथ ही, स्टडी से पता चला है कि आपके कारोबार को सुझाव देने की ग्राहकों की इच्छा और कारोबार के प्रति उनकी लॉयल्टी पर भी असर पड़ता है.

• डेस्कटॉप से वेबसाइट पर आने वाले लोगों की तुलना में मोबाइल से वेबसाइट पर आने वाले लोगों की संख्या में ज़्यादा बढ़ोतरी हुई है. इस वजह से, मोबाइल ऐप्लिकेशन पर आने वाले लोगों की संख्या मौजूदा या आने वाले समय की हो सकती है. साथ ही, मोबाइल पर साइट की स्पीड और कन्वर्ज़न के बीच मज़बूत संबंध है. SOASTA की एक स्टडी से पता चला है कि मोबाइल पेज लोड होने में हर सेकंड देरी से, कन्वर्ज़न में 20%तक की गिरावट आ सकती है.

इसका मतलब यह है कि डिजिटल प्लैटफ़ॉर्म के विशेषज्ञ लोगों के बारे में सोच-समझकर फ़ैसले लेने वाली कंपनियों को फ़ायदा होगा. ऐसे में एक सुझाव यह हो सकता है कि उन मीटिंग में एक डेवलपर को बुलाया जाए, जहां कारोबारी फ़ैसले लिए जा रहे हैं, ताकि यह पक्का किया जा सके कि साइट और इसकी सीमाओं पर शुरू से ही विचार किया जा रहा है और इस तरह से बिक्री में बढ़ोतरी होगी.

अपने हिस्सेदारों को प्रस्ताव भेजें

आम तौर पर, करीब 10% बिक्री डिजिटल प्लैटफ़ॉर्म पर होती है. हालांकि, स्टडी से पता चलता है कि दुकानों में होने वाली 85% बिक्री पर सबसे पहले डिजिटल तौर पर असर पड़ता है. इसलिए, हमारे कारोबार की आय के लिए एक ऐसी साइट का होना बहुत ज़रूरी है जो अच्छा परफ़ॉर्म करती हो, खास तौर पर मोबाइल पर (जो कि मुख्य डिवाइस है). हम ऐसे स्पीड प्रोजेक्ट का सुझाव देते हैं जो साइट पर कन्वर्ज़न बढ़ाने और बातचीत की स्ट्रीम सेट अप करने में मदद करेगा. इससे साइट पर असर डालने वाले फ़ैसले लेने से पहले, तकनीकी टीमों की अहम जानकारी का इस्तेमाल किया जा सकेगा.

अपने हिस्सेदारों के साथ मीटिंग की तैयारी करना

हिस्सेदारों से मिलने से पहले, यह पक्का कर लें कि आप अपनी वेबसाइट और प्रतिस्पर्धियों की साइटों के डेटा के साथ-साथ ऐसे डेटा के लिए भी तैयार हैं जो सुझाए जा रहे बदलावों के आरओआई को दिखाता है. स्पीड की अहमियत के बारे में डेटा इकट्ठा करें. अगर यह कंपनी की आय से जुड़ा है, तो सबसे अच्छा तरीका है. इसे पाने के कुछ तरीके यहां बताए गए हैं:

• अपनी मिलती-जुलती मोबाइल कन्वर्ज़न दर की गणना करें. अपनी Analytics टीम के साथ काम करें और रफ़्तार की वैल्यू में बताया गया विश्लेषण करें. अगर आपने पहले भी एक अवधि (कम से कम दो से तीन महीने) की है, जब लोड होने में लगने वाला समय समान अवधि की दूसरी अवधि से बहुत ज़्यादा रहा है, तो आम तौर पर साइट की धीमी स्पीड की वजह से मोबाइल कन्वर्ज़न पर बहुत ज़्यादा असर पड़ेगा. इस विश्लेषण की मदद से यह हिसाब लगाया जा सकता है कि स्पीड की वैल्यू की पुष्टि करते हुए, खराब स्पीड के दौरान कंपनी की कितनी कमाई हुई. अगर लोड होने में लगने वाले समय में कोई बदलाव नहीं होता है, तो विश्लेषण करना मुश्किल होगा. साथ ही, नीचे दिए गए विकल्पों से ज़्यादा जवाब मिल सकते हैं.
• आंकड़ों वाले मॉडल से गति के मान का अनुमान लगाएं. Google के TestMySite की मदद से, आप एक टेस्ट शुरू कर सकते हैं और फिर यह जान सकते हैं कि तेज़ साइट आपके कारोबार पर कितना असर डाल सकती है. आपको सिर्फ़ हर महीने आने वाले लोगों की औसत संख्या, कन्वर्ज़न रेट, और ऑर्डर की औसत कीमत से जुड़ा डेटा चाहिए. इसमें आपकी ऐनलिटिक्स टीम आपकी मदद कर सकती है.
• सबसे सही तरीके से जुड़ी केस स्टडी दें. दूसरी कंपनियों के केस भी इस्तेमाल किए जा सकते हैं, जिन्होंने अपनी साइट ज़्यादा तेज़ की है और उनका असर देखा है. पेज लोड होने में लगने वाले समय से कन्वर्ज़न रेट पर क्या असर पड़ता है: 12 केस स्टडी में कुछ उदाहरण दिए गए हैं.
• मोबाइल की अहमियत दिखाएं. Analytics टीम से यह डेटा उपलब्ध कराने के लिए कहें कि आपके पेज पर आने वाले ट्रैफ़िक का कितना प्रतिशत हिस्सा मोबाइल और डेस्कटॉप से आता है.
• शोध करें कि इसकी लागत कितनी होगी. ऊपर दिए गए कैलकुलेशन, हिस्सेदारों को स्पीड से होने वाली आय में होने वाली बढ़ोतरी को दिखाने के तरीके हैं. हालांकि, आरओआई के बारे में जानने के लिए, हिस्सेदारों को फ़ैसला लेने के लिए ज़रूरी है. इसलिए, अगर आप अनुमानित लागत तय करते हैं, तो सरकारी फ़ैसले पर तेज़ी से फ़ैसला लिया जा सकता है. ऐसा करने के लिए, आकलन करें कि स्पीड प्रोजेक्ट पर फ़ोकस करने में कितना समय लगेगा और उसके बाद, रखरखाव में कितना समय लगेगा. उदाहरण के लिए, फ़ास्ट-फ़ॉरवर्ड थिंकिंग: TUI ने साइलो (साइलो) को तोड़कर अपनी साइट की रफ़्तार बढ़ाई, इसके लिए डेवलपर को अपना 20% समय, बैकलॉग और कैंपेन से खाली रखा गया. इससे वे प्रोजेक्ट को तेज़ी से पूरा करने और साइट को बेहतर बनाने के दूसरे तरीकों में अपना योगदान दे सकते थे.

अपने हिस्सेदारों से मिलें

• यह दिखाएं कि आपको मोबाइल बनाम डेस्कटॉप से कितना ट्रैफ़िक मिल रहा है और पिछले कुछ सालों में मोबाइल से कितनी बढ़ोतरी हुई है. यह मोबाइल पर बेहतरीन अनुभव देने की अहमियत दिखाता है.
• इस बारे में अपने नतीजे पेश करें कि किस तरह तेज़ी से कंपनी के रेवेन्यू पर असर पड़ता है.
• Google के हिस्सेदारों को बताएं कि अगर डेवलपर, मोबाइल पर आने वाले लोगों से लगातार काम करने के लिए समय देते हैं, तो वे अपनी आय बढ़ा सकते हैं.
• सुझाव दें कि एक्ज़ीक्यूटिव टीम के एक व्यक्ति को एक्ज़ीक्यूटिव मीटिंग में न्योता दिया जाना चाहिए, जहां साइट से जुड़े फ़ैसले लिए जाएंगे. आज-कल हम डिजिटल प्लैटफ़ॉर्म पर प्रॉडक्ट बेचते हैं. विजेता वे कंपनियां होंगी जो अपने डिजिटल विशेषज्ञों से बातचीत करना शुरू करेंगी. आधुनिक कंपनियों के लिए ज़रूरी है कि वे डिपार्टमेंट के साथ-साथ, हिस्सेदारों और डेवलपर के बीच कम्यूनिकेशन स्ट्रीम सेट अप करें. हार्वर्ड बिज़नेस रिव्यू की एक स्टडी में पता चला कि हर छह में से एक आईटी प्रोजेक्ट की लागत 200% से ज़्यादा है. इसका एक उदाहरण Kmart था. साल 2000 में अपने आईटी उद्योग को आधुनिक बनाने का 1.4 अरब डॉलर का प्रोजेक्ट शुरू करते समय, वह Walmart और Target से अपनी प्रतिस्पर्धी स्थिति में नहीं गया. जल्दी-जल्दी बातचीत और रखरखाव सेट अप करने से, आपस में जानकारी शेयर करने की सुविधा को खत्म किया जा सकता है. साथ ही, जानकारी शेयर करने से प्रतिस्पर्धी फ़ायदा बन सकता है.

अपनी मार्केटिंग टीम की मदद से स्पीड को ठीक करें

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

मार्केटिंग टीमों को विज्ञापनों और डेटा को मैनेज करने के लिए टूल की ज़रूरत होती है, ताकि वे सोच-समझकर फ़ैसले ले सकें. हालांकि, ज़्यादातर टूल वेबसाइट की परफ़ॉर्मेंस को धीमा कर देते हैं. इन टूल को अक्सर रेंडर-ब्लॉक करने वाली स्क्रिप्ट के साथ लागू किया जाता है. इससे, साइट पर आने वाले लोगों को स्क्रीन पर कुछ भी देखने तक इंतज़ार करना पड़ता है. इसलिए, यहां संतुलन बनाए रखने की ज़रूरत है. मार्केटिंग डिपार्टमेंट को डेटा और टूल की ज़रूरत है, लेकिन साइट को कम बाउंस रेट और ज़्यादा कन्वर्ज़न रेट पाने के लिए तेज़ रफ़्तार रखनी चाहिए, ताकि मार्केटिंग को उनके निवेश पर अच्छा रिटर्न मिले.

स्क्रिप्ट के साथ सावधानी बरतकर बैलेंस हासिल किया जाता है:

• ऐसे डुप्लीकेट टाइटल न डालें जो करीब एक ही चीज़ मापते हों.
• जो टूल अब इस्तेमाल नहीं किए जा रहे हैं उन्हें हटाएं.
• "अच्छी" चीज़ों का आकलन न करें. सिर्फ़ कारोबार के लिए अहम चीज़ों को मापें.

डेवलपर के लिए यह जानना मुश्किल है कि मार्केटिंग डिपार्टमेंट किस पर निर्भर करता है. साथ ही, मार्केटिंग डिपार्टमेंट को शायद यह पता न हो कि साइट के लिए कौनसे टूल अहम हैं, इसलिए आपको मिलकर काम करने की ज़रूरत होगी.

अपनी मार्केटिंग टीम को एक प्रस्ताव भेजें

ट्रैकिंग और विज्ञापनों के लिए इस्तेमाल किए जाने वाले टूल, अक्सर यह ब्लॉक कर देते हैं कि साइट पर आने वाले लोगों को कॉन्टेंट कितनी जल्दी दिखता है. इससे मार्केटिंग में किए जाने वाले खर्च की वैल्यू में कमी आती है, क्योंकि हम विज्ञापनों के लिए पेमेंट करते हैं. इससे लोगों को दिलचस्पी होती है, क्लिक करने के बाद इंतज़ार करना पड़ता है. इससे वे चिड़चिड़े हो जाते हैं और बाहर निकल जाते हैं. एक अध्ययन में पाया गया कि स्पीड मेट्रिक टाइम टू इंटरैक्टिव के 0.15 s से बढ़कर 0.3 s होने पर, कन्वर्ज़न दर 50% से घटकर करीब 35% हो गई. क्या हम इस समस्या को हल करने के लिए साथ मिलकर काम कर सकते हैं, ताकि आपके काम आने वाले टूल और साइट की परफ़ॉर्मेंस के बीच संतुलन बनाया जा सके. इससे मार्केटिंग निवेश पर ज़्यादा रिटर्न मिल सकता है?

अपनी मार्केटिंग टीम के साथ मीटिंग की तैयारी करें

• साइट पर लागू की गई स्क्रिप्ट की सूची बनाएं.
• मार्केटिंग के लिए सूची भेजें और उन्हें पहले से ही इसे देखने और इन्हें तीन हिस्सों में बांटने के लिए कहें:
  • कारोबार के लिए अहम. ये स्क्रिप्ट बनी रहनी चाहिए.
  • शानदार. ऐसी स्क्रिप्ट जिनका कम इस्तेमाल किया जा सकता है या जिन्हें हटाया जा सकता है. उदाहरण के लिए, कभी-कभी कंपनियां हीट मैप या स्क्रीन रिकॉर्डिंग इकट्ठा करती हैं, लेकिन हो सकता है कि डेटा की समीक्षा कभी-कभार ही की जाए. इससे कोई कार्रवाई या कन्वर्ज़न नहीं होता. इस तरह के मामलों में, सिर्फ़ दो हफ़्ते तक टूल चलाने की सहमति दी जा सकती है. विश्लेषण के लिए अहम जानकारी इकट्ठा की जा सकती है. इसके बाद, स्क्रिप्ट को तब तक मिटाया जा सकता है, जब तक डेटा इकट्ठा करने पर फ़ोकस नहीं किया जाता.
  • इस्तेमाल नहीं किया गया या मालिकाना हक नहीं है. इन्हें हटा देना चाहिए.
• साइट की स्पीड की तुलना, उसके बिना और हर स्क्रिप्ट के साथ करके देखें कि हर स्क्रिप्ट आपकी साइट की स्पीड को कितनी धीमा कर देती है. WebPageTest में इसे बेहतर सेटिंग में ब्लॉक टैब में जाकर सेट अप किया जा सकता है. इसके अलावा, Chrome DevTools में नेटवर्क के अनुरोधों को ब्लॉक किया जा सकता है.

अपनी मार्केटिंग टीम से मिलें

• स्क्रिप्ट की सूची देखें और हर स्क्रिप्ट पर अपना व्यू दिखाएं. उदाहरण के लिए, क्या उपयोगी स्क्रिप्ट में से कोई भी साइट की परफ़ॉर्मेंस को बहुत नुकसान पहुंचा रही है? सुझाव मिलने से, मार्केटिंग टीम के लिए प्राथमिकता तय करना आसान हो जाता है. साथ ही, यह जानकर कि कारोबार के लिए क्या अहम है, आपको उनके नज़रिए को समझने में आसानी होती है.
• इन विषयों पर चर्चा करें:
  • क्या इकट्ठा किए गए डेटा के फ़ायदों की वजह से कन्वर्ज़न में बढ़ोतरी हो रही है? साइट के धीरे होने की वजह से हुए कन्वर्ज़न में भी बढ़ोतरी हुई है या नहीं? डेटा से ही यह फ़ैसला लेने में मदद मिलती है.
  • क्या आपकी कंपनी ने सेवा देने वाली ऐसी कंपनी चुनी है जिसके पास बाज़ार में इस टूल का सबसे तेज़ वर्शन है? मार्केटिंग डिपार्टमेंट को यह पता लगाने के लिए डेवलपर की मदद की ज़रूरत पड़ सकती है कि क्या कारोबार के लिए अहम टूल को तेज़ी से अन्य विकल्पों से बदला जा सकता है या नहीं.
  • क्या साइट पर मौजूद किसी भी स्क्रिप्ट के विकल्प मौजूद हैं? उदाहरण के लिए, हीटमैप के बजाय, उपयोगिता की जांच करना शुरू किया जा सकता है. इसमें आपको उपयोगकर्ता के व्यवहार की "वजह" के बारे में भी पता होता है, जिससे आपको बेहतर इनसाइट मिलती है.

ध्यान दें: एक आम चुनौती यह है कि जब लोग सुझावों का जवाब दें, तो वे आत्मरक्षा के मोड पर जाएं. इसकी कुंजी यह हो सकती है कि हमेशा अन्य विभागों के ज्ञान क्षेत्रों के सम्मान पर ज़ोर दिया जाए. खुद को समझने और सुनने की इच्छा रखने के लिए, लोगों को खुलकर अपने आइडिया को सुनने का मौका देना होगा. आखिर में, बातचीत के अलग-अलग विषयों पर अन्य टीमों को सामाजिक मेल-जोल या कॉफ़ी और बेकरी के लिए न्योता दें. कभी-कभी सबसे असरदार मीटिंग, मीटिंग रूम के बाहर होती हैं.

अगले चरणों पर सहमति दें

• आगे की प्रोसेस के बारे में तय करें. क्या मार्केटिंग को हमेशा नए टूल को लागू करने से पहले, डेवलपर से इसकी समीक्षा करनी चाहिए और रफ़्तार पर उनके असर की समीक्षा करनी चाहिए? या क्या मार्केटिंग को परफ़ॉर्मेंस के लिए एक बजट मिलना चाहिए, जिसमें वे स्पीड की जांच करना सीख सकें. साथ ही, क्या वे खुद ही यह तय कर सकें कि उन्हें स्पीड के टारगेट को पूरा करने के लिए कौनसे टूल चाहिए?

अपनी वेब डिज़ाइन टीम की मदद से, स्पीड को ठीक करें

वेब परफ़ॉर्मेंस की सबसे बड़ी चुनौतियों में से एक यह है कि कई क्षेत्रों में कनेक्टिविटी तेज़ी से बढ़ रही है, लेकिन वेबसाइटें भारी होती जा रही हैं. इस वजह से, उपयोगकर्ताओं की संख्या धीमी हो रही है. इस समस्या को हल करने के लिए, डेवलपर को वेब डिज़ाइनर के साथ मिलकर काम करना होगा.

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

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

हालांकि, छोटे वेब पेज शेयर करने की ज़िम्मेदारी भी एक ही होती है. डेवलपर, इमेज को तेज़ी से लोड करने के लिए, इमेज ऑप्टिमाइज़ेशन की कई तरह की तकनीकों का इस्तेमाल कर सकते हैं. वेब डिज़ाइनर ऐसे पेज बना सकते हैं जो पेज के वेट को एक तय लेवल से कम रखने में मदद करते हैं.

अपनी वेब डिज़ाइन टीम को एक प्रस्ताव भेजें

अध्ययनों से पता चला है कि कम इमेज और कम एलिमेंट वाले पेजों से ज़्यादा कन्वर्ज़न मिलते हैं. उदाहरण के लिए, Google और SOASTA की एक स्टडी में पता चला है कि ग्राहक में बदलने वाले सेशन में, न बदलने वाले सेशन की तुलना में 38% कम इमेज थीं. क्या हम स्पीड टारगेट तक पहुंचने और साइट पर कन्वर्ज़न बढ़ाने के लिए, साथ मिलकर काम करने के लिए साथ मिलकर काम कर सकते हैं? हम एक साथ क्या कर सकते हैं, इसके उदाहरण में क्वालिटी और स्पीड के बीच संतुलन के साथ इमेज कंप्रेशन का सही लेवल ढूंढना या मुश्किल लेआउट या फ़ंक्शन को कम करना शामिल है, जिनके कारण अक्सर भारी या धीमी गति से लोड होने वाली साइटें दिखती हैं.

अपनी वेब डिज़ाइन टीम के साथ मीटिंग की तैयारी करना

• देखें कि साइट के किन पेजों की लोड होने में लगने वाला समय सबसे ज़्यादा और पेज का वज़न सबसे ज़्यादा है. उदाहरण के लिए, अगर किसी ई-कॉमर्स साइट के साथ काम किया जा रहा है, तो न सिर्फ़ होम पेज, बल्कि सभी कैंपेन पेज, कुछ सबसे बड़े कैटगरी के पेजों, कुछ प्रॉडक्ट पेजों, और चेकआउट प्रोसेस को भी देखें.
• डिज़ाइनर के लिए, परफ़ॉर्मेंस बजट का प्रस्ताव तैयार करें. एक विकल्प यह है कि मेट्रिक के मुताबिक जितना हो सके उतना आसान तरीके से शुरुआत करें. साथ ही, सभी पेजों के लिए 1.5 एमबी टारगेट (या अगर कन्वर्ज़न के लिए ब्रैंडिंग बहुत ज़रूरी है, तो 1.5 एमबी) सेट करें.
• उन पेजों की सूची बनाएं जो टारगेट पेज के वेट लेवल से ऊपर हैं.

अपनी वेब डिज़ाइन टीम से मिलें

• इस बात की जांच करने के लिए कि डेवलपमेंट टीम, इमेज को तेज़ी से लोड करने के लिए अलग-अलग तरह की इमेज ऑप्टिमाइज़ेशन तकनीकों का इस्तेमाल करती है. इन तकनीकों में इमेज को कंप्रेस करना, रिस्पॉन्सिव इमेज, इमेज का साइज़ बदलना, लेज़ी लोडिंग, कैश मेमोरी में सेव करना, और सर्वर ऑप्टिमाइज़ेशन शामिल हैं.
• एक टेस्ट पेज बनाएं, जहां इमेज की अलग-अलग क्वालिटी और डाइमेंशन में इमेज पब्लिश की गई हों. साथ ही, उस पेज पर सहमति दें जो अलग-अलग स्क्रीन पर परफ़ॉर्मेंस और क्वालिटी के बीच संतुलन बना सके. याद रखें कि मोबाइल पर वेबसाइट पर आने वाले लोगों का सेशन अक्सर कम होता है. हालांकि, एक स्टडी से पता चला है कि आधे से ज़्यादा मोबाइल सेशन 30 सेकंड या उससे कम समय के होते हैं. ऐसा हो सकता है कि ये उपयोगकर्ता, इमेज के बारे में पूरी जानकारी न ढूंढ पाएं और साइट को तेज़ी से देखना पसंद करें.
• परफ़ॉर्मेंस बजट का सुझाव दें, जहां वेब डिज़ाइनर यह पक्का करने का वादा करते हैं कि सभी वेब पेजों का पेज वज़न 1 एमबी से कम या ज़्यादा से ज़्यादा 1.5 एमबी हो.

आंकड़ों की जानकारी देने वाली टीम की मदद से, स्पीड को ठीक करें

कारोबारों को यह जानने के लिए डेटा की ज़रूरत होती है कि किस चीज़ पर ध्यान देना है और यह जानने के लिए कि फ़ैसले लेने का आधार क्या है. हालांकि, कई कंपनियां साइट की स्पीड की अहमियत और आय और बिक्री से इसके संबंध के बारे में बताती हैं, लेकिन अब भी ऐसी कई कंपनियां हैं जो टेक टीमों के बाहर की हर हफ़्ते आने वाली रिपोर्ट में स्पीड की जानकारी शामिल नहीं करती हैं. अगर डेवलपर, Analytics टीमों के साथ मिलकर काम करना शुरू करते हैं, तो इसमें बदलाव किया जा सकता है.

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

सच्चाई यह है: रिपोर्ट नहीं की गई जानकारी पर फ़ोकस नहीं किया जाएगा. अगर साइट स्पीड, कारोबार के हिस्सेदारों को हफ़्ते या महीने में दी जाने वाली रिपोर्ट का हिस्सा नहीं है, तो इसे आसानी से भुला दिया जाएगा. साथ ही, इस पर फ़ोकस करने के लिए आपको संसाधन पाने में परेशानी होगी. हालांकि, आंकड़ों को ट्रैक करने वाली टीमों को अक्सर ट्रैकिंग की स्पीड का अनुभव नहीं होता है, इसलिए उन्हें डेवलपर से मदद की ज़रूरत होगी. इसके अलावा, रफ़्तार में सुधार किए जाने पर डेवलपर को आय पर पड़ने वाले असर का हिसाब लगाने के लिए, आंकड़ों की टीम की मदद की ज़रूरत होगी. ये डिपार्टमेंट एक-दूसरे पर निर्भर करते हैं, जबकि शुरुआत में शायद दोनों विभागों के बारे में न सोचना पड़े.

अपनी Analytics टीम को प्रस्ताव भेजें

कई केस स्टडी दिखाती हैं कि साइट की स्पीड का असर, आय और बाउंस रेट पर पड़ता है. क्या हम अपनी कंपनी के लिए साइट स्पीड ट्रैकिंग सेट अप करने के लिए मिलकर काम कर सकते हैं, और हिस्सेदारों के पास जा रही रिपोर्ट के हिस्से के तौर पर हम स्पीड हासिल कर सकते हैं, ताकि ज़्यादा से ज़्यादा ख़रीदारी की जा सके?

अपनी Analytics टीम के साथ मीटिंग की तैयारी करें

• नियमित रूप से स्पीड ट्रैक करें. हमारा सुझाव है कि आप Lighthouse CI, PageSpeed Insights या WebPageTest जैसे टूल के साथ एपीआई का इस्तेमाल करें. इससे आपको अलग-अलग समयावधि में आसान मानदंड के लिए, कंट्रोल वाली लैब सेटिंग में नियमित तौर पर आंकड़े इकट्ठा करने में मदद मिलेगी.
• Analytics टीम को स्पीड की वैल्यू फ़ॉरवर्ड करें और पूछें कि क्या वे विश्लेषण कर सकते हैं. इससे मीटिंग के दौरान विश्लेषण के लिए आपके पास चार्ट तैयार रहेगा.

आंकड़ों की जानकारी देने वाली अपनी टीम से मिलें

• स्पीड की वैल्यू से बनाया गया चार्ट देखें. सापेक्ष मोबाइल कन्वर्ज़न रेट, स्पीड के असर और आपकी साइट में सुधार को ट्रैक करने का एक तरीका है. Analytics टीम से पूछें कि क्या वह इसे ट्रैक करने के लिए तैयार है.
• तय करें कि Google Analytics में लोड होने में लगने वाले समय की मेट्रिक, कारोबार की आसान रिपोर्ट के लिए अच्छी है या नहीं. स्पीड की वैल्यू इस मेट्रिक का इस्तेमाल करती है. जैसा कि ज़्यादातर डेवलपर को पता है, यह कई ज़रूरी स्पीड मेट्रिक में से एक है. साथ ही, यह Google Analytics में लैब डेटा के बजाय, फ़ील्ड डेटा भी है. हालांकि, क्या कारोबार की आसान रिपोर्ट बनाने के लिए इसका इस्तेमाल किया जा सकता है? ऊपर दिए गए विश्लेषण से मिलने वाले नतीजे की जांच करें और देखें कि कम से कम दो से तीन महीने तक लोड समय ज़्यादा रहने पर, मिलती-जुलती मोबाइल कन्वर्ज़न दर में गिरावट दिख सकती है या नहीं. साथ ही, लोड का समय 2-3 महीने तक कम रहने पर भी मिलता-जुलता मोबाइल कन्वर्ज़न रेट बढ़ रहा है या नहीं. अगर आपकी लोडिंग का समय काफ़ी स्थिर है, तो यह पता लगाना मुश्किल होगा कि क्या विश्लेषण आपके लिए तब तक काम कर रहा है या नहीं, जब तक आप इसकी रफ़्तार को और भी बेहतर न बना लें. अगर हां, तो अगला विकल्प चुनें.
• डेवलपर की ओर से इस्तेमाल की जाने वाली स्पीड मेट्रिक के लिए अपने चार्ट दिखाएं. Analytics टीम को समझाएं और देखें कि आपको कन्वर्ज़न रेट या रिलेटिव मोबाइल कन्वर्ज़न रेट में कोई संबंध मिलता है या नहीं.
• आंकड़ों की टीम को कुछ समय दें, ताकि वह पता कर सके कि रेवेन्यू का हिसाब लगाने के लिए क्या-क्या तरीके अपनाए जा सकते हैं. साथ ही, यह भी बताया जा सकता है कि हिस्सेदारों को इसकी जानकारी कैसे दी जाए. अक्सर उनके लिए यह एक नया विषय होता है. इसके बाद, दोबारा मिलें और वह तरीका आज़माएं जिससे आप सहमत हों. हमेशा की तरह, आपको डेटा कलेक्शन में तब तक बदलाव करना होगा, जब तक कि आपको सही विकल्प न मिल जाए, लेकिन यह सहयोग शुरू करने का एक तरीका है.

अगले चरण

स्पीड प्रोजेक्ट से बड़े सुधार होने के बाद, अपनी Analytics टीम को स्पीड की वैल्यू सेक्शन में बताया गया विश्लेषण करने के लिए कहें. इससे कंपनी को पता चलेगा कि उसे कितने कन्वर्ज़न और रेवेन्यू मिले हैं. साथ ही, आपकी टीम और आपके साथ काम करने वाले सभी डिपार्टमेंट को इनाम दिया जाएगा. इसे हिस्सेदारों को भेजी जाने वाली हर हफ़्ते की रिपोर्ट में शामिल किया जा सकता है, ताकि प्रोजेक्ट सिर्फ़ एक बार में न चले, लेकिन इसका रखरखाव लगातार किया जा रहा है.