साइट की परफ़ॉर्मेंस और कारोबार की मेट्रिक के बीच का संबंध ढूंढना, ऑप्टिमाइज़ेशन की कोशिशों को सफल बनाने के लिए अहम था.
Swappie एक सफल स्टार्ट-अप है, जो नए जैसे किए गए फ़ोन बेचता है. कुछ सालों तक, उन्होंने साइट की परफ़ॉर्मेंस के बजाय नई सुविधाएं जोड़ने को प्राथमिकता दी. हालांकि, जब उन्हें पता चला कि मोबाइल साइट पर कारोबार के नतीजे, डेस्कटॉप वर्शन से पीछे चल रहे हैं, तो उन्होंने अपना रुख बदला. उन्होंने परफ़ॉर्मेंस को ऑप्टिमाइज़ करने पर फ़ोकस किया और जल्द ही उन्हें मोबाइल से होने वाले रेवेन्यू में बढ़ोतरी दिखी.
42%
मोबाइल से आने वाले विज़िटर से मिलने वाले रेवेन्यू में बढ़ोतरी
10pp*
*प्रतिशत में रिलेशनल mCvR में बढ़ोतरी
अवसर को हाइलाइट करना
रिलेटिव मोबाइल कन्वर्ज़न रेट (Rel mCvR) का हिसाब लगाने के लिए, मोबाइल कन्वर्ज़न रेट को डेस्कटॉप कन्वर्ज़न रेट से भाग दिया जाता है. स्पीड मेट्रिक को ट्रैक करने के कई अवसर हैं, लेकिन इन्हें कारोबार की मेट्रिक से जोड़ना काफ़ी मुश्किल हो सकता है. एक ही कैंपेन और सीज़नैलिटी, मोबाइल और डेस्कटॉप, दोनों पर पहुंचती हैं. इसलिए, Rel mCvR मेट्रिक इन बाहरी पैरामीटर का असर हटा देती है और सिर्फ़ यह दिखाती है कि मोबाइल साइट बेहतर हो रही है या नहीं.
अमेरिका की 10 सबसे बड़ी ई-कॉमर्स साइटों का औसत रिलेशनल mCvR 50%है, लेकिन Swappie का रिलेशनल mCvR 24% था. इससे पता चला कि मोबाइल साइट में समस्याएं थीं और कंपनी को रेवेन्यू नहीं मिल रहा था. इसलिए, परफ़ॉर्मेंस को बेहतर बनाने वाला प्रोजेक्ट लॉन्च किया गया.
परफ़ॉर्मेंस में हुए सुधारों का असर मेज़र करना
Swappie ने इस टेंप्लेट स्प्रेडशीट का इस्तेमाल करके, Google Analytics का इस्तेमाल करके, Rel mCvR और मोबाइल पर पेज लोड होने में लगने वाले औसत समय की रोज़ की ट्रैकिंग सेट अप की. (स्प्रेडशीट इस्तेमाल करने के निर्देश पढ़ें.) उन्होंने Google Analytics और BigQuery की मदद से, मुख्य वेब विज़ुअल को ट्रैक करना भी शुरू किया. ट्रैकिंग की सुविधा लागू होने के बाद, डेवलपर ने साइट की परफ़ॉर्मेंस पर काम करना शुरू किया.
सिर्फ़ तीन महीने के काम के बाद, इसका असर साफ़ तौर पर दिखने लगा था–Rel mCvR 24% से बढ़कर 34% हो गया और मोबाइल से होने वाला रेवेन्यू 42% बढ़ गया!
23%
पेज लोड होने में लगने वाला औसत समय कम करना
55%
कम एलसीपी
91%
कम सीएलएस
90%
कम एफ़आईडी
अनुकूलन
एलसीपी और सीएलएस के लिए ऑप्टिमाइज़ करना
Swappie की डेवलपमेंट टीम को पता चला कि उन छोटी चीज़ों में बहुत सुधार की गुंजाइश है जिन्हें लंबे समय से अनदेखा किया जा रहा था. अलग-अलग व्यूपोर्ट और अलग-अलग भाषाओं में साइट का अध्ययन करने पर, एलसीपी और सीएलएस से जुड़ी समस्याएं हाइलाइट हुईं. इन समस्याओं को हल करना आसान था और इनका असर साइट की परफ़ॉर्मेंस पर काफ़ी पड़ा. उदाहरण के लिए, जब संभव हो, तब क्लाइंट के बजाय सर्वर पर एलसीपी एलिमेंट को रेंडर करने से एलसीपी कम हो गया.
लेआउट में होने वाले बदलावों का पता लगाना मुश्किल था, क्योंकि ये व्यूपोर्ट और कनेक्शन के आधार पर काफ़ी अलग-अलग हो सकते हैं. उपयोगकर्ताओं से अपने आंकड़ों में वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी मिलने के बाद, उन्हें पता चला कि वे सही दिशा में हैं, क्योंकि सीएलएस कम हो गया था.
इमेज
इमेज को प्रीलोड करने, लेज़ी लोडिंग, और सही साइज़ के हिसाब से ऑप्टिमाइज़ किया गया था. ये मुख्य इमेज (उदाहरण के लिए, एलसीपी) को पहले से लोड कर लेते हैं. साथ ही, व्यूपोर्ट के बाहर की इमेज को सिर्फ़ ज़रूरत पड़ने पर लोड करते हैं.
फ़ॉन्ट
Swappie ने फ़ॉन्ट की सेवा देने वाली कंपनी को बदलकर, फ़ॉन्ट को ऑप्टिमाइज़ किया. इससे काफ़ी फ़ायदा हुआ, क्योंकि उन्हें अलग-अलग भाषाओं के लिए ज़रूरी टाइपफ़ेस को मैनेज करने का बेहतर तरीका चाहिए था.
तीसरे पक्ष की स्क्रिप्ट
Swappie ने तीसरे पक्ष की हर स्क्रिप्ट और विजेट की समीक्षा करने के लिए काफ़ी मेहनत की है. साथ ही, यह भी देखा है कि इनका इस्तेमाल कहां किया गया था और इनसे कौनसी सुविधाएं मिलीं. सभी हिस्सेदारों के साथ चर्चा करने के बाद, उन्होंने साइट पर स्क्रिप्ट के असर को कम करने के लिए प्लान बनाए. उन्होंने ग़ैर-ज़रूरी को हटा दिया और बाकी को ऑप्टिमाइज़ कर दिया. इससे, साइट पर तीसरे पक्ष के JavaScript की संख्या काफ़ी कम हो गई.
इस्तेमाल न किए गए कोड को हटाना और बंडलिंग को ऑप्टिमाइज़ करना
इंपोर्ट को ऑप्टिमाइज़ करने और इस्तेमाल न किए गए JS और CSS को हटाने से, Swappie की साइट की परफ़ॉर्मेंस में थोड़ा सुधार हुआ. हालांकि, समय के साथ ये छोटे सुधार बढ़ जाते हैं. उन्होंने अपने बंडलिंग सेटअप को भी ऑप्टिमाइज़ किया.
Swappie में परफ़ॉर्मेंस को बढ़ावा देना
Swappie को जो नतीजे मिले वे सिर्फ़ कोड में किए गए बदलावों की वजह से नहीं, बल्कि संगठन और उसकी प्राथमिकताओं में किए गए बदलावों की वजह से भी मिले.
इंजीनियरिंग लीड, तेमू हुवाइनन ने बताया:
साइट की स्पीड की अहमियत को हाइलाइट करने के लिए, आपको उसे कारोबार की मेट्रिक से लिंक करना होगा. जब आपके पास समय और संसाधन कम होते हैं, तो आपको प्राथमिकता तय करनी पड़ती है. ग्राहक की वैल्यू को प्राथमिकता देना सबसे सही तरीका है. हालांकि, अगर साइट की स्पीड को सिर्फ़ साइट के "फ़ील" को बेहतर बनाने के तौर पर देखा जाता है, तो नई सुविधाओं और सीधे कन्वर्ज़न में सुधार पर फ़ोकस करना बहुत आसान है. साइट की स्पीड को कारोबार की मेट्रिक से जोड़ना हमेशा आसान नहीं होता. ऐसे में, Rel mCvR की मदद से कैलकुलेशन से हमें काफ़ी मदद मिली.
Teemu Huovinen
जब डेवलपर की टीम को एक तिमाही के लिए, पूरी तरह से साइट की स्पीड पर फ़ोकस करने का मौका मिला, तो वे ज़्यादा बेहतर तरीके से काम करने के लिए प्रेरित हुए.
हमारी टीम के बढ़ते हुए सदस्यों की संख्या और हमारे असर को मिलाकर, यह और भी शानदार है. हमने जब परफ़ॉर्मेंस पर काम शुरू किया था, तब हमारे सात में से चार डेवलपर ने एक महीने के अंदर काम करना शुरू कर दिया था. इस काम का पूरा श्रेय टीम को जाता है. यह वाकई में कमाल है कि हम इस विषय पर एक साथ काम कर पाए और इसका इतना अच्छा असर पड़ा.
Teemu Huovinen
Teemu ने शुरुआत में समय बिताने के महत्व के बारे में भी बताया है, ताकि डेटा के आधार पर प्लान बनाए जा सकें. साथ ही, DevTools के परफ़ॉर्मेंस टैब का इस्तेमाल करने और कोई भी सुधार करने से पहले, उपयोगकर्ता के आंकड़े सेट अप करने के बारे में भी बताया है. ग्राफ़ (खास तौर पर, सही दिशा में बढ़ने वाले ग्राफ़), आपके काम के लिए सुझाव, शिकायत या राय पाने और पुष्टि करने का एक शानदार सोर्स हैं! Lighthouse (लैब पर आधारित) स्कोर के साथ-साथ फ़ील्ड में कोर वेब विटल की जांच करने से, उन्हें उन चीज़ों को ऑप्टिमाइज़ करने में मदद मिली जिनसे ज़्यादा से ज़्यादा लोगों पर असर पड़ेगा.