Surf-Triathlon

Inhaltsverzeichnis

Als Testkandidaten treten die aktuellen Windows-Versionen der vier großen Browser an: Internet Explorer 7, Firefox 3, Opera 9.52 und Safari 3.1. Da Firefox 3 angeblich in Sachen Speicherverbrauch und Geschwindigkeit erheblich verbessert sein soll, hält der oft als speicherhungrig verschriene und noch häufig eingesetzte Firefox 2 als Vergleichsmaßstab her.

Von zwei Browsern gibt es Vorabveröffentlichungen der nächsten Version: Internet Explorer 8 und Safari 4. Leistungsmessungen mit unfertiger Software stehen natürlich unter Vorbehalt – vor allem bei Safari 4, der als frühe „Developer Preview“ vorliegt. Vom IE 8 erschien gerade noch rechtzeitig die zweite Beta (siehe Seite 64), die Feature-komplett sein soll. Größere Neuheiten haben unter der Haube beide Vorabversionen zu bieten: Safari 4 eine neue JavaScript-Maschine, IE 8 eine komplett umgebaute Rendering-Engine.

Alle sieben Browser laufen auf einem sonst jungfräulichen Windows Vista Business Service-Pack 1, damit die Browser sich nicht wechselseitig ausbremsen können (das könnte allenfalls der vorinstallierte Internet Explorer). Jegliche Plug-ins und Erweiterungen fehlen. Um deren Effekt besser einschätzen zu können, gesellt sich als achter Proband ein gut ausstaffierter Firefox 3 dazu, der mit Adobe Flash, einer Java-Laufzeitumgebung und einem Dutzend von Mozilla empfohlenen Erweiterungen bestückt wurde (Sage too, FireGestures, AdBlock Plus, StumbleUpon, Greasemonkey, IE Tab, PicLens, DownThemAll!, Foxmarks, All-in-One Sidebar, ScribeFire und Better Gmail 2).

Der Testrechner dürfte dem ähneln, was viele Anwender unter dem Schreibtisch stehen haben: In der Maschine stecken ein mit 2,4 GHz getakteter Athlon 64 X2 Dual Core 4600+, 2 GByte RAM und eine Radeon X1600 als Grafikkarte, also ein ganz gewöhnliches Büro-Arbeitstier. Das Vista-System läuft mit den Standardeinstellungen; alle visuellen Effekte sind angeschaltet, das Asus-M2NE-Board und die 250-GByte-Festplatte (eine Seagate Barracuda) tauschen Daten per SATA aus.

Die Browser wurden frisch installiert, liefen im Vollbildmodus und ohne eine andere geöffnete Anwendung; an der Vorkonfiguration wurde nur die Startseite geändert, die bei den Testinstallationen auf eine leere Seite verweist. Jedem neuen Test ging eine Cache- und History-Leerung sowie ein Browser-Neustart voran.
Die Performance eines Browsers erweist sich vor allem an der Zeit, die er für das Laden und Darstellen von Webseiten braucht. Die Programme mussten sich an einer Reihe von realen Seiten beweisen, und zwar unter verschiedenen Bandbreiten.

Die Leistung der Skript-Engine, die für komplexe Webseiten von zentraler Bedeutung ist, lässt sich mit Hilfe von JavaScript-Testsuiten unter Laborbedingungen messen. Ergänzende Tests prüften die Geschwindigkeit beim Vor- und Zurückblättern, die Zeit für das teilweise Laden einer Seite und den Verbrauch an Speicher- und CPU-Ressourcen. Und schließlich sollten die Browser auch noch in möglichst kurzer Zeit starten.

Kavalierstart

Wie lange die Anwendungen für den Start benötigten, haben wir notgedrungen handgestoppt. Gemessen wurde die Zeit vom Icon-Klick bis zum Aufbau des Browserfensters mit leerer Startseite. Hier wie bei den anderen Tests haben wir dreimal gemessen und einen Mittelwert gebildet.

Kaum ein Browser benötigte länger als eine Sekunde für den Start; bemerkenswerterweise schienen die Vorabversionen von IE 8 und Safari 4 am schnellsten zu sein, auch wenn bei handgestoppten Zeiten unter einer Sekunde keine verbindlichen Aussagen möglich sind. Dabei konnte Internet Explorer 7 keinen Vorteil aus seiner privilegierten Stellung als Bestandteil des Betriebssystems ziehen.

Am längsten ließen die drei Firefox-Versionen auf sich warten, immerhin reagierte Firefox 3 einen Tick flinker als sein Vorgänger. Die Installation von Plug-ins wirkte sich wie erwartet auf die Startzeit aus, wobei der Effekt – eine Steigerung von 1,2 auf 2,2 Sekunden – noch moderat ausfällt.

In der Praxis liegen die Startzeiten meist deutlich höher als bei dem eher schnellen, unausgelasteten Testsystem. Auf einem zum Vergleich herangezogenen 2-GHz-Arbeitsrechner ergaben sich bei Firefox mit Erweiterungen Wartezeiten um die acht Sekunden, während Internet Explorer und Safari nur etwa halb so lange benötigten. Bei Opera kann der Einsatz des integrierten Mail-Clients die Startzeit erheblich verlängern.
Mit dem Test ließ sich nicht erfassen, ob die Anwendungen im Hintergrund noch Komponenten nachluden, während sie dem Benutzer bereits Einsatzbereitschaft signalisierten. Schwankungen der Ergebnisse gehen nicht nur auf Messfehler zurück, sondern möglicherweise auch auf die Vista-Funktion SuperFetch. Diese hält häufig benötigte Daten im Arbeitsspeicher vor, was auf Kosten von Rechnerressourcen den Start von Programmen beschleunigt.

JavaScript-Parcours

Kaum eine größere Website kommt ohne JavaScript aus; das Kompilieren und Ausführen des Skriptcodes ist ein entscheidender Faktor bei der Geschwindigkeit des Seitenaufbaus. Für JavaScript-Berechnungen und Manipulationen des Dokuments gibt es eine ganze Reihe von Testsuiten, die in der Summe ein zuverlässiges Bild liefern sollten.

SunSpider 0.9, die vielleicht umfassendste davon, stammt von den WebKit-Entwicklern. Es handelt sich dabei um 26 Einzeltests. Nach Angaben der Autoren orientieren sich die Tests an den Anforderungen der wirklichen Welt.

SunSpider beschränkt sich auf den JavaScript-Kern ohne Eingriffe ins Dokument-Objekt-Modell (DOM) und berechnet unter anderem 3D-Figuren, Bit-Operationen, Verschlüsselungen, Kalender, String- und Regex-Manipulationen. Die Testsuite genießt hohes Ansehen, doch eine kleine Warnung darf nicht fehlen: SunSpider kommt aus dem gleichen Stall wie Safari, der vermutlich mit Hilfe der Testsuite optimiert wurde. SunSpider läuft automatisch fünfmal durch und gibt nur die Durchschnittsergebnisse aus.

Schon diese Testsuite beweist, dass sich die JavaScript-Leistungen auf recht unterschiedlichem Niveau bewegen: Der langsamste und der schnellste Kandidat lagen bei SunSpider um den Faktor neun auseinander. Schlusslicht ist IE 7, der den größten Teil seiner 38 Sekunden über den String-Methoden brütete. Der designierte Nachfolger beseitigt diese Schwäche und legt auch in allen anderen Disziplinen deutlich zu – allerdings braucht er immer noch beinahe doppelt so lange wie ein aktueller Firefox.
Mit seinen knapp fünfeinhalb Sekunden liegt der Fuchs sogar noch knapp vor Safari 3. Der Vergleich mit dem viermal so langsamen Firefox 2 zeigt, wie erfolgreich die Entwickler an der Performance-Optimierung arbeiten. Opera kann nicht ganz mit Firefox und Safari mithalten, fällt aber nicht weit ab. An die Spitze setzt sich auf Anhieb Safari 4 – die neue Script-Engine „SquirrelFish“ scheint tatsächlich die Wunderdinge zu leisten, die man ihr nachsagt.

Weitere Tests der JavaScript-Interna bestätigen dieses Bild – wenn auch mit Modifikationen. Bei der kleinen Testsuite von celtickane.com etwa, die vor allem die verschiedenen Objekte von Array bis Math untersucht, schiebt sich Opera zwischen Safari und Firefox 3; die beiden Internet Explorer liegen nur um den Faktor zwei bis drei hinter dem Hauptfeld und überholen immerhin noch Firefox 2. In der angeblich berichtigten Fassung dieses Tests von nontroppo.org dagegen fallen die IEs wieder weit zurück. Hier holt Opera beinahe Safari 4 ein.

Die Geschwindigkeit bei der Verarbeitung von Schleifen und Kollektionen von DOM-Knoten misst der Loop-Benchmark des Sun-Mitarbeiters Gregory Reimer. Die Tests versuchen offenbar eher, den effektivsten JavaScript-Programmierstil als den schnellsten Browser zu ermitteln, aber dem Wert der Ergebnisse tut das keinen Abbruch.

Bei den Tests mit normalen Arrays liefern sich Firefox 3 und die beiden Safari-Versionen ein Kopf-an-Kopf-Rennen. Seine Stärken spielt der Mozilla-Browser beim zerstreuten Array aus, das überwiegend aus leeren Einträgen besteht. Die Schleife über eine HTML-Kollektion sieht hingegen Safari klar vorne und Opera auf Augenhöhe mit Firefox. Insgesamt zeigt sich Firefox 2 weniger als halb so schnell wie sein Nachfolger, während Internet Explorer 7 der Spitze etwa um den Faktor zehn hinterherhinkt und mehrmals nachfragt, ob er die Testskripte wirklich ausführen soll.

Der Mesh-Transform-Test der WebKit-Entwickler ermittelt Firefox 2 als Nachzügler, während Firefox 3 noch knapp vor Safari 4 liegt.

Schnellzeichner

Beim Animieren eines 3D-Würfels (ein Test von Simon Speich) muss die Skript-Engine nicht nur viel rechnen, sondern die Ergebnisse auch ins Browserfenster zeichnen. Hier schließt Internet Explorer zu Firefox auf, die aber beide Safari und Opera nur noch von hinten sehen.

Ein Raytracer, ursprünglich auf safalra.com veröffentlicht, quält die Browser mit massivenDOM-Manipulationen – in der hohen Auflösung gilt es, in 120 Durchläufen 59 000 DIV-Container zu rendern. Hier hält der Marktführer nicht ganz mit Safari und Opera mit, überrundet aber den in dieser Disziplin desolaten Firefox. Sein exzellentes Ergebnis erarbeitete sich Safari 4 nicht ganz ordnungsgemäß, indem er scheinbar einfror und erst am Ende die fertig gerenderte Grafik anzeigte.

Beim erneuten Anstoßen des Raytracing-Tests bleibt diese DOM-Wüste im Speicher des Browsers, wenn die Testseite nicht neu geladen wurde. Um zusätzlich zu den regulären Test-Wiederholungen die Tortur auf die Spitze zu treiben, sollten die Browser in zwei Durchläufen diese extreme Belastung meistern. Hier kämpfte sich IE 7 sogar zu Opera und Safari nach vorne.

Mit den DOM-Tests von Ian Hickson, einem ehemaligen Mitarbeiter von Netscape und Opera, können die Microsoft-Browser mangels Standard-Kenntnissen dagegen wenig anfangen; bei den Manipulationen des Dokumentenbaums und dem Abspielen eines kleinen Filmchens aus Rasterpunkten mit vier verschiedenen Verfahren setzt sich Opera ab, auch wenn Safari bei den Core-DOM-Methoden schneller ist.

Peter-Paul Koch von quirksmode.org schließlich vergleicht fünf Methoden (drei nach W3C-DOM, zwei nach Microsofts innerHTML-Syntax), Text in ein Dokument zu schreiben. Hier tauschen Safari und Opera wieder die Plätze, während IE 7 sein indiskutables Ergebnis der Trägheit bei den W3C-DOM-Methoden verdankt. Allerdings liegen die flinkeren Browser auch bei den innerHTML-Methoden deutlich vorne. IE 8 kommt glücklicherweise erheblich besser mit W3C-DOM zurecht.

Vorderlader

Während die JavaScript-Benchmarks präzise Ergebnisse liefern, begibt man sich bei der Messung der Lade- und Rendergeschwindigkeit auf dünnes Eis. Das übliche Verfahren ist es, ein onload-Ereignis in JavaScript zu setzen, das nach dem Laden der Seite ausgelöst wird – also etwa so:

<script type="text/javascript">
var anfang = new Date();
function laden() {
var ende = new Date();
alert(ende - anfang . ' Sekunden');
}
</script>
<body onload="laden()">

Dummerweise ist nicht ganz klar, wann eine Seite geladen ist. Man könnte glauben, dass onload wartet, bis die Seite und alle eingebundenen Dateien komplett empfangen und gerendert sind, aber es gibt da kleine Unterschiede, die sich zu einigen Zehntelsekunden summieren können. Insbesondere Safari steht im Verdacht, onload kreativ auszulegen. Während der Betaphase von Safari 3 führte der Browser teilweise onload-Aktionen aus, bevor eingebundene Bilder geladen waren – was allerdings als kritischer Bug galt und behoben sein soll.

Chefentwickler Dave Hyatt erklärt in einem Kommentar auf Ajaxian.com die Details: „Ja, onload wird in Safari früher ausgelöst als in anderen Browsern“ – nämlich unmittelbar nachdem alle eingebundenen Datenquellen geladen sind. Ob der Browser zu diesem Zeitpunkt schon Gelegenheit hatte, das heruntergeladene Material zu rendern, spielt dabei keine Rolle.

Um Arbeitsspeicher zu sparen, wartet Safari außerdem mit dem Dekodieren der Bilder, bis diese tatsächlich ins Browserfenster gezeichnet werden müssen. Auf ressourcenschwachen Geräten kann es daher zu kleinen Verzögerungen beim Scrollen kommen.

Übrigens optimieren auch andere Browser, wenn auch in geringerem Maße: Als ehemaliger Mozilla-Entwickler weist Hyatt zugleich darauf hin, dass Firefox onload zwar erst nach dem Rendern auslöst, dass er aber nicht unbedingt wartet, bis das gerenderte Layout fertig ins Browserfenster gezeichnet ist. Ajax-Daten, die beispielsweise die Pageflakes-Startseite beim Laden anfordert, ignorieren dagegen alle Browser beim Auslösen von onload – zu Recht, denn schließlich handelt es sich dabei um eine asynchrone Verbindung.

Kritisch ist nicht nur der Endpunkt der Messung, sondern auch der Beginn: Vor allem Opera und Firefox laden die Seiten progressiv, das heißt, sie beginnen mit der Darstellung, bevor überhaupt das HTML-Gerüst komplett geladen ist, geschweige denn die eingebundenen Skripte und Medien. Safari wartet mit dem Ausführen der Skripte (also mit dem Start der Stoppuhr), bis die komplette Seite eingelesen ist. Eine primitive Testseite mit der oben beschriebenen Messmethode, die aus dem Dateisystem geladen wird, ergibt deshalb bei Safari sensationelle Messergebnisse nahe null Millisekunden, während die anderen Browser realistischerweise um die 10 Millisekunden brauchen.

Messinstrumente

Zumindest dieses letztgenannte Problem lässt sich vergleichsweise leicht umgehen: Die Messseite bindet die Testseite als Iframe ein und startet die Uhr. Das hat zugleich den Vorteil, dass man die Ladezeiten anhand von realen, unmodifizierten Webseiten ermittelt. Nur leider gibt es keine praktikable Möglichkeit, das Ende des Ladevorgangs zu messen, ohne auf onload zu verzichten – bei Ergebnissen im Bereich weniger Sekunden ist eine manuelle Stoppuhr einfach zu ungenau, Verfahren mit Bildschirmerkennung erfordern zu viel Aufwand. Dieses Iframe-Verfahren wendet der Dienst WebWait.com an, der als Grundlage für die eigene Testumgebung diente.

Um die Safari-Probleme zu umgehen und zu verlässlicheren Ergebnissen zu kommen, versuchten wir zu prüfen, ob der Browser die Bilder alle geladen und gerendert hat; außerdem sollte das Layout fertig berechnet sein. Beides lässt sich im Prinzip mit JavaScript abfragen.

Nachdem die Seite im Iframe ihr „fertig!“ signalisiert, prüft die Funktion im Listing oben den Wahrheitsgehalt dieser Aussage. So ermittelt Zeile zwei eine Layout-Eigenschaft des Bodys und zwingt damit den Browser dazu, die Seite vor der Ausführung zu rendern (wenn auch nicht unbedingt ins Fenster zu zeichnen).
Der Rest der Funktion schaut nach, ob bei allen Bildern des eingebundenen Frames die Eigenschaft complete vorliegt – andernfalls soll der Browser in einer Zehntelsekunde noch einmal nachsehen.

Beide Tests benötigen jedoch Zugriff auf den Dokumentenbaum des Iframes – das aber unterbindet das Sicherheitsmodell aller gängigen Browser, wenn die Seite nicht vom gleichen Server stammt. Nach einigen Tests mit lokal gespeicherten Webseiten verzichteten wir auf image.complete und erzwungenes Rendern, weil ein nachweisbarer Effekt ausblieb.

Das Gleiche gilt für die Experimente, die Messzeiten nicht dem Browser-eigenen Date-Objekt zu entnehmen, sondern einem simplen PHP-Skript, das per synchroner Datenverbindung über XMLHttpRequest von einem lokalen Webserver aus die Uhrzeit zuliefert. Die meisten Ergebnisse fielen für beide Messverfahren exakt gleich aus, allerdings lag die Ajax-Messung vor allem bei Firefox öfter mal deutlich daneben. Von dem in beschriebenem Safari-Fehler beim Umgang mit Date in Iframes war bei den Tests nichts zu bemerken.

Bytedrossel

Bevor ein Browser zum Rendern kommt, muss er jedoch erst einmal die dafür nötigen Bytes aus dem Web saugen. Das sollten die Browser an einer Auswahl von 20 Webseiten unter Beweis stellen, von denen 17 auf den vorderen Plätzen der IVW-Liste liegen – die populärsten Webseiten sind oft auch ausgesprochen aufwendig zu laden, außerdem erwarteten wir von den großen Anbietern einen stabilen Server-Ausstoß.

Caching lässt sich bei den automatischen Tests nicht abschalten, sodass sich die erste Messung nicht mit den übrigen vergleichen lässt. Daher liefen die Ladetests viermal, jeweils im Abstand von fünf Sekunden und das erste Mal außer Konkurrenz. Damit der Browser nicht einfach alles aus dem Cache zaubert, wurde die URL mit einem Zufallsstring ergänzt; das zwingt die Software dazu, zumindest die zugrundeliegende Seite neu zu laden und neu zu rendern.

Auf einer firmeneigenen 100-MBit-Leitung, die Internetzugang ohne Proxy ermöglichte, konnten die Browser ihre Fähigkeiten unter Idealbedingungen unter Beweis stellen. Praxisrelevant sind aber nicht nur die leere Autobahn, sondern auch die enge Landstraße und das Gedränge in der Innenstadt. Deshalb drosselten wir in drei weiteren Ladetest-Durchläufen künstlich die Leitung – und zwar mit Hilfe des in vorgestellten Shapers. Dieses Gateway gaukelte den Programmen Standard-DSL (2 MBit/s, Upstream: 192 KBit/s), DSL Light (384 KBit/s, 64 KBit/s im Upstream) und ISDN (64 KBit/s in beide Richtungen) vor. Vergleichswerte lieferten Messungen, die unter ansonsten gleichen Bedingungen über einen Proxy liefen.

Trotz aller Vorkehrungen bleibt ein Rest Zufall bei den Messwerten. Offensichtliche Ausreißer, bei denen sich der Browser verschluckt oder die Daten sich verlaufen haben, gingen nicht in die Statistik ein – an ihrer Stelle haben wir neu gemessen oder plausible Werte eingesetzt und gesondert gekennzeichnet. Typischerweise handelte es sich dabei um die Einblendungen externer Werbeserver, vor allem bei niedriger Bandbreite.

Mitgestoppt

Bei vollem Leitungsdurchsatz konkurrierte Safari 3 vor allem mit seinem Nachfolger. Bei der Proxy-Messung folgen Firefox 3 und Opera dicht dahinter, während IE 7 mit etwas Abstand dahinter bleibt. Ohne Proxy dagegen überholte der IE Firefox und den vergleichsweise langsamen Opera, der aus seinen HTTP-1.1-Tricks (siehe Kasten) keinen Vorteil zieht. Die Safaris konnten den Abstand zum Feld vergrößern.

Bei DSL- und DSL-Light-Verbindung findet sich IE 7 zusammen mit seinem noch etwas behäbigen Nachfolger am Tabellenende wieder. Die in der Praxis relevanteste Disziplin – 2 MBit/s ohne Proxy – entscheiden wieder die beiden Apple-Probanden für sich, Opera und die Firefox-Varianten stellen das Mittelfeld.

Bei den schmalbandigen Anschlüssen ist Opera klar der Sieger: Bei ISDN- und DSL-Light-Verbindung – egal ob mit oder ohne Proxy – legte er die Bestzeit vor. Safari dagegen kommt mit der dünnen Leitung nicht gut klar: Bei ISDN ohne Proxy landete Safari 4 sogar auf dem letzten Platz. Dafür kämpfte sich hier IE 7 auf den zweiten Platz vor. Dramatisch waren die Unterschiede jedoch nicht – der Langsamste brauchte meist etwa anderthalb mal so lange wie der Schnellste.

Subjektiv

In der Praxis mindestens ebenso wichtig wie die vollständige Render-Zeit ist die Dauer, bis der Browser überhaupt Inhalte anzeigt. Das hängt stark von der Intelligenz der Software ab: Lädt ein Browser stupide das gesamte HTML, CSS, JavaScript und Medien ohne Größenangabe herunter, bevor er endlich beginnt, das Fenster vollzuzeichnen – oder versucht er, mit minimalen Informationen eine komplexe Seite zu skizzieren?

Vor allem bei langsamer Internetverbindung wäre das sehr wünschenswert, doch kann es dabei zu verwirrenden nachträglichen Layout-Korrekturen oder zum „Flash of unstyled content“ kommen. Außerdem kostet häufiges Neuzeichnen Rechnerressourcen. Hier ist also Fingerspitzengefühl gefragt. Manche Browser erlauben hier eine Feinabstimmung, indem der Anwender die Wartezeit bis zum ersten Darstellungsversuch oder den Neurender-Rhythmus bestimmen kann.

Ein Testkandidat für diese Disziplin ist zum Beispiel die T-Online-Startseite mit ihrem 90 KByte schweren Tabellenlayout. Gemessen wurde die Zeit, bis die Browser die Texte des ersten Inhaltsblocks („Aktuelles“) im Hauptteil der Seite darstellen, und zwar bei simulierter ISDN-Bandbreite. Theoretisch wäre das nach knapp 30 KByte Quelltextdownload möglich. In der Praxis dauerte es eine knappe Minute, bis sich das Browserfenster zu füllen begann.

Die Messergebnisse bestätigten allerdings nur den Eindruck, dass Safari, Opera und Firefox in Sachen Geschwindigkeit dicht beisammen liegen. Nur die beiden Internet Explorer bleiben ein wenig zurück.

Historisch

Relevant für die Browser-Performance ist auch die Geschwindigkeit, mit der er Seiten aus der History wieder abruft. Um das zu testen, wurden die 20 Ladetest-Seiten nacheinander aufgerufen. Mit Hilfe des Zurück-Knopfs wollten wir möglichst schnell an den Anfang navigieren, dann mit dem Vor-Button in die andere Richtung und schließlich wieder zurück an den Anfang.

Erstaunlicherweise kam nur ein Teil des Testfelds mit dieser einfachen Anforderung zurecht. Internet Explorer 7 und Safari 4 blieben beide beim Vorwärtsdurchgang an MyVideo hängen. Die Zeiten des Rückwärtslaufs (57 beziehungsweise 45 Sekunden) deuteten schon an, dass die History nicht zu den Stärken der Software zählen würde.

Internet Explorer 8 schaffte nicht einmal einen Rückwärtslauf. Safari 3 bestand den Test, zeigte beim Schnelldurchlauf aber Überlagerungen der einzelnen Seiten. Außerdem nervte der Apple-Browser durch penetrante und mitunter irreführende Hinweise auf zu installierende Plug-ins („Safari kann das Internet-Plug-In nicht finden“).

Robust und schnell präsentierten sich die drei Feuerfüchse beim History-Test – die Zeiten, in denen die Zurück-Funktion in Firefox notorisch langsam war, sind seit der Einführung von FastBack in Version 1.5 vorbei.

Opera, eigentlich bekannt für eine flinke History, blieb in Version 9.51 beim Vorwärtsdurchgang hängen. Der gerade noch rechtzeitig erschienene Nachfolger 9.52 wetzte mit der schnellsten Zeit die Scharte wieder aus.

Lageristen

Im Allgemeinen genießen die Browser nicht das Privileg, sich alleine auf einem Rechner mit 2 GByte RAM ausbreiten zu können – Sparsamkeit im Umgang mit dem Arbeitsspeicher ist also gefragt.

Vor allem Internet Explorer 6 hatte den Ruf, mit zahlreichen klaffenden Speicherlecks im Netz unterwegs zu sein; vom Nachfolger sind Probleme in diesem Ausmaß nicht bekannt. Doch auch ohne solche Lecks wächst beim Surfen der Appetit der Browser auf RAM, was vor allem an der Speicherfragmentierung durch gecachete Seiten und Bilder liegt.

Um den Speicherverbrauch zu protokollieren, bietet sich die in Windows Vista eingebaute Zuverlässigkeits- und Leistungsüberwachung (perfmon) an, die unaufdringlich alle erdenklichen Merkmale erfassen kann. Wichtigste Kenngröße waren für den Test die „privaten Bytes“ des Browser-Prozesses. Die perfmon-Anwendung schrieb brav mit, während der Browser die 20 Seiten des Ladetests in jeweils eigenen Tabs rendern musste.

Am meisten RAM gönnte sich Internet Explorer 8 – und zwar verteilt auf mehrere Einzelprozesse. Auch die beiden Safaris waren mit 272 beziehungsweise 265 MByte wenig sparsam. Mit knapp 250 MByte positionierten sich IE 7 und Firefox 3 mit Plug-ins im Mittelfeld. Deutlich bescheidener blieb Opera mit knapp 220 MByte, doch ganz weit vorne liegen Firefox 2 (145 MByte) und Firefox 3 ohne Erweiterungen, der nochmal etwa 8 MByte einspart. Allerdings dürfte Opera mit aktivem Mail-Modul genügsamer sein als beispielsweise die Kombination Firefox/Thunderbird. Der Test erfasst nicht, wie sehr die Browser bei stundenlangem Einsatz den Arbeitsspeicher volllaufen lassen.

Der Schnellste im Land

Die Messergebnisse zeigen viele verwirrende Details, die vor allem im Fall der Ladetests auch von Zufällen abhängen – dennoch lässt sich ein Trend ablesen. Beeindruckt haben die Ergebnisse der beiden Safari-Versionen, vor allem die der Vorabversion von Safari 4. Die Bravour, mit der das Programm die JavaScript-Benchmarks absolvierte, schimmerte zumindest bei den Ladetests mit hoher Bandbreite durch. Das lässt hoffen auf die finale Version von Safari 4. Nur bei langsamer Internetverbindung bekam das Siegerbild Kratzer.

Hier spielte Opera seine Stärken aus. In fünf von acht Ladetests ging der Browser aus Norwegen als Erster durchs Ziel. Die Benchmarks sahen ihn meist knapp hinter Safari und Firefox 3.

Firefox 3 platziert sich solide im vorderen Mittelfeld; außer beim Speicherverbrauch ragt er kaum einmal heraus, liefert aber fast durchweg gute Leistungen. Die Ausstattung mit Erweiterungen schlägt sich nur in geringem Maß auf die Performance nieder. Der Vergleich mit der Vorgängerversion sieht Firefox 3 meist im Vorteil, doch große Unterschiede waren kaum auszumachen. Das dürfte sich mit Firefox 4 ändern, der unter dem Codenamen „Tamarin“ eine komplett neue JavaScript-Engine bekommen wird – nämlich die von Adobe gespendete ActionScript Virtual Machine (AVM) aus dem Flash Player 9, die deutlich schneller als die bisherige Engine SpiderMonkey sein soll.

Die Tests belegen, dass nicht nur mangelnde Unterstützung von Webstandards und geringer Bedienkomfort gegen den IE 7 sprechen, sondern auch seine Geschwindigkeit. Bei den JavaScript-Benchmarks tritt das in aller Deutlichkeit zutage. Die Ladetests gaben ein widersprüchlicheres Bild ab, doch vier vorletzte Plätze in acht Tests zeigen eine klare Tendenz. Langsamer war nur die Beta 2 des Nachfolgers, an dessen Geschwindigkeit Microsoft vermutlich noch feilt.

Ansonsten hatte jeder Testkandidat seine Schwächen – der sonst solide wirkende Firefox etwa war beim Raytracing überfordert, Opera wusste eine gute Internetanbindung nicht recht zu nutzen, Safari hungerte nach Speicher und fiel bei den Tests mit ISDN-Verbindung ab. Und natürlich gibt es andere Argumente wie Standardunterstützung [9], Sicherheit und Bedienkomfort, die für oder gegen einen Browser sprechen.
Die wachsende Konkurrenz tut dem Browsermarkt gut. Opera und Mozilla werden auf die Fortschritte Safaris reagieren müssen. Und vielleicht findet ja auch der Internet Explorer irgendwann wieder Anschluss an die Konkurrenz.

Literatur

[1] Statistik: http://onlinestatbook.com/chapter8/mean.html

[2] Safaris onload-Fehler: https://bugs.webkit.org/show_bug.cgi?id=13241

[3] Dave Hyatt über Safaris onload-Behandlung: http://ajaxian.com/archives/safari-3-onload-firing-and-bad-timing

[4] Safari und Ladetests: www.howtocreate.co.uk/safaribenchmarks.html

[5] J. Endres, Dauerbremse, Langsame Internetverbindungen simulieren mit WANem, c't 13/08, S. 116

[6] Zeitpunkt für das Rendern von Stilen und Skripten: http://webkit.org/blog/66/the-fouc-problem

[7] Speicherleck-Detektor für IE 6: http://sourceforge.net/projects/ieleak

[8] Arbeitsspeicher-Fragmentierung: http://blog.pavlov.net/2007/11/10/memory-fragmentation

[9] Herbert Braun, Erstinspektion, Mehr als HTML: Die Engines der neuen Browser, c't 9/08, S. 140

[10] HTTP 1.1, Abschnitt 8.1.4: http://tools.ietf.org/html/rfc2616

[11] Axel Vahldiek, Verrammelt, Internet Explorer sicher konfigurieren, c't 13/04, S. 196

Soft-Link

---

JavaScript-Funktion: Webseite tatsächlich fertig geladen und gerendert?

1 function rendertest() {
2 var egal = frames[0].document.body.offsetHeight;
3 var ok = true;
4 var bilder = frames[0].document.getElementsByTagName('IMG');
5 for (var i=0; i<bilder.length; i++) {
6 if (!bilder[i].complete) {
7 ok = false;
8 break;
9 }
10 }
11 if (ok) {
12 geladen();
13 } else {
14 window.setTimeout('rendertest()', 100);
15 }
16 }

---

Saugstark

Die Hauptbremse beim Surfen ist nach wie vor das Laden der Daten vom Server. Die Schnelligkeit eines Browsers hängt also in hohem Maß davon ab, wie schlau er mit der Bandbreite umgeht und die Möglichkeiten von HTTP ausreizt. An einigen dieser Schräubchen kann der Nutzer auch selbst drehen.

Eines dieser Schräubchen ist die Zahl der gleichzeitigen HTTP-Verbindungen. Vor allem Nutzer von Breitbandverbindungen surfen mit einem höheren Wert eventuell ein Quäntchen schneller. Mehr ins Gewicht fällt die Zahl der gleichzeitigen HTTP-Verbindungen zum selben Server, denn in der Regel kommen Stylesheets, Skripte und Grafiken von der gleichen Quelle wie die zugrundeliegende HTML-Seite. Technische Probleme bei überhöhten Werten sind nicht bekannt, allerdings gilt es als schlechter Stil, unnötig viele gleichzeitige Verbindungen offen zu halten und damit den Server stärker zu belasten.

Von einem gängigen Trick, der mit Version 1.1 von HTTP möglich wurde, profitieren Besucher wie Betreiber: persistente Verbindungen („keep-alive“), welche die Verbindung zwischen Client und Server mehrfach nutzen, statt sie jedes Mal neu aufzubauen. Das erspart beiden Seiten den wiederholten Handshake.

Laut HTTP-Spezifikation sollten Browser nicht mehr als zwei persistente Verbindungen gleichzeitig zum Server unterhalten, um diesen nicht über Gebühr zu belasten. Zugunsten der Geschwindigkeit schlagen manche Browser diesen Ratschlag in den Wind; Firefox 3 etwa erlaubt per Voreinstellung sechs gleichzeitige persistente Verbindungen zum selben Server.

Während alle gängigen Browser persistente Verbindungen beherrschen, ist das darauf aufbauende Pipelining weit weniger verbreitet. Dabei bündelt der Browser mehrere Anfragen und schickt sie gleichzeitig an den Server, was vor allem bei Internetverbindungen mit hoher Latenz (etwa über UMTS) Zeit spart. Internet Explorer und offenbar auch Safari beherrschen dieses Kunststück nicht, bei Firefox ist es abgeschaltet, nur Opera nutzt es standardmäßig. In Firmennetzwerken wird man diese Funktionen kaum nutzen können, denn Proxys sprechen in der Regel nur HTTP 1.0.

Ein weiteres Kunststück, das die Ladezeit verkürzen kann, ist Prefetching. Dabei versucht der Browser zu erraten, welche Seite der Anwender als nächstes öffnen wird. Im Firefox ist eine moderate Form von Prefetching eingeschaltet, bei der der Browser besonders gekennzeichnete Ressourcen (etwa <a href="…" rel="next"> oder <link href="…" rel="prefetch"> lädt, während er auf Benutzereingaben wartet. In der Praxis spielt das kaum eine Rolle, weil nur wenige Webseiten diese Technik nutzen.

Die Firefox-Erweiterung Fasterfox treibt dieses Verhalten auf die Spitze, indem sie per Voreinstellung wie ein Offline-Browser oder Suchmaschinen-Robot alle verlinkten Seiten und Bilder lädt, die sie vorfindet – ein zweifelhaftes Vorgehen, das die Traffic-Kosten des Betreibers erhöhen und dessen Nutzungsstatistiken verfälschen kann.

Am schnellsten zeigt der Browser natürlich die Seiten, die er gar nicht aus dem Netz holen muss, sondern aus dem Cache. Die voreingestellte Größe und Aktualisierungsfrequenz des Festplattenpuffers bietet aber selten Raum für Optimierung – schließlich ist mit einer veralteten Version der angeforderten Seite niemandem gedient.

Tiefer legen

Vor allem Firefox eignet sich für Tuning-Experimente, da er sich unter about:config sehr fein einstellen lässt. Die wichtigsten Einstellungen, um möglicherweise das letzte Quäntchen Performance herauszukitzeln, finden sich unter network.http. Dort lassen sich zum Beispiel die max-connections, die max-connections-per-server, die max-persistent-connections-per-server und die max-persistent-connections-per-proxy hochsetzen; bei breitbandiger Netzanbindung haben sich Werte bewährt, die ungefähr beim Anderthalbfachen der Vorgaben liegen.

Einen Versuch wert ist auch das Anschalten von pipelining und proxy.pipelining; die pipelining.maxrequests kann man beherzt von 4 auf 30 erhöhen.

Um den Seitenaufbau zu beschleunigen, kann man Firefox dazu zwingen, die empfangenen Daten früher und häufiger auszuwerten – was natürlich höhere Anforderungen an die CPU stellt. Per Voreinstellung wartet der Browser eine Viertelsekunde mit dem ersten Render-Versuch; die neuen Config-Einträge nglayout.initialpaint.delay und ui.submenuDelay erlauben es, einen beliebigen Wert in Millisekunden einzutragen (auch null ist zulässig).

Mit drei neuen Schlüsseln unter content.notify lassen sich Anzahl und Frequenz der Neudarstellungen regeln: backoffcount gibt die maximale Anzahl von Render-Versuchen an (zum Beispiel 5), interval setzt den Mindestwert zwischen zwei Neudarstellungen in Mikrosekunden an (Standard: 120 000), was mit ontimer gleich true zu bestätigen ist.

Das Gegenstück dazu (also die maximale Wartezeit) ist content.max.tokenizing.time, voreingestellt auf das Dreifache von content.notify.interval. Ein niedriger Millisekundenwert in content.switch.threshold (Default: 750 000) lässt Firefox während des Ladens schneller auf Benutzereingaben reagieren, verlängert aber den Ladevorgang.

Einen großen Teil dieser Einstellungen setzen auch die oben erwähnte Erweiterung Fasterfox und die Anwendung Firetune, welche die Leistungsfähigkeit von Rechner und Netzanbindung untersucht, um dann passende Browser-Einstellungen vorzunehmen.

Um Arbeitsspeicher zu sparen, empfiehlt sich die Erweiterung RAMBack, die nicht mehr offene Seiten aus dem RAM löscht. Mit dem about:config-Wert config.trim_on_minimize auf true erlaubt Firefox Windows beim Minimieren, den Arbeitsspeicher auf die Festplatte auszulagern, was aber zu einer kleinen Denkpause beim Wiederherstellen führt.

Ähnliche Einstellmöglichkeiten wie Firefox kennt nur noch Opera, doch scheint das Optimierungspotenzial gering. In Einstellungen/Erweitert kann der Nutzer unter „Netzwerk“ die maximale Anzahl gleichzeitiger Verbindungen oder (unter „Browser“) die Wartezeit bis zum ersten Render-Versuch ändern. Das Gegenstück zu Firefox’ about:config heißt opera:config und enthält einen Punkt „Performance“. Dort lässt sich zum Beispiel die Größe des Netzwerk-Buffers festlegen, in dem der Browser noch nicht verarbeitete Daten zwischenlagert – ein Szenario, das nur für langsame Rechner mit schneller Netzverbindung interessant ist.
Die spartanischen Bedienoberflächen von Internet Explorer und Safari kennen keine Beschleunigungstricks. Der im IE sehr niedrig eingestellte Höchstwert gleichzeitiger Verbindungen lässt sich allerdings über die Registry hochsetzen: Dazu legt man in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings die Einträge MaxConnectionsPerServer und MaxConnectionsPer1_0Server an und setzt sie zum Beispiel auf 8.

Beschleunigend wirkt natürlich auch die Ausfilterung unerwünschter Inhalte, etwa mit den Firefox-Erweiterungen AdBlock Plus und Flashblock, über Operas „Inhalt blockieren“ oder beim Internet Explorer mit Hilfe des Zonenmodells.

Browser-Benchmarks
	Internet Explorer 7.0 [ms]	Internet Explorer 8 Beta 2 [ms]	Firefox 3.0.1 [ms]	Firefox 3.0.1 erweitert [ms]	Firefox 2.0.0.16 [ms]	Opera 9.52 [ms]	Safari 3.1.2	Safari 4 Developer Preview [ms]
Startzeit	1000	600	1200	2200	1500	900	1000	700
Benchmarks
SunSpider 0.9	38 632	11 424	5438	5392	22 640	7684	5788	4301
Celtic Kane	925	868	477	511	1087	447	359	306
Nontroppo/Celtic Kane	2678	1981	426	439	879	317	390	311
Schleifentests	34 607	20 110	3311	3351	8143	4711	3421	3024
Mesh Transform	1695	1108	732	731	4535	853	843	742
3D-Würfel	2274	3026	2112	2187	2867	924	839	1067
Raytracer	44 055	>1 000 000	489 220	489 382	577 959	29 604	32 022	15 812
DOM-Animationen	-	-	9567	9788	21 143	5455	9869	8732
DOM-Tests	4815	838	482	519	638	239	203	114
Ladetests
100 MBit/s mit Proxy	32 050	38 332	29 363	35 096	32 473	29 214	27 975	26 729
100 MBit/s ohne Proxy	42 650	55 483	49 703	46 255	56 193	52 478	31 899	36 831
2 MBit/s mit Proxy	50 780	59 104	48 499	47 297	42 922	39 023	40 817	39 068
2 MBit/s ohne Proxy	62 705	71 419	56 460	61 094	62 374	59 832	52 128	45 617
384 KBit/s mit Proxy	137 174	144 454	100 227	106 540	104 275	96 385	117 192	123 505
384 KBit/s ohne Proxy	155 080	155 650	104 288	120 730	109 235	95 442	109 666	126 436
64 KBit/s mit Proxy	528 799	685 920	405 823	458 229	393 598	346 305	520 863	535 916
64 KBit/s ohne Proxy	372 334	435 797	416 738	466 610	423 455	362 069	428 098	478 695
Progressives Laden	67 000	56 500	55 700	60 300	56 700	57 000	58 000	59 700
History-Test	-	-	24 300	29 600	23 600	21 800	32 500	-
Speicher (max., MByte)	249,2	276,5	136,5	244,5	144,9	218,5	265,4	272,3
Bewertung
JavaScript	–	[-]	[+]	[+]	[±]	[+]	[+]	[++]
Laden und Rendern	[±]	–	[+]	[+]	[+]	[+]	[+]	[+]
Speicherverbrauch	[±]	[-]	[++]	-	[++]	[+]	[±]
Die Werte geben den Durchschnitt aus drei Messungen an. Den Ladetests mit 20 Webseiten ging ein nicht gewerteter Durchgang zum Cachen eingebetteter Dateien voraus.
[++] sehr gut [+] gut [±] zufriedenstellend [-] schlecht – sehr schlecht + vorhanden - nicht vorhanden k. A. keine Angabe

(heb)