Gestern hielt ich auf dem Webmontag in Frankfurt einen Vortrag über Web Performance Optimierung. WPO wird nach Vorhersagen in den nächsten Jahren wie SEO eine eigene Industrie werden. Tenni Theurer und Steve Souders begannen 2006 bei Yahoo!, die Performanz von Webseiten eingehender zu untersuchen. Entsprechend der Prämisse, dass man am Ende mehr profitiert, wenn man seine Erkenntnisse mit anderen teilt, publizierte Yahoo! diese Ergebnisse auf Konferenzen und Blogs noch im selben Jahr. Souders veröffentlichte in der Zwischenzeit zwei Bücher zum Thema und arbeitet heute bei Google. Bei Namics befassen wir uns mit WPO seit Sommer 2006 und teilen auch gerne.
Ziel von Web Performance Optimierung ist es, schneller und kleiner zu werden: Studien von Yahoo! und Google haben ergeben, dass nur 10-20% der Ladezeit vom Server abhängig ist. Bis vor wenigen Jahren dachte man bei Geschwindigkeit ausschließlich an den Server. Tatsächlich werden aber 80-90% der Ladezeit im Frontend fällig. Darum ist WPO im Frontend effizienter.
Zwei wichtige Schwachstellen sind JavaScript-Dateien und die schiere Anzahl von Dateien: JavaScript lädt sequentiell und blockiert sämtliche nachfolgenden Inhalte. Darum sollte es nicht im Kopf, sondern im Fuß einer Seite stehen. Zweitens können ältere Browser, vor allem der Internet Explorer, nur 2-4 Dateien parallel laden. Dateien bilden eine Warteschlange, die nur langsam abgearbeitet wird. Ziel ist es darum, durch Zusammenfassung von Dateien die Anzahl der HTTP-Requests zu reduzieren.
Verschiedene internationale Unternehmen haben Studien angestellt oder einfach den Effekt von Optimierung getrackt.
Effekte von Langsamkeit
- Amazon: 100 ms. Verzögerung führten zu 1% weniger Umsatz.
- Google: 400 ms. Verzögerung führten zu 0,59% weniger Suchabfragen pro User (frühere Tests ergaben größere Zahlen).
- Yahoo!: 400 ms. Verzögerung führten zu 5-9% weniger Traffic.
- Bing: 2 Sekunden Verzögerung resultierten in 4,3% weniger Umsatz pro User.
Effekte von Geschwindigkeit
- Mozilla hat seine Downloadseite um 2,2 Sekunden schneller gemacht, was durch 15,4% mehr Downloads belohnt wurde.
- Google Maps reduzierte das Dateivolumen um 30% und beobachtete daraufhin 30% mehr Kartenaufrufe.
- Netflix schaltete Gzip auf dem Server ein; alleine dadurch wurden die Seiten um 13-25% schneller und sie sparten 50% Dateivolumen ein!
- Shopzilla schaffte es, die Ladezeit von 7 auf 2 Sekunden zu reduzieren, wodurch die Conversion Rate um 7-12% stieg, 25% mehr Seitenaufrufe beobachtet wurden, 50% der Server in den Ruhestand geschickt und entsprechend Energiekosten eingespart werden konnten.
- AOL beobachtete die Anzahl der Page Views auf verschiedenen Websites. Während die schnellsten User 7-8 Seiten aufriefen, waren es bei den langsamsten durchschnittlich nur 3-4.
Als Sahnehäubchen hat vor kurzem Google angekündigt, künftig die Ladezeit als Parameter im Suchmaschinenranking zu berücksichtigen.
Am Ende werden die Seiten schneller, die Kunden sind glücklich, generieren mehr Umsatz und Page Views, und gleichzeitig sinken Stromverbrauch und CO2-Ausstoß. Wieder einmal die Welt gerettet! Und wer dazu beitragen möchte, beginnt am besten damit, sich die Regeln bei Yahoo! anzuschauen. Ein paar Tricks, die darüber hinaus gehen, gibt’s in der Präsentation.









Hallo Martin und vielen Dank für die coolen Geschäftszahlen bei langsamen und schnellen Sites sowie die Quelle dazu (habe ich mir grad reingezogen). Merci, Jürg.
Danke für den gut aufbereiteten Post! Leider konnte ich ja nicht zum Webmontag kommen. Wirklich ein sehr interessantes und wichtiges Thema. Auch im Hinblick auf CRO! btw: Bei der Verknüpfung mit Social Media Elementen gibt es auch oft noch großes Potenzial zur Performance Optimierung.
@Tina, richtig, iFrames, wie sie neuerdings wieder überall mit Facebook-Like-Buttons und dergleichen in Mode kommen, sind eigentlich starke Performance-Hindernisse. Steve Souders hat bereits die Effekte von einigem Third Party Content untersucht. Insbesondere der Code von Adservern ist oft grauenvoll und langsam. Eine saubere Lösung für die Integration von Social Media wäre im Backend über die APIs.
Sehr interessantes Thema. Gerade in Verbindung mit SEO, wie du neulich schon angemerkt hast. Ich werde das sicherlich weiter verfolgen.
Mit dem Adblock filter
namics.com##div[id="logo-reloaded"]
kann man die Block sogar ungestört durch lächerliche Animationen lesen.
@Harald. Hi, hi… sozusagen eine “Branding-Fix”. Bei uns geht so was einfach, denn ausser der Wortmarke hat es keinen “Kitsch”…
@Jürg: WCAG Punkt 2.2.2 – Animationen lenken vom Lesen ab und sollen nach 5 Sekunden stoppen oder abschaltbar sein. Offenbar ein Punkt, der nicht nur für Menschen mit Lernbehinderung wichtig ist. Ist Barrierefreiheit in Projekten vielleicht doch oft relevanter, als manche meinen? Für mich war es immer ein Qualitätskriterium.