hallo Fabian,

Du weißt doch so gut wie wir alle, dass a) HTTP zustandslos und b) nicht verbindungspersitent ist. Jedes mal, wenn du ein im Browser anzeigbares Element (HTML-Seite, XML-Dokument, was du magst eben...) _änderst_ wird es vom Server geholt

Eben. Daher hatte ich ja um eine Einschätzung der Geschwindigkeit gebeten.

Alle Referenzen _in_ diesem Dokument werden erst dann geholt, wenn sie auf dem Client angekommen sind.

Natürlich. Da kommen wir übrigens auf Chräckers Frage nach den Grafiken zurück. Ich habe eben mal schnell noch eine Seite mit dazwischengeschoben, die eine große (über 250 kB) Grafik enthält, um etwas deutlicher zu machen, worum es mir geht.

Im Grunde genommen habe ich ja (mindestens) zwei Scripts: einmal die Gesamtseite, die eventuell nicht nur HTML auszugeben, sondern auch noch Variablen zu verarbeiten oder andere Dinge zu treiben hat, und als zweites das in alle Seiten eingebundene kleinere Navigationsscript. Der Effekt ist (bzw. soll sein), daß das Navigationsscript (das keine Grafik, sondern nur Text und ein bißchen CSS-Formatierung enthält) ja schon mit seiner Ausgabe fertig sein kann, während der Rest der Seite vielleicht noch aufgebaut wird. Optisch soll sich das so darstellen, daß an den Navigationslinks eben durch keinerlei "Flackern" bemerkbar wird, daß sie entweder aus dem Cache  -  was blitzschnell gehen sollte  -  oder tatsächlich neu vom Server geholt werden, während der "Rest" der Seite von mir aus bei größeren Grafiken auch etwas mehr Zeit beanspruchen darf. Du siehst das, wenn du dir die neu eingefügte Seite mit der großen Grafik mal anschaust  -  die Grafik _kannst_ du ja beim ersten Aufruf noch nicht in deinem Cache haben.

Und _diesen_ Effekt, daß eine Navigationsleiste, in der es keine Grafiken gibt, optisch scheinbar stillsteht, während sich eventuell aufgerufene Seiten neu aufbauen, wollte/will ich haben. Den hatte ich vor rund anderthalb Jahren noch nicht, jetzt scheint das aber zu funktionieren.

So, jetzt sollte deine Nachfrage beantwortet sein.

Grüße aus Berlin

Christoph S.