JavaScript - Aufteilung in separate, minimierte Dateien sinnvoll?

  • Hallo,

    in meiner EA gibt es viele Require.js Module, die sich jeweils einzelnen in einer eigenen js-Datei befinden. Ich möchte sie aus Performancegründen (und hier sicherlich öfters empfohlen) zu einer oder mehreren minimierten js-Datei(en) bündeln lassen.

    Zu meiner Frage: Ist es sinnvoll, je nach Anwendungsfall mehrere minimierte js-Dateien zu erstellen oder kann man bedenkenlos alles in einer minimierten js-Datei reinschmeißen? Es gibt in diesem Fall einige Module, die nur von bestimmten Benutzergruppen verwendet werden können, wie z.B. das Veröffentlichen von bestimmten Texten. Aus diesem Grund lässt mich der Gedanke nicht los, dass ich bei den Nutzern für unnötigen Traffic sorge, wenn ich denen eine js-Datei mit "nutzlosen" Modulen ausliefere. Von daher würde mich eure Meinung dazu interessieren. Vielleicht mache ich mir auch zu viele Gedanken :)

    Viele Grüße

    Joe

  • Früher (zu spdy-Zeiten) hat man empfohlen, die Dateien aufzuteilen. Heute empfiehlt es sich, alles zu bündeln, um die Anzahl der Requests klein zu halten. Allerdings sollte man nicht benötigtes CSS und JS bei Möglichkeit aufschieben, um das Rendering nicht zu blockieren.

    • Offizieller Beitrag

    Die genaue Aufteilung hängt vom verwendeten Protokoll ab:

    • HTTP 1.0/1.1: Große Bundles, um die Anzahl der Requests zu reduzieren.
    • HTTP 2.0 (trifft auch auf das alte SPDY-Protokoll zu): Kleinere Bundles, effizienter als jede Datei einzeln zu laden und vermeidet das Laden von nicht benötigtem Code.

    Allerdings kennt require.js das Prinzip der Bundles nicht wirklich, wodurch ein großes Bundle meist effizienter ist. Theoretisch kannst du auch ein "Core"-Bundle ausliefern, das die wichtigsten und am häufigsten benutzten Elemente ausliefert. Spezielle Dateien die nur selten verwendet werden, lässt du dann on-the-fly nachladen und erreichst so effizient das Ziel.

    Wenn die EA nur auf eigenen Systemen zum Einsatz kommt und HTTP 2.0 verwendet wird, ist der hybride Ansatz (Core-Bundle + einzelne Dateien) den meisten Sinn.

  • Vielen Dank für die Antworten! Ich werde dann mal schauen, ob ggf. einen Core-Bundle zusammengeschnürrt bekommen :thumbup: 3 Fragen hätte ich noch:

    1) Wie erstellt man mit r.js am geschicktesten den Core-Bundle? Sollte ich dafür am besten in der build-config die Funktion onBuildRead so anpassen, dass alle gewünschten Pfade/Module durchgelassen werden oder gibt es noch einfachere Lösungen?

    2)

    Spezielle Dateien die nur selten verwendet werden, lässt du dann on-the-fly nachladen und erreichst so effizient das Ziel.

    Wäre es also an dieser Stelle in Ordnung/vertretbar, wenn die selten genutzten Dateien nicht minimiert vorliegen, sondern "direkt" die Originaldatei geladen werden?

    3) Noch sicherheitshalber die Frage: Angenommen es würden alle vorhandenen Module in der minimierten js-Datei landen, gäbe es dafür Sicherheitsbedenken, die ich berücksichtigen sollte? An sich wären alle Module dann für alle Nutzer "sichtbar", aber mangels benötigster Nutzerrechte (z.B. bei Ajax Anfragen) unbrauchbar. Aber ich frage lieber jetzt als zu spät nach :)

    • Offizieller Beitrag

    1) Wie erstellt man mit r.js am geschicktesten den Core-Bundle? Sollte ich dafür am besten in der build-config die Funktion onBuildRead so anpassen, dass alle gewünschten Pfade/Module durchgelassen werden oder gibt es noch einfachere Lösungen?

    Ja, das ist die einfachste Möglichkeit. Die von uns verwendeten Build-Scripts findest du hier: https://github.com/WoltLab/WCF/tr…ed45ab9d2/extra

    Wäre es also an dieser Stelle in Ordnung/vertretbar, wenn die selten genutzten Dateien nicht minimiert vorliegen, sondern "direkt" die Originaldatei geladen werden?

    Das ist in der Regel nicht wirklich problematisch, der Performance-Unterschied verschwindet wahrscheinlich sogar im Messfehler.

    […] gäbe es dafür Sicherheitsbedenken, die ich berücksichtigen sollte? An sich wären alle Module dann für alle Nutzer "sichtbar", aber mangels benötigster Nutzerrechte (z.B. bei Ajax Anfragen) unbrauchbar.

    "Security by Obscurity" ist kein Sicherheitskonzept, ergo ist dies auch kein Sicherheitsproblem.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!