Es gibt Dinge, die sehen einfach aus, entwickeln sich aber beim näheren Hinsehen zum Problem. Browsertests, derzeit in aller Munde, gehören zu dieser Problemgruppe. So wirbt Apple mit einer deutlichen Beschleunigung des Safari-Browsers in iPhone und iPad beim Upgrade von iOS 4.2.1 auf 4.3, insbesondere dank der Javascript-Engine Nitro. Doch bei einem Test des Web-OptimierersBlaze war von der behaupteten deutlichen Geschwindigkeitssteigerung fast nichts zu spüren. Schlimmer noch für Apple: Deutlich schneller soll hingegen der in Android installierte Chrome sein.

Wer hat recht? Apple, die einen deutlichen Geschwindigkeitszuwachs versprechen, oder Blaze, die davon nichts messen? Nun, wahrscheinlich beide: Apple wird sicher einen Benchmark entwickelt haben, der die behauptete Geschwindigkeitssteigerung bestätigt. Und genauso wird Blaze seinen Benchmark präsentieren können, der kaum Unterschiede zwischen iOSÂ 4.2.1 und 4.3 findet.

Das Problem ist, dass es nicht die Browser-Geschwindigkeit gibt. Reine Javascript-Tests bestätigen Apples Nitro-Engine tatsächlich eine deutliche Geschwindigkeitssteigerung im Vergleich zum Vorgänger. Doch kann diese ihre Geschwindkgeitsvorteile logischerweise nur auf skriptlastigen Webseiten ausspielen. Deren Entwickler gehen aber zunehmend dazu über, die Skripte erst nach der initialen Darstellung der Seite nachzuladen. Was soll man nun als Renderzeit rechnen? Die Zeit bis zur initialen Anzeige (die man lesen kann, mit der man aber nicht interagieren kann), was vor allem einen schnellen HTML- und CSS-Parser verlangt, oder die Zeit inklusive dem Nachladen und Initialisieren aller Skripte (was zusätzlich die Interaktion ermöglicht), wofür zusätzlich die Javascript-Engine gefragt ist?

Viele Browser-Benchmarks verwenden lokal gespeicherte Kopien der Testseiten. Denn es soll ja nicht die Geschwindigkeit der Internetanbindung oder des jeweiligen Web-Servers gemessen werden, sondern die des Browsers. Im Umkehrschluss erkennt der Benchmark aber Verbesserungen im Netzwerkmodul nicht. Da aber zumindest beim Surfen per mobilem Internet die Ladezeiten oft die Renderzeiten überschreiten, wäre der Netzwerktest eigentlich noch interessanter als der Browsertest.

Flüssige Bedienung?

Zudem sind noch weitere Faktoren ebenso wichtig, die sich aber noch weniger in Benchmarks pressen lassen: Scrollt der Browser flüssig? Wie schnell reagiert er auf Interaktionen, etwa das Klicken auf ein AJAX-Element oder die Eingabe eines Werts in ein Formular? Sind die weiteren Funktionen (Bookmarks, Zurück-Button, Suchfenster etc. pp.) sinnvoll angeordnet und schnell zu erreichen? Denn was nutzt eine eine Sekunde kürzere Render-Zeit, wenn man sich vorher durch drei zusätzliche Menüs hangeln muss, um eine bestimmte Seite zu erreichen?

Benchmarks können somit nur einen Teilaspekt der Browsernutzung beleuchten. Klar verlangt man von einem guten oder sehr guten Smartphone-Browser auch eine ordentliche Geschwindigkeit. Aber eine sehr hohe Geschwindigkeit macht noch lange keinen guten Browser, zumal, wenn, wie dargestellt, die gemessene Geschwindigkeit sich noch nicht einmal auf das Gesamtprodukt bezieht, sondern nur auf Einzelfunktionen.