Andy Hume pendelt täglich mit dem Zug von Brighton nach London. Andy arbeitet bei Twitter, früher war er beim Guardian. Im Tunnel kommt es zu merkwürdigen Effekten. Es ist das Problem der fehlenden Fonts. Hume nennt das scherzend: „White Screen of Death-Scenario“.

Andy Hume hat einen der Slots als Speaker bei Codefront.io, einer Konferenz für Frontend-Web-Entwicklung im oberösterreichischen Linz. Mal nicht Berlin, mal London, und mit dem Zug in zwei Stunden gut zu erreichen.

Zurück zu seinem Vortrag: Das ist kein Bug, dass die Seiten nicht zu erreichen sind. Hume betrachtet aber dieses Verhalten auch als einen Ausfall. DevOps verwende viel Zeit auf das Verfügbarmachen von Seiten unter Last. Aber nicht nur so gehen Seiten kaputt. Tunnel sind ein möglicher Auslöser, aber auch mobile Carrier versuchen, Javascript zu komprimieren und lassen Seiten kaputt gehen. Ähnlich verhalten sich Firewalls im Unternehmensumfeld.

Der Browser ist an sich zwar taff, er hat da seine eigene Fehlerbehandlung. Aber dennoch gibt es eben die Effekte, dass Seiten bis auf ein paar Bilder weiß bleiben.

Andys Tipp: Über progressive Enhancement sollte man nachdenken, nicht weil es User gibt, die Javascript ausgeschaltet haben. Sondern weil ein Nutzer in einen Tunnel gefahren ist. (Der Tunnel ist ein pars pro toto, natürlich. Es geht nicht um Züge und tunnel. Das soll nur zeigen, dass Sachen schief gehen können.)

Dabei gibt es drei Ebenen von Content, den wir als Macher von Webseiten darstellen wollen. * Content – das Ding, das wir priorisieren wollen. Beim Guardian war das die News

* Enhancement – Swipe-Effekte für Touch-Geräte zum Beispiel, Fußballergebnisse in der rechten Spalte

* Leftovers – Analytics, Werbung – Dinge, die wichtig sind, aber nicht wichtig für den User

Hier sollte sich jeder die Frage stellen: Laden wir die Sachen zu den richtigen Zeitpunkten? Ein Tool, das die Analyse ermöglich hat, war der Critical Path Explorer in Google Chrome. Den gibt es nicht mehr. Andy hofft, dass das zurückkommt. (Er ist auf Webpagetest.org als Tool umgestiegen.)

Warum teilt man die Seite wirklich in drei Säulen? Weil die Zeit, bis Zeug auf dem Screen erscheint, für den User die wichtigste Performance-Metrik ist. Grundregel: So wenige HTTP-Requests wie möglich. Vor allem auf low-quality-high-latency-Netzwerken wie im mobilen Netz. Etwa in der U-Bahn. Oder im Zug auf dem Land. Oder in Konferenzen.

Ein weiteres performanceschädliches Element sind aus Humes Sicht Redirects. Redirects wie URL-Shortener sind eine eigene Subbranche in unserer Branche. „Ich hasse sie“, sagt Andy Hume. Sie fügen mehrere Roundtrips der normalen Abfrage hinzu.

Jetzt aber in der gebotenen Tiefe in das Problem der nicht erscheinenden Webfonts. Erstaunlicherweise geht der Internet Explorer am robustesten mit der Darstellung von Schrift um. Er stellt Schrift da und switcht dann die Webfont-Darstellung aus. Webkit und Blink blockieren die Darstellung des Textes. Die Seite bleibt einfach leer, wenn aus irgendwelchen Gründen die Konnektivität verloren geht. Firefox hat ein Timeout – wenn Font nicht lädt, wird nach drei Sekunden zumindest lesbarer Text geladen.

Web Font Loader ist eine Open-Source-Bibliothek, mit der man Fonts aus dem kritischen Pfad entfernen kann. Man fügt dem CSS eine weitere Klasse hinzu, clarendon.loaded, wenn man erst eine Schrift darstellen will. Das bläht zwar das CSS auf, aber die Performance für den User wird verbessert.

Eine nicht gerade intuitive Form der Performance-Verbesserung ist auch das Hinzufügen von CSS in den Head des Dokuments. Wenn nicht viele Seiten geladen werden, weil der Nutzer eh nur eine Seite ansieht, kann man auf Kosten des Cachings auch zu dieser Praxis greifen. Guardian kriegt eh nicht viel mehr als einen Seitenaufruf pro Besuch. Dort lädt man die Gestaltung für den sichtbaren Bereich im mobilen Browser.

Tipps zum Googlen: Google hat auch Empfehlung für weniger als 15k, bevor die Seite Brian McQuade hat das toll zusammengefasst: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/