Werden Javascript (Client) Frameworks zusammen mit der Webseite downgeladen wenn Websurfer auf eine Seite zugreifen?
-
Müßte doch so sein, denn die Javascript Befehle in der HTML Datei greifen auf solche Frameworkfunktionen ja zu.
Wenn die also auf dem Client (Browser) bekannt sein sollen, dann muss das ganze Framework ja downgeladen werden.Ist das so richtig?
Wenn ja, ist das nicht etwas viel Overhead zum Downloaden?
Das dürften doch sicher pro Webseite dann mindestens 1-2 MB sein und jede Webseite nutzt ein anderes Framework, womit sich die Downloadmenge akkumuliert.
Und was ist, wenn mehrere Webseiten das gleiche Framework verwenden, wird da wenigstens irgendwie am Download gespart?
-
Die JavaScript Runtime ist typischerweise im Browser integriert. D.h. wenn Du den Browser installierst wird die JS Runtime auch installiert oder es ist gerade ein Teil des Browsers.
Ist das so richtig?
In dem Fall: Nein.
-
theta schrieb:
Die JavaScript Runtime ist typischerweise im Browser integriert. D.h. wenn Du den Browser installierst wird die JS Runtime auch installiert oder es ist gerade ein Teil des Browsers.
Runtime != Framework.
Aber ich frage mich, welche Frameworks der TE benutzt, bei den Größenangaben.
Zur Frage:
Zunächst wird der Browsercache dafür sorgen, dass pro Site (Domain) nur einmal geladen wird, z.B. indem alle Seiten auf /javascript/xyztools.js verlinken. Dann werden Scripte oft obfuskiert, d.h. überflüssige Einrückungen entfernt und lange Bezeichner durch kurze ersetzt. Und zu guter Letzt können HTTP-Client und -Server miteinander aushandeln, dass bestimmte Dateien gezippt verschickt werden. Wenn der Server "weiß", dass diese Datei sich nicht oder selten ändert, kann er eine obfuskierte und gezippte Version irgendwo cachen.
-
Die werden gecachet hoff ich mal.
Die JavaScript Runtime
... ist hier gar nicht gemeint.
-
Und was ist, wenn mehrere Webseiten das gleiche Framework verwenden, wird da wenigstens irgendwie am Download gespart?
Noch etwas.
Könnte es sein, daß auf die Webseite des Frameworks referenziert wird?
So wie z.B. der Doctype bei HTML auf w3c.org.Wenn ja, dann würden viele Webseiten sich das Framework teilen und der Traffic wäre nicht all zu groß.
Aber ich frage mich, welche Frameworks der TE benutzt, bei den Größenangaben.
Ich meinte jetzt kein konkretes, aber wenn man sich den Umfang moderner Frameworks so anschaut, insbesondere diejenigen, die nen halben Desktop mit Fenstern, Buttons, Verzeichnisbaum usw. abbilden, dann dürfte das nicht klein sein.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Webzeugs verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Javascript Frameworks schrieb:
Aber ich frage mich, welche Frameworks der TE benutzt, bei den Größenangaben.
Ich meinte jetzt kein konkretes, aber wenn man sich den Umfang moderner Frameworks so anschaut, insbesondere diejenigen, die nen halben Desktop mit Fenstern, Buttons, Verzeichnisbaum usw. abbilden, dann dürfte das nicht klein sein.
Nicht raten, sondern selber messen. Übliche Frameworks sind weit unter einem Megabyte.
Jeder übliche HTTP-Server sendet seine Daten heute standardmäßig komprimiert, einfach weil mittlerweile jeder Browser das versteht und es deutlich effizienter ist. Dieses Forum hier sendet seine Seiten auch alle gezippt (natürlich nur, sofern der Browser dem Server sagt, dass er es versteht). Insofern ist der Traffic durch Javascript-Dateien eigentlich nur relevant bei wirklich großen Seiten mit entsprechend vielen Anfragen.
-
Ich dachte man hätte bei HTTP anfangs deswegen auf das zippen verzichtet, weil es Rechenzeit beim Server kostet und das reine rausschicken von HTML Text somit schneller geht.
Gerade bei großen Serven mit dutzenden Anfragen, die alle individualisierte HTML Seiten verschicken müssen, dürfte die ganze Packerei doch gehörig auf die Performance und Latenz gehen.
-
Javascript Frameworks schrieb:
Ich dachte man hätte bei HTTP anfangs deswegen auf das zippen verzichtet, weil es Rechenzeit beim Server kostet und das reine rausschicken von HTML Text somit schneller geht.
Gerade bei großen Serven mit dutzenden Anfragen, die alle individualisierte HTML Seiten verschicken müssen, dürfte die ganze Packerei doch gehörig auf die Performance und Latenz gehen.
Im Gegenteil, Komprimierung verringert die Latenz, weil man insgesamt weniger TCP-Pakete braucht. Der Rechenaufwand für eine einfache Komprimierung ist dermaßen gering, damit lastest du die Internetverbindung eines Servers ohne weiteres voll aus.
-
Die meistverwendeten Libraries bindet man dennoch gerne ueber ein gutes CDN ein - wo die Chance dass die Library lokal gecacht ist recht hoch ist.
zB googleapis: https://developers.google.com/speed/libraries/devguide