साइट स्पीड और कारोबार मेट्रिक से जुड़ा हुआ

अपने कारोबार की मेट्रिक पर साइट स्पीड के असर का आकलन करने के लिए, A/B टेस्टिंग की मदद लें.

Bart Jarochowski

Martin Schierle

Dikla Cohen

पिछले कुछ सालों में यह साबित हो चुका है कि साइट स्पीड की परफ़ॉर्मेंस, उपयोगकर्ता अनुभव का एक अहम हिस्सा है. साथ ही, इसमें सुधार करने से कन्वर्ज़न रेट और बाउंस रेट जैसी अलग-अलग कारोबारी मेट्रिक को फ़ायदा होता है. इस बात को साबित करने के लिए, कई लेख और केस स्टडी पब्लिश किए गए हैं. इनमें Cloudflare की वेबसाइट की परफ़ॉर्मेंस से कन्वर्ज़न रेट पर क्या असर पड़ता है, Deloitte का Milliseconds Make सुविधाएं, और Shopping for Speed on eBay.com जैसे कुछ उदाहरण शामिल हैं.

हालांकि, स्पीड की बात साफ़ तौर पर है, लेकिन कई कंपनियों को अब भी काम को प्राथमिकता देने में परेशानी होती है. इससे उनकी साइट की स्पीड बेहतर हो सकती है. ऐसा इसलिए, क्योंकि उन्हें नहीं पता कि इससे उनके उपयोगकर्ताओं और उनके कारोबार पर क्या असर होगा.

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

इस लेख में कारोबार की मेट्रिक पर साइट स्पीड के असर का आकलन करने के लिए, A/B टेस्टिंग का इस्तेमाल करने के बारे में बेहतर तरीके से दिशा-निर्देश दिए गए हैं. इससे इस मामले में बेहतर फ़ैसले लेने में मदद मिलेगी.

पहला चरण: A/B टेस्ट के लिए कोई पेज चुनना

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

• A/B टेस्ट सिर्फ़ मोबाइल उपयोगकर्ताओं के डिवाइस पर किया जाना चाहिए. दुनिया भर में, हम जिन पार्टनर साइटों की मदद करते हैं उन्हें मोबाइल से आने वाले ट्रैफ़िक का औसतन 50% से ज़्यादा (और बढ़ रहा!) दिखता है. हालांकि, यह इलाके और वर्टिकल के आधार पर काफ़ी बढ़ सकता है. प्रोसेसिंग और मेमोरी की कमी की वजह से मोबाइल डिवाइस, धीमी वेबसाइटों पर ज़्यादा संवेदनशील होते हैं. साथ ही, नेटवर्क कम स्थिर होते हैं. साथ ही, कभी भी, कहीं भी इस्तेमाल करने के पैटर्न का मतलब है कि स्पीड की उम्मीद ज़्यादा होती है.

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

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

• चुने गए पेज को काफ़ी ट्रैफ़िक मिलना चाहिए, ताकि आपको आंकड़ों के हिसाब से अहम नतीजे पाने के लिए लंबे समय तक इंतज़ार न करना पड़े.

• चुना गया पेज थोड़ा धीमा होना चाहिए. बल्कि, यह जितना धीमा होगा उतना ही बेहतर होगा. इसका मतलब यह है कि पेज को बेहतर बनाने में आपको आसानी होगी. साथ ही, डेटा ज़्यादा साफ़ होना चाहिए. Google Analytics की स्पीड रिपोर्ट या Search Console की वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली रिपोर्ट की मदद से, तेज़ी से स्कैन किया जा सकता है. इससे यह पता लगाया जा सकता है कि आपके कौनसे पेज सबसे धीमे हैं.

• पेज ज़्यादा से ज़्यादा स्थिर होना चाहिए. जांच पूरी होने तक, पेजों (कोई भी ऐसी चीज़ जिसका असर कारोबार की मेट्रिक पर पड़ता हो) को अपडेट न करें. विश्लेषण करने के लिए कम से कम बाहरी फ़ैक्टर का ध्यान रखना होगा.

ऊपर दी गई जानकारी का इस्तेमाल गाइड के तौर पर करने से, यह थोड़ा और साफ़ होना चाहिए कि आपकी जांच के लिए कौनसे पेज अच्छे हैं. विज्ञापन लैंडिंग पेज भी अच्छे विकल्प होते हैं, क्योंकि आपके पास कारोबार से जुड़ी मेट्रिक, A/B टेस्टिंग, और विश्लेषण होने की संभावना होती है. अगर आपको अब भी यकीन नहीं है, तो यहां हर वर्टिकल के लिए कुछ आइडिया दिए गए हैं:

• कॉन्टेंट की वेबसाइटें: सेक्शन, लेख
• स्टोरफ़्रंट: कैटगरी पेज, प्रॉडक्ट पेज
• मीडिया प्लेयर: वीडियो डिस्कवरी/खोज वाले पेज, वीडियो चलाने वाला पेज
• सेवाएं और डिस्कवरी (यात्रा, किराये की कार, सेवा के रजिस्ट्रेशन वगैरह): शुरुआती फ़ॉर्म एंट्री पेज

दूसरा चरण: परफ़ॉर्मेंस का आकलन करना

आम तौर पर, मेट्रिक को मेज़र करने के दो तरीके होते हैं: लैब में और फ़ील्ड में. हमने निजी तौर पर पाया है कि फ़ील्ड में मौजूद मेट्रिक को मेज़र करना ज़्यादा फ़ायदेमंद होता है, क्योंकि यह असल उपयोगकर्ताओं के अनुभव के बारे में बताता है. इसे रीयल उपयोगकर्ता की निगरानी (आरयूएम) के नाम से भी जाना जाता है. उन लाइब्रेरी और सेवाओं के उदाहरण जिनसे आपको आरयूएम डेटा की रिपोर्ट करने में मदद मिल सकती है. इनमें परफ़्यूम, Firebase की परफ़ॉर्मेंस पर नज़र रखने की सुविधा, और Google Analytics इवेंट शामिल हैं.

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

तीसरा चरण: स्पीड की परफ़ॉर्मेंस के लिए वैरिएंट बनाएं

इस चरण में, आपको पेज का एक तेज़ वर्शन बनाने के लिए बदलाव लागू करने होंगे, ताकि मौजूदा वर्शन की तुलना में उसकी जांच की जा सके.

इन बातों का ध्यान रखें:

1. यूज़र इंटरफ़ेस (यूआई) या UX में कोई भी बदलाव करने से बचें. एक पेज के दूसरे पेज से तेज़ होने के अलावा, बदलाव उपयोगकर्ताओं को नहीं दिखने चाहिए.
2. आकलन करना भी इस चरण का एक अहम पहलू है. लाइटहाउस जैसे लैब टेस्टिंग टूल को डेवलप करते समय, यह बताने के लिए इस्तेमाल किया जाना चाहिए कि आपके बदलावों का परफ़ॉर्मेंस पर क्या असर पड़ा है. ध्यान रखें कि एक मेट्रिक में बदलाव करने से, अक्सर दूसरी मेट्रिक पर असर पड़ सकता है. पेज लाइव होने के बाद, ज़्यादा सटीक आकलन के लिए RUM का ही इस्तेमाल करें.

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

ज़्यादा तेज़ पेज बनाना

• अपने टेस्ट पेज पर मौजूद इमेज को मैन्युअल तौर पर ऑप्टिमाइज़ करने के लिए, Squoosh जैसे टूल का इस्तेमाल करें.
• सिर्फ़ उस एक पेज के लिए इस्तेमाल नहीं हुए JavaScript या सीएसएस को मैन्युअल तरीके से हटाने के लिए, DevTools कोड कवरेज का इस्तेमाल करें
• तीसरे पक्ष की स्क्रिप्ट को बेहतर तरीके से लोड करना
• ज़रूरी सीएसएस को अलग करने और इनलाइन करने के लिए, क्रिटिकल जैसे टूल का इस्तेमाल करें
• ऐसा गै़र-ज़रूरी JavaScript कोड हटाएं जिससे उपयोगकर्ता अनुभव पर कोई असर नहीं पड़ता. साथ ही, जांच के मकसद से बिना ऐसा किया जा सकता है (उदाहरण के लिए, तीसरे पक्ष की कुछ लाइब्रेरी)
• ब्राउज़र-लेवल पर लेज़ी लोडिंग लागू करें, जो सभी ब्राउज़र पर काम नहीं करती. हालांकि, इससे परफ़ॉर्मेंस को बेहतर बनाने में मदद मिल सकती है.
• गैर-ज़रूरी Analytics टैग हटाएं या उन्हें एसिंक्रोनस रूप से लोड करें

अन्य ऑप्टिमाइज़ेशन, तेज़ी से लोड होने की अवधि और फ़्रंटएंड परफ़ॉर्मेंस चेकलिस्ट में देखे जा सकते हैं. PageSpeed Insights का इस्तेमाल करके भी Lighthouse चलाया जा सकता है. यह सुविधा, परफ़ॉर्मेंस को बेहतर बनाने के अवसरों की पहचान करती है.

पेज को धीमा करना

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

पेज लोड होने की रफ़्तार बढ़ाना

जिन मामलों में टेस्ट पेज (मान लें कि प्रॉडक्ट की जानकारी वाला पेज) ज़्यादातर किसी दूसरे पेज (जैसे कि होम पेज) से लिंक किया गया है वहां टेस्ट ग्रुप के लिए, प्रॉडक्ट पेज को सीधे होम पेज से प्रीफ़ेच करने या प्रीरेंडर करने से, पेज के लोड होने की रफ़्तार बढ़ जाएगी. ध्यान दें कि इस मामले में, A/B टेस्ट स्प्लिट (चौथा चरण) होम पेज पर किया जाता है. इसके अलावा, ये सभी चीज़ें पहले पेज को धीमा कर सकती हैं इसलिए, इसे ज़रूर मापें और जांच के नतीजों का विश्लेषण करते समय इस पर विचार करें (पांचवां चरण).

चौथा चरण: A/B टेस्ट बनाना

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

अगर Optimizely या Optimize जैसे किसी A/B टेस्टिंग टूल का इस्तेमाल किया जा रहा है, तो हमारा सुझाव है कि आप क्लाइंट-साइड टेस्ट के बजाय, सर्वर साइड टेस्ट सेट अप करें. इसकी वजह यह है कि क्लाइंट-साइड A/B टेस्टिंग, अक्सर प्रयोग के लोड होने तक पेज का कॉन्टेंट छिपाकर काम करती है. इसका मतलब है कि A/B टेस्टिंग उन मेट्रिक पर असर डाल सकती है जिन्हें आपको मेज़र करना है. अगर सिर्फ़ क्लाइंट-साइड टेस्टिंग की जा सकती है, तो एक्सपेरिमेंट को किसी दूसरे पेज पर सेट अप करें और अपने टेस्ट पेज के लिंक को बदलें. ऐसा करके ट्रैफ़िक को अलग-अलग किया जा सकता है. इस तरह, क्लाइंट-साइड टेस्ट में टेस्ट पेज को नीचे खींचकर नहीं छोड़ा जाता.

उदाहरण

सर्वर-साइड टेस्टिंग की मदद से, प्रॉडक्ट की जानकारी वाले पेज (पीडीपी) पर, एबी टेस्टिंग की परफ़ॉर्मेंस में होने वाले बदलावों का उदाहरण:

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

यहां क्लाइंट-साइड टेस्टिंग को सेटअप करने का उदाहरण दिया गया है. इसमें JavaScript की टेस्टिंग के लिए, पिछले पेज (नीचे दिए गए डायग्राम में दिए गए होम पेज) का इस्तेमाल किया गया है:

टेस्टिंग JavaScript, उपयोगकर्ताओं के दो टेस्ट ग्रुप को लिंक करने के लिए आउटगोइंग लिंक में बदलाव करता है. ये लिंक, उस पीडीपी के दोनों वर्शन के लिंक होते हैं जिसकी शिकायत की गई है. यह Optimizely या Optimize जैसे सामान्य A/B टेस्टिंग टूल की मदद से सेटअप और मैनेज करने में आसान है. साथ ही, इससे परफ़ॉर्मेंस की जांच पर कोई असर नहीं पड़ता, क्योंकि JavaScript किसी अलग पेज पर चलता है.

इसके अलावा, ऐसे दो पेज चुने जा सकते हैं जो एक जैसा व्यवहार करते हैं और परफ़ॉर्म करते हैं. उदाहरण के लिए, दो बहुत ही मिलते-जुलते प्रॉडक्ट के लिए. अपने बदलावों को उनमें से किसी एक पर लागू करें और फिर समय के साथ मेट्रिक में हुए अंतर की तुलना करें. इसका मतलब है कि सही A/B टेस्ट नहीं किया जा रहा है, फिर भी इससे काफ़ी अहम जानकारी मिल सकती है.

अगर आपके टेस्ट पेज का इस्तेमाल विज्ञापन कैंपेन के लैंडिंग पेज के तौर पर किया जाता है, तो अपनी विज्ञापन नेटवर्क कंपनी के बिल्ट-इन A/B टेस्टिंग टूल का इस्तेमाल करना आसान हो सकता है, जैसे कि Facebook Ads का स्प्लिट टेस्ट या Google Ads के ड्राफ़्ट और प्रयोग. अगर यह विकल्प नहीं है, तो एक ही सेटअप वाले दो कैंपेन इस्तेमाल किए जा सकते हैं और टारगेट के तौर पर अलग-अलग लैंडिंग पेज सेट किए जा सकते हैं.

पांचवां चरण: A/B टेस्ट का विश्लेषण करना

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

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

Optimizely या Optimize जैसे प्लैटफ़ॉर्म भी नतीजों को समझने के आसान तरीके मुहैया कराते हैं. साथ ही, इनसे यह तय करने में भी मदद मिलती है कि आपके पेजों पर किस तरह का असर हुआ है.

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

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

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

Looker Studio (इसे पहले Data Studio कहा जाता था) या दूसरे डेटा विज़ुअलाइज़ेशन टूल की मदद से, Google Analytics समेत कई तरह के डेटा सोर्स को आसानी से इंटिग्रेट किया जा सकता है. इससे विश्लेषण करना आसान हो जाता है. साथ ही, ऐसे डैशबोर्ड भी बनाए जा सकते हैं जिन्हें आने वाले समय में खरीदारी के लिए, आधुनिक वेबसाइट चलाने से जुड़े कई हिस्सेदारों के साथ शेयर किया जा सकता है. उदाहरण के लिए, Guardian ने अपने-आप मिलने वाली सूचना देने वाला सिस्टम बनाया, जिसने एडिटोरियल टीम को चेतावनी दी कि हाल ही में पब्लिश किया गया कॉन्टेंट, पेज के साइज़ या स्पीड के थ्रेशोल्ड को पार कर गया था. इस वजह से, उपयोगकर्ताओं के असंतुष्ट होने की संभावना थी.

छठा चरण: नतीजे निकालना और तय करना कि आगे क्या करना है

जब आपके पास परफ़ॉर्मेंस और कारोबार मेट्रिक को जोड़ने वाला डेटा हो, तो नतीजों की जांच करके नतीजा निकाला जा सकता है.

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

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

चेतावनियां

साइट स्पीड मेट्रिक और कारोबार मेट्रिक के बीच सही संबंध न दिखने की कई वजहें हो सकती हैं:

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

नतीजा

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