🧐 🔁 🦔 कैसे Gatsby ने Next.js को दरकिनार कर दिया 💪🏻 🔙 👛

लेख के लेखक, जिसका अनुवाद आज हम प्रकाशित करते हैं, एंटलर में एक प्रोग्रामर के रूप में काम करता है। यह कंपनी एक वैश्विक स्टार्टअप जनरेटर है। साल में कई बार एंटलर में डेमो दिन होते हैं, जिससे दुनिया भर के कई स्टार्टअप निर्माता और निवेशक एक साथ आते हैं। COVID-19 के आसपास की स्थिति ने एंटलर को अपनी घटनाओं को एक ऑनलाइन प्रारूप में अनुवाद करने के लिए मजबूर किया।

कंपनी यह सुनिश्चित करना चाहती थी कि आगंतुक अपनी आभासी घटनाओं से, बिना किसी चीज़ से विचलित हुए, और कहीं भी अटक न जाएं, सबसे महत्वपूर्ण बात देखेंगे। अर्थात्, स्टार्टअप के विचारों को जनता के सामने प्रस्तुत किया गया, जिसे वेब पेजों की सामग्री के रूप में व्यक्त किया गया। आभासी प्रदर्शन के दिन काफी व्यापक दर्शकों के लिए रुचि के हो सकते हैं। इस ऑडियंस के कुछ सदस्य पहली बार इस तरह से भाग ले सकते हैं। इसलिए, कंपनी को हर संभव प्रयास करना पड़ा और स्टार्टअप का प्रतिनिधित्व करने वाले पृष्ठों की उच्च गति लोडिंग प्रदान की। उन्होंने फैसला किया कि यह केवल एक मामला है जब एक उच्च-प्रदर्शन प्रगतिशील वेब अनुप्रयोग (PWA, प्रगतिशील वेब ऐप) काम में आ सकता है। मुख्य मुद्दा PWA के विकास के लिए सही तकनीक का पता लगाना था।

सर्वर रेंडरिंग या स्थिर साइट जनरेटर?

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

हमें प्रदर्शन के एक असम्बद्ध स्तर की आवश्यकता थी। इसलिए, हमने सर्वर-साइड रेंडरिंग (एसएसआर, सर्वर-साइड रेंडरिंग) या एक स्थिर साइट जनरेटर (एसएसजी, स्टेटिक साइट जनरेटर) का उपयोग करने के बारे में सोचना शुरू किया, ताकि अनुप्रयोगों का प्रारंभिक लोडिंग जितनी जल्दी हो सके।

हमारा डेटा क्लाउड फायरस्टोर में संग्रहीत है, और हम अल्गोलिया का उपयोग करके उन्हें एक्सेस करते हैं। यह हमें डेटाबेस फ़ील्ड स्तर पर प्रतिबंधित API कुंजियों के साथ डेटा तक सार्वजनिक पहुंच को नियंत्रित करने की अनुमति देता है। यह क्वेरी प्रदर्शन में भी सुधार करता है। अनुभव से, हम जानते हैं कि अल्गोलिया प्रश्न सामान्य से तेज हैं, और यह कि फायरस्टार जावास्क्रिप्ट एसडीके 86 केबी आकार का है । अल्गोलिया के मामले में, यह 7.5 Kb है ।

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

प्रारंभ में, हमारा आवेदन गैट्सबी के आधार पर बनाया गया था, क्योंकि हम पहले से ही गैट्सबी पर निर्मित लैंडिंग पृष्ठों का उपयोग करते थे, और उनमें से एक पर सामग्री-यूआई पुस्तकालय पहले से ही उपयोग किया गया था। परियोजना के पहले संस्करण ने एक पृष्ठ बनाया, जबकि डेटा लोड किया जा रहा था, एक "कंकाल" प्रदर्शित किया। उसी समय, पहला विवादास्पद पेंट (एफसीपी) 1 सेकंड के क्षेत्र में था।

बाद के डेटा लोडिंग के साथ पेज के "कंकाल" को डाउनलोड करना

समाधान दिलचस्प हो गया, लेकिन इसकी कमियां थीं, क्योंकि क्लाइंट की पहल पर पेज के आउटपुट के लिए डेटा डाउनलोड किया गया था:

पृष्ठ की सामग्री को देखने के लिए, उपयोगकर्ताओं को स्वयं इस पृष्ठ के डाउनलोड होने का इंतजार करना होगा और इसमें प्रदर्शित डेटा, अल्गोलिया के लिए 4 अनुरोधों के माध्यम से प्राप्त किया जाएगा।
JS- . , React «» . DOM.
. , , .

नतीजतन, लंबे सप्ताहांत में, मैंने Next.js. का उपयोग करके बनाई गई परियोजना के SSR संस्करण के साथ प्रयोग करने का निर्णय लिया। मेरे लिए सौभाग्य से, सामग्री- UI के लिए प्रलेखन नेक्स्ट के लिए एक उदाहरण परियोजना थी। इसलिए, मुझे खरोंच से इस सभी ढांचे को सीखने की आवश्यकता नहीं थी। मुझे बस ट्यूटोरियल और प्रलेखन के कुछ हिस्सों को देखना था। मैंने एप्लिकेशन को सर्वर पर प्रदान की गई परियोजना में बदल दिया। जब कोई उपयोगकर्ता पृष्ठ लोड करने का अनुरोध करता है, तो सर्वर पृष्ठ को भरने के लिए आवश्यक डेटा के लिए अनुरोधों को निष्पादित करता है। इस कदम ने हमें उपरोक्त तीनों समस्याओं को हल करने की अनुमति दी। यहां दो आवेदन विकल्पों के लिए परीक्षा परिणाम दिए गए हैं।

Google पेजस्पीड इनसाइट्स का उपयोग करके अनुप्रयोगों पर शोध करने के परिणाम । बाईं ओर Gatsby (SSG) है, दाईं ओर Next.js (SSR) ( मूल चित्र ) है

। परियोजना के Next.js संस्करण के लिए FCP, Gatsby पर आधारित इसके संस्करण की तुलना में लगभग 3 गुना अधिक था। परियोजना के गैट्सबी संस्करण में 3.3 सेकंड का स्पीड इंडेक्स था, जबकि नेक्स्ट.जेएस संस्करण में 6.2 सेकंड था। अगली बाइट का समय (TTFB, टाइम टू फर्स्ट बाइट) Next.js का उपयोग करते समय 2.56 सेकंड, और Gatsby का उपयोग करते समय 10-20 ms है।

यह ध्यान दिया जाना चाहिए कि साइट के Next.js संस्करण को किसी अन्य सेवा पर तैनात किया गया था (यहां हमने ZEIT Now और Firebase होस्टिंग सेवाओं का उपयोग किया है - यह TTFB में वृद्धि को भी प्रभावित कर सकता है)। लेकिन, इसके बावजूद, यह स्पष्ट था कि सर्वर पर डेटा अपलोड संचालन के हस्तांतरण ने साइट को धीमा कर दिया, इस तथ्य के बावजूद कि सभी पृष्ठ सामग्री एक ही समय में भरी हुई थीं। तथ्य यह है कि परियोजना के Next.js-संस्करण में उपयोगकर्ता कुछ समय के लिए केवल एक खाली सफेद पृष्ठ देखता है।

एक एप्लिकेशन के दो संस्करण लोड करते हुए स्क्रीन कैप्चर दिखा रहा है। डाउनलोड एक ही समय में पूरा नहीं हुआ। रिकॉर्ड्स आपके द्वारा दर्ज की गई कुंजी को दबाने के क्षण में सिंक्रनाइज़ किए जाते हैं।

यह सब हमें वेब विकास के क्षेत्र से एक महत्वपूर्ण सबक देता है: आपको उपयोगकर्ताओं को दृश्य प्रतिक्रिया देने की आवश्यकता है। एक अध्ययन में पाया गया है कि कंकाल की स्क्रीन का उपयोग करने वाले एप्लिकेशन तेजी से लोड होते हैं।

यह परिणाम, इसके अलावा, मूड के अनुरूप नहीं है जिसे आपने पिछले कुछ वर्षों में वेब विकास के बारे में लेख पढ़ा होगा। अर्थात्, हम इस तथ्य के बारे में बात कर रहे हैं कि ग्राहक के संसाधनों का उपयोग करने में कुछ भी गलत नहीं है, और यह कि एसएसआर प्रदर्शन समस्याओं का एक व्यापक समाधान नहीं है।

स्थैतिक साइट जनरेशन प्रदर्शन: तुलना गैट्सबी और Next.js

जबकि, Gatsby और Next.js पर विचार करने वाले दो ढांचे क्रमशः ज्ञात हैं, स्थैतिक साइटों और सर्वर रेंडरिंग की क्षमता के लिए, SSG के लिए समर्थन Next.js 9.3 में सुधार किया गया था, जो इसे Gatsby का प्रतियोगी बनाता है।

इस लेखन के समय, Next.js की स्थैतिक साइटों को बनाने की क्षमता अभी भी बहुत ताज़ा थी। वह एक महीने से थोड़ी अधिक थी। उसे अभी भी परियोजना के पहले पृष्ठ पर बताया गया है। अब Gatsby और Next.js के SSG क्षमताओं की कई तुलना नहीं हैं (या शायद अभी तक ऐसी कोई तुलना नहीं हुई है)। नतीजतन, मैंने अपना खुद का प्रयोग करने का फैसला किया।

मैंने क्लाइंट को डेटा डाउनलोड किए जाने पर प्रोजेक्ट के गैट्सबी संस्करण को राज्य को वापस कर दिया, और इसे बनाया ताकि एप्लिकेशन के दोनों संस्करणों में सुविधाओं का एक ही सेट हो। अर्थात्, मुझे Gatsby प्लगइन्स के लिए जिम्मेदार क्या हैं: एसईओ कार्यों, favicons, PWA प्रकट उत्पन्न करना था। विशेष रूप से फ्रेमवर्क द्वारा बनाए गए जावास्क्रिप्ट बंडलों की तुलना करने के लिए, मैंने परियोजनाओं में बाहरी स्रोतों से डाउनलोड की गई छवियों और अन्य सामग्री को शामिल नहीं किया। एप्लिकेशन के दोनों संस्करण फायरबेस होस्टिंग प्लेटफ़ॉर्म पर तैनात किए गए थे। संदर्भ के लिए, आवेदन के दो संस्करण Gatsby 2.20.9 और Next.js 9.3.4 के आधार पर बनाए गए थे।

मैंने प्रत्येक संस्करण के लिए 6 बार अपने कंप्यूटर पर लाइटहाउस चलाया। परिणामों ने गैट्सबी को थोड़ा फायदा दिखाया।

प्रत्येक फ्रेमवर्क ( मूल छवि ) के लिए 6 लाइटहाउस के लॉन्च के बाद प्राप्त औसत मूल्य

, समग्र प्रदर्शन मूल्यांकन के संदर्भ में, नेक्स्ट.जेएस संस्करण केवल गैट्सबी संस्करण से थोड़ा पीछे था। उसी के लिए जाता है FCP और गति सूचकांक। अनुप्रयोग के Next.js संस्करण के लिए अगला संभावित पहला इनपुट विलंब Gatsby संस्करण की तुलना में थोड़ा अधिक है।

क्या हो रहा है यह बेहतर ढंग से समझने के लिए, मैंने Chrome डेवलपर टूल के नेटवर्क टैब की ओर रुख किया। जैसा कि यह निकला, परियोजना के Next.js संस्करण में, जावास्क्रिप्ट कोड को विभाजित करने वाले टुकड़ों की संख्या गैट्सबी संस्करण (प्रकट फ़ाइलों को छोड़कर) से 3 अधिक है, लेकिन संपीड़ित कोड 20 KB छोटा है। क्या इन फ़ाइलों को डाउनलोड करने के लिए आवश्यक अतिरिक्त अनुरोध एक छोटे बंडल के लाभों को इतना बढ़ा सकते हैं कि यह प्रदर्शन को नुकसान पहुंचाता है?

परियोजना के गैट्सबी संस्करण में, 379 KB डेटा डाउनलोड करने के लिए 7 अनुरोध निष्पादित किए जाते हैं। परियोजना के Next.js संस्करण में - 359 KB डेटा ( मूल छवि ) डाउनलोड करने के लिए 12 अनुरोध

यदि आप जावास्क्रिप्ट प्रदर्शन का विश्लेषण करते हैं, तो डेवलपर उपकरण कहते हैं कि परियोजना के Next.js संस्करण को पहले रेंडरिंग के लिए अतिरिक्त 300 ms की आवश्यकता है, और यह संस्करण मूल्यांकन कार्य पर अधिक समय खर्च करता है। डेवलपर के टूल में, इस कार्य को "लंबे कार्य" के रूप में भी चिह्नित किया गया था।

Chrome डेवलपर टूल ( मूल छवि ) के प्रदर्शन टैब का उपयोग करके विभिन्न प्रोजेक्ट विकल्पों के प्रदर्शन का विश्लेषण

मैंने यह जानने के लिए प्रोजेक्ट कोड की तुलना की कि क्या उनके कार्यान्वयन में कोई अंतर हैं जो प्रदर्शन को प्रभावित कर सकते हैं। लापता टाइपस्क्रिप्ट प्रकारों से जुड़े अनावश्यक कोड और सुधारों को हटाने के अपवाद के साथ, एकमात्र अंतर पृष्ठ के चिकनी स्क्रॉलिंग का कार्यान्वयन था जब इसके व्यक्तिगत भागों में स्थानांतरित किया जाता है। यह सुविधा पहले एक फ़ाइल द्वारा शुरू की गईgatsby-browser.jsथी और इसे गतिशील रूप से आयातित घटक में स्थानांतरित किया गया था। नतीजतन, यह कोड केवल एक ब्राउज़र में चलेगा। (हमने चिकनी-स्क्रॉल एनपीएम पैकेज का उपयोग किया है, और इसे आयात करते समय, उसे एक ऑब्जेक्ट की आवश्यकता होती हैwindow।) यह समस्या अपराधी हो सकती है, लेकिन मुझे नहीं पता कि इसे Next.js. में कैसे संभाला जाता है।

डेवलपर के दृष्टिकोण से गैट्सबी अधिक सुविधाजनक है

अंत में, मैंने परियोजना के गैट्सबी संस्करण को चुनने का फैसला किया। इसके अलावा, यहां मैंने बहुत छोटे प्रदर्शन लाभ को ध्यान में नहीं रखा, जो कि Gatsby ने Next.js SSG तंत्र की तुलना में दिखाया (मैंने 0.6 सेकंड के लाभ के लिए गंभीरता से चिपकाया है?)। तथ्य यह है कि पीडब्ल्यूए की कई विशेषताएं परियोजना के गैट्सबी संस्करण में पहले से ही लागू हैं, और मैंने उन्हें आवेदन के Next.js संस्करण में फिर से लागू करने का बिंदु नहीं देखा।

जब मैं परियोजना का पहला गैट्सबी संस्करण बना रहा था, तो मैं परियोजना में कुछ उपयोगी PWA सुविधाओं को जल्दी से जोड़ने में सक्षम था। उदाहरण के लिए, प्रत्येक पृष्ठ को एसईओ के लिए आवश्यक मेरे स्वयं के मेटा टैग में जोड़ने के लिए, मुझे बस मैनुअल पढ़ना था । प्रोजेक्ट को PWA मेनिफ़ेस्ट से लैस करने के लिए, मुझे केवल उपयुक्त प्लगइन का उपयोग करने की आवश्यकता है। फ़ेविकॉन्स के साथ परियोजना को लैस करने के लिए जो सभी उपलब्ध प्लेटफार्मों का समर्थन करेगा (और इस मामले में अभी भी एक भयानक गड़बड़ है ), मुझे कुछ भी करने की ज़रूरत नहीं थी, क्योंकि फ़ेविकॉन समर्थन प्रकट होने के लिए जिम्मेदार प्लगइन का हिस्सा है। यह बहुत आरामदायक है!

आवेदन के Next.js संस्करण में समान सुविधाओं को लागू करने के लिए अधिक काम करने की आवश्यकता होगी। मुझे प्रशिक्षण मैनुअल, सभी प्रकार की "सर्वोत्तम प्रथाओं" को देखना होगा। और तथ्य यह है कि मैं सफल होगा, वैसे भी, मुझे कोई लाभ नहीं देगा। आखिरकार, फिर भी, प्रोजेक्ट का Next.js संस्करण अपने गैट्सबी संस्करण की तुलना में उच्च प्रदर्शन में भिन्न नहीं है। यह, इसके अलावा, यही कारण था कि मैंने प्रोजेक्ट के गैट्सबी संस्करण की संबंधित विशेषताओं को बस अक्षम करने का निर्णय लिया, इसकी तुलना नेक्स्ट.जेएस संस्करण के साथ की। Next.js प्रलेखन Gatsby प्रलेखन से अधिक संक्षिप्त है (हो सकता है तथ्य यह है कि है Next.js है की तुलना में छोटे Gatsby) मैं वास्तव में Gamified Next.js. ट्यूटोरियल पसंद करता हूं लेकिन अधिक व्यापक Gatsby प्रलेखन PWA के वास्तविक विकास के साथ अधिक मूल्यवान है, भले ही पहली नज़र में यह बहुत बड़ा लगता है।

Gatsby प्रलेखन

सच है, मैं Next.js ताकत के बारे में चुप नहीं रह सकता:

ट्यूटोरियल और Next.js के संक्षिप्त प्रलेखन के लिए धन्यवाद, ऐसा लगता है कि इस रूपरेखा को गैट्सबी की तुलना में तेजी से सीखा जा सकता है।
Next.js में उपयोग किया जाने वाला डेटा लोडिंग सिस्टम एसिंक्रोनस फ़ंक्शंस और फ़ेच एपीआई पर आधारित है। परिणामस्वरूप, Next.js को विकसित करते समय, डेवलपर को यह महसूस नहीं होता है कि उसे रूपरेखा की क्षमताओं का पूरा लाभ उठाने के लिए ग्राफकॉल को सीखने की आवश्यकता है।
Next.js TypeScript, Gatsby , ( ). Next.js , , , .

इस तथ्य के लिए धन्यवाद कि Next.js ने SSG समर्थन में सुधार किया है, यह ढांचा एक शक्तिशाली उपकरण बन गया है जो प्रत्येक व्यक्ति के स्तर पर, इसके साथ काम करने की विधि को चुनने की अनुमति देता है। यह SSR, SSG या CSR हो सकता है।

वास्तव में, यदि मैं एक पूरी तरह से स्थिर रूप में इस आवेदन उत्पन्न कर सकता है, तो Next.js मुझे बेहतर सूट होता है, के बाद से मैं मानक Algolia जे एस-एपीआई इस्तेमाल कर सकते हैं और डेटा लोड करने के लिए कोड रख सकता है एक ही फाइल में के रूप में और घटक कोड। चूंकि अल्गोलिया में बिल्ट-इन ग्राफक्यूएल एपीआई नहीं है, और अल्गोलिया के लिए कोई गैट्सबी प्लगइन नहीं है, इसलिए गैट्सबी में इस तरह के तंत्र को लागू करने के लिए इस कोड को एक नई फ़ाइल में जोड़ना होगा । और यह पृष्ठों का वर्णन करने के सहज तरीके के खिलाफ जाता है।

प्रोजेक्ट प्रदर्शन को बेहतर बनाने के अतिरिक्त तरीकों के बारे में

जब हमने फ्रेमवर्क चुनने की समस्या को हल कर लिया है, तो यह ध्यान दिया जा सकता है कि परियोजना के प्रदर्शन में सुधार के लिए अतिरिक्त तरीके हैं जो फ्रेमवर्क से संबंधित नहीं हैं। ये सुधार अच्छी तरह से लाइटहाउस परियोजना की रेटिंग 100 तक ला सकते हैं।

में मार्च Algolia मेलिंग सूची, यह एक संकेत जोड़ने के लिए सिफारिश की गई थी preconnectक्वेरी निष्पादन की गति और अधिक वृद्धि करने के लिए। (सच है, दुर्भाग्य से, गलत कोड टुकड़ा समाचार पत्र में दिया गया है। यहां सही कोड है।)
. JS- CSS-, webpack- Gatsby. Gatsby . , , Netlify Amazon S3. , Firebase Hosting, , .
हम एप्लिकेशन में स्टार्टअप निर्माता द्वारा अपलोड की गई JPEG और PNG छवियों का उपयोग करते हैं। हम उन्हें संकुचित और अनुकूलित नहीं करते हैं। हमारे आवेदन के इस पहलू में सुधार करना काफी चुनौती भरा है और इस परियोजना के दायरे से परे है। इसके अलावा, यह बहुत अच्छा होगा यदि इन सभी छवियों को वेबपी प्रारूप में बदल दिया गया। नतीजतन, हमें केवल एक अत्यधिक कुशल ग्राफिक प्रारूप का उपयोग करके छवियों को संग्रहीत करना होगा। दुर्भाग्य से, कई अन्य PWA सुविधाओं के साथ, Safari WebKit डेवलपमेंट टीम WebP समर्थन के साथ दीवानी है। अब यह एकमात्र प्रमुख ब्राउज़र है जो इस प्रारूप का समर्थन नहीं करता है ।

सारांश

यदि हम संक्षेप में यहां बता रहे हैं कि हम यहां क्या बात कर रहे थे, तो हम निम्नलिखित कह सकते हैं:

क्लाइंट द्वारा डेटा लोड करने के दौरान पृष्ठ के "कंकाल" संस्करण का आउटपुट उपयोगकर्ता को तेजी से वेबसाइट संचालन की भावना पैदा करता है जब उपयोगकर्ता सर्वर लोड करते समय एक खाली पृष्ठ को देखता है।
साइट का गैट्सबी संस्करण केवल Next.js संस्करण की तुलना में थोड़ा तेज था। हालांकि, गैट्सबी प्लग-इन सिस्टम और उच्च-गुणवत्ता वाली परियोजना प्रलेखन डेवलपर के लिए इस ढांचे की उपयोगिता को बढ़ाती है।

प्रिय पाठकों! क्या आप अपनी परियोजनाओं को गति देने के लिए स्थैतिक साइट जनरेटर या सर्वर-साइड रेंडरिंग सिस्टम का उपयोग करते हैं?

कैसे Gatsby ने Next.js को दरकिनार कर दिया

सर्वर रेंडरिंग या स्थिर साइट जनरेटर?

स्थैतिक साइट जनरेशन प्रदर्शन: तुलना गैट्सबी और Next.js

डेवलपर के दृष्टिकोण से गैट्सबी अधिक सुविधाजनक है

प्रोजेक्ट प्रदर्शन को बेहतर बनाने के अतिरिक्त तरीकों के बारे में

सारांश

More articles: