Wenn Sie sich nur um die Leistung kümmern, sind die meisten Ratschläge in diesem Thread völlig falsch und werden in der SPA-Ära, in der wir davon ausgehen können, dass die Seite ohne den JS-Code unbrauchbar ist, immer falscher. Ich habe unzählige Stunden damit verbracht, die Ladezeiten von SPA-Seiten zu optimieren und diese Ergebnisse mit verschiedenen Browsern zu überprüfen. Auf der ganzen Linie kann die Leistungssteigerung durch Neu-Orchestrierung Ihres HTML-Codes ziemlich dramatisch sein.
Um die beste Leistung zu erzielen, müssen Sie sich Seiten als zweistufige Raketen vorstellen. Diese beiden Stufen entsprechen ungefähr <head>und <body>Phasen, aber betrachten Sie sie stattdessen als <static>und <dynamic>. Der statische Teil ist im Grunde eine String-Konstante, die Sie so schnell wie möglich über die Antwortleitung schieben. Dies kann etwas schwierig sein, wenn Sie eine Menge Middleware verwenden, die Cookies setzt (diese müssen vor dem Senden von http-Inhalten gesetzt werden), aber im Prinzip wird nur der Antwortpuffer geleert, hoffentlich bevor Sie in einen Vorlagencode (Rasiermesser, PHP, etc) auf dem Server. Das mag schwierig klingen, aber dann erkläre ich es nur falsch, weil es fast trivial ist. Wie Sie vielleicht vermutet haben, sollte dieser statische Teil alles Javascript enthalten, das inline und minimiert ist. Es würde ungefähr so aussehen
<!DOCTYPE html>
<html>
<head>
<script>/*...inlined jquery, angular, your code*/</script>
<style>/* ditto css */</style>
</head>
<body>
<!-- inline all your templates, if applicable -->
<script type='template-mime' id='1'></script>
<script type='template-mime' id='2'></script>
<script type='template-mime' id='3'></script>
Da es Sie so gut wie nichts kostet, diesen Teil über das Kabel zu senden, können Sie davon ausgehen, dass der Client dies nach einer Verbindung mit Ihrem Server etwa 5 ms + Latenz empfängt. Unter der Annahme, dass der Server relativ nahe ist, kann diese Latenz zwischen 20 ms und 60 ms liegen. Browser beginnen mit der Verarbeitung dieses Abschnitts, sobald sie ihn erhalten, und die Verarbeitungszeit dominiert normalerweise die Übertragungszeit um den Faktor 20 oder mehr. Dies ist nun Ihr amortisiertes Fenster für die serverseitige Verarbeitung des <dynamic>Teils.
Es dauert ungefähr 50 ms, bis der Browser (Chrome, Rest möglicherweise 20% langsamer) Inline-Abfrage + Signal + Winkel + ng animiert + ng Berührung + ng Routen + Lodash verarbeitet. Das ist an und für sich schon erstaunlich. Die meisten Web-Apps haben weniger Code als alle gängigen Bibliotheken zusammen, aber nehmen wir an, Sie haben genauso viel, sodass wir auf dem Client Latenz + 100 ms Verarbeitung gewinnen würden (dieser Latenzgewinn kommt vom zweiten Übertragungsblock). Bis der zweite Block eintrifft, haben wir den gesamten js-Code und die Vorlagen verarbeitet und können mit der Ausführung von dom-Transformationen beginnen.
Sie können einwenden, dass diese Methode orthogonal zum Inlining-Konzept ist, dies ist jedoch nicht der Fall. Wenn Sie anstelle von Inlining eine Verknüpfung zu CDNS oder Ihren eigenen Servern herstellen, muss der Browser eine andere Verbindung (en) öffnen und die Ausführung verzögern. Da diese Ausführung grundsätzlich kostenlos ist (da die Serverseite mit der Datenbank spricht), muss klar sein, dass all diese Sprünge mehr kosten würden, als überhaupt keine Sprünge zu machen. Wenn es eine Browser-Eigenart gäbe, die besagt, dass externes js schneller ausgeführt wird, könnten wir messen, welcher Faktor dominiert. Meine Messungen zeigen, dass zusätzliche Anforderungen die Leistung in dieser Phase beeinträchtigen.
Ich arbeite viel mit der Optimierung von SPA-Apps. Es ist üblich, dass die Leute denken, dass das Datenvolumen eine große Sache ist, während in Wahrheit Latenz und Ausführung oft dominieren. Die minimierten Bibliotheken, die ich aufgelistet habe, addieren sich zu 300 KB Daten, und das sind nur 68 KB gezippt oder 200 ms Download auf einem 2 MBit 3g / 4g-Telefon. Dies ist genau die Latenz, die auf demselben Telefon benötigt wird, um zu überprüfen, ob dieselben Daten vorhanden sind bereits im Cache, auch wenn der Proxy zwischengespeichert wurde, da die Steuer auf mobile Latenz (Telefon-zu-Turm-Latenz) weiterhin gilt. In der Zwischenzeit haben Desktop-Verbindungen mit geringerer First-Hop-Latenz normalerweise ohnehin eine höhere Bandbreite.
Kurz gesagt, im Moment (2014) ist es am besten, alle Skripte, Stile und Vorlagen einzubinden.
BEARBEITEN (MAI 2016)
Da JS-Anwendungen weiter wachsen und einige meiner Nutzdaten jetzt mehr als 3 Megabyte minimierten Codes stapeln, wird klar, dass zumindest gängige Bibliotheken nicht mehr eingebunden werden sollten.