Prefetching: was soll das denn sein?
Das ist zunächst mal ein ganz netter Mechanismus, mit dem es möglich wird, den Browser „vorausschauend“ mit dem Laden von Dateien zu beauftragen, die er demnächst brauchen könnte.
Bei einer Website, auf der die Pfade der Besucher leicht voraussehbar sind (z.B. wenn nur die Wahl zwischen „vorige Seite“ und „nächste Seite“ besteht), ließe sich sagen: gut, dann kann der Browser auch schon mal anfangen die nächste Seite zu saugen, wenn er schon sonst nichts zu tun hat. Realisiert wird das über das rel-Attribut in <link>-Tag, Metatag oder HTTP-Header. Beispiel:
[html]
[/html]
Nützliches Feature oder Traffic-Monster?
Das ist ja schön und gut, sofern ich selbst meinen Besuchern das Prefetching meiner Seiten nahelege. Benutzt wird Prefetching aber z.B. auch vom Suchriesen Google, der gerne mal die vordersten Suchergebnisse von den Browsern seiner Besucher saugen lässt (Herrjeh! Es könnte ja sein, dass da jemand draufklickt!).
Websites in den vorderen Rängen der Suchergebnisse kann auf diese Art durchaus eine Menge „ins blaue“ verusachter Datenverkehr blühen, der nicht mehr im gesunden Verhältnis zu den Besucherzahlen steht. Und wenn das großen Portalen noch egal sein mag – Otto Normalwebmaster rauft sich vielleicht die Haare.
Auch Proxies oder Tools wie der Google Web Accelerator arbeiten zur „gefühlten“ Beschleunigung des Surfens mit Prefetching
Zeig mir deinen HTTP-Header
Gegenwärtig wird Prefetching von iCab (*staun*), dem Mozilla Firefox und seinen Brüdern sowie dem Google Web Accelerator unterstützt. Führen diese Prefetching-Anfragen aus, wird der folgende Header mitgesendet:
[code]X-moz: prefetch[/code]
Möchte ich nicht, dass mein Server seine (Rechen-)Zeit mit solchen Anfragen vergeudet, kann ich die Anfrage abfangen und verwerfen, indem ich meine .htaccess-Datei ein wenig tune:
[code]RewriteEngine On
SetEnvIfNoCase X-moz prefetch IST_PREFETCH=1
RewriteCond %{ENV:IST_PREFETCH} 1
RewriteRule .* 503.php [L][/code]
Man beachte: statt dem Client einfach ein „Forbidden“ vorzusetzen, ist der HTTP-Status „503 Service Temporarily Unavailable“ angebracht – kommt der Zugriff von einem Suchmaschinen-Robot, wirft der uns am Ende sonst noch die Seite aus dem Index! Deswegen verpassen wir ihm eine „höfliche“ Abfuhr in gestalt des Robot-sicheren 503-Status‘ und geben ihm mit auf den Heimweg, dass er die Seite demnächst hier wieder abholen darf 🙂
Allein mit mod_rewrite ist das leider nicht möglich, deswegen behelfen wir uns einfach mit einem kurzen PHP-Script. Der Inhalt von 503.php kann z.B. so aussehen:
[html] header(‚HTTP/1.1 503 Service Temporarily Unavailable‘);[/html]
Und das war’s schon! Anhand der im Logfile notierten 503-Codes kann man sich in absehbarer Zeit anschauen, wieviele Zugriffe gespart wurden, jedenfalls sofern der Server keine anderen schwerwiegenden Probleme hat 🙂
Serverlast dynamisch reduzieren
Dieser kleine Trick ist nicht nur für Geizkragen geeignet: habe ich tatsächlich einen Webserver der zwischendrin wirklich mit starken Auslastungen zu kämpfen hat, kann ich die Prefetching-Sperre auch als dynamisch an- und ausschaltbares Feature implementieren.
Siehe auch: