Diejenigen, die bereits in den Genuss von #newtwitter kommen, werden es bereits gemerkt haben: es fühlt sich merklich schneller an als die alte Version. Das liegt nicht nur daran, dass man im Hintergrund die Hardware aufgestockt hat, sondern vielmehr an konsequenter Frontend-Optimierung.

Schaut man sich die Applikation in Firebug einmal genauer an, fällt sofort auf, dass jetzt auch das Webinterface die Twitter-API nutzt. Das hat den Vorteil, dass sämtliche Weiterentwicklungen nur noch an einer Stelle geschehen müssen und nicht wie vorher doppelt (für das Webinterface und die API getrennt). Es ist davon auszugehen, dass der Code für die Schnittstelle allgemein performanter ist, da dort ja bereits vorher eine wesentlich größere Last bewältigt werden musste als über das Webinterface. Durch die Umstellung auf die API profitiert die Website an sich bereits ohne weitere Arbeiten. Besonders deutlich sieht man den Unterschied, wenn man sich mal die “Retweet”-Sektion anschaut. Während dieses Feature vorher unerträglich langsam war, ist es jetzt genauso schnell wie die persönliche Timeline oder eine Suche.

Ein weiterer Grund für den Performance-Schub ist auch zweifelsohne der Einsatz einfachster Frontend-Optimierungen (GZIP, Request-Minimierung, JS/CSS-Minifying). Beim alten Web-Client war davon noch kaum etwas zu sehen.

Der wichtigste Fortschritt ist jedoch das konsequent und exzessiv umgesetzte Client-Caching. Was einmal übertragen wurde wird auf der Seite des Users gespeichert und braucht nicht wieder vom Server geholt zu werden. Schön sieht man das, wenn man zwischen den Tabs hin und her springt. Hat man einen Tab während einer Sitzung bereits einmal besucht, bekommt man zunächst den letzten Stand, der auf dem Client gespeichert ist angezeigt. Gleichzeitig wird jedoch ein API-Request abgesetzt um Updates vom Server nachzuladen.

Früher wurde immer die komplette Timeline neu vom Server angefordert. Das führte dazu, dass sich Twitter trotz asynchroner HTTP-Requests wie eine ganz gewöhnliche Website ohne AJAX anfühlte, weil einfach viel zu viele Daten nachgeladen wurden.

Generell sagt man ja “je weniger Requests, desto schneller die Seite”. Beobachtet man in Firebug, was passiert, wenn man auf einen Tweet klickt und so in der Sidebar die Details geladen werden, fällt jedoch auf, dass man bei den Twitter-Entwicklern gleich mehrere Requests an die API anstößt. Das hat mehrere Gründe, der wichtigste zuerst: Wollte man die Anzahl der Requests auf die API reduzieren, müsste man mehr Informationen über die einzelnen Schnittstellen ausliefern. Das bläht die Schnittstellen nicht nur auf, sondern nimmt auch jede Menge Flexibilität. Das Verteilen der Aufgaben auf die verschiedenen Cluster würde sich wesentlich schwieriger gestalten und unter Last wäre es relativ kompliziert, einzelne Features abzuschalten, ohne eine Reihe von Third-Party-Software kaputt zu machen.

Der zweite Grund für das Anfordern verschiedener Daten in mehreren Requests ist, dass “objektiv schnell” nicht gleich “subjektiv schnell” ist. Fordert man alle Daten auf einmal an, mag die Gesamtzeit für das Darstellen der Informationen geringer sein, der Zeitpunkt, zu dem der User das erste Mal etwas zu sehen bekommt, kommt jedoch wesentlich später. Die wichtigsten Informationen treffen durch dieses Prinzip früher beim User ein und vermitteln ein schnelleres Gesamtbild.

Mit #newtwitter haben die Entwickler einen großen Fortschritt gemacht: es werden mehr Informationen in kürzerer Zeit dargestellt und die Usability hat sich in meinen Augen zumindest für sehende Nutzer erheblich verbessert. Schafft man es jetzt noch, die Accessibility-Hürden aus dem Weg zu räumen, steht dem Erfolg nichts mehr im Wege.