डेवलपर टूल · Base64 एनकोडर और डिकोडर
CSS में इनलाइन Base64 छवियां: जब डेटा: यूआरआई मदद करते हैं और जब वे चोट पहुंचाते हैं
· यह क्यों मायने रखती है
Base64 प्रदर्शन
एक छवि को Base64 डेटा के रूप में इनलाइन करना: URI एक अनुरोध को हटा देता है लेकिन फ़ाइल को बढ़ाता है और कैशिंग को हरा देता है। यह पोस्ट बताती है कि कब व्यापार इसके लायक है और कब एक अलग फ़ाइल तेज़ होती है।
स्टाइलशीट जो सैकड़ों किलोबाइट तक बढ़ गई - एक टीम की इनलाइनिंग आदत और यह लोड टाइमिंग में कैसे दिखाई देती है
एक विकास टीम ने निर्णय लिया कि उनके CSS में Base64 डेटा: यूआरआई के रूप में छोटे आइकन को इनलाइन करने से HTTP अनुरोध कम हो जाएंगे और पेज लोड गति में सुधार होगा। समय के साथ, जैसे-जैसे अधिक आइकन जोड़े गए, स्टाइलशीट बढ़कर 400 किलोबाइट हो गई।
CSS बंडल, जिसमें शैली नियम शामिल होने चाहिए, अब छवि डेटा पर हावी है। टीम ने लोड टाइमिंग को मापा और पाया कि पेज इनलाइनिंग से पहले की तुलना में धीमा था, तेज़ नहीं। समस्या स्पष्ट हो गई: 400-किलोबाइट स्टाइलशीट प्रत्येक पेज लोड पर डाउनलोड की जाती है और प्रति पेज कैश की जाती है, जबकि यदि आइकन अलग-अलग फ़ाइलें थीं, तो एक एकल आइकन फ़ाइल को कैश किया जाएगा और प्रत्येक पेज पर साझा किया जाएगा।
क्या डेटा है: URI इनलाइन और यह Base64 क्यों है - सिंटैक्स, मीडिया प्रकार और आकार दंड
साइट पर और पेज जोड़ने से समस्या और भी बदतर हो गई, क्योंकि प्रत्येक पेज उन सभी रेखांकित छवियों के साथ एक ही स्टाइलशीट को फिर से डाउनलोड करता है। यह पोस्ट बताती है कि डेटा क्या है: URI, यह Base64 क्यों है, इनलाइनिंग कैशिंग और प्रदर्शन को कैसे प्रभावित करती है, और ट्रेड-ऑफ कब इसके लायक है यह तय करने के लिए सामान्य नियम। डेटा: URL किसी संसाधन को किसी बाहरी फ़ाइल से लिंक करने के बजाय सीधे HTML या CSS फ़ाइल में एम्बेड करने का एक तरीका है। सिंटैक्स डेटा है:मीडियाटाइप;Base64,एनकोडेड_बाइट्स।
mediaType बताता है कि आगे किस तरह का रिसोर्स है, जैसे SVG के लिए image/svg+xml और PNG के लिए image/png तथा टेक्स्ट के लिए text/plain। ;base64 फ़्लैग बताता है कि पेलोड प्रतिशत-एनकोडेड टेक्स्ट के बजाय Base64 में एनकोड है। encoded_bytes असली डेटा है। ब्राउज़र को href, src या background-image प्रॉपर्टी में data: URL मिलने पर वह Base64 डिकोड करके रिसोर्स इनलाइन रेंडर करता है। रिसोर्स मूल डॉक्यूमेंट में पहले से एम्बेड है, इसलिए HTTP रिक्वेस्ट नहीं होती। इससे एक या कुछ HTTP रिक्वेस्ट बचती हैं, जो HTTP/1.1 में हर रिक्वेस्ट के ओवरहेड के कारण मायने रखती हैं।
कैशिंग और महत्वपूर्ण पथ - स्टाइलशीट वाले प्रत्येक पेज के साथ इनलाइन बाइट्स फिर से क्यों डाउनलोड किए जाते हैं
HTTP/2 या HTTP/3 दुनिया में जहां कई अनुरोधों को एक कनेक्शन पर मल्टीप्लेक्स किया जा सकता है, बचत कम होती है। Base64 एन्कोडिंग का आकार दंड तत्काल और महत्वपूर्ण है। एक SVG आइकन जो XML फ़ाइल के रूप में सहेजे जाने पर 3 किलोबाइट का होता है, जब Base64-एन्कोड किया जाता है और डेटा के रूप में एम्बेड किया जाता है तो यह 4 किलोबाइट बन जाता है: URI। एन्कोडिंग से 33% size वृद्धि को स्टाइलशीट वाले प्रत्येक पेज पर जोड़ा जाना चाहिए। यदि आइकन का उपयोग दस पेजों पर किया जाता है, तो स्टाइलशीट दस बार डाउनलोड की जाती है, हर बार उसी 4-किलोबाइट एन्कोडेड छवि को शामिल करते हुए।
यदि आइकन एक अलग फ़ाइल होती, तो 3-किलोबाइट मूल को एक बार डाउनलोड किया जाता और कैश किया जाता, फिर सभी दस पेजों पर कैश से उपयोग किया जाता। अधिकांश आइकनों के लिए आर्थिक विकल्प स्पष्ट है: अलग-अलग फ़ाइलें कुल मिलाकर छोटी होती हैं। इनलाइनिंग लाभ केवल तभी लागू होता है जब किसी आइकन का उपयोग बिल्कुल एक पेज या बहुत कम पेजों पर किया जाता है, और आइकन वास्तव में उस पेज के लिए महत्वपूर्ण होता है। प्रत्येक पेज पर दिखाई देने वाला फ़ेविकॉन इनलाइनिंग के लिए ख़राब उम्मीदवार है; यह एक अलग कैश्ड फ़ाइल के रूप में बेहतर है।
क्लाइंट पर पार्सिंग लागत - CSS और HTML पार्सर्स द्वारा बड़ी इनलाइन स्ट्रिंग्स को कैसे नियंत्रित किया जाता है, गुणात्मक रूप से वर्णित है
किसी अनुरोध को सहेजने के लिए इनलाइनिंग से केवल लैंडिंग पेज पर उपयोग किए जाने वाले एकमुश्त चित्रण से लाभ हो सकता है। कैशिंग इनलाइनिंग डेटा के अधिकांश लाभों को विफल कर देता है: स्टाइलशीट में यूआरआई। एक स्टाइलशीट आमतौर पर दिनों या हफ्तों के लिए कैश की जाती है। जब स्टाइलशीट डाउनलोड की जाती है, तो उसमें शामिल प्रत्येक संसाधन को फिर से डाउनलोड किया जाता है, भले ही ब्राउज़र में वह छवि पहले से ही कैश्ड हो। यदि स्टाइलशीट अद्यतन की जाती है, तो सभी इनलाइन डेटा को पुनः सत्यापित या पुनः डाउनलोड किया जाना चाहिए, भले ही केवल एक CSS नियम बदला गया हो।
यह ब्लोट का कारण बनता है: रंगों या रिक्ति में परिवर्तन से स्टाइलशीट का पूर्ण पुनः डाउनलोड शुरू हो जाता है, जिसमें किलोबाइट छवि डेटा भी शामिल होता है जो नहीं बदला। एक अलग छवि फ़ाइल को अपने स्वयं के समाप्ति हेडर के साथ स्वतंत्र रूप से कैश किया जा सकता है, अलग से अपडेट किया जा सकता है और स्टाइलशीट और पेजों में पुन: उपयोग किया जा सकता है। जब संसाधन बड़े दस्तावेज़ों में एम्बेड किए जाते हैं तो ब्राउज़र कैश कहीं अधिक कुशल होता है जब संसाधन अलग-अलग फ़ाइलें होते हैं। जब बड़ी Base64 स्ट्रिंग्स को स्टाइलशीट में एम्बेड किया जाता है तो पार्सिंग और रेंडरिंग की लागत बढ़ जाती है। नियमों को लागू करने से पहले CSS पार्सर को पूरी स्टाइलशीट पढ़नी होगी।
कारगर उदाहरण: एक छोटे SVG आइकन को टेक्स्ट के रूप में इनलाइन करना - मार्कअप को एनकोडर में चिपकाना और डेटा को असेंबल करना: URI हाथ से
एक 400-किलोबाइट स्टाइलशीट इनलाइन Base64 के साथ 400 किलोबाइट टेक्स्ट है जिसे किसी भी नियम को लागू करने से पहले पार्स किया जाना चाहिए। एक HTML पार्सर एक बड़े डेटा के साथ एक पेज प्रस्तुत करता है: URI एक शैली विशेषता या पेजभूमि-छवि संपत्ति में Base64 को डीकोड करना होगा और तत्व प्रस्तुत करने से पहले छवि का निर्माण करना होगा। सरल SVG आइकन के लिए यह मामूली है। अधिक जटिल छवियों या बड़े आइकनों के लिए, डिकोडिंग और रेंडरिंग मुख्य थ्रेड पर होती है, जो संभावित रूप से अन्तरक्रियाशीलता को अवरुद्ध करती है। गुणात्मक लागत वास्तविक है लेकिन प्रोफाइलिंग के बिना मापना कठिन है।
एक नियम के रूप में, यदि रेखांकित छवि कुछ किलोबाइट से बड़ी है, तो अलग-अलग फ़ाइलें तेज़ होती हैं। एक कार्यशील उदाहरण सटीक व्यापार-बंद दिखाता है। एक साधारण SVG तीर चिह्न, 1.2 किलोबाइट XML लें। Base64-एन्कोडेड यह 1600 वर्ण बन जाता है, या डेटा के साथ लगभग 1.6 किलोबाइट बन जाता है: URL उपसर्ग। बैकग्राउंड-इमेज के साथ एक अलग CSS नियम: url(/icons/arrow.svg) स्टाइलशीट में शायद 40 bytes जोड़ता है। आइकन फ़ाइल को एक बार डाउनलोड किया जाता है, कैश किया जाता है और पुन: उपयोग किया जाता है। इनलाइनिंग उस एक आइकन के लिए एक HTTP अनुरोध सहेजता है लेकिन प्रत्येक स्टाइलशीट लोड में 1.6 किलोबाइट जोड़ता है।
सामान्य नियम जो लागू होते हैं - छोटी, महत्वपूर्ण, एकल-उपयोग वाली संपत्तियाँ इनलाइन; बाकी सब कुछ एक फ़ाइल के रूप में
यदि स्टाइलशीट 50 किलोबाइट है और 20 पेजों पर साझा की जाती है, तो उस आइकन को इनलाइन करने से कुल डाउनलोड 32 किलोबाइट प्रति साइट विज़िट बढ़ जाता है। HTTP अनुरोध जो इसे सहेजता है वह अधिकतम कुछ सौ बाइट्स ओवरहेड है। अनुरोध भी स्वचालित रूप से HTTP/2, में मल्टीप्लेक्स हो जाता है जिससे ओवरहेड अंतर समाप्त हो जाता है। जब तक स्टाइलशीट छोटी न हो, आइकन बड़ा न हो या आइकन बिल्कुल एक पेज पर दिखाई न दे और कहीं और न हो, इनलाइनिंग ट्रेड बुरी तरह से हार जाता है। जांच से बचे रहने वाले सामान्य नियम सीमित और विशिष्ट हैं।
छोटी, महत्वपूर्ण, एकल-उपयोग वाली संपत्तियों को रेखांकित किया जा सकता है। एक 200-बाइट SVG तीर जो केवल एक असामान्य पेज पर दिखाई देता है, अनुरोध ओवरहेड को सहेजने के लिए इनलाइन किया जा सकता है। बाकी सब अलग होना चाहिए. महत्वपूर्ण रेंडरिंग पथ तर्क मायने रखता है: यदि कोई आइकन तुरंत दिखाई देना चाहिए और लोड समय के प्रत्येक मिलीसेकंड में रूपांतरण की लागत होती है, तो इनलाइनिंग जीत सकती है। विशिष्ट आइकन वाले विशिष्ट पेजों के लिए, अलग-अलग फ़ाइलें लगभग हमेशा बेहतर होती हैं। अपनी वास्तविक संपत्तियों के साथ दोनों दृष्टिकोणों का परीक्षण करें और पेज लोड, कैश हिट दर और अनुरोध वॉटरफॉल को मापें।
इसमें क्या शामिल नहीं है - HTTP/2 और HTTP/3 मल्टीप्लेक्सिंग विवरण और छवि-प्रारूप संपीड़न
यह न मानें कि इनलाइनिंग माप के बिना एक अनुकूलन है। एक फूली हुई स्टाइलशीट के साथ समाप्त होने का सबसे आसान तरीका यह मापे बिना वृद्धिशील रूप से इनलाइन करना है कि प्रत्येक जोड़ वास्तव में तेज़ है या नहीं। Base64 एनकोडर और डिकोडर इनलाइनिंग के लिए प्रतिबद्ध होने से पहले आपको यह निर्णय लेने में मदद करता है। अपने SVG मार्कअप या अन्य आइकन स्रोत को टेक्स्ट के रूप में टूल में चिपकाएँ। एनकोड पर क्लिक करें और डेटा जेनरेट करने के लिए विकल्प सेट करें: URI। टूल आपको डेटा की सटीक लंबाई दिखाता है: URL। इसकी तुलना एक अलग CSS नियम और परिसंपत्ति फ़ाइल के आकार से करें।
गणना करें कि इनलाइनिंग बनाम अलग-अलग फ़ाइलों पर संतुलन बनाए रखने के लिए स्टाइलशीट को साझा करने के लिए कितने पेजों की आवश्यकता होगी। डेटा इकट्ठा करें: URI और इसे स्टाइलशीट में डालने से पहले वास्तविक HTML पेज में इसका परीक्षण करें। यदि URI कुछ सौ वर्णों से अधिक लंबा है, तो एम्बेडिंग की लागत अनुरोध को सहेजने के लाभ से अधिक होने की संभावना है। अपने वास्तविक आइकन और संपत्तियों का परीक्षण करने के लिए टूल का उपयोग करें, फिर इनलाइनिंग से पहले और बाद में अपने वास्तविक पेज लोड मेट्रिक्स पर प्रभाव को मापें।
टेकवे: संयम से इनलाइन करें और मापें - कैसे Base64 एनकोडर और डिकोडर आपको SVG मार्कअप को एनकोड करने और आपके प्रतिबद्ध होने से पहले सटीक आकार देखने की सुविधा देता है
इनलाइनिंग के बारे में निष्पादक दृष्टिकोण चयनात्मक होना है। प्रत्येक पेज पर या कई पेजों पर उपयोग किए गए चिह्न अलग-अलग कैश्ड फ़ाइलें हैं। बिल्कुल एक पेज पर उपयोग किए गए या पहले पेंट के लिए वास्तव में महत्वपूर्ण चिह्नों को इनलाइन किया जा सकता है। सामान्य सलाह का पालन करने के बजाय अपनी वास्तविक संपत्तियों और पेजों के लिए व्यापार-बंद को मापें। स्टाइलशीट में जोड़ने से पहले किसी भी इनलाइन एसेट का सटीक आकार देखने के लिए Base64 एनकोडर और डिकोडर का उपयोग करें। आकार दंड वास्तविक है और प्रत्येक पेज दृश्य में कई गुना बढ़ जाता है।
कैशिंग और अनुरोध मल्टीप्लेक्सिंग ने इनलाइनिंग के मूल लाभ को कम महत्वपूर्ण बना दिया है। अधिकांश आधुनिक अनुप्रयोगों के लिए, छोटी स्टाइलशीट और अलग-अलग फ़ाइलों से बेहतर कैश दक्षता अनुरोध ओवरहेड से अधिक होती है। संयम से इनलाइन करें, परिणाम को मापें और अंतर्ज्ञान पर भरोसा करें।