यह सीएसएस और जावास्क्रिप्ट स्टोर करने के लिए HTML5 स्थानीय भंडारण का उपयोग करने के लिए यथार्थवादी है

Question

अक्सर सीएसएस और जावास्क्रिप्ट को संग्रहीत करने के लिए एचटीएमएल 5 स्थानीय भंडारण का उपयोग करने का विचार है।

उदाहरण के लिए (छद्म कोड):

var load_from_cdn = true;
अगर (स्थानीय भंडारण का पता लगाएं)  
{
  अगर (कैश ऑफ सीएसएस, जेएस पाया गया)
  {
     स्थानीय संग्रहण कैश लोड करें
     load_from_cdn = false;
  }
}
अगर (load_from_cdn)
{
   document.write ( '<script> ...');
}

क्या यह संभव है या यथार्थवादी?

मैं ब्राउज़र कैश के बारे में जानता हूं, अभी भी कुछ हेडर एक्सेस की जाँच होगी,
मुझे लगता है कि कोई HTTP एक्सेस बेहतर नहीं है (मेरी सोच में )

पुनश्च: ऐसा लगता है कि स्थानीय भंडारण केवल कुंजी-मूल्य जोड़ी का समर्थन करता है , क्या कोई इसे साबित कर सकता है?
(कुछ उदाहरणों के साथ सबसे अच्छा)

Comments

: विकिपीडिया जाहिरा तौर पर बहुत अच्छा प्रभाव को यह करने की कोशिश की twitter.com/catrope/status/408018210529615872 twitter.com/catrope/status/408018210529615872/photo/1

— डेव

यह मेरा 2 साल पहले का विचार है ... :)

— ajreal

आपका सवाल पहली बात है जब मैंने इसके बारे में गुगली पाई थी। यहाँ इस बारे में बहुत चर्चा हुई कि यह एक अच्छा विचार था या नहीं, इसलिए मैंने सोचा कि मैं इसके पक्ष में कुछ महत्वपूर्ण सबूत दूंगा!

— डेव

वह तस्वीर भ्रामक है। यदि आप और नीचे स्क्रॉल करते हैं तो आप देख सकते हैं कि भारी गिरावट वास्तव में नहीं थी, क्योंकि स्थानीयकरण कैशिंग से बेहतर था, बल्कि उनके कैशिंग सेटअप में एक बग: " कम शानदार निकला :( ग्राफ़ आंतरिक ट्रैफ़िक का है, ड्रॉप के कारण। लोकलस्टोरेज में कैशिंग बग छिपाना "- twitter.com/catrope/status/40811038259978782400

— जेमी बार्कर

बाहर की जाँच addyosmani.com/basket.js

— xhh

Answer 1

जेएस और सीएसएस को स्टोर करने के लिए स्थानीय भंडारण का उपयोग करना बिल्कुल ठीक है। हालाँकि, स्थानीय संग्रहण में प्रति डोमेन सीमा 5M है। आपको इस रणनीति पर पुनर्विचार करना पड़ सकता है।

डेस्कटॉप वेब के लिए, आप ट्रिक करने के लिए डिफ़ॉल्ट ब्राउज़र कैश का लाभ उठा सकते हैं। बस जेएस और सीएसएस HTTP प्रतिक्रिया सेट करने योग्य होने के लिए सेट करें। यह सरल और आसान है।

मोबाइल वेब के लिए, विलंबता अधिक है। इसलिए, HTTP अनुरोधों को कम करना महत्वपूर्ण है। इसलिए, बाहरी URL में JS & CSS होना इष्टतम है। बेहतर होगा कि JS & CSS इनलाइन हो। यह HTTP अनुरोधों को कम करता है, लेकिन HTML सामग्री को फूला हुआ करता है। फिर क्या? जैसा आपने कहा, स्थानीय भंडारण का उपयोग करें!

जब कोई ब्राउज़र पहली बार साइट पर जाता है, तो JS & CSS को इनलाइन डाला जाता है। JS में दो और नौकरियां भी हैं: 1) स्थानीय भंडारण में JS & CSS; 2) कुकी को ध्वजांकित करने के लिए सेट करें कि जेएस और सीएसएस स्थानीय भंडारण में हैं।

जब ब्राउज़र दूसरी बार साइट तक पहुंचता है, तो सर्वर को कुकी मिल जाती है और पता चलता है कि ब्राउज़र में पहले से ही संबंधित जेएस और सीएसएस है। इसलिए रेंडर एचटीएमएल में जेएस और सीएसएस को स्थानीय भंडारण से पढ़ने के लिए इनलाइन जेएस इनलाइन है और डोम ट्री में डाला जाता है।

यह मूल विचार है कि bing.com मोबाइल संस्करण कैसे बनाया जाता है। उत्पादन में इसे लागू करते समय आपको JS & CSS संस्करण नियंत्रण पर विचार करने की आवश्यकता हो सकती है।

धन्यवाद

Comments

हां, मैं जो सोच रहा हूं उसके काफी करीब हूं।

— अजासत

Google ने पेज स्पीड मॉड के लिए एक मॉड्यूल विकसित किया जो बहुत ही काम करता है। यहाँ वह पृष्ठ है जहाँ वे सामान, बैड और नॉटकोन डेवलपर्स के

— tacone

upvoted, लेकिन wtf इस मामले में "इनलाइन" करता है। "इनलाइन" के 5 अलग-अलग अर्थ हैं।

— अलेक्जेंडर मिल्स

यह वास्तव में डेस्कटॉप के लिए 10MB और मोबाइल के लिए 5MB

— Roko C. Buljan

आपको किसी कुकी की आवश्यकता नहीं है। आप बस पढ़ सकते हैं यदि LocalStorage कुंजी / मान लिए आप देख रहे है प्लस आप (स्पष्ट अमान्यकरण प्रयोजनों के लिए) एक संस्करण प्रदान करनी चाहिए। दूसरी बार साइट एक्सेस होने के बाद भी यह ट्रिक अच्छी है और अगर संपत्ति कैश में नहीं है (किसी कारण के लिए)

— vsync

Answer 2

क्या ब्राउज़र पहले से ही आपके लिए ऐसा नहीं करता है, और शायद बेहतर है?

Comments

एक आशा

— अलेक्जेंडर मिल्स

Answer 3

क्या बात है?

पहले से ही एक अच्छी तरह से स्थापित तकनीक है जिसे क्लाइंट-साइड कैशिंग कहा जाता है। एचटीएमएल 5 स्थानीय भंडारण इस मामले में क्या लाता है कि कैशिंग क्या गायब है?

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

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

---

आपके पहले संपादन के जवाब में (आपका दूसरा संपादन ऑफ-टॉपिक हो रहा है):

मैं ब्राउज़र कैश के बारे में जानकारी रखता हूं, फिर भी कुछ हेडर एक्सेस की जाँच होगी

आपको ब्राउज़र कैशिंग की कुछ समझ की कमी लगती है। इसलिए यह समझना आवश्यक है कि यह कैसे काम करता है पहले, अपने घर-निर्मित कैशिंग तंत्र को लागू करने से पहले । अपने स्वयं के पहिये को तभी पुनर्निर्मित करें जब आप पर्याप्त विद्यमान पहियों को समझते हैं और उनके उपयोग न करने का एक अच्छा कारण है। मेरे प्रश्न के उत्तर के बिंदु 1 को देखें "पहिया को फिर से बंद करना और इसे पछतावा नहीं" ।

HTTP के माध्यम से कुछ डेटा प्रदान करते समय, आप कैश से संबंधित कुछ हेडर निर्दिष्ट कर सकते हैं:

• Last-Modified निर्दिष्ट करता है कि सामग्री कब बदली गई,
• Expiresनिर्दिष्ट करता है कि सामग्री बदलने पर ब्राउज़र को सर्वर से पूछना चाहिए ।

वे दो हेडर ब्राउज़र को इसकी अनुमति देते हैं:

• सामग्री को बार-बार डाउनलोड करने से बचें। यदि Last-Modifiedअंतिम महीने के लिए सेट किया गया है, और सामग्री कुछ घंटों पहले ही आज डाउनलोड की गई थी, तो इसे फिर से डाउनलोड करने की कोई आवश्यकता नहीं है।
• उस तिथि के लिए क्वेरी करने से बचें जहाँ फ़ाइल को अंतिम बार संशोधित किया गया था। यदि Expiresएक कैश इकाई के मई 5 ^वीं , 2014, आप किसी भी GET अनुरोध जारी करने की जरूरत नहीं है न 2011 में, और न ही 2012 या 2013 में, जब से आप जानते हैं कि कैश अप-टू-डेट है।

सीडीएन के लिए दूसरा आवश्यक है। जब Google स्टैक ओवरफ्लो के आगंतुक को JQuery का cdn.sstatic.netकाम करता है या स्टैक ओवरफ्लो द्वारा उपयोग की जाने वाली छवियों या स्टाइलशीट परोसता है, तो वे हर बार नए संस्करण के लिए ब्राउज़र को क्वेरी नहीं करना चाहते हैं। इसके बजाय, वे एक बार उन फ़ाइलों की सेवा कर रहे हैं, जो समाप्ति तिथि को कुछ लंबे समय तक सेट करते हैं, और यह सब है।

उदाहरण के लिए जब मैं स्टैक ओवरफ्लो होम पेज पर आता हूं, तो उसके स्क्रीनशॉट का एक उदाहरण है:

सेवा करने के लिए 15 फाइलें हैं। लेकिन वे सभी 304 Not Modifiedप्रतिक्रियाएं कहां हैं ? आपके पास केवल सामग्री के तीन अनुरोध हैं जो बदल गए हैं। अन्य सभी चीज़ों के लिए, ब्राउज़र किसी भी सर्वर से कोई अनुरोध किए बिना कैश किए गए संस्करण का उपयोग करता है ।

---

निष्कर्ष निकालने के लिए, आपको वास्तव में अपने स्वयं के कैश तंत्र को लागू करने से पहले दो बार सोचने की जरूरत है, और विशेष रूप से एक अच्छा परिदृश्य ढूंढें जहां यह उपयोगी हो सकता है । जैसा कि मैंने अपने उत्तर की शुरुआत में कहा था, मैं केवल एक ही पा सकता हूं: जहां आप जावास्क्रिप्ट का उपयोग कर रहे हैं, उन्हें OMG, के माध्यम से उपयोग करने के लिए eval()। लेकिन इस मामले में, मुझे पूरा यकीन है कि बेहतर दृष्टिकोण हैं जो या तो हैं:

• मानक कैश तकनीकों का उपयोग करके अधिक प्रभावी, या
• बनाए रखने के लिए आसान है।

Comments

इस एक के लिए +1। यह बिल्कुल व्यर्थ है। लगभग सभी मामलों में। कुछ अद्वितीय, हैश-आधारित कुंजी द्वारा कैशिंग बेहतर है।

— शबनम

आप ब्राउज़र कैश के बारे में पूरी तरह से सही नहीं हैं। सभी ब्राउज़र कैश चेकिंग को पास करके एक हार्ड रिफ्रेश होगा।

— अजासत

reinventing the wheel and not regretting itमृत होने की कड़ी है: '(

— एस्लेइजा

बोउसर कैचिंग जितना आप सोच सकते हैं उतना सीधा आगे नहीं है, और न ही यह सभी ब्राउज़रों के अनुरूप है। उदाहरण के लिए, कुछ ब्राउज़र बेतरतीब ढंग से वेब फोंट लोड करने का निर्णय लेते हैं (हेडर की परवाह किए बिना - अभी इस बारे में लेख नहीं पा सकते हैं लेकिन मुझे लगता है कि यह डेव रूपर्ट था जिन्होंने यह खोज की थी)। इसके अलावा, ETAGs ब्राउज को यह जांचने के लिए मजबूर करता है कि क्या कोई संसाधन अपडेट किया गया है ... और कभी-कभी आप ETAG (उदाहरण के लिए Amazon S3) को नहीं हटा सकते हैं - इसलिए यदि आपकी CSS फ़ाइल ETAG हेडर भेजती है, तो यह हमेशा अपडेट के लिए जाँच की जाएगी (304s) अभी भी एक पेलोड हैं)। अनावश्यक अनुरोधों को रोकने के लिए, कस्टम कैशिंग की आवश्यकता है।

— रयान व्हीले

Answer 4

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

इसके अलावा, ब्राउज़र बाहरी संसाधनों को लोड करना शुरू कर सकता है, क्योंकि पेज लोड होना शुरू हो जाता है, इससे पहले कि आप वास्तव में उस पेज में जावास्क्रिप्ट को चलाना शुरू कर सकें, फिर अपने संसाधनों को एचटीएमएल 5 स्थानीय भंडारण से प्राप्त कर सकते हैं।

इसके अलावा, एचटीएमएल 5 लोकल स्टोरेज से लोड करने के लिए आपको वैसे भी पेज में कोड की आवश्यकता होती है, इसलिए अपने सभी जेएस को एक बाहरी, कैचबल जेएस फाइल में डालें।

Answer 5

पहिए को फिर से मजबूत करने के बजाय केवल HTML5 ऑफ़लाइन कार्यक्षमता का उपयोग करें: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html

Answer 6

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

आप हमेशा अपने हाथ से रोल किए गए एचटीएमएल 5 समाधान के लिए ब्राउज़र कैशिंग को बेंचमार्क कर सकते हैं। लेकिन मेरी शर्त यह है कि देशी कैचिंग पैंट को हरा देगी।

Answer 7

लोकलस्टोरेज का उपयोग तेज (एर) है! मेरा टेस्ट दिखाया

• CDN से लोडिंग jQuery: Chrome 268ms , फ़ायरफ़ॉक्स: 200ms
• स्थानीयस्टोर से jQuery लोड हो रहा है: क्रोम 47ms , फ़ायरफ़ॉक्स 14ms

मुझे लगता है कि HTTP अनुरोध को सहेजना पहले से ही एक बड़ा गति लाभ लाता है। यहां पर हर कोई उल्टा दोषी ठहराता है, इसलिए कृपया मुझे गलत साबित करें।

यदि आप मेरे परिणामों का परीक्षण करना चाहते हैं, तो मैंने एक छोटी सी लाइब्रेरी की स्थापना की, जो लोकलस्टोरेज में स्क्रिप्ट को कैश करती है। इसे Github https://github.com/webpgr/cached-webpgr.js पर देखें या नीचे दिए उदाहरण से कॉपी करें।

पूरा पुस्तकालय:

function _cacheScript(c,d,e){var a=new XMLHttpRequest;a.onreadystatechange=function(){4==a.readyState&&(200==a.status?localStorage.setItem(c,JSON.stringify({content:a.responseText,version:d})):console.warn("error loading "+e))};a.open("GET",e,!0);a.send()}function _loadScript(c,d,e,a){var b=document.createElement("script");b.readyState?b.onreadystatechange=function(){if("loaded"==b.readyState||"complete"==b.readyState)b.onreadystatechange=null,_cacheScript(d,e,c),a&&a()}:b.onload=function(){_cacheScript(d,e,c);a&&a()};b.setAttribute("src",c);document.getElementsByTagName("head")[0].appendChild(b)}function _injectScript(c,d,e,a){var b=document.createElement("script");b.type="text/javascript";c=JSON.parse(c);var f=document.createTextNode(c.content);b.appendChild(f);document.getElementsByTagName("head")[0].appendChild(b);c.version!=e&&localStorage.removeItem(d);a&&a()}function requireScript(c,d,e,a){var b=localStorage.getItem(c);null==b?_loadScript(e,c,d,a):_injectScript(b,c,d,a)};

पुस्तकालय बुला रहा है

requireScript('jquery', '1.11.2', 'http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js', function(){
    requireScript('examplejs', '0.0.3', 'example.js');
});

Comments

आपके उपाय अप्रासंगिक हैं। (1) यदि उपयोगकर्ता वेबसाइट पर नया है, तो उसके पास स्थानीय संग्रहण में वैसे भी कोई jQuery नहीं है। (2) यदि, दूसरी ओर, उपयोगकर्ता पहले से ही आपकी वेबसाइट पर गया है, तो उसके पास कैश में jQuery है, जिसका अर्थ है कि इसे CDN से लोड नहीं किया जाएगा। यह एक तीसरे बिंदु की ओर भी जाता है: (3) स्थानीय संग्रहण किसी दिए गए साइट के लिए उचित है, जबकि Google के CDN पर jQuery को कई साइटों द्वारा साझा किया गया है, जिसका अर्थ है कि एक उपयोगकर्ता जो विज़िट किया गया, कहता है, ढेर अतिप्रवाह लेकिन आपकी साइट के लिए नया है जीता यदि आपको jQuery के एक ही संस्करण का उपयोग करना है, तो CDN से jQuery को पुनः लोड करने की आवश्यकता नहीं है।

— आर्सेनी मूरज़ेंको

@ मेनमा शायद यह उपाय ठीक नहीं है, मैं अब इसे देखता हूं, लेकिन ब्राउज़र कैश के लिए काम करने के लिए एक सर्वर को एक अनुरोध भेजने की आवश्यकता होती है, जो तब 304 देता है। इस अनुरोध को फ़ाइल को स्थानीय रूप से सीधे प्राप्त करने की तुलना में अधिक समय लगता है । यदि मैं गलत हूं तो मुझे सही करों।

— चयन करें

@ मेनमा कृपया प्रोग्रामर से टिप्पणियों की भी जांच करें ।stackexchange.com/a/105526/195684 कैश के साथ और भी मुद्दे हैं, ईटीएजी तुलना की तरह जो इस कस्टम कैचिंग को तेज करते हैं

— चयन करें।