सर्वोत्तम प्रथाओं - केवल आपको आवश्यक सीएसएस डाउनलोड करें, या एक मिनीफिकेशन प्रक्रिया का उपयोग करें?

Question

समग्र साइट के प्रदर्शन में सुधार (डाउनलोड करने और गति प्रदान करने) के संदर्भ में वहाँ के बाद दो सर्वोत्तम प्रथाओं के बीच एक विरोधाभास प्रतीत होता है:

1. केवल नीचे सीएसएस है कि आप के लिए पेज से किया जा रहा जरूरत लाना देखी। (क्योंकि बहुत से सीएसएस नियम धीमे प्रतिपादन का कारण बनते हैं)

2. हमेशा सीएसएस को कम करें और इसे एक फ़ाइल में गठबंधन करें। (क्योंकि अधिक अनुरोध का मतलब धीमी पेज लोड)

अब कहते हैं कि मैं नियम का पालन करने का फैसला 1.

निम्न समस्याओं आए:

क्या होगा यदि 2 पृष्ठों को साझा सीएसएस नियमों की 1 सेट ?

इस मामले में, मुझे उन नियमों को एक अलग फ़ाइल में रखना होगा और दोनों पृष्ठों से उस फ़ाइल को संदर्भित करना होगा।

हालांकि, अगर मैं इन "साझा नियम" का एक बहुत कुछ है करने के लिए शुरू, मैं प्रत्येक पृष्ठ से अलग फ़ाइलों का एक बहुत संदर्भित खत्म हो सकता है, और इस तरह, नियम को तोड़ने 2.

उदाहरण के लिए, पेज एक सीएसएस 1 और 2 पर निर्भर हो सकता है, जबकि पृष्ठ बी और सी दोनों सीएसएस 2 पर निर्भर करते हैं और पेज डी सीएसएस पर निर्भर करता है 1.

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

लेकिन क्या हम प्रत्येक पृष्ठ के लिए सभी सीएसएस को एक अलग प्रति पृष्ठ सीएसएस फ़ाइल में संयोजित करके इस समस्या को हल नहीं कर सकते?

हम कर सकते थे, लेकिन इससे अन्य समस्याएं पैदा होंगी।

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

क्योंकि हमने सीएसएस को पृष्ठ द्वारा संपीड़ित किया है, हमने अनावश्यकताएं होने की अनुमति दी है जहां एक सीएसएस खंड दो या दो से अधिक पृष्ठों द्वारा साझा किया जाता है।

ब्राउजर कैशिंग ब्राउज़र के कारण हमें कोई अच्छा नहीं करता है, प्रत्येक सीएसएस फ़ाइल में एक अलग फ़ाइल नाम होता है, और इस प्रकार एक अलग फ़ाइल है, भले ही उनमें से कुछ में समान सामग्री हो।

तो हमें किस नियम को तोड़ना चाहिए?

एक मैं बंद को पार होता है:

1. आप केवल सीएसएस कि आप पृष्ठ के लिए की जरूरत है देखा जा रहा नीचे लाना चाहिए।

मुझे लगता है कि यह ज्यादा सरल और अधिक कम करें/मेरी साइट के लिए सभी सीएसएस से बाहर नरक गठबंधन, और में एक जाने इसे नीचे लाने के लिए व्यावहारिक है।

प्रदर्शन की समस्याओं इस बना सकता है का सवाल है, मुझे लगता है कि वे निम्नलिखित तथ्यों द्वारा कम कर रहे हैं:

• आधुनिक ब्राउज़रों तेजी से संसाधन सीएसएस नियमों में हो रही है, तो बहुत जल्द इससे कोई फर्क नहीं होगा अगर आपके पास स्मृति में बहुत से नियम हैं जिनका उपयोग नहीं किया जा रहा है।

• अपने सभी सीएसएस कैश्ड गति एक बहुत किसी भी सुधार आप अनावश्यक नियम, जो जा रहे हैं बाहर छोड़ने से लाभ होता है की तुलना में अधिक सुधार होगा होने वैसे भी लोड करने के लिए, उपयोगकर्ता पृष्ठों है कि उन नियमों की आवश्यकता को ब्राउज़ करता है ।

क्या मैं यहां हूँ?

Answer 1

1. आप का उपयोग करना चाहिए Gzip

alt text http://shup.com/Shup/376348/1106472221-My-Desktop.png

http://www.fiftyfoureleven.com/weblog/web-development/css/the-definitive-css-gzip-method

http://paulstamatiou.com/how-to-optimize-your-css-even-more

asp.net के लिए

http://web2asp.net/2009/01/introduction-one-of-big-complaints.html

संपादित करें:

2. और लिखने CSS चयनकर्ताओं का कुशलतापूर्वक

http://code.google.com/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors

http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/

https://developer.mozilla.org/en/Writing_Efficient_CSS

3. और संयोजन

http://rakaz.nl/2006/12/make-your-pages-load-faster-by-combining-and-compressing-javascript-and-css-files.html

RewriteEngine On 
RewriteBase/
RewriteRule ^css/(.*\.css) /combine.php?type=css&files=$1 
RewriteRule ^javascript/(.*\.js) /combine.php?type=javascript&files=$1 

4. जवाब इस सवाल CSS Performance issues

---

मैं प्रत्येक पृष्ठ के लिए कई सीएसएस फ़ाइलों के लिए पसंद नहीं है की से पढ़ें सुझाव । 4-5 सीएसएस फाइलें पर्याप्त हैं।

1. Common.css (with reset and common layout and typography and Form styling) 
2. pagespecific.css (css of home and other landing pages) 
3. print.css 
<---- ie only css --- > 
4. ie6.css 
5. ie7.css 
<--- > 

और सीएसएस से सफेद स्थान को अलग करना एफ़टीपी के माध्यम से संपादन को संपादित करेगा।

यहाँ एक सीएसएस या एकाधिक सीएसएस पर एक अच्छा लेख है http://css-tricks.com/unique-pages-unique-css-files/

Answer 2

वहाँ हमेशा है व्यापार गत। यदि आप स्वयं को कई सीएसएस फाइलें पाते हैं और ऐसी कई निर्भरताएं हैं जो ट्रैकिंग करते हैं कि कौन सी सीएसएस फ़ाइल को उलझाना मुश्किल हो जाता है, तो एक (या दो से अधिक) सीएसएस फाइलें बनाना और उन्हें कम करना बेहतर होगा।उम्मीद है कि आपकी सीएसएस फाइलें पागल नहीं हैं।

Answer 3

यह एक बहुत ही अच्छा दृश्य Mr.Jonathaxxx है ..

हाँ मैं आपसे सहमत हूँ, दोनों बिंदु पर ले ऊपर प्रमुख बिंदु हैं। मेरे एक अपना पहला बिंदु के बारे में टिप्पणी है जो ..

1. आप केवल सीएसएस कि आप पृष्ठ देखी होने के लिए की जरूरत है नीचे लाना चाहिए। (क्योंकि बहुत से सीएसएस नियम प्रतिपादन धीमा कर देते हैं)।

मुझे लगता है कि हम इसे भी प्राप्त कर सकते हैं।

वेब एप्लिकेशन में हमारे पास ऐप्स के सभी दृश्यों के लिए एक आम कंकाल होगा। हम इसे मास्टर पेज कह सकते हैं। हमारे सभी अलग-अलग पेज/विचार इसे से गोद ले रहे हैं। तो सभी पृष्ठों के बीच एक आम रूप और अनुभव है। उस मामले में हम केवल इसके लिए एक स्टाइल शीट क्यों नहीं बना सकते हैं। तो इसे सभी पृष्ठों/विचारों के बीच साझा किया जा सकता है। यह एक लेआउट फ़ाइल हो सकती है।

यह एक सीएसएस फ़ाइल है।

अगला, हम पृष्ठ में नियंत्रण के लिए एक और सीएसएस उत्पन्न कर सकते हैं या हम लेआउट सीएसएस फ़ाइल में नियंत्रण की शैलियों को भी जोड़ सकते हैं।

किसी भी शैलियों के बाद अलग-अलग पेज मिल सकते हैं, हमारे पास उनके लिए एक अलग फ़ाइल हो सकती है। यह एक पृष्ठ के लिए सीएसएस फ़ाइलों की मात्रा में वृद्धि नहीं करेगा। अधिकतम पृष्ठ को 2 या 3 स्टाइल शीट मिलेगी जो पूरी तरह से प्रासंगिक हैं।

[संपादित करें]

डिफ़ॉल्ट सीएसएस फ़ाइल हमेशा कैश्ड किया जाएगा और सभी पृष्ठों आवेदन के/विचारों के बीच में इस्तेमाल किया जाएगा।

Answer 4

हमेशा दोनों मामले मान्य हैं।

आपके समाधान को के साथ अपने costumers बेंचमार्किंग के साथ जाना है।

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

फिर भी, कुछ चीजें आप मदद कर सकते हैं:

• YUI Compressor साथ संपीड़ित सीएसएस
• अपाचे है (या जो भी) deflate अपने सीएसएस फ़ाइलों
• और सबसे की महत्वपूर्ण (मुझे सबसे अच्छा परिणाम देता है) सभी, सुनिश्चित करें कि उपयोगकर्ता को उपयोगकर्ता द्वारा कैश किया गया है!

रखें सीएसएस स्वच्छ

एक बात आप एक साइट पर कई विकासशील रन होने के बाद उपयोगी लग सकती Dust-Me Selectors एक Firefox विस्तार है कि अप्रयुक्त चयनकर्ताओं के लिए अपनी साइट को शामिल किया गया है।

उपयोग चयनकर्ता बुद्धिमानी (गति प्रस्तुत करना!)

शायद सभी चयनकर्ता इंजन सही से जाना .parent div.myclassdiv.parent .myclass तुलना में तेजी से बनाने के लिए छोड़ दिया है। अपने सीएसएस को लिखते समय इसे ध्यान में रखें। यह भी याद रखें कि आईडी की # कक्षाओं की तुलना में बहुत तेज है। इसके अलावा यह सामान्य है, सार्वभौमिक चयनकर्ताओं से बचें, गैर लिंक तत्वों पर न हो, ... Google has a great article उस पर।

उस दौड़ के शीर्ष पर Firefox's Extension - Page Speed जो आपको धीमी चयनकर्ताओं और बहुत कुछ पर एक बहुत विस्तृत जानकारी देता है।

अपाचे अपस्फीति उदाहरणdeflating is smaller than gzipping जेफ तो कृपया अपने ब्लॉग पर हमारे लिए डाल दिया।

LoadModule deflate_module modules/mod_deflate.so 
<FilesMatch "\.(js|css|html|htm|php|xml)$"> 
    SetOutputFilter DEFLATE 
</FilesMatch> 

अपाचे कैशिंग उदाहरण

# Set up caching on media files for 1 month as recommended by page speed 
<FilesMatch "\.(gif|jpg|jpeg|png|swf|js|css)$"> 
    ExpiresDefault A2629744 
    Header append Cache-Control "public, proxy-revalidate" 
    Header append Vary "Accept-Encoding: *" 
</FilesMatch> 

आशा है कि यह मदद करता है!