kyle: " @paul_irish ich stimme nicht zu. http://bit.ly/9IfMMN Cacheability (externe CDNs), paralleler Download, Skriptänderungsvolatilität..."

james burke: " @paul_irish @fearphage @getify RequireJS hat ein Build-Tool zum Bündeln/Minimieren von Skripten, kann also das Beste von beidem haben: dynamisch und vorgefertigt"

Der einfachste Weg für Entwickler, mit dem Laden von Skripten zu beginnen, wäre wahrscheinlich die Verwendung von $Lab.js, da es bereits die Verkettungssyntax verwendet, mit der viele jQuery-Benutzer vertraut sind.

Wenn sie große Unternehmensanwendungen erstellen, können sie bei Bedarf jederzeit zu require.js migrieren.

Derzeit gibt es drei Haupttechniken zum Laden von Skripten:

1. KopfJS
2. ControlJS
3. LABjs

Verwenden Sie es oder nicht, es ist fraglich, welches verwendet werden soll: http://blog.getify.com/2010/12/on-script-loaders/

Es gibt auch requireJS und EnhanceJS, nur um Sie über die Alternativen zu HeadJS ControlJS und LabJS zu informieren . Sogar Yahoo und Google bieten etwas Ähnliches an.

Mit der Veröffentlichung von jQuery 1.5 und deferreds -- http://www.erichynds.com/jquery/using-deferreds-in-jquery/ verwendet Boris Moore sie in DeferJS, einem neuen Skript-Loader-Projekt: https://github. com/BorisMoore/DeferJS

Standardmäßig stoppt das Laden von Skripten alle anderen Downloads, daher ist das Herunterladen von modernizr im Header schlecht. Inlining-Loader sind sinnvoll, da Loader Skripte parallel und im nicht blockierenden Modus herunterladen können. Wenn Sie beispielsweise nicht alle modernizr-Funktionen benötigen, können Sie head.min.js, das nur 6 KB groß ist, oder einen benutzerdefinierten Build von modernizr (http://modernizr.github.com/Modernizr/2.0-beta/) einbinden. Inlining CSS macht manchmal auch Sinn. Google verwendet Inlining, sie inline CSS, JS und leere 1x1-Gifs über Datauri.

LabJS wird immer häufiger verwendet und ist eine gute Lösung - es kann auch asynchron eingebunden werden, muss also nicht blockiert werden.

http://blog.getify.com/2010/12/on-script-loaders/ ist vom Autor

http://yepnopejs.com/ ist gerade auf 1.0 umgestiegen und bricht kein neues Webkit ein, im Gegensatz zu LAB und head.js. Das Laden des Skripts ist schwer.

yepnope ist auch als Modernizr.load in Modernizr integriert. http://modernizr.github.com/Modernizr/2.0-beta/

Wir werden also wahrscheinlich bald einen Skript-Loader in h5bp über Modernizr.load haben.

Ich glaube nicht, dass es 1.0 wird, aber sobald ich Modernizr auf 1.8 gebracht habe, werfen wir das in h5bp 1.1. Ja

Hallo Paul

Ich habe eine vorhandene Site portiert, um Ihr H5BP zu verwenden, und möchte den Skriptlader yepnope.js verwenden. Es ist wirklich schön zu sehen, wie all die Bits und Bots so zusammengestellt wurden, wie Sie es getan haben.

Was würden Sie derzeit empfehlen?

1. Fügen Sie yepnope.js zusammen mit modernizer.js oben auf der Seite ein
2. Fügen Sie es unten auf der Seite ein, damit es geladen wird, nachdem der HTML-Code vollständig geladen wurde.
3. Verwenden Sie die Beta-Version von modernizer.js
4. Ich könnte yepnope.js mit modernizer.js zu einem Include verketten.

Unabhängig davon, wie Sie es am besten einbinden, wie empfehlen Sie das Laden der Skripte mit yepnope,js?

Ich denke, wir sollten es hier tun: https://github.com/paulirish/html5-boilerplate/blob/master/index.html#L52 und verwenden Sie yepnope, um die CDN / Local-Kopie von jQuery und unseren anderen Skripten zu laden.

Aber denken Sie, dass es am besten ist, ein externes Skript zu verwenden oder einen Skriptblock innerhalb des HTML-Codes zu rendern, der dann die Skripte über yepnope.js lädt?

Vielen Dank.

Andy

Ach und noch was.

Da Yepnope CSS per laden kann, würde ich sagen, dass es am besten ist, das Haupt-CSS wie gewohnt einzubinden und Yepnope zu verwenden, um nur CSS für bestimmte Fixes einzubinden.

Zum Beispiel einschließlich einiger CSS, die nur auf ältere Versionen von IE angewendet werden.

Hokapoka,

Verwenden Sie die Beta-Version von modernizr.. Fügen Sie einfach das ein, was Sie benötigen (und fügen Sie Modernizr.load() ) und fügen Sie es dann oben auf der Seite ein.

Der eigentliche Code für den jquery-Fallback mit yepnope befindet sich auf http://yepnopejs.com/

Und ja, ich mag Ihre Vorstellung von der bedingten Belastung von IE CSS.

tbh es gibt zu viel blindes Vertrauen in Bezug auf die Leistung von Skriptladern und ich glaube nicht, dass wir bereit sind zu sagen, dass dies der richtige Weg ist.

Wir brauchen mehr Forschung zu Dateigrößen, Bandbreite und Netzwerkbedingungen, die auf intelligente Empfehlungen zum Laden von Skripten hinweisen, aber im Moment ist das Feld im Entstehen und wir wären naiv, eine Pauschallösung für das Laden von Skripten zu empfehlen.

so.

Schließen Sie dieses Ticket und bitten Sie jeden, der sich dafür interessiert, die umfassenden Recherchen und Veröffentlichungen durchzuführen, die erforderlich sind, um es Entwicklern zu erleichtern, eine kluge Wahl zu diesem Thema zu treffen

Ich habe ziemlich viel über Concat vs. Parallel Load recherchiert. Ich empfehle dennoch ohne Vorbehalt, zuerst alle js in einer Datei zu kombinieren, sie dann in 2-3 gleich große Blöcke aufzuteilen und diese parallel zu laden.

Ich würde gerne meine Forschungen nutzen und sie weit verbreiten und skalieren, damit sie in diesem Bereich als "Tatsache" tragfähig wäre. Das Problem ist, dass ich versucht habe, Hosting-Bandbreite zu finden, bei der es mich nicht viel kostet, die Tests tatsächlich in großem Maßstab durchzuführen, und ich habe diese Hosting-Bereitstellung noch nicht gefunden.

Wenn ich/wir das Bandbreitenproblem zum Testen lösen können, habe ich die Tests, die durchgeführt werden können, um herauszufinden, ob die Theorie des parallelen Ladens tatsächlich praktikabel ist (wie ich glaube).

@getify was brauchst du als Prüfstand?

Ich kann ungefähr 1,5 TB mehr Daten aus meinem persönlichen Server herausholen, als ich derzeit verwende. Ich habe Nginx installiert und das kann ungefähr 4 Billionen Billiarden Treffer pro Mikrosekunde verarbeiten. Ich habe nicht das Gefühl, dass die Technologie hier die Barriere ist.

Wenn wir uns über Standorte Sorgen machen, können wir eine höhere Latenz vortäuschen und/oder ein paar andere Leute mit etwas mehr Platz auf ihren Boxen finden.

Übrigens, ich nehme ein kleines Problem mit "blinden Glaubens".

Es ist einfach, nachweisbar und fast ohne Frage wahr, dass, wenn Sie eine bestehende Site haben, die viele Skripte mit Skript-Tags lädt, die Verwendung eines parallelen Skriptladers (ohne weitere Änderungen) die Leistung verbessert. Dies ist wahr, weil selbst die neuesten Browser das Laden von Skripten vom Blockieren von DOM-ready nicht lösen können (und dies glaube ich auch nie tun werden). Selbst im besten Fall beim Laden des Browsers, wenn es keinen anderen Vorteil gibt, ist die drastische Beschleunigung der DOM-Bereitschaft auf einer Site fast immer ein Gewinn (für Benutzer und UX).

Ihre Aussage ist ein bisschen falsch, weil sie davon ausgeht, dass wir versuchen, für jede Site das parallele Laden mit dem Skript-Concat zu vergleichen. Die meisten Websites im Web können/können Script-Concat nicht verwenden, daher ist der Vergleich (für sie die Mehrheit) nicht ganz so nuanciert und kompliziert, wie Sie annehmen. Wenn sie script-concat (aus welchen Gründen auch immer) nicht verwenden können/können, ist der Vergleich einfach: Paralleles Laden ist fast immer ein Gewinn gegenüber Skript-Tags.

Wenn sie offen für Script-Concat sind (oder es bereits verwenden), dann ja, es wird etwas nuancierter/komplizierter zu entscheiden, ob paralleles Laden helfen könnte oder nicht. Aber script-concat ist auch keine Universallösung für alle, daher gibt es viele Websites, für die das parallele Laden der bevorzugte und beste Ansatz bleibt.

Nur weil einige Sites sich mit den Nuancen/Kompliziertheiten der Entscheidung zwischen Parallel-Loading vs. Script-Concat beschäftigen, bedeutet das nicht, dass die größere (einflussreichere) Diskussion über Parallel-Loading vs. Script-Tags in der Mischung verloren gehen sollte. Ersteres ist schwer zu beweisen, letzteres ist an dieser Stelle fast schon gegeben.

All dies soll sagen, dass, alles in allem, IMHO ein Musterbeispiel ein Muster ermutigen sollte, das den größten Einfluss in eine positive Richtung hat. Wenn 80 % der Websites im Internet heute Skript-Tags verwenden, von denen die meisten davon profitieren würden, von Skript-Tags zum Parallelladen zu wechseln, dann ist Parallelladen ein sehr guter Ausgangspunkt für die Boilerplate.

Es ist ein viel kleinerer (aber wichtiger) Unterabschnitt dieser Sites, der möglicherweise noch mehr Nutzen aus der Untersuchung von Skript-Concat vs. Parallel-Loading ziehen kann. Aber ein kleiner Anwendungsfall ist nicht das, was in einer Boilerplate optimiert werden sollte.

Nur meine paar Cent.

@paulirish @slexaxton --

Was den Bandbreitenbedarf anbelangt, schätzte ich, dass es ungefähr so ​​wäre, wenn 10.000 Leute (was meiner Meinung nach für eine genaue Stichprobe erforderlich war) den Test einmal ausführen würden (und viele Leute würden ihn sicher mehrmals ausführen). 200 GB Bandbreite ausgegeben. Für manche Leute ist das ein Tropfen auf den heißen Stein. Für mich würden 200 GB Bandbreite in wenigen Tagen meine Server-Hosting-Kosten überfordern. Daher habe ich die Skalierung der Tests nicht allein aus diesem Grund verfolgt.

Darüber hinaus habe ich mehr als ein Dutzend Variationen dieses Tests, die wir meiner Meinung nach untersuchen müssen. Also, Dutzende Male 100-200 GB Bandbreite zu verwenden, wäre für mich ziemlich unerschwinglich, um die Rechnung zu bezahlen. Ich wollte diesen Weg nicht einschlagen, wenn ich nicht sicher war, dass ich genug Bandbreite hatte, um die Aufgabe zu erledigen.

Es sind nur statische Dateien, und die Tests erfordern nicht viele gleichzeitige Benutzer, daher gibt es keine wirklichen Bedenken hinsichtlich herkömmlicher Skalierungsprobleme wie CPU usw. Nur Bandbreite, das ist alles.

Wir können den Rest der Diskussion der Tests offline nehmen und per E-Mail oder IM verfolgen. Ich würde sehr gerne endlich die Tests skalieren und dieses Thema "regeln". Es hängt jetzt seit fast einem Jahr im hinteren Teil meines Gehirns.

Ich kann unbegrenzt TB auf meinem Dreamhost-VPS machen, also wird dies kein Problem sein. Im Moment mache ich 72 GB/Tag und kann viel mehr verarbeiten. :)

Ich stimme Paul zu und denke, dass es einige Fehlinformationen darüber gibt, wie und wann Skriptlader für jeden von Nutzen sein werden.

In Ihrem ersten Absatz heißt es, dass es "einfach", "beweisbar" und "ohne Frage" ist, dass Skriptlader die Leistung verbessern.

Ich habe @jashkenas vor einiger Zeit eine ähnliche

https://github.com/SlexAxton/AssetRace

Der Code ist alles da. Offensichtlich gab es kein großes Testpublikum, aber die Ergebnisse zeigten bestenfalls, dass dieser Skript-Loader ungefähr die gleiche Geschwindigkeit wie die Concat-Methode hatte (wobei Ihre Richtlinien für das parallele Laden von 3 Dateien ähnlicher Größe befolgt wurden) und im schlimmsten Fall zeigten, dass Skript- Lader variierten viel stärker und waren im Allgemeinen mit einer Fehlergrenze langsamer. Zögern Sie nicht und finden Sie eine Lösung, die unsere oder beide schlägt, auch wenn sie sich nur auf Ihrem Computer in einem Browser befindet.

Was die "falsche Prämisse" angeht, da h5bp davon ausgeht, dass die Leute ihre js verketten. Dieses Argument ist völlig ungültig, da h5bp ein Skripterstellungstool bietet, komplett mit Concat und Minimierung. Das Argument, dass paralleles Laden fast immer ein Gewinn gegenüber mehreren Skript-Tags ist, mag wahr sein, aber es ist nicht besser als das, was h5bp derzeit bietet. Das ist der Kontext dieser Diskussion.

Ich denke, das Worst-Case-Szenario ist, dass Leute etwas wie yepnope oder lab.js nehmen und es als Skript-Tag-Polyfill verwenden. Das führt absolut zu einem langsameren Laden (der 19 JS- und 34 CSS-Dateien) sowie zu einer Reihe von Problemen mit der Abwärts- und Vorwärtskompatibilität, die ihnen völlig unbekannt sind.

Ich denke, in dem Sinne, den Leuten die sinnvollste und leistungsfähigste und kompatibelste Standardeinstellung für eine _Boilerplate_ zu geben, geht ein Build-Tool viel weiter, um alle drei zu gewährleisten.

@slexaxton

... die Ergebnisse zeigten bestenfalls, dass dieser Skript-Loader ungefähr die gleiche Geschwindigkeit wie die Concat-Methode hatte (wobei Ihre Richtlinien für das parallele Laden von 3 Dateien ähnlicher Größe befolgt wurden) ...

Ich werde gerne etwas Zeit finden, um einen Blick auf die von Ihnen zusammengestellten Tests zu werfen. Ich bin mir sicher, dass Sie wissen, was Sie tun, also bin ich sicher, dass Ihre Tests gültig und korrekt sind.

OTOH, ich habe viele widersprüchliche Beweise. Wenn ich jemals etwas zwingendes gesehen hätte, das darauf hindeutet, dass das parallele Laden von Skripten für die meisten Websites eine Verschwendung oder nicht hilfreich ist, hätte ich die verrückte Zeitsenke LABjs schon vor langer Zeit aufgegeben.

Ich kann mit 100%iger Sicherheit sagen, dass ich in 2 Jahren, in denen ich geholfen habe, LABjs für die Leute herauszubringen, noch nie eine Situation gefunden habe, in der LABjs langsamer war als die Skript-Tag-Alternative. Nullmal ist mir das jemals passiert. Es gab ein paar Mal, dass Leute sagten, dass sie keinen großen Nutzen sehen. Es gab einige Male, in denen Leute mehr als 100 Dateien luden und der verrückte Overhead dieser vielen Verbindungen alle Vorteile zunichte machte, die sie sonst vielleicht gesehen hätten. Aber mir hat noch nie jemand gesagt, dass LABjs ihre Site langsamer gemacht hat.

Ich selbst habe buchstäblich mehr als 50 verschiedenen Sites geholfen, von Skript-Tags zu LABjs zu wechseln, und die Sites sahen auf Anhieb Leistungsverbesserungen. Zu Beginn der Bemühungen nahm ich eine Stichprobe von vielleicht 7 oder 8 Websites, denen ich geholfen hatte, und sie hatten insgesamt eine durchschnittliche Verbesserung der Ladegeschwindigkeit von etwa 15 % festgestellt. Für die 4 oder 5 Sites, die ich verwalte, habe ich natürlich LABjs implementiert und sofort die 3-fache Ladegeschwindigkeit gesehen.

Als LABjs zum ersten Mal veröffentlicht wurde, war es natürlich Stand der Technik, dass Browser Skripte parallel laden (nur wenige taten das). Die Gewinne waren also riesig und sichtbar. Jetzt haben fast alle Browser paralleles Laden, also sind die Gewinne nicht mehr so ​​drastisch.

Aber unbestreitbar ist, dass alle Browser das DOM-ready-Ereignis zum Laden von Skript-Tags blockieren. Sie _müssen_ wegen der Möglichkeit, document.write() . Paralleles Laden von Skripten bedeutet im Wesentlichen "Browser, ich verspreche, dass Sie sich nicht mit document.write befassen müssen, also fahren Sie mit der Seite fort".

Schauen Sie sich die beiden Diagramme auf Folie 10 dieses Decks an:

http://www.slideshare.net/shadedecho/the-once-and-future-script-loader-v2

Vergleichen Sie die Platzierung der blauen Linie (DOM-ready). Dies ist eine drastische Verbesserung der wahrgenommenen Leistung (UX), auch wenn die Gesamtladezeit der Seite (oder die Zeit zum Beenden des Ladens aller Assets) nicht besser ist.

...h5bp bietet ein Skript-Build-Tool...

Die falsche Annahme hier ist, dass alle (oder sogar die meisten) Benutzer von h5bp es verwenden können, nur weil h5bp dieses Tool anbietet. Selbst wenn 100 % der Benutzer von h5bp es _do_ verwenden, bedeutet dies nicht, dass, wenn h5bp in den Long-Tail des Internets eingeführt würde, alle dieses Concat-Tool verwenden würden. Es gibt eine Reihe anderer Faktoren, die jemanden leicht daran hindern können, dies zu verwenden. Es gibt _sehr wenige_ Gründe, warum jemand nicht von der Verwendung von Skript-Tags zu einem parallelen Skript-Loader wechseln kann.

Als solches bietet das parallele Laden von Skripten immer noch eine breitere Anziehungskraft auf das Longtail des Internets. Für die meisten Websites, die keine Optimierungen beim Laden von Skripten verwenden, ist es immer noch einfacher, von nichts zu etwas zu wechseln, und etwas bietet ihnen Leistungsgewinne. Nur wenige dieser Long-Tail-Sites werden jemals die Mühe aufwenden (oder die Fähigkeit haben, damit zu experimentieren) automatisierte Skripterstellungstools in ihren billigen 6-Dollar/Monat-, Massen-Shared-Hosting- und Nicht-CDN-Webhosting-Umgebungen.

Ich denke, das Worst-Case-Szenario ist, dass Leute etwas wie yepnope oder lab.js nehmen und es als Skript-Tag-Polyfill verwenden. Das wird definitiv zu einem langsameren Laden führen ...

Ich könnte dieser Aussage nicht mehr widersprechen. LABjs wurde speziell als Skript-Tag-Polyfill entwickelt. Und die Verbesserungen von LABjs gegenüber regulären Skript-Tags (vorerst ignorieren Sie Skript-Concat) sind gut etabliert und wurden nie ernsthaft widerlegt. Wenn Sie den Beweis haben, dass die meisten (oder sogar viele) Websites, die LABjs verwenden, besser zu Skript-Tags zurückkehren sollten, teilen Sie dies bitte mit.

Es gibt absolut keinen Grund, warum das parallele Laden von Skripten zu einem langsameren Laden führt als das, was der Browser mit Skript-Tags erreichen könnte. Das macht keinen Sinn. Und wie ich oben festgestellt habe, blockieren Skript-Tags immer DOM-bereit, während das parallele Laden von Skripten nicht möglich ist.

eine Reihe von Problemen mit der Rückwärts- und Vorwärtskompatibilität einführen, die ihnen völlig unbekannt sind.

Von welchen Kompatibilitätsproblemen sprichst du? Die Browser-Support-Matrix von LABjs deckt die überwiegende Mehrheit aller Webbrowser der Welt ab. Die verrückte kleine Anzahl von Browsern, in die es einbricht, wird bei weitem durch die große Anzahl von Browsern aufgewogen, in denen es klare Vorteile hat.

LABjs 1.x enthielt eine Reihe verrückter Hacks, wie das Vorladen des Caches, die in der Tat ein großes Problem für das Brechen mit Browsern waren. LABjs 2.x hat das komplett auf den Kopf gestellt und verwendet nun in allen Fällen zuverlässige und standardisierte Ansätze für das parallele Laden und greift nur auf den Hack für den älteren Webkit-Browser zurück. Darüber hinaus enthält LABjs 2.x bereits Checks für Feature-Tests von kommenden Skriptladetechniken (hoffentlich bald standardisiert) wie "real preloading".

Ich kann nicht definitiv für andere Skriptlader sprechen – ich weiß, dass viele immer noch Hacks verwenden – aber was LABjs angeht, bin ich verwirrt über die Behauptung, dass es Vorwärts- oder Rückwärtskompatibilitätsprobleme einführt, da ich denke, dass dies offensichtlich irreführend ist Anspruch.

um ein wenig zu erläutern, warum ich beabsichtige, dass LABjs tatsächlich ein Skript-Tag-Polyfill sein soll ...

1. ältere Browser sind eindeutig im Umgang mit dem Laden von Skript-Tags VIEL unterlegen, das paralleles Laden verarbeiten kann. In diesen "älteren Browsern" (die die neuesten/besten waren, als LABjs vor 2 Jahren auf den Markt kam) sahen wir die ~3x-Verbesserungen der Seitenladezeit. Das macht LABjs fast per Definition zu einem besseren Polyfill für Skript-Tags, da es Browsern, die es selbst nicht unterstützen, eine Funktion (dh die Leistung des parallelen Ladens) bietet.
2. neuere Browser sind offensichtlich viel besser. aber sie haben die Vorteile von Skriptladern nicht vollständig beseitigt. Chrome noch vor v12 (ich denke, sie wurden anscheinend in v13 endlich behoben) blockierte immer noch das Laden von Bildern, während das Laden der Skript-Tags abgeschlossen war. selbst mit den neuesten Versionen von IE, Firefox und Chrome blockieren sie alle immer noch DOM-ready, während Skripte dynamisch geladen werden, weil sie alle immer noch pessmistisch annehmen müssen, dass document.write() lauern könnte.

Für die neueren Browser ist LABjs also ein "Polyfill" in dem Sinne, dass es "das Laden von nicht DOM-bereiten blockierenden Skripten" auf eine Weise in den Browser bringt, die Skript-Tags nicht können. Die einzige Möglichkeit, dies in modernen Browsern ohne einen parallelen Skriptlader zu erreichen, wäre die Verwendung von Skript-Tags mit defer ( async offensichtlich nicht funktionieren, da die Reihenfolge nicht beibehalten wird). . defer hat jedoch eine Reihe von Macken, und seine Unterstützung ist nicht weit genug verbreitet, um eine praktikable Lösung zu sein (der Fallback für Nicht-Aufschub ist schlechte Leistung). Man könnte also sagen, dass LABjs im einfachsten Fall ein Polyfill für die Leistungsmerkmale des Skript-Tags defer (wenn auch nicht genau).

Ehrlich gesagt denke ich immer noch, dass wir Standards für ein Skriptladeobjekt beantragen sollten. Ein Skript-Tag eines anderen Typs als Text/Javascript erstellen zu müssen, um den Cache auszulösen (oder, schlimmer noch, ein Objekt-Tag oder ein Bildobjekt oder was auch immer eine neue Version eines gängigen Browsers erfordert) zu verwenden, ist umsonst zu springen und die Leistung hängt von zu vielen Variablen ab. Ich kann verstehen, dass wir Stylesheets immer noch mit dem Einfügen von dom-Knoten laden (aber das ist nur wegen der Reihenfolge), aber wenn es um Skripte geht, denke ich, dass es überhaupt keinen Sinn mehr macht (ich wünschte, Google würde aufhören, document.write in den meisten Fällen zu verwenden? ihre Skripte, aber das ist eine ganz andere Geschichte).

Außerdem denke ich, dass wir hier den größten Punkt in Bezug auf Skriptlader übersehen: js-Code bei Bedarf laden zu können, anstatt alles im Voraus zu laden (selbst wenn alles im Cache ist, braucht das Parsen und Initialisieren Zeit und es kann schön werden hässlich mit einer nicht trivialen Menge an verketteten Skripten). Nach einer UI-Interaktion eine gewisse Wartezeit zu haben, ist viel weniger problematisch, als wenn der Browser beim Start auch nur ein wenig "hängt" (DOM ist möglicherweise schon fertig, aber was nützt es, wenn der Code zur Verbesserung der Seite verwendet wird?) und iteraction hinzufügen wurde noch nicht ausgeführt: Haben Sie schon einmal bemerkt, wie manche Sites sofort geladen werden und dann etwas Klobiges passiert?).

Eine strenge Leistungsmessung ist also in Ordnung und gut, aber ich denke immer noch, dass die wahrgenommene Leistung das ultimative Ziel ist ... und leider viel weniger einfach zu schätzen/optimieren/berechnen.

Das ist intensiv.

@jaubourg--

Ehrlich gesagt denke ich immer noch, dass wir Standards für ein Skriptladeobjekt beantragen sollten.

Es gibt viele Petitionen, wie die Standards/Spezifikationen und Browser uns eine bessere Technik zum Laden von Skripten bieten können. Der erste große Gewinn in dieser Kategorie seit Jahren war das "Ordered Async" ( async=false ), das bereits im Februar eingeführt wurde und jetzt in jedem großen aktuellen Browser verfügbar ist (Ausnahme: Opera kommt sehr bald und IE10p2 hat es) ).

Die nächste Debatte, über die ich derzeit mit Ian Hickson spreche, ist das, was ich "echtes Preloading" nenne. Meiner Meinung nach wäre "real preloading" (das der IE übrigens bereits seit v4 unterstützt) einer "Wunderwaffe" am nächsten, die fast alle Skript-Lade-Szenarien ziemlich trivial lösen würde. Ich bin immer noch recht optimistisch, dass wir so etwas standardisiert sehen werden.

Weitere Informationen finden Sie in diesem Wiki: http://wiki.whatwg.org/wiki/Script_Execution_Control

Sie müssen ein Skript-Tag eines anderen Typs als Text/Javascript erstellen, um den Cache auszulösen (oder schlimmer noch, verwenden Sie ein Objekt-Tag oder ein Bildobjekt oder was auch immer eine neue Version eines gängigen Browsers erfordert).

Dies wird als "Cache-Vorladen" bezeichnet und ist ein zugegebener hässlicher und schrecklicher Hack. LABjs Weg reduziert dies jetzt ab v2 (verwendet es nur als Fallback für ältere Webkits). Andere Skriptlader verwenden es leider immer noch als primären Lademechanismus. Aber 90% des Bedarfs an "Cache-Preloading" kann mit "Ordered Async" gelöst werden, das standardisiert und kein Hack ist, also sollten gut erzogene Skriptlader dies jetzt dem "Cache-Preloading" vorziehen.

Ich stimme also zu, dass "Cache-Vorladen" scheiße ist, aber es gibt viel bessere Möglichkeiten, document.createElement("script") verwenden, die solche Hacks nicht beinhalten Skript lädt. Wenn wir "echtes Preloading" erreichen können, ist das Script-Element alles, was wir brauchen. Das glaube ich ehrlich gesagt.

Ich denke, wir verpassen hier den größten Punkt in Bezug auf Skriptlader: js-Code bei Bedarf laden zu können

Ich stimme sehr zu, dass dies ein wichtiger Vorteil ist, den Skriptlader mit sich bringen. Aber es ist irgendwie ein strittiges Argument in _diesem_ Thread, weil die "Skript-Concat"-Leute den Anwendungsfall ohne das Laden des Skripts einfach nicht lösen können, daher macht es keinen Sinn, die beiden zu "vergleichen". Sie können als Befürworter von "Skript-Concat" sagen "Gut, dieser Anwendungsfall ist uns egal", aber Sie können nicht sagen "Wir können diesen Anwendungsfall mit XYZ besser bedienen".

Die wahrgenommene Leistung _ist_ riesig und wichtig, da stimme ich zu. On-Demand-Laden ist ein großer Teil davon. Das Laden bei Bedarf verbessert auch die tatsächliche tatsächliche Leistung (nicht nur die Wahrnehmung), da es dazu führt, dass weniger tatsächlich heruntergeladen werden, wenn Sie nur das herunterladen, was benötigt wird (wenige Seitenbesuche erfordern 100% des von Ihnen geschriebenen Codes).

Die wahrgenommene Leistung ist auch der Grund, warum ich das obige Argument von DOM-ready befürworte. Denn wie schnell ein Benutzer das Gefühl hat, mit einer Seite interagieren zu können, ist _sehr_ wichtig dafür, wie schnell die Seite seiner Meinung nach ist (unabhängig davon, wie schnell sie wirklich geladen wird). Das ist eine Tatsache, die durch viele Benutzerforschungen festgestellt wurde.

Ich liebe die leidenschaftlichen, langen Kommentare von @getify
Kyle ...

Wenn ich in irgendeiner Weise zur Forschung beitragen kann, würde ich das _liebe_ tun.
Bandbreite (Kosten) scheint nicht das Problem zu sein, also @getify , was schlagen Sie für die
Zögern Sie nicht, mich per E-Mail (aaron [at] aaronpeters [dot] oder twitter (@aaronpeters)

@Kyle

Ja, ich bin der Diskussion über die "Erweiterungen" des Skript-Tags bezüglich des Vorabladens gefolgt und kaufe den Ansatz "Noch ein weiteres Attribut zum Skript-Tag hinzufügen" einfach nicht als praktikablen Ansatz. Ich habe gesehen, was es mit der xhr-Spezifikation gemacht hat: viel Komplexität in Bezug auf den geringen Nutzen, den wir am Ende erhalten.

Klar ist, dass wir das Preloading-Verhalten so ziemlich nur beim dynamischen Einfügen benötigen (dh bereits in Javascript). Es ist nicht so, dass wir das Tag dort behalten oder als DOM-Knoten verwenden: Es ist nur ein Mittel zum Zweck, das nichts mit der Dokumentstruktur zu tun hat.

Ich würde mich mit etwas in dieser Richtung viel wohler fühlen:

window.loadScript( url, function( scriptObject ) {
    if ( !scriptObject.error ) {
        scriptObject.run();
    }
});

Dies würde Wunder bewirken. Es ist ganz einfach, mehrere Skript-Ladeereignisse zu "verknüpfen" und diese Skripte dann in beliebiger Reihenfolge auszuführen. Es impliziert auch nicht das Vorhandensein eines DOM, was es noch allgemeiner macht. Ich wünschte, wir würden so schnell wie möglich von der Skript-Tag-Injection wegkommen. Außerdem ist es einfach genug, dies mit den Tricks, die wir alle kennen, zu polyfillen. Es ist auch viel weniger belastend als ein komplettes Anforderungssystem (kann aber ein Baustein für ein Anforderungssystem sein, das dann nicht auf Browser beschränkt ist).

Davon abgesehen stimme ich dir bezüglich der wahrgenommenen Leistung zu 100% zu, ich wollte nur darauf hinweisen, weil das Mantra "Lass uns alles zusammen packen" schnell zu einer Art Glaubenssatz wird, der die Dinge für meinen Geschmack viel zu sehr verwischt ;)

fwiw, defer wird in IE4+, Chrome, Safari und FF 3.5+ unterstützt. Wird von Opera nicht unterstützt.

Das bedeutet also.... 98,5% der Benutzer haben bereits script@defer Support.

@getify

defer hat jedoch eine Reihe von Macken,

Details bitte? davon habe ich noch nichts gesehen

Werden Skripte mit Verzögerung ausgeführt, bevor oder nachdem DOM-Ready-Ereignisse ausgelöst werden?

Wird die Ausführungsreihenfolge in allen Browsern beibehalten?

Wie wäre es mit der Ausführung von Execs und der Kopplung von extern mit Inline-Skripten?

@paulirish--

...98,5% der Benutzer haben bereits script@defer- Unterstützung.

Unterstützung kann in so vielen Browsern vorhanden sein, aber das bedeutet nicht, dass sie in so vielen Browsern zuverlässig ist. Das ist es was ich meinte. (siehe unten)

Defer hat jedoch eine Reihe von Macken,

Details bitte? davon habe ich noch nichts gesehen

Lass mich sehen... IIRC:

1. Die Unterstützung von Defer für dynamische Skriptelemente wird in keinem Browser definiert oder unterstützt ... funktioniert nur für Skript-Tags im Markup. Dies bedeutet, dass es für die "On-Demand"- oder "Lazy-Loading"-Techniken und Anwendungsfälle völlig nutzlos ist.
2. Ich glaube, es gab einen Fall, in dem in einigen Browsern verzögerte Skripte direkt vor dem Auslösen von DOM-ready ausgeführt wurden, und bei anderen sofort nach dem Auslösen von DOM-ready. Muss noch mehr graben, um genauere Informationen zu erhalten.
3. defer das für ein Skript-Tag verwendet wird, das auf eine externe Ressource verweist, verhielt sich anders als defer das für ein Skript-Tag mit Inline-Code angegeben wurde. Das heißt, es kann nicht garantiert werden, dass beide Skripttypen zurückgestellt werden und sie trotzdem in der richtigen Reihenfolge ausgeführt werden.
4. defer auf einem Skript-Tag, das durch eine document.write() Anweisung geschrieben wurde, unterschied sich von einem Skript-Tag im Markup mit defer .

Ich habe nicht viele Details zu diesen Themen zur Hand. Ich erinnere mich, dass ich vor ungefähr 2 Jahren (vor LABjs) versuchte, defer , und bei Cross-Browser-Tests auf genug davon gestoßen bin, dass ich es im Grunde genommen beiseite gelegt und seitdem nicht mehr wirklich wieder besucht habe.

Ich sollte auch darauf hinweisen, dass defer nicht wirklich dasselbe ist wie das, was LABjs (und andere parallele Lader) bieten. Ich sagte das oben mit der Einschränkung, dass es nur irgendwie so ist. Tatsächlich bietet das parallele Laden von Skripten (zumindest für den Teil von LABjs) "geordnete asynchrone", die absolut nicht nur durch Markup erreicht werden können.

Der Unterschied zwischen "ordered async" und "defer" besteht darin, dass "ordered async" immer noch mit der Ausführung beginnt, sobald das erste angeforderte Skript geladen ist, während "defer" wartet, bis `DOM-ready ist, bevor die Ausführung gestartet wird. Bei einer einfachen Seite mit wenig Markup und keinen anderen blockierenden Markup-Aufrufen (wie bei anderen Skript-Tags) ist dieser Unterschied gering. Aber für eine Seite mit vielen Ressourcen kann es sehr unterschiedlich sein, wann Skripte ausgeführt werden dürfen.

Also, ich möchte ehrlich gesagt nicht zu viel von der Tangente von defer , denn in Wirklichkeit ist dies kein guter Vergleich zu dem, was das parallele Laden von Skripten bietet. Es war nur das naheliegendste Beispiel für Markup, das ich verwenden konnte, um das von mir angestrebte Verhalten bei der Ausführung zu beschreiben. Ich hätte defer wahrscheinlich nicht einmal zur Sprache bringen sollen – bringt nur die Diskussion durcheinander.

Lassen Sie mich es von oben umformulieren: "Für moderne Browser ist LABjs eine Art 'Polyfill' für 'Ordered Async'-Verhalten, für das in keinem Browser nur Markup ausgewählt werden kann."

Ich mag "ordered async", das ist ein guter Satz.

Kyle > afaik, Skripte mit defer werden _before_ onload ausgeführt, noch bevor sie domready sind.
Skripte mit async-Attribut werden so schnell wie möglich und _always_ _before_ onload ausgeführt, aber nicht unbedingt vor domready

@aaronpeters--
Ich glaube, Sie sind vielleicht etwas vom Weg abgekommen. So verstehe ich es:

async Skripte (ob im Markup oder dynamisch erstellt) werden so schnell wie möglich ausgeführt, dh jederzeit vor oder nach DOM-bereit. Mit anderen Worten, async Skripte sollten auf nichts warten (außer auf die Verfügbarkeit der JS-Engine selbst). Wenn sie jedoch vor window.onload angefordert werden, dann "halten" sie in fast allen Browsern das window.onload Ereignis, bis sie geladen und ausgeführt werden. Ich denke, es gab einen dokumentierten Fall, in dem die async Skripte window.onload nicht überlebten, sich nur nicht an die genauen Details erinnerten.

defer hingegen bedeutet konkret: warten bis nach DOM-ready. Außerdem gibt es eine "Warteschlange" aller Skripte, auf denen defer gesetzt ist, so dass die Warteschlange erst nach DOM-ready verarbeitet wird das DOM ist bereit und fertig geparst, um genau zu sein). Sie können sich jedoch noch weiter verzögern (bei langsamem Laden). Sie sollten jedoch window.onload . Ich erinnere mich nur aus vagem Gedächtnis, dass in einigen Versionen von IE die tatsächliche Praxis dieser Theorie ein wenig verschwommen war.

@getify

Ich wollte diesen Thread nicht noch mehr entgleisen, also habe ich meine Gedanken zum Vorladen von Skripten und Ihren Vorschlag auf der WHATWG-Seite hier gepostet: http://jaubourg.net/driving-a-nail-with-a-screwdriver-the-way -Netz

async Skripte (ob im Markup oder dynamisch erstellt) werden so schnell wie möglich ausgeführt, dh jederzeit vor oder nach DOM-bereit. Mit anderen Worten, async Skripte sollten auf nichts warten (außer auf die Verfügbarkeit der JS-Engine selbst). Wenn sie jedoch vor window.onload angefordert werden, dann "halten" sie in fast allen Browsern das window.onload Ereignis, bis sie geladen und ausgeführt werden.

Dies ist wahrscheinlich einfacher zu verstehen, wenn Sie feststellen, dass JavaScript Single-Threaded ist. (Ich weiß, es hat eine Weile gedauert…)

Wenn Sie setTimeout(fn, 0) , um Ressourcen herunterzuladen, und diese in die Download-Warteschlange eintreten, bevor onload ausgelöst wird, verzögert das Laden dieser Ressourcen (noch) onload .

Ich denke, es gab einen dokumentierten Fall, in dem die async Skripte window.onload nicht überlebten, sich nur nicht an die genauen Details erinnerten.

Ich würde gerne mehr Infos dazu bekommen. Bitte denk daran! :)

Yay Skriptlader!

Ein Problem, das ich bei der Implementierung im AOL-Netzwerk von Sites hatte, war der Umgang mit Race-Conditions. Laden Sie beispielsweise jQuery asynchron in den Kopf und sagen Sie dann ein jQuery-Plugin mitten im Dokument, das asynchron in einem Blog-Post bereitgestellt wird.

Daher habe ich mein eigenes Skript-Loader-Wissenschaftsprojekt (Boot.getJS) gestartet, um damit umzugehen. Die Idee ist, alle Skripte parallel herunterzuladen und sie so schnell wie möglich in der richtigen Reihenfolge auszuführen. Es unterstützt auch das Verzögern des Bereitens oder Ladens und das Zwischenspeichern von Skripten. Die meisten Ideen wurden von Leuten in diesem Thread ausgeliehen (gestohlen), also danke Leute. :)

Da Sie über Benchmarks gesprochen haben, dachte ich, ich würde eine Testseite teilen, die ich erstellt habe, um die Unterschiede in Leistung, Syntax und Verhalten der verschiedenen Skriptlader zu verstehen. Schauen Sie sich hier an:

http://artzstudio.com/files/Boot/test/benchmarks/script.html

Um zu sehen, wie sich verschiedene Loader verhalten, leeren Sie den Cache und beobachten Sie die Netzwerkanforderungen und die letzte Zeit sowie die Reihenfolge, in der die Skripte ausgeführt werden.

Dave (@artzstudio), txs für das Teilen deiner Gedanken und den Link zu deiner Testseite.

Frage: Warum laden Sie LABjs auf der Seite '<script> tag in head'? Das scheint falsch zu sein.

@artzstudio auch, Sie verwenden eine alte Version von LABjs. Ist das beabsichtigt? Wenn ja warum?

@aaronpeters Bei AOL haben wir Skripte wie Omniture und einen Anzeigencode (und mehr), die in den Kopf gehen müssen, also geht die Loader-Bibliothek in unserem Anwendungsfall dorthin. Auch wenn Skripte ganz unten sind, gibt es in einigen unserer Widgets ein FOUC-Problem. Je früher Abhängigkeiten geladen werden (wie jQuery), desto besser.

Es war nicht beabsichtigt, dieser Test ist ein paar Monate alt. Ich werde die Bibliotheken bei Gelegenheit aktualisieren.

Zu Ihrer Information (hoffe, das ist etwas interessant/relevant), ich habe ein paar Tests auf Webpagetest.org durchgeführt, um zu sehen, was im IE8 passiert, wenn einige der @artzstudio- Testseiten
Skript-Tags: http://www.webpagetest.org/result/110810_C7_752b756180e132f50a3ef065e9e059ca/
Ja: http://www.webpagetest.org/result/110810_8S_a53f4ed2e16179c328fc57c572e71076/
LABjs: http://www.webpagetest.org/result/110810_ZV_1ece92044799e52ed5199aed6b407133/
RequireJS: http://www.webpagetest.org/result/110810_Z3_a1537e41a0b0570286151859973d0cfa/

Video zum Vergleich von Yepnope und LABjs: http://www.webpagetest.org/video/view.php?id=110810_074cb94c1b04a7ac9bd6538ec3fdd8d3c07f842d

Einige Notizen:

• Gzip ist auf dem Server deaktiviert, daher wirkt sich die größere Dateigröße von RequireJS aus
• Wie bereits erwähnt, lädt die Script-Tags-Seite LABjs in den HEAD (macht keinen Sinn) und das hat natürlich Auswirkungen

Aus diesen beiden Gründen habe ich ein Video erstellt, das nur Yepnope und LABjs zeigt.

Interessant finde ich, dass die Start-Render-Zeit für LABjs viel besser ist. Warum ist das so? Würde gerne besser verstehen.

Schlussbemerkung: Ich poste dies nicht mit dem Ziel, LABjs gegenüber Yepnope oder ähnlichem zu bevorzugen. Einfach Daten teilen...

Entschuldigung, ich verstehe, was Sie mit den LABjs im <script>-Test meinten. Jetzt behoben, zusammen mit einem Upgrade auf LABjs.

@artzstudio--

Daher habe ich mein eigenes Skript-Loader-Wissenschaftsprojekt (Boot.getJS) gestartet, um damit umzugehen. Die Idee ist, alle Skripte parallel herunterzuladen und sie so schnell wie möglich in der richtigen Reihenfolge auszuführen

Wussten Sie also, dass LABjs _genau_ dafür entwickelt wurde und sehr gut funktioniert (wenn ich das selbst sage)? Was ich meine ist, wollten Sie nur eine andere API oder was war mit der parallelen Skriptladefunktionalität nicht ausreichend?

Auf jeden Fall, so sehr ich es auch liebe, mit LABjs zu prahlen, denke ich nicht, dass es effektiv ist, diesen Thread mit Diskussionen vom Typ "Schau, mein Skriptlader ist besser bei X" zu verzetteln. Diese Diskussionen sind nützlich, aber woanders.

Am Ende läuft die gesamte Skript-Loader-Technologie auf ein paar einfache Ideen hinaus. Egal, welche Art von ausgefallener API Sie darüber legen oder welche Anwendungsfälle Sie bedienen, die Technologie ist dieselbe. Heutzutage muss es 50 verschiedene Skriptlader geben, und keiner von ihnen bietet technisch etwas anderes, nur unterschiedliche APIs. Der Vergleich von APIs ist also wirklich eine ziemlich irrelevante Diskussion.

Worauf wir uns konzentrieren sollten, ist, ob die grundlegende Skriptladetechnologie, die wir derzeit in Browsern zur Verfügung haben, verwendet werden kann, um die Leistung beim Laden von Seiten zu verbessern, verglichen mit der bloßen Verwendung von Skript-Tags im Markup. Dies ist eine lang gehegte Prämisse von mir, die absolut wahr ist, aber diese Prämisse wurde in diesem Thread in Frage gestellt. Aufgabe Nr. 1 besteht also darin, diese Frage zu beantworten.

Wenn wir herausfinden, dass Skript-Tags einfach besser sind als das Laden von Skripten, können wir diesen ganzen Wahnsinn einfach stoppen und alle unsere Projekte schließen. Ich vermute jedoch, dass dies nicht der Fall sein wird. ;-)

Aufgabe #2 ist, ein für alle Mal herauszufinden, ob script-concat immer besser ist als paralleles Laden. Auch hier zeigen meine Prämisse (und meine Tests), dass es gut ist, alle Dateien zu einer zu verketten, aber dann müssen Sie diese große Datei in 2-3 ungefähr gleiche Teile aufteilen und diese Blöcke parallel laden. Also müssen wir diese Theorie auch wirklich testen.

Wenn wir herausfinden, dass Skript-Concat immer am besten ist, sind Skriptlader immer noch nützlich, wenn man bedenkt, dass die meisten Websites Skripte von mehr als einem Ort laden (jquery von Google CDN, Google Analytics von Google, Facebook/Twitter/g+ Schaltflächen , etc). Also müssten wir dann als Aufgabe Nr. 3 feststellen, ob concat so viel besser ist, dass Sie Ihre eigenen Kopien all dieser Dateien hosten und sie mit Ihrem eigenen Code zusammenfügen.

Kyle, können Sie die Quelle meines Beispiels anzeigen und mir mitteilen, wie ich LabJS instrumentieren würde, um alle Skripte auf der Seite der Reihe nach auszuführen (auch außerhalb der Kette)? Ich könnte die API sehr gut falsch gelesen haben (wie Paul sagte, Skriptlader sind schwer, %-).

Am 10. August 2011 um 9:09 Uhr schrieb [email protected] :

@artzstudio--

Daher habe ich mein eigenes Skript-Loader-Wissenschaftsprojekt (Boot.getJS) gestartet, um damit umzugehen. Die Idee ist, alle Skripte parallel herunterzuladen und sie so schnell wie möglich in der richtigen Reihenfolge auszuführen

Wussten Sie also, dass LABjs _genau_ dafür entwickelt wurde und sehr gut funktioniert (wenn ich das selbst sage)? Was ich meine ist, wollten Sie nur eine andere API oder was war mit der parallelen Skriptladefunktionalität nicht ausreichend?

---

Auf jeden Fall, so sehr ich es auch liebe, mit LABjs zu prahlen, denke ich nicht, dass es effektiv ist, diesen Thread mit Diskussionen vom Typ "Schau, mein Skriptlader ist besser bei X" zu verzetteln. Diese Diskussionen sind nützlich, aber woanders.

Am Ende läuft die gesamte Skript-Loader-Technologie auf ein paar einfache Ideen hinaus. Egal, welche Art von ausgefallener API Sie darüber legen oder welche Anwendungsfälle Sie bedienen, die Technologie ist dieselbe. Heutzutage muss es 50 verschiedene Skriptlader geben, und keiner von ihnen bietet technisch etwas anderes, nur unterschiedliche APIs. Der Vergleich von APIs ist also wirklich eine ziemlich irrelevante Diskussion.

Worauf wir uns konzentrieren sollten, ist, ob die grundlegende Skriptladetechnologie, die wir derzeit in Browsern zur Verfügung haben, verwendet werden kann, um die Leistung beim Laden von Seiten zu verbessern, verglichen mit der bloßen Verwendung von Skript-Tags im Markup. Dies ist eine lang gehegte Prämisse von mir, die absolut wahr ist, aber diese Prämisse wurde in diesem Thread in Frage gestellt. Aufgabe Nr. 1 besteht also darin, diese Frage zu beantworten.

Wenn wir herausfinden, dass Skript-Tags einfach besser sind als das Laden von Skripten, können wir diesen ganzen Wahnsinn einfach stoppen und alle unsere Projekte schließen. Ich vermute jedoch, dass dies nicht der Fall sein wird. ;-)

Aufgabe #2 ist, ein für alle Mal herauszufinden, ob script-concat immer besser ist als paralleles Laden. Auch hier zeigen meine Prämisse (und meine Tests), dass es gut ist, alle Dateien zu einer zu verketten, aber dann müssen Sie diese große Datei in 2-3 ungefähr gleiche Teile aufteilen und diese Blöcke parallel laden. Also müssen wir diese Theorie auch wirklich testen.

Wenn wir herausfinden, dass Skript-Concat immer am besten ist, sind Skriptlader immer noch nützlich, wenn man bedenkt, dass die meisten Websites Skripte von mehr als einem Ort laden (jquery von Google CDN, Google Analytics von Google, Facebook/Twitter/g+ Schaltflächen , etc). Also müssten wir dann als Aufgabe Nr. 3 feststellen, ob concat so viel besser ist, dass Sie Ihre eigenen Kopien all dieser Dateien hosten und sie mit Ihrem eigenen Code zusammenfügen.

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment -1772315

Man könnte meinen, die Physik sagt, Concat sei das Beste. Jede neue HTTP-Verbindung ist ein weiterer Slow-Start + eine 100-ms-Steuer im schlimmsten Fall vom CDN.

Die Wahrheit über Dokumente ist jedoch, dass sie sehr lang sein können. Das Laden einer BFJS-Datei in den Kopf kann daher die Initialisierung von Modulen unnötig verlangsamen. Das Laden am Ende kann zu lästigem FOUC führen. Große Dateien können Auswirkungen auf Mobilgeräte haben: http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

Ich denke, dies ist das Motiv hinter der "Split the Payload"-Regel von Souders (http://oreilly.com/server-administration/excerpts/9780596522315/splitting-the-initial-payload.html). Wir müssen auch das, was spürbar schneller ist, tun.

Und leider läuft dies darauf hinaus, dass es sich um eine Art Antwort "es kommt darauf an" handelt, die dieses Problem interessant genug macht, um uns alle zu unterhalten.

Ich spiele mit einem hybriden Ansatz herum, bei dem getJS-Aufrufe in die Warteschlange gestellt und regelmäßig in einem festgelegten Zeitintervall verkettet werden, sowie auf Modulabhängigkeitsebene verketten (zum Beispiel Verketten von RequireJS-Abhängigkeiten, anstatt sie einzeln zu laden). alles im Handumdrehen am Front-End.

Es ist ein wissenschaftliches Experiment, das, wie Sie betonen, hoffentlich bald sinnlos sein wird, aber dennoch interessant ist.

@getify : Ich weiß, dass das gepisst , aber trotzdem.

Wenn wir feststellen, dass Skript-Tags einfach besser sind als das Laden von Skripten,
dann können wir diesen ganzen Wahnsinn einfach stoppen und alle unsere Projekte schließen.
Ich vermute jedoch, dass dies nicht der Fall sein wird. ;-)

Ich könnte viele Dinge über Schlangenöl sagen, aber eine Demonstration funktioniert genauso gut:

http://jashkenas.s3.amazonaws.com/misc/snake-oil/labjs.html

http://jashkenas.s3.amazonaws.com/misc/snake-oil/vanilla.html

Das ist eine Seite mit 100.000 Text, 10 Bildern und 171.000 JavaScript. Die Vanilla-Version verwendet eine einzelne minimierte Datei, die jQuery, jQuery-UI, Underscore und Backbone enthält, sowie die Datei timer.js , die die Ergebnisse der Ladezeit ausgibt. Die LABjs-Version lädt jede der 5 (separat minifizierten) JavaScript-Dateien mit LABjs.

Sie werden feststellen, dass die LAB-Version nicht nur keine Vorteile bietet, sondern dass die zusätzlichen HTTP-Anfragen nur die Ladeleistung beeinträchtigen und mit anderen Assets auf der Seite wie Bildern konkurrieren müssen. Aber das alles wurde schon oft gesagt...

Ich kann ein Gegenargument zum Laden Ihrer Skripts in Stücken erwarten ... aber das ist völlig orthogonal zur Skriptladetechnik, also lassen Sie es bitte aus der Diskussion.

Stoppen Sie auf jeden Fall den Wahnsinn.

@jashkenas Voll, 100% Bestätigung. Skriptlader fügen nur Overhead und Komplikationen und Fehlerquellen hinzu. Eine einzelne, serververkettete Datei wird schnell geladen, sowohl in Bezug auf die reine Übertragungszeit als auch in Bezug auf die Effizienz der JavaScript-Interpreter, und als Bonus funktioniert gzipping besser, wenn Sie nur eine einzelne Datei haben.

Ich muss sagen, die LABjs-Version lädt _manchmal_ schneller in meinem Browser (im Vergleich zur Vanilla-Seite), aber nicht konstant. Außerdem wird onload nicht immer ausgelöst, was ... seltsam erscheint.

Ja, gzipping bietet Ihnen mit weniger HTTP-Anfragen einen noch größeren Gesamtgewinn.

Und hier geht es nicht um Dogmen, es muss keine _einzelne_ JS-Datei für die gesamte App sein – zwei oder drei mit defer sind für feinkörniges Caching in Ordnung, ebenso wie das Laden von mehr später.

Einige Recherchen des Google Page Speed-Teams:

http://pagespeed-velocity2011.appspot.com/#8 siehe Folien 8-14, was der Diskussion mehr Unschlüssigkeit verleiht

Ich bin immer noch scharf auf das Attribut @defer des Skripts und denke, dass dies eine weise Grundeinstellung ist, es sei denn, Sie planen, viele Stunden / Tage in das Perf-Testen Ihrer eigenen Variationen zu investieren.

@miketaylr : Ja, bitte

Nun, labjs lädt _always_ am schnellsten in meinem Browser (Safari 5.1) selbst mit Shift-Refresh oder wenn Elemente zwischengespeichert werden.

Natürlich ist die Verwendung eines Skript-Loaders ohne Verkettung langsamer als ein verkettetes Skript-Tag. Aus diesem Grund haben Leute (YUI, requireJS) Skriptlader erstellt, die verkettete Dateien laden und Dienste, die sie auf Anfrage verketten (https://github.com/rgrove/combohandler).

Komm schon, diese Diskussion macht keinen Sinn. Skriptlader dienen zum Laden von Skripten bei Bedarf, insbesondere nach Benutzerinteraktionen, beispielsweise zum Laden der Logik hinter der Dialog- und Formularvalidierung beim Klicken auf eine "Anmelden"-Schaltfläche.

Ich habe den heimlichen Verdacht, dass @madrobby die Dinge zu
Steve schlägt vor, dass das parallele Herunterladen mehrere Vorteile für eine Reihe von Blockierungsproblemen und Browsern bietet _(ja, das bedeutet nicht-WebKit)_. Er erwähnt auch eine Strategie, das für Dom-Load-Aufgaben erforderliche Minimum an JS zu laden und den Rest später nach Bedarf zu laden. Da Situationen und Entwicklungsanforderungen variieren, weiß ich nicht, ob ein Skriptlader in eine Boilerplate gehört _(standardmäßig aktiviert)_, aber ich würde das Baby noch nicht mit dem Bade ausschütten.

Wenn es in meinem ursprünglichen Beitrag nicht klar war. Ich neige dazu, (mit jdalton) zuzustimmen, dass es einige Vorteile von Skriptladern in stark getesteten und spezifischen Umgebungen gibt, die besondere Aufmerksamkeit erfordern. Ich denke nicht, dass es eine angemessene Standardeinstellung ist.

Ich stimme @jdalton zu : Es gibt keinen Lader für alle Größen. Ich persönlich verwende verschiedene Skriptlader, abhängig von meinen tatsächlichen Bedürfnissen und Projekten. Manchmal ist etwas Einfaches wie Yepnope oder LabJS in Ordnung, manchmal ist RequireJS ein Glücksfall. Ich bin mir nicht sicher, ob ein Boilerplate einen erzwingen muss. Es ist knifflig, denn die Idee wäre, dass der Boilerplate das Umschalten auf einen Script-Loader erleichtert ... also würde ich das Baby nicht einfach mit dem Bade ausschütten doch auch nicht.

Außerdem, @getify , so zu tun, als Skriptlader tatsächlich dieselbe Technologie verwenden, ist eine sehr uninformierte Aussage.

Für was es wert ist...
Dies

var script = document.createElement('script')
script.src = 'foo.js'
document.getElementsByTagName('head')[0].appendChild(script)

ist besser als das

<script src="foo.js"></script>

aus dem einen Hauptgrund, dass es nicht blockierend ist. Daher müssen nachfolgende Bilder und CSS-Dateien warten, bis diese Datei mit der letztgenannten Version heruntergeladen wurde. Ersteres ist asynchron — Dies sollte jeder wissen, unabhängig davon, ob Sie sich für einen Skriptlader entscheiden oder nicht.

re: "So zu tun, als würden alle Skriptlader tatsächlich dieselbe Technologie verwenden, ist eine sehr uninformierte Aussage."

Wenn sie es nicht so machen, machen sie es falsch

Um ehrlich zu sein, die Verwendung von appendChild ist in Ungnade gefallen... :D

Ich habe diesen Testfall jedoch zu AssetRace hinzugefügt

https://github.com/SlexAxton/AssetRace/blob/master/asyncconcat.html

Es macht das Feuer unter Last schneller, so dass es einen wahrgenommenen Vorteil _könnte_. Aber die Endzeit ist ungefähr gleich...

@ded : Wir sprechen hier nicht über inkompetente große Blockierungen von <script> 's in <head> ... wir sprechen über Skript-Tags mit einem defer oder async Attribut, das am Ende von <body> geladen wird, wo nichts mehr zu blockieren ist.

@jaubourg--

Außerdem, @getify , so zu tun, als Skriptlader tatsächlich dieselbe Technologie verwenden, ist eine sehr uninformierte Aussage.

Dies ist eine völlig falsche Darstellung dessen, worauf ich hinaus wollte. Tatsächlich tun die meisten Skriptlader NICHT die Dinge, die sie meiner Meinung nach tun sollten (und die LABjs jetzt tut), um die beste Technologie zu verwenden. Mein Punkt war, selbst wenn alle die beste Technologie verwendet haben, gibt es immer noch eine begrenzte Grenze dessen, was wir technisch tun können. Ich bin mir ziemlich sicher, dass es keine Lader gibt, die eine magische Wunderwaffe verwenden, die LABjs nicht kennt oder nicht verwendet. Sie können Licht nicht schneller als Lichtgeschwindigkeit erreichen, egal was Sie tun oder wie Sie mit den Zahlen herumspielen.

Über die Technik darunter zu streiten (indem man sagt "Hey, sieh dir meine coole und bessere API an") ist sinnlos. Die beste Technologie beim Laden von Skripten ist eine bekannte endliche Menge (auch wenn viele Lader verantwortungslos sind und sie nicht verwenden). Wir können auf bessere Technologie drängen (was ich bin), aber zu diskutieren, wer die bessere API auf seinem Loader hat, trägt nichts dazu bei.

In diesem Thread scheint es wirklich am sinnvollsten zu sein, festzustellen, ob Skript-Tags alleine gut genug sind (mit oder ohne Verzögerung) oder ob Skript-Loader helfen, eine bessere Leistung zu erzielen. Zweitens müssen wir herausfinden, ob Concat wirklich das Ende des Skriptladens ist.

Es ist auch ein strittiger Punkt (für diesen Thread), dass Skriptlader all diese anderen Anwendungsfälle haben, die sie tun können, die Markup-Skript-Tags nicht können (wie On-Demand/Lazy-Loading). Auch das ist an dieser Stelle im Grunde eine Selbstverständlichkeit, daher ist es sinnlos, diese Tatsache wiederherzustellen.

NEIN U

WUT LADEN!

Sehen Sie sich hier den Originalbeitrag an.

Auch alle Personen, die von einem Cartoon-Penis beleidigt werden: Willkommen im Internet! Ich empfehle Ihnen , Ihre Reise hier zu beginnen .

OK, ich habe 3 Tests erstellt, um einige Punkte zu veranschaulichen. Zuerst manuelle Skript-Tags (als Grundlinie):

http://labjs.com/dev/test_suite/test-script-tags.php

Beachten Sie, dass DOMContentLoaded (auch bekannt als "DOM-ready") viel spät kommt, nachdem die Skripte abgeschlossen sind. Das ist das Schlechte. Während die tatsächliche Ladezeit der Seite mit den späteren Tests identisch sein kann, ist die wahrgenommene Ladezeit der Seite immer viel langsamer, wenn DOM-ready blockiert wird (so warten viele Sites bis DOM-ready, um Klickverhalten anzuhängen, JS-gesteuerte Verbesserungen auf den Inhalt anwenden usw.).

Was nun passiert ist, dass wir defer für unsere Skript-Tags verwenden:

http://labjs.com/dev/test_suite/test-script-defer-tags.php

Das ist gut so, wir haben das DOMContentLoaded-Verzögerungsproblem behoben, aber jetzt haben wir ein anderes Problem. Der Inline-Skriptblock funktioniert nicht mit defer . Es wird sofort ausgeführt. Hoppla. Übrigens, dies ist kein Fehler, die Spezifikation schreibt dies ausdrücklich vor.

http://labjs.com/dev/test_suite/test-LABjs.php

Der LABjs-Test erhält im Wesentlichen die gleichen (oder bessere) Leistungszahlen im Vergleich zum defer Test, aber es gelingt ihm nicht, den Inline-Code nach Abschluss der Skripts auszuführen.

Versuchen Sie diese Tests mehrmals in modernen Browsern (Chrome 13, FF5 usw.). Für mich hat LABjs beim defer Test immer ungefähr gleich oder besser abgeschnitten. Bei all meinen Versuchen habe ich noch nie erlebt, dass LABjs schlechter abschneidet als der defer Test. Versuchen Sie diese Tests in älteren Browsern (wie FF3.5 oder IE7) und Sie werden sehen, dass der Skriptlader die anderen Tests um ein Vielfaches übertrifft.

Obwohl der LABjs-Test ähnliche Zahlen wie der defer Test in den neuesten Browsern hat, ist es ein Deal Breaker, wenn defer nicht für defer ALLE Codes verwendet werden kann (funktioniert nur für Code, der über eine externe Datei geladen wird). VIELE Sites laden Skripte und haben dann Inline-Code, um den gerade geladenen Code zu aktivieren/initieren. defer bietet uns hierfür keine Lösung.

Daher ist defer als Technologie für das "allgemeine Laden von Skripten" ungeeignet. Die nächstbeste Option ist ein Skriptlader.

@getify

Es geht nicht nur um Mikrooptimierungen ... und JA, API ist wichtig und ist im Allgemeinen ein guter Hinweis auf die Art der Einschränkungen, die die zugrunde liegende Technologie hat, hauptsächlich aufgrund der Mikro- (oder sogar Makro-) Optimierungen. Es geht nicht immer nur darum, Skripte zu laden. Komplexes Abhängigkeitsmanagement, richtiges Sandboxing und tatsächliche, echte Modularität ist nichts, was man einfach wegwaschen kann, nur weil man kein Interesse daran hat. Erraten Sie, was? Dies sind eigentlich die Dinge, die die Leute brauchen, und die Seitenladeleistung kann mit statischen Skript-Tags auf einem einigermaßen guten Niveau erreicht werden.

Letztendlich läuft alles darauf hinaus, dass die Skript-Tag-Injektion nicht das richtige Werkzeug für die Aufgabe ist: Das war es eigentlich nie. Es ist nur ein sehr hässlicher Hack. In diesem Sinne drängen Sie eigentlich nicht auf eine bessere Technologie: Sie drängen auf mehr davon mit neuen Arten von Vorbehalten, die noch keiner von uns ableiten kann. Denken Sie bitte kurz nach und sehen Sie, ob es endlich klickt.

Was wirklich ärgerlich ist, ist, dass Sie sich weigern, ein einziges Argument zugunsten der Injektion von Skript-Tags im Gegensatz zu einer richtigen, nativen Javascript-API zum Laden von Skripten vorzubringen. Du ignorierst das Ganze einfach. Aber ich erspare Ihnen die Mühe: Da gibt es keinen Streit . Aber, heh, wir können alle etwas mentale Masturbation über die Besonderheiten von Aufschub und Asynchronität haben und uns fühlen, als wären wir die Götter des Javascript, oder? Oder debattieren Sie über 50-ms-Optimierungen, als ob sie tatsächlich jedem in dieser Branche helfen würden.

Wenn Sie schließlich entscheiden, dass ich einer intelligenten Antwort würdig genug bin (im Gegensatz zu einer weiteren LabJS-Werbung), tun Sie dies auf meinem Blog und lassen Sie uns diesen Thread in Ruhe. Dankeschön.

@jaubourg --
ich habe deinen Beitrag letzte Nacht ausführlich gelesen. Ich hatte vor, als Antwort einen Blogbeitrag zu schreiben, in dem ich Sie größtenteils für die guten Gedanken lobe und beglückwünsche, die Sie dort präsentiert haben. Leider wurde das, was Sie vorschlagen, bereits von Mitgliedern des Diskussionsthreads zu W3C und WHATWG IN LÄNGE herausgehackt. Du bist ziemlich spät zu dieser Party.

Es gab mehrere Leute, die eine völlig neue Loader-API unterstützten, und es gab mehrere wichtige Gegenargumente, warum dies wahrscheinlich nicht der beste Weg war. Auch hier hatte ich vor, Ihnen in einem sorgfältigen und begründeten Blogbeitrag eine Antwort zu schreiben, um das alles zu erklären.

Schade, dass du hier so ein Arsch sein musst. Jetzt habe ich das Gefühl, dass dieser begründete Blogpost nur Zeitverschwendung ist. Sie halten mich offensichtlich für einen Idioten und haben nie über die Dinge nachgedacht, die Sie ansprechen wollen. Weil ich den größten Teil des letzten Jahres nicht damit verbracht habe, absolut besessen von der Skript-Loader-Technologie zu sein und wie man die Spezifikation und die Browser bekommt, um sie zu verbessern. Ja, ich bin ein Idiot. Ich habe offensichtlich noch nie über etwas anderes als das Skript-Tag nachgedacht.

Sie haben anscheinend nicht auf die 15 Mal gehört, dass _dieser_ Thread das bessere Ziel hatte, sich auf die spezifischen Fragen zu konzentrieren, die Paul Irish und Alex Sexton aufgeworfen haben: Ist defer gut genug? ist script-concat besser als paralleles Laden?

Das sind die wichtigeren Fragen.

Nicht welche zugrundeliegende "Loader"-Technologie verwendet wird. Es gibt ein anderes und besseres Forum, um zu diskutieren, was die zugrunde liegende Ladertechnologie ist. Ich verstehe, Sie mögen das Skript-Tag nicht. Bußgeld. Verbringen Sie Dutzende von Stunden auf der W3C/WHATWG-Liste und versuchen Sie, Ian und andere dazu zu bringen, Ihnen zuzuhören. Sie werden wahrscheinlich alle nur gähnen und sagen: "Das haben wir schon rausgehauen, geh weg."

@getify : Das Erstellen lächerlicher Strohmann-Tests wird Ihnen keine Punkte

Wenn Sie testen, um eine falsche Vorstellung zu bestätigen ... Ihre Tests werden diese falsche Vorstellung immer bestätigen. Die Debatte drehte sich nie um 20 Skript-Tags im Vergleich zu 20 LABjs-Skriptladungen. Es geht darum, Ihr JavaScript in so wenigen HTTP-Anfragen wie möglich intelligent zu trimmen, zu verketten, zu verkleinern, zu gzippen und zu laden und es dann zwischenzuspeichern.

Einerseits haben wir einen zuverlässigen, browsergestützten, bewährten Ansatz, der auf realen Seiten nachweislich besser funktioniert; und auf der anderen Seite haben wir eine zusammengehackte "Technologie", die in der Vergangenheit tatsächlich jede Site, die sie verwendet, nach einem Browser-Update kaputt gemacht hat, die im Durchschnitt nachweislich schlechter abschneidet und eine weitaus größere Varianz der Langsamkeit aufweist.

Es ist eine einfache Wahl.

@jashkenas--

Wir wissen auch, dass die Ausführung von Inline-Skriptblöcken vor "verschobenen" Skripten für echte Sites in keiner Weise ein Problem darstellt.

Ähh ... Ich schätze, Sie haben auf etwa 98% aller Websites im Internet keine Quelltextansicht durchgeführt, die tatsächlich Inline-Skriptblöcke im Markup verwenden, um den Code auszuführen/zu initialisieren, den sie zuvor geladen haben (Blockierung) Skript-Tag-Aufruf.

Wenn @paulirish vorschlägt, dass defer gut genug ist und dass Skriptlader nicht erforderlich sind, dann ist es mir wichtig, darauf hinzuweisen, warum defer tatsächlich NICHT gut genug ist.

SIE kümmern sich vielleicht nur um die wenigen Nischenseiten, die Sie kontrollieren, die Sie vollständig in Bezug auf Build-Prozesse usw mit einem halben Dutzend Skript-Tags (einige davon Inline-Skriptblöcke!), wobei die Verwendung eines halben Dutzends $LAB.script() Aufrufe wahrscheinlich die Leistung verbessern würde. Darum ging es bei LABjs schon immer. Nur weil es dir nicht wichtig ist, heißt das nicht, dass es nicht relevant ist.

Die Debatte drehte sich nie um 20 Skript-Tags im Vergleich zu 20 LABjs-Skriptladungen.

Die Debatte in diesem Thread dreht sich darum, ob 3-4 Skript-Tags (mit oder ohne defer ) schlechter, gleich oder besser abschneiden als 3-4 Skripte, die dynamisch mit einem parallelen Skript-Loader geladen werden. Meine "lächerlichen Strohmann-Tests" sollen nämlich genau das testen.

Meiner Erfahrung nach verkürzen Skriptlader die Seitenladezeit um viele Millisekunden. Aber ich glaube, wir haben hier alle den Punkt verfehlt. JavaScript hat einige größere Probleme:

• Fehlende Importanweisungen machen es schwierig, Ihren Code modular zu organisieren
• Globale Variablen kollidieren, es sei denn, der sorgfältigen Namensteilung wird viel Aufmerksamkeit geschenkt.
• Keine Möglichkeit, klar zu erkennen, was die Abhängigkeiten eines Skripts sind

Ich verwende RequireJS nicht, weil es schneller lädt, obwohl das ein netter Nebeneffekt ist. Ich benutze es, damit ich meine JS-App in kleine Module organisieren kann, ähnlich wie in NodeJS. Jedes Modul listet seine Abhängigkeiten klar auf und verwendet das Sandbox-Muster, um den globalen Namespace sauber zu halten. Module (und ihre Abhängigkeiten) können im Voraus geladen werden, bei Bedarf geladen werden (z. B. auf Benutzerklick) oder träge geladen werden. Mit diesen Techniken können Sie Ihre Leistung wirklich verfeinern. Und RequireJS wird auch mit einem Build-Tool geliefert, das alle Abhängigkeiten in einer einzigen (oder einer Handvoll) gzip-bereiten Datei(en) für die Bereitstellung kombiniert und minimiert. Die Lösung dieser drei Probleme ist für mich ein großer Gewinn.

Ich kann verstehen, warum Leute darüber diskutieren, einen Skriptlader zu verwenden, der diese Probleme nicht löst. Wenn Leistung der einzige Punkt ist und darüber fraglich, dann sicher. Wenn Sie jedoch einen AMD-Modullader wie RequireJS verwenden, wird die Debatte irrelevant. Module sind die Zukunft von JavaScript. Dave Herman von Mozilla arbeitet mit Vorstandsmitgliedern von Apple und Google daran , der Sprache selbst native Module hinzuzufügen. Aber in der Zwischenzeit können wir alle Vorteile nutzen, indem wir einen AMD-Modullader verwenden. Es geht nicht nur um Leistung.

@getify

Sie können nicht erwarten, dass die Leute Sie anders behandeln als andere. Bevormundung ist kein schlauer Weg, um eine anständige Reaktion zu bekommen (und Gott, du bevormundest) und wie ich in meinem Blogbeitrag sagte, ich glaube nicht, dass du ein Idiot bist, ich denke nur, dass du besessen bist (was du sagst sich übrigens selbst) und dass es Ihr Urteilsvermögen ernsthaft beeinträchtigt. Wie ich in meinem Blogbeitrag sagte, ist es nicht Sache von W3C oder WHATWG, dieses Problem zu lösen, sondern EcmaScript selbst: Dies ist kein Browserproblem, sondern ein Sprachproblem. Geben Sie diese Antwort nicht, wenn Sie nicht möchten, es ist Ihr Vorrecht.

Vielleicht bin ich so hart gekommen, aber ich verteidige nur, woran ich glaube.

Ich melde mich von diesem Thread ab und kommentiere ihn nicht mehr. Tut mir leid, dass ich @paulirish und @SlexAxton entgleist habe.

@getify

SIE interessieren sich vielleicht nur für die wenigen Nischenseiten, die Sie kontrollieren und die Sie haben
vollständige Fähigkeit, in Bezug auf Build-Prozesse usw. stark optimiert zu werden. I on the
Andererseits kümmern wir uns darum, die Leistung auf den Long-Tail-Sites der . zu verbessern
Internet, die mit einem halben Dutzend Skript-Tags (einige davon Inline-Skript
Blöcke!), wo die Verwendung von einem halben Dutzend $LAB.script()-Aufrufen tatsächlich wahrscheinlich wäre
die Leistung verbessern. Darum ging es bei LABjs schon immer. Nur weil
Es ist nicht das, was Sie interessiert, bedeutet nicht, dass es nicht relevant ist.

Wenn es mit LABjs darum geht, mittelmäßigen Sites zu helfen, etwas weniger schlecht zu laden ... das ist ein hehres Ziel, denke ich. Aber wenn Sie es ernst meinen mit einer langsam ladenden Website und sie so schnell wie möglich laden zu lassen – möglicherweise buchstäblich Sekunden schneller, als LABjs es zulässt, dann sollten Sie offen bleiben und anerkennen, dass dies einfacher und weniger zerbrechlich ist Technik ist auch leistungsfähiger.

Bei der Debatte in diesem Thread geht es darum, ob 3-4 script-Tags (mit oder ohne defer)
schneidet schlechter, gleich oder besser ab als 3-4 dynamisch geladene Skripte mit
ein paralleler Skriptlader. Meine "lächerlichen Strohmann-Tests" sollen eigentlich
teste genau das.

Die Debatte in diesem Thread dreht sich darum, wie man eine Website erstellt, um ihr JavaScript so schnell wie möglich zu laden und auszuführen. Schlangenöl an Kunden zu verkaufen und es an Webentwickler zu bewerben, ist für beide ein Bärendienst.

Latenz existiert im Internet. Verketten, verkleinern und komprimieren Sie Ihr JS und laden Sie es unten auf der Seite in so wenigen HTTP-Anfragen wie möglich. sagte Nuff.

@jashkenas--

Wenn es mit LABjs darum geht, mittelmäßigen Websites zu helfen, etwas weniger schlecht zu laden ... das ist ein hehres Ziel, denke ich

Es gibt Hunderte von Sites, die ich persönlich aus den letzten 2 Jahren kenne, die nichts anderes getan haben, als ihre Skript-Tags durch $LAB.script() Aufrufe zu ersetzen, und alle sahen eine bessere Leistung (einige drastisch, andere nur bescheiden).

Es wurden Artikel geschrieben (völlig unabhängig und nicht mit mir verbunden), die sich darauf konzentrierten, Websites in verschiedenen Branchen (wie E-Commerce, Immobilien usw.) zu einer besseren Leistung zu verhelfen (weil eine bessere Leistung mehr Conversions bedeutet), in denen diese Artikel Websites empfohlen wurden, die Sie ersetzen Skript-Tags durch $LAB-Aufrufe, und viele Leute in diesen Kommentar-Threads haben bejaht, dass es ihnen geholfen hat.

Hätten diese Artikel gesagt "OK, was Sie tun müssen, um mehr Leistung zu erzielen, ist einen Serveradministrator einzustellen, der gzip versteht und ruby ​​oder node.js installieren kann, damit Sie einige automatisierte Build-Prozesse durchführen können......." diese Leute das Lesen dieser Artikel wäre übergeblättert und gegangen, ohne weiter darüber nachzudenken. Aber ich glaube gerne, dass "Hey, <script> durch script() ersetzen" eine ziemlich einfache Nachricht für sie war, die sie verstehen und mit der sie sich verbinden können.

Was ich für LABjs wollte, ist eine einfache Lösung, die jemand einfach vorbeischauen kann, um seine Skript-Tags ohne viel Nachdenken zu ersetzen. Ich bin mir bewusst, dass Sie viel mehr Leistung aus vielen Websites herausholen können, wenn Sie sich persönlich mit einer Website beraten und die besten Optimierungen herausfinden. Aber ich erkenne auch, dass dies meine Fähigkeiten als eine Person für den langen Schwanz des Internets bei weitem übersteigt mit ihnen eine fremde Sprache zu sprechen. OTOH, es war ziemlich erfolgreich zu sagen "Hey, nimm diese 3 Skript-Tags und führe sie 3 script()-Aufrufe aus. Sehen Sie, wie einfach das war?"

Unterm Strich war mein Ansatz mit LABjs, die tief hängenden Früchte zu treffen.

Nichts davon soll bedeuten, dass ausgefeiltere Optimierungsansätze nicht möglich sind – das sind sie eindeutig, und wenn ich die Gelegenheit habe, mich zu beraten, werde ich sie definitiv untersuchen. Es ist nur zu sagen, dass es für einen Großteil des Webs komplizierter/komplizierter ist, als sie bereit oder in der Lage sind. Und ich versuche nur, _diesen_ Websites dabei zu helfen, sich auf eine für sie leichter verständliche Weise zu verbessern.

@jashkenas--

potenziell buchstäblich Sekunden schneller als es LABjs erlauben würde, dann ist es angebracht, offen zu bleiben und anzuerkennen, dass die einfachere und weniger fragile Technik auch performanter ist.

Es gab nie Beweise dafür, dass LABjs Websites erheblich verlangsamt. Es gibt viele etablierte Beweise dafür, dass es vielen Websites hilft. Also kaufe ich das nicht ab – was Sie meinen, ist eine falsche Prämisse, die von Tatsachen ausgeht, die nicht bewiesen sind.

@paulirish hat einen Beitrag gefunden, der auf Probleme mit dem Attribut defer hinweist:
http://hacks.mozilla.org/2009/06/defer/

Aus Sicht der mobilen Leistung - wie @jashkenas sagte, ist es immer am besten, es zu verketten, zu gzip und als ein Paket über die Leitung zu senden, als mehrere HTTP-Anforderungen aufgrund von Latenzzeiten durch 3g-Netzwerkverbindungen zu haben.

Es wird viel über die Verwendung von Inlining-Techniken geforscht, bei denen Sie Bilder mit Base64 in Strings codieren und sie dann als Schlüssel:Wert- Paare in localStorage speichern, nur um http-Anfragen zu reduzieren und das „Caching“ zu nutzen: http://channel9.msdn.com/Events /MIX/MIX11/RES04 ist eine großartige Präsentation von James Mickens von Microsoft Research.

Hier ist ein ziemlich gutes Deck über die mobile Leistung mit http-Anfragen und ihre Auswirkungen auf die Benutzererfahrung: http://davidbcalhoun.com/present/mobile-performance/

Ich arbeite an RequireJS und möchte

1) Zeigen Sie den Weg für modularen Code in JS, der überall gut funktioniert, wo JS läuft.
2) Laden Sie Skripte.

Der Teil "Skripte laden" ist ein notwendiger Teil, um das erste Ziel zu erreichen. In Dev ist es keine gute Idee, alle Ihre Skripte zu verketten, da dies das Debuggen erschwert und die Zeilennummern nicht übereinstimmen. Skript-Loader machen es auch einfach, eine JS-API zu verwenden, um Code bei Bedarf zu laden. Für Apps in Webmail-Größe ist dies ein notwendiger Teil der Leistungsgeschichte. Die Verkettung der Skripts in eine oder eine kleine Anzahl von Anforderungen ist jedoch normalerweise die beste Bereitstellungsoption.

Aber das Ziel von requirejs ist es, das Shim/Polyfill/was auch immer zu sein, um zu zeigen, wie modulare Codeeinheiten erstellt und referenziert werden können, die mit anderen auf eine Weise geteilt werden können, die Globals entmutigt und explizite Abhängigkeiten fördert.

Es verwendet die AMD-API, die zusammen mit anderen Entwicklern modularer Skriptlader (einschließlich Compliance-Tests ) entwickelt wurde, mit dem Ziel, Diskussionen über ein Modulformat in JS zu unterstützen. Dieser Ansatz durch reale Implementierungen und das Erreichen einer Vereinbarung mit anderen über die API ist der Weg, um Fortschritte zu erzielen.

Angesichts des Netzwerkcharakters von JS und seiner Beziehung zu Webdokumenten/-anwendungen sollte die Loader-Plugin-API in gewisser Weise mit den ES Harmony-Modulen unterstützt werden, und ich arbeite daran, die ES Harmony-Module über ein Prototyp zu erstellen

Für die Performance-Leute :

• Es gibt einige Auswahlmöglichkeiten für Lader, die AMD unterstützen ( curl , Dojo 1.7 , loadrunner , requirejs), sogar eine sehr kleine , die für die Optimierung "alle Skripte in einer JS-Datei" für die Bereitstellung verwendet werden kann. So ist es möglich, eine hervorragende Leistung zu erzielen und gleichzeitig die besten Codierungspraktiken zu fördern – einfachere Codefreigabe durch Vermeidung von Globals und Verwendung expliziter Abhängigkeiten.
• Der requirejs-Optimierer läuft in Node sehr schnell und kann in Rhino ausgeführt werden. Es ist ein Befehlszeilentool, aber der neueste Master-Zweigcode exportiert es als ein in Node verwendbares Modul, sodass es beispielsweise über einen Node-basierten http-Server ausgeführt werden kann, der den Build im laufenden Betrieb ausführen kann . Sie können also immer im Modus "Ein Skript immer herunterladen" entwickeln, wenn Sie es vorziehen, aber dann entscheiden Sie sich dafür, ein oder zwei Module aus dieser optimierten Datei wegzulassen, damit Sie sie leicht debuggen können.

Im Kontext dieses Tickets : Die Auswahl eines AMD-kompatiblen Loaders (muss nicht erforderlich sein) passt zu den Zielen der HTML-Boilerplate: den Weg zu Best Practices sowohl im Code als auch in der Leistung aufzuzeigen. Ich weiß jedoch zu schätzen, dass es sehr schwierig ist, einen HTML-Boilerplate auszuarbeiten, es gibt konkurrierende Interessen, einige stilistische, daher schätze ich es, zu diesem Zeitpunkt keine Empfehlung in diesem Bereich abgeben zu wollen.

Ich möchte nur klarstellen, dass das Ziel von requirejs und Loadern, die die AMD-API implementieren, einen größeren Nutzen bietet, als nur einige Skripte zu laden, die globale Werte ausgeben und den Entwickler zwingen, den vollständigen, manchmal impliziten Abhängigkeitsbaum zu erarbeiten. Diese Ziele werden mit Lösungen mit soliden Leistungsprofilen erreicht.

Um sich von früher zu fokussieren ... Vergleichen Sie den defer Test mit dem LABjs-Test ... (und ignorieren Sie die Tatsache, dass defer bei Inline-Skriptblöcken nicht funktioniert), sieht jemand, dass die LABjs-Test schneidet schlechter ab als der defer Test? Ich habe es in einer Reihe von Browsern und sogar auf meinem Mobilgerät ausprobiert und sehe immer noch ungefähr gleiche Zahlen.

http://labjs.com/dev/test_suite/test-script-defer-tags.php

http://labjs.com/dev/test_suite/test-LABjs.php

@getify

Ich habe keine Ahnung, warum oder wie Sie dies optimieren können, aber ich habe auf meinem 3+ Jahre alten MacBook einen konstanten Unterschied von 3000 zwischen den beiden, was @defer begünstigt.

Ich habe allerdings nur mit Firefox getestet.

@espadrine-- ziemlich seltsam. würde dem gerne auf den Grund gehen. mit welcher Firefox-Version testest du? kannst du mir einen Screenshot von den Ergebnissen schicken?

Verketten und verkleinern Sie einfach Ihr gesamtes JS und CSS und fügen Sie es direkt in Ihre HTML-Seite ein und fertig. Einzelne HTTP-Anfrage FTW! :P

Im Ernst, es gibt so viele größere Probleme, auf die wir uns in dieser Community konzentrieren sollten, als nur darauf, wie Ihre App geladen wird. Die Chancen stehen gut, dass die einfachste Methode (Skript-Tags unten) wahrscheinlich schnell genug ist. Einfach tolle Apps schreiben und sich am Ende mit der Ladeleistung auseinandersetzen. Alles andere ist eine vorzeitige Optimierung.

Gibt es einen allgemeinen Konsens unter den Leuten in diesem Thread, dass AMD der Goldstandard für die JS-Code-Organisation sein sollte? Ich habe nicht wirklich andere Optionen gesehen, aber ich stimme zu, dass die Boilerplate ein guter Anfang wäre, um die Leute richtig in die Organisation von Code einzurichten.

Firefox UX 8.0a1 (2011-08-07) Update-Kanal.

Auch hier keine Ahnung warum, und das ist wahrscheinlich sehr spezifisch. LABjs ist wahrscheinlich sehr gut mit Legacy-Browsern.

Bitte verwenden Sie die Testseite von @getify nur zum Lachen. Zitieren:

<script defer src="http://labjs.xhr.me/dev/test_suite/testscript1.php?_=4911710&delay=5"> <script defer src="http://labjs.xhr.me/dev/test_suite /testscript2.php?_=6146431&delay=3"> <script defer src="http://labjs.xhr.me/dev/test_suite/testscript3.php?_=9499116&delay=1">

@getify , wenn Sie einen echten Test durchführen AssetRace -Repository von

Stellen Sie außerdem sicher, dass Sie das JS tatsächlich für ein einzelnes Skript-Tag verketten – defer oder nicht. Der Punkt ist, dass der gleiche Inhalt, der über eine HTTP-Anfrage bereitgestellt wird, den gleichen Inhalt übertrifft, der über 10 HTTP-Anfragen bereitgestellt wird.

Es gab nie Beweise dafür, dass LABjs signifikant ist
Verlangsamung von Websites. Es gibt viele etablierte Beweise dafür, dass es sehr hilft
von Websites. Also kaufe ich das nicht – was Sie meinen, ist eine falsche Prämisse unter der Annahme
Tatsachen nicht nachweisbar.

Was oben gezeigt wurde , ist, dass LABjs Websites tatsächlich erheblich verlangsamt, indem ihr JS über viele HTTP-Anfragen mit ihren Bildern, CSS und anderen Assets konkurriert. @getify : Ich würde gerne einen Link zu einer Site sehen, die Ihrer Meinung nach durch Ihre Konvertierung in LABjs deutlich demonstriert wurde. Vielleicht können wir eine Kopie davon herunterladen und als Testfall verwenden, den Sie respektieren werden.

Fürs Protokoll, ich denke, es wäre ratsam, noch mehr Bilder auf der AssetRace-Repo-Testseite zu erhalten. Aber im Moment ist es sicherlich eine gute Ausgangsbasis.

@artzstudio Die Organisation Ihres JS mit einem AMD-Loader ist in der Tat der Goldstandard, zumindest bis die Module von Harmony fertig sind und weitgehend unterstützt werden. Dann wird es einen klaren Migrationspfad von AMD-Modulen zu Native-Modulen geben.

AMD-Module als Goldstandard sind sicherlich eine Meinung (die ich teilen kann). Es gibt jedoch viele schlaue Leute (ich denke an Yehuda Katz und Dan Webb), die das nicht mögen und andere Lösungen anbieten.

Der Loadrunner von @danwrong kann irgendwie beides, wenn das auch deine Tasche ist: https://github.com/danwrong/loadrunner

Ein paar ziemlich gute Sachen drin. Möglicherweise auch etwas praktischer für Nicht-JS-Leute. Ich mag AMD-Module für meine Sachen, aber nicht jeder möchte Zeit damit verbringen, jede Version der Bibliotheken, die er verwendet, in Module umzuwandeln.

Ich weiß, dass @strobecorp an einer eigenen Lösung arbeitet, die nicht viel zusätzlichen Code erfordert, den AMD-Module erfordern.

Obwohl ich es lieben würde, AMD als Standard zu verwenden, ist es aus Sicht einer Multi-Library/Newb wahrscheinlich nicht klug, so sehr ich es mir wünschte.

@jashkenas--

Bitte verwenden Sie die Testseite von @getify nur zum Lachen.

Wenn Sie nicht höflich sein können, möchte ich nichts weiter mit Ihnen besprechen. Ich handle nach Treu und Glauben. Ich würde mich über ein bisschen Anstand freuen.

@getify , wenn du einen echten Test machen willst

Ich möchte Sie auf jeden Fall bitten, zu erklären, warum das, was ich tue, so verrückt, lächerlich und ungültig ist. Ich habe den Ansatz direkt von Steve Souders übernommen, der (in seiner großen Erfahrung und Weisheit) in all seinen Tests vorschlug, dass Sie das Server-Timing verwenden, um die Skripte zu steuern, um die Varianz in Ihren Tests zu reduzieren. Genau das tue ich.

Ein kontrollierterer Test ist ein gültiger Basistest. Das ist etablierte wissenschaftliche Praxis. Das bedeutet nicht, dass Tests aus der realen Welt nicht auch nützlich sind, aber es bedeutet auch nicht, dass du mich anschnüffeln und sagen kannst "lach ihn aus, was für ein Idiot, weil er seine Tests anders macht als ich denke, sie" Sollte gemacht werden."

Zögern Sie nicht , das @SlexAxton zu forken und eine LABjs-Version hinzuzufügen

Das mache ich gerne. Aber nicht, weil ich damit einverstanden bin, dass meine anderen Tests ungültig sind. Wenn Sie begründete, besonnene Argumente haben, warum mein Testaufbau nicht gültig ist, teilen Sie uns dies bitte mit. Aber hör auf, so ein Arsch zu sein.

@jashkenas--

Der Punkt ist, dass der gleiche Inhalt, der über eine HTTP-Anfrage bereitgestellt wird, den gleichen Inhalt übertrifft, der über 10 HTTP-Anfragen bereitgestellt wird.

Ich weiß, dass Sie (und andere) hier immer wieder darüber schimpfen, wie es in dieser Diskussion um Concat vs. Nicht-Concat gehen sollte. Wenn Sie viel weiter oben in dem Thread gelesen haben, gab ich zu, dass zwei Fragen beantwortet werden mussten. Die beiden Probleme sind, soweit es mich betrifft, orthogonal. Die erste ist, ob Skript-Tags im Markup genauso gut (oder besser) sein können als dynamische Skriptelemente, die in einem parallelen Skriptlader verwendet werden. DIESER FRAGE versuche ich immer noch mit meinen Tests zu beantworten.

Die zweite Frage, zu der wir noch nicht gekommen sind, ist, ob script-concat immer besser ist. Ich weiß, dass Sie bereits davon überzeugt sind, aber ich habe Gegenbeweise dafür, dass es nicht so einfach ist. Auch diese Frage muss gründlich getestet werden. Aber es ist nicht das, was ich gerade in diesem Thread herausarbeiten möchte.

Indem Sie weiterhin darauf bestehen, dass Ihr Weg der bessere ist, machen Sie die ganze Debatte nur weniger angenehm. Alles, was ich versuche, ist, methodisch einige Beweise für jede dieser beiden Hauptfragen zu finden, damit wir aufhören zu raten und besser informiert sind. Warum können Sie da nicht helfen, anstatt zu versuchen, mir ein Idiot zu sein, weil Sie nicht meiner Meinung sind?

In Bezug auf den defer Test im Vergleich zum LABjs-Test habe ich gerade eine kurze Screencast-Aufnahme der beiden direkten Tests in IE9, FF8 (nächtlich) und Chrome15 (Kanarienvogel) gemacht.

http://www.screenr.com/icxs

Um die frühere Frage von @paulirish (https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment-1765361) zu defer Macken zu beantworten, sehen Sie sich an, wie sich "DOMContentLoaded" im IE verhält. Chrome und Firefox im defer Test.

In IE9 und Chrome15 wird das DOMContentLoaded-Ereignis angehalten (blockiert) und erst nach der Ausführung der Skripte ausgelöst. In FF wird das DOMContentLoaded-Ereignis jedoch nicht aufgehalten, es wird sofort ausgelöst und die Skripts werden danach ausgeführt. Das ist eine riesige Inkonsistenz bei modernen Browsern und einer der Gründe, warum defer meiner Meinung nach nicht ausreicht.

Soweit ich die Spezifikation gelesen habe, bin ich mir nicht sicher, welches Verhalten richtig ist. Aber ich weiß, dass es zwischen Browsern eindeutig skurril und inkonsistent ist.

@getify Ich versuche nicht, ein

Natürlich sehe ich das, was Sie als Schimpfwort empfinden, als den Punkt der Diskussion ... und was ich als Schlangenöl sehe, sehen Sie als hilfreichen Schritt nach vorn.

Die beiden Probleme sind in der Tat orthogonal (Sprache, die ich in meinem ursprünglichen Beitrag verwendet habe).

Die erste ist, ob Skript-Tags im Markup genauso gut (oder besser) sein können als
dynamische Skriptelemente, die in einem parallelen Skriptlader verwendet werden.

Wir sind uns in dieser Frage völlig einig – es spielt keine Rolle. Natürlich ist das parallele Laden für mehr als ein Skript schneller als das sequentielle Laden. Und natürlich ist es besser, dies auf nicht-blockierende Weise zu tun, entweder am Ende des <body> Tags oder mit defer oder mit einem Skriptlader, als das Blockieren im <head> .

Aber das verfehlt den Punkt. Das Einfügen von sequentiellen Skript-Tags ist ein Strohmann, mit dem man vergleichen kann, denn niemand, der sich um die Leistung seines JavaScripts kümmert, würde diesen Ansatz verwenden. Ratet mal, was auch schneller ist als sequenzielle Skript-Tags? _Irgendetwas_.

Die zweite Frage, zu der wir noch nicht gekommen sind, ist, ob
script-concat ist immer besser.

Diese Frage haben wir uns "erkannt". Tatsächlich ist es die Frage von @paulirish oben auf dieser Seite. Wenn Sie nicht versuchen, es in diesem Thread herauszuarbeiten, müssen Sie es tun. Es trifft den Kern all Ihrer Behauptungen darüber, was LABjs tut, nicht nur in diesem Thread, sondern im Laufe der Jahre.

Auch diese Frage muss gründlich getestet werden.

Um mich zu wiederholen, hier ist ein (fairer) Testfall. Dieselben 5 realen Skripte, die auf eine mittelgroße Seite mit anderen vorhandenen Assets geladen werden, wobei eines die Best Practices von LABj verwendet, um die Ladereihenfolge sicherzustellen, und das andere ein einzelnes verkettetes Skript verwendet:

http://jashkenas.s3.amazonaws.com/misc/snake-oil/labjs.html

http://jashkenas.s3.amazonaws.com/misc/snake-oil/vanilla.html

Wenn Sie einen anderen Testfall untersuchen möchten oder eine reale LABjs-Website verwenden möchten, mit der Sie experimentieren möchten, teilen Sie ihn bitte mit.

@SlexAxton Danke. Ich wäre neugierig auf Yehudas Meinung dazu und andere starke Meinungen (außer es ist zu schwer zu refaktorisieren). Ich fand dies aber nicht die Rede.

Um den Kommentar von @geddesign zu verdeutlichen: Stand heute sieht es so aus, als ob AMD-Module ziemlich einfach in Harmoniemodule umgewandelt werden können, aber dieser Vorschlag für Harmoniemodule halte ich noch für im Fluss, er könnte sich später ändern. Es hat noch keinen rigorosen Implementierungstest durchlaufen, aber es beginnt, einige Schritte zu machen. Auf der positiven Seite können AMD Loader + Loader-Plugins solides Feedback zum Ausprobieren einiger Harmonieideen geben.

Zu @SlexAxtons Kommentar:

Für Loadrunner: Mir ist nicht klar, dass die Syntax besser ist, nur anders. Es unterstützt AMD, also funktioniert es immer noch.

Für Stroboskop: Ich habe noch keinen Code von ihnen darauf gesehen. Sie scheinen ziemlich nach innen gerichtet zu sein, obwohl ich die Arbeit schätze, die Yehuda geleistet hat, um diese Entwicklung zu öffnen. Alex, wenn du Hinweise hast, was sie denken, würde ich mich freuen, sie zu bekommen.

Wenn der Ansatz verschachtelte Abhängigkeiten zulässt (was für die allgemeine Codefreigabe erforderlich ist), benötigen Sie eine Syntax, die:

• gibt einer Codeeinheit einen Namen
• eine Möglichkeit, Abhängigkeiten anzugeben
• einen Funktionswrapper um diesen Code, um sicherzustellen, dass er nicht ausgeführt wird, bis die Abhängigkeiten bereit sind. Oder verlangen Sie immer einen Build- oder XHR-Zugriff, der nicht über das gesamte Spektrum der JS-Entwicklung skalierbar ist.

Dies ist, was AMD bietet, und die Syntax ist so schlank wie es nur geht. Alles andere ist nur der Kampf um Namen und möglicherweise einige Arten von Interpunktion. Irgendwann muss einfach etwas gewählt werden, und bisher habe ich weder von Dan Webb noch von Yehuda von strukturellen Schwächen gehört, die AMD unhaltbar machen. Einige AMD-Loader, wie beispielsweise requirejs, können nur normale Skripte laden, sie müssen keine Module sein.

Es ist sehr einfach, sich Code-Syntax auszudenken, insbesondere für Module, und ich kann verstehen, dass jeder seine eigenen persönlichen Vorlieben hat. AMD hat jedoch eine ziemlich lange Geschichte darin, harte Arbeit zu leisten, um eine Art von Vereinbarung und, was noch wichtiger ist, echten Code und Bereitstellung zu erzielen, um sie zu unterstützen. Ich denke, die Verantwortung liegt jetzt bei anderen, wirklich sehr klar und deutlich zu sein, warum AMD nicht gut passt (dieses Ticket ist nicht der richtige Ort dafür, zögern Sie nicht, mich außerhalb der Liste zu kontaktieren oder die amd-implement- Liste zu verwenden). .

Aber ich schätze die Ansicht von @SlexAxton . Die Standardisierung auf einen AMD-Ansatz für HTML-Boilerplate könnte verfrüht sein, und damit bin ich vollkommen einverstanden. Wenn das Boilerplate-Projekt sich für eine entscheiden möchte, ist AMD eine gute Wahl, die zu einem breiten Spektrum der JS-Entwicklung passt.

@SlexAxton Ich bin bei dir. Mein eigener Code ist komplett AMD. Obwohl ich mir wünsche, dass jeder Module anstelle von Skripten schreiben würde, kann RequireJS zum Glück sowohl einfache Skripte als auch Module laden.

Wenn Sie sich auf Yehudas handlebars.js-Vorlagen beziehen, funktionieren diese sehr gut mit RequireJS. Vor allem, wenn Sie ein Plugin schreiben, das die Vorlage kompiliert/zwischenspeichert und ihre Vorlagenfunktion zurückgibt.

define(['tmpl!navigation.html'], function(nav){
   $('body').append(nav(data));
});

Dieser Aussage stimme ich jedoch nicht zu:

Obwohl ich es lieben würde, AMD als Standard zu verwenden, ist es aus Sicht einer Multi-Library/Newb wahrscheinlich nicht klug, so sehr ich es mir wünschte.

Neulinge brauchen die saubere Struktur, die AMD bietet, noch mehr als ein erfahrener Entwickler, da sie anfälliger für globale Variablenkollisionen sind, eine schreckliche Code-Organisation, die zu riesigen unordentlichen JS-Dateien führt, die niemand aus Angst vor Zusammenführungskonflikten anfassen möchte, etc. Bibliotheken profitieren enorm von Modulen, weshalb kommende Dojo 1.7 und Mootools 2.0 auf AMD umziehen. Ich hoffe, dass jQuery an Bord kommt - eine der größten Beschwerden ist, dass es "alles oder nichts" heißt. Sie können seine hervorragende DOM-Manipulation nicht verwenden, ohne auch seine Animation, Ajax, Events usw. auf die Seite zu laden. Also ja, AMD ist eine Win-Win-Situation. Wenn HTML5 Boilerplate die Leute auf Best Practices hinweisen möchte, wäre es eine Schande, AMD wegzulassen. Es löst elegant so viele Probleme von JavaScript.

Deutlich sein. Ich stimme zu. Ich wünschte, sie brauchten den ganzen Weg.

Ich glaube einfach nicht, dass sie es tun werden.

Ich glaube, die Leute wissen noch nicht, dass AMD ein Modewort ist, eine "Sache", über die jeder ernsthafte Entwickler Bescheid wissen sollte. Sobald sie dies getan haben, werden sie ihren Chefs und zukünftigen Interviews sagen wollen, dass sie davon wissen und es verwenden.

Wenn wir alle unseren Teil dazu beitragen und sagen "Seht, es ist einfach und besser und wichtig" und es zu einem Schlagwort macht, werden die Herden um ihrer Karriere willen folgen.

@jashkenas--

Die erste ist, ob Skript-Tags im Markup genauso gut (oder besser) sein können als dynamische Skriptelemente, die in einem parallelen Skriptlader verwendet werden.

Wir sind uns in dieser Frage völlig einig – es spielt keine Rolle.

Eigentlich habe ich meine Teilnahme an diesem Thread unter der Annahme begonnen, dass alle zustimmen, dass dynamisches Laden von Skriptelementen zu einer besseren Leistung führt als Skript-Tags. Aber sowohl @paulirish als auch @slexaxton haben diese Annahme in _diesem_ Thread in Frage gestellt.

@paulirish hat vorgeschlagen, dass defer ein ausreichender Weg ist, um das einfache alte Skript-Tag so gut (oder besser) zu machen als die Alternative zum Laden von dynamischen Skriptelementen. Ich bin nicht der Meinung, dass defer ausreicht, und ich habe jetzt mehrere Gründe dafür gefunden.

Daher denke ich, dass es berechtigt ist, wenn wir die erste Frage untersucht und untersucht haben, ob defer besser ist als Skriptlader. Es mag einige wenige Fälle geben, in denen Sie mit defer davonkommen, aber was den verallgemeinerten Fall angeht, behandeln/normalisieren Skriptlader alle Macken, während defer Sie diesen Problemen aussetzt.

Ich bin mir immer noch nicht sicher, ob jeder sieht oder zustimmt, warum defer nicht ausreicht.

Um mich zu wiederholen, hier ist ein (fairer) Testfall. Dieselben 5 realen Skripte, die auf eine mittelgroße Seite mit anderen vorhandenen Assets geladen werden, wobei eines die Best Practices von LABj verwendet, um die Ladereihenfolge sicherzustellen, und das andere ein einzelnes verkettetes Skript verwendet:

Dies ist Ihre (und andere) falsche Testprämisse. Ich habe nie behauptet, dass das Laden von 5 Skripten anstelle von 1 schneller sein würde. Niemals. Je. Kann ich noch klarer sein? Die Prämisse war nie 5 vs. 1.

Der erste Test bestand darin, 3 Skript-Tags im Vergleich zu 3 script() Aufrufen zu testen, denn das ist ein fairer Test. Und ich denke, das Video und die Tests veranschaulichen, dass das Laden von Skripten in DIESEM Szenario von Vorteil ist.

Die zweite und viel komplexer zu prüfende Frage lautet, ob es eine Möglichkeit gibt, die Leistung einer Site zu verbessern, die bereits ihr gesamtes JS in eine Datei lädt. Die meisten Leute sagen, dass es unmöglich ist, das zu verbessern. Ich bin nicht einverstanden.

HINWEIS: Diese Frage ist orthogonal, weil Sie diese einzelne Concat-Datei entweder mit einem Skript-Tag oder mit dynamischem Laden vom Typ document.createElement("script") laden können. In jedem Fall ist die Frage nach einer einzelnen Concat-Datei eine gültige Frage, aber unabhängig davon, ob Skript-Tags oder dynamisches Laden von Skripten besser sind.

Was Sie in diesem Thread und auch in vielen anderen Kontexten (einschließlich aller meiner Konferenzreden zu diesem Thema, Blog-Posts usw.) mehrmals von mir gehört haben, ist, dass ich es für möglich halte, die einzelne JS-Datei-Concat zu verbessern Ansatz durch "Chunking" (das Aufteilen der großen Concat-Datei) in 2 oder 3 Chunks (höchstens). Wenn die Chunks ungefähr gleich groß sind und parallel geladen werden, ist es möglich, dass die Seite trotz des zusätzlichen HTTP-Overheads aufgrund der Verbindung "Keep-Alive", des parallelen Ladeeffekts usw. schneller geladen wird.

Tatsächlich habe ich vor LANGE über dieses Thema geschrieben, im November 2009, kurz nach der ersten Veröffentlichung von LABjs: http://blog.getify.com/2009/11/labjs-why-not-just-concat/

In diesem Blog-Post und seitdem habe ich gesagt, dass, wenn Sie in der Lage sind (nicht jeder ist ... tatsächlich ist das meiste im Web nicht) Build-Prozesse zum Verketten zu verwenden, sollten Sie dies tun so. Zeitraum. Immer. Verketten Sie Dateien immer von 10-20 lokalen Dateien auf viel weniger.

ABER ich sage auch, dass es, sobald Sie diese einzelne Concat-Datei haben, auch von Vorteil sein könnte, Ihre einzelne Datei in 2-3 Blöcken zu laden, die parallel geladen werden (mit einem Skript-Loader).

Warum könnte das besser sein? Ich habe es in diesem Blogbeitrag ausgeführt, aber kurz gesagt:

1. Parallelladeeffekt ist real. fragen Sie Bit-Torrent-Benutzer danach. der HTTP-Overhead ist ebenfalls real und wirkt, um diesem Vorteil entgegenzuwirken und diesen zu eliminieren. Aber es bedeutet nicht, dass es unmöglich ist, davon zu profitieren. Mit Verbindung Keep-Alive ist es möglich, dass Sie 2 oder 3 gleichzeitige Verbindungen erhalten (ohne 2-3 volle Verbindungs-Overhead-Strafen) und Ihren Code in kürzerer Zeit laden. Wird es 1/3 der Zeit (60-70% schneller) sein, wenn Sie es in 3 Blöcken laden? Nein auf keinen Fall. Aber es kann 20-30% schneller sein.
2. Das Bereitstellen Ihres gesamten Codes in einer einzigen Datei verhindert, dass Sie unterschiedliche Cache-Header für unterschiedlichen Lebenszeitcode erstellen. jquery ist beispielsweise sehr stabil und muss nie erneut heruntergeladen werden. Ihr UX-zentrierter Code auf Ihrer Website kann jedoch sehr volatil sein (Sie können ihn einmal pro Woche oder öfter optimieren). Es ist dumm, kurze Cache-Header für die einzelne Concat-Datei zu verwenden, da es unnötig häufigere erneute Downloads von stabilem Code erzwingt. Es ist auch dumm, lange Caching-Header für die einzelne Concat-Datei zu erstellen, da Sie dadurch gezwungen werden, die zwischengespeicherte Datei (Cache Bust Param usw.) flüchtigerer Code. Wenn Sie also Ihre große Concat-Datei in 2 Blöcke aufteilen, einen für den stabilen Code, einen für den flüchtigen Code, können Sie für jeden Block unterschiedliche Caching-Header verwenden. Dadurch wird der Cache effektiver genutzt und die Leistung im Laufe der Zeit möglicherweise verbessert, da Benutzer Ihre Website wiederholt besuchen.
3. Studien haben gezeigt, dass ein einzelner Seitenaufruf im Durchschnitt weit weniger als 100 % des JS verwendet, das auf der Seite geladen wird (einige Schätzungen gehen von etwa 20-30 % des Codes aus). Das Laden Ihres gesamten Codes auf einmal, zu Beginn des Seitenladens, überlastet die Zeile unnötig, um 70-80% der Datei zu verschieben, die dann nicht benötigt wird (und möglicherweise "nie" benötigt wird). Wenn Sie Ihren Code in 2 Blöcken haben (einer ist der kritischere Code und der andere weniger kritischer Code), und Sie laden den ersten Block sofort und laden den zweiten Block einige Sekunden nach dem Laden der Seite, können Sie freigeben die Pipe für die viel wichtigeren Bilder/CSS und Inhalte. Im Wesentlichen ermöglicht Ihnen das Chunking, Ihren Code zu priorisieren.

Fazit... zum Thema Concat vs. Parallel... Ich sage den Leuten _immer_: beides.

@getify gut gesagt.

Kyles LABjs hat meine Unterstützung.
Als Berater, der Websites hilft, die Leistung zu verbessern, habe ich oft gesehen, wie LABjs gut funktioniert.
Es hat nicht nur die Leistung erheblich verbessert (nicht nur 100 ms, sondern 1+ s), sondern es hat auch den Entwicklern gefallen.
Leicht verständlich, einfach umzusetzen.

Und ich werde diese Gelegenheit nutzen, um öffentlich zu sagen: "Danke Kyle, für die großartige Unterstützung bei LABjs. Du hast meine Erwartungen mehrmals übertroffen."

Wenn Sie die Keep-Alive-Verbindung verwenden, können Sie 2 oder 3 gleichzeitige Verbindungen erhalten (ohne 2-3 volle Verbindungs-Overhead-Strafen).

HTTP muxt/verschachtelt keine Antworten, sodass Sie keine parallelen Downloads durchführen können, ohne zuerst mehrere Verbindungen zu öffnen. Der Idealfall einer persistenten und Pipeline-Verbindung entspricht dem fortlaufenden Download einer einzelnen Datei (+ wenige Header).

@pornel--

Ich habe aus erster Hand gesehen und bestätigt, dass Browser mehrere Verbindungen parallel zu einem einzigen Server öffnen können, wobei mit Connection Keep-Alive der Overhead für die zweite und dritte Verbindung drastisch geringer ist als für die erste. Das ist der Effekt, von dem ich rede.

@getify Fantastic, ich denke, wir haben eine Art Konsens erreicht. Um Ihr Gedächtnis aufzufrischen:

Ich kann ein Gegenargument zum Laden Ihrer Skripte in Stücken erwarten ...
aber das ist völlig orthogonal zur Skriptladetechnik, also lass es bitte weg
der Diskussion.

Ja, ich stimme zu, dass das Laden Ihrer flüchtigen Skripts in eine andere JS-Datei als Ihre permanenten Skripts großartig ist. Das Laden des Skripts, das nur für eine bestimmte Seite benötigt wird, nur auf dieser bestimmten Seite, ist ähnlich großartig.

Was soll ich also tun, wenn ich ein Webentwickler bin und eine Seite mit vielen JavaScripts habe? Verwenden Sie LABjs oder verketten Sie meine permanenten Skripts in einer Datei und meine flüchtigen Skripts in einer anderen und laden Sie beide am unteren Rand des Body-Tags mit <script defer="true"> ?

Warum sollte ich meine App Caching-Kopfschmerzen, Browser-Inkompatibilitäten, Wettrennen-gegen-den-Bildern-auf-der-Seite und dem Rest der Probleme aussetzen, die ein Skriptlader mit sich bringt?

Wenn die gesamte Prämisse bei der Verwendung eines Skriptladers für die Leistung darin besteht, dass es einfacher und einfacher ist als die Verwendung von zwei Skript-Tags ... Ich habe eine Brücke in Brooklyn, die ich Ihnen verkaufen kann.

@getify mehr als einmal einen Webserver implementiert hat: Keep-Alive beeinflusst in keiner Weise gleichzeitige Anfragen und reduziert nur die Kosten für nachfolgende Anfragen. Ein Split-Body mit zwei aufeinanderfolgenden Requests mit Keep-Alive ist immer noch teurer als ein einzelner Request. Zwei gleichzeitige Anfragen für die beiden Körperteile werden wahrscheinlich eine bessere Leistung erbringen, aber bedenken Sie, dass der Browser nur eine begrenzte Anzahl gleichzeitiger Anfragen öffnet (je nach Browser und Konfiguration ungefähr 5, denke ich), was in Ordnung ist, wenn alle Sie laden Ihre drei js-Dateien, aber wie @jashkenas mehr als einmal

@jashkenas-

Was soll ich also tun, wenn ich ein Webentwickler bin und eine Seite mit vielen JavaScripts habe? Verwenden Sie LABjs oder verketten Sie meine permanenten Skripts in einer Datei und meine flüchtigen Skripts in einer anderen und laden Sie beide am Ende des body-Tags mit <script defer="true">?

TL;DR: beide

Erstens werden viele Websites im Web von CMS zusammengestellt, was bedeutet, dass Inline-Skriptblöcke über die gesamte Seite verstreut sind und SEHR schwer zu lösen sind, wenn man einfach sagt "Verschiebe den gesamten Code in eine Datei". Ich denke also, dass die Prämisse, dass _die meisten_ Sites davonkommen können, ohne dass irgendein "Inline-Code" ausgeführt wird, nachdem ein anderes externes Skript geladen und ausgeführt wurde, bestenfalls unwahrscheinlich ist.

Zweitens habe ich bewiesen, dass sich defer DOMContentLoaded in verschiedenen Browsern anders verhält als defer ein Problem darstellen. Es ist vor allem wahr, dass es sich um einen sensiblen Bereich mit vielen Missverständnissen und Verwirrung handelt, sodass es schnell zu "Dies ist keine einfache einfache Lösung" wird. Es braucht viel mehr Gedanken.

Drittens denke ich, dass es für viele Sites viel einfacher ist, ihr Markup zu ändern, um $LAB.script() anstelle von <script> als ihnen zu erklären, wie man einen automatisierten (oder manuellen) Bulid-Prozess auf ihrer Seite installiert Server. Vor allem, wenn diese Site auf Shared-Hosting läuft (der größte Teil des Webs), und sie nicht wirklich viel von ihrem Server kontrollieren, und sie bitten, Build-Prozesse herauszufinden, damit ihre Code-Wartbarkeit nicht verloren geht, ist ... nun. .. nicht trivial.

Können diese Dinge überwunden werden? Ja. Natürlich können sie. Aber sie machen viel Arbeit. In einigen Fällen (wie beim DOM-bereiten Ding) können sie Ihren Code tatsächlich mühsam anpassen. Es braucht eine Person mit engagiertem Einsatz und viel Know-how und Leidenschaft in diesem Bereich, um alles zu regeln.

Im Gegensatz dazu können sie in LABjs anstelle des <script> Tags einen "schnellen Gewinn" erzielen. Es gibt wenig, worüber sie nachdenken müssen (außer document.write() ). Meistens "funktioniert es einfach". Und meistens sehen sie eine sofortige Geschwindigkeitssteigerung beim Seitenladen. Für die meisten Websites ist das ein großer Gewinn.

Um Ihre Frage zu beantworten, würde ich sagen, wie ich bereits sagte, tun Sie beides ... Zuerst fallen Sie in LABjs ab, sehen Sie einige sofortige Geschwindigkeitssteigerungen. Berücksichtigen Sie nun die Vorteile der Verwendung eines Build-Prozesses, um Sie von 15 Dateien auf 2 Dateien zu verschieben (1 Datei in zwei Hälften geteilt). Wenn Sie das tun (wenn Sie das tun, was wie gesagt die meisten nicht tun), können Sie LABjs fallen lassen, wenn Sie es wirklich wollen. Aber es schadet nicht wirklich (es ist klein und speichert gut, sogar auf dem Handy). Es wird Ihre beiden Dateiblöcke weiterhin gut laden UND dies ohne die Macken, die defer verursachen könnte.

Wenn LABjs bereits vorhanden ist, ist es für Sie außerdem unglaublich einfach, Schritt 3 auszuführen, nämlich herauszufinden, welchen Code Sie später "lazy/on-demand laden" können. Ohne einen Skriptlader geht das nicht. Wenn LABjs bereits vorhanden und vertraut ist, müssen Sie sich keine Gedanken darüber machen, wie Sie dieses On-Demand-Skript laden - es ist bereits herausgefunden.

@rkh--

Ich habe mir (insbesondere in Apache, mit Umschalten der Keep-Alive-Einstellung) demonstrieren lassen, wie mehrere parallele Anfragen betroffen waren (positiv, wenn Keep-Alive da war). Ich bin kein Experte auf diesem Gebiet, daher kann ich nicht über die genauen Details streiten, wie es funktioniert oder nicht. Ich kann sagen, dass der Zeitpunkt von Anfrage Nr. 2 geringer war als der Zeitpunkt von Anforderung Nr. 1, als Keep-Alive da war. Wie der Browser und der Server das gemacht haben, kann ich nur teilweise vermuten.

Ein Split-Body mit zwei aufeinanderfolgenden Requests mit Keep-Alive ist immer noch teurer als ein einzelner Request.

Ich habe nie behauptet, dass die zweite Anfrage kostenlos ist. Ich argumentierte, dass der zweite Antrag nicht so teuer ist wie der erste Antrag. Wenn wir also davon ausgehen, dass mindestens eine Anfrage gestellt werden muss, ist eine parallele zweite Anfrage hinsichtlich des Overheads oder der Zeitkosten NICHT dasselbe wie zwei völlig unabhängige Verbindungen zum selben Server.

Als Schätzung, es schien, dass Anfrage Nr. 1 X zu bedienen war und Nr. 2 parallel zu Keep-Alive-Vorhandenheit 0,7X war. Mir wurde erklärt, dass der Server einen Teil des bestehenden Verbindungs-Overheads für die Bedienung der zweiten Anfrage nutzen kann, wodurch es etwas billiger wird. Bei ausgeschaltetem Keep-Alive hatte die zweite Anforderung keinen solchen messbaren Rückgang.

Diese ganze Diskussion ist jedoch ein ernsthaft tiefer Kaninchenbau. Ich bin kein Server-Experte. Ich muss nicht sein. Ich kann nur erklären, dass ich tatsächlich zu diesem genauen Thema gesehen (und Tests erstellt) habe ... kann ich diese einzelne 100k-Dateiladezeit im Vergleich zum parallelen Laden von zwei Hälften derselben Datei testen, und wird der zweite Test messbar sein? Menge schneller. Wie ich bereits sagte, sah ich beim Chunked-in-Parallel-Test irgendwo zwischen 15-25% schneller. Wie es das geschafft hat und es irgendwie geschafft hat, den schrecklichen "OMG HTTP RESPONSE OVERHEAD IS TERRIBLE" -Effekt zu überholen und immer noch von zwei parallelen Ladevorgängen zu profitieren, bin ich wohl nicht qualifiziert, um es wissenschaftlich zu beweisen. Aber es hat definitiv durch Beobachtung getan.

Himmel, ihr Leute tippt schnell. Ich lese zu Ende, lade die Seite neu, und da sind noch neun weitere Kommentare.

Ich brauche Hilfe. Ich habe versucht, genau zu bestimmen, wohin wir in diesem Thread gegangen sind, von der Diskussion _was am besten für eine HTML-Datei mit Boilerplate funktioniert_ bis zur Diskussion _ob Skriptlader in allen Fällen Schlangenöl sind_.

@getify , Sie sollten LABjs auf jeden Fall verteidigen und auf spezifische Kritiken anderer im Thread reagieren, aber (mit Ausnahme von @jashkenas) denke ich, dass diejenigen, die LABjs kritisieren, dies tun, um zu zeigen, dass dies nicht die beste Lösung für eine Boilerplate ist. Sie argumentieren, dass es einfacher ist, Legacy-Seiten in LABjs zu konvertieren als in script[defer] , und das mag stimmen, aber wie trifft das auf eine HTML-Boilerplate-Datei zu (die per Definition bei Null beginnt)?

Sie sagen, dass es für Leute gedacht ist, die keine ausgefallenen Build-Prozesse haben, aber Sie scheinen auch das Verketten, das Aufteilen in gleich große Blöcke und das parallele Laden zu befürworten. Ist das nicht eine Aufgabe für ein Build-Skript? Auch hier scheint es die falsche Wahl für eine Boilerplate zu sein, die entwickelt wurde, um dem Benutzer intelligente Voreinstellungen zu geben. Wenn ein Benutzer diese angebliche Geschwindigkeitssteigerung von 20-30% wünscht, kann er später ein Upgrade über das anbieten, was der Boilerplate bietet, aber das ist keine triviale Aufgabe.

Wenn das alles gesagt ist, wenn ihr mit dem allgemeinen Thema ("Script Loaders: Valuable Tool or Snake Oil?") weitermachen wollt, werde ich gerne rumhängen und Popcorn machen.

@getify : Ich kann zustimmen, dass die zweite und dritte Verbindung möglicherweise schneller geöffnet wird als die erste – die erste wartet auf DNS und möglicherweise ist das Weiterleiten des allerersten Pakets an den Server etwas langsamer als das Weiterleiten des Rests entlang des gleichen Pfads. Bei HTTPS hilft der SSL-Sitzungscache nachfolgenden Verbindungen sehr.

Ich sehe jedoch keine Relevanz von Keep-Alive in dieser Situation. Nachfolgende _Anfragen_ auf derselben Verbindung werden mit Keep-Alive schneller gestartet, aber diese Anfragen sind innerhalb der Verbindung seriell.

Ich bin hier fast fertig -- ich habe gerade meinen "verrückten und nicht mehr ertragen" Moment in Bezug auf Skriptlader erreicht.

Abgesehen davon denke ich, dass dieser Thread für ein Flammenfest tatsächlich ziemlich produktiv war. Wenn LABjs einen Anspruch auf die unglücklichen und inkompetenten Websites erheben und die Leute in Ruhe lassen will, die ihre Websites eigentlich schnell laden möchten, ist dies ein großer Schritt nach vorne.

beruhig dich, Alter

@savetheclocktower--

Faire Fragen.

Ich habe meine Teilnahme an diesem Thread nicht damit begonnen, mich nachdrücklich dafür einzusetzen, dass LABjs (oder irgendein Skriptlader) in h5bp aufgenommen wird. Ich denke, es ist nützlich (siehe unten), aber es war nicht mein Hauptanliegen, dass ich den Schlaf verliere. Dieser Thread hat sich eindeutig in einen umfassenden Angriff auf alles verwandelt, was "Skriptladen" ist. Das ist mir natürlich etwas wichtiger.

Sie sagen, dass es für Leute gedacht ist, die keine ausgefallenen Build-Prozesse haben, aber Sie scheinen auch das Verketten, das Aufteilen in gleich große Blöcke und das parallele Laden zu befürworten. Ist das nicht eine Aufgabe für ein Build-Skript?

Ich plädiere zunächst dafür, alle Ihre Dutzende von Skript-Tags in einen parallelen Skript-Loader wie LABjs zu verschieben. Dies erfordert nichts weiter als die Möglichkeit, Ihr Markup anzupassen. Das ist ein weitaus einfacherer/weniger einschüchternder Schritt, als beispielsweise einer Mom&Pop-Site zu sagen, dass sie ein automatisiertes node.js-basiertes Build-System verwenden soll.

Und für diejenigen, die ihre Dateien erstellen KÖNNEN, befürworte ich, dass LABjs immer noch Vorteile hat, da es Ihnen helfen kann, diese Chunks parallel zu laden. Wenn Sie der Meinung sind, dass Chunks in irgendeiner Weise nützlich sind, sehen Sie keinen Grund, LABjs über defer . Aber wenn Sie verstehen, warum Chunking hilfreich sein kann, sollte ein Skript-Loader _bei diesem Prozess auch helfen_.

Auch hier scheint es die falsche Wahl für eine Boilerplate zu sein, die entwickelt wurde, um dem Benutzer intelligente Voreinstellungen zu geben.

Der einzige Grund, warum ich denke, dass ein Skriptlader (insbesondere einer, der wie LABjs entwickelt wurde, um eine Eins-zu-Eins-Zuordnung zwischen Skript-Tags und script() Aufrufen zu haben) einen Vorteil in einem Boilerplate hat, ist der in einem Boilerplate , sehen Sie oft eine Instanz von etwas (wie einem Tag), und Ihre Tendenz beim Aufbau Ihrer Seite besteht darin, dies so oft zu kopieren und einzufügen, wie Sie es benötigen. Wenn Sie also ein Muster mit schlechter Leistung (Skript-Tag) in der Boilerplate haben, neigen die Leute dazu, das Skript-Tag ein Dutzend Mal zu duplizieren. Ich denke, im Durchschnitt, wenn sie stattdessen den $LAB.script() Call ein paar Mal duplizieren, besteht eine gute Chance, dass ihre Leistung nicht ganz so schlecht ist, wie sie gewesen wäre.

Das ist der einzige Grund, warum ich angefangen habe, mich an diesem Thread zu beteiligen. Dies ist der einzige Grund, warum ich den Kommentar von beanstandet habe .

Sooooooooooo ja.

Ich denke, es ist klar, dass diese Diskussion weit darüber hinausgegangen ist, ob ein Skriptlader für das h5bp-Projekt geeignet ist. Aber das ist gut so, denn es lohnt sich, dieses Thema zu erkunden.

trotzdem interessiere ich mich sehr für reproduzierbare Testfälle neben Testergebnissen.

Es scheint auch, dass die Spezifikation für @defer geschrieben wurde, um einige der unberechenbaren Verhaltensweisen zu schützen, die Browser damit mitliefern. Dieses Verhalten sollte dokumentiert werden. Ich kann helfen, es zum MDC zu migrieren, wenn es fertig ist.

Wir brauchen eine klare Dokumentation zu diesem Verhalten, die alle Browser, verschiedene Verbindungstypen und Netzwerkeffekte erfasst. Ich bin mir nicht sicher, ob ein Teststand Cuzillion oder Assetrace verwenden sollte, aber das kann festgestellt werden.

Ich habe ein Ticket eingerichtet, um Interesse daran zu wecken https://github.com/paulirish/lazyweb-requests/issues/42

Begleiten Sie mich dort drüben, wenn Sie sich für die _superfun_-Aufgaben der Webperf-Recherche und Beweisdokumentation interessieren.

Betrachten wir diesen Thread als geschlossen, meine Herren.

Lazy Loading ist nicht der Hauptvorteil von AMD-Modulen, wie @import während der Entwicklung und das Ausführen eines automatisierten Builds zum Kombinieren von Stylesheets auch für große Projekte empfohlen wird ...

Ich glaube, dass dieser Beitrag, den ich letztes Jahr geschrieben habe, zum Thema passt: Das Leistungsdogma - Es geht nicht nur um Leistung und stellen Sie sicher, dass Sie nicht _Ihre Zeit verschwenden_, etwas "optimieren", das keinen _echten_ Unterschied macht ...

Und ich bin bei @SlexAxton , ich möchte AMD, aber einfache Skript-Tags reichen wahrscheinlich für die meisten Leute. Vielleicht wäre ein gültiger Ansatz, eine neue Einstellung hinzuzufügen, um ein AMD-Projekt auszuwählen und den RequireJS-Optimierer anstelle der _concat_-Aufgaben ( RequireJS-Optimierer-Ant-Aufgabe ) auszuführen, das wäre ziemlich cool und wahrscheinlich nicht so schwer zu implementieren.

Betrachten wir diesen Thread als geschlossen, meine Herren.

@paulirish Wie wäre es mit AMD-Support? Wo sollen wir das diskutieren?

@benatkin öffne ein neues Ticket, Bruder.

@paulirish OK, danke. @jrburke würden Sie bitte ein neues Ticket eröffnen, um die von Ihnen begonnene Diskussion fortzusetzen? Ich denke, ich werde einen Kommentar hinzufügen, aber ich glaube nicht, dass ich so gut wie Sie für AMD-Unterstützung argumentieren kann.

Unterhaltsam und informativ. Danke Leute.

Ich denke, jemand muss ein neues Skript-Loader-Projekt starten und es "Issue28" nennen. :)

Für die breiteste Kompatibilität kann eine schnelle Leistung erzielt werden, indem das Skript unten, minify, gzip, aber nicht verschoben wird. Zumindest nicht, bis die Browserkompatibilität für einige Jahre konsistent ist.

Engpässe können durch Anzeigen, zu viel Javascript, aufgeblähtes HTML, zu viel CSS, zu viele Iframes, zu viele Anfragen, Serverlatenz, ineffizientes Javascript entstehen. Anwendungen, die viele Bibliotheken von Drittanbietern verwenden, haben Probleme, die nicht nur durch zu viel Javascript verursacht werden, sondern darüber hinaus auch durch viele andere Probleme, hauptsächlich aufgeblähtes HTML, ungültiges HTML, zu viel CSS und ineffizientes Javascript. Da fällt einem sofort Twitter ein, da es zwei Versionen von jQuery und zwei Onscroll-Handler hat, die einen hüpfenden Onscroll in der rechten Spalte verursachen.

Der Clou ist, dass Sie diese Probleme vermeiden können, wenn Sie wissen, was Sie tun. Sie benötigen keine Dinge wie jQuery oder Unterstrich, und daher sind Ihre Skripte viel kleiner. Du schreibst sauberes, einfaches, valides HTML und CSS. Folglich werden Ihre Seiten schneller geladen, die App ist flexibler in Bezug auf Änderungen und die SEO verbessert sich. Und so fügt die Verwendung eines Skript-Loaders nur ungerechtfertigte Komplexität und Overhead hinzu.

https://github.com/BroDotJS/AssetRage

BOOM! Ich schließe die Clubs und ich schließe die Fäden.

Was für ein Thread ... wow.

Imo, die Diskussion begann im Kontext des h5bp, das ein Ausgangspunkt für Webentwickler sein soll.
Als solches können Sie feststellen, dass das Webdev, das das h5bp verwendet, tatsächlich sauberes HTML, sauberes CSS, eine gute .htaccess usw. hat und _vielleicht_ sogar _nicht_ unter zu vielen Bildern, ineffizientem JS, vielen beschissenen JS von Drittanbietern usw. leidet. weil der Web-Entwickler sich für die Verwendung des Hochleistungs-h5bp entscheidet und sich daher Gedanken über die Leistung macht und auf das Nicht-h5bp-Zeug achten wird, das auf die Seite(n) geht.

Aus dem Thread und in diesem Zusammenhang denke ich, dass es leider nicht genügend Beweise gibt, um eine endgültige Schlussfolgerung zu ziehen.
Ich bin mit Paul dabei, die Forschung in Gang zu bringen und zu dokumentieren, was dokumentiert werden muss.
Zählen Sie mich in Paul.

Randnotiz. Ich bin mit AMD nicht sehr vertraut und auf den ersten Blick erscheint es mir einschüchternd oder zumindest nicht so leicht zu erkennen. Ich denke, die meisten "normalen" Webentwickler werden zustimmen.
Das Zeug, das Sie in h5bp sehen, muss eine niedrige Eintrittsbarriere haben, sonst wird es nicht verwendet und die Aufnahme von h5bp kann langsamer sein, als es ohne es sein könnte.
Ich bezweifle, dass so etwas wie AMD in die h5bp gehört.
Halte es einfach.

Und noch ein Kommentar....
„Skripte ganz unten platzieren“ und „JS-Dateien zu einer einzigen Datei verketten“ steht seit vielen Jahren ganz oben auf der Liste der Best Practices von Web Perf. Warum haben also >90% der durchschnittlichen Websites, die von internen Entwicklern und Top-Markenagenturen erstellt wurden, immer noch mehrere Skript-Tags im HEAD? Wirklich? Warum ist das so?

Und die anderen 9% haben eine einzelne, verkettete JS-Datei ... im HEAD.
Selten sehe ich eine "normale" Site, die _nicht_ von einem Top-Web-Perf-Entwickler mit einem Skript unten erstellt wurde.

Entwickler halten Baustellen wie seit Jahren.
Websitebesitzer kümmern sich am meisten um Design und Funktionen, also verbringen die Entwickler ihre Zeit damit.

Eine Arbeitsweise zu ändern, ein Build-System, den Code ... es muss einfach sein, sehr einfach, sonst passiert es nicht.

Ich habe an vielen Sites gearbeitet, bei denen das Kombinieren des JS im HEAD in einer einzigen Datei und das Laden dieser am unteren Rand von BODY die Seiten auf der Site brachen. Und dann was? In den meisten Fällen ist es nicht einfach eine Stunde Arbeit, das zu beheben. Es muss ernsthaft umgestaltet werden ... und dies geschieht nicht aus Mangel an Wissen und vor allem aus Zeitmangel.

(oh richtig, der Thread ist geschlossen...)

Wir sprechen von einer Bibliothek, die auf jQuery und Modernizr basiert. Sagt wirklich alles. Wer nutzt das? Oh, Scheiße, ich vergesse, Twitter.com, das zwei jQuerys verwendet und auch im Quellcode Folgendes hat:

 Zeile 352, Spalte 6: End-Tag-Div gesehen, aber es gab offene Elemente.
 Fehler Zeile 350, Spalte 6: Ungeschlossenes Element ul.
 Fehler Zeile 330, Spalte 6: Ungeschlossenes Element ul.

Und das Problem bei der Erwartung, dass der Browser Fehler korrigiert, ist, dass HTML4 keine Fehlerkorrekturmechanismen definiert hat und Sie am Ende mit einem wer-weiß-was-wer-weiß-wo enden werden. Klar, HTML5 definiert die Fehlerbehandlung, aber es ist nicht rückwirkend - es gibt immer noch viele "alte" Browser.

Apropos Scheiße, hat sich hier jemand die jQuery ES5-Shims angesehen?

Übrigens, haben Sie Ihrer Aussage noch etwas hinzuzufügen, "dass der Webdev, der das h5bp verwendet, tatsächlich sauberes HTML haben wird", aaronpeters?

@GarrettS ok, ok, ich hätte schreiben sollen "wird _wahrscheinlich_ sauberes HTML haben"

:-D wir können immer hoffen!

Ein totes Pferd schlagen, ich weiß ... aber es stellte sich heraus, dass zur gleichen Zeit, als wir diese schillernde Diskussion führten, die aktuelle Version von LABjs tatsächlich einen Fehler hatte, der dazu führte, dass JavaScript in einigen Browsern in der falschen Reihenfolge ausgeführt wurde: https: //github.com/getify/LABjs/issues/36

Oh die Ironie.

muss. widerstehen. posten. total. [unangemessen. Bild. zum. früher. Aussage.... aggggh! AGONIE!

Mein Lieblingsteil war, als der Typ, der dhtmlkitchen.com (derzeit total durcheinander ) gemacht hat, anfing, über Markup-Fehler zu sprechen.

Diese Site wurde an Paulo Fragomeni übertragen. Ja, ich habe es geschafft und bin stolz auf das, was ich dort geschrieben habe, wie hier. Mach einen Screenshot von deinem schwachen Avatar, Esel.

...und wenn du damit fertig bist, versuche deinen Kopf aus deinem Arsch zu ziehen und den Unterschied zwischen meiner alten persönlichen Website (die nicht mehr von mir gepflegt wird) und einer, die von einem Team entwickelt und finanziert wird, zu verstehen ein profitables Multi-Millionen-Dollar-Unternehmen (obwohl Twitter Milliarden AFAIK wert sein kann).

Ich bin froh, dass wir das stilvoll und _zum Thema_ halten, Leute.

jashkenas hat die relevanten Informationen zu Beginn dieser Diskussion veröffentlicht.

Aber dann war da die Gegenreaktion. Nein! Es darf nicht sein! Souders sagte, es zu tun! Und es gab den schlechten Rat, aufschieben zu verwenden, sich nicht darum zu kümmern, wie es fehlschlägt, wenn es fehlschlägt.

Und dann kam ironischerweise aus dem Nichts die Behauptung, dass h5bp-Benutzer die Dinge richtig machen würden. Und das ist sehr ironisch, denn dieser Kommentar kam _nach_ Kommentaren von seinen Unterstützern, die offensichtlich ungültiges Markup produzieren und eine Menge Abstraktionsschichten von Drittanbietern (und schreckliche) verwenden. Und nach dem Kommentar zur Verwendung von Defer.

Und was hat das alles damit zu tun, dass dhtmlkitchen.com ausgefallen ist? Überhaupt nichts, offensichtlich. Das war nur ein schwacher Stoß von einem h5bp-Forker, der es nicht ertragen kann, Kritik zu hören.

Brüder
Kumpel.
Brüder

Dieser Thread ist geschlossen. Erinnern? Du musst nicht nach Hause gehen, aber du kannst hier nicht brennen.

Hey, erinnerst du dich daran, dass wir einmal einen epischen Thread erstellt haben, in dem es mehrere Debatten gab, persönliche Flammenkriege, die Leute überall wütend wurden, ein oder zwei obszöne Bilder und eine rundum gute Zeit? Ich kann nicht glauben, dass es kostenlos war. Das sollten wir irgendwann wiederholen.