Web Performance Optimierung (WPO)

Hinweis der Redaktion

• #2: „WPO“ ist das Akronym für Web Performance Optimierung, analog zu „SEO“ wird es in den nächsten Jahren eine eigene Industrie werden.
• #3: 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.
• #4: Ziel von Web Performance Optimierung ist vor allem, schnell und klein zu sein. Wenige, kleine Server-Requests.
• #5: 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 Web Performance Optimierung (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 darum eine Schlange, die nur langsam abgearbeitet wird. Ziel ist es darum, durch Zusammenfassung von Dateien die Anzahl der HTTP-Requests zu reduzieren.
• #6: In diesem Beispiel einer deutschen Bank ist zu sehen, dass sich die Ladezeit der Seite in zwei Teile aufteilt: das Backend macht in diesem Fall inkl. DNS-Lookup 813 ms oder 13,71% aus, das Frontend über 5,4 Sekunden, das sind 91,13% (es gibt Überlappungen).
• #7: Zwei kritische Punkte hier sind das JavaScript und die Bilder: JavaScript lädt nur sequentiell, nicht parallel, und blockiert hier den Seitenaufbau um 1,7 Sekunden. Bilder laden parallel, aber in der Regel nur 2-4 gleichzeitig, weswegen selbst kleine Dateien „Schlange stehen“ müssen, bis sie an der Reihe sind, und für jedes muss eine eigene Serverabfrage gemacht werden.
• #8: Jetzt könnte man meinen, 5,9 Sekunden Ladezeit wären doch nicht so übel. Tatsache ist aber, dass Kunden selbst Veränderungen im Bereich von wenigen hundert Millisekunden quittieren:
• #9: Zusätzlich zur Seitenverzögerung hat man festgestellt, dass die Nutzer abgelenkter werden. 400 ms. mehr Ladezeit führten zu fast 800 ms. Verzögerung bis zur Interaktion mit der Seite!
• #11: AOL hat die Anzahl der Page Views in Abhängigkeit von der Ladegeschwindigkeit untersucht. Wenig überraschend war die Anzahl der besuchten Seiten höher, wenn sie schnell luden. Interessanterweise ist der Kurvenverlauf bei den untersuchten Sites unterschiedlich. Offenbar spielt der Kontext bzw. Surf-Modus eine Rolle, wieviele Seiten ein User durchklickt. Übereinstimmend lässt sich sagen: schnellere Websites laden zum Browsen, zum Herumstöbern ein. Man kann mehr Informationen an den User vermitteln.
• #15: Besondere Bedeutung hat WPO noch bekommen, als im April 2010 Google verkündete, dass die Seitengeschwindigkeit nun auch ein Ranking-Parameter sein wird.
• #16: Zusammenfassend lässt sich sagen: alle sind glücklich. Die Seiten laden schneller, verbrauchen weniger Serverressourcen und damit weniger Strom, die Kunden werden stöberfreudiger, und der Umsatz steigt. Nebenbei ist es grüner, und wir haben wieder einmal die Welt gerettet – was will man mehr?
• #18: Die 14 in „High Performance Websites“ veröffentlichten Regeln.
• #20: GZIP lässt sich auf Apache-Servern mit wenigen Zeilen aktivieren. Es wird alles gezippt, das textbasiert ist. Bilder müssen nicht gezippt werden, denn sie sind ohnehin bereits komprimiert.
• #21: Durch den Expires Header wird Caching ermöglicht. Je weiter das Datum in der Zukunft ist, desto besser. Wenn JavaScript- und CSS-Dateien serverseitig aggregiert werden, kann die generierte neue Datei mit einem Timestamp versehen werden und mit einem Expires Header in der fernen Zukunft sehr lange gecacht werden. Auch Dateien, die sich nach einem Launch nicht mehr oft ändern, wie CSS-Dateien oder das Favicon, sollten sehr lange gecacht werden. Es wird alles gecacht außer den HTML-Dateien selbst.
• #22: Die ideale Zahl an (Sub-) Domains in einer Seite ist 2-4. Einige Websites verwenden eine cookiefreie Subdomain für Bilder, um nicht bei jedem Bild-Request die Cookies mit auszutauschen.
• #23: Redirects sollten vermieden werden. Wenn es unbedingt welche geben muss, sollten sie eine 301 oder 302 Response zurückgeben.
• #24: CSS-Sprites gibt es seit 2004. Statt vieler kleiner Dateien mit jeweils einem Icon gibt es dann eine einzige mit vielen Icons, die als CSS-Background-Images mit background-position verschoben werden. Auf diese Weise spart man sehr viele zeitintensive HTTP-Requests. http://www.alistapart.com/articles/sprites
• #25: Die Website der WebTech-Konferenz bringt es auf stolzer 800 KB mit 101 HTTP-Requests, wovon die meisten auf Profilbilder der Referenten entfallen. Das lässt sich nicht vermeiden. Aber die 10 CSS-Bilder ließen sich reduzieren, die 8 CSS-Dateien zu einer einzigen zusammenfassen und die JavaScript-Dateien ebenso.
• #26: Auffällig bei der Websites des Internet Briefings sind die 17 JavaScript-Dateien, die mit 348 KB auch sehr groß sind. Hier lässt sich viel optimieren. 29 Bilder werden vermutlicht nicht gebraucht, und die 9 CSS-Dateien lassen sich serverseitig aggregieren. Ebenfalls auffällig ist, dass über 200 KB nicht gecacht werden.
• #27: Apache modconcat aggregiert einfach Dateien ohne viel Aufwand. Nachteil: dies geschieht zur Laufzeit.
• #28: Darüberhinaus gibt es noch viele weitere Tools zur Aggregation: per Ant-Script,
• #29: … mit JSMin per PHP,
• #30: … oder mit JAWR in Java.
• #32: JavaScript-Dateien minifizieren (also überflüssigen Whitespace entfernen) kann man mit modjsmin,
• #33: … oder, wenn es nur gelegentlich oder kurz vor dem finalen Deployment erforderlich ist, mit der Minifizierungsfunktion in Google Page Speed.
• #34: Google Page Speed.
• #35: Der Server benötigt 200-500ms zum Zusammenbauen der Seite: diese Zeit kann man nutzen, indem CSS in den <head> gestellt wird. Die Qualität von CSS-Selektoren beeinflusst übrigens kaum die Performance.
• #37: JavaScript wird am Ende des Codes unmittelbar vor dem schließenden </body> eingebunden, damit die Dateien keine anderen Inhalte blockieren.
• #38: Ausgenommen davon sind non-blocking Scripts, die entweder per JavaScript oder in HTML5 mit dem async-Attribut eingebunden werden.
• #40: Mit Content Delivery Networks wie Amazon S3 oder Akamai werden Inhalte von einem Proxy in der Nähe des Users ausgeliefert, was Zeit spart.
• #41: Etags setzen sich aus vielen Faktoren zusammen. Bei einer Serverfarm haben verteilte Dateien zwar einen gleichen URL, aber oft unterschiedliche Etags. Dies führt dazu, dass ein Bild, das von Server 1 ausgeliefert wurde, das nächste Mal von Server 2 erneut abgefragt wird, weil durch die unterschiedlichen Etags für den Browser nicht die gleiche Ressource vorliegt. Somit ist Caching ausgehebelt. Am einfachsten ist es, Etag mit obigem Befehl in Apache auszuschalten.
• #42: Auch AJAX-/JSON-Requests sollten gecacht werden. Die Freunde bei Facebook ändern sich nicht so oft, man kann sie leicht eine Stunde cachen. GET-Requests lassen sich leicht cachen.
• #43: Nach 14 Slides ein bisschen Kurzweil mit Chrome Speed Tests – da geht es auch um Geschwindigkeit.
• #44: Auf die im zweiten Buch besprochenen neuen Regeln möchte ich nur stichprobenhaft eingehen, denn sie würden den Umfang dieses Vortrags sprengen. Im Detail sind sie bei Yahoo! Im Web nachzulesen.
• #45: Große Websites flushen oft den Buffer, wenigstens nach der Generierung des HTML-Heads. Dann kann der Browser bereits das CSS laden.
• #46: Unvorsichtig eingesetztes JavaScript kann den Browser für einige Sekunden einfrieren lassen, insbesondere den Internet Explorer. Vorsicht bei einfach aussehenden Selektoren in jQuery, die dahinter komplexe Abfragen fahren.
• #47: Vorsicht auch bei IFRAMEs.
• #49: Julien Lecomte hat die Performance von 3rd Party Content untersucht. Während Google Analytics sehr gut mit Ressourcen umgeht, sind andere Skripte sehr groß.
• #50: Bilder werden oft von Redakteuren zu hochauflösend oder in einem falschen Format eingebettet. Bilder sollten nie im Browser runterskaliert werden!
• #51: Man muss hinzufügen, dass das ein Hack ist. Effizienter ist es, wenn das CMS beim Upload der Bilder entsprechende Korrekturen in Format und Qualität vornimmt.
• #52: PngOptimizer
• #53: Yahoo! SmushIt
• #54: Unter Lazy-Loading versteht man das Nachladen von Bildern, die nicht sofort sichtbar oder nicht im sichtbaren Bereich sind, nachdem die Seite fertig geladen hat.
• #55: Es gibt verschiedene JavaScript-Libraries, die Bilder erst dann nachladen, wenn man sie braucht.
• #57: Anstelle von CSS-Sprites kann man Icons auch in einer eigenen Schriftdatei einbetten. Aus Gründen der Barrierefreiheit sollten die Icons nicht auf die Buchstaben ABC gelegt werden, sondern auf das entsprechenden Unicode-Zeichen, etwa für einen Stern.
• #60: Gegen Ende der Frontend-Programmierung sollten alle CSS background-images durch data:URIs ersetzt werden. Damit werden weitere HTTP-Requests eingespart.
• #61: Base64 braucht man, damit die data:URIs auch im Safari auf dem iPhone angezeigt werden.
• #62: MHTML im IE, Teil 1: Zunächst baut man in einem CSS-Kommentar den data:URI ein und referenziert ihn mit einer ID (Content-Location)
• #63: MHTML im IE, Teil 2: Als URL des background-images verwendet man dann das CSS mit „!ID“ angehängt