javascript - जावास्क्रिप्ट से पहले सीएसएस को शामिल करने की सिफारिश अमान्य है?

css performance (9)

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

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

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

मेरा परीक्षण दोहन

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

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 मुझे सीएसएस को स्थानांतरित करने में 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>

जब मैं पहले सीएसएस को शामिल करता हूं, तो पृष्ठ को प्रस्तुत करने में 1.5 सेकंड लगते हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह प्रश्न विशेष रूप से वेब साइटों पर रखे जा रहे सभी विज्ञापनों पर लागू होता है। यदि साइट लेखकों ने केवल विज्ञापन सामग्री के लिए प्लेसहोल्डर divs प्रस्तुत किया है और यह सुनिश्चित किया है कि ऑनलोड ईवेंट में विज्ञापनों को इंजेक्शन देने से पहले उनकी साइट लोड हो गई हो और इंटरैक्टिव हो। फिर भी मैं एक बार में सभी के बजाय क्रमशः लोड किए गए विज्ञापनों को देखना चाहता हूं क्योंकि वे फ़्लोट किए गए विज्ञापन लोड होने के दौरान साइट सामग्री को स्क्रॉल करने की मेरी क्षमता को प्रभावित करते हैं। लेकिन यह सिर्फ एक व्यक्ति का दृष्टिकोण है।

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

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

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

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

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

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

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

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

1) सीएसएस..सीएसएस..जेएस 2) सीएसएस..जेएस..सीएसएस 3) जेएस..सीएसएस..सीएसएस

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

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

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

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

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

सुनिश्चित करें कि कोई HTTP कैशिंग नहीं है इसलिए ब्राउज़र को प्रत्येक बार लोड होने पर पूर्ण डाउनलोड करना होगा।
वास्तविकता अनुकरण करने के लिए, मैंने jQuery और H5BP सीएसएस को शामिल किया है (इसलिए पार्स करने के लिए स्क्रिप्ट / सीएसएस की एक सभ्य राशि है)
दो पेज सेट करें - एक स्क्रिप्ट से पहले सीएसएस के साथ, एक स्क्रिप्ट के बाद सीएसएस के साथ।
<head> निष्पादित करने के लिए बाहरी स्क्रिप्ट के लिए कितना समय लगा
<body> DOMReady <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

इसके बाद, मैंने सीएसएस के बजाय 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

अंत में, मैंने 500ms तक देरी करने के लिए 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> को <head> में <link> s से पहले जाना चाहिए या नहीं।

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

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

क्यूं कर?

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

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

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

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

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

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

क्रोम 1 (वेबकिट 525) (100%)
आईई 8 (75%)
फ़ायरफ़ॉक्स 3.5 (9 6%)
सफारी 4 (99%)
ओपेरा 11.60 (85%)

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

मोबाइल ब्राउज़र पर, मोबाइल ब्राउजर और ओएस लैंडस्केप कितना विषम है, इस वजह से निश्चित संख्याएं प्राप्त करना थोड़ा मुश्किल है। चूंकि सट्टा प्रतिपादन वेबकिट 525 (मार्च 2008 को जारी किया गया) में लागू किया गया था, और बस हर सार्थक मोबाइल ब्राउज़र वेबकिट पर आधारित है, हम निष्कर्ष निकाल सकते हैं कि "अधिकतर" मोबाइल ब्राउज़र को इसका समर्थन करना चाहिए । quirksmode अनुसार, आईओएस 2.2 / एंड्रॉइड 1.0 वेबकिट 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

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

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

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

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

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

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

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

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

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

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

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

यह अब सच नहीं है । क्रोम 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> इसके नीचे स्क्रिप्ट के डाउनलोड और निष्पादन को अवरुद्ध नहीं करेगा

यह गलत है । स्टाइलशीट डाउनलोड को अवरुद्ध नहीं करेगा लेकिन यह स्क्रिप्ट के निष्पादन को अवरुद्ध कर देगा ( यहां थोड़ा स्पष्टीकरण )। क्रोम 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:                                                                                                                                            ◆