HTML-Frames zur Entlastung des Servers

Stellen Sie sich einen Frame mit der Größe 0 vor. Der Frame wäre effektiv unsichtbar für den Anwender. Nicht besonders sinnvoll? Im Gegenteil. Wenn man den Server-Traffic reduzieren will, ist ein versteckter Frame eine sehr nützliche Angelegenheit.

Eine Verwendungsmöglichkeit für einen versteckten Frame ist das Speichern von Informationen, die später verarbeitet werden sollen. Ein Beispiel: Ich habe einmal für ein Versicherungsunternehmen ein Intranet-basiertes System für technische Anfragen erstellt. Dieses System erlaubte internen Kunden die Eingabe unterschiedlicher Anfragen, die Hilfe durch den System-Support erforderten. Es gab ungefähr ein Dutzend verschiedener technischer Anfragen, die von so einfachen wie „Run the fuzzy report“ bis zu „Take this input file, convert it to our internal format, and load it to the insured database“ reichten.

Der Kunde musste eine oder mehr Seiten an Informationen eingeben, je nach Art der Anfrage. Anstatt diese Informationen direkt vom Client an den Server zu schicken und sie in Session-Variablen auf dem Server zu speichern, entschied ich mich dafür, sie beim Client mithilfe eines versteckten Frames zu speichern. Dies erlaubte es dem Benutzer, den Zurück-Button zu benutzen, um die vorherige Seite mit allen Daten aus dem versteckten Frame anstatt vom Server zu sehen, was den Traffic reduzierte. Sobald die Eingaben vollständig waren und der Benutzer auf „Abschicken“ klickte, wurde das Formular aus dem versteckten Frame abgeschickt.

Wie bei fast allen Dingen, kann man es auch bei dieser Technik übertreiben. Ich habe einmal eine Intranet-Anwendung gesehen, die mehr als 50 versteckte Frames enthielt, wo alle nur denkbaren Objekte gespeichert waren, die möglicherweise irgendwann einmal beim Navigieren durch die Anwendung benötigt werden könnten. Dies waren List-Boxes, Bilder und Swing-Applets, die alle beim ersten Aufruf der Anwendung geladen wurden. Die Idee dabei war, dass nach dem vollständigen anfänglichen Laden die Anwendung sehr schnell sein würde, denn es wäre z.B. unnötig, jedes Mal eine neue List-Box mit Produkten zu erstellen. Stattdessen könnte sie einfach aus dem versteckten Frame kopiert werden, was den Server entlasten würde. Ich hielt das für eine der genialsten Ideen, die ich je gehört hatte. Allerdings lies die Ausführung noch einiges zu wünschen übrig.

Stellen Sie sich vor, zur gleichen Zeit 50 ASP-Seiten zu laden, von denen die meisten Informationen aus einer Datenbank benötigen. Andere Seiten benötigten große Bilder oder riesige Java Swing Applets. Ich gebe zu, sobald erst einmal alles geladen war, lief das Ganze beeindruckend schnell, aber das Laden dauerte fünf Minuten mit Ethernet-Geschwindigkeit! Ich wage nicht, mir vorzustellen, wie lange es mit einer 56K-Verbindung gedauert hätte. Obwohl also die Umsetzung der Technik des Ladens von Objekten in versteckten Frames noch zu wünschen übrig lies, war die grundlegende Idee doch brauchbar.

Eine Frage der Frames

Wie jedes andere Werkzeug sind Frames von Natur aus weder gut noch böse. Die meisten Bauchschmerzen, die Entwickler mit Frames haben, rühren aus missbräuchlicher Verwendung in der Vergangenheit her. Wie wir gesehen haben, sind HTML-Frames bei korrektem Gebrauch eine Möglichkeit, den Server zu entlasten. Im nächsten Artikel werde ich eine praktikable Möglichkeit zeigen, wie man Objekte in versteckte Frames lädt – was weniger als fünf Minuten dauern wird.