Versteckte Frames für clientseitiges Caching

Um den Inline-Frame innerhalb des versteckten Frames zu erzeugen, verwenden wir auf der Client-Seite die JavaScript-Funktion document.write. Glücklicherweise sind Inline-Frames aus Sicht des Browsers schlichte HTML-Dokumente. Dies erlaubt es, den readyState des Inline-Frames abzufragen, um festzustellen, ob das Dokument fertig ist. Aber wenn man ständig den readyState abfragt, macht das die ganze Sache ja wieder langsamer. Besser ist es deshalb, zu diesem Zweck eine JavaScript-Funktion zu erstellen und window.setTimeout zu benutzen, um die Ausführung der Funktion zu verzögern. Dann kann man den readyState des Inline-Frames in regelmäßigen Abständen abfragen, ohne Ressourcen auf dem Client-Rechner zu verschwenden und womöglich den Browser zu blockieren.

Sobald das Inline-Frame-Dokument fertig ist, ist das Kopieren eines Objekts in einen sichtbaren Frame eine relativ einfache Angelegenheit. Dazu muss man nur das innerHTML aus dem Inline-Frame in den sichtbaren Frame kopieren.

Das setSpan-Skript
Ich habe eine JavaScript-Funktion namens setSpan geschrieben, die einem die mühselige Arbeit der dynamischen Erzeugung von Inline-Frames abnimmt. Die Funktion überprüft, ob ein Inline-Frame erstellt wurde und ob er fertig ist. Wurde der Inline-Frame noch nicht erstellt, holt die Funktion dies nach und wartet, bis er fertig ist. Sobald der readyState des Inline-Frames ‚complet‘ signalisiert, kopiert setSpan das innerHTML an das gewünschte Ziel und ruft gegebenenfalls eine Initialisierungs-Routine auf.

Aus Gründen der Konsistenz habe ich mich entschieden, für jedes Objekt eine eigene Active Server Page zu erstellen und diese in einem Verzeichnis namens IFrame abzulegen. Ebenfalls aus Konsistenzgründen gibt es außerdem für jedes im sichtbaren Frame anzuzeigende Objekt ein include. Dieses include besteht aus einem HTML <Span>-Tag und einem Verweis auf setSpan (Listing B).

Ich habe ein paar Code-Beispiele geschrieben, um die Verwendung der in diesem Artikel beschriebenen Routinen zu veranschaulichen. Die Beispiele sind als Download verfügbar und bieten eine Überblick, wie man versteckte dynamische Inline-Frames für clientseitiges Caching einsetzen kann.

Fazit

Clientseitiges Caching ist keineswegs ein Allheilmittel gegen all die Probleme, die Ihnen als Webentwickler Kopfschmerzen bereiten können. Es löst nicht alle Probleme, denen Sie sich beim täglichen Spagat zwischen dem Wunsch nach Geschwindigkeit und professionell wirkenden Anwendungen gegenüber sehen. Aber es stellt eine relativ einfache Möglichkeit dar, die Performance auf der Client-Seite zu verbessern.

Page: 1 2

ZDNet.de Redaktion

Recent Posts

Vorinstallierte Schadsoftware auf IoT-Geräten

Mit dem Internet verbundene Digitale Bilderrahmen oder Mediaplayer können mit Schadsoftware infiziert werden und sind…

6 Tagen ago

iOS und iPadOS 18.2 beseitigen 21 Sicherheitslücken

Schädliche Apps können unter Umständen einen Systemabsturz auslösen. Mindestens eine Anfälligkeit erlaubt eine Remotecodeausführung.

6 Tagen ago

Top-Malware im November: Infostealer Formbook bleibt Nummer 1

Sein Anteil an allen Infektionen steigt in Deutschland auf 18,5 Prozent. Das Botnet Androxgh0st integriert…

6 Tagen ago

Google schließt schwerwiegende Sicherheitslücken in Chrome

Betroffen sind Chrome 131 und früher für Windows, macOS und Linux. Angreifer können unter Umständen…

7 Tagen ago

Data Analytics: Dienstleister wachsen zweistellig

Marktforscher Lündendonk erwartet für das Jahr 2025 ein durchschnittliches Umsatzwachstum von 14,9 Prozent.

7 Tagen ago

Open-Source-Malware auf Rekordniveau

Alarmierender Anstieg von Open-Source-Malware / Seit 2019 haben Sonatype-Analysen mehr als 778.500 bösartige Pakete aufgedeckt

1 Woche ago