Die Browserszene im Zeichen des Pinguin ist in voller Bewegung. Nicht nur hat der Test vor zwei Monaten [1] gezeigt, dass sich im letzten Jahr viele Programmierer ehrgeizig an das Ausbessern von Fehlern gemacht haben, auch in den letzten Wochen wurde gebastelt.

Das spürt man besonders beim Konqueror, der mit der aktuellen Version eine große Scharte auswetzen konnte. Die Vorgängerversion weigerte sich standhaft, Radiobuttons, Checkboxes oder Texteingabefelder zu rendern, wenn sie in »FIELDSET«-Klammern standen. Das klappt jetzt und Konqueror schafft aus dem Stand elf Punkte mehr als beim letzten Mal. In die Mozilla-Klasse steigt er aber dennoch nicht auf.

Wie im letzten Test versprochen, folgen heute die HTML-4-Ergebnisse von Mozilla 1.1 und Netscape 7. Doch auch die anderen Browser haben neue Versionen herausgegeben, so dass letztlich nur der Oldie Netscape 4.79 und Beonex 0.8 unverändert im Rennen sind. Galeon ist jetzt mit 1.2.6 vertreten, Konqueror mit 3.0.3, Opera mit 6.03. Und auch aus Redmond kommt Neues: Das Service Pack 1 für den Internet Explorer 6 ist da. So haben wir eigentlich fast alles noch einmal getestet - und die Geschwindigkeitsmessungen obendrein.

Der Benchmark

Genau wie im Konformitätstest wird beim Geschwindigkeitstest mit dem i-Bench von E-Testinglabs gearbeitet, der Labortochter des US-Verlags Ziff Davis Media. Die Version 3.0 bietet eine Fülle von Geschwindigkeitsmessungen, aus der das Linux-Magazin einen Teil ausgesucht hat (siehe Kasten "So haben wir getestet"). Die wichtigste Messung ist natürlich die Geschwindigkeit beim HTML-Rendering. Dazu gesellt sich ein ähnlicher Test für XML-Dokumente. Zu beiden Tests gibt es auch ein Pendant, das HTML beziehungsweise XML im Document Object Model (DOM) untersucht.

Jeder vollständige Messdurchlauf wird achtmal wiederholt. Dabei weist i-Bench die Durchlaufzeit für den ersten Gang getrennt aus, er fließt nicht in das eigentliche Messergebnis (Subsequent) ein. Dieses errechnet sich aus dem Durchschnitt der sieben gewerteten Läufe. Die Daten aller gewerteten Durchläufe kommen aus dem lokalen Cache des Browsers, so dass der eingesetzte Webserver keinen Einfluss auf das Messergebnis hat.

Um die Seitenwechsel zu beschleunigen, wenden moderne Browser Tricks an. Der Internet Explorer arbeitet beispielsweise mit getrennten Programmteilen am Rendern der Seite und dem eigentlichen Aufbau der angezeigten Seite. Dank der Leistung moderner Prozessoren ist das Rendern längst schneller als das Pinseln der Pixel. Der IE bricht sofort ab, wenn eine aktualisierte Seite fertig gerendert ist. Das bringt Geschwindigkeit.

Mozilla geht sogar noch weiter: Seit der Version 1.1 sieht es für den Betrachter so aus, dass Mozilla das Pinseln einer Seite gar nicht erst anfängt, wenn das Rendern einer aktualisierten Seite beginnt. Das bringt noch mehr. Dadurch ist es aber leider nicht mehr möglich, beim Benchmarken zu kontrollieren, ob die Seiten überhaupt gerendert werden.

Daher hat das Linux-Magazin eine vom üblichen i-Bench-Verfahren abweichende Kontrolle eingeführt. Nach der erfolgten Messung wird ein neuer Messlauf gestartet. Bei ihm wird der Browser immer wieder durch willkürliches Abschalten der Javascript-Unterstützung (die Benchmark-Kontrolle arbeitet in Javascript) abgewürgt. Dabei lässt sich prüfen, ob das Rendern noch stattfindet. Beanstandungen haben sich daraus übrigens nicht ergeben, offenbar schummelt noch keiner der Browser.

Hürdenlauf

Das untersuchte Javascript erwies sich für Opera und Konqueror als echte Hürde. Was auf dem IE nur fünf Sekunden dauert, quält sich hier 97 beziehungsweise geschlagene 189 Sekunden durch den Prozessor. Hier schlug die große Stunde von Oldie Netscape 4.79: Mit acht Sekunden deklassiert er alle modernen Pinguin-Browser.

Zum Schluss wird noch einigen Plugins und natürlich Java auf den Zahn gefühlt. Gerade der Flash-Player von Macromedia machte erheblichen Ärger. Macromedia liefert den aktuellen Player als Netscape-4-Plugin. Diese Schnittstelle ist jedoch veraltet und wird von moderneren Browsern nur noch nachgemacht.

Hinzu kommen Probleme mit Glibc-Symbolen aus frühen Versionen, auf deren Existenz sich Macromedia wohl verlässt, was beim Einsatz mit aktuellen Browsern zum Absturz des Plugins in bestimmten Situationen führt. Eine offizielle Anfrage an Macromedia Deutschland blieb unbeantwortet. So kam es auch in diesem Test immer wieder dazu, dass der Flash-Player zwar von Browsern korrekt angeworfen wird - zu sehen am korrekten ersten Bild -, die Animation aber tot ist.

Bei Java scheint es andere Probleme zu geben, die aber ähnliche Auswirkungen haben. Das Java Runtime Environment von IBM, das SuSE mitliefert, scheint manchem Browser nicht ganz geheuer, denn mitunter löste nur ein Umstieg auf die JRE von Sun das Problem. Ein System war nicht zu erkennen, welche Browser jetzt welche JRE haben möchten. Mysteriös: Mitunter verschwanden Java-Probleme scheinbar von selbst oder traten überhaupt erst nach längeren Testsessions auf.