2021 में, Chrome ऑरोरा की टीम ने Next.js में तीसरे पक्ष की स्क्रिप्ट के लोड होने की परफ़ॉर्मेंस को बेहतर बनाने के लिए, स्क्रिप्ट कॉम्पोनेंट लॉन्च किया था. इसके लॉन्च होने के बाद से ही, हमने तीसरे पक्ष के संसाधनों को लोड करना आसान और तेज़ बनाने की सुविधा बढ़ा दी है.
इस ब्लॉग पोस्ट में, हमारी रिलीज़ की गई नई सुविधाओं के बारे में खास जानकारी दी गई है. खास तौर पर, @next/third-party लाइब्रेरी के साथ-साथ आने वाले समय में की जाने वाली पहलों के बारे में जानकारी.
तीसरे पक्ष की स्क्रिप्ट की परफ़ॉर्मेंस से जुड़ी समस्याएं
Next.js साइटों में, तीसरे पक्ष के सभी अनुरोधों में से 41% अनुरोध स्क्रिप्ट होते हैं. दूसरी तरह के कॉन्टेंट से अलग, स्क्रिप्ट को डाउनलोड करने और उन्हें लागू करने में काफ़ी समय लगता है. इससे रेंडरिंग ब्लॉक हो सकती है और उपयोगकर्ता से इंटरैक्ट करने में देरी हो सकती है. Chrome की उपयोगकर्ता अनुभव रिपोर्ट (CrUX) के डेटा से पता चलता है कि तीसरे पक्ष की ज़्यादा स्क्रिप्ट लोड करने वाली Next.js साइट का, इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) और सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) का पास रेट कम है.
इस चार्ट में मौजूद कोरिलेशन का यह मतलब नहीं है कि सेशन की वजह क्या है. हालांकि, लोकल एक्सपेरिमेंट से इस बात का अतिरिक्त सबूत मिलता है कि तीसरे पक्ष की स्क्रिप्ट, पेज की परफ़ॉर्मेंस पर काफ़ी असर डालती हैं. उदाहरण के लिए, नीचे दिया गया चार्ट अलग-अलग लैब मेट्रिक की तुलना करता है. ऐसा तब होता है, जब Google Tag Manager के किसी कंटेनर—जिसमें बिना किसी क्रम के 18 चुने गए टैग शामिल होते हैं—इसे Next.js के एक लोकप्रिय उदाहरण ऐप्लिकेशन टैक्सोनॉमी में जोड़ा जाता है.
WebPageTest दस्तावेज़ से पता चलता है कि इन टाइमिंग को कैसे मापा जाता है. एक नज़र में देखने से पता चलता है कि ये सभी लैब मेट्रिक पर GTM कंटेनर का असर पड़ा है. उदाहरण के लिए, टोटल ब्लॉकिंग टाइम (TBT)—एक उपयोगी लैब प्रॉक्सी, जो आईएनपी का अनुमान लगाता है—से करीब 20 गुना ज़्यादा बढ़ोतरी हुई.
स्क्रिप्ट कॉम्पोनेंट
जब हमने Next.js में <Script> कॉम्पोनेंट शिप किया था, तब हमने इसे उपयोगकर्ता के लिए आसान एपीआई के ज़रिए उपलब्ध कराया था. यह एपीआई, <script> के पारंपरिक एलिमेंट से काफ़ी मिलता-जुलता होता है. इसका इस्तेमाल करके, डेवलपर अपने ऐप्लिकेशन के किसी भी कॉम्पोनेंट में तीसरे पक्ष की स्क्रिप्ट को साथ में ले जा सकते हैं. साथ ही, ज़रूरी संसाधन लोड होने के बाद Next.js स्क्रिप्ट को सीक्वेंस करने का काम करेगा.
<!-- By default, script will load after page becomes interactive -->
<Script src="https://example.com/sample.js" />
<!-- Script is injected server-side and fetched before any page hydration occurs -->
<Script strategy=”beforeInteractive” src="https://example.com/sample.js" />
<!-- Script is fetched later during browser idle time -->
<Script strategy=”lazyOnload” src="https://example.com/sample.js" />
हज़ारों Next.js ऐप्लिकेशन—इसमें Patreon, Target, और Notion जैसी लोकप्रिय साइटें शामिल हैं—<Script> कॉम्पोनेंट का इस्तेमाल करती हैं. इसके असरदार होने के बावजूद, कुछ डेवलपर ने इन चीज़ों के बारे में समस्याएं बताई हैं:
- तीसरे पक्ष की अलग-अलग कंपनियों के इंस्टॉल करने के अलग-अलग निर्देशों का पालन करते हुए, Next.js ऐप्लिकेशन में
<Script>कॉम्पोनेंट को कहां रखें (डेवलपर के लिए अनुभव). - तीसरे पक्ष की अलग-अलग स्क्रिप्ट (उपयोगकर्ता अनुभव) के लिए, लोड होने की कौनसी रणनीति सबसे बेहतर होगी.
इन दोनों चिंताओं को दूर करने के लिए, हमने @next/third-parties लॉन्च किया है. यह एक खास लाइब्रेरी है, जो लोकप्रिय तीसरे पक्षों के हिसाब से तैयार किए गए, ऑप्टिमाइज़ किए गए कॉम्पोनेंट और सुविधाएं उपलब्ध कराती है.
डेवलपर अनुभव: तीसरे पक्ष की लाइब्रेरी को मैनेज करना आसान बनाना
तीसरे पक्ष की कई स्क्रिप्ट का इस्तेमाल, Next.js साइट के एक बड़े प्रतिशत में किया जाता है. इनमें Google Tag Manager सबसे ज़्यादा लोकप्रिय है, जिसका इस्तेमाल
66% साइटें करती हैं.
@next/third-parties ऊपर के लेवल वाले रैपर पेश करके, <Script> कॉम्पोनेंट के ऊपर बनता है.
इन सामान्य इस्तेमाल के उदाहरणों के लिए, इन्हें आसानी से इस्तेमाल करने के लिए डिज़ाइन किया गया है.
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
<GoogleTagManager gtmId="GTM-XYZ" />
</html>
);
}
Google Analytics—तीसरे पक्ष की एक ऐसी स्क्रिप्ट जिसका इस्तेमाल बड़े पैमाने पर किया जाता है (Next.js साइटों का 52%)—का अपना एक कॉम्पोनेंट भी है.
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
<GoogleAnalytics gaId="G-XYZ" />
</html>
);
}
@next/third-parties, आम तौर पर इस्तेमाल होने वाली स्क्रिप्ट को लोड करने की प्रोसेस को आसान बनाता है. हालांकि, इससे तीसरे पक्ष की अन्य कैटगरी के लिए सुविधाएं डेवलप करना भी हमारी मदद कर पाते हैं, जैसे कि एम्बेड. उदाहरण के लिए, Google Maps और YouTube पर एम्बेड किए गए कॉन्टेंट का इस्तेमाल, Next.js वेबसाइट के 8% और 4% वेबसाइटों पर होता है. साथ ही, हमने आसानी से लोड करने के लिए कॉम्पोनेंट भी भेजे हैं.
import { GoogleMapsEmbed } from "@next/third-parties/google";
import { YouTubeEmbed } from "@next/third-parties/google";
export default function Page() {
return (
<>
<GoogleMapsEmbed
apiKey="XYZ"
height={200}
width="100%"
mode="place"
q="Brooklyn+Bridge,New+York,NY"
/>
<YouTubeEmbed videoid="ogfYd705cRs" height={400} params="controls=0" />
</>
);
}
उपयोगकर्ता अनुभव: तीसरे पक्ष की लाइब्रेरी को तेज़ी से लोड करना
एक आदर्श दुनिया में, बड़े पैमाने पर इस्तेमाल होने वाली तीसरे पक्ष की हर लाइब्रेरी को पूरी तरह ऑप्टिमाइज़ किया जाएगा. इससे, परफ़ॉर्मेंस को बेहतर बनाने वाले किसी भी ऐब्सट्रैक्ट का इस्तेमाल करने की ज़रूरत नहीं होगी. हालांकि, जब तक यह संभव नहीं हो जाता, तब तक हम Next.js जैसे लोकप्रिय फ़्रेमवर्क के ज़रिए अपने उपयोगकर्ता अनुभव को बेहतर बनाने की कोशिश कर सकते हैं. हम लोड करने की अलग-अलग तकनीकों के साथ प्रयोग कर सकते हैं, यह पक्का कर सकते हैं कि स्क्रिप्ट सही तरीके से क्रम से लगाई गई हैं या नहीं. इसके बाद, हम तीसरे पक्ष की सेवा देने वाली कंपनियों के साथ अपना सुझाव शेयर कर सकते हैं, ताकि अपस्ट्रीम बदलाव किए जा सकें.
उदाहरण के लिए, YouTube से एम्बेड किए गए वीडियो देखें. वहीं, नेटिव एम्बेड के मुकाबले, लागू करने के कुछ वैकल्पिक तरीकों की परफ़ॉर्मेंस बेहतर होती है. फ़िलहाल, @next/third-parties से एक्सपोर्ट किया गया <YouTubeEmbed> कॉम्पोनेंट, lite-youtube-embed का इस्तेमाल करता है. जब "Hello, World" Next.js में दिखाया गया हो, तो यह कॉम्पोनेंट तेज़ी से लोड होता है.
इसी तरह, Google Maps के लिए हम एम्बेड के डिफ़ॉल्ट एट्रिब्यूट के तौर पर loading="lazy" को शामिल करते हैं, ताकि यह पक्का किया जा सके कि मैप सिर्फ़ तब लोड हो, जब यह व्यूपोर्ट से एक तय दूरी पर हो. यह एट्रिब्यूट दिखने में सामान्य लग सकता है. खास तौर पर, जब Google Maps के दस्तावेज़ में इसे अपने उदाहरण के कोड स्निपेट में शामिल किया गया हो, लेकिन Google Maps को एम्बेड करने वाली 45% Next.js साइटें loading="lazy" का इस्तेमाल कर रही हैं.
वेब वर्कर में तीसरे पक्ष की स्क्रिप्ट चलाना
एक बेहतर तकनीक जिस पर हम @next/third-parties में काम कर रहे हैं, वह है तीसरे पक्ष की स्क्रिप्ट को वेब वर्कर पर ऑफ़लोड करना आसान बनाना. इसे पार्टीटाउन जैसी लाइब्रेरी से लोकप्रिय बनाया जाता है. यह पेज की परफ़ॉर्मेंस पर तीसरे पक्ष की स्क्रिप्ट के असर को काफ़ी हद तक कम कर सकता है. इसके लिए, उन्हें मुख्य थ्रेड से पूरी तरह से दूसरी जगह ले जाना पड़ता है.
नीचे दिया गया ऐनिमेटेड GIF, Next.js साइट में GTM कंटेनर पर अलग-अलग <Script> रणनीतियों को लागू करते समय, लंबे टास्क और मुख्य थ्रेड के ब्लॉक होने के समय में अंतर दिखाता है. ध्यान रखें कि रणनीति के विकल्पों के बीच स्विच करने से, इन स्क्रिप्ट के लागू होने का समय ही देर से शुरू होता है. उन्हें वेब वर्कर पर ले जाने से, मुख्य थ्रेड पर बना उनका समय पूरी तरह खत्म हो जाता है.
इस उदाहरण में, GTM कंटेनर और उससे जुड़े टैग स्क्रिप्ट को एक वेब वर्कर में ले जाने से TBT में 92%की कमी आई है.
ध्यान रखें कि अगर इसे सावधानी से मैनेज नहीं किया जाता, तो यह तकनीक तीसरे पक्ष की कई स्क्रिप्ट को बिना किसी रुकावट के नुकसान पहुंचा सकती है. इससे, डीबग करना मुश्किल हो जाता है. आने वाले महीनों में, हम इस बात की पुष्टि करेंगे कि वेब वर्कर में चलाए जाने पर, @next/third-parties से मिलने वाले तीसरे पक्ष के कॉम्पोनेंट सही तरीके से काम कर रहे हैं या नहीं. अगर ऐसा है, तो हम डेवलपर को इस तकनीक का इस्तेमाल करने का एक आसान और
वैकल्पिक तरीका उपलब्ध कराने की दिशा में काम करेंगे.
अगले चरण
इस पैकेज को डेवलप करने की प्रक्रिया से पता चला कि लोड होने वाले तीसरे पक्ष के सुझावों को एक ही जगह पर लाने की ज़रूरत थी, ताकि दूसरे फ़्रेमवर्क को भी इस्तेमाल की गई तकनीकों से फ़ायदा मिल सके. इससे हमने तीसरे पक्ष की
कैपिटल बनाई. यह एक लाइब्रेरी है, जो
तीसरे पक्ष का कॉन्टेंट लोड करने की तकनीकों के बारे में बताने के लिए JSON का इस्तेमाल करती है. फ़िलहाल, यह
@next/third-parties के लिए आधार के तौर पर काम करती है.
अगले चरणों के तौर पर, हम Next.js के लिए मिलने वाले कॉम्पोनेंट को बेहतर बनाने पर ध्यान देंगे. साथ ही, हम दूसरे लोकप्रिय फ़्रेमवर्क और कॉन्टेंट मैनेजमेंट सिस्टम प्लैटफ़ॉर्म पर भी इसी तरह की सुविधाओं को शामिल करने की कोशिश करेंगे. फ़िलहाल, हम Nuxt के रखरखाव करने वाली कंपनियों के साथ मिलकर काम कर रहे हैं. आने वाले समय में हम तीसरे पक्ष की ऐसी ही सुविधाएं रिलीज़ करने की योजना बना रहे हैं जो उनके नेटवर्क के हिसाब से बनाई गई हों.
आपके Next.js ऐप्लिकेशन में इस्तेमाल होने वाले तीसरे पक्ष में से अगर @next/third-parties पर काम करता है, तो
पैकेज इंस्टॉल करें
और उसे आज़माएं! हमें GitHub के बारे में आपकी राय जानकर खुशी होगी.