CSS मीडिया क्वेरी: एक फाइल अलग फ़ाइलों और गति लोड हो रहा है पर प्रभाव बनाम

Question

एक साइट मैं वर्तमान में style.css और अन्य स्टाइलशीट का एक समूह, 960.css, आदि का उपयोग करें, इस तरह भरी हुई के लिए:

<link rel=​"stylesheet" media=​"screen" href=​"css/​style.css"> 
<link rel=​"stylesheet" media=​"only screen and (max-width:​ 960px)​" href=​"​css/​960.css"​> 
.... 

अब मैं गति के बारे में चिंतित हूं। मुझे पता है कि मैं फ़ाइलों को एक बड़ी फाइल में जोड़ सकता हूं, लेकिन इसका मतलब अप्रासंगिक डेटा भी डाउनलोड करना होगा।

तो मूल रूप से, मेरा प्रश्न है: अनुरोधों की मात्रा को कम करने, या एक उपयोगकर्ता को पारित डेटा की मात्रा को कम करने का बेहतर तरीका क्या है?

Answer 1

यह मूल रूप से आपके सिस्टम के प्रदर्शन के बारे में है।

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

यदि आप उपयोगकर्ता को पास किए गए डेटा की मात्रा को कम करना चाहते हैं - राशि आईएमएचओ समान है क्योंकि टैग सर्वर पर सीएसएस फ़ाइल से पूछताछ करेगा और इसे पार्स/रीड/डाउनलोड करेगा। आईएमएचओ में कोई प्रासंगिक प्रदर्शन मुद्दा नहीं है। आप क्या कर सकते हैं उत्पन्न करने के लिए और "अनावश्यक" सीएसएस फ़ाइल। लेकिन वास्तव में यह छोटा नहीं है :)

Answer 2

तो मूल रूप से, मेरा प्रश्न है: अनुरोधों की मात्रा को कम करने, या एक उपयोगकर्ता को पारित डेटा की मात्रा को कम करने का बेहतर तरीका क्या है?

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

Answer 3

उचित गति लिंक पर अतिरिक्त अनुरोध में शामिल विलंबता और ओवरहेड शायद उस उपयोगकर्ता के लिए कम से कम आवश्यक नहीं है (उम्मीदवार रूप से minified और gzipped) टेक्स्ट डेटा डाउनलोड न करके लाभ से अधिक हो जाएगा उस संकल्प पर पेज प्रदर्शित करने के लिए। कई उपयोगकर्ताओं के लिए यह प्राथमिक प्रदर्शन बाधा साबित होने के तरीके के बारे में अधिक जानकारी के लिए Ilya Grigorik के excellent post on latency देखें।

अतिरिक्त डेटा की विलंबता लागत मोबाइल उपकरणों पर उपयोगकर्ताओं के लिए विशेष रूप से सच होगी (जो उपयोग में नहीं होने पर अपने रेडियो को बचाने में सक्षम होगी), और मोबाइल 2 जी या 3 जी कनेक्शन पर भी अधिक संभावना है जिसमें अपेक्षाकृत अधिक लागत है कनेक्शन स्थापित करना (4 जी स्पष्ट रूप से इस पर काफी सुधार करता है)।

कुंजी, इन सभी चीजों के साथ, परीक्षण और मापना है - लेकिन मैं लगभग निश्चित रूप से उम्मीद करता हूं कि शैलियों को बंडल करना आपके उपयोगकर्ताओं के लिए तेज़ी से साबित होगा। प्रत्येक वैध स्टाइलशीट को न भूलें (where the media query evaluates to true) पृष्ठ के प्रतिपादन को अवरुद्ध कर देगा।

यह भी ध्यान देने योग्य बात है कि इल्या (जो गूगल के लिए काम करता है ताकि पता होना चाहिए) का हवाला देते वेबकिट अभी भी स्टाइलशीट मीडिया क्वेरी कि झूठे लौटने के लिए, एक कम प्राथमिकता के साथ यद्यपि और एक गैर अवरुद्ध ढंग से डाउनलोड करेगा लायक है।

मीडिया क्वेरी झूठी तो स्टाइलशीट nonblocking के रूप में चिह्नित किया गया है करने के लिए मूल्यांकन करता है और एक बहुत कम डाउनलोड प्राथमिकता

और

केवल चेतावनी दी गई है अगर , जैसा कि स्कॉट इंगित करता है, यह है कि ब्राउजर सभी सक्षम स्टाइलशीट डाउनलोड करेगा, भले ही आपके डिवाइस पर स्क्रीन कभी भी टी से अधिक न हो वह [उद्धृत] चौड़ाई

वेबकिट स्रोत पर संक्षेप में देखते हुए ऐसा लगता है कि यह अभी भी होता है स्क्रीन रोटेशन या खिड़की का आकार बदलने के लिए त्वरित प्रतिक्रिया अनुमति देने के लिए प्रतीत होता है, शायद।

// Load stylesheets that are not needed for the rendering immediately with low priority. 

223 ResourceLoadPriority priority = isActive ? ResourceLoadPriorityUnresolved : ResourceLoadPriorityVeryLow; 

224 CachedResourceRequest request(ResourceRequest(document().completeURL(url)), charset, priority); 

225 request.setInitiator(this); 

226 m_cachedSheet = document().cachedResourceLoader()->requestCSSStyleSheet(request); 

इस तरह के प्रश्नों के लिए मैं अत्यधिक High Performance Browser Networking जो आप मुफ्त में ऑनलाइन पढ़ सकते हैं सिफारिश कर सकते हैं।