एक असरदार इमेज कॉम्पोनेंट बनाना

इमेज कॉम्पोनेंट, परफ़ॉर्मेंस के सबसे सही तरीकों को शामिल करता है. साथ ही, इमेज को ऑप्टिमाइज़ करने के लिए, एक ऐसा समाधान उपलब्ध कराता है जो पहले से तैयार होता है.

Leena Sohoni
Leena Sohoni
Kara Erickson
Kara Erickson
Alex Castle
Alex Castle

वेब ऐप्लिकेशन की परफ़ॉर्मेंस में रुकावट आने की समस्या का आम तौर पर इमेज से जुड़ा होना आम बात है. इसलिए, इमेज को ऑप्टिमाइज़ करना ज़रूरी है. ऑप्टिमाइज़ न की गई इमेज का पेज ब्लोट में योगदान होता है. 90th पर्सेंटाइल पर इनकी वजह से पेज के कुल वज़न का 70% से ज़्यादा हिस्सा बाइट में आता है. इमेज को ऑप्टिमाइज़ करने के कई तरीकों के लिए, बेहतर "इमेज कॉम्पोनेंट" की ज़रूरत होती है. इसमें परफ़ॉर्मेंस से जुड़े समाधान डिफ़ॉल्ट रूप से शामिल होते हैं.

Aurora की टीम ने ऐसा एक कॉम्पोनेंट बनाने के लिए, Next.js के साथ काम किया. इसका मकसद, ऑप्टिमाइज़ किया गया ऐसा इमेज टेंप्लेट बनाना था जिसे वेब डेवलपर अपनी पसंद के मुताबिक बना सकें. यह कॉम्पोनेंट एक अच्छे मॉडल के तौर पर काम करता है. साथ ही, अन्य फ़्रेमवर्क, कॉन्टेंट मैनेजमेंट सिस्टम (सीएमएस), और टेक्नोलॉजी स्टैक में इमेज कॉम्पोनेंट बनाने के लिए एक स्टैंडर्ड सेट करता है. हमने Nuxt.js के लिए एक जैसे कॉम्पोनेंट पर साथ मिलकर काम किया है. साथ ही, आने वाले वर्शन में इमेज ऑप्टिमाइज़ेशन के लिए, हम Angular के साथ काम कर रहे हैं. इस पोस्ट में, हमने Next.js इमेज कॉम्पोनेंट को डिज़ाइन करने के तरीके और इस प्रोसेस के दौरान मिले सबक के बारे में बताया है.

इमेज के एक्सटेंशन के तौर पर इमेज कॉम्पोनेंट

इमेज ऑप्टिमाइज़ेशन से जुड़ी समस्याएं और अवसर

इमेज का असर, न सिर्फ़ परफ़ॉर्मेंस पर पड़ता है, बल्कि कारोबार पर भी पड़ता है. वेबसाइटों पर आने वाले उपयोगकर्ताओं के कन्वर्ज़न का सबसे ज़्यादा अनुमान लगाने के लिए, पेज पर मौजूद इमेज की संख्या दूसरी सबसे अहम बात थी. जिन सेशन में उपयोगकर्ता ग्राहक में बदले उनमें, ग्राहक में नहीं बदलने वाले उपयोगकर्ताओं के सेशन की तुलना में 38% कम इमेज थीं. Lighthouse, सबसे सही तरीकों के ऑडिट के तहत, इमेज को ऑप्टिमाइज़ करने और वेब पर वेबसाइट की परफ़ॉर्मेंस से जुड़ी अहम जानकारी को बेहतर बनाने के लिए कई अवसर बताता है. इमेज से वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी और उपयोगकर्ता अनुभव पर असर पड़ सकता है. ऐसा इन वजहों से होता है.

बिना साइज़ वाली इमेज, सीएलएस को नुकसान पहुंचाती हैं

साइज़ की जानकारी के बिना दिखाई गई इमेज की वजह से, लेआउट में अस्थिरता हो सकती है. साथ ही, क्युम्युलेटिव लेआउट शिफ़्ट (सीएलएस) की दर भी बढ़ सकती है. img एलिमेंट पर width और height एट्रिब्यूट सेट करने से, लेआउट शिफ़्ट को रोकने में मदद मिल सकती है. उदाहरण के लिए:

<img src="flower.jpg" width="360" height="240">

चौड़ाई और ऊंचाई को ऐसे सेट करना चाहिए कि रेंडर की गई इमेज का आसपेक्ट रेशियो, उसके नैचुरल आसपेक्ट रेशियो के करीब हो. आस्पेक्ट रेशियो में काफ़ी अंतर होने पर, इमेज खराब दिख सकती है. यह एक नई प्रॉपर्टी है, जिसकी मदद से सीएसएस में आसपेक्ट रेशियो तय किया जा सकता है. इससे सीएलएस को रोकने के साथ-साथ, इमेज का साइज़ ज़रूरत के हिसाब से तय किया जा सकता है.

बड़ी इमेज से एलसीपी पर असर पड़ सकता है

इमेज का फ़ाइल साइज़ जितना बड़ा होगा, उसे डाउनलोड होने में उतना ही ज़्यादा समय लगेगा. बड़ी इमेज, पेज के लिए "हीरो" इमेज हो सकती है या व्यूपोर्ट में सबसे अहम एलिमेंट हो सकती है. यह सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) को ट्रिगर करने के लिए ज़िम्मेदार होती है. अगर कोई इमेज अहम कॉन्टेंट का हिस्सा है और उसे डाउनलोड होने में ज़्यादा समय लगता है, तो एलसीपी में देरी होगी.

कई मामलों में, डेवलपर बेहतर कंप्रेशन और रिस्पॉन्सिव इमेज का इस्तेमाल करके, इमेज के साइज़ को कम कर सकते हैं. <img> एलिमेंट के srcset और sizes एट्रिब्यूट की मदद से, इमेज फ़ाइलों को अलग-अलग साइज़ में उपलब्ध कराया जा सकता है. इसके बाद, ब्राउज़र स्क्रीन के साइज़ और रिज़ॉल्यूशन के हिसाब से सही इमेज चुन सकता है.

इमेज को खराब तरीके से कंप्रेस करने से, एलसीपी पर असर पड़ सकता है

AVIF या WebP जैसे आधुनिक इमेज फ़ॉर्मैट, आम तौर पर इस्तेमाल किए जाने वाले JPEG और PNG फ़ॉर्मैट की तुलना में बेहतर तरीके से इमेज को कंप्रेस कर सकते हैं. बेहतर कंप्रेशन, इमेज की एक जैसी क्वालिटी के लिए, कुछ मामलों में फ़ाइल के साइज़ को 25% से 50% तक कम करता है. इससे डेटा खर्च कम होता है और वीडियो तेज़ी से डाउनलोड होते हैं. ऐप्लिकेशन को उन ब्राउज़र पर मॉडर्न इमेज फ़ॉर्मैट काम करने चाहिए जो इन फ़ॉर्मैट के साथ काम करते हैं.

ग़ैर-ज़रूरी इमेज लोड करने से, एलसीपी पर असर पड़ता है

पेज लोड होने पर, फ़ोल्ड के नीचे या व्यूपोर्ट में मौजूद इमेज उपयोगकर्ता को नहीं दिखती हैं. इन्हें बाद में लोड किया जा सकता है, ताकि वे एलसीपी में योगदान न दें और उसमें देरी न हो. लेज़ी लोडिंग का इस्तेमाल करके, ऐसी इमेज को बाद में लोड किया जा सकता है, जब उपयोगकर्ता उन पर स्क्रोल करता है.

ऑप्टिमाइज़ेशन से जुड़ी चुनौतियां

टीमें ऊपर बताई गई समस्याओं के आधार पर, परफ़ॉर्मेंस की लागत का आकलन कर सकती हैं. साथ ही, उनसे निपटने के लिए सबसे सही तरीकों का इस्तेमाल कर सकती हैं. हालांकि, ऐसा अक्सर नहीं होता और वेब को धीमा करने वाली इमेज का इस्तेमाल जारी रहता है. ऐसा इन वजहों से हो सकता है:

  • प्राथमिकताएं: वेब डेवलपर आम तौर पर कोड, JavaScript, और डेटा ऑप्टिमाइज़ेशन पर फ़ोकस करते हैं. इसलिए, हो सकता है कि उन्हें इमेज से जुड़ी समस्याओं या उन्हें ऑप्टिमाइज़ करने के बारे में पता न हो. हो सकता है कि डिज़ाइनर की बनाई गई या उपयोगकर्ताओं की अपलोड की गई इमेज, प्राथमिकता की सूची में सबसे ऊपर न हों.
  • तैयार समाधान: भले ही, डेवलपर को इमेज ऑप्टिमाइज़ेशन की बारीकियों की जानकारी हो, लेकिन उनके फ़्रेमवर्क या टेक्नोलॉजी स्टैक के लिए, एक साथ सभी काम करने वाला कोई तैयार समाधान न होना, समस्या का हल करने में रुकावट बन सकता है.
  • डाइनैमिक इमेज: ऐप्लिकेशन का हिस्सा बनने वाली स्टैटिक इमेज के अलावा, डाइनैमिक इमेज को उपयोगकर्ता अपलोड करते हैं या बाहरी डेटाबेस या सीएमएस से सोर्स किया जाता है. जिन इमेज का सोर्स डाइनैमिक होता है उनके साइज़ को तय करना मुश्किल हो सकता है.
  • ज़्यादा मार्कअप: अलग-अलग साइज़ के लिए इमेज साइज़ या srcset को शामिल करने के लिए, हर इमेज के लिए अतिरिक्त मार्कअप की ज़रूरत होती है. यह काम मुश्किल हो सकता है. srcset एट्रिब्यूट को 2014 में लॉन्च किया गया था. हालांकि, फ़िलहाल सिर्फ़ 26.5% वेबसाइटों ने इसका इस्तेमाल किया है. srcset का इस्तेमाल करते समय, डेवलपर को अलग-अलग साइज़ में इमेज बनानी पड़ती हैं. just-gimme-an-img जैसे टूल से मदद मिल सकती है. हालांकि, हर इमेज के लिए इनका इस्तेमाल मैन्युअल तरीके से करना होगा.
  • ब्राउज़र पर काम करना: AVIF और WebP जैसे आधुनिक इमेज फ़ॉर्मैट, कम साइज़ की इमेज फ़ाइलें बनाते हैं. हालांकि, इन फ़ॉर्मैट को उन ब्राउज़र पर दिखाने के लिए, खास तरीके से हैंडल करना पड़ता है जो इनका इस्तेमाल नहीं करते. डेवलपर को कॉन्टेंट नेगोशिएशन या <picture> एलिमेंट जैसी रणनीतियों का इस्तेमाल करना होगा, ताकि इमेज सभी ब्राउज़र पर दिखें.
  • लेज़ी लोडिंग से जुड़ी समस्याएं: फ़ोल्ड के नीचे मौजूद इमेज के लिए, लेज़ी लोडिंग की सुविधा लागू करने के कई तरीके और लाइब्रेरी उपलब्ध हैं. सबसे अच्छा विकल्प चुनना मुश्किल हो सकता है. हो सकता है कि डेवलपर को यह भी न पता हो कि देर से लोड होने वाली इमेज को "फ़ोल्ड" से कितनी दूरी पर लोड करना है. डिवाइसों पर व्यूपोर्ट के अलग-अलग साइज़, इस प्रोसेस को और मुश्किल बना सकते हैं.
  • बदलाव की प्रक्रिया: परफ़ॉर्मेंस को बेहतर बनाने के लिए, ब्राउज़र में नई HTML या CSS सुविधाएं काम करना शुरू कर देती हैं. ऐसे में, डेवलपर के लिए इन सभी सुविधाओं का आकलन करना मुश्किल हो सकता है. उदाहरण के लिए, Chrome ऑरिजिन ट्रायल के तौर पर, फ़ेच करने की प्राथमिकता सुविधा लॉन्च कर रहा है. इसका इस्तेमाल, पेज पर मौजूद कुछ इमेज की प्राथमिकता बढ़ाने के लिए किया जा सकता है. कुल मिलाकर, अगर इस तरह के बेहतर बनाने की सुविधाओं का आकलन करके, उन्हें कॉम्पोनेंट लेवल पर लागू किया जाता है, तो डेवलपर के लिए यह आसान हो जाएगा.

समाधान के तौर पर इमेज कॉम्पोनेंट

इमेज को ऑप्टिमाइज़ करने के उपलब्ध अवसरों और उन्हें हर ऐप्लिकेशन के लिए अलग-अलग लागू करने में आने वाली चुनौतियों से, हमें इमेज कॉम्पोनेंट के बारे में आइडिया मिला. इमेज कॉम्पोनेंट, सबसे सही तरीकों को लागू कर सकता है. <img> एलिमेंट को इमेज कॉम्पोनेंट से बदलकर, डेवलपर इमेज की परफ़ॉर्मेंस से जुड़ी समस्याओं को बेहतर तरीके से हल कर सकते हैं.

पिछले साल, हमने Next.js फ़्रेमवर्क के साथ मिलकर काम किया है. इसका मकसद, इमेज कॉम्पोनेंट को डिज़ाइन करना और लागू करना था. इसका इस्तेमाल, Next.js ऐप्लिकेशन में मौजूदा <img> एलिमेंट के लिए, ड्रॉप-इन रिप्लेसमेंट के तौर पर किया जा सकता है. इसके लिए, यह तरीका अपनाएं.

// Before with <img> element:
function Logo() {
  return <img src="/logo.jpg" alt="logo" height="200" width="100" />
}

// After with image component:
import Image from 'next/image'

function Logo() {
  return <Image src="/logo.jpg" alt="logo" height="200" width="100" />
}

यह कॉम्पोनेंट, सुविधाओं और सिद्धांतों के बेहतर सेट की मदद से, इमेज से जुड़ी समस्याओं को सामान्य तौर पर हल करने की कोशिश करता है. इसमें ऐसे विकल्प भी शामिल हैं जिनकी मदद से डेवलपर, इमेज की अलग-अलग ज़रूरतों के हिसाब से इसे पसंद के मुताबिक बना सकते हैं.

लेआउट शिफ़्ट से सुरक्षा

जैसा कि पहले बताया गया है, साइज़ नहीं की गई इमेज की वजह से लेआउट शिफ़्ट होता है और सीएलएस बढ़ता है. Next.js इमेज कॉम्पोनेंट का इस्तेमाल करते समय, डेवलपर को width और height एट्रिब्यूट का इस्तेमाल करके इमेज का साइज़ देना ज़रूरी है, ताकि लेआउट शिफ़्ट न हो. अगर साइज़ की जानकारी नहीं है, तो डेवलपर को layout=fill तय करना होगा, ताकि किसी साइज़ के कंटेनर में मौजूद बिना साइज़ वाली इमेज दिखाई जा सके. इसके अलावा, स्टैटिक इमेज इंपोर्ट का इस्तेमाल करके, बिल्ड के समय हार्ड ड्राइव पर मौजूद असल इमेज का साइज़ वापस पाया जा सकता है और उसे इमेज में शामिल किया जा सकता है.

// Image component with width and height specified
<Image src="/logo.jpg" alt="logo" height="200" width="100" />

// Image component with layout specified
<Image src="/hero.jpg" layout="fill" objectFit="cover" alt="hero" />

// Image component with image import
import Image from 'next/image'
import logo from './logo.png'

function Logo() {
  return <Image src={logo} alt="logo" />
}

डेवलपर, इमेज कॉम्पोनेंट का इस्तेमाल बिना साइज़ के नहीं कर सकते. इसलिए, डिज़ाइन से यह पक्का होता है कि वे इमेज के साइज़ पर ध्यान देंगे और लेआउट शिफ़्ट को रोकेंगे.

जवाब देने की सुविधा दें

सभी डिवाइसों पर इमेज को रिस्पॉन्सिव बनाने के लिए, डेवलपर को <img> एलिमेंट में srcset और sizes एट्रिब्यूट सेट करने होंगे. हम इमेज कॉम्पोनेंट की मदद से, इस प्रोसेस को आसान बनाना चाहते थे. हमने Next.js इमेज कॉम्पोनेंट को इस तरह से डिज़ाइन किया है कि हर ऐप्लिकेशन के लिए एट्रिब्यूट की वैल्यू सिर्फ़ एक बार सेट की जा सके. हम इन्हें लेआउट मोड के आधार पर, इमेज कॉम्पोनेंट के सभी इंस्टेंस पर लागू करते हैं. हमने तीन हिस्सों में इसका समाधान दिया है:

  1. deviceSizes प्रॉपर्टी: इस प्रॉपर्टी का इस्तेमाल, ऐप्लिकेशन के उपयोगकर्ता आधार में शामिल डिवाइसों के आधार पर, ब्रेकपॉइंट को एक बार कॉन्फ़िगर करने के लिए किया जा सकता है. ब्रेकपॉइंट की डिफ़ॉल्ट वैल्यू, कॉन्फ़िगरेशन फ़ाइल में शामिल होती हैं.
  2. imageSizes प्रॉपर्टी: यह कॉन्फ़िगर की जा सकने वाली प्रॉपर्टी भी है. इसका इस्तेमाल, डिवाइस के साइज़ के ब्रेकपॉइंट के हिसाब से इमेज का साइज़ पाने के लिए किया जाता है.
  3. हर इमेज में layout एट्रिब्यूट: इसका इस्तेमाल यह बताने के लिए किया जाता है कि हर इमेज के लिए deviceSizes और imageSizes प्रॉपर्टी का इस्तेमाल कैसे किया जाए. लेआउट मोड के लिए, fixed, fill, intrinsic, और responsive वैल्यू का इस्तेमाल किया जा सकता है

जब किसी इमेज का अनुरोध, लेआउट मोड रिस्पॉन्सिव या फ़िल के साथ किया जाता है, तो Next.js उस इमेज की पहचान करता है जिसे पेज का अनुरोध करने वाले डिवाइस के साइज़ के आधार पर दिखाया जाना है. साथ ही, वह इमेज में srcset और sizes को सही तरीके से सेट करता है.

नीचे दी गई तुलना से पता चलता है कि अलग-अलग स्क्रीन पर इमेज का साइज़ कंट्रोल करने के लिए, लेआउट मोड का इस्तेमाल कैसे किया जा सकता है. हमने Next.js के दस्तावेज़ों में शेयर की गई डेमो इमेज का इस्तेमाल किया है. इसे फ़ोन और स्टैंडर्ड लैपटॉप पर देखा गया है.

लैपटॉप स्क्रीन फ़ोन की स्क्रीन
लेआउट = आंतरिक: छोटे व्यूपोर्ट पर कंटेनर की चौड़ाई को फ़िट करने के लिए छोटा किया जाता है. बड़े व्यूपोर्ट पर, इमेज के मूल साइज़ से ज़्यादा नहीं स्केल होती. कंटेनर की चौड़ाई 100% है
पहाड़ों की इमेज को वैसे ही दिखाया गया है पहाड़ों की इमेज का साइज़ कम किया गया
लेआउट = फ़िक्स्ड: इमेज रिस्पॉन्सिव नहीं है. `` एलिमेंट की चौड़ाई और ऊंचाई तय होती है. भले ही, इसे किसी भी डिवाइस पर रेंडर किया गया हो.
पहाड़ों की इमेज को वैसे ही दिखाया गया है पहाड़ों की इमेज, स्क्रीन पर फ़िट नहीं हो रही है
लेआउट = रिस्पॉन्सिव: अलग-अलग व्यूपोर्ट पर कंटेनर की चौड़ाई के हिसाब से, आसपेक्ट रेशियो को बनाए रखते हुए स्केल करें या स्केल करें.
स्क्रीन पर फ़िट करने के लिए, पहाड़ों की इमेज को बड़ा किया गया स्क्रीन पर फ़िट करने के लिए, पहाड़ों की इमेज का साइज़ छोटा किया गया
लेआउट = फ़िल: पैरंट कंटेनर को भरने के लिए, चौड़ाई और ऊंचाई को स्ट्रेच किया जाता है. (इस उदाहरण में, पैरंट <div> की चौड़ाई 300*500 पर सेट है)
पहाड़ों की इमेज को 300*500 साइज़ में रेंडर किया गया पहाड़ों की इमेज को 300*500 साइज़ में रेंडर किया गया
अलग-अलग लेआउट के लिए रेंडर की गई इमेज

पहले से मौजूद लेज़ी लोडिंग की सुविधा

इमेज कॉम्पोनेंट, डिफ़ॉल्ट के तौर पर, पहले से मौजूद लेज़ी लोडिंग समाधान उपलब्ध कराता है. <img> एलिमेंट का इस्तेमाल करते समय, लेज़ी लोडिंग के लिए कुछ विकल्प होते हैं. हालांकि, इन सभी में कुछ ऐसी कमियां होती हैं जिनकी वजह से इनका इस्तेमाल करना मुश्किल हो जाता है. डेवलपर, इनमें से कोई एक तरीका अपना सकता है:

  • loading एट्रिब्यूट के बारे में बताएं: यह सभी मॉडर्न ब्राउज़र पर काम करता है.
  • Intersection Observer API का इस्तेमाल करें: कस्टम लेज़ी-लोडिंग सलूशन बनाने के लिए, ज़रूरी है कि आप इसे ध्यान से डिज़ाइन करें और लागू करें. ऐसा हो सकता है कि डेवलपर के पास हमेशा ऐसा करने का समय न हो.
  • इमेज को लेज़ी-लोड करने के लिए, तीसरे पक्ष की लाइब्रेरी इंपोर्ट करना: लेज़ी लोडिंग के लिए, तीसरे पक्ष की किसी लाइब्रेरी का आकलन करने और उसे इंटिग्रेट करने के लिए, ज़्यादा मेहनत की ज़रूरत पड़ सकती है.

Next.js इमेज कॉम्पोनेंट में, लोडिंग डिफ़ॉल्ट रूप से "lazy" पर सेट होती है. लैज़ी लोडिंग को इंटरसेक्शन ऑब्ज़र्वर का इस्तेमाल करके लागू किया जाता है. यह ज़्यादातर आधुनिक ब्राउज़र पर उपलब्ध है. डेवलपर को इसे चालू करने के लिए कुछ और करने की ज़रूरत नहीं है, लेकिन ज़रूरत पड़ने पर वे इसे बंद कर सकते हैं.

ज़रूरी इमेज पहले से लोड करना

अक्सर, एलसीपी एलिमेंट इमेज होती हैं. बड़ी इमेज की वजह से एलसीपी में देरी हो सकती है. ज़रूरी इमेज को पहले से लोड करना अच्छा होता है, ताकि ब्राउज़र उस इमेज को जल्दी ढूंढ सके. <img> एलिमेंट का इस्तेमाल करते समय, एचटीएमएल हेड में प्रीलोड करने का संकेत इस तरह शामिल किया जा सकता है.

<link rel="preload" as="image" href="important.png">

अच्छी तरह से डिज़ाइन किए गए इमेज कॉम्पोनेंट में, इमेज के लोड होने के क्रम में बदलाव करने का विकल्प होना चाहिए. भले ही, इसके लिए किसी भी फ़्रेमवर्क का इस्तेमाल किया गया हो. Next.js इमेज कॉम्पोनेंट के मामले में, डेवलपर इमेज कॉम्पोनेंट के priority एट्रिब्यूट का इस्तेमाल करके यह बता सकते हैं कि किस इमेज को पहले से लोड किया जा सकता है.

<Image src="/hero.jpg" alt="hero" height="400" width="200" priority />

priority एट्रिब्यूट जोड़ने से मार्कअप आसान हो जाता है और इसका इस्तेमाल करना ज़्यादा सुविधाजनक हो जाता है. इमेज कॉम्पोनेंट के डेवलपर, हेयुरिस्टिक्स लागू करने के विकल्पों को भी एक्सप्लोर कर सकते हैं. इससे, पेज पर ऊपर दिखने वाली उन इमेज को अपने-आप प्रीलोड किया जा सकता है जो खास शर्तों को पूरा करती हैं.

बेहतर परफ़ॉर्मेंस वाली इमेज होस्टिंग को बढ़ावा दें

इमेज ऑप्टिमाइज़ेशन को ऑटोमेट करने के लिए, इमेज सीडीएन का सुझाव दिया जाता है. साथ ही, ये WebP और AVIF जैसे मॉडर्न इमेज फ़ॉर्मैट के साथ भी काम करते हैं. Next.js इमेज कॉम्पोनेंट, डिफ़ॉल्ट रूप से लोडर आर्किटेक्चर का इस्तेमाल करके इमेज सीडीएन का इस्तेमाल करता है. नीचे दिए गए उदाहरण से पता चलता है कि लोडर, Next.js कॉन्फ़िगरेशन फ़ाइल में सीडीएन को कॉन्फ़िगर करने की अनुमति देता है.

module.exports = {
  images: {
    loader: 'imgix',
    path: 'https://ImgApp/imgix.net',
  },
}

इस कॉन्फ़िगरेशन की मदद से, डेवलपर इमेज सोर्स में रिलेटिव यूआरएल का इस्तेमाल कर सकते हैं. साथ ही, फ़्रेमवर्क, रिलेटिव यूआरएल को सीडीएन पाथ के साथ जोड़कर, सटीक यूआरएल जनरेट करेगा. Imgix, Cloudinary, और Akamai जैसे लोकप्रिय इमेज वाले सीडीएन इस्तेमाल किए जा सकते हैं. यह आर्किटेक्चर, ऐप्लिकेशन के लिए कस्टम loader फ़ंक्शन लागू करके, कस्टम क्लाउड प्रोवाइडर का इस्तेमाल करने की सुविधा देता है.

खुद होस्ट की गई इमेज के साथ काम करना

ऐसा हो सकता है कि वेबसाइटें, इमेज सीडीएन का इस्तेमाल न कर पाएं. ऐसे मामलों में, इमेज कॉम्पोनेंट को खुद होस्ट की गई इमेज के साथ काम करना चाहिए. Next.js इमेज कॉम्पोनेंट, इमेज ऑप्टिमाइज़र का इस्तेमाल, पहले से मौजूद इमेज सर्वर के तौर पर करता है. यह सर्वर, सीडीएन जैसा एपीआई उपलब्ध कराता है. अगर ऑप्टिमाइज़र पर इंस्टॉल किया गया है, तो यह प्रोडक्शन इमेज ट्रांसफ़ॉर्मेशन के लिए शार्प का इस्तेमाल करता है. यह लाइब्रेरी, इमेज ऑप्टिमाइज़ेशन की अपनी पाइपलाइन बनाने वाले लोगों के लिए एक अच्छा विकल्प है.

प्रगतिशील लोडिंग की सुविधा के साथ काम करना

प्रगतिशील लोडिंग एक ऐसी तकनीक है जिसका इस्तेमाल, उपयोगकर्ताओं की दिलचस्पी बनाए रखने के लिए किया जाता है. इसमें, असल इमेज लोड होने के दौरान, प्लेसहोल्डर इमेज दिखाई जाती है. आम तौर पर, यह इमेज बहुत खराब क्वालिटी की होती है. इससे, वेबसाइट की परफ़ॉर्मेंस बेहतर होती है और उपयोगकर्ता अनुभव भी बेहतर होता है. इसका इस्तेमाल, फ़ोल्ड के नीचे वाली इमेज के लिए लेज़ी लोडिंग के साथ किया जा सकता है. इसके अलावा, इसे फ़ोल्ड के नीचे की इमेज के लिए भी इस्तेमाल किया जा सकता है.

Next.js इमेज कॉम्पोनेंट, प्लेसहोल्डर प्रॉपर्टी की मदद से, इमेज के लिए प्रोग्रेसिव लोडिंग की सुविधा देता है. असल इमेज लोड होने के दौरान, खराब क्वालिटी या धुंधली इमेज दिखाने के लिए, इसका इस्तेमाल एलक्यूआईपी (कम क्वालिटी वाली इमेज प्लेसहोल्डर) के तौर पर किया जा सकता है.

असर

इन सभी ऑप्टिमाइज़ेशन को शामिल करने के बाद, हमें प्रोडक्शन में Next.js इमेज कॉम्पोनेंट का इस्तेमाल करके सफलता मिली है. साथ ही, हम मिलते-जुलते इमेज कॉम्पोनेंट पर अन्य टेक्नोलॉजी स्टैक के साथ भी काम कर रहे हैं.

जब Leboncoin ने अपने लेगसी JavaScript फ़्रंटएंड को Next.js पर माइग्रेट किया, तब उन्होंने Next.js इमेज कॉम्पोनेंट का इस्तेमाल करने के लिए, अपनी इमेज पाइपलाइन को भी अपग्रेड किया. <img> से next/image पर माइग्रेट किए गए पेज पर, एलसीपी 2.4 सेकंड से घटकर 1.7 सेकंड हो गया. पेज के लिए डाउनलोड की गई इमेज के कुल बाइट, 663 केबी से 326 केबी हो गए. इसमें, लेज़ी लोड की गई इमेज के 100 केबी बाइट शामिल हैं.

सीखी गई बातें

Next.js ऐप्लिकेशन बनाने वाले किसी भी व्यक्ति को, ऑप्टिमाइज़ेशन के लिए Next.js इमेज कॉम्पोनेंट का इस्तेमाल करने से फ़ायदा हो सकता है. हालांकि, अगर आपको किसी दूसरे फ़्रेमवर्क या सीएमएस के लिए, परफ़ॉर्मेंस के ऐसे ही एब्स्ट्रैक्शन बनाने हैं, तो यहां दिए गए कुछ सबक आपके लिए मददगार हो सकते हैं.

सुरक्षा वाल्व से फ़ायदा होने के बजाय नुकसान ज़्यादा हो सकता है

Next.js इमेज कॉम्पोनेंट के शुरुआती रिलीज़ में, हमने unsized एट्रिब्यूट उपलब्ध कराया था. इसकी मदद से, डेवलपर साइज़ की ज़रूरी शर्त को बायपास कर सकते थे और ऐसे डाइमेंशन वाली इमेज का इस्तेमाल कर सकते थे जिनके डाइमेंशन की जानकारी नहीं दी गई थी. हमें लगा कि यह उन मामलों में ज़रूरी होगा जहां इमेज की ऊंचाई या चौड़ाई को पहले से जानना नामुमकिन था. हालांकि, हमें पता चला है कि उपयोगकर्ताओं ने साइज़ से जुड़ी ज़रूरी शर्तों से जुड़ी समस्याओं को हल करने के लिए, GitHub में unsized एट्रिब्यूट का सुझाव दिया है. ऐसा उन मामलों में भी किया जा सकता है जहां वे समस्या को ऐसे तरीकों से हल कर सकें जिनसे सीएलएस खराब न हो. इसके बाद, हमने unsized एट्रिब्यूट के इस्तेमाल पर रोक लगा दी और उसे हटा दिया.

काम के फ़्रिक्शन को बेमतलब के फ़्रिक्शन से अलग करना

इमेज का साइज़ तय करना, "काम का फ़्रिक्शन" का एक उदाहरण है. इससे कॉम्पोनेंट के इस्तेमाल पर पाबंदी लगती है, लेकिन इसके बदले परफ़ॉर्मेंस में काफ़ी सुधार होता है. अगर उपयोगकर्ताओं को परफ़ॉर्मेंस से जुड़े संभावित फ़ायदों की साफ़ तौर पर जानकारी दी जाती है, तो वे आसानी से पाबंदी को स्वीकार कर लेंगे. इसलिए, कॉम्पोनेंट के बारे में दस्तावेज़ और पब्लिश किए गए अन्य कॉन्टेंट में, इस बदलाव के बारे में बताना ज़रूरी है.

हालांकि, इस तरह की समस्या से निपटने के लिए, परफ़ॉर्मेंस से समझौता किए बिना समाधान ढूंढे जा सकते हैं. उदाहरण के लिए, Next.js इमेज कॉम्पोनेंट के डेवलपमेंट के दौरान हमें ऐसी शिकायतें मिली कि स्थानीय तौर पर सेव की गई इमेज का साइज़ खोजने में परेशानी हो रही थी. हमने स्टैटिक इमेज इंपोर्ट जोड़े हैं. ये Babel प्लग इन का इस्तेमाल करके, बिल्ड के समय स्थानीय इमेज के डाइमेंशन को अपने-आप हासिल करके, इस प्रोसेस को आसान बनाते हैं.

सुविधाओं और परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के बीच संतुलन बनाए रखना

अगर आपका इमेज कॉम्पोनेंट, उपयोगकर्ताओं पर "काम का फ़्रिक्शन" लगाने के अलावा कुछ नहीं करता, तो डेवलपर इसका इस्तेमाल नहीं करना चाहेंगे. हमने पाया कि इमेज का साइज़ तय करने और srcset वैल्यू अपने-आप जनरेट होने जैसी परफ़ॉर्मेंस से जुड़ी सुविधाएं सबसे ज़्यादा अहम थीं. डेवलपर के लिए उपलब्ध सुविधाएं, जैसे कि अपने-आप लेज़ी लोडिंग और पहले से मौजूद धुंधले प्लेसहोल्डर, Next.js Image कॉम्पोनेंट में भी दिलचस्पी बढ़ाने में मदद करते हैं.

सुविधाओं के लिए रोडमैप सेट करें, ताकि उन्हें ज़्यादा से ज़्यादा लोग अपना सकें

एक ऐसा समाधान बनाना जो सभी स्थितियों के लिए पूरी तरह से काम करता हो, बहुत मुश्किल होता है. ऐसा हो सकता है कि आप कुछ ऐसा डिज़ाइन करना चाहें जो 75% लोगों के लिए सही हो. इसके बाद, बाकी 25% लोगों को यह बताएं कि "इन मामलों में, यह कॉम्पोनेंट आपके लिए नहीं है."

असल में, कॉम्पोनेंट डिज़ाइनर के तौर पर, यह रणनीति आपके लक्ष्यों के मुताबिक नहीं होती. आपको डेवलपर को अपना कॉम्पोनेंट इस्तेमाल करने के लिए कहना है, ताकि वे परफ़ॉर्मेंस से जुड़े फ़ायदे पा सकें. अगर कुछ उपयोगकर्ता माइग्रेट नहीं कर पा रहे हैं और उन्हें लगता है कि वे बातचीत से बाहर हैं, तो ऐसा करना मुश्किल हो जाता है. इससे वे आपके ऐप्लिकेशन को इस्तेमाल करने में दिलचस्पी नहीं दिखाएंगे. साथ ही, इसकी वजह से लोगों की राय खराब हो सकती है और ऐप्लिकेशन को अपनाने की संख्या कम हो सकती है.

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

नतीजा

इमेज का इस्तेमाल और ऑप्टिमाइज़ेशन करना मुश्किल है. बेहतरीन उपयोगकर्ता अनुभव देने के साथ-साथ, डेवलपर को इमेज की परफ़ॉर्मेंस और क्वालिटी के बीच संतुलन बनाना होगा. इस वजह से, इमेज ऑप्टिमाइज़ेशन की प्रोसेस में ज़्यादा समय और पैसे लगते हैं.

हमने सबसे सही तरीकों का एक टेंप्लेट बनाया है, ताकि हर ऐप्लिकेशन को हर बार नया तरीका न आज़माना पड़े. डेवलपर, फ़्रेमवर्क, और अन्य टेक्नोलॉजी स्टैक, इस टेंप्लेट का इस्तेमाल अपने ऐप्लिकेशन में इन तरीकों को लागू करने के लिए रेफ़रंस के तौर पर कर सकते हैं. यह अनुभव वाकई अहम साबित होगा, क्योंकि हम दूसरे फ़्रेमवर्क के इमेज कॉम्पोनेंट के साथ काम करते हैं.

Next.js इमेज कॉम्पोनेंट की मदद से, Next.js ऐप्लिकेशन की परफ़ॉर्मेंस को बेहतर बनाया गया है. इससे उपयोगकर्ता अनुभव भी बेहतर हुआ है. हमारा मानना है कि यह एक बेहतरीन मॉडल है, जो बड़े नेटवर्क में भी अच्छा काम करेगा. हम उन डेवलपर से बातचीत करना चाहेंगे जो अपने प्रोजेक्ट में इस मॉडल को अपनाना चाहते हैं.