हमने स्लो रिस्पॉन्स को 80% तक कैसे कम किया

Subito इटली का एक प्रमुख मार्केटप्लेस है। हम हर मिनट हज़ारों रिक्वेस्ट हैंडल करते हैं। हमारा एड डिटेल पेज SEO और रेवेन्यू के लिए अत्यंत महत्वपूर्ण है।

हमने इस पेज को Next.js Pages Router से App Router पर माइग्रेट किया। हमने ऐसा करने के लिए प्रोडक्ट के काम को नहीं रोका। हमने छोटे-छोटे चरणों में यह बदलाव किया।

यहाँ बताया गया है कि हमने इसे कैसे किया।

दृष्टिकोण (The Approach)

हमने एक इंक्रीमेंटल (incremental) रणनीति का उपयोग किया। हमने पुराने Pages Router के साथ-साथ App Router ट्री को भी जोड़ा। इससे हमें माइग्रेशन के दौरान नए फीचर्स लॉन्च करने की सुविधा मिली।

हमने डेटा फेचिंग (data fetching) के लिए Server Components का उपयोग किया। इससे डेटा को कई लेयर्स के माध्यम से पास करने की आवश्यकता समाप्त हो गई। हमने एक Data Access Layer भी बनाया। इससे यह सुनिश्चित हुआ कि हम प्रति रिक्वेस्ट केवल एक बार ही डेटा फेच करें।

हमने HTML स्ट्रीमिंग को सक्षम करने के लिए Suspense और use() हुक का उपयोग किया। यह डेटा लोड होने के दौरान एक स्केलेटन स्क्रीन (skeleton screen) दिखाता है। इससे यूजर को पेज तेज़ी से दिखाई देता है।

चुनौतियाँ (The Challenges)

समस्या 1: HTTP 410 Gone जब कोई पेज स्थायी रूप से हटा दिया जाता है, तो सर्च इंजन को 410 स्टेटस की आवश्यकता होती है। App Router में इसे भेजने का कोई इन-बिल्ट तरीका नहीं है। हमने इसे अपने Express सर्वर का उपयोग करके हल किया। सर्वर रिस्पॉन्स को इंटरसेप्ट करता है और स्टेटस कोड को बदल देता है।

समस्या 2: HTML Streaming हमने पाया कि हमारे लोडिंग स्केलेटन दिखाई नहीं दे रहे थे। पेज कुछ सेकंड तक खाली रहता था।

हमने पाया कि Nginx और Akamai हमारे रिस्पॉन्स को बफर (buffer) कर रहे थे। यदि CDN, HTML को बफर करता है, तो स्ट्रीमिंग विफल हो जाती है। हमें Nginx में बफरिंग बंद करनी पड़ी और Akamai में कस्टम सेटिंग्स लागू करनी पड़ीं। एक बार जब हमने इसे ठीक कर लिया, तो कंटेंट यूजर तक बिल्कुल सही तरीके से स्ट्रीम होने लगा।

रोलआउट (The Rollout)

हमने अपने SEO को सुरक्षित रखने के लिए इसे दो चरणों में रोल आउट किया।

चरण 1: हमने ट्रैफिक को App Router पर स्थानांतरित कर दिया लेकिन स्ट्रीमिंग को बंद रखा। हमने इसे एक बार में एक कैटेगरी के हिसाब से किया।

चरण 2: हमने HTML स्ट्रीमिंग को सक्षम किया। हमने पहले छोटी कैटेगरीज़ पर इसका परीक्षण किया। अगली कैटेगरी पर जाने से पहले हमारी SEO टीम ने दो सप्ताह तक रैंकिंग की निगरानी की।

परिणाम (The Results)

परिणाम शानदार रहे। माइग्रेशन से पहले, हमारे 40% तक रिस्पॉन्स स्लो थे। माइग्रेशन के बाद, स्लो रिस्पॉन्स में 80% की कमी आई।

अब अधिकांश पेज 500ms से कम समय में लोड हो जाते हैं।

मुख्य बातें (Takeaways)

Next.js App Router पर माइग्रेट करके हमने धीमी प्रतिक्रियाओं (slow responses) को 80% तक कैसे कम किया

परफॉरमेंस एक फीचर है। Subito में, हमने देखा कि हमारे उपयोगकर्ताओं का एक बड़ा हिस्सा धीमी प्रतिक्रिया समय (slow response times) का अनुभव कर रहा था, विशेष रूप से हमारे p95 और p99 लेटेंसी मेट्रिक्स में।

समस्या: Pages Router की सीमाएं

Pages Router का उपयोग करते समय, हमारी मुख्य समस्या क्लाइंट-साइड डेटा फेचिंग थी।

क्लाइंट-साइड फेचिंग और वॉटरफॉल प्रभाव

हम डेटा फेच करने के लिए useEffect का उपयोग कर रहे थे। इसका मतलब था कि:

  1. ब्राउज़र को पहले HTML डाउनलोड करना पड़ता था।
  2. फिर JavaScript डाउनलोड और निष्पादित (execute) करनी पड़ती थी।
  3. उसके बाद ही डेटा फेचिंग शुरू होती थी।

इससे "वॉटरफॉल" (waterfall) प्रभाव पैदा होता था, जहाँ एक के बाद एक रिक्वेस्ट होती थी, जिससे कुल लोडिंग समय बढ़ जाता था।

समाधान: Next.js App Router का उपयोग

App Router पर माइग्रेट करने से हमें कई महत्वपूर्ण सुधार मिले:

1. React Server Components (RSC)

RSC के साथ, हम डेटा को सर्वर पर ही फेच कर सकते हैं। इससे क्लाइंट को डेटा के लिए इंतज़ार नहीं करना पड़ता और उन्हें पहले से ही तैयार HTML मिलता है।

2. स्ट्रीमिंग और Suspense

हमने Suspense का उपयोग करके स्ट्रीमिंग को लागू किया। अब, हम पूरे पेज के लोड होने का इंतज़ार करने के बजाय, पेज के उन हिस्सों को तुरंत दिखा सकते हैं जो तैयार हैं।

3. कम JavaScript बंडल साइज

चूंकि डेटा फेचिंग सर्वर पर हो रही है, इसलिए क्लाइंट को कम JavaScript भेजनी पड़ती है, जिससे पेज जल्दी लोड होता है।

परिणाम

इस माइग्रेशन के बाद, हमने अपने स्लो रिस्पॉन्स (slow responses) में 80% की कमी देखी।