Ist es eine gute Praxis, ein Bundle pro Ansicht in Asp Net MVC zu haben?

Da es beim Bündeln und Minimieren darum geht, Seiten zu optimieren und schneller zu laden, erscheint es mir logisch, ein Paket für Skripte und ein Paket für Stile pro Ansichtsbasis zu erstellen, damit ein Browser alle Skripte und Stile laden kann höchstens 2 Anfragen zu stellen. _Layout.cshtmlNehmen wir also an, ich habe eine Datei bootstrap.js, in der ich 3 JS-Dateien benötige , jquery.jsund in einigen custom1.jskann ich ein Bundle erstellen, etwa so:

bundles.Add(new ScriptBundle("~/bundles/layout").Include(
          "~/Scripts/bootstrap.js",
          "~/Scripts/jquery.js",
          "~/Scripts/custom1.js"));

Nehmen wir an, ich habe eine andere Ansicht, User.cshtmlwo ich sie benötige bootstrap.js, jquery.jsund custom2.jserstelle erneut ein Bundle:

bundles.Add(new ScriptBundle("~/bundles/user").Include(
          "~/Scripts/bootstrap.js",
          "~/Scripts/jquery.js",
          "~/Scripts/custom2.js"));

Der gleiche Ansatz kann für Stilbündel verwendet werden. Soweit ich weiß, ist es jedoch nicht üblich, dies auf diese Weise zu tun. In der Regel werden Bundles auf Typbasis erstellt, z. B. eines für Bootstrap, eines für JQuery, eines für benutzerdefinierte JS / CSS-Dateien usw. Dies würde sich jedoch nicht erhöhen Die Ladezeit der Seite, da mehr Bundles mehr Anfragen an den Server bedeuten. Was ist auch das Problem, Dinge so zu machen, wie ich es am Anfang beschrieben habe?

Ich denke, es könnte fast sogar kontraproduktiv sein, ein einziges Bundle pro Seite zu verwenden.

Es gibt einen Overhead für die Erstellung des Bundles ... obwohl dieser Overhead einmal pro Anwendungsinstanz anfällt (er wird von der Anwendung nach dem ersten Aufruf zwischengespeichert), aber wenn Sie für jede Seite ein neues Bundle haben, bedeutet dies für jede einzelne Seite Wenn Sie uns besuchen, muss ein neues Bundle erstellt werden, bevor es bereitgestellt werden kann. Das würde den Zweck der Bundles erheblich beeinträchtigen, denke ich.

Vielmehr habe ich normalerweise zwei Bundles: ein Core-Bundle, das voraussichtlich von jeder Seite benötigt wird und sich nach dem Einrichten des ersten Projekts kaum ändern wird. Dies umfasst Kernstile, jQuery / Knockout und andere Bibliotheken von Basisanbietern.

Das zweite Bundle ist normalerweise ein Anwendungskontext (z. B. enthält das Benutzerpaket möglicherweise modulare Elemente, die sich auf Benutzer im Allgemeinen beziehen, jedoch nicht unbedingt auf eine bestimmte Seite).

Alles, was seitenspezifisch ist, geht normalerweise nicht einmal in ein Bündel.

Der praktische Leistungseffekt der Bündelung (zumindest für Geschäftsanwendungen, die ich normalerweise schreibe) ist nicht wirklich großartig, wenn man bedenkt, dass der Client sie nach dem ersten Aufruf so lange verwendet, bis sie sich ohnehin wieder ändert.

Wenn Sie eine öffentliche Website haben, auf der Sie eine größere Anzahl von Erstbesuchern erwarten, können Sie einen etwas anderen Ansatz wählen.

Nein.

Durch das Zwischenspeichern von Browsern erzielen Sie die besten Gesamtergebnisse, wenn Sie auf allen Seiten dasselbe Bundle oder dieselben Bundles verwenden. Dies bedeutet, dass der Benutzer alle CSS und JS herunterlädt, wenn er auf die erste Seite gelangt, und diese Datei auf den folgenden Seiten wiederverwendet.

Da der Großteil des Bundles aus Javascript-Frameworks wie jquery und bootstrap besteht. Ihre zusätzlichen paar Bytes an benutzerdefiniertem Code wirken sich nur unwesentlich auf die Gesamtladegeschwindigkeit der Seite aus.

Der Nachteil eines Bundles pro Seite ist, dass das zwischengespeicherte Bundle von einer Seite nicht auf einer anderen Seite verwendet werden kann. Normalerweise möchten Sie, dass der Großteil Ihrer Skripte (z. B. jQuery-Bootstrap usw.) einmal heruntergeladen und für alle Seiten zwischengespeichert wird der Standort.

Die aus Caching-Sicht "optimale" Lösung wäre, ein einziges Bundle zu haben, das alle .js für alle Seiten auf der gesamten Site enthält. Der Nachteil dieses Ansatzes besteht darin, dass das Bundle ziemlich groß ist, was bedeutet, dass das anfängliche Laden der Seite langsamer ist Dies ist möglicherweise nicht wünschenswert für Websites mit Kundenkontakt, auf denen erste Eindrücke alles sind.

Die "beste" Lösung wird wahrscheinlich eine Mischung von Techniken sein, z

• Ein "Kern" -Paket (Dinge wie jQuery und Bootstrap, die auf fast jeder Seite verwendet werden) plus ein Paket pro Seite
• Ein einzelnes Bundle für die gesamte Site, möglicherweise ohne eine Javascript-schwere Seite, die die Bundle-Größe erheblich erhöht