पब्लिश होने की तारीख: 14 अक्टूबर, 2025
पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी), रिस्पॉन्स में लगने वाले समय का आकलन करने के लिए, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली एक ज़रूरी मेट्रिक है. Fotocasa के लिए, Google Search Console ने ऐसे कई पेजों को हाइलाइट किया जो 2024 में, आईएनपी को पहले इनपुट में देरी (एफ़आईडी) की जगह लागू किए जाने के बाद, "बेहतर बनाने की ज़रूरत है" और "खराब" के तौर पर मार्क किए गए थे. इस केस स्टडी में, इन समस्याओं का पता लगाने और उन्हें हल करने के लिए इस्तेमाल किए गए टूल और रणनीतियों के बारे में बताया गया है. इससे, INP में काफ़ी सुधार हुआ.
Fotocasa की टीम ने कहां से शुरुआत की
एफ़आईडी से आईएनपी पर स्विच करने से पहले, डेस्कटॉप और मोबाइल, दोनों पर मौजूद लगभग हर पेज "अच्छा" थ्रेशोल्ड में था. इसका मतलब है कि उस समय वेबसाइट की परफ़ॉर्मेंस की सभी अहम जानकारी (एलसीपी, सीएलएस, और एफ़आईडी) अच्छी परफ़ॉर्म कर रही थीं. हालांकि, INP पर स्विच करने के बाद, लगभग सभी पेज "सुधार की ज़रूरत है" वाले सेक्शन में चले गए. कुछ पेज "खराब" वाले सेक्शन में भी चले गए, क्योंकि ज़्यादातर यूज़र इंटरैक्शन के लिए INP वैल्यू लगातार 200 मिलीसेकंड से ज़्यादा थी.
इस बदलाव से, Fotocasa की टीम को यह पता चला कि वे उपयोगकर्ता अनुभव के एक अहम पहलू को नज़रअंदाज़ कर रही हैं. एफ़आईडी सिर्फ़ पहले इंटरैक्शन में होने वाली देरी को मापता है. वहीं, आईएनपी सभी इंटरैक्शन के रिस्पॉन्सिव होने का आकलन करता है. इसमें इनपुट प्रोसेसिंग और प्रज़ेंटेशन में होने वाली देरी को भी शामिल किया जाता है. Google के मुताबिक, यह बेहतर मेज़रमेंट, असली इंटरैक्टिविटी का बेहतर प्रॉक्सी है. साथ ही, इससे उन मौकों के बारे में पता चलता है जिनका फ़ायदा नहीं उठाया गया.
Google Search Console, फ़ील्ड की परफ़ॉर्मेंस का डेटा उपलब्ध कराता है. हालांकि, यह रीयल-टाइम इनसाइट उपलब्ध नहीं कराता. इसका डेटा, 28 दिनों के हिसाब से इकट्ठा किया जाता है. इसलिए, यह पता लगाना मुश्किल हो जाता है कि किस इंटरैक्शन की वजह से समस्या आ रही है.
आईएनपी को रीयल टाइम में ट्रैक करने का तरीका ज़रूरी था, ताकि उन इंटरैक्शन की पहचान की जा सके जो सबसे धीमे और उपयोगकर्ताओं के सबसे ज़्यादा इस्तेमाल किए गए थे. साथ ही, उन्हें टीम के डेवलपमेंट एनवायरमेंट में भरोसेमंद तरीके से फिर से बनाया जा सके. बदलावों के असर को समझना भी उतना ही ज़रूरी था. यह जानना ज़रूरी था कि किन सुधारों से मदद मिली. साथ ही, यह भी जानना ज़रूरी था कि किन बदलावों से परफ़ॉर्मेंस खराब हुई.
इन वजहों से, समस्याओं का पता लगाने और उन्हें हल करने के लिए टूल के एक सेट का इस्तेमाल किया गया. इनमें से सबसे अहम ये थे:
- Google Chrome DevTools, खास तौर पर परफ़ॉर्मेंस टैब.
- Fotocasa की टीम ने Datadog में, web-vitals लाइब्रेरी का इस्तेमाल करके कस्टम RUM (Real User Monitoring) सिस्टम बनाया है.
- React डेवलपर टूल.
समस्या का पता लगाने वाले टूल
आईएनपी की परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाने और उन्हें ठीक करने के लिए, इन टूल का इस्तेमाल किया गया.
Google Chrome DevTools
वेब ऐप्लिकेशन में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी से जुड़ी समस्याओं का पता लगाने और उन्हें फिर से बनाने का सबसे अच्छा तरीका है कि Google Chrome DevTools में परफ़ॉर्मेंस टैब का इस्तेमाल किया जाए. परफ़ॉर्मेंस टैब, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक को अपने-आप मेज़र करता है. इससे, लोड होने, इंटरैक्टिविटी, और लेआउट शिफ़्ट की मेट्रिक के बारे में तुरंत सुझाव, शिकायत या राय मिलती है. यह काफ़ी हद तक इस बात से मेल खाता है कि इन मेट्रिक को Google के अन्य टूल में कैसे रिपोर्ट किया जाता है.
आईएनपी से जुड़ी समस्याओं की पहचान करने और उन्हें हल करने के लिए, Fotocasa की टीम आम तौर पर सीपीयू की परफ़ॉर्मेंस को कम करती थी. इससे, कम और मध्यम परफ़ॉर्मेंस वाले डिवाइसों की परफ़ॉर्मेंस का सिम्युलेशन तैयार किया जा सकता था. इससे Fotocasa की टीम को यह देखने में मदद मिली कि पेज, ज़्यादा सीमित शर्तों के तहत कैसा काम करता है. इसके बाद, प्रोफ़ाइलर का इस्तेमाल करके सेशन को रिकॉर्ड किया गया. साथ ही, ट्रेस का बारीकी से विश्लेषण किया गया. इसमें परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाने के लिए, उपयोगकर्ता के इंटरैक्शन पर फ़ोकस किया गया.
बॉटलनैक की पहचान करते समय, INP के उप-भागों और ब्राउज़र के हर उप-भाग में किए गए टास्क की जांच करना खास तौर पर फ़ायदेमंद होता है. उदाहरण के लिए, इस इमेज में देखा जा सकता है कि दस्तावेज़ के मुख्य हिस्से में स्टाइल में हुए बदलावों की वजह से, स्टाइल को दो बार फिर से कैलकुलेट किया गया है. इसलिए, आईएनपी का स्कोर काफ़ी ज़्यादा है.
Fotocasa ने आईएनपी और वेबसाइट की परफ़ॉर्मेंस की अन्य अहम जानकारी वाली मेट्रिक को ट्रैक करने के लिए एक सिस्टम सेट अप किया. इससे यह पक्का किया जा सका कि परफ़ॉर्मेंस से जुड़ी किसी भी समस्या की पहचान तुरंत की जा सके और उसे ठीक किया जा सके. जब कोई मेट्रिक, Google की तय की गई रेंज के आधार पर किसी थ्रेशोल्ड से ज़्यादा हो जाती है, तो एट्रिब्यूशन को लॉग कर दिया जाता है. इससे समस्या का विश्लेषण करके उसे ठीक किया जा सकता है.
उस सिस्टम के लिए, web-vitals लाइब्रेरी का इस्तेमाल किया गया था. इससे असली उपयोगकर्ताओं से इन मेट्रिक को इस तरह से कैप्चर किया गया कि वे Chrome के मेज़रमेंट के तरीके से सटीक तौर पर मेल खाएं. साथ ही, उन्हें Google के अन्य टूल (जैसे कि Chrome उपयोगकर्ता अनुभव रिपोर्ट, PageSpeed Insights, Search Console की स्पीड रिपोर्ट वगैरह) को रिपोर्ट किया जा सके.
डेटा को इकट्ठा और विज़ुअलाइज़ करने के लिए, Fotocasa ने Datadog का इस्तेमाल किया. इससे टीम को डेटा के आधार पर बेहतर फ़ैसले लेने में मदद मिली. साथ ही, उसे एक ही जगह पर पूरी जानकारी मिली और वह ट्रैकिंग को मैनेज कर पाई. कस्टम मेट्रिक की वजह से, लागत कम रहती है. साथ ही, इससे Fotocasa की वेबसाइट पर मौजूद लगभग सभी उपयोगकर्ताओं को बेहतर तरीके से ट्रैक किया जा सकता है.
इस सिस्टम की मदद से, Fotocase की टीम यह तुरंत देख सकती है कि बदलावों से मेट्रिक पर असर पड़ा है या नहीं. साथ ही, यह भी देखा जा सकता है कि कोई ऐसा बदलाव तो नहीं हुआ है जिससे मेट्रिक पर बुरा असर पड़ सकता है. इसके बाद, आईएनपी मेट्रिक को इनपुट में देरी, प्रोसेसिंग में लगने वाला समय, और नतीजे दिखने में देरी जैसे हिस्सों में बांटा जा सकता है. इससे यह पता लगाया जा सकता है कि इंटरैक्शन के किस हिस्से की वजह से, इंटरैक्शन में ज़्यादा समय लग रहा है.
जब Fotocasa को गड़बड़ियों का पता चला, तो उसने तुरंत कार्रवाई की. जैसे, फ़िगर 7 और 8 में दिखाया गया है. साथ ही, उसने OpenSearch का इस्तेमाल किया. यह एक ऐसा टूल है जिससे यह पता लगाने में मदद मिलती है कि बदलाव कहां हो रहा है. web-vitals लाइब्रेरी से मिले डेटा की मदद से, टारगेट (वह DOM एलिमेंट जिसकी वजह से मेट्रिक की वैल्यू बढ़ गई है) की पहचान की गई. इससे टीम को समस्या को ठीक करने पर ज़्यादा ध्यान देने में मदद मिली.
इसके अलावा, अलग-अलग फ़िल्टर तय किए जा सकते हैं. जैसे, पेज टाइप, डिवाइस या लोड होने की स्थिति. इससे अलग-अलग स्थितियों को बेहतर तरीके से समझा जा सकता है. साथ ही, यह भी पता लगाया जा सकता है कि INP पर क्या असर पड़ रहा है.
React डेवलपर टूल
Fotocasa की डीबग करने की क्षमताओं को बेहतर बनाने के लिए, React Developer Tools का इस्तेमाल किया गया. इससे एक ऐसी बेहतरीन सुविधा मिलती है जिसकी मदद से, उन कॉम्पोनेंट को हाइलाइट किया जा सकता है जिन्हें विज़ुअल तौर पर फिर से रेंडर किया गया है.
इस सुविधा को चालू करने के लिए, प्रोफ़ाइलर टैब पर जाएं. इसके बाद, सबसे ऊपर मौजूद बार की दाईं ओर मौजूद कॉगव्हील पर क्लिक करें. सामान्य टैब पर जाएं और कॉम्पोनेंट रेंडर होने पर अपडेट हाइलाइट करें चेकबॉक्स पर सही का निशान लगाएं. इस सुविधा के चालू होने पर, कॉम्पोनेंट को फिर से रेंडर किए जाने पर हाइलाइट किया जाता है. इससे डाइनैमिक विज़ुअल मिलता है.
फिर से रेंडर होने की वजह का पता लगाना
जिस कॉम्पोनेंट को फिर से रेंडर किया गया है उसकी पहचान करने के बाद, अगला सवाल यह है कि "ऐसा क्यों हुआ?" React DevTools, फ़्लेम ग्राफ़ व्यू में मददगार टूलटिप के साथ इसका जवाब देता है.
इस जानकारी को ऐक्सेस करने के लिए, प्रोफ़ाइलर सेशन रिकॉर्ड करें. प्रोफ़ाइलर के आउटपुट का विश्लेषण करके, आपको यह काम की जानकारी मिलेगी:
- सबसे ऊपर दाएं कोने में, React कमिट की संख्या दिखती है.
- फ़्लेम ग्राफ़, कॉम्पोनेंट ट्री को दिखाता है. इसमें ग्रे रंग से उन कॉम्पोनेंट को दिखाया जाता है जो फिर से रेंडर नहीं हुए. हर बार, React कॉम्पोनेंट ट्री में हुए बदलाव को दिखाता है. साथ ही, यह भी दिखाता है कि डीओएम में इससे जुड़ा बदलाव कब किया गया.
- फ़्लेम ग्राफ़ में मौजूद हर कॉम्पोनेंट पर कर्सर घुमाने से, यह रेंडर क्यों हुआ?" सबहेडिंग में, उसके रेंडर होने की वजह दिखेगी.
किसी कॉम्पोनेंट को फिर से रेंडर करने की ये वजहें हो सकती हैं:
- यह पहली बार है, जब कॉम्पोनेंट रेंडर किया गया है
- संदर्भ बदला गया
- हुक बदले गए
- प्रॉप्स बदले गए
- राज्य परिवर्तित
- पैरंट कॉम्पोनेंट रेंडर किया गया
रेंडरिंग में लगने वाला समय पता करना
फ़्लेम ग्राफ़ में मौजूद रंग, अहम जानकारी देते हैं. नीले रंग के अलग-अलग शेड से पता चलता है कि किसी कॉम्पोनेंट को रेंडर होने में, दूसरे कॉम्पोनेंट की तुलना में कम समय लगा. इसके उलट, नारंगी और लाल रंग से पता चलता है कि किसी कॉम्पोनेंट को रेंडर होने में ज़्यादा समय लगा है.
Fotocasa की टीम ने समस्या को कैसे ठीक किया
ग़ैर-ज़रूरी रेंडरिंग हटाएं
जब भी React को नए डेटा के साथ यूज़र इंटरफ़ेस (यूआई) को अपडेट करने की ज़रूरत होती है, तब रेंडरिंग की प्रोसेस फिर से शुरू होती है. आम तौर पर, यह किसी उपयोगकर्ता की कार्रवाई, एपीआई रिस्पॉन्स या अन्य ज़रूरी इवेंट से मिलता है. इसके लिए, यूज़र इंटरफ़ेस (यूआई) को अपडेट करना ज़रूरी होता है. हर बार रेंडर करने पर JavaScript चलती है. इसलिए, एक साथ बहुत ज़्यादा रेंडर करने से, मुख्य थ्रेड ब्लॉक हो सकती है और परफ़ॉर्मेंस से जुड़ी समस्याएं आ सकती हैं. ऐसा खास तौर पर, बड़ी कॉम्पोनेंट ट्री में होता है.
रीरेंडर दो तरह के होते हैं:
- ज़रूरी रिरेंडर: जब किसी कॉम्पोनेंट को अपडेट करने की वाकई ज़रूरत हो, क्योंकि वह नए डेटा का मालिक है या उसका इस्तेमाल करता है.
- ज़रूरी न होने पर बार-बार रेंडर करना: जब कोई कॉम्पोनेंट बिना किसी ज़रूरी बदलाव के अपडेट होता है, तो ऐसा अक्सर स्टेट मैनेजमेंट के ठीक से काम न करने या प्रॉप को गलत तरीके से हैंडल करने की वजह से होता है.
कुछ गैर-ज़रूरी रेंडर से आम तौर पर कोई खास फ़र्क़ नहीं पड़ता, क्योंकि React इतना तेज़ है कि उपयोगकर्ताओं को आम तौर पर इसका पता नहीं चलता. हालांकि, अगर ये बार-बार होते हैं या कॉम्पोनेंट ट्री के किसी बड़े हिस्से में होते हैं, तो इससे उपयोगकर्ता अनुभव खराब हो सकता है. साथ ही, पेज के आईएनपी पर बुरा असर पड़ सकता है.
Fotocasa टीम के साथ ऐसा ही हुआ. उन्हें पता चला कि वेबसाइट पर कई बार गैर-ज़रूरी रेंडरिंग हो रही है. ये दो मुख्य स्थितियों में हुए:
- पेज लोड होने के दौरान: मुख्य थ्रेड पर लंबे समय तक चलने वाले टास्क की संख्या बढ़ गई और पहले इंटरैक्शन में देरी हुई. इससे पेज के आईएनपी पर बुरा असर पड़ा.
- उपयोगकर्ता के इंटरैक्शन के दौरान: ज़्यादातर इंटरैक्शन को प्रोसेस करने में लगने वाला समय बढ़ गया. इससे आईएनपी पर भी बुरा असर पड़ा.
Fotocasa की वेबसाइट पर, कई बार गैर-ज़रूरी रेंडरिंग को ऑप्टिमाइज़ किया गया. सबसे बड़ा ऑप्टिमाइज़ेशन, खोज पेज पर किया गया था. पेज लोड होने पर, तीन बार बिना वजह रेंडर किया गया. इन वीडियो को हटाने के बाद, ये नतीजे मिले:
- लंबे टास्क की संख्या कम होना (नीचे दिया गया डायग्राम देखें)
- टोटल ब्लॉकिंग टाइम कम होना (आंकड़े 14 और 15 की तुलना करें)
स्टेट कोलोकेशन
React स्टेट को गलत तरीके से रखने पर, ऐप्लिकेशन धीमा हो सकता है और यूज़र इंटरफ़ेस (यूआई) काम नहीं कर सकता. किसी कॉम्पोनेंट की स्थिति बदलने पर, उसके चाइल्ड कॉम्पोनेंट डिफ़ॉल्ट रूप से फिर से रेंडर होंगे. ऐसा तब तक होगा, जब तक कि किसी एस्केप हैच (उदाहरण के लिए, मेमो) का इस्तेमाल न किया जाए.
पिछले सेक्शन में बताया गया है कि रेंडरिंग की प्रोसेस को दोबारा शुरू करना हमेशा बुरा नहीं होता. हालांकि, किसी खास स्टेट अपडेट की वजह से पूरे पेज को फिर से रेंडर करने पर, इंटरैक्शन धीमे हो सकते हैं. ऐसा इसलिए होता है, क्योंकि रेंडरिंग के बाद DOM अपडेट होते हैं.
उदाहरण के लिए, खोज वाले पेज पर एक डायलॉग होता है. इसमें किसी बटन पर क्लिक करने पर, सभी फ़िल्टर दिखते हैं.
इस मामले में, डायलॉग के खुले होने की स्थिति को कंट्रोल करने वाली स्थिति को खोज पेज पर रखा गया था. इस स्थिति में बदलाव होने पर, पूरे पेज को फिर से रेंडर किया जा रहा था. इससे आईएनपी खराब हो रहा था. खास तौर पर, धीमे डिवाइसों पर. ऐसा तब देखा गया, जब DevTools में सीपीयू थ्रॉटलिंग का इस्तेमाल किया गया था:
बदलाव को ट्रिगर करने वाले कॉम्पोनेंट के आस-पास की स्थिति को बदलने से, इस समस्या को हल किया जा सकता है. इस मामले में, स्थिति को फ़िल्टर के बटन कॉम्पोनेंट में रखा जा सकता है. इससे स्थिति में बदलाव होने पर, सिर्फ़ बटन को फिर से रेंडर किया जाएगा.
ग़ैर-ज़रूरी स्थितियां हटाएं
स्टेट में, ज़रूरत से ज़्यादा या डुप्लीकेट जानकारी नहीं होनी चाहिए. ऐसा करने से, बिना वजह रेंडरिंग हो सकती है और समस्याएं आ सकती हैं.
उदाहरण के लिए, Fotocasa के फ़िल्टर बार में, एक टेक्स्ट मौजूद है. यह टेक्स्ट, किसी खोज के लिए लागू किए गए फ़िल्टर की संख्या दिखाता है:
लागू किए गए फ़िल्टर की संख्या का हिसाब, ऐप्लिकेशन की स्थिति के हिसाब से लगाया जाता है. हालांकि, इससे न सिर्फ़ पूरे कॉम्पोनेंट को बिना वजह फिर से रेंडर करना पड़ा, बल्कि कुछ मामलों में लेआउट शिफ़्ट भी हुआ. इसकी वजह यह है कि इस कॉम्पोनेंट को सर्वर-साइड पर रेंडर किया जाता है:
const [filtersCount, setFiltersCount] = useState(DEFAULT_COUNTER)
useEffect(() => {
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER
setFiltersCount(counter)
}, [searchParams]);
इस समस्या को हल करने के लिए, वैल्यू को फ़िल्टर ऑब्जेक्ट से लिया गया था. इसके लिए, स्टेट का इस्तेमाल करने के बजाय, एक वैरिएबल का इस्तेमाल किया गया था:
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER;
ज़्यादा समय लेने वाले रेंडर कम करें
जब React ऐप्लिकेशन में कोई इंटरैक्शन होता है, तो आम तौर पर इससे स्थिति में बदलाव होता है. जैसा कि हमने पहले बताया था, किसी कॉम्पोनेंट की स्थिति बदलने पर, उसे और उसके सभी चाइल्ड कॉम्पोनेंट को फिर से रेंडर किया जाएगा.
अगर इनमें से किसी कॉम्पोनेंट के रेंडर फ़ंक्शन में ज़्यादा समय लगता है, तो इससे पेज के आईएनपी पर बुरा असर पड़ेगा. ऐसा इसलिए, क्योंकि शायद एक लंबा टास्क जनरेट होगा और डीओएम को अपडेट होने में ज़्यादा समय लगेगा.
Fotocasa की टीम ने, कॉम्पोनेंट के रेंडर फ़ंक्शन में समय लेने वाली कंप्यूटेशन को कम करने की पूरी कोशिश की. रेंडरिंग की प्रोसेस धीमी होने का पता लगाने में, Chrome DevTools और React Developer Tools काफ़ी मददगार साबित हुए.
कोड को कुछ समय बाद चलाने की सुविधा
कॉम्पोनेंट के रेंडर फ़ंक्शन को ऑप्टिमाइज़ करने के साथ-साथ, अन्य फ़ंक्शन को भी ऑप्टिमाइज़ किया गया है, ताकि लंबे समय तक चलने वाले टास्क को कम से कम किया जा सके. हालांकि, कुछ टास्क को ऑप्टिमाइज़ नहीं किया जा सका, क्योंकि वे तीसरे पक्ष के कोड पर निर्भर थे.
इसका एक उदाहरण, आंकड़ों का विश्लेषण करना था. इस मामले में, यह फ़ैसला लिया गया कि Analytics कोड को तब तक एक्ज़ीक्यूट नहीं किया जाएगा, जब तक उपयोगकर्ता इंटरैक्शन नहीं करता. साथ ही, उपयोगकर्ता के इंटरैक्शन करने पर, DOM अपडेट को प्राथमिकता दी जाएगी. इसके लिए, Fotocasa की टीम ने idlefy नाम की लाइब्रेरी का इस्तेमाल किया. इससे यह भी पक्का किया गया कि ब्राउज़र को तुरंत बंद करने के बाद भी, ऐनलिटिक्स कोड चलता रहे.
परफ़ॉर्मेंस कल्चर
परफ़ॉर्मेंस को बेहतर बनाने के लिए, एक बार काम करने से कुछ नहीं होता. हर सुविधा को प्रोडक्शन के लिए रिलीज़ करते समय, इस पर ध्यान देना ज़रूरी है. टीम के सभी सदस्यों को एक साथ काम करना होगा. ऐसा न करने पर, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक में गिरावट आ सकती है.
इस समस्या को हल करने के लिए, Fotocasa की टीम ने अपनी टीम के साथ जानकारी शेयर की. साथ ही, Fotocasa के Datadog RUM डेटा के आधार पर, परफ़ॉर्मेंस से जुड़ी समस्याओं की पहचान करने के लिए एक फ़्रेमवर्क तैयार किया. इसमें यह भी बताया गया कि समस्याओं को कैसे दोहराया जाए. आरयूएम सिस्टम में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक, खास तौर पर आईएनपी के लिए सूचनाएं सेट अप की गई थीं. इन्हें इस तरह कॉन्फ़िगर किया गया था कि ये सीधे तौर पर Fotocasa की टीम को Slack पर सूचनाएं भेज सकें. इस तरीके से, परफ़ॉर्मेंस को बेहतर बनाए रखने पर ध्यान दिया गया. साथ ही, इससे समस्याओं को रिग्रेशन में बदलने से पहले ही पकड़ने में मदद मिली.
नतीजे
Fotocasa पर INP को बेहतर बनाने के लिए, तकनीकी ऑप्टिमाइज़ेशन और कल्चरल बदलावों को एक साथ लागू करना पड़ा. ज़रूरत न होने पर रेंडरिंग को बंद करके, स्टेट प्लेसमेंट को ऑप्टिमाइज़ करके, महंगी रेंडरिंग को कम करके, और गैर-ज़रूरी कोड को कुछ समय के लिए रोककर, Fotocasa की टीम ने सभी डेस्कटॉप पेजों को "सुधार की ज़रूरत है" से "अच्छा" में बदल दिया. साथ ही, मोबाइल पेजों की परफ़ॉर्मेंस को बेहतर बनाया. इसके लिए, उन्होंने "खराब" और "सुधार की ज़रूरत है" वाले पेजों को "अच्छा" में अपग्रेड किया.
इन बदलावों से, Fotocasa के उपयोगकर्ताओं को बेहतर अनुभव मिला. साथ ही, अन्य पहलों के साथ मिलकर, संपर्क और फ़ोन कॉल वाली लीड जनरेट करने वाले विज्ञापनों में 27% की बढ़ोतरी हुई. इससे कंपनी की मुख्य कारोबारी मेट्रिक को सीधे तौर पर बेहतर बनाने में मदद मिली.
Datadog की मदद से रीयल-टाइम मॉनिटरिंग की जा सकती है. इससे Fotocasa की टीम को INP में हुए सुधारों की पुष्टि करने, गड़बड़ियों का तुरंत पता लगाने, और रिग्रेशन को रोकने में मदद मिली. इन उपलब्धियों के अलावा, Fotocasa ने वेब परफ़ॉर्मेंस को अपनी डेवलपमेंट संस्कृति में भी शामिल किया है. इससे यह पक्का किया जा सका है कि हर रिलीज़ में आईएनपी और वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक को प्राथमिकता दी जाए.