smart | Webentwicklung
Alles rund um HTML5, PHP, WordPress & Co.

Einführung in die HTML5 Application Cache API

22. September 2013
Stephan
Einführung in die HTML5 Application Cache API

Eine Möglichkeit statische Ressourcen, wie z.B. HTML-, CSS-, JavaScript-, & Grafikdateien, im Webbrowser zu Cachen, ist das bekannte Browser-Caching.

Insbesondere für Webapplikationen bietet HTML5 hierfür aber auch eine Alternative an und zwar in Form der Application Cache API und dem dazugehörigen Application Cache des Webbrowsers.

Wie ihr die HTML5 Application Cache API einsetzt und welche Vor- und Nachteile die API hat, erfahrt ihr in diesem Artikel.

3 Schritte zum Cachen von Ressourcen

Um mittels der Application Cache API bzw. dem Application Cache Ressourcen zu Cachen, sind im wesentlichen die folgenden 3 Schritte notwendig:

  1. Erstellen eines Cache-Manifests
    Hierbei handelt es sich um eine Datei, in der angegeben wird, welche Ressourcen gecached, nicht gecached bzw. im Offline-Betrieb durch andere Ressourcen ersetzt werden sollen.
  2. Manifest-Referenz den zu cachenden Webseiten hinzufügen
    Webseiten, die im Offline-Betrieb verfügbar sein sollen, müssen die Manifest-Datei referenzieren, damit der Webbrowser das Manifest und die darin angegebenen Ressourcen herunterlädt.
  3. Webserver konfigurieren
    Der Webserver muss das Manifest mit dem richtigem MIME-Typ ausliefern und zum Client senden.

Die Cache-Manifest-Datei

Bei der Cache-Manifest-Datei bzw. dem Manifest, handelt es sich um eine reine Textdatei, in der die absoluten bzw. relativen URLs der Ressourcen definiert werden.

Da die Application Cache API der Same Origin Policy unterliegt, muss die Herkunft (Origin) der Ressourcen mit der der Manifest-Datei übereinstimmen.

Sowohl der Name als auch die Endung der Datei können individuell gewählt werden. Wichtig ist nur, dass die Textdatei bzw. das Manifest UTF-8 kodiert ist und vom Webserver mit dem MIME-Typ text/cache-manifest ausgeliefert wird.

Beispiel:

CACHE MANIFEST
# v.1
styles.css
jquery.js

NETWORK:
webservice.php

FALLBACK:
registrierung.html fallback.html

CACHE:
images/logo.png

SETTINGS:
prefer-online

Die erste Zeile des Manifests besteht grundsätzlich immer aus der Zeichenkette CACHE MANIFEST und Kommentare werden immer mit einer Raute (#) angegeben. Nach der obligatorischen ersten Zeile können direkt die URLs der zu cachenden Ressourcen aufgelistet oder aber durch die Angabe von 4 verschiedenen Schlüsselwörtern spezielle Manifest-Abschnitte eingeleitet werden.

Im oben aufgeführten Beispiel ist z.B. definiert, dass die styles.css und jquery.js im Cache gespeichert werden.

Die Bedeutung der erwähnten Schlüsselwörter bzw. dadurch eingeleiteten Abschnitte sind im Folgenden erläutert:

  • CACHE
    Dient als alternative Möglichkeit zur Angabe der URLs von zu cachenden Ressourcen, die nicht unmittelbar nach der ersten Zeile aufgelistet sind. Im aufgeführten Beispiel wird somit auch die Grafik logo.png als zu cachende Ressource deklariert.
  • NETWORK
    Auflistung der URLs von Ressourcen, die nicht gecached werden sollen. Anfragen an diese Ressourcen werden nicht zum Cache weitergeleitet. Beispielsweise sollten spezielle API-Anfragen im Allgemeinen nicht gecached werden. Im Gegensatz zum CACHE-Abschnitt ist auch die Angabe von „Wildcards“ erlaubt.
  • FALLBACK
    Ermöglicht die Angabe von alternativen Ressourcen, die geladen werden sollen, wenn eine angefragte Ressource nicht verfügbar ist. Im Beispiel wird z.B. angegeben, dass die fallback.html geladen werden soll, falls die registrierung.html nicht gecached und somit nicht verfügbar ist. Wie im NETWORK-Abschnitt können auch hier „Wildcards“ eingesetzt werden.
  • SETTINGS
    Sobald eine Ressource im Application Cache verfügbar ist, lädt der Webbrowser die Ressourcen immer aus dem Cache auch wenn eine Internetverbindung besteht. Mittels prefer-online wird dem Webbrowser mitgeteilt, dass die Ressourcen nur dann aus dem Cache bezogen werden, wenn keine Internetverbindung besteht.

Angemerkt sei auch, dass die im Cache gespeicherten Ressourcen nur dann vom Webbrowser neu geladen und im Cache gespeichert werden, wenn sich das Manifest geändert hat.

Wie beschrieben, müssen die entsprechenden Webseiten das Manifest auch referenzieren. Hierfür dient das manifest-Attribut, dass dem html-Tag einer Webseite hinzugefügt wird:

<html lang="de" manifest="app-cache.manifest">

Jede Webseite mit einem solchen Eintrag wird im Kontext des HTML5 Application Caches als ein sogenannter Master-Eintrag gewertet. Das bedeutet, dass die Webseite nicht explizit in der Cache-Manifest-Datei angegeben werden muss, sondern automatisch vom Webbrowser immer mitgecached wird.

Die API

Bei der Application Cache API handelt es sich um eine synchrone API, die zum Zugriff auf den Application Cache des Webbrowsers dient. Konkret erfolgt der Zugriff dabei über das globale applicationCache-Objekt, welches das ApplicationCache-Interface implementiert:

interface ApplicationCache : EventTarget
{
    const unsigned short UNCACHED = 0;
    const unsigned short IDLE = 1;
    const unsigned short CHECKING = 2;
    const unsigned short DOWNLOADING = 3;
    const unsigned short UPDATEREADY = 4;
    const unsigned short OBSOLETE = 5;
    readonly attribute unsigned short status;

    void update();
    void abort();
    void swapCache();

    attribute EventHandler onchecking;
    attribute EventHandler onerror;
    attribute EventHandler onnoupdate;
    attribute EventHandler ondownloading;
    attribute EventHandler onprogress;
    attribute EventHandler onupdateready;
    attribute EventHandler oncached;
    attribute EventHandler onobsolete;
};

Der Application Cache findet sich zu jedem Zeitpunkt in einem bestimmten Zustand, der durch einen entsprechenden Status repräsentiert wird. Um den aktuellen Status auszulesen, gibt es die status-Eigenschaft. Diese Eigenschaft gibt einen der im Interface vordefinierten Konstantenwerte zurück.

Findet ein Statuswechsel statt, werden entsprechende Events vom Webbrowser ausgelöst. Die im Interface spezifizierten Event-Handler dienen dazu, um auf die verschiedenen Statuswechsel reagieren zu können.

Für nähere Informationen zur API, wie z.B. der Erläuterung der einzelnen Statuswerte, empfehle ich euch die dazugehörige Spezifikation anzuschauen: WHATWG – Offline web applications

Des Weiteren definiert das ApplicationCache-Interface 3 Methoden. Erstere lautet update und dient zum programmatischen Start des Update-Prozesses. Die abort-Methode dagegen bricht einen laufenden Update-Prozess ab. Die swapCache-Methode kann aufgerufen aufgerufen werden, um den Cache mit den aktuellsten Ressourcen zu verwenden.

Generell wird der Cache mit den neuesten Ressourcen immer erst nach einem Aufruf von swapCache oder einem Neuladen der Webseite vom Webbrowser verwendet.

Browser-Unterstützung

Generell wird die Application Cache API von allen gängigen und modernen Webbrowsern unterstüzt. Eine genaue Browser-Auflistung mit den unterstützten Versionen findet ihr auf caniuse.com.

Vor- & Nachteile

Vorteile:

  • einfache zu implementierende API
  • eignet sich zum Cachen von statischen Ressourcen
  • Update-Prozess des Cache kann programmatisch gestartet werden
  • in allen gängigen Webbrowsern verfügbar

Nachteile:

  • keine Möglichkeit, programmatisch auf die gecachten Ressourcen zuzugreifen
  • Cache wird nur aktualisiert, wenn sich das Manifest geändert hat
  • Ressourcen werden immer aus dem Cache geladen, was für bestimmte Anwendungsfälle nicht unbedingt optimal ist
  • keine Möglichkeit, die Gültigkeit des Cache bzw. einzelner gecachter Ressourcen anzugeben

Weiterführende Informationen

Falls ich ihr noch mehr über die HTML5 Application Cache API nachlesen möchtet, dann empfehle ich euch die folgenden Artikel:

Fazit

Mit der HTML5 Application Cache API und dem dazugehörige Cache gibt es eine sinnvolle Alternative zum traditionellen HTTP-Browser-Caching zum Cachen von statischen Ressourcen.

Interessant ist diese API zum einen für offline-fähige Webapplikationen als auch generell zur Optimierung der Performance von Webapplikationen.

Habt ihr mit der HTML5 Application Cache API schon mal rumexperimentiert? Was haltet ihr von dieser Art des Caching?

Kommentare  
0 Kommentare vorhanden
0 Trackbacks/Pingbacks vorhanden
Du bist herzlich eingeladen auch ein Kommentar zu hinterlassen!
Kommentar schreiben

Vielen Dank für dein Kommentar!