वेबसाइट की परफ़ॉर्मेंस की जानकारी को ऑप्टिमाइज़ करने और Next.js पर माइग्रेट करने पर फ़ोकस करने वाले एक प्रोजेक्ट से, कन्वर्ज़न रेट में 5% और हर सेशन में पेजों में 87% की बढ़ोतरी हुई.
Quintoandar, ब्राज़ील की एक प्रॉपटेक कंपनी है जिसके प्रॉडक्ट, रीयल एस्टेट से जुड़े डिजिटल प्लैटफ़ॉर्म पर शुरू से लेकर आखिर तक समाधान देते हैं. इस साल, हमने अपने ऐप्लिकेशन में कॉन्टेंट हब की परफ़ॉर्मेंस को बेहतर बनाने के लिए एक प्रोजेक्ट शुरू किया था. इससे हमें उपयोगकर्ताओं के ट्रैफ़िक और कन्वर्ज़न मेट्रिक को बढ़ाने में मदद मिली.
46%
बाउंस रेट में कमी
87%
हर सेशन में पेजों की संख्या में हुई बढ़ोतरी
5%
पुष्टि के चरण के दौरान कन्वर्ज़न में सुधार
चैलेंज
हमारे ऐप्लिकेशन में 40,000 से ज़्यादा पेज वाला कॉन्डोमिनियम कॉन्टेंट हब है, जहां लोग अपनी प्रॉपर्टी के बारे में जानकारी पा सकते हैं, कॉमन एरिया की फ़ोटो देख सकते हैं, आस-पास की जगहों के बारे में पढ़ सकते हैं, और किराये या बिक्री के लिए उपलब्ध लिस्टिंग देख सकते हैं. QuintoAndar के लिए ये पेज बहुत ज़रूरी हैं:
- वे ऑर्गैनिक ट्रैफ़िक के एक अहम सोर्स हैं, जहां सर्च इंजन के नतीजों से आने वाले उपयोगकर्ताओं की संख्या लगातार बढ़ती जा रही है.
- अन्य पेजों की तुलना में, मध्यम से दीर्घ अवधि में उनकी कन्वर्ज़न दर ज़्यादा होती है.
हालांकि, इन पेजों पर परफ़ॉर्मेंस और उपयोगकर्ता अनुभव को लेकर कई चुनौतियां थीं:
- वेबसाइट की परफ़ॉर्मेंस की जानकारी के आधार पर, कंपनी की परफ़ॉर्मेंस को ऑप्टिमाइज़ नहीं किया गया. साथ ही, पेज के लोड होने में ज़्यादा समय लगने, उपयोगकर्ता के इनपुट कम होने, और लेआउट के खराब होने जैसी समस्याओं की वजह से भी कई समस्याएं हुईं.
- ऐप्लिकेशन के अन्य हिस्सों के मुकाबले, इन लोगों की बाउंस रेट ज़्यादा थी. भले ही, हमें उम्मीद थी कि ये रेट ज़्यादा होंगे.
- Google Search में पेज की परफ़ॉर्मेंस से जुड़े अपडेट—जो उस समय रिलीज़ नहीं हुआ था—उसे रैंकिंग एल्गोरिदम में वेबसाइट की परफ़ॉर्मेंस से जुड़ी अहम जानकारी के तौर पर शामिल किया जाएगा. इसका मतलब है कि पेज की परफ़ॉर्मेंस से, खोज के नतीजों के दिखने के तरीके पर असर पड़ सकता है.
इसी दौरान, हमने डेवलपर को मिलने वाले अनुभव के कुछ ऐसे अवसरों का पता लगाया जिनसे कंपनी के दूसरे प्रोजेक्ट में फ़ायदा मिल सकता है:
- हमारा सर्वर साइड रेंडरिंग तर्क, जो ज़्यादा ट्रैफ़िक वाले सभी पेजों को रेंडर करता है, उनमें कंडोमिनियम पेज भी शामिल हैं. इसे इन-हाउस बनाया गया. इसलिए, नए कर्मचारियों को बनाए रखने और उन्हें शामिल करने के लिहाज़ से यह काफ़ी जटिल हो गया है.
- ऐप्लिकेशन की अच्छी परफ़ॉर्मेंस के लिए, इसमें कुछ ज़रूरी सुविधाएं शामिल हैं. जैसे, कोड को अलग-अलग हिस्सों में बांटना. इसके अलावा, इसमें डेवलपर को मैन्युअल तरीके से सेटअप करने के साथ-साथ डेवलपर को भी काम करने की ज़रूरत पड़ती है.
- QuintoAndar में 30 से ज़्यादा React वेब ऐप्लिकेशन हैं. इन ऐप्लिकेशन को अपडेट देना और सबसे सही तरीकों के हिसाब से इनका रखरखाव करना एक मुश्किल काम है.
तरीका
हमने कंडोमिनियम कॉन्टेंट हब के परफ़ॉर्मेंस ऑप्टिमाइज़ेशन प्रोजेक्ट पर काम शुरू किया, ताकि इसके उपयोगकर्ताओं के अनुभव को बेहतर बनाया जा सके. ऐसा इसलिए, क्योंकि इन सुधारों की वजह से कन्वर्ज़न बढ़ाने, एसईओ, और बेहतर इस्तेमाल करने में मदद मिल सकती है. यह पहल, डेवलपर के अनुभव को बेहतर बनाने के लिए भी एक बढ़िया अवसर थी.
Next.js पर माइग्रेट करना
कॉन्डोमिनियम पेज का नया वर्शन, Next.js की मदद से लागू किया गया. ऐप्लिकेशन के अन्य हिस्सों से काफ़ी हद तक अलग होने की वजह से, नया फ़्रेमवर्क आज़माने के लिए कंडोमिनियम कॉन्टेंट हब एक अच्छा कैंडिडेट लग रहा था. हम यह समझ पाएंगे कि माइग्रेशन की क्षमता कितनी है. साथ ही, हम यह आकलन कर पाएंगे कि इसकी सुविधाएं, Quintoandar के अन्य React ऐप्लिकेशन पर असर डाले बिना कैसे मदद कर सकती हैं.
यह पक्का करना मुश्किल था कि पेज, सर्च इंजन से क्रॉल किए जा सकें. Next.js इस ज़रूरी शर्त को पूरा करता है. इसके लिए, सर्वर-साइड रेंडरिंग की सुविधा बेहतर होगी. साथ ही, यह कस्टम सेटअप की ज़रूरत को हटा देता है. इस दस्तावेज़ की मदद से, सर्वर पर डेटा फ़ेच करने और नए डेवलपर को शामिल करने जैसे कामों के बारे में आसानी से जानकारी शेयर की जा सकती है. सर्वर साइड रेंडरिंग को फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) जैसी परफ़ॉर्मेंस को बेहतर करने के लिए भी जाना जाता है.
इस फ़्रेमवर्क में, परफ़ॉर्मेंस को बेहतर बनाने वाली अन्य सुविधाएं भी मिलती हैं. जैसे, कोड को अपने-आप बांटना और प्रीफ़ेच करना. हालांकि, मौजूदा स्ट्रक्चर में पहले से ही ये सुविधाएं उपलब्ध थीं, फिर भी डेवलपर को और काम करने की ज़रूरत थी, लेकिन अब भी इसे इस्तेमाल करने की प्रक्रिया रुक गई है. उदाहरण के लिए, पेज या कॉम्पोनेंट के लेवल पर कोड को मैन्युअल तरीके से बांटना होता है.
JavaScript के संसाधनों को ऑप्टिमाइज़ करना
सबसे पहले, इस्तेमाल न किए जा रहे कोड को हटाना है. हमने वेबपैक बंडल ऐनालाइज़र रिपोर्ट को देखा, जिसमें हर JS बंडल का कॉन्टेंट दिखता है. साथ ही, हमने तीसरे पक्ष की सभी स्क्रिप्ट की ध्यान से समीक्षा की है. इस वजह से, हम कुछ ऐसी ट्रैकिंग लाइब्रेरी को हटा पाए जिनका इस्तेमाल इस पेज पर नहीं किया जाता था.
हमारी टीम ने इसके बाद, मौजूदा सुविधाओं की परफ़ॉर्मेंस पर होने वाले खर्च का आकलन किया. उदाहरण के लिए, "पसंद करें" बटन को काम करने के लिए काफ़ी सारे JS की ज़रूरत थी. हालांकि, कॉन्डमिनियम पेज पर, 0.5% से कम उपयोगकर्ताओं ने बटन से इंटरैक्ट किया. यह बटन उपलब्ध है और इसका इस्तेमाल हमारे ऐप्लिकेशन के अन्य हिस्सों में ज़्यादा किया जाता है. इंजीनियरिंग और प्रॉडक्ट, दोनों से जुड़ी चर्चा के बाद हमने इस सुविधा को हटाने का फ़ैसला लिया है.
अन्य JS ऑप्टिमाइज़ेशन पहले से मौजूद थे. जैसे, Brotli के साथ स्टैटिक कंप्रेशन. यह प्रोसेस, बिल्ड के दौरान BrotliWebpackPlugin
का इस्तेमाल करके की जाती थी. साथ ही, इसे अन्य तरह के स्टैटिक संसाधनों पर भी लागू किया जाता था. पहले हम सीडीएन से मिलने वाले कंप्रेस पर निर्भर थे. इसलिए, Brotli ने gzip की तुलना में JS साइज़ को 18% कम किया. हालांकि, बिल्ड के समय हमने Brotli का कंप्रेशन इस्तेमाल करने पर स्विच किया. इससे हमें 24% की कमी हासिल हुई.
इमेज के संसाधनों को ऑप्टिमाइज़ करना
मोबाइल वर्शन में हीरो इमेज, पेज के ऊपरी हिस्से के ज़्यादातर हिस्से में दिख रही है. यह पेज का सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी) भी होता है.
रिस्पॉन्सिव इमेज दिखाने के लिए, सभी इमेज में पहले से ही srcset
और sizes
एट्रिब्यूट मौजूद थे. हमने thumbsor का इस्तेमाल करके, मांग पर इमेज का साइज़ बदला है. साथ ही, उन्हें बेहतर तरीके से कैश मेमोरी में सेव करने के लिए, अपने सीडीएन को कॉन्फ़िगर किया है.
आधुनिक मोबाइल डिवाइस में बहुत ज़्यादा पिक्सल डेंसिटी वाले डिसप्ले होते हैं. इसका मतलब है कि उपलब्ध होने पर ब्राउज़र, इमेज का 3x या 4x वर्शन रेंडर करेगा. जैसे-जैसे रिज़ॉल्यूशन बढ़ता है, लोगों की आंखों के लिए दोनों अंतर को समझना मुश्किल हो जाता है. हालांकि, फ़ाइल का साइज़ बढ़ता जाएगा, फिर चाहे फ़ाइल का साइज़ बढ़ता जाए. इमेज के ज़्यादा से ज़्यादा रिज़ॉल्यूशन को पूरा करने से, उपयोगकर्ता अनुभव से समझौता किए बिना इमेज का साइज़ बेहतर होता है. हमने हीरो इमेज को ज़्यादा से ज़्यादा दोx वर्शन दिखाने के लिए सीमित कर दिया है. यह इमेज, 3x वर्शन से करीब 35% छोटी और 4x वर्शन से 50% छोटी है.
इस प्रोसेस को पूरा करने के लिए, हमने पहले से लोड करने की रणनीति का इस्तेमाल किया, ताकि इसे जल्द से जल्द डाउनलोड करके दिखाया जा सके. हमें उम्मीद है कि एलसीपी मेट्रिक में सुधार होगा.
<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">
Next.js बिल्ट-इन इमेज कॉम्पोनेंट में, इनमें से कई ऑप्टिमाइज़ेशन शामिल होते हैं. जैसे, रिस्पॉन्सिव साइज़ बदलना और प्राथमिकता के हिसाब से लोड करना. इस प्रोजेक्ट के दौरान, हमने इस कॉम्पोनेंट का इस्तेमाल करने के लिए मौजूदा इमेज को माइग्रेट नहीं किया. हालांकि, हम इसे नई सुविधाओं में शामिल करने की योजना बना रहे हैं.
लेआउट शिफ़्ट को कम किया जा रहा है
कॉन्डोमिनियम पेज पर, कुल लेआउट शिफ़्ट (सीएलएस) की कुछ समस्याएं थीं. लेआउट शिफ़्ट के लिए ज़िम्मेदार एलिमेंट सिर्फ़ क्लाइंट में रेंडर किए जाते थे—उदाहरण के लिए, क्लाइंट के रेंडर किए गए कॉम्पोनेंट के साथ सर्वर साइड मार्कअप को हाइड्रेट करना या ऐसी इमेज जिनमें width
और height
एट्रिब्यूट तय न किए गए हों.
इन समस्याओं को हल करने के लिए, हम ज़रूरत पड़ने पर इन एलिमेंट के सटीक डाइमेंशन या min-height
की मदद से अनुमानित वैल्यू सेट करते हैं. कई और विकल्प मौजूद हैं. जैसे, aspect-ratio
सीएसएस प्रॉपर्टी का इस्तेमाल करना. हमने प्लेसहोल्डर भी बनाए हैं, ताकि डाइनैमिक तौर पर रेंडर होने वाले कॉम्पोनेंट की वजह से, लेआउट शिफ़्ट न हो.
बदलावों को धीरे-धीरे रोल आउट करना
हमारी टीम इस बात की पुष्टि करना चाहती है कि लोगों को बेहतर अनुभव देने के लिए, कंडोमिनियम हब पेज के ऑप्टिमाइज़ किए गए वर्शन को ऑप्टिमाइज़ किया गया है या नहीं. इसे हासिल करने के लिए, हमने धीरे-धीरे रोल आउट की रणनीति अपनाई:
- पहले चरण में, नए वर्शन को चुनिंदा यूआरएल के लिए पब्लिश किया गया था, इसलिए हर दिन सिर्फ़ सैकड़ों उपयोगकर्ताओं को वे यूआरएल दिखेंगे;
- दूसरे चरण में, इसे कुछ और पेजों के लिए पब्लिश किया गया था. हर दिन सिर्फ़ कुछ हज़ार उपयोगकर्ताओं को ध्यान में रखा गया था;
- तीसरे और आखिरी चरण में, इसे सभी पेजों के लिए पब्लिश किया गया और सभी उपयोगकर्ताओं के लिए रोल आउट पूरा किया गया.
इस दौरान, इंजीनियरिंग टीम ने प्रोडक्शन में पेज की परफ़ॉर्मेंस को लगातार मापा और उसे बेहतर बनाने के लिए काम किया. इसके अलावा, टीम ने नए और पिछले वर्शन के बीच कारोबार की मेट्रिक की तुलना की. पुष्टि की इस अवधि में मिले नतीजे भरोसेमंद थे.
नतीजे
टीम ने कंडोमिनियम पेज की जांच करने के लिए, लगातार लैब टेस्ट करने के लिए, SpeedCurve का इस्तेमाल किया. ये रहे मोबाइल वर्शन के नतीजे:
लैब मेट्रिक | पहले | बाद में | अंतर |
---|---|---|---|
सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी) | 2.41 सेकंड | 1.48 सेकंड | -39% से ज़्यादा |
टाइम टू इंटरैक्टिव (टीटीआई) | 12.16 सेकंड | 7.48 सेकंड | -39% से ज़्यादा |
टोटल ब्लॉकिंग टाइम (टीबीटी) | 1124 मिलीसेकंड | 1056 मिलीसेकंड | -4% से कम |
कुल लेआउट शिफ़्ट (सीएलएस) | 0.0402 | 0.0093 | -77% से कम |
हम यह भी देखना चाहते थे कि टेक्नोलॉजी का इस्तेमाल करने वाले लोगों पर इसका क्या असर पड़ सकता है. Instana वेबसाइट मॉनिटरिंग की मदद से इकट्ठा किए गए फ़ील्ड डेटा का इस्तेमाल करके, हमने रोल आउट से एक महीने पहले और बाद की अवधि को देखा. मोबाइल उपयोगकर्ताओं के 75वें पर्सेंटाइल की तुलना में, हमें पता चला कि एलसीपी में 26% और एफ़आईडी में 72% की कमी आई.
PageSpeed Insights पिछले 28 दिनों का फ़ील्ड डेटा रिपोर्ट उपलब्ध कराता है. सिर्फ़ सबसे ज़्यादा ऐक्सेस किए गए कॉन्डोमिनियम पेज में, मोबाइल इस्तेमाल करने वालों के लिए रिपोर्ट जनरेट करने के लिए ज़रूरी डेटा था. नवंबर 2021 से, वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली सभी मेट्रिक "अच्छी" कैटगरी में हैं.
धीरे-धीरे रोल आउट करने के दौरान, हमने बाउंस दरों में गिरावट देखी. सभी पेजों के लिए रिलीज़ तैयार करने से पहले, Google Analytics ने बाउंस रेट में 46% की कमी, हर सेशन में पेजों में 87% की बढ़ोतरी, और सेशन की औसत अवधि में 49% की बढ़ोतरी दिखाई. पेड सर्च के मामले में बाउंस रेट में गिरावट आई और वह 59% तक पहुंच गई. यह हर क्लिक के पेमेंट (पीपीसी) विज्ञापनों में निवेश के मामले में एक अच्छा संकेत है.
कारोबार की मेट्रिक पर पड़ने वाले असर के लिए, हमने लेन-देन के लिए कन्वर्ज़न रेट का विश्लेषण किया. जैसे, टूर शेड्यूल करना और प्रॉपर्टी खरीदने या किराये पर लेने के लिए आवेदन करना. जब तक सुधार लागू किए जा रहे थे, तब हमारी टीम ने पुराने और नए वर्शन के बीच हुए कन्वर्ज़न की तुलना की. इसी हफ़्ते, नए वर्शन वाले पेजों के ग्रुप के कन्वर्ज़न में 5% की बढ़ोतरी हुई, जबकि दूसरे पेजों के लिए उसी मेट्रिक में थोड़ी कमी आई.
नतीजा
यह प्रोजेक्ट, लंबे समय तक चलने वाले माइग्रेशन की कोशिश का पहला हिस्सा है. माइग्रेशन के लिए, बिना फ़्रेमवर्क के प्रतिक्रिया देने की सुविधा से Next.js पर स्विच करना. उसके बाद से, कॉन्डोमिनियम पेज पर काम करने वाली टीमों ने डेवलपर के बेहतर अनुभव के बारे में पॉज़िटिव फ़ीडबैक दिया है. अन्य टीमों को नए वेब ऐप्लिकेशन को बूटस्ट्रैप करना पड़ा था, वे Next.js के साथ पहले ही ऐसा कर चुकी हैं. हमारा मानना है कि Next.js से, कई ऐप्लिकेशन के रखरखाव का काम आसान हो जाएगा और यह अलग-अलग ऐप्लिकेशन के बीच एक मज़बूत रिश्ता बना लेगा.
कुल मिलाकर, उपयोगकर्ताओं की संख्या और लेन-देन के मामले में, कॉन्डमिनियम कॉन्टेंट हब लगातार बढ़ रहा है. लंबे समय तक किए जाने वाले विश्लेषण में, कई वजहों से इसमें योगदान हो सकता है. जैसे, Quinto&ar के काम करने का दायरा बढ़ाना और पेज को बेहतर तरीके से इंडेक्स करने जैसी एसईओ की पहल. इस प्रोजेक्ट के दौरान, हमने देखा है कि पेज की परफ़ॉर्मेंस भी इनमें से एक है. इसकी वजह से कन्वर्ज़न पर सकारात्मक असर पड़ने की संभावना है.
उपयोगकर्ता के डेटा की पूरी जानकारी और इस केस स्टडी में दिखाए गए सभी कन्वर्ज़न विश्लेषण बनाने के लिए, एसईओ टीम के प्रॉडक्ट मैनेजर, पेड्रो कार्मो को खास धन्यवाद.