क्या CSS को हमेशा जावास्क्रिप्ट से पहले करना चाहिए?


897

ऑनलाइन कई स्थानों पर मैंने जावास्क्रिप्ट को सीएसएस से पहले शामिल करने की सिफारिश देखी है। तर्क इस प्रकार है :

जब आपके CSS और JavaScript को ऑर्डर करने की बात आती है, तो आप चाहते हैं कि आपका CSS पहले आए। कारण यह है कि रेंडरिंग थ्रेड में सभी शैली की जानकारी है जो इसे पृष्ठ को रेंडर करने की आवश्यकता है। यदि जावास्क्रिप्ट में पहले शामिल है, तो संसाधनों के अगले सेट पर जारी रखने से पहले जावास्क्रिप्ट इंजन को इसे पार्स करना होगा। इसका मतलब है कि रेंडरिंग थ्रेड पूरी तरह से पृष्ठ नहीं दिखा सकता है, क्योंकि इसमें सभी शैलियों की आवश्यकता नहीं है।

मेरे वास्तविक परीक्षण से कुछ अलग पता चलता है:

मेरा टेस्ट हार्नेस

मैं विभिन्न संसाधनों के लिए विशिष्ट देरी उत्पन्न करने के लिए निम्न रूबी स्क्रिप्ट का उपयोग करता हूं:

require 'rubygems'
require 'eventmachine'
require 'evma_httpserver'
require 'date'

class Handler  < EventMachine::Connection
  include EventMachine::HttpServer

  def process_http_request
    resp = EventMachine::DelegatedHttpResponse.new( self )

    return unless @http_query_string

    path = @http_path_info
    array = @http_query_string.split("&").map{|s| s.split("=")}.flatten
    parsed = Hash[*array]

    delay = parsed["delay"].to_i / 1000.0
    jsdelay = parsed["jsdelay"].to_i

    delay = 5 if (delay > 5)
    jsdelay = 5000 if (jsdelay > 5000)

    delay = 0 if (delay < 0) 
    jsdelay = 0 if (jsdelay < 0)

    # Block which fulfills the request
    operation = proc do
      sleep delay 

      if path.match(/.js$/)
        resp.status = 200
        resp.headers["Content-Type"] = "text/javascript"
        resp.content = "(function(){
            var start = new Date();
            while(new Date() - start < #{jsdelay}){}
          })();"
      end
      if path.match(/.css$/)
        resp.status = 200
        resp.headers["Content-Type"] = "text/css"
        resp.content = "body {font-size: 50px;}"
      end
    end

    # Callback block to execute once the request is fulfilled
    callback = proc do |res|
        resp.send_response
    end

    # Let the thread pool (20 Ruby threads) handle request
    EM.defer(operation, callback)
  end
end

EventMachine::run {
  EventMachine::start_server("0.0.0.0", 8081, Handler)
  puts "Listening..."
}

उपरोक्त मिनी सर्वर मुझे जावास्क्रिप्ट फ़ाइलों (सर्वर और क्लाइंट दोनों) और मनमाने ढंग से सीएसएस देरी के लिए मनमाने विलंब सेट करने की अनुमति देता है। उदाहरण के लिए, http://10.0.0.50:8081/test.css?delay=500मुझे CSS को स्थानांतरित करने में 500 एमएस की देरी होती है।

परीक्षण करने के लिए मैं निम्नलिखित पृष्ठ का उपयोग करता हूं।

<!DOCTYPE html>
<html>
  <head>
      <title>test</title>
      <script type='text/javascript'>
          var startTime = new Date();
      </script>
      <link href="http://10.0.0.50:8081/test.css?delay=500" type="text/css" rel="stylesheet">
      <script type="text/javascript" src="http://10.0.0.50:8081/test2.js?delay=400&amp;jsdelay=1000"></script> 
  </head>
  <body>
    <p>
      Elapsed time is: 
      <script type='text/javascript'>
        document.write(new Date() - startTime);
      </script>
    </p>    
  </body>
</html>

जब मैं पहले CSS को शामिल करता हूं, तो रेंडर करने में पेज को 1.5 सेकंड का समय लगता है:

पहले सीएसएस

जब मैं जावास्क्रिप्ट को पहले शामिल करता हूं, तो रेंडर करने में पेज को 1.4 सेकंड का समय लगता है:

पहले जावास्क्रिप्ट

मुझे क्रोम, फ़ायरफ़ॉक्स और इंटरनेट एक्सप्लोरर में समान परिणाम मिलते हैं। ओपेरा में हालांकि, ऑर्डर देने से कोई फर्क नहीं पड़ता।

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

क्या मुझे कुछ याद आ रहा है, क्या सीएसएस को शामिल करने की सिफारिश जावास्क्रिप्ट से पहले शामिल है सही नहीं है?

यह स्पष्ट है कि हम रेंडर थ्रेड को मुक्त करने के लिए async जोड़ सकते हैं या सेटटाइमआउट का उपयोग कर सकते हैं या जावास्क्रिप्ट कोड को पाद लेख में डाल सकते हैं, या जावास्क्रिप्ट लोडर का उपयोग कर सकते हैं। यहां बिंदु सिर में आवश्यक जावास्क्रिप्ट बिट्स और सीएसएस बिट्स के आदेश के बारे में है।


120
1511 बनाम 1422 एक सांख्यिकीय महत्वपूर्ण अंतर है? वह 6 प्रतिशत है। उल्लेखनीय-से-औसत-मानव प्रदर्शन अंतर के लिए सामान्य सीमा लगभग 20 प्रतिशत है।
जेफ एटवुड

15
मुद्दा यह है कि पुनर्लेखन इस मनमाने ढंग से विलंब को समाप्त करता है, आप अपने इच्छित किसी भी चीज के लिए देरी को निर्धारित कर सकते हैं, यह मुद्दे का सिर्फ एक डेमो है।
सैम केसर

3
क्या आपकी देरी 100ms थी? आपके स्क्रीनशॉट में अंतर 89ms है। अपने URL में यह है delay=400&amp;jsdelay=1000और delay=500जो कहीं नहीं निकट 100ms या 89ms है। मुझे लगता है कि मैं स्पष्ट नहीं हूँ कि आप किस संख्या का उल्लेख कर रहे हैं।
जेफ एटवुड

4
"यदि जावास्क्रिप्ट में पहले शामिल है, तो जावास्क्रिप्ट इंजन को संसाधनों के अगले सेट पर जारी रखने से पहले इसे पार्स करना होगा। इसका मतलब है कि रेंडर थ्रेड पूरी तरह से पृष्ठ नहीं दिखा सकता है, क्योंकि इसमें सभी शैलियों की आवश्यकता नहीं है। । " - यदि जेएस शामिल है तो सिर में है, तो जेएस को निष्पादित किया जाएगा इससे पहले कि पेज शामिल है या नहीं, सीएसएस शामिल है या नहीं।
nnnnnn

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

जवाबों:


712

यह एक बहुत ही दिलचस्प सवाल है। मैंने हमेशा अपने CSS <link href="...">को अपने JS s से पहले रखा है <script src="...">क्योंकि "मैंने एक बार पढ़ा कि यह बेहतर है।" तो, तुम सही हो; यह उच्च समय है जब हम कुछ वास्तविक शोध करते हैं!

मैंने नोड (नीचे कोड) में अपना स्वयं का परीक्षण हार्नेस स्थापित किया। मूल रूप से, मैं:

  • सुनिश्चित करें कि कोई HTTP कैशिंग नहीं था, इसलिए ब्राउज़र को हर बार एक पृष्ठ लोड होने पर एक पूर्ण डाउनलोड करना होगा।
  • वास्तविकता का अनुकरण करने के लिए, मैंने jQuery और H5BP CSS को शामिल किया (इसलिए इसमें स्क्रिप्ट / सीएसएस को पार्स करने के लिए एक सभ्य राशि है)
  • स्क्रिप्ट से पहले सीएसएस के साथ दो पृष्ठ सेट करें - एक स्क्रिप्ट के बाद सीएसएस के साथ।
  • रिकॉर्ड किया गया कि बाहरी स्क्रिप्ट <head>को निष्पादित करने में कितना समय लगा
  • रिकॉर्ड किया गया कि इनलाइन स्क्रिप्ट <body>को निष्पादित करने में कितना समय लगा , जो अनुरूप है DOMReady
  • 500ms तक ब्राउज़र को सीएसएस और / या स्क्रिप्ट भेजने में देरी।
  • 3 प्रमुख ब्राउज़रों में 20 बार परीक्षण चला।

परिणाम

सबसे पहले, सीएसएस फ़ाइल 500ms देरी से:

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 583ms  36ms  | 559ms  42ms  | 565ms 49ms
St Dev      | 15ms   12ms  | 9ms    7ms   | 13ms  6ms
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 584ms  521ms | 559ms  513ms | 565ms 519ms
St Dev      | 15ms   9ms   | 9ms    5ms   | 13ms  7ms

अगला, मैंने CSS के बजाय 500ms देरी से jQuery सेट किया:

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 597ms  556ms | 562ms  559ms | 564ms 564ms
St Dev      | 14ms   12ms  | 11ms   7ms   | 8ms   8ms
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 598ms  557ms | 563ms  560ms | 564ms 565ms
St Dev      | 14ms   12ms  | 10ms   7ms   | 8ms   8ms

अंत में, मैंने 500 सेकंड तक देरी करने के लिए jQuery और CSS दोनों को सेट किया:

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 620ms  560ms | 577ms  577ms | 571ms 567ms
St Dev      | 16ms   11ms  | 19ms   9ms   | 9ms   10ms
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 623ms  561ms | 578ms  580ms | 571ms 568ms
St Dev      | 18ms   11ms  | 19ms   9ms   | 9ms   10ms

निष्कर्ष

सबसे पहले, यह नोट करना महत्वपूर्ण है कि मैं इस धारणा के तहत काम कर रहा हूं कि आपके पास <head>आपके दस्तावेज़ की स्क्रिप्ट्स हैं (जैसा कि अंत के विपरीत है <body>)। <head>दस्तावेज़ के अंत में आप अपनी स्क्रिप्ट से लिंक क्यों कर सकते हैं, इस बारे में विभिन्न तर्क हैं , लेकिन यह इस उत्तर के दायरे से बाहर है। यह इस बारे में कड़ाई से है कि <script>s को <link>s से पहले जाना चाहिए या नहीं <head>

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

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

क्यों?

ऐतिहासिक रूप से, जब किसी ब्राउज़र को <script>बाहरी संसाधन की ओर इशारा करते हुए एक टैग का सामना करना पड़ता है , तो ब्राउज़र HTML को पार्स करना बंद कर देगा , स्क्रिप्ट को पुनर्प्राप्त करेगा, इसे निष्पादित करेगा, फिर HTML को पार्स करना जारी रखेगा। इसके विपरीत, यदि ब्राउज़र को <link>बाहरी स्टाइलशीट के लिए सामना करना पड़ा, तो यह CSS फ़ाइल (समानांतर में) लाने के दौरान HTML को पार्स करना जारी रखेगा

इसलिए, पहले से स्टाइलशीट लगाने के लिए व्यापक रूप से दोहराया सलाह - वे पहले डाउनलोड करेंगे, और डाउनलोड करने के लिए पहली स्क्रिप्ट समानांतर में लोड की जा सकती है।

हालांकि, आधुनिक ब्राउज़र (ऊपर ब्राउज़ किए गए सभी ब्राउज़रों सहित) ने सट्टा पार्सिंग को लागू किया है , जहां ब्राउज़र HTML में "आगे दिखता है" और स्क्रिप्ट डाउनलोड करने और निष्पादित करने से पहले संसाधन डाउनलोड करना शुरू कर देता है।

सट्टा पार्सिंग के बिना पुराने ब्राउज़रों में, स्क्रिप्ट डालने से पहले प्रदर्शन प्रभावित होगा क्योंकि वे समानांतर में डाउनलोड नहीं करेंगे।

ब्राउज़र का समर्थन

सट्टाबाजी को पहली बार लागू किया गया था: (इस संस्करण का उपयोग करने वाले दुनिया भर के डेस्कटॉप ब्राउज़र उपयोगकर्ताओं के प्रतिशत के साथ या जनवरी 2012 तक)

  • Chrome 1 (WebKit 525) (100%)
  • IE 8 (75%)
  • फ़ायरफ़ॉक्स 3.5 (96%)
  • सफारी 4 (99%)
  • ओपेरा 11.60 (85%)

कुल मिलाकर, आज उपयोग में आने वाले लगभग 85% डेस्कटॉप ब्राउज़र सट्टा लोडिंग का समर्थन करते हैं। CSS के पहले स्क्रिप्ट डालने से विश्व स्तर पर 15% उपयोगकर्ताओं पर प्रदर्शन जुर्माना होगा ; आपकी साइट के विशिष्ट दर्शकों के आधार पर YMMV। (और याद रखें कि संख्या सिकुड़ रही है।)

मोबाइल ब्राउज़र पर, मोबाइल ब्राउज़र और OS परिदृश्य कितना विषम है, इसकी वजह से निश्चित संख्या में प्राप्त करना थोड़ा कठिन है। चूंकि सट्टा प्रतिपादन WebKit 525 (मार्च 2008 को रिलीज़) में लागू किया गया था, और बस हर सार्थक मोबाइल ब्राउज़र WebKit पर आधारित है, हम यह निष्कर्ष निकाल सकते हैं कि "सबसे" मोबाइल ब्राउज़र को इसका समर्थन करना चाहिएQuirksmode के अनुसार , iOS 2.2 / Android 1.0 WebKit 525 का उपयोग करता है। मुझे नहीं पता कि विंडोज फोन कैसा दिखता है।

हालांकि, मैंने अपने एंड्रॉइड 4 डिवाइस पर परीक्षण चलाया, और जब मैंने डेस्कटॉप परिणामों के समान संख्या देखी, तो मैंने इसे एंड्रॉइड के लिए क्रोम में शानदार नए रिमोट डिबगर तक झुका दिया , और नेटवर्क टैब ने दिखाया कि ब्राउज़र वास्तव में डाउनलोड होने की प्रतीक्षा कर रहा था सीएसएस जब तक जावा स्क्रिप्ट पूरी तरह से लोड नहीं किया जाता है - दूसरे शब्दों में, यहां तक ​​कि एंड्रॉइड के लिए वेबकिट का नवीनतम संस्करण भी सट्टा पार्सिंग का समर्थन नहीं करता है। मुझे संदेह है कि मोबाइल उपकरणों में निहित सीपीयू, मेमोरी और / या नेटवर्क बाधाओं के कारण इसे बंद किया जा सकता है।

कोड

धीमेपन को क्षमा करें - यह प्रश्नोत्तर था।

app.js

var express = require('express')
, app = express.createServer()
, fs = require('fs');

app.listen(90);

var file={};
fs.readdirSync('.').forEach(function(f) {
    console.log(f)
    file[f] = fs.readFileSync(f);
    if (f != 'jquery.js' && f != 'style.css') app.get('/' + f, function(req,res) {
        res.contentType(f);
        res.send(file[f]);
    });
});


app.get('/jquery.js', function(req,res) {
    setTimeout(function() {
        res.contentType('text/javascript');
        res.send(file['jquery.js']);
    }, 500);
});

app.get('/style.css', function(req,res) {
    setTimeout(function() {
        res.contentType('text/css');
        res.send(file['style.css']);
    }, 500);
});


var headresults={
    css: [],
    js: []
}, bodyresults={
    css: [],
    js: []
}
app.post('/result/:type/:time/:exec', function(req,res) {
    headresults[req.params.type].push(parseInt(req.params.time, 10));
    bodyresults[req.params.type].push(parseInt(req.params.exec, 10));
    res.end();
});

app.get('/result/:type', function(req,res) {
    var o = '';
    headresults[req.params.type].forEach(function(i) {
        o+='\n' + i;
    });
    o+='\n';
    bodyresults[req.params.type].forEach(function(i) {
        o+='\n' + i;
    });
    res.send(o);
});

css.html

<!DOCTYPE html>
<html>
    <head>
        <title>CSS first</title>
        <script>var start = Date.now();</script>
        <link rel="stylesheet" href="style.css">
        <script src="jquery.js"></script>
        <script src="test.js"></script>
    </head>
    <body>
        <script>document.write(jsload - start);bodyexec=Date.now()</script>
    </body>
</html>

js.html

<!DOCTYPE html>
<html>
    <head>
        <title>CSS first</title>
        <script>var start = Date.now();</script>
        <script src="jquery.js"></script>
        <script src="test.js"></script>
        <link rel="stylesheet" href="style.css">
    </head>
    <body>
        <script>document.write(jsload - start);bodyexec=Date.now()</script>
    </body>
</html>

test.js

var jsload = Date.now();


$(function() {
    $.post('/result' + location.pathname.replace('.html','') + '/' + (jsload - start) + '/' + (bodyexec - start));
});

jquery.js jquery-1.7.1.min.js था


137
यह एक शानदार जवाब है, विज्ञान का उपयोग करने के लिए धन्यवाद ! आपके परिणाम के अनुसार "आधुनिक ब्राउज़रों में, यह ऐसा लगता है कि सीएसएस से लिंक करना पहले कभी कोई प्रदर्शन हासिल नहीं करता है" , मुझे लगता है कि प्रश्न शीर्षक का उत्तर हां है , सीएसएस की पुरानी सलाह पहले स्पष्ट रूप से अमान्य है।
जेफ एटवुड

मोबाइल पर व्युत्क्रम के बारे में @ josh3736 के अपडेट के बारे में ... यह इस महत्वपूर्ण बदलाव पर बंदूक नहीं कूदने का एक मामला है। मुझे उत्सुकता होगी कि मोबाइल में प्रदर्शन के रूप में अन्य मोबाइल ब्राउज़र कैसे व्यवहार करते हैं (वेबकिट, गेको, प्रेस्टो, ट्रिडेंट, आदि) अक्सर अधिक महत्वपूर्ण होता है।
स्क्यूलिफ

1
आपको धीमे सर्वर की गति का अनुकरण करने के लिए सीएसएस / जेएस को प्रिंट करने के लिए कुछ सुस्ती को जोड़ने का भी प्रयास करना चाहिए।
21

1
"सबसे पहले, यह नोट करना महत्वपूर्ण है कि मैं इस धारणा के तहत काम कर रहा हूं कि आपके पास <head>आपके दस्तावेज़ की स्क्रिप्ट्स हैं (जैसा कि अंत के विपरीत है <body>)।" मुझे लगता है कि लोगों का ध्यान जाएगा बहुत जवाब में पहले, शीर्ष पर की तरह। एक भी शामिल है scriptमें headहै कि संदर्भित करता है के लिए एक बाहरी फ़ाइल लगभग कभी नहीं सही है, लगभग किसी भी परिप्रेक्ष्य (निश्चित रूप से एक प्रदर्शन एक नहीं) से। मुझे याद नहीं है कि वास्तविक जीवन में कभी ऐसा करना पड़ा हो। विषम रेखा या दो इनलाइन लिपि शायद, लेकिन यह सब है। डिफ़ॉल्ट, बहुत अच्छे विपरीत कारणों के बिना , शरीर का अंत होना चाहिए।
टीजे क्राउडर

1
डाउन-वोटेड, jQuery जावास्क्रिप्ट नहीं है और यह केवल पृष्ठ को और अधिक प्रस्फुटित करता है इसलिए इसका उपयोग करने के परिणाम उद्देश्यपूर्ण नहीं हैं।
जॉन

303

सीएसएस को जावास्क्रिप्ट से पहले डालने के दो मुख्य कारण हैं।

  1. पुराने ब्राउज़र (इंटरनेट एक्सप्लोरर 6-7, फ़ायरफ़ॉक्स 2, आदि) सभी बाद के डाउनलोड को अवरुद्ध कर देंगे जब उन्होंने एक स्क्रिप्ट डाउनलोड करना शुरू किया। तो अगर आप a.jsद्वारा पीछा किया हैb.css क्रमिक रूप से डाउनलोड किया है: तो पहले एक बी। यदि आपने इसके b.cssबाद a.jsसमानांतर में डाउनलोड किया है तो पृष्ठ अधिक तेज़ी से लोड होता है।

  2. जब तक सभी शैलियों को डाउनलोड नहीं किया जाता है तब तक कुछ भी नहीं गाया जाता है - यह सभी ब्राउज़रों में सच है। स्क्रिप्ट अलग-अलग हैं - वे स्क्रिप्ट टैग के नीचे स्थित सभी DOM तत्वों के प्रतिपादन को रोकते हैं जो पृष्ठ में । यदि आप अपनी स्क्रिप्ट्स को हेड में रखते हैं तो इसका मतलब है कि पूरे पेज को सभी स्टाइलशीट और सभी स्क्रिप्ट डाउनलोड होने तक रेंडर करने से रोक दिया गया है। हालांकि यह स्टाइलशीट के लिए सभी रेंडरिंग को ब्लॉक करने के लिए समझ में आता है (इसलिए आप पहली बार सही स्टाइल प्राप्त करें और अनस्टिल्ड कंटेंट FOUC के फ्लैश से बचें), यह स्क्रिप्ट के लिए पूरे पेज के रेंडरिंग को ब्लॉक करने का कोई मतलब नहीं है। अक्सर स्क्रिप्ट किसी भी DOM तत्वों या DOM तत्वों के एक हिस्से को प्रभावित नहीं करती हैं। संभव है कि स्क्रिप्ट को पेज में जितना कम लोड किया जाए, या बेहतर तरीके से उन्हें अतुल्यकालिक रूप से लोड किया जाए।

क्यूजिलियन के साथ उदाहरण तैयार करना मजेदार है । उदाहरण के लिए, इस पृष्ठ की HEAD में एक स्क्रिप्ट है इसलिए पूरा पृष्ठ खाली है जब तक कि इसे डाउनलोड नहीं किया जाता है। हालाँकि, अगर हम स्क्रिप्ट को BODY के अंत में ले जाते हैं तो पृष्ठ शीर्षलेख रेंडर करते हैं क्योंकि SCRIPT टैग के ऊपर उन DOM तत्व होते हैं, जैसा कि आप इस पृष्ठ पर देख सकते हैं ।


10
सम्मानित स्टीव ने मुझे जवाब देने के लिए हराया, लेकिन मैं एक लेख जोड़ूंगा, जिसमें
जुआन पाब्लो बरिटिका

4
देखें कि कौन से ब्राउज़र उस asyncविशेषता का समर्थन करते हैं, जो स्टीव यहाँ सिफारिश कर रहा है जब वह कहता है कि "इससे भी बेहतर उन्हें अतुल्यकालिक रूप से लोड करता है" - stackoverflow.com/questions/1834077/…
जेफ एटवुड

अरे आप मुझे बता सकते हैं कि सीएसएस फाइलों को कोई भी @importनिर्देश के साथ क्यों लिंक करेगा ?
जोश स्टोडोला

6
2 के लिए स्रोत क्या है), और अगर यह सच है, तो क्या आप बता सकते हैं कि क्यों मौके पर एक पेज सामग्री लोड करना समाप्त कर देगा, फिर सीएसएस एक दूसरे या दो बाद में लागू किया जाता है? (ऐसा शायद ही कभी हुआ हो, मेरे अपने पन्नों पर जहां सीएसएस <head> टैग्स में था)
इज़काता

2
तो हमें पेज के अंत में jQuery+ jQuery UI+ लगाना चाहिए $(document).ready(function () { });? क्या यह हमेशा उम्मीद के मुताबिक काम करेगा ?
ओलिवियर पोंस

42

आपके द्वारा प्राप्त परिणामों पर मैं बहुत अधिक जोर नहीं दूंगा, मेरा मानना ​​है कि यह व्यक्तिपरक है, लेकिन मेरे पास आपको समझाने का एक कारण है कि js से पहले CSS में डालना बेहतर है।

आपकी वेबसाइट के लोडिंग के दौरान, दो परिदृश्य हैं जिन्हें आप देखेंगे:

मामले 1: सफेद स्क्रीन> अस्थिर वेबसाइट> स्टाइल वेबसाइट> इंटरैक्शन> स्टाइल और इंटरैक्टिव वेबसाइट

CASE 2: व्हाइट स्क्रीन> अस्थिर वेबसाइट> इंटरैक्शन> स्टाइल वेबसाइट> स्टाइल और इंटरैक्टिव वेबसाइट।


मैं ईमानदारी से किसी को चुनने के मामले में कल्पना नहीं कर सकता - इसका मतलब यह होगा धीमे इंटरनेट कनेक्शन का उपयोग करने वाले आगंतुकों को एक अस्थिर वेबसाइट के साथ सामना करना पड़ेगा, जो उन्हें जावास्क्रिप्ट (जो पहले से लोड है) का उपयोग करके इसके साथ बातचीत करने की अनुमति देता है। इसके अलावा, एक अस्थिर वेबसाइट को देखने के लिए समय की राशि इस तरह अधिकतम होगी। कोई ऐसा क्यों चाहेगा?

यह jQuery राज्यों के रूप में भी बेहतर काम करता है

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

जब फ़ाइलें गलत क्रम में लोड की जाती हैं (पहले JS, फिर CSS), CSS फाइलों में सेट की गई संपत्तियों पर निर्भर कोई भी जावास्क्रिप्ट कोड (उदाहरण के लिए एक div की चौड़ाई या ऊंचाई) सही तरीके से लोड नहीं किया जाएगा। ऐसा लगता है कि गलत लोडिंग ऑर्डर के साथ, सही गुण 'कभी-कभी' जावास्क्रिप्ट के लिए जाने जाते हैं (शायद यह एक जाति की स्थिति के कारण होता है?)। यह प्रभाव उपयोग किए गए ब्राउज़र के आधार पर बड़ा या छोटा लगता है।


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

@Jonnio यदि आपके JS पर निर्भरता है, तो आपको उस निर्भरता को स्पष्ट करना चाहिए। अन्यथा, आपके पास हमेशा दुर्लभ समयावधि होगी। ईएस 6 मॉड्यूल ऐसा करने का एक अच्छा तरीका है, लेकिन कई पुस्तकालय हैं जिनका उपयोग भी किया जा सकता है।
किमीकम्प

26

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

नियम में "शीर्ष पर स्टाइलशीट और नीचे स्क्रिप्ट रखें" का उद्देश्य, सामान्य तौर पर, यह इष्टतम प्रगतिशील प्रतिपादन प्राप्त करने का सबसे अच्छा तरीका है । जो उपयोगकर्ता के अनुभव के लिए महत्वपूर्ण है।

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


1
मैं उस बिंदु की सराहना करता हूं जो आप बोल्ड कर रहे हैं, लेकिन ओपी इस बारे में बात कर रहा है कि क्या होता है जब आप शीर्ष पर दोनों के साथ क्रम बदलते हैं , न ही नीचे।
nnnnnn

1
इस प्रकार, "मान लेना [उसका] परीक्षण वैध है।"
स्किपर

21

मैं एक अलग कारण के लिए जावास्क्रिप्ट से पहले सीएसएस फाइलें शामिल करता हूं।

अगर मेरे जावास्क्रिप्ट को कुछ पेज एलिमेंट के डायनामिक साइज़िंग करने की ज़रूरत है (उन कॉर्नर के मामलों के लिए, जहाँ CSS वास्तव में एक मुख्य है) तो JS लोड होने के बाद CSS लोड करना रेस की स्थिति पैदा कर सकता है, जहाँ सीएसएस स्टाइल से पहले एलिमेंट का आकार बदल दिया जाता है। लागू होते हैं और इस तरह से अजीब लगते हैं जब शैली अंततः किक करती है। अगर मैं सीएसएस पहले से लोड करता हूं तो मैं गारंटी दे सकता हूं कि चीजें इच्छित क्रम में चलती हैं और अंतिम लेआउट वह है जो मैं चाहता हूं कि यह हो।


2
यह कुछ ब्राउज़र पर एक दिन टूट जाएगा। मैं अनुमान नहीं लगा रहा हूं।
jcolebrand

1
jcolebrand: हाँ, मुझे लगता है कि जब मैंने यह लिखा था तो मैंने पर्याप्त कॉफी नहीं पी थी। (रेट्रोस्पेक्ट में, मुझे लगता है कि सीएसएस के गतिशील लोडिंग से बचने के लिए महत्वपूर्ण बातें हैं और यदि आपको डायनामिक साइज़िंग करने की आवश्यकता है तो जेएस को एक डोमराइड इवेंट के अंदर डाल दें)
hugomg

लिपियों को किसी भी प्रदर्शन को नहीं बदलना चाहिए। यह सीएसएस काम है। HTML = सामग्री, CSS = सामग्री को कैसे प्रदर्शित करें, जावास्क्रिप्ट गतिशील रूप से सामग्री को बदलते हैं। इसके अलावा js को केवल (या जबकि) DOMContentLoaded को कुछ छोटी लेकिन बहुत विशिष्ट स्थितियों के साथ निकाल दिया जाना चाहिए।
ब्रूनोइस

@brunoais: कुछ लेआउट केवल जावास्क्रिप्ट के साथ ही बनाए जा सकते हैं। उदाहरण के लिए, जिस चीज़ को गतिशील रूप से आकार देने की आवश्यकता होती है, उसे जावास्क्रिप्ट के माध्यम से बनाया जाना चाहिए और कुछ चीजें (जैसे आकार 100% होना चाहिए - 20px) पुराने ब्राउज़रों में जावास्क्रिप्ट को आंशिक रूप से करने की आवश्यकता होती है।
हुगोमग

@missingno उन मामलों में, वैसे भी DOMContentLoaded घटना का उपयोग करें। लेकिन मैं समझता हूं कि आपका क्या मतलब है। (बेवकूफ आईई!)
ब्रूनोइस

10

क्या जावास्क्रिप्ट को अमान्य करने से पहले CSS को शामिल करने की सिफारिश की गई है?

यदि आप इसे केवल एक सिफारिश के रूप में मानते हैं। लेकिन अगर आपका व्यवहार इसे एक कठिन और तेज़ नियम के रूप में मानता है, तो, यह अमान्य है।

से https://developer.mozilla.org/en-US/docs/Web/Reference/Events/DOMContentLoaded

स्टाइल्सशीट लोड स्क्रिप्ट के निष्पादन को रोकती है , इसलिए यदि आपके पास एक पृष्ठ <script> होने के बाद <link rel="stylesheet" ...>पार्सिंग समाप्त नहीं होगी - और DOMContentLoaded फायर नहीं करेगी - जब तक कि स्टाइलशीट लोड न हो जाए।

ऐसा प्रतीत होता है कि आपको यह जानने की आवश्यकता है कि प्रत्येक स्क्रिप्ट किस पर निर्भर करती है और यह सुनिश्चित करती है कि स्क्रिप्ट का निष्पादन सही पूर्ण होने के बाद तक देरी हो। यदि स्क्रिप्ट केवल DOM पर निर्भर करती है, तो यह ondomready / domcontentloaded में फिर से शुरू हो सकता है, अगर यह लोड होने के लिए छवियों पर निर्भर करता है या स्टाइलशीट को लागू करने के लिए है, तो अगर मैं उपरोक्त संदर्भ को सही ढंग से पढ़ता हूं, तो उस कोड को ऑनलोड घटना तक स्थगित किया जाना चाहिए।

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

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

यह प्रश्न विशेष रूप से वेब साइटों पर लगाए जा रहे सभी विज्ञापनों पर लागू होता है। अगर साइट लेखकों ने विज्ञापन सामग्री के लिए सिर्फ प्लेसहोल्डर डिविज़ को प्रस्तुत किया है तो मुझे यह पसंद आएगा और यह सुनिश्चित करना होगा कि किसी ऑनलोड घटना में विज्ञापनों को इंजेक्ट करने से पहले उनकी साइट लोड और इंटरेक्टिव हो। तब भी मैं विज्ञापनों को एक साथ देखने के बजाय क्रमबद्ध रूप से लोड करना चाहूंगा क्योंकि वे मेरी सामग्री को साइट की सामग्री को स्क्रॉल करने की क्षमता को प्रभावित करते हैं जबकि फूला हुआ विज्ञापन लोड हो रहा है। लेकिन यह सिर्फ एक व्यक्ति की बात है।

  • अपने उपयोगकर्ताओं को जानें और उनका क्या मूल्य है।
  • अपने उपयोगकर्ताओं को जानें और वे किस ब्राउज़िंग वातावरण का उपयोग करते हैं।
  • पता करें कि प्रत्येक फ़ाइल क्या करती है, और इसके पूर्व आवश्यक क्या हैं। सब कुछ बनाने से गति और सुंदर दोनों पर पूर्वता होगी।
  • ऐसे उपकरण का उपयोग करें जो आपको विकसित करते समय नेटवर्क टाइम लाइन दिखाते हैं।
  • आपके उपयोगकर्ताओं द्वारा उपयोग किए जाने वाले प्रत्येक वातावरण में परीक्षण करें। इसे गतिशील रूप से करने की आवश्यकता हो सकती है (सर्वर साइड, पेज बनाते समय) उपयोगकर्ताओं के वातावरण के आधार पर लोडिंग के क्रम को बदल देती है।
  • जब संदेह हो, तो आदेश को बदल दें और फिर से मापें।
  • यह संभव है कि लोड क्रम में शैलियों और लिपियों का अंतरतम इष्टतम होगा; एक के नहीं तो दूसरे के सभी।
  • प्रयोग न केवल क्या फाइलों को लोड करने के लिए आदेश, लेकिन कहाँ। सिर? शरीर में? बॉडी के बाद? DOM तैयार / भरा हुआ? लदा हुआ?
  • जब पृष्ठ से इंटरेक्ट करने में सक्षम होने से पहले उपयोगकर्ता द्वारा अनुभव की जाने वाली शुद्ध देरी को कम करने के लिए async और defer विकल्पों पर विचार करें। यह निर्धारित करने के लिए परीक्षण करें कि क्या वे मदद करते हैं या चोट लगी है।
  • इष्टतम लोड ऑर्डर का मूल्यांकन करते समय हमेशा विचार करने के लिए व्यापार नापसंद होगा। सुंदर बनाम उत्तरदायी सिर्फ एक।

1
लिंक किए गए लेख में अब दावा नहीं किया गया है "स्टाइलशीट लोड स्क्रिप्ट निष्पादन को रोकती है"। क्या यह अब सच नहीं है?
ग्रेग

@Greg - यह अभी भी सच है। लिपियों को DOM .style विशेषताओं को क्वेरी करने में सक्षम होने की आवश्यकता है, इसलिए स्टाइलशीट अभी भी स्क्रिप्ट निष्पादन को रोकते हैं। हो सकता है कि वे स्क्रिप्ट लोडिंग को ब्लॉक न करें , यदि वे स्मार्ट हैं, लेकिन वे script.onLoad इवेंट को ब्लॉक कर देंगे।
जिमी ब्रेक-मैके

10

2017-12-16 को अपडेट किया गया

मुझे ओपी में परीक्षणों के बारे में निश्चित नहीं था। मैंने थोड़ा प्रयोग करने का फैसला किया और कुछ मिथकों को तोड़कर समाप्त कर दिया।

सिंक्रोनस <script src...>इसे डाउनलोड करने और निष्पादित होने तक इसके नीचे के संसाधनों को डाउनलोड करने से रोक देगा

यह अब सच नहीं है । Chrome 63 द्वारा उत्पन्न जलप्रपात पर एक नज़र डालें:

<head>
<script src="//alias-0.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=1"></script>
<script src="//alias-1.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=2"></script>
<script src="//alias-2.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=3"></script>
</head>

क्रोम नेट इंस्पेक्टर -> झरना

<link rel=stylesheet> डाउनलोड और स्क्रिप्ट के निष्पादन को इसके नीचे ब्लॉक नहीं करेगा

यह गलत है । स्टाइलशीट डाउनलोड को ब्लॉक नहीं करेगा, लेकिन यह स्क्रिप्ट के निष्पादन ( यहां थोड़ा स्पष्टीकरण ) को ब्लॉक करेगा । Chrome 63 द्वारा बनाए गए प्रदर्शन चार्ट पर एक नज़र डालें:

<link href="//alias-0.redacted.com/payload.php?type=css&amp;delay=666" rel="stylesheet">
<script src="//alias-1.redacted.com/payload.php?type=js&amp;delay=333&amp;block=1000"></script>

क्रोम देव उपकरण -> प्रदर्शन


उपरोक्त बातों को ध्यान में रखते हुए, ओपी के परिणामों को इस प्रकार समझाया जा सकता है:

सीएसएस पहले:

CSS Download  500ms:<------------------------------------------------>
JS Download   400ms:<-------------------------------------->
JS Execution 1000ms:                                                  <-------------------------------------------------------------------------------------------------->
DOM Ready   @1500ms:                                                                                                                                                      

जेएस प्रथम:

JS Download   400ms:<-------------------------------------->
CSS Download  500ms:<------------------------------------------------>
JS Execution 1000ms:                                        <-------------------------------------------------------------------------------------------------->
DOM Ready   @1400ms:                                                                                                                                            

यही कारण है कि डॉक्युमेंट.राइट () HTMLDOM के लिए अब तक के सबसे बुरे विचारों में से एक है।
ब्रूनोइस

1
The reason is that the script may want to get coordinates and other style-dependent properties of elements, like in the example above. Naturally, it has to wait for styles to load. javascript.info/… जेएस के मामले में वही धारणा क्यों लागू नहीं होती है? मेरे लिए बहुत मायने नहीं रखता, निष्पादित जेएस का आदेश इसके उद्देश्य के बारे में कुछ भी नहीं बताता है।
थोरस्टन स्कोनिंग

4

मुझे बिल्कुल यकीन नहीं है कि आपके परीक्षण ने जावा स्क्रिप्ट का उपयोग करते हुए 'रेंडर' समय कैसे दिया। हालाँकि इस पर विचार करें

आपकी साइट पर एक पृष्ठ 50k है जो अनुचित नहीं है। उपयोगकर्ता पूर्वी तट पर है जबकि आपका सर्वर पश्चिम में है। MTU निश्चित रूप से 10k नहीं है इसलिए आगे और पीछे कुछ यात्राएं होंगी। आपके पेज और स्टाइलशीट को प्राप्त करने में 1/2 सेकंड का समय लग सकता है। आमतौर पर (मेरे लिए) जावास्क्रिप्ट (jquery प्लगइन के माध्यम से और इस तरह) CSS की तुलना में बहुत अधिक है। थेरेस भी तब होता है जब आपका इंटरनेट कनेक्शन पेज पर मध्य मार्ग को चोक कर देता है, लेकिन इसे अनदेखा कर देता है (यह मेरे साथ कभी-कभी होता है और मुझे विश्वास है कि सीएसएस प्रस्तुत करता है लेकिन मैं 100% सुनिश्चित नहीं हूं)।

चूंकि सीएसएस सिर में है, इसलिए इसे प्राप्त करने के लिए अतिरिक्त कनेक्शन हो सकते हैं, जिसका अर्थ है कि यह संभावित रूप से पृष्ठ से पहले समाप्त हो सकता है। पृष्ठ के शेष हिस्से के प्रकार और इस दौरान जावास्क्रिप्ट फ़ाइलें (जो कई और बाइट्स हैं) पृष्ठ अस्थिर है जो साइट / कनेक्शन को धीमा बनाता है।

ईवीएन यदि जेएस दुभाषिया तब तक शुरू करने से इनकार कर देता है जब तक कि सीएसएस को जावास्क्रिप्ट कोड डाउनलोड करने के लिए समय नहीं दिया जाता है, खासकर जब सर्वर से दूर सीएसएस समय में कटौती हो रही है जो साइट को सुंदर नहीं बना देगा।

इसका एक छोटा अनुकूलन लेकिन इसका कारण है।


1
सर्वर पूर्वी तट, fwiw पर है। आप भी, जाहिरा तौर पर, इस तथ्य से अनजान हैं कि वे अब सीडीएन का उपयोग करते हैं।
jcolebrand

3

यहाँ उपरोक्त सभी प्रमुख उत्तरों का सारांश है (या शायद बाद में नीचे :)

आधुनिक ब्राउज़रों के लिए, आपको जहाँ भी पसंद हो, वहाँ css डाल दें। वे आपकी html फ़ाइल का विश्लेषण करेंगे (जिसे वे सट्टा पार्सिंग कहते हैं ) और html पार्सिंग के साथ समानांतर में सीएसएस डाउनलोड करना शुरू करते हैं।

पुराने ब्राउज़रों के लिए शीर्ष पर सीएसएस डालते रहें (यदि आप पहले एक नग्न लेकिन इंटरैक्टिव पृष्ठ नहीं दिखाना चाहते हैं)।

सभी ब्राउज़रों के लिए, जावास्क्रिप्ट को यथासंभव पृष्ठ पर नीचे रखें, क्योंकि यह आपके HTML के पार्सिंग को रोक देगा। अधिमानतः, इसे अतुल्यकालिक रूप से डाउनलोड करें (यानी, अजाक्स कॉल)

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

तो, सवाल का जवाब देने के लिए: हाँ। जेएस को आधुनिक ब्राउज़रों के लिए अमान्य करने से पहले सीएसएस को शामिल करने की सिफारिश की गई है। आप जहां चाहें सीएसएस लगाएं, और जहां तक ​​संभव हो, जेएस को अंत की ओर रखें।


1

स्टीव सॉडर्स ने पहले ही एक निश्चित जवाब दिया है लेकिन ...

मुझे आश्चर्य है कि क्या सैम के मूल परीक्षण और जोश के दोहराव के साथ कोई समस्या है।

दोनों परीक्षण कम विलंबता कनेक्शन पर किए गए प्रतीत होते हैं जहां टीसीपी कनेक्शन स्थापित करने की एक तुच्छ लागत होगी।

यह कैसे परीक्षण के परिणाम को प्रभावित करता है मुझे यकीन नहीं है और मैं एक 'सामान्य' अक्षांश कनेक्शन पर परीक्षणों के लिए झरने को देखना चाहता हूं: ...

डाउनलोड की गई पहली फ़ाइल को html पेज के लिए उपयोग किया गया कनेक्शन मिलना चाहिए , और डाउनलोड की गई दूसरी फ़ाइल को नया कनेक्शन मिलेगा। (जो कि गतिशील है, लेकिन यह यहां नहीं किया जा रहा है)

नए ब्राउज़रों में दूसरा टीसीपी कनेक्शन सट्टा खोला जाता है, इसलिए कनेक्शन ओवरहेड कम हो जाता है / चला जाता है, पुराने ब्राउज़रों में यह सच नहीं है और दूसरा कनेक्शन ओपन होने का ओवरहेड होगा।

काफी / अगर यह उन परीक्षणों के परिणाम को प्रभावित करता है जो मुझे यकीन नहीं है।


निम्नलिखित नहीं, जब तक कि आपके पास पाइप लाइनिंग नहीं है जो अविश्वसनीय रूप से दुर्लभ है, तो आपको कनेक्शन सेटअप कम होने की बहुत संभावना नहीं है ... सहमत हैं कि परीक्षण को कम विलंबता पर दोहराया जाना चाहिए
सैम केसरॉन

यदि आप इस जलप्रपात को देखते हैं तो आप देख सकते हैं कि Chrome ने webpagetest.org/result/… (IE9 यही करता है) की आवश्यकता होने से पहले ही दूसरा कनेक्शन खोल दिया है ... मैं कम के बजाय TCP उद्देश्यों के लिए सामान्य विलंबता सोच रहा था - किस प्रकार पर्यावरण का परीक्षण किसमें किया गया था?
एंडी डेविस

2
पुन: "स्टीव सौडर्स ने पहले ही एक निश्चित उत्तर दिया है लेकिन ..." वेब विकास के साथ बात यह है कि कोई निश्चित उत्तर नहीं हैं। :) लिपियों को लोड करने के लिए 3-4 तरीके हैं और चीजें बदल जाती हैं। वास्तविक सही सिमेंटिक वास्तव में स्टीव के लिए "सिंक्रोनस जावास्क्रिप्ट से पहले सीएसएस रखो" कहने के लिए होना चाहिए था अन्यथा लोगों को इसे सामान्य करने से गलत हो जाता है क्योंकि यह सभी लिपियों के लिए एक नियम है ...
हेक्सालिस

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

1

मुझे लगता है कि यह सभी मामलों के लिए सच नहीं होगा। क्योंकि सीएसएस समानांतर लेकिन जेएस कैंट डाउनलोड करेगा। उसी मामले पर विचार करें,

सिंगल सीएसएस होने के बजाय, 2 या 3 सीएसएस फाइल लें और इसे इन तरीकों से आज़माएं,

1) css..css..js 2) css..js..css 3) js..css..css

मुझे यकीन है कि css..css..js अन्य सभी की तुलना में बेहतर परिणाम देगा।


0

हमें यह ध्यान रखना है कि नए ब्राउज़रों ने अपने जावास्क्रिप्ट इंजन, उनके पार्सर और इतने पर काम किया है, जो आम कोड और मार्कअप समस्याओं को इस तरह से अनुकूलित करते हैं कि प्राचीन ब्राउज़रों जैसे <= IE8 में अनुभव होने वाली समस्याएं अब प्रासंगिक नहीं हैं, न केवल के साथ मार्कअप के संबंध में, लेकिन जावास्क्रिप्ट वेरिएबल्स, एलिमेंट सिलेक्टर्स आदि का उपयोग करने के लिए, मैं भविष्य में इतने दूर की स्थिति में नहीं देख सकता, जहां प्रौद्योगिकी एक ऐसे बिंदु पर पहुंच गई है जहां प्रदर्शन वास्तव में अब कोई मुद्दा नहीं है।


प्रदर्शन हमेशा एक मुद्दा है। मैं सिर्फ लगभग उन ब्राउज़रों को अनदेखा करता हूं जो कल्पना का पालन नहीं करते हैं। मैं सिर्फ अपना कोड तैयार करता हूं, जो कि पूरी गति से युक्ति का पालन करता है और अन्य मैं बस ऐसा करता हूं कि यह काम करता है। इसलिए, उदाहरण के लिए, यदि यह IE8 में काम करता है, तो सब ठीक है।
ब्रूनोइस

-5

व्यक्तिगत रूप से, मैं इस तरह के "लोक ज्ञान" पर बहुत अधिक जोर नहीं दूंगा। अतीत में जो सत्य रहा होगा वह शायद अब सच न हो। मुझे लगता है कि वेब पेज की व्याख्या और प्रतिपादन से संबंधित सभी ऑपरेशन पूरी तरह से अतुल्यकालिक हैं ("कुछ लेना" और "उस पर अभिनय करना" दो पूरी तरह से अलग-अलग चीजें हैं जो विभिन्न थ्रेड्स द्वारा नियंत्रित की जा सकती हैं, आदि)। ), और किसी भी मामले में पूरी तरह से आपके नियंत्रण या आपकी चिंता से परे है।

मैं दस्तावेज़ के "सिर" भाग में सीएसएस संदर्भों को बाहरी लिपियों के किसी भी संदर्भ के साथ रखूँगा। (कुछ लिपियों को शरीर में रखने की मांग की जा सकती है, और यदि हां, तो उन्हें उपकृत करें।)

उस से परे ... यदि आप मानते हैं कि "यह इस / उस ब्राउज़र की तुलना में अधिक तेज़ / धीमा प्रतीत होता है," इस अवलोकन को एक दिलचस्प लेकिन अप्रासंगिक जिज्ञासा के रूप में मानें और इसे अपने डिज़ाइन निर्णयों को प्रभावित न करने दें। बहुत सी चीजें बहुत तेजी से बदलती हैं। (कोई भी व्यक्ति फ़ायरफ़ॉक्स टीम के अपने उत्पाद के एक और अंतरिम-रिलीज़ के साथ बाहर आने से पहले कितने मिनटों तक कोई भी शर्त रखना चाहता है ? हाँ, मुझे भी नहीं।)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.