Handlungsempfehlungen "Green Web" für Administratoren

HTTP-Caching-Unterstützung konfigurieren

Die Konfiguration der Webbrowser kann im Allgemeinen nicht von den Designern und Administratoren verändert werden. Deshalb muss hier die serverseitige Unterstützung des Caching näher in den Blick gerückt werden. Etwa 80% der Webnutzer haben das Caching in ihrem Webbrowser konfiguriert, die übrigen 20% haben immer einen leeren Cache (vgl. Theurer 2007). Durch das Einbinden Caching-bezogener Metadaten durch den Webserver kann die Anzahl der HTTP-Anfragen und HTTP-Antworten signifikant verringert werden. In HTTP/1.1 ist das Caching dazu bestimmt,

  • die Notwendigkeit für Anfragen an den Server ("expiration mechanism") und
  • die Notwendigkeit für Anworten an den Client ("validation mechanism")

zu verringern.

Der "expiration mechanism" verringert die Zahl der an den Server gesendeten HTTP-Anfragen. Der "validation mechanism" verringert hingegen die Nutzlast der an den Client zurückgesendeten HTTP-Antworten und befasst sich somit mit der Reduktion der Netzwerkbandbreite (vgl. Fielding 1999, S. 74).

Um den "expiration mechanism" von HTTP-Servern zu unterstützen, können Administratoren einen Expires- oder Cache-Control-Header für Serverantworten definieren bzw. konfigurieren. Der in HTTP/1.0 (vgl. Berners-Lee 1996, S. 41) beschriebene Expires-Header legt das Datum fest, nach dem die Antwort als ungültig betrachtet wird. Ein geringeres Problem mit dem Expires-Header ist, dass ausdrücklich Zeichenketten mit Datums- bzw. Zeitangaben verwendet werden. Für eine korrekte Funktionsweise müssen deshalb die Uhren von Client und Server synchronisiert sein, was i. A. nicht der Fall ist (vgl. Crocker 1982, S. 26; Souders 2007, S. 22). Diese Beschränkung des Expires-Header wurde mit HTTP/1.1 aufgehoben. Hier wird die Direktive Max-Age verwendet, um die Dauer in Sekunden festzulegen, die die angefragte Ressource im Cache verbleiben soll. Um mit älteren HTTP-Clients, die HTTP/1.1 nicht unterstützen, kompatibel zu bleiben, darf weiterhin der Expires-Header zusammen mit dem Cache-Control-Header verwendet werden. In diesem Fall überschreibt der Cache-Control-Header den Expires-Header.

Der "validation mechanism" wird von HTTP-Clients verwendet, die einen bereits abgelaufenen Ressourceneintrag in ihrem Cache haben. In diesem Fall darf der Client eine bedingte HTTP-Anfrage an den Server senden. Diese bedingte Anfrage sieht genauso aus wie eine normale Anfrage, außer, dass sie einen sogenannten Validator mitführt, der vom Server verwendet werden kann, um zu entscheiden, ob die vom Client verwendete Ressource immer noch aktuell ist oder ob sie aktualisiert werden muss. Für den Fall, dass sie aktualisiert werden muss, werden die aktuellen Daten an den Client zurück gesandt. Andernfalls antwortet der Server mit dem HTTP-Status "304 Not modified". Es können zwei Cache-Validatoren verwendet werden: "Last-Modified" oder "Entity-Tag" (auch: "ETag"). Im Falle einer Last-Modified-Datumsangabe wird ein Eintrag im Cache als gültig betrachtet, falls die angeforderte Ressource seit dem angegebenen Zeitpunkt auf dem Server nicht mehr verändert wurde. Ein Entity-Tag ist ein eindeutiger Bezeichner für eine bestimmte Version (Entität/entity) einer Ressource (vgl. Fielding 1999, S. 85). Die Berechnung der Entity-Tags wird allerdings nicht von der Spezifikation festgelegt, sondern der Implementierung des Webservers überlassen. Die HTTP/1.1-Spezifikation legt fest, dass Server beide Werte, Entity-Tag und Last-Modified, zusammen in ihren Antworten senden dürfen. HTTP/1.1 Clients werden jedoch von der Spezifikation dazu gezwungen, Entity-Tags in bedingten HTTP-Anfragen zu senden, sofern der Server diese bereitgestellt hat. Zusätzlich können Clients auch die Last-Modified-Datumsangabe übertragen, falls diese gesetzt wurde (vgl. Fielding 1999, S. 86).

Um die Zahl der HTTP-Anfragen und die Größe der Nutzlast in den HTTP-Antworten zu verringern, empfehlen wir die serverseitige Unterstützung der Client-Caches richtig zu konfigurieren. Das heißt:

  1. Setzen später Ablaufdatumsangaben und Cache-Control-Header für Ressourcen, die sich selten ändern
  2. Setzen des Last-Modified-Headers und der Entity-Tags für alle Ressourcen, die in nachfolgenden Anfragen nicht neu berechnet/generiert werden müssen (hauptsächlich statischer Inhalt)

Ein einfaches Konfigurationsfragment für den weit verbreiteten Apache Webserver könnte z. B. so aussehen:

ExpiresActive On

ExpiresDefault "access plus 355 days"
FileETag MTime Size

Die Konfigurationsanweisung "ExpiresDefault" beinhaltet sowohl die Erstellung des Expires-Headers als auch die Erstellung des Cache-Control-Headers für die jeweils angegebenen Dateitypen.

Komprimierung anwenden

Heute unterstützen viele moderne Webbrowser Komprimierungsalgorithmen, die das Datenvolumen der Serverantwort verringern, wodurch kürzere Übertragungszeiten erzielt werden, woraus sich ein niedrigerer Energieverbrauch für die Datenübertragung ergibt.

Webbrowser unterstützen üblicherweise die Kompressionsformate GZIP und/oder DEFLATE. Beide Formate werden eigens in der HTTP/1.1 Spezifikation genannt. Der Accept-Encoding-Header wird von Webbrowsern verwendet, um dem Webserver anzuzeigen, welche Kodierungsarten sie akzeptieren. Ein Webserver darf dann den Inhalt mit einem vom Webbrowser angegebenen Kodierungsart bzw. Kompressionsmethode komprimieren, muss den Webbrowser aber mit dem Content-Encoding-Header über die verwendete Kompressionsmethode in Kenntnis setzen (vgl. Fielding 1999).

Die Komprimierung ist jedoch nicht so einfach, wie sie auf den ersten Blick erscheint. Einige ältere Browserversionen, die angeben, dass sie eine Kompressionsmethode unterstützen, unterstützen diese auf Grund von Inkompatibilitäten oder Programmfehlern tatsächlich nicht. Allerdings ist bekannt, dass mehr als 95% (vgl. ADTECH 2008) der in Europa benutzten Webbrowser die Kompressionsmethode GZIP unterstützen. Deshalb ist es im Bezug auf das Ziel eines "Green Web Engineerings" vernünftig, die Kompression serverseitig zu aktivieren.

Allerdings sind nicht alle Inhalte für die Komprimierung geeignet, wie z. B. komprimierte Bilder, komprimierte Videos und Musik oder PDF-Dokumente. Die Komprimierung dieser Dateitypen kann manchmal sogar kontraproduktiv sein. Deshalb sollte die Komprimierung nur auf Dateien angewandt werden, die gut komprimierbar sind, wie z. B. textbasierte Dateien oder nicht komprimierte Bilder. Bei einer einfachen Beispielwebseite, die von einem Apache Webserver mit GZIP komprimiert wurde, erreichten wir die in Tabelle 1 gezeigten Einsparungen. Die durchschnittliche Einsparung der gesamten Beispielseite beträgt somit ca. 60% (unter der Annahme, dass die bereits komprimierten PNG-Bilder nicht nochmals komprimiert werden).

Tabelle 1: Gegenüberstellung von unkomprimierter und komprimierter Dateigröße
Beispielinhalt Unkomprimierte Dateigröße (KB) Komprimierte Dateigröße (KB) Ersparnis
index.html 5,45 2,44 55,3%
style.css 2,73 0,68 75,1%
prototype.js 126,00 29,51 76,6%
ida-logo.png 24,80 24,86 -0,2%
ucb-logo.png 9,27 9,28 -0,1%

"Green IT" Konzepte anwenden

Bisher gibt es mehrere Web-Hosting-Anbieter, die Web-Hosting mit erneuerbaren Energien anbieten. Zusätzlich können Administratoren die neuesten Techniken im Bezug auf Green IT anwenden, wie z. B. Server-Virtualisierung.

Quellen- und Literaturverzeichnis

  • ADTECH (2008): Survey Unveils Extent of Internet Explorer Domination Across the European Browser Landscape. [Online] ADTECH: London.
    Verfügbar unter: http://www.adtech.com/news/pr-08-07_en.htm [Letzter Abruf: 10.10.2009].
  • Berners-Lee, T., Fielding, R. & Frystyk, H. (1996): Hypertext Transfer Protocol -- HTTP/1.0. Request for Comments 1945. [Online] Network Working Group.
    Verfügbar unter: http://tools.ietf.org/html/rfc1945 [Letzter Abruf: 10.10.2009].
  • Crocker, D. H. (1982): Standard for the Format of ARPA Internet Text Messages. Request for Comments 822. [Online] University of Delaware.
    Verfügbar unter: http://tools.ietf.org/html/rfc822 [Letzter Abruf: 10.10.2009].
  • Fielding, R.; Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. & Berners-Lee, T. (1999): Hypertext Transfer Protocol -- HTTP/1.1. Request for Comments 2616. [Online] The Internet Society.
    Verfügbar unter: http://tools.ietf.org/html/rfc2616 [Letzter Abruf: 10.10.2009].
  • Souders, S. (2007): High Performance Web Sites. Sebastopol: O’Reilly Media.
  • Theurer, T. (2007): Performance Research, Part 2: Browser Cache Usage - Exposed! [Online]
    Verfügbar unter: http://www.yuiblog.com/blog/2007/01/04/performance-research-part-2/ [Letzter Abruf: 10.10.2009].

Danksagung

Teile dieses Textes wurden durch INSTICC Press veröffentlicht:

  • Dick, Markus; Naumann, Stefan; Held, Alexandra: Green Web Engineering. A Set of Principles to Support the Development and Operation of "Green" Websites and their Utilization during a Website’s Life Cycle. Filipe, Joaquim; Cordeiro, José (Hrsg.): WEBIST 2010 : Proceedings of the 6th International Conference on Web Information Systems and Technologies, April 7 - 10, 2010, Valencia, Spain, Volume 1. Setúbal: INSTICC Press, 2010, S. 48 - 55.