Prefetch im Firefox: Mythos und Wahrheit

Montag, 21 Juli 2008 18:24 MET

Thema:
Kommunikation, Ausgewählte Artikel  
Stichworte:
, , ,  
dieser Artikel  
Button with text: Wink, I'll do the rest
Prefetch im Firefox: Mythos und Wahrheit [hyperkontext | Weblog]
Kommentare 1, Bezugnahme 8

Halbwahrheiten und Mythen um die Funktion Prefetch im Firefox-Browser werden langsam inflationär. Ich gehe der Sache hier etwas tiefgreifender auf den Grund. Ich stieß im Test auf Ungereimtheiten mit der offiziellen Dokumentation.

Und ja: Ich bin auch für das Abschalten dieser Funktion. Konsequenterweise aber bitteschön im Gleichklang mit abgeschaltetem Javascript.

Aufruhr in Bloggersdorf

In den letzten Wochen häuften sich Blogeinträge zur Funktion Prefetch im Firefox. Die einen sorgen sich um ihren Leumund, die anderen noch zusätzlich um die Bandbreite.

Hier mal die Artikel, auf die sich die meisten Kommentare und Bezugnahmen beriefen:

Gleich vorweg:
Ich bin auch für das Abschalten dieser Funktion. Konsequenterweise aber bitteschön im Gleichklang mit abgeschaltetem Javascript.

Erklärende und sachlich relativierende Kommentare werden in so panikmachender Atmosphäre dann kaum mit dem nötigen Ernst wahr genommen. Dokumentationen schlicht nicht gelesen. Und so verdienen diese Kommentare und Beiträge eine extra Auflistung:

Sachliche Hinweise und Erklärungen aus jüngster Zeit:

Ehrlich gesagt, war mir diese Prefetch Funktion bis zum Beitrag von Peter Kröner nicht bekannt und erregte meine Aufmerksamkeit nicht weiter. Nach dem erhellenden Kommentar zum nämlichen Beitrag einige Zeit später, las ich mir die Dokumentation zu dieser Funktion durch und war auch nicht weiter beunruhigt.

Nach der jüngsten Blog-Welle – nennen wir sie mal Anti-Prefetching-Kampagne – werden Halbwahrheiten und Mythen um diese Funktion aber langsam inflationär. Und so setzte ich meine (Recherche-)Brille auf und versuche hier der Sache etwas tiefgreifender auf den Grund zu gehen.

Mythos und Wahrheit

Mythos 1:
Firefox 3 hat eine neue Funktion Prefetch und ladet alle Verweise einer Seite im Voraus.

Die Wahrheit zu Mythos 1:

  1. Es handelt sich in keinem Fall um anklickbare Verweise in a Elementen, die im Voraus geladen werden! Auch das aktive Hinzufügen des Attributs rel="prefetch" lässt den Feuerfuchs kalt.

  2. Ausschließlich die Elemente link im Kopfbereich einer Webseite, die mit dem Attribut rel="prefetch" oder rel="next" markiert sind, versucht Firefox bei Leerlauf im Hintergrund bereits im Voraus zu besuchen. Hierbei gelten auch – theoretisch laut Dokumentation – noch folgende Einschränkungen:

    • URLs (Uniform Resource Locators) mit Query-Strings werden nicht geladen.
    • Alles was mit https beginnt, wird auch nicht geladen.

    Allerdings scheint die Dokumentation mit der Wirklichkeit nicht ganz übereinzustimmen:

    Note you can prefetch any http url up to 64KB, even ones with arguments (tested with firefox 2.0.0.1) even though the Mozilla documentation says it will not prefetch urls with arguments. Affiliate Cookie Setting with X-moz Prefetch

    Nach eigenhändigem Test (mit Firefox 3.0.1) kann ich feststellen:

    • URLs mit Argumenten werden sehr wohl geladen. Die Dokumentation bei diesem Punkt – URLs with a query string are not prefetched – scheint nicht (mehr) richtig zu sein.
    • Es wird nur das angegebene Objekt (Seite oder Bild) geladen; keine weiteren Scripts, Verweise oder Bilder einer im Voraus geladenen Seite.
    • Die Anzahl der im Voraus zu ladenden Seiten scheint ziemlich hoch oder unbegrenzt.
      Bei einer Test-Konfiguration von 25 verschiedenen <link rel="prefetch" href="[url]"> im Kopf einer Seite, wurden meist alle Seiten im Voraus geladen; manchmal blieben einige mit 404-Error zurück und in einigen Fällen wurden nur die ersten paar Seiten geladen und alle weiteren Zugriffe mit Error 404 abgebrochen.
    • URLs die mit https beginnen werden tatsächlich nicht geladen.

  3. Die Funktion besteht schon seit Firefox-Version 1.02 (bzw. Mozilla 1.2) und war immer schon per Default eingestellt. Die Dokumentation der Entwickler besteht in der ursprünglichen Fassung offenbar schon seit dem Jahr 2002.

    • Mozilla prefetching [simonwillison.net] – Artikel vom 17. Oktober 2002
    • Alexa Cheat [bluehatseo.com] – Im Jahr 2006 ging das Gerücht um, dass das auch der IE unterstützt und das Alexa-Ranking beeinflusst werden kann. Hier wurden auch die Elemente link und a wild durcheinander gemischt. Diese Gerüchte halten sich anscheinend bis heute.
<link> und <a> verstehen

Um den Unterschied zwischen anklickbaren Elementen im body-Bereich und nicht-anklickbaren im Kopf einer Seite zu verstehen, bedarf es grundsätzlicher Kenntnisse in HTML (HyperText Markup Language). Ein paar Verweise hierzu:

Firefox-Extension Fasterfox

Eingangs erwähnter Mythos – ladet alle Verweise einer Seite im Voraus – wird oft mit dem Add-On Fasterfox vermischt. Fasterfox empfinde ich auch als durchaus problematische Erweiterung für den Feuerfuchs. In den richtigen Händen kann sie aber sehr nützlich für Anwenderinnen sein.

Leider kann Fasterfox aber auch quasi als Amokläufer eingestellt werden, der jeden Verweis versucht herunterzuladen – also auch die anklickbaren –, ohne dass diese jemals benutzt worden wären.

Diese Problematik haben auch die Entwickler der Erweiterung erkannt und empfehlen das Folgende in die bekannte robots.txt Datei einzufügen, um einen Amoklauf des Programms von Betreiberseite zu unterbinden:

User-agent: Fasterfox 
Disallow: /

Fasterfox prüft die robots.txt Datei beim ersten Zugriff auf die Domain. Bei obigem Eintrag werden keine Seiten von dieser Erweiterung im Voraus geladen.

Anmerkung:
Ich habe Fasterfox nie verwendet. Die Funktionsweise bezog ich aus den folgenden Beschreibungen und Blogeinträgen. Sollte ich hier etwas falsch dargestellt haben, bitte mich zu berichtigen.

Meine Quellen zu Fasterfox:

Mythos 2:
Firefox lädt mit Prefetch immer das erste Suchergebnis von Google im Voraus.

Diese Behauptung ist eine Halbwahrheit. Es stimmt, dass in eindeutigen Konstellationen von Google vor dem ersten Ergebnis <link rel="prefetch" href="[url]"> eingefügt wird. Der Feuerfuchs mit eingeschaltetem Prefetching ladet somit diese Seite bereits im Voraus, ohne dass wir sie tatsächlich besucht hätten.

Die Wahrheit zu Mythos 2:

  1. Google markiert nur dann das erste Suchergebnis mit <link rel="prefetch" href="[url]">, wenn es sich um einen eindeutigen Fall handelt. Das kommt zum Tragen, wenn das gesuchte Wort mit einer bekannten und zuverlässigen Domain übereinstimmt.

    Wenn wir also nach webkrauts suchen, dann trifft das zu, weil die Webkrauts eine bekannte und zuverlässige Domain ist und wir genau dieses Wort gesucht haben, das mit dem Domain-Namen übereinstimmt.

    Wären die Webkrauts nicht so bekannt oder hätten wir nach der Einzahl Webkraut gesucht, würde eine Seite der Webkrauts in diesem Fall wahrscheinlich auch an erster Stelle des Suchergebnisses erscheinen, aber Tante Guugl würde kein <link rel="prefetch"> setzen.

  2. Die in Punkt 1 erwähnte Vorgangsweise betreibt Google seit dem Jahr 2005.

  3. Anmerkung nebenbei:
    Die Suchmaschine von Google verwendet das link-Element – in gewohnt schlechter Tradition – jenseits jeglicher Richtlinien im body-Bereich des Dokuments, direkt vor dem ersten Suchergebnis. Nach gängigen Standards von HTML4.01 oder XHTML1.0 wäre das nur im head-Bereich einer Seite zulässig.

    Durch die nicht vorhandene Dokumententyp-Deklaration auf Google-Seiten, verhalten sich Browser im sogenannten Quirks-Mode, stellen sich auf steinzeitlichstes HTML ein und bemühen sich auch den größten Unsinn zu interpretieren.

    Es muss einmal erwähnt werden, dass Google-Suchseiten ein unfassbares steinzeitliches Code-Gemetzel sind.

Die Konsequenz: Prefetch und Javascript ausschalten

Auf manchen Seiten findet sich auch in normalen anklickbaren Verweisen ein Attribut rel="prefetch". Damit glauben wohl einige halblustige Optimierer, dass der Feuerfuchs nun sofort solcherart markierte Links im Voraus ladet und die Page-Impressions in die Höhe treibt. (Ich verbinde zu den paar gefundenen Seiten nicht, weil ich niemanden in diesem Kontext bloßstellen will.)

Der Firefox sollte standardmäßig ohne eingeschalteter Prefetch-Funktion ausgeliefert werden.

Die unlautere Absicht solcher Optimierer würde aber sehr wohl funkionieren, wenn sie diese anklickbaren Verweise auch mit <link rel="prefetch" href="[url]"> in den Kopfbereich (head) stellen würden.

Sollte das Schule machen, dann wird sich das auch schnell bei diversen klickerhaschenden großen Medien-Sites und CMS-Entwicklern herumsprechen. Dann werden wohl auch die Firefox-Entwickler reagieren und die Funktion ausgeschaltet ausliefern.

Mitunter finden sich Tipps, wie prefetch auch noch ausgenutzt werden kann: Affiliate Cookie Setting with X-moz Prefetch [seo.has.no.com].

Wir sollten also in weiser Voraussicht – aber ohne in Paranoia zu verfallen – die Funktion Prefetch im Firefox manuell abschalten. Das geht so:

  1. about:config in die Adresszeile eintippen.
  2. In den alphabetisch geordneten Einträgen nach network.prefetch-next suchen.
  3. Wenn die Funktion nicht fett erscheint, dann darauf doppelt klicken. Nun sollte der Eintrag fett sein und als Wert das Wort false erscheinen.

Weiters gibt es noch eine schöne Anleitung, wie wir Prefetching als Site-Betreiber in der Datei .htaccess unterbinden können: .htaccess & Firefox Prefetch [vbseo.com].

Javascript, iframes und Bandbreite

Mit Javascript und DOM Hacks, aber auch mit iframes, kann und wird viel im Hintergrund geladen und Zugriffe von und auf andere Server realisiert. Wir könnten auch sagen, dass diese Praktiken heute normal sind und Bestandteil vieler Web2.0-Applikationen.

Im Angesicht der fast schon paranoid anmutenden Anti-Prefetching-Kampagne ist die Konsequenz für alle die diese Funktion in ihrem Firefox-Browser ausschalten, dass diese Leute auch mit der Erweiterung NoScript unterwegs sein müssten oder Javascript prinzipiell abgeschaltet haben sollten.

Wenn wir Javascript ausschalten, dann sinkt die Ladezeit auf vielen – und vor allem Medien-Sites – in den Drei-Sekunden-Bereich!

Ladezeit und Bandbreite

Einige in einigen Kommmentaren meinten, dass ohne Prefetching die Ladezeit der Seiten sinken würde. … hm …

Heute werden auf (Medien-)Sites via Javascript Megabytes von zusätzlichem digitalem Material geladen, das überhaupt nichts mit dem eigentlichen Inhalt zu tun hat.

Und mal abgesehen von der Ladezeit und Bandbreite: Denken wir einmal darüber nach, was uns da so alles untergeschoben werden kann.

Konsequent sein

Auch wenn AJAX hip und bequem ist und Javascript (mittlerweile wieder) the way of Web-Life (und somit Teil des Web2.0), sollte es heute nicht automatisch eingeschaltet sein. Es wird für unendlich viele Zugriffe von und auf fremde Server verwendet.

Wer Javascript immer eingeschaltet hat, den kann die aktivierte Prefetch-Funktion im Browser auch nicht stören. Denn Prefetch im Firefox ist im Vergleich zu vorher genannten gängigen Methoden – ob in guter oder böser Absicht – ein Nebenschauplatz.

Falls jemand hierzu mehr weiß und der Prefetch-Funktion größere Sicherheitsbedenken als diversen Scripts einräumt, dann bitte vortreten.

Abschnitt 1 von 1

Die Schlüssel-Verweise dieses Artikels nochmals auf einen Blick:

Weitere Verweise:

Externe Verweise dieses Artikels wurden zuletzt am 9. Februar 2009 auf Relevanz geprüft.

Datum:
veröffentlicht am 21 Juli 2008, 18:24 MET.
Artikel:
Prefetch im Firefox: Mythos und Wahrheit [hyperkontext | Weblog]
(twittern)
Kurz-URL:
http://hyperkontext.at/s/149
Thema:
Kommunikation, Ausgewählte Artikel 
Stichworte:
, , ,  
Reaktionen:
Kommentare 1, Bezugnahme 8

Kommentare (1) und externe Bezugnahmen (8) ansehen

Dieser Eintrag kann nicht mehr kommentiert werden.

Mögliche themenverwandte Artikel aus dem Weblog

Blättern (chronologisch)

« neuerer Artikel
IETester: Verschiedene IE-Versionen in einem XP- oder Vista-Fenster
älterer Artikel »
Rezension: Social Web

Weitere Links

Neue Beiträge

Zuletzt kommentiert

Empfohlen

Einstellungen