tr0y

Ich persönlich empfinde deine Frage zwar etwas pauschal gestellt aber ich versuch sie mal lückenfüllend zu beantworten:

Zuerst eine Vorabinfo: Das was du willst ist nicht, das du verhindern willst das die Page neu geladen wird. Du möchtest die Ladezeiten für den Besucher der deine Webseite betrachtet so gering wie möglich halten, was im Kerngedanke ja auch eine Gute Idee ist. Zu verhindern das die Page dabei ständig neugeladen und neu aufgebaut ( heruntergeladen ) wird, ist im Kern aber auch der Denkfehler. Das Zauberwort heißt (Browser-)Caching.

Nundenn Theorie hin oder her, ein Beispiel muss her: Facebook ( ich duck mich schon mal, aber ein besseres fällt mir jetzt nicht ein.. )

Es gibt aus Sicht des Servers ( Traffic ) und aus Sicht des betrachtenden Users keinen spürbaren Unterschied zwischen dem Laden bereits im Cache des Browser liegender Daten und nachladen von Content-Inhalten ( Facebook ) und dem nachladen von HTML-Fragmenten in einem bereits dargestellten HTML-Grundgerüst ( dein Ansatz. )

Im Beispiel Facebook wird bei jedem Request der einen Seitenwechsel darstellt die komplette Webseite requested, gegen die Daten im Cache validiert und entsprechend nicht-vorhandener Änderungen der Cache dargestellt. Das ist kein Wunder der Technik, das ist eine Basisfunktion der heutigen Browser-Technologie. Jeder aktuelle Browser kann das, sogar schon seit einigen Versionen. Alle nicht-statischen Inhalte die in das Grundgerüst gehören werden dann per AJAX ( Javascript ) nachgeladen. Anwendbar ist die Methode bei Webseiten die zwar hochflexibel in der Darstellung von Content sein müssen, dessen Grundaufbau allerdings immer der selbe ist. Wie auch in deinem Fall.

Schematisch bedeutet das:

• REQUEST & LOAD : ( cached ) Website Skelett ( 20-50 kbytes )
• RUN AJAX: Navigation States ( 100-200 byte )
• RUN AJAX: Site Content ( ∞ kbytes )

Der erste schritt passiert in der Regel pro "neuer Besucher" irgendwann mal einmalig, insofern sich das Skelett der Seite nicht ändert.

Dagegen Schematisch ein normaler Seitenaufbau:

• REQUEST & LOAD : ( never cached ) Full Website ( ∞ kbytes )

Egal bei welchem Request würde ein Cache-Skelett dem Server also 20.000-50.000 Bytes an Traffic ersparen. Die Grundoptik würde also nur einmal geladen werden müssen ( Kern-Komponente dieser Methode ), was schlussendlich zu einem nicht "verschnellerbaren" Seitenaufbau führt.

Sicherlich könnte man jetzt mit dem Stichwort server-side Caching kommen und ich könnte auch noch mein "heiliges" Smarty mit in den Topf werfen. Server-side caching reduziert allerdings nur hinterrücks die Ladezeit, was da reduziert wird ist im Grunde die Generierungszeit für den kompletten HTML-Matsch der an den Browser gehen soll. Beides ( server-side & browser caching ) ist aber durchaus gut kombinierbar und effizient.

Es gibt im Bereich Caching aber einiges das du beachten musst, fang am besten an dich darüber zu informieren was Caching im genauen bedeutet und arbeite dich dann durch zu der genauen Funktionsweise von Browser-Caching und dessen Voraussetzungen ( Header & Co ).

Lesestoff: http://www.mnot.net/cache_docs/ ( englisch ) - außerdem siehe Wikipedia "Cache"

Eine (un)echte Alternative dazu wäre die Seite ansich und dessen grafische Gimmicks "schneller" zu machen. JPEGs & Co kann man durchaus mit einer Kompressionsstufe verwenden die aus einem 800kb Datei-Kollos eine 290kb Datei macht. Bilder können so granulativ fragmentiert werden das sie von mehreren "Servern" ( eigentlich ein und dem selben ) gleichzeitig vom Browser geladen werden ( auch dazu findet man relativ viel lesestoff per Google ). Boost-Möglichkeiten gibt es in 99% der Fälle immer. Ob notwendig sei vorerst dahingestellt.

Was du hier liest ist der Theoretische Lösungsansatz. Ich poste dir hier explizit keinen Code der obiges oder anderes realisiert. Den kriegst du selbst zu stande, wenn du dir darüber im klaren bist welche Logik hinter dem ganzen steckt.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

Mister Ad