रिक्त छवि। क्या उपयोग करें: Base64 बनाम 1x1 JPEG छवि


12

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

क्योंकि सभी छवियों की data-srcविशेषता है src, W3C मुझे त्रुटियों को दिखाता है।

इस समय मुझे इस समस्या को हल करने के लिए दो विकल्प मिले:

  1. रिक्त 1x1 छवि का url होने के लिए सभी छवियों का प्रारंभिक src
  2. सभी छवियों का प्रारंभिक src डेटा बेस 64 रिक्त छवि होना चाहिए

जब मैं एक रिक्त 1x1 छवि के URL का उपयोग कर रहा हूं, तब (tools.phatt.com के साथ परीक्षण किया गया) यह 1 HTTP अनुरोध दिखाता है। जब मैं डेटा बेस 64 रिक्त छवि का उपयोग कर रहा हूं तो यह पेज पर छवियों की संख्या के रूप में कई अनुरोधों को दिखाता है।

उनमें से कौन सा अधिक कुशल तरीका है, एक वेबसाइट के लिए तेज गति और कम HTTP अनुरोध करता है? (मान लें कि उपयोगकर्ता वेबपेज को 14.4kbps इंटरनेट स्पीड - पहली इंटरनेट स्पीड पर लोड कर रहा है)।

लेकिन SEO के लिए?

क्या कोई और विकल्प है?


8
"जब मैं डेटा बेस 64 रिक्त छवि का उपयोग कर रहा हूं तो यह पेज पर छवियों की संख्या के रूप में कई अनुरोधों को दिखाता है।" - वहाँ कुछ गड़बड़ है? डेटा-यूआरआई का उपयोग करने का पूरा बिंदु यह है कि कोई बाहरी HTTP अनुरोध नहीं है। (केवल उपयोगकर्ता-एजेंट जो डेटा-यूआरआई को नहीं समझते हैं, HTTP अनुरोध को आग लगा सकते हैं।)
MrWhite

यदि रिक्त छवि 1x1 px से बड़ी होगी (मुझे लगता है कि यह है), मैं एक बड़ी पृष्ठभूमि छवि (10x10 px, 100x100 px) की सिफारिश करूंगा क्योंकि प्रतिपादन तेज होगा
तात्यामेली

3
कोई भी उपयोग करें? आप उसी समय डायनामिक रूप से img टैग बना सकते हैं जब आप डेटा-src को src में बदलते हैं। डेटा-src के साथ रिक्त छवि रखने के बजाय, आप छवियों की सूची संग्रहीत कर सकते हैं और आवश्यकता पड़ने पर टैग उत्पन्न कर सकते हैं।
the_lotus

@ प्रिंट जो काम नहीं करता है क्योंकि ब्राउज़र छवियों को डाउनलोड करेगा भले ही वे छिपे हों।
असंतुष्टगीतगत

जो भी आप सामग्री वितरित करने के लिए चुनते हैं, उसे png8 के रूप में एन्कोडिंग करना संभवतः जेपीईजी से अधिक तेज होगा।
सिम्बियन

जवाबों:


12

बेस 64 छवि विकल्प का उपयोग किया जाना चाहिए जहां आपके पास केवल बहुत कम संख्या में चित्र होंगे और आप सर्वर से एक तस्वीर लाने के नेटवर्क ओवरहेड को खत्म करना चाहते हैं। हालाँकि आप जो प्रश्न में संकेत कर रहे हैं उससे मुझे लगता है कि यह बड़ी संख्या में चित्र बना सकता है। इस स्थिति में मैं सर्वर से एक लंबी कैश लाइफ के साथ एक 1px x 1px पारदर्शी छवि का उपयोग करूंगा क्योंकि यह सर्वर से एक बार फिर ब्राउज़र और किसी भी मध्यवर्ती प्रॉक्सी सर्वर में कैश किया जाएगा।

एक उदाहरण के रूप में यह छवि आकार में लगभग 95 बाइट्स होगी ( https://commons.wikimedia.org/wiki/File:1x1.png ), एक बेस 64 एन्कोडेड छवि स्ट्रिंग के लिए आप पाएंगे कि आकार इस चित्र के बराबर होगा। फ़ाइल का आकार लेकिन आपके द्वारा इसमें जोड़े जाने वाले हर एक चित्र के लिए दोहराया जाएगा।

2-5 छवियों के लिए आकार और गति नगण्य होगी और एक पूरे भ्रूण को समाप्त करके सर्वर ट्रैफ़िक को कम करेगा, लेकिन इससे अधिक के लिए पृष्ठ का आकार बहुत बड़ा होना शुरू हो जाएगा जो लोडिंग समय और बदले एसईओ रैंकिंग को प्रभावित करेगा।


6
एक रिक्त बेस 64 छवि में 55 बाइट्स हो सकते हैं data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=:। यदि छवि का URL थोड़ा लंबा है (उदाहरण के लिए: example.com/templates/template-name/files/1x1.png ), बेस 64 छवि की अनुशंसा की जाएगी क्योंकि आप HTTP प्रश्न नहीं बनाते हैं और यह बाइट्स में छोटा होता है छवि URL की तुलना में (पृष्ठ पर प्रत्येक छवि के लिए दोहराया गया) + बाहरी छवि आकार।
NETCreator होस्टिंग

@ NETCreatorHosting-WebDesign आपकी टिप्पणी के लिए धन्यवाद। मैंने बेस 64 छवि और बाहरी छवि का उपयोग करते समय वेबसाइट के आकार की तुलना की, और बेस 64 छवि का उपयोग करते समय आकार छोटा होता है। मैं प्रति पृष्ठ लगभग 40 छवियों का उपयोग कर रहा हूं।
एमएम पीपी

या आप अपनी वेबसाइट के रूट पर छवि अपलोड कर सकते हैं और एक रिश्तेदार यूआरएल का उपयोग कर सकते हैं, इसलिए वेबसाइट बहुत छोटी होगी।
NETCreator होस्टिंग

3
gzip रिपीटिशन का ध्यान रखेगा, इसलिए आपके पेज में 400 बेस -64 इनकोडेड इमेज होने से 400 से ज्यादा URL की इमेजेज पर ज्यादा बैंडविड्थ खर्च नहीं होगी।
user2428118 7:15 पर

3
@ यदि आपका पृष्ठ 25.6 एमबी बड़ा (400 82-बाइट लंबा डेटा यूआरआई के साथ 64kB = 25,568,800 बाइट्स के बीच) है, तो आपको बेस-एनकोडिंग छवियों के 32.8 kB से अधिक के बारे में चिंता करने की बड़ी समस्याएं मिली हैं।
user2428118

5

निश्चित रूप से डेटा URI के साथ जाएं, जब तक कि आपको IE <8. ( ब्राउज़र समर्थन ) के लिए समर्थन की आवश्यकता न हो ।

छोटे छवियों को सीधे HTML में की बहुत सारी एम्बेड जैसे कि यह सीधे उनसे लिंक करने वाली की तुलना में अधिक बैंडविड्थ लगेगा, लेकिन वृद्धि से कम किया जाएगा लग सकता है gzip ; पृष्ठ के आकार में एकमात्र अंतर किसी रिक्त छवि के एक डेटा URI और आपके सर्वर पर छवि के एक URL के बीच लंबाई के अंतर से आएगा । एक खाली GIF 43 बाइट्स जितना छोटा हो सकता है। बेस 64-एनकोडेड, यह 82 बाइट्स है। ऐसा कोई तरीका नहीं है जो कभी भी एक > 500-बाइट HTTP अनुरोध , एक समान आकार की प्रतिक्रिया से भी बदतर प्रदर्शन करने वाला है , और फिर मैं टीसीपी पैकेट आकार और अन्य ओवरहेड को भी ध्यान में नहीं रख रहा हूं।

यहाँ आधार 64-एन्कोडेड 43-बाइट GIF छवि है:

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

एसईओ के लिए, Google साइट के स्रोत कोड पर एक नज़र डालें, उदाहरण के लिए Google समाचार , और खोजें data:image/gif,base64...


आपकी छवि बड़ी है। 55 बाइट संस्करण के लिए ऊपर टिप्पणी की जाँच करें।
यहोशू

1
StackOverflow पर रिपोर्ट किए गए परीक्षणों (मई 2014) के साथ यह उत्तर दिखाता है कि 1px छवियों की बड़ी संख्या (~ 1800) को एम्बेड करना एक ही बाहरी छवि को बार-बार लिंक करने की तुलना में काफी धीमा है । बाहरी छवि को एक बार और कैश करने का अनुरोध किया जाता है, जबकि ब्राउज़र को HTML पार्सिंग प्रक्रिया के हिस्से के रूप में हर डेटा-यूआरआई को अलग से डिकोड करना होगा - यह अड़चन प्रतीत होगी। इससे यह प्रतीत होता है कि डेटा (URI) कम संख्या में (छोटी) छवियों तक सीमित होना चाहिए।
DocRoot

@ जोशुआ हालांकि वह छवि मेरे ब्राउज़र (फ़ायरफ़ॉक्स) में सही ढंग से प्रदर्शित होती है, इसे कुछ अन्य कार्यक्रमों (जैसे पेंट) द्वारा नहीं खोला जा सकता है, इसलिए मैं इसका उपयोग करूंगा।
user2428118

2

इस समय मुझे दो विकल्प मिले, इस समस्या को हल करने के लिए: सभी छवियों का प्रारंभिक src डेटा बेस 64 रिक्त छवि होना चाहिए

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

रिक्त 1x1 छवि का url होने के लिए सभी छवियों का प्रारंभिक src

यह एक ठीक चाल है बशर्ते कि सभी छवि स्लॉटों के लिए रिक्त छवि URL बिल्कुल एक ही URL है और यह HTTP हेडर "कैश-कंट्रोल" में परिभाषित एक लंबा कैश जीवनकाल है। इसके साथ समस्या यह है कि जैसे-जैसे नई छवि फ़ाइलें लोड होती हैं, छवि वर्ग नए आकार में कूद जाएगा, जो उपयोगकर्ता के अनुभव को उतना अद्भुत नहीं बना सकता है।

लगभग सही विचार यह है ...

जब पृष्ठ शुरू होता है, तो निश्चित आकार के बक्से के साथ एक ग्रिड पेश करें जो प्रत्येक छवि को समायोजित कर सकता है। यदि स्क्रीन पर पूरा ग्रिड फिट नहीं है तो यह ठीक है। फिर जावास्क्रिप्ट लोड करें जो HTML लोड होने के बाद निष्पादित होती है, और उस जावास्क्रिप्ट में, एक नया छवि तत्व बनाएं और इसे ग्रिड के प्रत्येक सेल में संलग्न करें फिर छवि के स्रोत को सही छवि फ़ाइल में सेट करें। ऐसा तब तक करें जब तक कि पहली स्क्रीन भर न जाए। फिर जावास्क्रिप्ट के भीतर स्क्रॉलिंग का पता लगाएं और फिर जब स्क्रॉलिंग होती है, तो नई कोशिकाओं के लिए उपरोक्त प्रक्रिया दोहराएं।

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

यदि आप तेज़ मार्ग पर जाना चाहते हैं, तो इसका उपयोग करने के लिए एक टेम्पलेट HTML है। केवल दो अनुरोध किए गए हैं। HTML कोड, और एक छवि। इस कोड में, मुझे लगता है कि शीट से प्रत्येक छवि चौड़ाई में 100 पिक्सेल और ऊंचाई में 200 पिक्सेल है और प्रत्येक छवि पूरी तरह से बिना अंतराल के एक दूसरे के बगल में गठबंधन की गई है।

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

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


2
जब तक आपकी छवियां आकार में आधा गीगाबाइट नहीं होती हैं, तब तक कोई रास्ता नहीं है कि बेस 64-डिकोडिंग एक छवि पर प्रदर्शन पर कोई औसत दर्जे का प्रभाव डालेगा।
user2428118

यह कंप्यूटर सिस्टम पर भी निर्भर करता है। यदि क्लाइंट के पास अभी भी एक पुराने जमाने का कंप्यूटर है जैसे कि पेंटियम 1, तो प्रदर्शन हिट हो सकता है।
माइक

1

छवि, क्योंकि रखरखाव।

मेरे अनुभव में यह छवि का उपयोग करने के लिए बेहतर काम करता है। यह वास्तविक कोड में अधिक स्पष्ट है और याद रखना आसान है। मुझे संदेह है कि आपको एक पारदर्शी छवि के लिए एन्कोडेड स्ट्रिंग याद होगा, और यहां तक ​​कि अगर आप करते हैं, तो आपके succesors / collegaes।
यदि आप कुछ हफ्तों के बाद इस कोड पर वापस आते हैं, तो आपने आधार 64 को माफ़ कर दिया है।

यदि आप छवि का उपयोग करते हैं तो कोड को बनाए रखने के लिए यह एक बहुत बड़ा सिम्पेलेर होगा, न्यूनतम प्रो इस पर भार नहीं करता है।


कई लोग आधार -64 मान उत्पन्न करने के लिए स्क्रिप्ट का उपयोग करते हैं, इसलिए ऐसे मूल्यों को याद रखने की आवश्यकता खिड़की से बाहर है जब तक कि ओपी अपनी वेबसाइट के कोड का प्रतिनिधित्व करने के लिए केवल HTML फ़ाइलों के एक सेट का उपयोग करने के लिए नहीं होता है।
माइक

1

कैसे के बारे में केवल ~ 3 अतिरिक्त बाइट्स, 0 अतिरिक्त http अनुरोध, और 0 अतिरिक्त img src लंबाई (या 0 बिना डेटा-छवि धारक)। क्या आप छवि के लिए रिक्त src का उपयोग कर सकते हैं?

<img src data-src="banannanannas.jpg" />

और अगर उनके पास altटैग हैं तो आप उन्हें त्रुटि / असफल छवि से छिपा सकते हैं:

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

प्रदर्शित करता है: कुछ भी नहीं। ऑल्ट टैग को हैक करने से इमेज प्लेसहोल्डर बॉर्डर से थोड़ी FOUC देरी होती है। शायद यह भी साफ किया जा सकता है।


2
हालांकि एक खाली srcविशेषता अभी भी W3C वैलिडेटर (जो चिंता प्रतीत होती है) में त्रुटियों को फेंक देगी।
MrWhite

@ w3dk हाँ जो बेकार है, लेकिन फिर बहुत कम आधुनिकीकरण गुजरते हैं।
ढपिन

यदि आप W3C नियमों को पास करना चाहते हैं, तो src के लिए कुछ निर्दिष्ट करने की आवश्यकता है, भले ही इसका URL 404 त्रुटि देता हो। मैं छवि के लिए चौड़ाई और ऊंचाई विशेषताओं के मूल्यों को निर्दिष्ट करने की भी सिफारिश करूंगा ताकि उपयोगकर्ता वास्तविक प्लेसहोल्डर्स को लोडिंग प्रक्रिया के माध्यम से आधे रास्ते को बढ़ाने वाले छोटे बक्से के बजाय पहली बार में देखें।
माइक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.