Ein Leser schrieb mir kürzlich und fragte mich (im Wesentlichen)
Gibt es einen Grund, das
async-Attribut zu verwenden, wenn sich dasscriptbereits am Ende der Seite befindet?
Ich bin kein Meister darin, aber so verstehe ich das...
Worüber er sprach, war dies
<script async src="/js/script.js"></script>
</body>Wir haben das schon einmal kurz behandelt. Es ist jedoch besonders interessant, es jetzt noch einmal zu betrachten, da das async-Attribut mittlerweile wirklich der einzig empfohlene Weg ist, asynchrone Skripte zu implementieren.
Gibt es also überhaupt einen Grund, das async-Attribut zu verwenden, wenn das script bereits am Ende der Seite platziert ist?
Kurze Antwort
Nein.
Längere Antwort
Was Sie mit dem async-Attribut zu verhindern versuchen, ist das Blockieren des Parsers. Wenn Sie das async-Attribut verwenden, sagen Sie: Ich möchte nicht, dass der Browser aufhört, was er tut, während er dieses Skript herunterlädt. Ich weiß, dass dieses Skript nichts wirklich von etwas benötigt, das im DOM fertig sein muss, wenn es ausgeführt wird, und dass es auch nicht in einer bestimmten Reihenfolge ausgeführt werden muss.
Wenn Sie das Skript am Ende der Seite laden, ist der Parser im Wesentlichen bereits fertig, sodass das Blockieren keine große Rolle spielt. Sie *verzögern* das Skript im Grunde bereits, was eine Art härteres Async ist. Siehe Vergleich.
Es könnte sogar ein wenig gefährlich sein.
Wenn Sie einfach davon ausgegangen sind, dass async = gut ist, könnten Sie etwas tun wie
<script async src="/js/libs.js"></script>
<script async src="/js/page.js"></script>
</body>Das könnte schlechte Nachrichten sein, denn die Chancen stehen gut, dass "libs.js" Abhängigkeiten für "page.js" hat, aber jetzt gibt es keine Garantie für die Reihenfolge, in der sie ausgeführt werden (schlecht).
Es ist meistens eine Sache von Drittanbietern.
Skripte von Drittanbietern sind der Hauptanwendungsfall für asynchrone Skripte. Sie (die Drittanbieter) können nicht kontrollieren, wo Sie dieses Skript auf Ihrer Seite platzieren, daher sind sie normalerweise so konzipiert, dass sie sowieso funktionieren, egal wann/wo sie geladen werden. Sie können Drittanbieter auch nicht kontrollieren (das ist, was ein Drittanbieter ist, Wayne), daher ist es ideal, dafür zu sorgen, dass sie Ihre Website nicht verlangsamen.
Gibt es noch andere Anwendungsfälle?
Ich schätze, wenn Sie den Download eines Ihrer eigenen Skripte sofort starten wollten und es keine Rolle spielt, wann es ausgeführt wird, könnten Sie es in den <head> einfügen und es asynchron laden.
Ich könnte mich vielleicht irren.
Ich neige dazu, diese JavaScript-Ratschlagsposts zu vermasseln, also wenn ich das getan habe, lasst uns in den Kommentaren darüber sprechen und ich werde dafür sorgen, dass der Inhalt dieses Posts die besten Informationen widerspiegelt.
Es gibt immer noch einen Anwendungsfall für die Verwendung von async, obwohl es am Ende platziert wurde. Jedes Skript, das synchron im Dokument hinzugefügt wird, blockiert das DOMContentLoaded (ready)-Ereignis, das oft zur Initialisierung von UI-Widgets/Komponenten verwendet wird.
Aber Sie haben absolut Recht. Der wichtigste Anwendungsfall für async heutzutage wäre Code von Drittanbietern, der asynchron oder besser mit der friendly iframe-Technik geladen werden muss. Leider ist dies oft unmöglich, aufgrund schlecht geschriebener Skripte.
Mir gefällt die kurze Antwort, sie ist sauberer.
+10
Laut einem Kommentar des Autors im Artikel unter igvita.com gibt es immer noch einen Vorteil
Vielen Dank für diesen Beitrag, ohne ihn hätte ich diese kleinen Details über async nicht gelernt!
Siehe: https://www.igvita.com/2014/05/20/script-injected-async-scripts-considered-harmful/#comment-1398899164
Bedeutet das, dass der Preloader keine Skripte findet, die kein async-Attribut haben? Das scheint seltsam. Ich frage mich nur, ich werde mich mit dieser Konversation beschäftigen müssen, um mehr zu erfahren.
@ Chris Coyier: Beide sind für den Preload-Scanner auffindbar. Aber wenn Sie (sagen wir) zwei Skripte haben, die nicht voneinander abhängig sind, lässt die Kennzeichnung jedes einzelnen mit dem Async-Flag den Browser sie in beliebiger Reihenfolge ausführen. Wenn also (sagen wir) das erste Skript langsam heruntergeladen wird, kann der Browser es vorziehen, das zweite Skript auszuführen, bevor das erste fertig heruntergeladen und ausgeführt wird. Wenn Sie Async weglassen, muss das zweite immer noch auf das erste warten. Es hat also immer noch einen nützlichen Zweck, selbst wenn die Skripte ganz am Ende von HTML stehen.
@ChrisCoyier @Chris Das Zitat bezieht sich auf die Verwendung des async-Attributs im Vergleich zur Skript-Injektion. Es wird nicht behandelt, ob das async-Attribut auf einem Skript-Tag verwendet werden soll oder nicht.
Mein Verständnis des async-Attributs wird von @T.J.Crowder gut zusammengefasst. Das async-Attribut ist vorteilhaft, wenn man weiß, was man tut, ist aber kein guter Standard für am Ende geladene Skript-Tags, wie Chris im Artikel schlussfolgerte.
Auch wenn ich zustimme, dass man es nicht verwenden sollte, weil es die Ausführungsreihenfolge nicht garantiert... Durch die Verwendung des async-Attributs wird das Skript tatsächlich doppelt so schnell wie ein normales Skript-Tag ausgeführt. Das Einfügen über das Skript-Tag in den DOM dauert im Durchschnitt 0,1 Sekunde länger, aber ich denke immer noch, das ist die beste Lösung.
Doppelt so schnell**. Chris' Kommentar oben ist ebenfalls korrekt.
Gibt es einen Grund, das
async-Attribut zu verwenden, wenn sich dasscriptbereits am Ende der Seite befindet?Ich sage: Nein, aber manchmal Ja!
Wenn die `script` am Ende voneinander unabhängig sind, können wir `async` verwenden, damit die Latenz beim Laden des ersten Skripts das zweite nicht beeinträchtigt.
Weitere Frage. Wenn Sie beispielsweise 10 Skripte am Ende Ihrer Seite laden und keine Abhängigkeiten vorhanden wären, würden sie dann durch das asynchrone Laden aller parallel geladen, anstatt vielleicht zuerst 6 Anfragen und dann weitere 4?
Ich habe einen eingefleischten Backend-Entwickler-Freund, der schwört, dass das Platzieren von Skripten am Ende der Seite schlechte Praxis ist und sich wirklich ärgert, wenn er auf Seiten nach den Skripten sucht und sie dann weiter unten findet. Ist es wirklich besser, sie vor dem Ende des `body` zu platzieren, oder ist es hauptsächlich eine Frage der Bequemlichkeit?
Hat er Gründe dafür, *warum* das schlechte Praxis wäre – ich meine, abgesehen davon, dass es ihn nur "annervt", dass er sie ein wenig länger suchen muss ...?
Wer tiefer eintauchen möchte: Dies ist mein Lieblingsartikel für das Laden von JS, ich fand ihn in der Vergangenheit sehr informativ.
http://www.html5rocks.com/en/tutorials/speed/script-loading/
josh
Es ist keine Bequemlichkeit, es ist für die Leistung. Das Hinzufügen der Skripte vor dem `body` erhöht die Rendering-Zeit. Mit einigen Ausnahmen bevorzugen einige Analyse-Skripte, dass Entwickler das Skript im Head platzieren, damit sie es verfolgen können, sobald die Seite aufgerufen wird.
Was ist mit der Verwendung von Async mit einem einzelnen verketteten Skript, anstatt sie alle aufzuteilen, sich um die Ausführungsreihenfolge zu kümmern und möglicherweise HTTP-Anfragen zu verbrennen? Wenn Sie `cat *.js > app.min.js` auf der Kommandozeile über Ihre JS-Datei ausführen, werden alle verkettet.
Verkettung ist meiner Meinung nach ein weiteres wichtiges Thema. Aus der Perspektive dieses Artikels sollte davon ausgegangen werden, dass Sie bereits so viel intelligente Verkettung wie möglich durchgeführt haben. Nur weil eine Seite zwei Skripte lädt, heißt das nicht, dass sie bei der Verkettung versagt. Es könnte durchaus sinnvoll sein, ein `global.js` zu haben, das auf allen Seiten geladen wird (und somit Caching nutzt) und ein `subpage.js`, das nur auf einigen Seiten geladen wird, aber auf Dingen aus `global` basiert.
@ Chris Coyier: Genau. Oder Sie haben die geschäftliche Entscheidung getroffen, Standardelemente von einem kostenlosen CDN und Ihre eigenen Sachen lokal herunterzuladen (und sich darum gekümmert, was passiert, wenn diese in einer chaotischen Reihenfolge vorliegen).
Nichts von all dem ist Dogma. Es sind pragmatische Entscheidungen, intelligent getroffen.
Oder zumindest, wissen Sie, das ist es, was wir sowieso anstreben... ;-)
Was ist mit dem asynchronen Laden von Skripten wie diesem?
Hmm, ich wollte HTML-Code einfügen...
<script src=”/js/AsyncLoader.js”></script>
<script>
AsyncLoader.Ready(function () {
AsyncLoader.Load([“jQuery”, “extensions”], function () {
// Anwendungslogik hier.
});
});
</script>
http://www.dustindiaz.com/scriptjs
Async-Laden mit Abhängigkeitsmanagement KAPOW.
Ein Abhängigkeitsattribut wäre besser, aber da es nicht existiert, ist dies sehr nützlich.
Vielen Dank für Ihre Klarstellung. Kürzlich hatte ich mit dem Async-Problem in meinem Projekt zu kämpfen. Ich bevorzuge das Laden des Skripts im Footer. Aber gibt es irgendwelche Nachteile, das Skript am Ende der Seite zu platzieren? Selbst einen?