वेब पर मौजूद इमेज का इतिहास

भले ही, आप वेब के लिए डिज़ाइन और डेवलप करने के बारे में अभी सीख रहे हों, लेकिन <img> एलिमेंट के बारे में बहुत कम जानकारी की ज़रूरत होती है. 1993 में Netscape (“मोज़ेक” उस समय) में लॉन्च होने वाला और 1995 में एचटीएमएल एट्रिब्यूट में शामिल किया गया <img>, लंबे समय तक वेब प्लैटफ़ॉर्म में बेहद आसान और अहम भूमिका निभाता है. डेवलपर, src एट्रिब्यूट के साथ एक "सोर्स" इमेज फ़ाइल जोड़ता है. साथ ही, इमेज के रेंडर नहीं हो पाने या सहायक टेक्नोलॉजी किसी विकल्प का अनुरोध करने पर, alt एट्रिब्यूट के साथ टेक्स्ट का विकल्प देता है. यहां से, ब्राउज़र का सिर्फ़ एक ही काम है: इमेज का डेटा पाएं, फिर उसे जल्द से जल्द रेंडर करें.

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

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

रिस्पॉन्सिव लेआउट में इमेज

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

आम तौर पर आप किसी इमेज का अपस्केल नहीं करना चाहेंगे. इसका मतलब है कि <img> को सोर्स इमेज के ओरिजनल साइज़ से बड़े साइज़ में रेंडर करें. दिखाई गई इमेज धुंधली और दानेदार दिखेगी.

img { max-width: 100% } का इस्तेमाल करने का मतलब है कि सुविधाजनक कंटेनर के हिसाब से, इमेज का साइज़ कम या ज़्यादा किया जाएगा. width: 100% को ज़्यादा कठोर सेट करने के उलट, इससे यह भी पक्का होता है कि इमेज का साइज़, स्वाभाविक साइज़ से बड़ा नहीं होगा. लंबे समय तक, इमेज के साथ काम करने के नियमों में बस इतना ही था: ब्राउज़र के लिए समझे जाने वाले फ़ॉर्मैट का इस्तेमाल करें, सही तरीके से कंप्रेस करें, और इमेज को कभी भी ऊपर की ओर स्केल न करें.

हालांकि, यह तरीका विज़ुअल के तौर पर जितना आसान और असरदार था, उतना ही बढ़िया परफ़ॉर्मेंस भी मिला. <img> में, इमेज डेटा के लिए सिर्फ़ एक सोर्स का इस्तेमाल किया जा सकता है. इसलिए, इस तरीके को अपनाने के लिए हमें, बड़े साइज़ की इमेज ऐसेट उपलब्ध करानी होगी. लेआउट में खाली जगह लेने के लिए बनी इमेज जो 300px से 2000px के बीच की किसी भी जगह की हो सकती है. यह उपयोगकर्ता के व्यूपोर्ट के साइज़ पर निर्भर करता है. इसके लिए, ऐसे इमेज सोर्स की ज़रूरत होती है जिसकी चौड़ाई कम से कम 2000px हो. ऐसे उपयोगकर्ता के लिए जो पेज को सिर्फ़ छोटे व्यूपोर्ट के ज़रिए देखता है, उसके लिए सब कुछ उम्मीद के मुताबिक दिखेगा—इमेज का साइज़ ठीक-ठाक होगा. रेंडर किए गए पेज में, बड़े साइज़ की, लेकिन कम साइज़ वाली सोर्स इमेज, किसी सही साइज़ की इमेज से अलग नहीं दिखेगी. हालांकि, वे अब भी 2000px चौड़ी इमेज को ट्रांसफ़र और रेंडर कर रहे होंगे, जिसमें बड़ी मात्रा में बैंडविथ और प्रोसेसिंग पावर का इस्तेमाल किया जा रहा होगा. हालांकि, कोई असल फ़ायदा नहीं होगा.

पहले "Retina" डिवाइस के आने के बाद से, चीज़ें बहुत बिगड़ गई हैं. जैसे, व्यूपोर्ट के साइज़ के साथ-साथ डिसप्ले डेंसिटी भी एक चिंता का विषय बन गया. किसी इमेज सोर्स को ज़्यादा सघनता वाले डिसप्ले के साथ काम करने के लिए, उसकी इंटेंसिक विड्थी की ज़रूरत होती है. आसान शब्दों में कहें, तो दोगुने सघनता वाले डिसप्ले में इमेज को दोगुने इमेज पिक्सल की ज़रूरत होती है, ताकि इमेज को तेज़ी से रेंडर किया जा सके.

यहां डेवलपर फिर से, इमेज को विज़ुअल तौर पर कम करने के लिए, रेंडरिंग इंजन की क्षमता पर भरोसा करने लगे. ब्राउज़र को src में 800px की चौड़ी सोर्स इमेज जोड़कर, फिर यह तय करें कि उसे सीएसएस की मदद से 400px की चौड़ाई में दिखाया जाए. ऐसा करने पर, दोगुने पिक्सल की सघनता पर इमेज रेंडर की जाती है:

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

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