Werden JS-Bibliotheken in Frames seltener geladen?

[Gerd Siebert]

Hallo, liebe Experten,
vielleicht erinnern sich noch einige über meine Anfrage weiter unten betreffs an Script-Bibliotheken zu kommen, die im Cache liegen, ohne dass diese dauernd neu geladen werden müssen (weil sie so riesig groß sind).  Nun, ich sehe ein, der Weg geht nicht!  Deshalb eine andere Idee:
Ein Frame Konstrukt!  Im Parent werden die Bibliotheken als externe Dateien aufgerufen - und sonst passiert in dem Parent Frame (der auch nicht sichbar ist) nicht viel mehr.  Alles weitere Surfen findet im Child-Frame statt und alle dort stattfindenden JS-Funktionsaufrufe bekommen halt das parent. .... davor (verdammt viel Arbeit!).
So ist - glaube ich - gewährleistet, dass die Bibliotheken höchstens einmal pro Surf-Session auf der Seite geladen werden und nicht bei jedem Seitenwechsel - das scheinbar durch nichta bei den Browsern normal zu vermeiden ist. (expires ... nützt trotz timestamp der Perl-Files nichts)

Also Parent ist dauernd aktiv und deshalb statisch und im Child wird gesurft mit JS-Funktionen die im Parent liegen!

Bevor ich mir nun die Riesenarbeit mache und das ganze System umbaue, möchte ich fragen, ob diese Idee Aussicht auf Erfolg hat?!

Im Augenblick ist es so, dass das Nachladen der fixen Bibliotheken mehr Traffic erzeugt, als die variablen Daten der Seite, die durch Perl erzeugt werden.

Hat das schon mal jemand gemacht?
Vielen Dank alleine scho mal dafür, diese Beschreibung überhaupt gelesen zu haben. ;)

[Cybaer]

Hi,

vielleicht erinnern sich noch einige über meine Anfrage weiter unten betreffs an Script-Bibliotheken zu kommen, die im Cache liegen, ohne dass diese dauernd neu geladen werden müssen (weil sie so riesig groß sind).

Gesucht, gefunden, geantwortet. ;-)

Nun, ich sehe ein, der Weg geht nicht!

Da siehst Du IMHO falsch.

Ein Frame Konstrukt!  Im Parent werden die Bibliotheken als externe Dateien aufgerufen - und sonst passiert in dem Parent Frame (der auch nicht sichbar ist) nicht viel mehr.

Die Bibliothek kann auch vom Frameset geladen werden (oder meintest Du das mit "Parent Frame"?)! Aber ich sehe dafür wirklich keinerlei Notwendigkeit. Alle Scripts zu ändern, wäre brutal. Vom unterschiedlichen Laufzeit-Verhalten und von sonstigen "bedenkenswerten Dingen" ganz zu schweigen ...

So ist - glaube ich - gewährleistet, dass die Bibliotheken höchstens einmal pro Surf-Session auf der Seite geladen werden

Das ist allerdings korrekt.

Hat das schon mal jemand gemacht?

Um Himmels willen ... =:-o

Gruß, Cybaer

[Gerd Siebert]

Hat das schon mal jemand gemacht?

Um Himmels willen ... =:-o

Gruß, Cybaer

Hi, Cybaer,
vielen Dank auch hier für Deine nette und hilfreiche Erklärung.  Nun, ich konnte die Finger nicht davon lassen und muß sagen, ich bin mehr als überrasccht.  Ich habe einfach mal angefangen, die Bibliotheken im Hauptdocument per ...src=... wie gewohnt im Header zu laden.  Mein eigentliches Document ist jetzt ein Frame.  Von dort werden alle Funhtionsaufrufe an die Bibliotheken mit "top.bibfubc()" gemacht.  Das hat den Vorteil, dass dieses Document genauso gut funktioniert (also wie bisher) wenn das System Framelos ist.
Die Änderungen in den Bibliotheken sind eigentlich auch relativ einfach und sicher.  Ansprechen von Objecteigenschaften wie "document.write()" gekommen einfach eine Namen davor "Aktdoc.document.write()", der wiederum im Hauptdocument entweder als Frame oder als der Documentenname definiert wird.
Und?  Es sieht wie gesagt recht gut aus.  Ich versuche natürlich mit dieser Umänderung nicht mein ganzes System zu zerstören und probiere mich Schritt für Schritt nach vorn.  Jedenfalls kann ich bisher auch keine Performanceeinbusen erkennen.
Und das allerwichtigste ist:  Definitiv findet innerhalb einer Session KEIN Neuladen der Bibliotheken mehr statt, den im Parent wird ja keine Seite weiter aufgerufen!

[Ingo Turski]

Hi,

Mein eigentliches Document ist jetzt ein Frame.  Von dort werden alle Funhtionsaufrufe an die Bibliotheken mit "top.bibfubc()" gemacht.  Das hat den Vorteil, dass dieses Document genauso gut funktioniert (also wie bisher) wenn das System Framelos ist.

und den Nachteil, daß keine Seite mehr vernünftig bookmarkbar ist und ein Deeplink - z.B. über eine Suchmaschine - nicht mehr funktionieren dürfte.
Du solltest wirklich einmal Deine HTTP-Header überprüfen. Normalerweise fordern die Browser die Resource nämlich nicht mehrfach an, wenn das hierin übermittelte Erstellungsdatum nicht neu ist.

freundliche Grüße
Ingo

[Gerd Siebert]

Du solltest wirklich einmal Deine HTTP-Header überprüfen. Normalerweise fordern die Browser die Resource nämlich nicht mehrfach an, wenn das hierin übermittelte Erstellungsdatum nicht neu ist.

freundliche Grüße
Ingo

Hi, Ingo,
vielen Dank für Deine Bemerkungen.
Aber glaube mir, ich würde hier nicht so'n Wind machen, wenn ich nicht schon alles probiert und untersucht hätte.  Ich habe sogar schon ausgiebig mit dem Leiter/Admin eines Providerunternehmens disskutiert.  Und wir haben nichts gefunden, außer der Tatsache, dass die Java-Script Bibliotheken immer wieder angefordert werden.
Die HTTP-header der Hauptseiten werden vom CGI header Modul erstellt und die wiederum von mir mit -cookie, -type und -expire gefüttert.  Alles läuft dabei bestens!  Hier ist der empfangen Header der Hauptseite (auszugsweise):

HTTP/1.1 200 (OK) Cache-Control: private Connection: closeDate: Sat, 06 Nov 2004 21:34:38 GMT Location: http://www.mytest.com Server: Microsoft-IIS/5.0 Content-Length: 121 Content-Type: text/html Client-Date: Sat, 06 Nov 2004 21:34:38 GMT Client-Peer: 471.108.154.711:80 Client-Response-Num: 1 Set-Cookie: Rnd=0%2E9715469; expires=Wed, 12-Nov-2036 08:00:00 GMT; domain=.mytest.com; path=/Set-Cookie: GUID=68A4906F%2D2620%2D45ED%2D7843%2D15DFDCAC87938; expires=Wed, 12-Nov-2036 08:00:00 GMT; domain=.mytest.com; path=/Title: ....

Aber wie schon immer wieder gesagt: Den Header von externen Java-Script Bibliotheken kann man nicht beeinflussen - jedenfalls nach meiner Kenntnis nicht!  Und genau da liegt der Hase im Pfeffer.

Vielen Dank jedenfalls für Eure tolle Mithilfe!

[Ingo Turski]

Hi,

Die HTTP-header der Hauptseiten werden vom CGI header Modul erstellt und die wiederum von mir mit -cookie, -type und -expire gefüttert.  Alles läuft dabei bestens!

Eine vielleicht dumme Frage: kann der Server *.js Dateien nicht unabhängig ausliefern?

1&1 liefert meine JS-Dateien so aus:
Response Headers - http://www.1ngo.de/1ngo.js

Transfer-Encoding: chunked
Date: Tue, 09 Nov 2004 17:32:35 GMT
Server: Apache/1.3.29 (Unix)
Last-Modified: Fri, 05 Nov 2004 12:29:32 GMT
Etag: "d9970c-1272-418b722c"
Accept-Ranges: bytes

Keep-Alive: timeout=2, max=200  
Connection: Keep-Alive  
Content-Type: application/x-javascript  
  
Anhand von Last-Modified erkennen wirklich fast alle Browser, ob sie die Datei bereits angefordert haben und holen sie dann ggfls. aus dem Cache. Im Server-Log wird dann der Statuscode 304 notiert, wonavh außer dem Header keine Daten mehr übermitelt wurden.  
  

> Server: Microsoft-IIS/5.0  

Oops.. kein Apache. aber auch diesem Server sollte man doch beibringen können, einen passenden HTTP-Header auszuliefern. Vielleicht kann Dir hier jemand sagen, wie das geht.  
  
freundliche Grüße  
Ingo

[Gerd Siebert]

Hi,

Die HTTP-header der Hauptseiten werden vom CGI header Modul erstellt und die wiederum von mir mit -cookie, -type und -expire gefüttert.  Alles läuft dabei bestens!
Eine vielleicht dumme Frage: kann der Server *.js Dateien nicht unabhängig ausliefern?

...Doch!  Da isser (hier mal von einem anderen Server):

HTTP/1.1 200 OK
Date: Tue, 09 Nov 2004 18:22:04 GMT
Server: Apache/1.3.31 (Unix) mod_ssl/2.8.19 OpenSSL/0.9.7d VDB/1.0.2
Last-Modified: Tue, 02 Nov 2004 23:07:30 GMT
ETag: "8a524a-173cf-41870932"
Accept-Ranges: bytes
Content-Length: 95195
VDB-Engine: 1.0.2
Content-Type: application/x-javascript

Aber diese Info hält IE6, Firefox oder Opera nicht ab, bei jedem Seitenwechsel neu zu laden.  Ich glaub' ich erschieß' mich mal ein bißchen...
Ich drehe echt bald durch.
Vielen Dank für Deine großartigen Bemühungen mit mir.

[Ingo Turski]

Hi,

Aber diese Info hält IE6, Firefox oder Opera nicht ab, bei jedem Seitenwechsel neu zu laden.

schon sehr merkwürdig. Wie gesagt werden meine JS-Dateien nur einmal übertragen. Das einzige, was mir dazu noch einfällt wäre der Etag-Header, der die Datei ja eindeutig bezeichnet und auch vom Client verwendet werden kann um zu prüfen, ob die Datei bereits gecached ist.

freundliche Grüße
Ingo

[Gerd Siebert]

Wie gesagt werden meine JS-Dateien nur einmal übertragen. Das einzige, was mir dazu noch einfällt wäre der Etag-Header, der die Datei ja eindeutig bezeichnet und auch vom Client verwendet werden kann um zu prüfen, ob die Datei bereits gecached ist.

freundliche Grüße
Ingo

Hallo Ingo,
ich hoffe, Du kommst nochmal in diesem Thread vorbei, weil ich scheinbar die Klärung des ganzen Problems habe!!!

Laut Log auf verschiedenen Servern erzeugt eine http-Header-Anfrage einer JS-Bibliothek schon selbst einen Datentransfer von 13-15kb!

Da bei meinem System vier Bibliotheken im Spiel sind, werden also daraus schonmal fast 60kb (was sich mit meinen Leitungstrafficdaten deckt).  Da das bei jedem Seitenwechsel stattfindet, werden aus 1000 Seitenklicks ganz schnell 60MB - ohne, dass ein tatsächliches Nachladen stattgefunden hat.

Ich würde mich freuen, wenn Du das mal auf Deinem Server testen könntest.  Ich habe meine 1&1 Accounts alle gekündigt, weil die Performance und der Preis einfach nicht mehr paßten.  Jeder Free-Hoster ist schneller und billiger.

Viele Grüße und schonmal Danke. Gerd

[Ingo Turski]

Hi,

ich hoffe, Du kommst nochmal in diesem Thread vorbei, weil ich scheinbar die Klärung des ganzen Problems habe!!!

natürlich doch...

Laut Log auf verschiedenen Servern erzeugt eine http-Header-Anfrage einer JS-Bibliothek schon selbst einen Datentransfer von 13-15kb!

Äußerst merkwürdig. Und warum sollte dies nur bei *.js Dateien sein?

Ich würde mich freuen, wenn Du das mal auf Deinem Server testen könntest.

Ich werte ja nur die Zugriffslogs aus und hier finde ich z.B.:

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
  "GET /web/infobox.html HTTP/1.1" 200 9852
  "GET /1ngo.js HTTP/1.1" 200 4722
  (verschiedene CSS- und Bilddateien)
  "GET /access-js1.gif?1280 HTTP/1.1" 200 932   (Test bestätigt aktiviertes Javascript)
  "GET /web/tips.html HTTP/1.1" 200 4749
  "GET /web/spam.html HTTP/1.1" 200 6690
  "GET /web/leistungen.html HTTP/1.1" 200 3493
  (ohne Anforderung der bereits geladenen Resourcen!?)
  "GET /web/leistungen.png HTTP/1.1" 200 25177

oder:
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
  "GET /tanz/salsa.html HTTP/1.0" 200 17820
  "GET /1ngo.js HTTP/1.0" 200 4722
  (verschiedene CSS- und Bilddateien)
  "GET /access-js1.gif?1024 HTTP/1.0" 200 932    (Test bestätigt aktiviertes Javascript)
  "GET /tanz/tanzschritte.html HTTP/1.0" 200 5470
  "GET /1ngo.js HTTP/1.0" 304 -
  (erneute Anforderung der bereits geladenen Resourcen mit 304 quittiert)

je nachdem, ob der Browser so eingestellt ist, daß er die Gültigkeit der Resourcen stets überprüft.

Der Header siet bei 200 so aus:
200 OK
Content-Length: 4722
Accept-Ranges: bytes
Server: Apache/1.3.29 (Unix)
Last-Modified: Fri, 05 Nov 2004 12:29:32 GMT
Connection: close
Etag: "d9970c-1272-418b722c"
Date: Wed, 10 Nov 2004 11:17:28 GMT
Content-Type: application/x-javascript

Bei 304 wüßte ich leider nicht, wie ich ihn herausbekomme...

Ich habe meine 1&1 Accounts alle gekündigt, weil die Performance und der Preis einfach nicht mehr paßten.  Jeder Free-Hoster ist schneller und billiger.

schneller kann ich nun nicht bestätigen aber billiger bei den aktuellen Paketen von 1&1 sicherlich; ich habe aber noch so ein Uralt-Billig-Angebot mit natürlich sehr beschränkten Möglichkeiten.

freundliche Grüße
Ingo

[Gerd Siebert]

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
  "GET /web/infobox.html HTTP/1.1" 200 9852
  "GET /1ngo.js HTTP/1.1" 200 4722
  (verschiedene CSS- und Bilddateien)
  "GET /access-js1.gif?1280 HTTP/1.1" 200 932   (Test bestätigt aktiviertes Javascript)
  "GET /web/tips.html HTTP/1.1" 200 4749
  "GET /web/spam.html HTTP/1.1" 200 6690
  "GET /web/leistungen.html HTTP/1.1" 200 3493
  (ohne Anforderung der bereits geladenen Resourcen!?)
  "GET /web/leistungen.png HTTP/1.1" 200 25177

Hi, Ingo,
vielen Dank für Deine Mühe!
Aber auch bei Deinem Log fallen mir zwei Sachen auf:
1.) Zum einen ist es ein GET und kein HEAD!  D.h. Dein Browser fragt auch nicht nach den http-headern, sondern will auch alles.
2.) Wie groß ist Deine js-Datei?  Sie ist doch genau 4722 Bytes groß!  Also, nix mit "nicht laden" wenn im Cache!

Meine Logs von meiner Datei belegen jetzt ganz klar, dass zwar keine Komplettfiledownloads stattfinden, aber GET's (keine HEAD's) mit immer schön 12346 Bytes pro Datei und Seite - und das alles such ohne Proxy und mit vielen verschiedenen Usern, Browsern und Servern getestet!

Ich bin gespannt, was bei Dir rauskommt, wenn Dein Browser eine .js Anfrage macht und die 1ngo.js im Cache ist.... Ehrlich!  Vielleicht sogar mehr Daten, als wenn die Datei geladen wird.

Viele Grüße und der frohen Hoffnung endlich mal Licht in diesen Tunnel zu bekommen!
Gerd

[Ingo Turski]

Hi,

1.) Zum einen ist es ein GET und kein HEAD!  D.h. Dein Browser fragt auch nicht nach den http-headern, sondern will auch alles.

Korrekt. In dem ersten von Dir zitierten Beispiel ist der Browser allerdings so eingestellt, daß er nur beim ersten Zugriff die JS-Datei anfordert und bei Folgeseiten (wie Du ja auch siehst) nicht mehr. Diese Einstellung ist bei meinen Besuchern übrigens so wi ich das auf den ersten Blick sehe am häufigsten.

2.) Wie groß ist Deine js-Datei?  Sie ist doch genau 4722 Bytes groß!  Also, nix mit "nicht laden" wenn im Cache!

Genau. Aber wenn Du Dir das zweite Beispiel ansiehst, wirst Du feststellen, daß der Browser die Datei erneut per Get anfordert und
  "GET /1ngo.js HTTP/1.0" 304 -
sie nicht erneut übertragen wird sondern nur mit Statuscode 304 (nicht geändert) geantwortet wird. An Traffic fallen also nur die paar Headerdaten an.

Meine Logs von meiner Datei belegen jetzt ganz klar, dass zwar keine Komplettfiledownloads stattfinden, aber GET's (keine HEAD's) mit immer schön 12346 Bytes pro Datei und Seite

Und mit welchen Statuscode? Und wirklich genau diese "12346" Byte? Eine sehr merkwürdige Zahl... Abgesehen davon: stelle Dir eine Seite mit 20 kleinen Gifs vor, wenn jeder Header alleine 12kb ausmachen würde - unvorstellbar.
Und für den Server ist eine *.js auch nur eine Datei wie jede andere auch - er muß lediglich den passenden Typ im Header übermitteln.

Ich bin gespannt, was bei Dir rauskommt, wenn Dein Browser eine .js Anfrage macht und die 1ngo.js im Cache ist.... Ehrlich!  Vielleicht sogar mehr Daten, als wenn die Datei geladen wird.

Auf jeder meiner Seiten wird dasselbe Javascript eingebunden und dieses enthält zwei Abfragen, die während des Ladens bereits ausgeführt werden. Wie ich schon sagte, wird die js-Datei - obwohl sie benutzt wird - meist nicht erneut angefordert und wenn doch mit 304 quittiert.

HEAD-Anfragen verzeichne ich übrigens fast ausschließlich nur von AOL (die sparen ja vermutlich mit ihrem Proxy).

freundliche Grüße
Ingo

[Cybaer]

Hi,

Laut Log auf verschiedenen Servern erzeugt eine http-Header-Anfrage einer JS-Bibliothek schon selbst einen Datentransfer von 13-15kb!

? =:-o Also ich habe da so meine Zweifel ...

... zumindest, daß das so sein muß. ;-)

Ich habe meine 1&1 Accounts alle gekündigt, weil die Performance und der Preis einfach nicht mehr paßten.  Jeder Free-Hoster ist schneller und billiger.

IMHO:
Schneller: Nein
Billiger: Ja
Besser: Nein

Alleine, daß 1&1 bei PHP auf den safe_mode verzichtet, ist ein gewaltiges Plus. Um mal nur einen wichtigen Punkt zu nennen.

Aber klar, es kommt immer auch auf die jeweiligen Bedürfnisse an ...

Gruß, Cybaer