Code effektiv aufteilen
1 
molily
Code effektiv aufteilen
Der MartinHi Leute,
ich hab einen recht "langen" Code (ca 10kb) und nicht alle Teile des Codes (also Funktionen) werden immer benötigt.
Macht es Sinn, den Code in kleinere Dateien aufzuteilen, also zB ajax zeug fürs login in eine extra Datei zu packen und die dann je nach Situation mit <script src"..">... zu laden oder gibts eine Methode, das noch während der Laufzeit zu tun (also wie bei PHP include/require)?
Besonders am Bespiel vom LogIn folgende Probelmatik: Das Script wird in Datei 1 nur benötigt, wenn der User noch nicht eingeloggt ist, ansonsten bräuchte es nicht geladen werden. In Datei 2 wird es gar nicht benötigt.
Hoffe, mein Problem ist halbwegs verständlich :)
Thx
-
Hallo,
ich hab einen recht "langen" Code (ca 10kb) und nicht alle Teile des Codes (also Funktionen) werden immer benötigt.
10 KB ist nicht nennenswert. Da lohnt sich eine Aufteilung kaum.
Ist die Datei schon minified und gzipped oder ist unverarbeiteter JavaScript-Code? Mit Minification (z.B. mit UglifyJS2) und GZip-Kompression lassen sich die 10 KB vielleicht auf 3-4 KB verkleinern.
Macht es Sinn, den Code in kleinere Dateien aufzuteilen, also zB ajax zeug fürs login in eine extra Datei zu packen und die dann je nach Situation mit <script src"..">... zu laden
Bei wirklich viel JavaScript (mehr als 100 KB minified+gzipped) macht es Sinn, über Lazy-Loading von JavaScript-Modulen nachzudenken. Darunter ist der HTTP-Overhead zu groß, wenn das JavaScript in mehreren einzelnen Dateien geladen werden. Somit ergibt sich kein Performance-Vorteil.
gibts eine Methode, das noch während der Laufzeit zu tun (also wie bei PHP include/require)?
Keine eingebaute. Man kann JavaScript-Dateien laden, indem man script-Elemente erzeugt und ins DOM einhängt. jQuery hat dafür die Methode getScript. Man kann das aber auch selbst in 15-20 Zeilen implementieren.
Für größere Anwendungen gibt die Modulstandards AMD und CommonJS. Entsprechende Loader sind RequireJS und Curl.
Mit r.js lassen sich aus vielen kleinen Modulen Pakete schnüren, die dann vom Client bei Bedarf geladen werden. – Das ist i.d.R. erst sinnvoll, wenn die JavaScript-Gesamtmenge mehrere 100 KB überschreitet (minified + gzipped). Es kommt natürlich auch ganz auf die Anwendung und deren Modularisierbarkeit an.
Besonders am Bespiel vom LogIn folgende Probelmatik: Das Script wird in Datei 1 nur benötigt, wenn der User noch nicht eingeloggt ist, ansonsten bräuchte es nicht geladen werden. In Datei 2 wird es gar nicht benötigt.
Diese Logik kannst du auch serverseitig in PHP programmieren. Wenn der User eingeloggt ist, wird kein script-Element ins HTML geschrieben.
Mathias
-
Hi,
danke für deine Antwort :)
Ok, da es maximal 15kb groß wird, wird es wohl ok sein, wenn alles in einer Datei ist. Dann probiere ich mal eine Kompression.
Mit neuen Script Tags hatte ich jetzt nicht so gute Erfahrung gemacht, meines Wissens musste der Code nämlich noch durch ein eval ausgeführt werden.-
Lieber jsoz,
Mit neuen Script Tags hatte ich jetzt nicht so gute Erfahrung gemacht, meines Wissens musste der Code nämlich noch durch ein eval ausgeführt werden.
das klingt nach einer etwas unglücklichen Programmarchitektur! Es kann sein, dass Du per Ajax nachgeladenes JSON mittels
eval("var j = "+meinAjax.responseText)einbauen wolltest. Was molily Dir aber vorschlagen wollte, war nicht Ajax zu nutzen, sondern wirklich ein neues <script>-Element per JavaScript ins Dokument zu schreiben, woraufhin der Browser die JS-Datei lädt und wie üblich verarbeitet.Beispiel:
function getScript (url) { var s = document.createElement("script"); s.type = "text/javascript"; s.src = url; document.body.appendChild(s); } // JS nachladen getScript('/js/script.js'); // erzeugt <script type="text/javascript" src="/js/script.js"></script> am Ende des <body>-ElementsLiebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)-
Jo, stimmt, hast recht, das war damals mit AJAX, aber hatte auch einen anderen Zweck.
Ok, danke für das Script :)
-
-
Hallo,
Dann probiere ich mal eine Kompression.
nein, lass es. Sehr wahrscheinlich macht dein Server das schon von sich aus, weil komprimierte Übertragung bereits als Option in HTTP vorgesehen ist. Schau dir mal die HTTP-Response-Header der Javascript-Ressource an (z.B. mit Firebug oder der LiveHTTP-Extension für Firefox). Wenn da ein
Content-Transfer-Encoding: gzip
oder etwa in der Art vorkommt, wird das Zeug bereits komprimiert übertragen, und der Browser entpackt es automatisch beim Empfang. Der Content-Lenght-Header gibt dann die komprimierte Größe an - wenn die signifikant von der echten Dateigröße abweicht, ist das auch ein deutliches Indiz.
So long,
Martin--
Ist die Katze gesund,
freut sich der Hund.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Jo, hast Recht, danke.
-
Dann probiere ich mal eine Kompression.
nein, lass es. Sehr wahrscheinlich macht dein Server das schon von sich aus, …
Das ist schon richtig. Trotzdem ist es üblich, .gz-Dateien einmalig mit hoher Kompression beim Deployment (Einspielen einer neuen Version) zu erzeugen. Die On-the-Fly-Kompression ist nämlich auf Performance optimiert und arbeitet nicht mit der höchstmöglichen Kompressionsstufe.
Apache und Nginx erlauben auch das automatische Ausliefern vorkomprimierter .gz-Dateien, wenn sie im Dateisystem liegen. Wenn z.B. foo.html angefragt wird und foo.html.gz existiert, wird letztere mit entsprechenden Headern ausgeliefert. On-the-Fly-Kompression kann mit mod_deflate bzw. ngx_http_gzip_module erfolgen.
Grüße,
Mathias
-
-
-