Next.js 14 च्या Server Components मुळे बंडलचा आकार (bundle size) अंदाजे ६०% ने कमी होतो आणि सामान्य ब्लॉग पेजवर 'first-paint' वेळ २०० ms च्या खाली येतो, याचा अर्थ वापरकर्त्यांना मजकूर वेगाने दिसतो आणि सर्च इंजिन्सना पूर्णपणे रेंडर झालेले HTML मिळते.

हे नवीन रिलीज Next.js सह तयार केलेल्या React ॲप्ससाठी डीफॉल्ट एक्झिक्यूशन मॉडेलमध्ये मोठा बदल घडवून आणते. पूर्वी प्रत्येक कंपोनंट ब्राउझरकडे पाठवला जात असे, परंतु आता डेव्हलपर्स UI चे काही भाग “Server Components” म्हणून मार्क करू शकतात जेणेकरून ते फक्त बॅकएंडवर चालतील. त्या कंपोनंट्सचा कोड क्लायंटपर्यंत कधीच पोहोचत नाही, ज्यामुळे ब्राउझरकडे फक्त इंटरअॅक्टिव्हिटीसाठी आवश्यक असलेले भाग उरतात.

हा बदल का महत्त्वाचा आहे

React डेव्हलपर्स दीर्घकाळापासून तीन एकमेकांशी संबंधित समस्यांशी झुंजत आहेत: नेटवर्क रिक्वेस्टचा मोठा ओघ, फुगलेले (bloated) JavaScript बंडल्स आणि संथ पेज लोडिंग. या समस्यांमुळे SEO वरही परिणाम होतो कारण क्रॉलर्सना पाठवलेले सुरुवातीचे HTML अनेकदा रिकामे असते, ज्यामुळे सर्च बॉट्सना क्लायंट-साइड हायड्रेशनसाठी (client-side hydration) वाट पाहावी लागते. Next.js 14 डेटा-हेवी काम पूर्णपणे क्लायंटच्या बाहेर हलवून या मूळ कारणावर उपाय करते.

Server Components जुन्या मॉडेलपेक्षा कसे वेगळे आहेत

  • Server Components – सर्व्हरवर एक्झिक्युट होतात, डेटा मिळवतात (fetch), डेटाबेसशी संवाद साधतात आणि साधे HTML आउटपुट देतात. त्यांचा JavaScript कधीही नेटवर्कवरून प्रवास करत नाही.
  • Client Components – ब्राउझरमध्ये राहतात आणि बटण क्लिक, फॉर्म सबमिशन किंवा React state किंवा effects वापरणाऱ्या कोणत्याही कंपोनंटसारख्या UI इंटरअॅक्शन्स हाताळतात.

हे फ्रेमवर्क एका साध्या निर्देशकाच्या (directive) मदतीने हे विभाजन लागू करते. फाईलच्या वरच्या बाजूला use client जोडल्यास Next.js ला तो कंपोनंट फक्त क्लायंट-साइड मानण्यास सांगितले जाते. त्या मार्करशिवाय असलेले सर्व काही डीफॉल्टनुसार Server Component असते.

वास्तववादी आकडेवारी

एका वैयक्तिक ब्लॉग पेजवरील छोट्या प्रयोगातून याचा परिणाम दिसून येतो. 'fetch' प्रक्रिया Server Component मध्ये हलवल्यानंतर आणि सर्व्हरला ती यादी स्टॅटिक HTML म्हणून रेंडर करू दिल्यानंतर, JavaScript बंडल ६०% ने कमी झाले आणि पेज २०० ms च्या आत रेंडर झाले.

एक व्यावहारिक लेअरिंग पॅटर्न

  1. Bottom layer (Server) – APIs किंवा डेटाबेसमधून डेटा मिळवा. कोणताही खाजगी लॉजिक (private logic) येथे ठेवा; तो सर्व्हरच्या बाहेर कधीही जात नाही.
  2. Middle layer (Server) – कच्चा डेटा (raw data) शुद्ध HTML मार्कअपमध्ये रूपांतरित करा. हे लेअर अजूनही React च्या JSX सिंटॅक्सचा वापर करू शकते परंतु ते फक्त सर्व्हरपुरते मर्यादित राहते.
  3. Top layer (Client) – इंटरअॅक्टिव्हिटीसाठी लहान, स्वतंत्र विगेट्स (widgets) समाविष्ट करा. "लाईक" बटणे, कमेंट फॉर्म किंवा स्टेटची आवश्यकता असलेल्या ड्रॉपडाउन मेनू ही याची सामान्य उदाहरणे आहेत.

या श्रेणीबद्ध रचनेचे (hierarchy) पालन केल्यामुळे ॲपचा मोठा भाग हलका राहतो आणि वापरकर्त्यांना अपेक्षित असलेला डायनॅमिक अनुभवही टिकून राहतो.

तुम्ही आजच करून पाहू शकता असे काही टप्पे

  1. तुमच्या कोडबेसमध्ये असे कंपोनंट्स शोधा जे केवळ डेटा मिळवण्यासाठी useEffect वापरतात.
  2. 'fetch' कॉल एका नवीन Server Component मध्ये हलवा आणि त्याला रेंडर केलेला मार्कअप परत करू द्या.
  3. उरलेल्या कोणत्याही इंटरअॅक्टिव्ह घटकांसाठी एक किमान (minimal) क्लायंट कंपोनंट तयार करा (वर use client जोडा).
  4. तुमचा बंडल अ‍ॅनालाइझर (bundle analyzer) पुन्हा चालवा; तुम्हाला आकारामध्ये लक्षणीय घट दिसून येईल.

सर्वत्र use client वापरणे टाळा. जर एखादा कंपोनंट React state, context किंवा lifecycle hooks वर अवलंबून नसेल, तर त्याला Server Component म्हणूनच ठेवा. तुम्ही जितका जास्त कोड क्लायंटच्या बाहेर ठेवाल, तितका डाउनलोड आकार लहान असेल आणि पेज वेगाने लोड होईल.

थोडक्यात सांगायचे तर: डेटा फेचिंग आणि हेवी रेंडरिंग सर्व्हरवर हलवून, Next.js 14 तुम्हाला खूप कमी JavaScript पाठवण्यास, त्वरित पूर्णपणे रेंडर केलेले HTML प्रदान करण्यास आणि जिथे खरोखर गरज आहे तिथे इंटरअॅक्टिव्हिटी टिकवून ठेवण्यास मदत करते. याचा परिणाम म्हणजे वापरकर्ते आणि सर्च इंजिन्स या दोघांसाठीही अधिक वेगवान आणि सुटसुटीत वेब अनुभव मिळतो.