जानें कि QuintoAndar ने पेज की परफ़ॉर्मेंस को बेहतर बनाकर, हर सेशन में कन्वर्ज़न रेट और पेजों की परफ़ॉर्मेंस को कैसे बढ़ाया

Core Web Vitals को ऑप्टिमाइज़ करने और Next.js पर माइग्रेट करने पर फ़ोकस करने वाले प्रोजेक्ट की वजह से, कन्वर्ज़न रेट में 5% और हर सेशन के पेजों में 87% की बढ़ोतरी हुई.

Daniela Sayuri Yassuda
Daniela Sayuri Yassuda

QuintoAndar, ब्राज़ील की प्रॉपर्टी टेक्नोलॉजी कंपनी है. इसके प्रॉडक्ट, रीयल एस्टेट से जुड़ी सभी समस्याओं के लिए डिजिटल समाधान उपलब्ध कराते हैं. इस साल, हमने अपने ऐप्लिकेशन में कॉन्टेंट हब की परफ़ॉर्मेंस को बेहतर बनाने पर फ़ोकस किया. इससे हमें उपयोगकर्ता ट्रैफ़िक और कन्वर्ज़न मेट्रिक को बढ़ाने में मदद मिली.

46%

बाउंस दर में कमी

87%

हर सेशन में देखे गए पेजों की संख्या में हुई बढ़ोतरी

5%

पुष्टि करने के दौरान कन्वर्ज़न में सुधार

चुनौतियां

हमारे ऐप्लिकेशन में,40, 000 से ज़्यादा पेजों वाला एक कॉन्डोमिनियम कॉन्टेंट हब है. यहां उपयोगकर्ता अपनी प्रॉपर्टी के बारे में जानकारी पा सकते हैं, सामान्य जगहों की फ़ोटो देख सकते हैं, आस-पास के इलाके के बारे में पढ़ सकते हैं, और किराये या बिक्री के लिए उपलब्ध लिस्टिंग देख सकते हैं. ये पेज QuintoAndar के लिए बहुत ज़रूरी हैं:

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

हालांकि, इन पेजों की परफ़ॉर्मेंस और उपयोगकर्ता अनुभव को लेकर कुछ समस्याएं थीं:

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

साथ ही, हमें डेवलपर के अनुभव से जुड़े कुछ ऐसे अवसर मिले जिनसे कंपनी के दूसरे प्रोजेक्ट में भी फ़ायदे मिल सकते हैं:

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

तरीका

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

Next.js पर माइग्रेट करना

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

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

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

JavaScript रिसॉर्स को ऑप्टिमाइज़ करना

पहला कदम, इस्तेमाल न किए गए कोड को हटाना था. हमने Webpack Bundle Analyzer की रिपोर्ट देखी हैं. इन रिपोर्ट में हर JS बंडल का कॉन्टेंट दिखता है. साथ ही, हमने तीसरे पक्ष की सभी स्क्रिप्ट की सावधानी से समीक्षा की है. इस वजह से, हम इस पेज पर इस्तेमाल न की जाने वाली कुछ ट्रैकिंग लाइब्रेरी को हटा पाए.

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

इस ऐनिमेशन में, “पसंद करें” बटन की सुविधा दिख रही है. किराये पर उपलब्ध अपार्टमेंट का कार्ड. कार्ड के नीचे दाएं कोने में, दिल के आकार का स्लेटी बटन होता है, जिस पर क्लिक करने पर उसका रंग नीला हो जाता है.

दूसरे JS ऑप्टिमाइज़ेशन पहले से ही मौजूद थे, जैसे कि Brotali के साथ स्टैटिक कंप्रेशन, जो बिल्ड के समय BrotliWebpackPlugin का इस्तेमाल करके किया गया था और दूसरे तरह के स्टैटिक रिसॉर्स पर भी लागू किया गया था. पहले, हम सीडीएन की ओर से उपलब्ध कराए गए कंप्रेसन पर निर्भर थे. gzip की तुलना में, Brotli ने JS के साइज़ को 18% कम कर दिया. हालांकि, हमने बाइल्ड के समय Brotli कंप्रेसन का इस्तेमाल किया और 24% की कमी हासिल की.

इमेज के संसाधनों को ऑप्टिमाइज़ करना

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

Edifício Copan (साओ पाओलो, ब्राज़ील) का कॉन्डोमिनियम पेज. ज़मीन से ली गई फ़ोटो में, इमारत के स्ट्रक्चर के कर्व दिख रहे हैं.
कोंडोमिनियम पेज की हीरो इमेज.

इससे पहले, रिस्पॉन्सिव इमेज दिखाने के लिए, सभी इमेज में srcset और sizes एट्रिब्यूट पहले से मौजूद होते थे. हमने Thumbor का इस्तेमाल करके, मांग पर इमेज का साइज़ भी बदला. साथ ही, अपने सीडीएन को कॉन्फ़िगर किया, ताकि इमेज को बेहतर तरीके से कैश मेमोरी में सेव किया जा सके.

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

आखिर में, हमने एलसीपी मेट्रिक को बेहतर बनाने के लिए, पहले से लोड करने की रणनीति का इस्तेमाल किया, ताकि इमेज को जल्द से जल्द डाउनलोड और दिखाया जा सके.

<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">

Next.js में पहले से मौजूद इमेज कॉम्पोनेंट में, इनमें से कई ऑप्टिमाइज़ेशन शामिल हैं. जैसे, रिस्पॉन्सिव साइज़ बदलना और प्राथमिकता के हिसाब से लोड करना. इस प्रोजेक्ट के दौरान, हमने इस कॉम्पोनेंट का इस्तेमाल करने के लिए, मौजूदा इमेज को माइग्रेट नहीं किया. हालांकि, हम इसे नई सुविधाओं में इस्तेमाल करने की योजना बना रहे हैं.

लेआउट शिफ़्ट को कम करना

कंडोमिनियम पेज पर, कुल लेआउट शिफ़्ट (सीएलएस) से जुड़ी कुछ समस्याएं थीं. लेआउट में बदलाव करने वाले एलिमेंट सिर्फ़ क्लाइंट में रेंडर किए गए थे. उदाहरण के लिए, क्लाइंट-रेंडर किए गए कॉम्पोनेंट की मदद से सर्वर-साइड मार्कअप को हाइड्रेट करना या width और height एट्रिब्यूट के बिना इमेज.

इन समस्याओं को हल करने के लिए, जब भी मुमकिन हो, हम इन एलिमेंट के लिए सटीक डाइमेंशन या अनुमानित वैल्यू सेट करते हैं. इसके लिए, हम min-height का इस्तेमाल करते हैं. इसके अलावा, aspect-ratio सीएसएस प्रॉपर्टी का इस्तेमाल करके भी ऐसा किया जा सकता है. हमने डाइनैमिक तौर पर रेंडर किए गए कॉम्पोनेंट की वजह से लेआउट में होने वाले बदलावों को रोकने के लिए, प्लेसहोल्डर भी बनाए हैं.

Google Maps में एक शहरी इलाके को दिखाने वाली इमेज. इसमें बीच में लाल मार्कर है.
मैप इमेज जैसे एलिमेंट के लिए डाइमेंशन तय करने से, सीएलएस कम हो गया.

बदलावों को धीरे-धीरे रोल आउट करना

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

  1. पहले चरण में, नए वर्शन को चुनिंदा यूआरएल के लिए पब्लिश किया गया था. इसलिए, हर दिन सिर्फ़ कुछ सौ उपयोगकर्ताओं को ही यह वर्शन दिखेगा;
  2. दूसरे चरण में, इसे ज़्यादा पेजों के लिए पब्लिश किया गया. इसकी वजह यह थी कि हर दिन कुछ हज़ार उपयोगकर्ता थे;
  3. तीसरे और आखिरी चरण में, इसे सभी पेजों के लिए पब्लिश किया गया. साथ ही, सभी उपयोगकर्ताओं के लिए रोल-आउट पूरा हो गया.

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

नतीजे

टीम ने SpeedCurve का इस्तेमाल करके, लगातार लैब टेस्ट चलाए, ताकि कन्डोमिनियम पेज की परफ़ॉर्मेंस को बेहतर बनाया जा सके. मोबाइल वर्शन के लिए ये नतीजे हैं:

लैब मेट्रिक पहले बाद में अंतर
सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी) 2.41 सेकंड 1.48 सेकंड -39%
टाइम टू इंटरैक्टिव (टीटीआई) 12.16 सेकंड 7.48 सेकंड -39%
टोटल ब्लॉकिंग टाइम (टीबीटी) 1,124 मिलीसेकंड 1056 मिलीसेकंड -4%
कुल लेआउट शिफ़्ट (सीएलएस) 0.0402 0.0093 -77% से कम
SpeedCurve की मदद से इकट्ठा की गई लैब मेट्रिक के नतीजे.

हम यह भी देखना चाहते थे कि इस समस्या का असर हमारे असली उपयोगकर्ताओं पर पड़ा है या नहीं. Instana वेबसाइट मॉनिटरिंग की मदद से इकट्ठा किए गए फ़ील्ड डेटा का इस्तेमाल करके, हमने रोल-आउट से पहले और बाद के एक महीने की अवधि को देखा. मोबाइल का इस्तेमाल करने वाले उपयोगकर्ताओं के लिए 75वें पर्सेंटाइल की तुलना करने पर, हमें पता चला कि एलसीपी में 26% और एफ़आईडी में 72% की कमी आई है.

एलसीपी वैल्यू वाला लाइन ग्राफ़. इसमें मौजूदा और पिछले महीने के नए और पिछले वर्शन की तुलना की गई है. नए वर्शन के लिए कर्व, दो से चार सेकंड के बीच फ़्लोट करता है. ज़्यादातर समय, यह पिछले वर्शन के कर्व से नीचे रहता है.
एफ़आईडी की वैल्यू दिखाने वाला लाइन ग्राफ़. इसमें, मौजूदा और पिछले महीने के नए और पिछले वर्शन की तुलना की गई है. नए वर्शन का कर्व ज़्यादातर समय 100 मि॰से॰ से कम रहता है, जबकि पिछले वर्शन के कर्व में 250 मि॰से॰ के बीच कुछ बढ़ोतरी होती है.
Instana की मदद से इकट्ठा की गई फ़ील्ड मेट्रिक के नतीजे.

PageSpeed Insights, पिछले 28 दिनों का फ़ील्ड डेटा दिखाता है. सबसे ज़्यादा ऐक्सेस किए गए कोंडोमिनियम पेज में, मोबाइल उपयोगकर्ताओं के लिए रिपोर्ट जनरेट करने के लिए काफ़ी डेटा था. नवंबर 2021 से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली सभी रिपोर्ट को "अच्छी" कैटगरी में रखा गया है.

फ़ील्ड डेटा सेक्शन पर फ़ोकस करने वाली PageSpeed Insights रिपोर्ट का स्क्रीनशॉट. वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली सभी मेट्रिक (एफ़सीपी, एफ़आईडी, एलसीपी, सीएलएस) का परफ़ॉर्मेंस अच्छी है.
PageSpeed Insights से पता चलता है कि मोबाइल उपयोगकर्ताओं को सबसे ज़्यादा ऐक्सेस किए जाने वाले कंडोमिनियम पेज पर अच्छा अनुभव मिलता है.

धीरे-धीरे रोल आउट करने के दौरान, हमें बाउंस रेट में गिरावट दिखी. सभी पेजों के लिए रिलीज़ पूरी होने तक, Google Analytics में बाउंस रेट में 46% की कमी, हर सेशन में देखे गए पेजों की संख्या में 87% की बढ़ोतरी, और सेशन की औसत अवधि में 49% की बढ़ोतरी दिखी. पेड सर्च के लिए, बाउंस रेट में 59% की गिरावट आई. यह पे-पर-क्लिक (पीपीसी) विज्ञापनों में निवेश करने के लिए एक अच्छा संकेत है.

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

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

दो लाइन ग्राफ़, साथ में हैं. हर ग्राफ़, मौजूदा और पिछले हफ़्ते के बीच के कन्वर्ज़न की तुलना करता है. बाईं ओर मौजूद ग्राफ़, पेज के पिछले वर्शन का है. इसमें मौजूदा हफ़्ते का कन्वर्ज़न कर्व, पिछले हफ़्ते के कन्वर्ज़न कर्व से थोड़ा कम है. दाईं ओर मौजूद ग्राफ़ नए वर्शन के लिए है. साथ ही, मौजूदा हफ़्ते का कन्वर्ज़न कर्व, पिछले हफ़्ते के कन्वर्ज़न कर्व से थोड़ा ऊपर है.
उसी हफ़्ते, नए वर्शन के लिए कन्वर्ज़न में बढ़ोतरी हुई, जबकि पिछले वर्शन में थोड़ी कमी आई.

नतीजा

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

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

उपयोगकर्ता के डेटा को समझने और इस केस स्टडी में दिखाए गए सभी कन्वर्ज़न विश्लेषण बनाने के लिए, एसईओ टीम के प्रॉडक्ट मैनेजर पेड्रो कार्मो का खास धन्यवाद.