Frage Ist die Empfehlung, CSS vor JavaScript zu verwenden, ungültig?


An unzähligen Orten online habe ich die Empfehlung gesehen, CSS vor JavaScript zu integrieren. Die Begründung ist im Allgemeinen, von dieser Form:

Wenn Sie CSS und JavaScript bestellen möchten, möchten Sie Ihr CSS   um zuerst zu kommen. Der Grund dafür ist, dass der Rendering-Thread alle enthält   Stilinformationen müssen die Seite rendern. Wenn das JavaScript   enthält zuerst, die JavaScript-Engine muss alles vorher analysieren   Weiter zu den nächsten Ressourcen. Dies bedeutet das Rendern   Thread kann die Seite nicht vollständig anzeigen, da sie nicht alle enthält   Stile, die es braucht.

Meine eigentliche Prüfung zeigt etwas ganz anderes:

Mein Testgeschirr

Ich verwende das folgende Ruby-Skript, um bestimmte Verzögerungen für verschiedene Ressourcen zu generieren:

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..."
}

Der obige Mini-Server erlaubt es mir, beliebige Verzögerungen für JavaScript-Dateien (sowohl Server als auch Client) und beliebige CSS-Verzögerungen einzustellen. Beispielsweise, http://10.0.0.50:8081/test.css?delay=500 gibt mir eine 500 ms Verzögerung beim Übertragen des CSS.

Ich benutze die folgende Seite zum Testen.

<!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>

Wenn ich das CSS zuerst einschließe, dauert die Wiedergabe der Seite 1,5 Sekunden:

CSS first

Wenn ich das JavaScript zuerst einschließe, dauert die Wiedergabe der Seite 1,4 Sekunden:

JavaScript first

Ich bekomme ähnliche Ergebnisse in Chrome, Firefox und Internet Explorer. In Opera spielt die Reihenfolge jedoch keine Rolle.

Es scheint, dass der JavaScript-Interpreter nicht startet, bis das gesamte CSS heruntergeladen ist. So scheint es, dass JavaScript-Includes zuerst effizienter ist, da der JavaScript-Thread mehr Laufzeit erhält.

Fehle ich etwas, ist die Empfehlung, CSS-Includes vor JavaScript zu platzieren, nicht korrekt?

Es ist klar, dass wir async hinzufügen oder setTimeout verwenden können, um den Render-Thread freizugeben oder den JavaScript-Code in die Fußzeile zu stellen oder einen JavaScript-Loader zu verwenden. Hier geht es um die Bestellung von essentiellen JavaScript-Bits und CSS-Bits im Kopf.


827
2018-02-14 03:24


Ursprung


Antworten:


Das ist eine sehr interessante Frage. Ich habe immer mein CSS gesetzt <link href="...">s vor meinem JS <script src="...">Weil "Ich lese einmal, dass es besser ist." Also hast du recht; Es ist höchste Zeit, dass wir recherchieren!

Ich habe meinen eigenen Test-Kabelbaum in Node eingerichtet (Code unten). Grundsätzlich, ich:

  • Stellen Sie sicher, dass kein HTTP-Caching durchgeführt wurde, sodass der Browser jedes Mal, wenn eine Seite geladen wird, einen vollständigen Download durchführen muss.
  • Um die Realität zu simulieren, habe ich jQuery und die H5BP CSS (also gibt es eine anständige Menge an zu analysierenden Skripten / CSS)
  • Richten Sie zwei Seiten ein - eine mit CSS vor dem Skript, eine mit CSS nach dem Skript.
  • Aufgezeichnet, wie lange es für das externe Skript in der <head> ausführen
  • Aufgezeichnet, wie lange es für das Inline-Skript in der <body> ausführen, was analog zu DOMReady.
  • Verzögert das Senden von CSS und / oder Skript an den Browser um 500ms.
  • Habe den Test 20 Mal in den 3 wichtigsten Browsern durchgeführt.

Ergebnisse

Erstens, mit der CSS-Datei um 500ms verzögert:

     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

Als Nächstes setze ich jQuery so, dass es um 500 ms statt um das CSS verzögert wird:

     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

Endlich setze ich mich beide jQuery und das CSS um 500ms zu verzögern:

     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

Schlussfolgerungen

Zunächst ist es wichtig zu beachten, dass ich davon ausgehe, dass sich Skripte in der <head> Ihres Dokuments (im Gegensatz zum Ende des <body>). Es gibt verschiedene Argumente dafür, warum Sie im <head> gegen das Ende des Dokuments, aber das ist außerhalb des Umfangs dieser Antwort. Hier geht es ausschließlich darum, ob <script>s sollte vorher gehen <link>s in der <head>.

In modernen DESKTOP-Browsern Es sieht so aus, als würde man zuerst mit CSS verlinken noch nie bietet einen Leistungsgewinn. Wenn Sie CSS nach dem Skript einfügen, erhalten Sie eine triviale Menge an Gewinn, wenn sowohl CSS als auch Skript verzögert sind, aber Sie haben große Vorteile, wenn CSS verzögert wird. (Gezeigt von der last Spalten in der ersten Reihe von Ergebnissen.)

Vorausgesetzt, dass die letzte Verknüpfung mit CSS die Performance nicht zu beeinträchtigen scheint kann unter bestimmten Umständen Gewinne erzielen, Sie sollten auf externe Stylesheets verlinken nach Sie verlinken zu externen Skripten nur auf Desktop-Browsern wenn die Leistung alter Browser keine Rolle spielt. Lesen Sie weiter für die mobile Situation.

Warum?

Historisch gesehen, wenn ein Browser auf einen gefunden hat <script> Tag, der auf eine externe Ressource zeigt, würde der Browser halt Analysieren des HTML, Abrufen des Skripts, Ausführen des Skripts und anschließendes Parsen des HTML. Im Gegensatz dazu, wenn der Browser eine gefunden hat <link> für ein externes Stylesheet würde es das tun fortsetzen Parsen des HTML, während er die CSS-Datei (parallel) abgerufen hat.

Daher die weit verbreitete Empfehlung, Stylesheets an die erste Stelle zu setzen - sie würden zuerst heruntergeladen und das erste herunterzuladende Skript könnte parallel geladen werden.

Allerdings haben moderne Browser (einschließlich aller Browser, die ich oben getestet habe) implementiert spekulatives Parsing, wo der Browser im HTML nach vorne schaut und mit dem Herunterladen von Ressourcen beginnt Vor Skripte herunterladen und ausführen.

In älteren Browsern ohne spekulatives Parsing wirkt sich das Setzen von Skripten auf die Leistung aus, da sie nicht parallel heruntergeladen werden.

Browserunterstützung

Das spekulative Parsing wurde zuerst implementiert in: (zusammen mit dem Prozentsatz der weltweiten Desktop-Browser-Benutzer, die diese Version oder höher ab Januar 2012 verwenden)

  • Chrome 1 (WebKit 525) (100%)
  • IE 8 (75%)
  • Firefox 3.5 (96%)
  • Safari 4 (99%)
  • Oper 11.60 (85%)

Insgesamt unterstützen heute etwa 85% der Desktop-Browser spekulative Ladevorgänge. Wenn Sie Skripts vor CSS setzen, wird dies bei 15% der Benutzer zu einer Leistungseinbuße führen global; YMMV basiert auf der spezifischen Zielgruppe Ihrer Website. (Und denken Sie daran, dass die Zahl schrumpft.)

In mobilen Browsern ist es aufgrund der Heterogenität des mobilen Browsers und der OS-Landschaft schwieriger, endgültige Zahlen zu erhalten. Da spekulatives Rendering in WebKit 525 implementiert wurde (veröffentlicht im März 2008), und fast jeder lohnende mobile Browser auf WebKit basiert, können wir daraus schließen, dass "die meisten" mobilen Browser sollte unterstütze es. Gemäß Quirkmodus, iOS 2.2 / Android 1.0 verwenden WebKit 525. Ich habe keine Ahnung, wie Windows Phone aussieht.

Jedoch, Ich habe den Test auf meinem Android 4-Gerät ausgeführt, und während ich ähnliche Zahlen wie auf dem Desktop sah, habe ich ihn an das fantastische neue angeschlossen Remote-Debugger In Chrome für Android und auf der Registerkarte "Netzwerk" wurde angezeigt, dass der Browser tatsächlich darauf wartete, das CSS herunterzuladen, bis die JavaScripts vollständig geladen waren. Mit anderen Worten: Selbst die neueste Version von WebKit für Android scheint kein spekulatives Parsen zu unterstützen.  Ich vermute, dass es aufgrund der CPU-, Speicher- und / oder Netzwerkeinschränkungen von mobilen Geräten möglicherweise ausgeschaltet ist.

Code

Verzeihen Sie die Schlamperei - das war Q & D.

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 war jquery-1.7.1.min.js


671
2018-02-14 06:37



Es gibt zwei Hauptgründe, CSS vor JavaScript zu setzen.

  1. Alte Browser (Internet Explorer 6-7, Firefox 2 usw.) würden alle nachfolgenden Downloads blockieren, wenn sie mit dem Herunterladen eines Skripts beginnen. Also wenn du es getan hast a.js gefolgt von b.css Sie werden nacheinander heruntergeladen: zuerst a dann b. Wenn Sie haben b.css gefolgt von a.js Sie werden parallel heruntergeladen, sodass die Seite schneller geladen wird.

  2. Es wird nichts gerendert, bis alle Stylesheets heruntergeladen sind - dies gilt für alle Browser. Skripte sind unterschiedlich - sie blockieren das Rendering aller DOM-Elemente unter dem Skript-Tag auf der Seite. Wenn Sie Ihre Skripte in den HEAD einfügen, bedeutet dies, dass die gesamte Seite vom Rendern blockiert wird, bis alle Stylesheets und alle Skripte heruntergeladen sind. Während es sinnvoll ist, das Rendering für Stylesheets zu blockieren (damit Sie beim ersten Mal den richtigen Stil erhalten und den Flash von unfriedlichem Inhalt vermeiden), ist es nicht sinnvoll, das Rendern der gesamten Seite für Skripte zu blockieren. Oft beeinflussen Skripte keine DOM-Elemente oder nur einen Teil von DOM-Elementen. Es empfiehlt sich, Skripts so niedrig wie möglich auf der Seite zu laden oder sie sogar asynchron zu laden.

Es macht Spaß, Beispiele mit zu erstellen Cuzillion. Beispielsweise, diese Seite hat ein Skript im HEAD, so dass die gesamte Seite leer ist, bis das Herunterladen abgeschlossen ist. Wenn wir das Skript jedoch an das Ende des BODY-Blocks verschieben, wird der Seitenkopf gerendert, da diese DOM-Elemente oberhalb des SCRIPT-Tags erscheinen, wie Sie sehen können diese Seite.


293
2018-02-14 06:27



Ich würde nicht zu sehr auf die Ergebnisse hinweisen, die Sie haben, ich glaube, dass es subjektiv ist, aber ich habe einen Grund, Ihnen zu erklären, dass es besser ist, CSS vor js zu setzen.

Während des Ladens Ihrer Website gibt es zwei Szenarien, die Sie sehen würden:

FALL 1: weißer Bildschirm> unbelastete Website> gestylte Website> Interaktion> gestylte und interaktive Website

FALL 2: weißer Bildschirm> unbelastete Website> Interaktion> gestaltete Website> gestylte und interaktive Website


Ich kann mir ehrlich gesagt nicht vorstellen, dass jemand Fall 2 wählt. Das würde bedeuten, dass Besucher, die langsame Internetverbindungen nutzen, mit einer unfertigen Website konfrontiert werden, die es ihnen erlaubt, mit Javascript zu interagieren (da das bereits geladen ist). Darüber hinaus würde der Zeitaufwand für das Betrachten einer unfertigen Website auf diese Weise maximiert werden. Warum sollte das jemand wollen?

Es funktioniert auch besser als jQuery gibt an 

"Bei Skripten, die auf dem Wert von CSS-Stileigenschaften basieren,   Es ist wichtig, auf externe Stylesheets zu verweisen oder Stile einzubetten   Elemente vor dem Verweis auf die Skripts ".

Wenn die Dateien in der falschen Reihenfolge geladen werden (zuerst JS, dann CSS), wird jeglicher JavaScript-Code, der auf in CSS-Dateien festgelegten Eigenschaften beruht (z. B. die Breite oder Höhe eines div), nicht korrekt geladen. Es scheint, dass bei falscher Ladereihenfolge die richtigen Eigenschaften "manchmal" Javascript bekannt sind (vielleicht wird dies durch eine Race Condition verursacht?). Dieser Effekt scheint je nach verwendetem Browser größer oder kleiner zu sein.


40
2018-02-14 07:55



Wurden Ihre Tests auf Ihrem PC oder auf einem Webserver durchgeführt? Es ist eine leere Seite oder ist es ein komplexes Online-System mit Bildern, Datenbanken usw.? Führen Ihre Skripts eine einfache Hover-Ereignisaktion aus oder sind sie eine Kernkomponente für die Darstellung und Interaktion Ihrer Website mit dem Benutzer? Es gibt mehrere Dinge, die hier zu beachten sind, und die Relevanz dieser Empfehlungen wird fast immer zu Regeln, wenn Sie sich auf hochkarätige Web-Entwicklung einlassen.

Der Zweck der Regel "Stylesheets an der Spitze und Skripts an der untersten Stelle" lautet, dass es im Allgemeinen der beste Weg ist, um optimale Ergebnisse zu erzielen progressives Rendering, Das ist für die Benutzererfahrung entscheidend.

Alles andere beiseite: Wenn Ihr Test gültig ist und Sie tatsächlich Ergebnisse erzielen, die den gängigen Regeln widersprechen, wäre das eigentlich keine Überraschung. Jede Website (und alles, was nötig ist, um das Ganze auf dem Bildschirm eines Benutzers erscheinen zu lassen) ist anders und das Internet entwickelt sich ständig weiter.


25
2018-02-14 13:31



Ich schließe CSS-Dateien vor Javascript aus einem anderen Grund ein.

Wenn mein Javascript dynamische Größenanpassungen für einige Seitenelemente benötigt (für jene Fälle, in denen CSS wirklich eine Hauptfunktion im Hintergrund ist), kann das Laden der CSS nach dem JS Russing zu Wettlaufbedingungen führen, bei denen das Element vor CSS-Stilen angepasst wird werden angewendet und sehen dann komisch aus, wenn die Styles endlich einsetzen. Wenn ich das CSS vorher lade, kann ich garantieren, dass die Dinge in der vorgesehenen Reihenfolge ablaufen und dass das endgültige Layout so ist, wie ich es möchte.


21
2018-05-25 20:00



Ist die Empfehlung, CSS vor JavaScript zu verwenden, ungültig?

Nicht, wenn Sie es als eine einfache Empfehlung behandeln. Aber wenn Sie es als eine harte und schnelle Regel behandeln, ja, ist es ungültig.

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

Stylesheet lädt die Skriptausführung, wenn Sie eine haben <script>   nach einer <link rel="stylesheet" ...> Die Seite wird die Analyse nicht beenden   - und DOMContentLoaded wird nicht ausgelöst - bis das Stylesheet geladen ist.

Anscheinend müssen Sie wissen, worauf sich jedes Skript stützt, und sicherstellen, dass die Ausführung des Skripts erst nach dem richtigen Abschlussereignis verzögert wird. Wenn das Skript nur vom DOM abhängt, kann es in ondomready / domcontentloaded fortgesetzt werden, wenn es auf geladenen Bildern oder zu verwendenden Stylesheets angewiesen ist. Wenn ich den obigen Verweis richtig gelesen habe, muss dieser Code bis zum onload-Ereignis zurückgestellt werden.

Ich denke nicht, dass eine Sockengröße für alle passt, auch wenn sie so verkauft werden und ich weiß, dass eine Schuhgröße nicht für alle passt. Ich glaube nicht, dass es eine definitive Antwort gibt, auf die man zuerst laden kann, Styles oder Script. Es ist mehr eine fallweise Entscheidung dessen, was in welcher Reihenfolge geladen werden muss und was später aufgeschoben werden kann, als sei es nicht auf dem "kritischen Pfad".

Um mit dem Beobachter zu sprechen, der kommentierte, dass es besser ist, die Benutzerfähigkeit zu verzögern, bis das Blatt hübsch ist. Es gibt viele von euch da draußen und Sie ärgern Ihre Kollegen, die das Gegenteil fühlen. Sie kamen zu einem Ort, um einen Zweck zu erfüllen, und verzögerten ihre Fähigkeit, mit einer Seite zu interagieren, während sie darauf warteten, dass Dinge, die nicht wichtig sind, um das Laden zu beenden, sehr frustrierend sind. Ich sage nicht, dass du falsch liegst, nur dass du dir bewusst sein solltest, dass es eine andere Fraktion gibt, die deine Priorität nicht teilt.

Diese Frage gilt insbesondere für alle Anzeigen auf Websites. Ich würde es lieben, wenn Site-Autoren nur Platzhalter-Divs für den Anzeigencontent gerendert und sichergestellt haben, dass ihre Website geladen und interaktiv ist, bevor die Anzeigen in ein Onload-Event eingefügt werden. Selbst dann würde ich gerne sehen, dass die Anzeigen seriell statt alle auf einmal geladen werden, weil sie meine Fähigkeit beeinträchtigen, den Inhalt der Website zu scrollen, während die aufgeblähten Anzeigen geladen werden. Aber das ist nur eine Personensicht.

  • Kenne deine Nutzer und was sie schätzen.
  • Kennen Sie Ihre Benutzer und welche Browserumgebung sie verwenden.
  • Wissen, was jede Datei macht und was ihre Voraussetzungen sind. Alles in Gang zu setzen, hat Vorrang vor Geschwindigkeit und Schönheit.
  • Verwenden Sie Tools, die bei der Entwicklung die Netzwerkzeitlinie anzeigen.
  • Testen Sie in jeder Umgebung, die Ihre Benutzer verwenden. Es kann erforderlich sein, die Reihenfolge des Ladens basierend auf der Benutzerumgebung dynamisch zu ändern (serverseitig beim Erstellen der Seite).
  • Im Zweifelsfall die Reihenfolge ändern und erneut messen.
  • Es ist möglich, dass die Intermischungsstile und Skripts in der Ladereihenfolge optimal sind. nicht alle, dann alle anderen.
  • Experimentieren Sie nicht nur, in welcher Reihenfolge die Dateien geladen werden sollen sondern wo. Kopf? In Körper? Nach dem Körper? DOM bereit / geladen? Geladen?
  • Berücksichtigen Sie asynchrone und verzögerte Optionen, wenn dies angemessen ist, um die Nettoverzögerung zu reduzieren, die der Benutzer erfährt, bevor er mit der Seite interagieren kann. Testen Sie, ob sie helfen oder verletzen.
  • Es wird immer Kompromisse geben, die bei der Bewertung der optimalen Ladereihenfolge zu berücksichtigen sind. Pretty vs Responsive ist nur einer.

10
2018-04-27 12:16



Aktualisiert 2017-12-16

Ich war mir nicht sicher über die Tests in OP. Ich beschloss, ein wenig zu experimentieren und endete damit, einige der Mythen zu zerstören.

Synchron <script src...> wird das Herunterladen der Ressourcen blockieren   darunter, bis es heruntergeladen und ausgeführt wird

Das ist nicht mehr wahr. Werfen Sie einen Blick auf den von Chrome 63 generierten Wasserfall:

<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>

Chrome net inspector -> waterfall

<link rel=stylesheet> blockiert nicht den Download und die Ausführung von   Skripte darunter

Das ist falsch. Das Stylesheet blockiert den Download aber nicht werden Blockieren der Ausführung des Skripts (kleine Erklärung hier). Sehen Sie sich das von Chrome 63 generierte Leistungsdiagramm an:

<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>

Chrome dev tools -> performance


Unter Berücksichtigung der obigen Ausführungen können die Ergebnisse in OP wie folgt erklärt werden:

CSS zuerst:

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

JS zuerst:

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

6
2018-02-14 22:33