Frontend Interview: CSR, SSR, SSG और ISR में से कैसे चुनें?

प्रॉम्प्ट और लागू होने वाले परिदृश्य

एक Next.js 16 कॉमर्स प्लेटफ़ॉर्म में चार पेज श्रेणियाँ (families) हैं:

• /guides/[slug]: 20,000 सार्वजनिक गाइड, जिन्हें साप्ताहिक रूप से संपादित किया जाता है, जिनका मुख्य टेक्स्ट सर्च इंजनों द्वारा विश्वसनीय रूप से खोजने योग्य (discoverable) होना चाहिए;
• /products/[id]: दस लाख सार्वजनिक उत्पाद पेज जिनके विवरण और छवियां पाँच मिनट तक पुरानी हो सकती हैं, जबकि चेकआउट से पहले कीमत और इन्वेंट्री की लाइव पुष्टि होनी चाहिए;
• /search?q=: ऐसे परिणाम जो क्वेरी, फ़िल्टर और वर्तमान कैटलॉग स्थिति के अनुसार बदलते हैं; पहला दृश्य साझा करने योग्य (shareable) होना चाहिए, लेकिन प्रत्येक क्वेरी संयोजन को इंडेक्स करने की आवश्यकता नहीं है;
• /account/orders: निजी पेज जो साइन-इन किए गए उपयोगकर्ता के अनुसार बदलते हैं और जिन्हें न तो साझा कैश में जाना चाहिए और न ही सर्च इंडेक्स में।

टीम सार्वजनिक पेजों पर खोजे जाने की क्षमता (discoverability) या इंटरैक्टिव पेजों पर रिस्पॉन्सिवनेस से समझौता किए बिना ओरिजिन रेंडरिंग को कम करना चाहती है। उम्मीदवार को प्रत्येक रूट फ़ैमिली के लिए एक प्राथमिक रेंडरिंग रणनीति चुननी होगी, फिर यह बताना होगा कि कौन से क्षेत्र (regions) एक अलग रणनीति को मिला सकते हैं। उत्तर में फ्रेशनेस सीमा, इनवैलिडेशन ट्रिगर, फेलियर आउटपुट और प्रोडक्शन प्रमाण को परिभाषित किया जाना चाहिए।

2026 की एक सार्वजनिक फ़्रंटएंड इंटरव्यू गाइड स्पष्ट रूप से किसी दिए गए पेज के लिए रेंडरिंग रणनीति चुनने और ISR तथा SSR के बीच निर्णय लेने को सूचीबद्ध करती है। एक अलग फ़्रंटएंड प्रश्न बैंक में CSR, SSR, SSG और ISR की समर्पित तुलना है। कई खोज परिणाम केवल चार पंक्तियों वाली फायदे-और-नुकसान (pros-and-cons) तालिका पर ही समाप्त हो जाते हैं। बहुत कम ही इनवैलिडेशन, महत्वपूर्ण फ़ील्ड्स के लाइव सत्यापन, बाहरी CDN और फेलियर सेमेंटिक्स को एक साथ जोड़ते हैं। यह प्रश्न उस प्रोडक्शन निर्णय स्तर को जोड़ता है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

पहला, क्या उम्मीदवार कोई संक्षिप्त नाम (acronym) चुनने से पहले पेज की आवश्यकताओं को परिभाषित करता है? रेंडरिंग का स्थान लक्ष्य नहीं है। सार्वजनिक इंडेक्सिबिलिटी, प्रारंभिक सामग्री, फ्रेशनेस, पर्सनलाइज़ेशन, ट्रैफ़िक, पेज काउंट, इंटरैक्शन लागत और फेलियर व्यवहार इसके इनपुट हैं। "SEO के लिए SSR अच्छा है" किसी ऑर्डर पेज या दस लाख पेजों वाले कैटलॉग का फैसला नहीं कर सकता।

दूसरा, क्या वे समझते हैं कि प्रत्येक रणनीति कहाँ लागत डालती है?

तीसरा, क्या वे एक हाइब्रिड मॉडल की पहचान कर सकते हैं? एक उत्पाद पेज इंडेक्स करने योग्य विवरण के लिए ISR का उपयोग कर सकता है, क्लाइंट पर वर्तमान डिलीवरी विकल्पों को फ़ेच कर सकता है, और चेकआउट सेवा में कीमत और इन्वेंट्री को फिर से सत्यापित कर सकता है। ISR चुनने से हर फ़ील्ड को पुराना सर्व करना सुरक्षित नहीं हो जाता। SSR चुनने से क्लाइंट JavaScript या हाइड्रेशन समाप्त नहीं हो जाता।

चौथा, क्या वे इस विकल्प को एक परीक्षण योग्य अनुबंध (testable contract) में बदल सकते हैं? एक मजबूत उत्तर यह बताता है कि सामग्री कितनी पुरानी हो सकती है, इसे कौन इनवैलिडेट करता है, पुनरुत्पादन विफलता क्या दिखाती है, क्या कैश कुंजियों में उपयोगकर्ता या क्षेत्र शामिल हैं, और एक वास्तविक ब्राउज़र कितना JavaScript डाउनलोड करता है। यह बिल्ड, रनटाइम, कैश और व्यावसायिक-शुद्धता मेट्रिक्स प्रदान करता है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या पेज सार्वजनिक है और इंडेक्स करने के लिए अभिप्रेत है? सार्वजनिक बॉडी टेक्स्ट, शीर्षक, कैनोनिकल और स्थिति अधिमानतः प्रारंभिक प्रतिक्रिया में मौजूद होने चाहिए। निजी ऑर्डरों के लिए प्रमाणीकरण, कोई साझा कैशिंग नहीं, और एक स्पष्ट noindex नीति की आवश्यकता होती है।
• "रीयल टाइम" कितना तेज़ है? विवरण पाँच मिनट पुराना हो सकता है, जबकि कीमत और इन्वेंट्री भुगतान के वादे को प्रभावित करते हैं। वे फ़ील्ड समान कैश SLA इनहेरिट नहीं कर सकते।
• कौन से आयाम (dimensions) सामग्री को बदलते हैं? लोकेल, क्षेत्र, मुद्रा, प्रमाणीकरण और प्रयोग समूह कैश कुंजी को बदल सकते हैं। एक अनुपलब्ध आयाम गलत या निजी डेटा सर्व कर सकता है; बहुत अधिक आयाम हिट दर को नष्ट कर देते हैं।
• पेज काउंट और अपडेट वितरण क्या है? प्रत्येक रिलीज़ पर दस लाख URL बनाना आकर्षक नहीं है। यदि 95% लॉन्ग-टेल पेज हैं, तो लोकप्रिय पाथ को पहले से बनाएँ (prebuild) और बाकी को पहले एक्सेस पर जनरेट करें।
• क्या प्रकाशन घटनाएँ (events) विश्वसनीय हैं? क्या CMS या कैटलॉग किसी एंटिटी ID को उत्सर्जित कर सकता है? यदि घटनाएँ खो सकती हैं, तो क्षतिपूर्ति के रूप में समय-आधारित समाप्ति, समाधान (reconciliation), या मैन्युअल इनवैलिडेशन जोड़ें।
• कैशिंग कैसे तैनात की जाती है? एक प्रोसेस, एकाधिक कंटेनर, एक प्रबंधित प्लेटफ़ॉर्म और एक बाहरी CDN इनवैलिडेशन को अलग-अलग तरीके से प्रसारित करते हैं। Next.js सर्वर कैश को पर्ज करने पर किसी अन्य CDN की प्रति सुरक्षित रह सकती है।
• विफलता पर, क्या गलत सामग्री की तुलना में पुरानी सामग्री अधिक सुरक्षित है? अंतिम सफल गाइड को सर्व करना आमतौर पर उचित होता है। कीमत, इन्वेंट्री और ऑर्डर की स्थिति की पुष्टि किसी आधिकारिक सेवा द्वारा की जानी चाहिए।
• सफलता के मानक (gates) क्या हैं? इंडेक्स करने योग्य-सामग्री की पूर्णता, TTFB/LCP/INP, हिट दर, पुनरुत्पादन विलंब, सामग्री की आयु, ओरिजिन रेंडर QPS, बिल्ड अवधि, त्रुटि दर और चेकआउट संघर्ष दर को परिभाषित करें।

30-सेकंड उत्तर ढाँचा

"मैं रूट्स को पब्लिसिटी, प्रति-अनुरोध भिन्नता, फ्रेशनेस और पेज काउंट के आधार पर विभाजित करता हूँ। गाइड मुख्य रूप से SSG हैं और प्रकाशन पर पाथ द्वारा इनवैलिडेट किए जाते हैं। उत्पाद विवरण कम लागत वाले, इंडेक्स करने योग्य बॉडी के लिए ISR का उपयोग करते हैं, जिसमें कैटलॉग इवेंट्स के साथ पाँच मिनट का समय फ़ॉलबैक होता है; कीमत और इन्वेंट्री क्लाइंट में रीफ़्रेश होती हैं और चेकआउट द्वारा फिर से पुष्टि की जाती हैं। खोज प्रति क्वेरी SSR है, उपयोगकर्ता आयामों वाली प्रतिक्रियाओं को साझा किए बिना। निजी ऑर्डर एक प्रमाणित सर्वर शेल और CSR डेटा अपडेट का उपयोग करते हैं। मैं प्रोडक्शन बिल्ड में कैश व्यवहार को सत्यापित करता हूँ और सामग्री की आयु, हिट दर, TTFB, LCP, JavaScript आकार, पुनरुत्पादन विफलता और व्यावसायिक संघर्षों की निगरानी करता हूँ, बिना किसी एक Lighthouse स्कोर पर भरोसा किए।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: प्रति रूट प्राथमिक रणनीति चुनने के लिए एक निर्णय मैट्रिक्स का उपयोग करें

फ़्रेमवर्क API से शुरू करने के बजाय प्रत्येक पेज फ़ैमिली को एक ही मैट्रिक्स के माध्यम से रखें:

"SSG प्लस प्रकाशन इनवैलिडेशन" रनटाइम पर वृद्धिशील पुनरुत्पादन का उपयोग करता है, हालांकि इसका प्राथमिक सामग्री मॉडल एक प्री-रेंडर किया गया स्थिर पेज बना रहता है। यह 20,000 गाइडों के प्रत्येक अनुरोध के लिए SSR की तुलना में सस्ता है और टाइपो के लिए पूरी साइट को फिर से बनाने की तुलना में अधिक लक्षित है। सभी गाइड शुरू में बनाए जा सकते हैं; यदि सेट बढ़ता है, तो लोकप्रिय पाथ को पहले से बनाएँ और शेष को पहले अनुरोध पर जनरेट करें।

ISR उत्पाद विवरण के लिए उपयुक्त है क्योंकि बॉडी सार्वजनिक है, बार-बार देखी जाती है, और इसे संक्षेप में पुराना होने की अनुमति है। पाँच मिनट की पुनर्वैधीकरण सेटिंग हर स्थिति में पाँच मिनट की कठिन अधिकतम सीमा नहीं है। अंतराल के बाद पहला अनुरोध अभी भी पुराना HTML प्राप्त कर सकता है जबकि पृष्ठभूमि में पुनर्जनन शुरू होता है। कम ट्रैफ़िक वाला पेज बाद में ट्रिगर हो सकता है, और एक विफल पुनर्जनन पुराने संस्करण के जीवनकाल को बढ़ाता है। यदि प्रकाशन तुरंत दिखाई देना चाहिए, तो राइट सफल होने के बाद उत्पाद ID द्वारा इनवैलिडेट करें और समय विंडो को केवल क्षतिपूर्ति के रूप में रखें।

सर्च क्वेरी स्पेस पहले से बनाने के लिए बहुत बड़ा है। SSR पहली प्रतिक्रिया में क्वेरी-संगत सामग्री और वास्तविक स्थिति डाल सकता है। कैश कुंजियों में प्रत्येक सार्वजनिक पैरामीटर शामिल होना चाहिए जो परिणामों को बदलता है। प्रमाणीकरण या वैयक्तिकृत मूल्य से जुड़ी प्रतिक्रियाएं निजी या गैर-कैश की जानी चाहिए। क्लाइंट पहले दृश्य के बाद फ़िल्टर, पेजिनेशन और इनपुट को संभालता है।

ऑर्डर पेज को सार्वजनिक इंडेक्स करने योग्य HTML से कोई लाभ नहीं मिलता है। सर्वर एक प्रमाणित शेल स्थापित कर सकता है, जबकि CSR एक उपयोगकर्ता API से सूची और लाइव स्थिति लोड करता है। उस प्रतिक्रिया को साझा कैश में प्रवेश नहीं करना चाहिए। CSR एक रेंडरिंग विकल्प है; प्रमाणीकरण और प्राधिकरण अभी भी सर्वर के अंतर्गत आते हैं।

चरण 2: ISR को फ्रेशनेस और इनवैलिडेशन अनुबंध के रूप में व्यक्त करें

उत्पाद रूट को दो अनुबंधों की आवश्यकता होती है:

Cacheable body: name, description, images, category
  Event invalidation: after product:{id} updates successfully
  Time fallback: 300 seconds
  Failure semantics: serve the last successful version and alert

Critical live fields: price, inventory, delivery eligibility
  Page display: refresh from the authority and show update time
  Checkout submission: recompute on the server and confirm changes

Next.js ISR गाइड में कहा गया है कि अंतराल के बाद पहला अनुरोध पुरानी सामग्री प्राप्त कर सकता है जबकि बैकग्राउंड में पुनर्जनन चलता है। बाद के अनुरोध सफलता के बाद नया संस्करण प्राप्त करते हैं। यदि पुनर्जनन विफल हो जाता है, तो अंतिम सफल संस्करण कैश्ड रहता है और दूसरा अनुरोध पुनः प्रयास करता है। सामग्री की आयु की निगरानी करें; एक कॉन्फ़िगरेशन मान इस बात का प्रमाण नहीं है कि व्यावसायिक SLA पूरा हो गया है।

Next.js 16 में, revalidateTag(tag, "max") stale-while-revalidate का उपयोग करता है और लेखों, कैटलॉग या उत्पाद बॉडी के लिए उपयुक्त है जो थोड़ी देरी की अनुमति देते हैं। जब किसी उपयोगकर्ता को तुरंत अपना राइट पढ़ना चाहिए, तो सर्वर एक्शन में updateTag रीड-योर-राइट्स सेमेंटिक्स प्रदान करता है। वे परस्पर विनिमेय "कैश साफ़ करें" बटन नहीं हैं। इवेंट स्रोत, अनुमत पुरानापन, और कॉल साइट यह निर्धारित करते हैं कि कौन सा ऑपरेशन उपयुक्त है।

प्रसार श्रृंखला (propagation chain) को भी आरेखित करें। ब्राउज़र, CDN, Next.js रूट कैश, डेटा कैश और अपस्ट्रीम सेवा प्रत्येक का एक TTL हो सकता है। आधिकारिक CDN गाइड चेतावनी देता है कि Next.js में पाथ या टैग इनवैलिडेशन अलग से कैश्ड CDN प्रति को स्वचालित रूप से पर्ज नहीं करता है। यदि कोई बाहरी CDN जोड़ा जाता है, तो मिलान करने वाले HTML और डेटा वेरिएंट को भी पर्ज करें, या इसके TTL को समान फ्रेशनेस अनुबंध को पूरा करने दें। मल्टी-इंस्टेंस सेल्फ-होस्टिंग को साझा कैश या सिंक्रोनाइज़्ड टैग स्थिति की भी आवश्यकता होती है ताकि एक इंस्टेंस पुराना न रहे।

चरण 3: SEO, इंटरैक्शन और विफलता सीमाओं को अलग-अलग संभालें

Google JavaScript निष्पादित कर सकता है और रेंडर किए गए HTML को इंडेक्स कर सकता है, लेकिन रेंडरिंग एक कतार (queue) में प्रवेश करती है, और अन्य बॉट JavaScript को निष्पादित नहीं कर सकते हैं। सार्वजनिक गाइड और उत्पाद बॉडी को प्रारंभिक HTML में दृश्यमान टेक्स्ट, शीर्षक, कैनोनिकल, संरचित डेटा और सही स्थिति डालनी चाहिए। एक खाली 200 शेल न लौटाएं और क्लाइंट को किसी अनुपलब्ध उत्पाद को "not found" में बदलने न दें। सर्वर या स्थिर-उत्पादन पाथ को वास्तविक 404 का उत्पादन करना चाहिए।

प्री-रेंडरिंग स्वचालित रूप से किसी पेज को तेज़ या इंटरैक्टिव नहीं बनाती है। बहुत अधिक क्लाइंट घटकों वाला SSR/SSG/ISR पेज अभी भी JavaScript डाउनलोड, पार्स और हाइड्रेशन लागत का भुगतान करता है। निकटवर्ती डेटा के साथ अच्छी तरह से विभाजित CSR साइन-इन नेविगेशन पर अच्छा प्रदर्शन कर सकता है। TTFB, LCP, INP, लंबे कार्यों, डाउनलोड और निष्पादित JavaScript, और दृश्यमान से इंटरैक्टिव तक के समय को मापें।

डेटा जोखिम द्वारा विफलता व्यवहार को वर्गीकृत करें:

• गाइड या उत्पाद-बॉडी पुनर्जनन विफल होता है: अंतिम सफल संस्करण सर्व करें, इसके अपडेट समय को प्रदर्शित करें, और आयु पर अलर्ट करें।
• खोज अपस्ट्रीम टाइम आउट: एक पुनः प्रयास करने योग्य विफलता या स्पष्ट रूप से अनुमत लघु कैश दिखाएं, न कि कोई मनगढ़ंत खाली परिणाम।
• मूल्य या इन्वेंट्री API विफल: किसी पुराने मूल्य की पुष्टि न करें; चेकआउट से पहले पुनः प्रयास की आवश्यकता होती है।
• ऑर्डर API विफल: पहले से लोड किए गए UI को बनाए रखें और पुनः प्रयास की पेशकश करें; साझा कैश के माध्यम से कभी भी उपयोगकर्ताओं के बीच फ़ॉलबैक न करें।
• इनवैलिडेशन घटनाओं में देरी: एंटिटी संस्करणों का मिलान करें, प्राधिकरण से पीछे छूटे पेजों को खोजें, और क्षतिपूर्ति इनवैलिडेशन जारी करें।

चरण 4: प्रोडक्शन बिल्ड और व्यावसायिक मेट्रिक्स के साथ सत्यापित करें

डेवलपमेंट मोड स्थिर-उत्पादन और ISR व्यवहार को साबित नहीं कर सकता है। सभी चार रूट श्रेणियों को सत्यापित करने से पहले प्रोडक्शन के लिए बिल्ड करें और प्रोडक्शन सर्वर चलाएं। कम से कम इन परीक्षणों को शामिल करें:

1. बिल्ड आउटपुट का निरीक्षण करें और पुष्टि करें कि प्रत्येक रूट इच्छानुसार स्थिर, ऑन-डिमांड या डायनामिक है, न कि अनकैश किए गए एक रीड के कारण गलती से SSR बन गया है।
2. हिट साबित करने के लिए एक उत्पाद का बार-बार अनुरोध करें; फिर इसे अपडेट करें और इवेंट, इनवैलिडेशन और प्रथम-नए-HTML समय को रिकॉर्ड करें।
3. पुनर्जनन निर्भरता को विफल करें, साबित करें कि अंतिम सफल बॉडी बनी हुई है और त्रुटि दर्ज की गई है, फिर पुनर्प्राप्त करें।
4. पूर्ण कुंजियों और निजी-प्रतिक्रिया अलगाव को साबित करने के लिए विभिन्न लोकेल, क्षेत्रों, मुद्राओं और प्रमाणीकरण स्थितियों का अनुरोध करें।
5. बॉडी, मेटाडेटा, कैनोनिकल और 404 को सत्यापित करने के लिए सीधे प्रारंभिक HTML फ़ेच करें, फिर हाइड्रेशन के लिए एक वास्तविक ब्राउज़र का उपयोग करें।
6. एक बाहरी CDN और एकाधिक इंस्टेंसेस को मॉडल करें; साबित करें कि इनवैलिडेशन हर परत और इंस्टेंस तक पहुँचता है।
7. वास्तविक पेज वितरण के साथ, बिल्ड समय, ओरिजिन रेंडर QPS, हिट दर, TTFB, LCP, INP और JS लागत को मापें।
8. चेकआउट प्राधिकारी के साथ प्रदर्शित मूल्यों की तुलना करें और मूल्य/इन्वेंट्री संघर्षों पर नज़र रखें, ताकि अनुकूलन लेनदेन की शुद्धता को न बदल सके।

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

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं एप्लिकेशन के लिए एक संक्षिप्त नाम नहीं चुनूँगा। गाइड सार्वजनिक, एकसमान और विरल रूप से संपादित हैं, इसलिए मैं स्थिर HTML बनाता हूँ और सफल CMS प्रकाशन के बाद पाथ को इनवैलिडेट करता हूँ। प्रारंभिक टेक्स्ट इंडेक्स करने योग्य रहता है और लगभग हर अनुरोध स्थिर कैशिंग का उपयोग करता है। दस लाख उत्पाद URL हैं, इसलिए मैं लोकप्रिय उत्पादों को पहले से बनाता हूँ और बाकी को पहले एक्सेस पर जनरेट करता हूँ। उत्पाद बॉडी ISR का उपयोग करती है, जिसे उत्पाद ID द्वारा इनवैलिडेट किया जाता है, जिसमें खोई हुई घटना की क्षतिपूर्ति के रूप में केवल 300 सेकंड होते हैं। समाप्ति के बाद पहला अनुरोध अभी भी पुरानी सामग्री प्राप्त कर सकता है और पृष्ठभूमि निर्माण शुरू कर सकता है, इसलिए मैं यह वादा करने के बजाय कि 300 का अर्थ एक कठिन अधिकतम है, एंटिटी अपडेट समय और कैश जनरेशन समय के बीच के अंतर की निगरानी करता हूँ।"

"मूल्य, इन्वेंट्री और डिलीवरी पात्रता बॉडी की पुरानी विंडो को इनहेरिट नहीं करते हैं। ब्राउज़र उन्हें प्राधिकारी से रीफ़्रेश करता है, और चेकआउट उन्हें सर्वर पर फिर से गणना करता है और यदि कीमत बदल गई है तो पुष्टि मांगता है। खोज में बहुत सारे संयोजन होते हैं और प्रति क्वेरी परिवर्तन होते हैं, इसलिए इसका पहला दृश्य SSR है और क्लाइंट बाद के फ़िल्टर का स्वामी है। प्रमाणीकरण या वैयक्तिकृत शर्तों वाली प्रतिक्रियाएं कभी भी साझा कैश में प्रवेश नहीं करती हैं। ऑर्डर सर्वर-साइड उपयोगकर्ता प्राधिकरण और noindex के साथ एक प्रमाणित शेल और CSR डेटा का उपयोग करते हैं।"

"मैं एक प्रोडक्शन बिल्ड के साथ वास्तविक रूट मोड को सत्यापित करता हूँ, फिर हिट, इवेंट इनवैलिडेशन, 300-सेकंड फ़ॉलबैक, पुनर्जनन विफलता और रिकवरी का परीक्षण करता हूँ। एक बाहरी CDN को Next.js के साथ पर्ज होना चाहिए, और कई इंस्टेंसेस को सिंक्रोनाइज़्ड इनवैलिडेशन की आवश्यकता होती है। मैं बॉडी, कैनोनिकल और स्थिति के लिए प्रारंभिक सार्वजनिक HTML का निरीक्षण करता हूँ, फिर वास्तविक ब्राउज़र में TTFB, LCP, INP और JavaScript लागत को मापता हूँ। अंत में, मैं प्रदर्शित और चेकआउट कीमतों की तुलना करता हूँ। लेनदेन की शुद्धता में गिरावट के दौरान पासिंग प्रदर्शन अभी भी विफलता है।"

सामान्य गलतियाँ और सुधार

• एप्लिकेशन के लिए एक रणनीति चुनें → सार्वजनिक, खोज और निजी पेजों की अलग-अलग आवश्यकताएं होती हैं → प्रति रूट और कभी-कभी प्रति डेटा क्षेत्र तय करें।
• SSR को SEO गारंटी के रूप में मानें → मेटाडेटा, स्थिति, कैनोनिकल और क्रॉल करने योग्य लिंक अभी भी गलत हो सकते हैं → प्रारंभिक HTML और क्रॉलर आउटपुट का निरीक्षण करें।
• कहें कि CSR खोज के लिए पूरी तरह से अदृश्य है → Google कतारबद्धता और भिन्न बॉट क्षमताओं के साथ JavaScript को रेंडर कर सकता है → प्रमुख सार्वजनिक सामग्री को प्री-रेंडर करें और सीमा का सटीक वर्णन करें।
• revalidate=300 को एक कठिन पाँच मिनट के SLA के रूप में मानें → कम ट्रैफ़िक, बैकग्राउंड कार्य और विफलता पुरानेपन को बढ़ाते हैं → इवेंट इनवैलिडेशन, आयु निगरानी और एक समय फ़ॉलबैक को संयोजित करें।
• पूरे पेज को एक फ्रेशनेस नियम दें → विवरण पुरानेपन को सहन करता है; कीमत और इन्वेंट्री का इससे वादा नहीं किया जा सकता → डेटा को जोखिम के आधार पर विभाजित करें और लेनदेन सीमा पर पुनः जाँच करें।
• केवल Next.js को पर्ज करें → एक बाहरी CDN या अन्य इंस्टेंस एक प्रति बनाए रख सकता है → प्रत्येक कैश को मैप करें और प्रसार का परीक्षण करें।
• मान लें कि प्री-रेंडर का मतलब तेज़ है → अत्यधिक JavaScript, हाइड्रेशन और धीमे अपस्ट्रीम अभी भी नुकसान पहुंचाते हैं → नेटवर्क, मुख्य थ्रेड, Web Vitals और सर्वर मेट्रिक्स को मापें।
• केवल डेवलपमेंट में ISR का परीक्षण करें → डेवलपमेंट व्यवहार प्रोडक्शन कैशिंग का प्रतिनिधित्व नहीं करता है → हिट, इनवैलिडेशन और विफलता परीक्षणों के लिए प्रोडक्शन बिल्ड और सर्वर का उपयोग करें।
• हर त्रुटि को छिपाने के लिए पुराने पेजों का उपयोग करें → खाली खोज, बासी कीमत या क्रॉस-यूज़र ऑर्डर गलत निर्णय या लीक का कारण बनते हैं → डेटा जोखिम द्वारा stale-if-error को परिभाषित करें।

अनुवर्ती प्रश्न

यदि उत्पाद परिवर्तन दस सेकंड के भीतर विश्व स्तर पर दिखाई देने चाहिए, तो क्या ISR बना रह सकता है?

हाँ, लेकिन दस सेकंड को एंड-टू-एंड इनवैलिडेशन SLO बनना चाहिए। कैटलॉग लेनदेन कमिट होने के बाद, मज़बूती से एक वर्शनयुक्त इवेंट उत्सर्जित करें, सभी Next.js इंस्टेंसेस में टैग इनवैलिडेशन को सिंक्रोनाइज़ करें, बाहरी CDN को पर्ज करें, और कई क्षेत्रों से नए संस्करण की जांच करें। समय पुनर्वैधीकरण क्षतिपूर्ति है, दस सेकंड की गारंटी नहीं। यदि पर्ज श्रृंखला लक्ष्य को पूरा नहीं कर सकती है, तो उस फ़ील्ड को डायनामिक रूप से पढ़ें या एक छोटे कैश पाथ का उपयोग करें जिसकी सीमा प्रदर्शित की जा सके।

दस लाख उत्पादों को स्थिर रूप से जनरेट करना एक समस्या क्यों हो सकती है?

यह बिल्ड समय, आर्टिफैक्ट्स और रिलीज़ जोखिम को पेज काउंट से जोड़ता है, हालांकि कई लॉन्ग-टेल पेजों को कभी नहीं पढ़ा जा सकता है। उच्च-ट्रैफ़िक वाले उत्पादों को पहले से बनाएँ और बाकी को पहले अनुरोध पर जनरेट करें। पुनर्जनन समवर्तीता (concurrency) को सीमित करें, किसी हॉट इवेंट को पुनर्जनन का तूफ़ान (storm) बनने से रोकें, और अनुपलब्ध उत्पादों के लिए विश्वसनीय 404 व्यवहार बनाए रखें।

क्या SSR प्रतिक्रिया को CDN में कैश किया जा सकता है?

साझा करने की क्षमता इस बात पर निर्भर करती है कि प्रतिक्रिया प्रत्येक कैश-कुंजी आयाम में समान है या नहीं, न कि SSR नाम पर। एक पूर्ण कुंजी और अनुमत लघु पुरानेपन वाली एक सार्वजनिक खोज प्रतिक्रिया को सावधानीपूर्वक कैश किया जा सकता है। कुकीज़, उपयोगकर्ता अनुमतियाँ, वैयक्तिकृत मूल्य निर्धारण, या प्रयोग सदस्यता से जुड़ी प्रतिक्रिया निजी या अनकैश होनी चाहिए। लॉगआउट के बाद Vary, कुंजी निर्माण, और क्रॉस-यूज़र अलगाव का परीक्षण करें।

क्या RSC, स्ट्रीमिंग SSR और PPR चार-तरफ़ा मॉडल को अमान्य करते हैं?

वे स्थिर और गतिशील कार्य को एक रूट के भीतर अधिक सूक्ष्मता से संयोजित करने की अनुमति देते हैं, लेकिन निर्णय इनपुट को नहीं हटाते हैं। आपको अभी भी यह बताना होगा कि काम कहाँ चलता है, प्रारंभिक HTML में क्या शामिल है, डेटा कितने समय तक कैश्ड रहता है, क्लाइंट को कितना JavaScript प्राप्त होता है, और एक गतिशील क्षेत्र कैसे विफल होता है। एक साक्षात्कार में, CSR/SSR/SSG/ISR डिलीवरी और फ्रेशनेस स्थापित करें, फिर बताएं कि RSC, स्ट्रीमिंग या आंशिक प्री-रेंडरिंग किसी विशिष्ट क्षेत्र को कैसे बेहतर बनाती है।

आप इनवैलिडेशन तूफ़ान (storm) को कैसे रोकते हैं?

एंटिटी द्वारा बार-बार होने वाली घटनाओं को संयोजित (coalesce) करें, अप्रचलित संस्करणों को अस्वीकार करें, सीमित पुनर्जनन समवर्तीता और जिटर जोड़ें, और प्रति कैश कुंजी एक जनरेटर की अनुमति दें। कतार की गहराई, निर्माण अवधि, विफलताओं और सामग्री की आयु की निगरानी करें। यदि बैकलॉग बढ़ता है, तो कीमत और इन्वेंट्री के लिए आधिकारिक गतिशील रीड्स को बनाए रखें जबकि उत्पाद बॉडी अपने अंतिम सफल संस्करण को सर्व करना जारी रखे।