#CGNWebPerformance Meetup 23: Doug Sillars & Felix Hassert über Bildoptimierung und HTTP/2

Am 12. Juni trafen sich mehr als 20 #WebPerformance Interessierte, um am CGN Webperf Meetup teilzunehmen. Als Standort diente beim 23. Meetup unser Sevenval Office in direkter Nachbarschaft zum Kölner Dom.

Zwei Talks waren angesetzt – der erste von Doug Sillars über Bild – und Videooptimierung bei Webseiten. Doug ist als Developer Evangelist für Mobile und Web Performance bekannt und hat unter anderem das Buch “High Performance Android Apps” verfasst.

Der zweite Talk wurde anlässlich des dritten Geburtstages von HTTP/2 in Produktion von Felix Hassert gehalten . Als Direktor für Software-Entwicklung und Anwendung bei Sevenval & wao.io sammelt er täglich Erfahrungen im Einsatz von HTTP/2 (h2).

Nach und nach kamen die Meetup Teilnehmer, sodass das Buffet mit Kaltgetränken und Snacks direkt eröffnet wurde. Neben bekannten Gesichtern waren dieses Mal auch viele neue, neugierige Frontender und auch Backender zugegen. Sogar ein Student der Code University Berlin von Thomas Bachem hatte den Weg zum Meetup gefunden.

Talk I – Doug Sillars: Bild – und Videooptimierung bei Webseiten

Die Talks begannen pünktlich um 19:30 Uhr mit Doug, der das Publikum in seiner Präsentation direkt mit einer Analogie zwischen Angst vor wackeligen Brücken über steinige Abgründe und dem Stress von Nutzern während des Wartens auf das Laden von Webseiten an sich band (der Stress beim Warten ist höher!). Hier kann man von den Amerikanern lernen, Doug kommt aus Kalifornien und weiß, sein Publikum zu begeistern.

Aus dem Stress resultieren Zahlen: etwa die 20%-ige Steigerung der Absprungrate für jede Sekunde, die eine Webseite länger braucht zu laden. 4% der mobilen Nutzer gehen so weit ihr Mobiltelefon durch den Raum zu schmeißen, wenn Seiten zu lange laden!

Der Übergang zum Hauptproblem – Bilder und Videos auf Webseiten – war fließend. Doch wie kann man diese Masse an Daten (75% des mobilen Webs besteht mittlerweile aus Bild- und Videodaten) möglichst schnell und gut an die User ausliefern?

Hier empfiehlt Doug den Kreislauf aus Messen, Analysieren und Optimieren. Zur Messung eignen sich Tools, wie z.B. Web Page Test oder auch der Analyzer von wao.io.

Die Analyse der Ergebnisse erfordert spezielles Frontend Fachwissen. Doug präsentierte exemplarisch vier spezifische Probleme und Lösungsmöglichkeiten:

1) Datenmenge von Grafiken und deren mobile Skalierbarkeit

Generell lassen sich hier die größten Verbesserungen durch den Einsatz des SVG Formats (skalierbare Vektorgrafiken) erzielen. Hierbei ist zu beachten, dass nur “einfache” Grafiken überhaupt sinnvoll in SVG konvertiert werden können und nach Export z.B. aus Adobe Illustrator das Bild manuell von überflüssigen Informationen befreit werden muss – sonst ist der Datenvorsprung gegenüber den Bildformaten JPG und WebP schnell wieder verloren.

2) Datenmengen von Bildern, die nicht als Vektorgrafiken komprimiert werden können – Lossy Komprimierung

Durch die verlustbehaftete Komprimierung von Bildern werden für das menschliche Auge “überflüssige” Bilddaten nicht mehr exakt sondern nur annähernd gespeichert. Diese Komprimierung lässt sich über den Qualitätsparameter (q) bei Bildern steuern.

Gewünscht sind Bilder, die qualitativ gut aussehen und gleichzeitig schnell laden. Hier gibt es verschiedene Algorithmen, die Bilder komprimieren. Doug stellte das Tool Cloudinary vor, womit er einige Komprimierungstests fuhr, um die Unterschiede in Größe und Qualität eines Bildes darzustellen. Dahinter wird der Struktureller Ähnlichkeite Index (SSIM) verwendet, um die verbleibende Bildqualität zu messen.

Neben der Komprimierung kommt es laut Doug auch auf das Bildformat an – die Verwendung von z.B. WebP in Chrome führt in 95% der Fälle zu einer kleineren Datenmenge bei gleichbleibender Qualität.

Mein persönlicher Tipp: Da dies viel Fingerspitzengefühl, manuelle Arbeit und Aufwand bedeutet, gibt es von wao.io einen Bildkomprimierungsalgorithmus, der automatisch das beste Verhältnis von Qualität und Größe des Bildes sowie Bildformat errechnet.

Responsive Images

Bei der mobilen Nutzung des Internets werden viele verschiedene Geräte genutzt. Vom iPhone 4 bis zum Galaxy 7 und allen Geräten dazwischen sind die Bildschirmgrößen und -auflösungen meist verschieden.

Bilder können zwar automatisch skaliert werden, aber dabei lädt der jeweilige Browser und damit auch der Nutzer sehr viel überflüssige Daten mit.

Die Best-Practice Lösung ist hier die Nutzung von “Responsive Breakpoints”, die für jede Bildschirmgröße ein passendes Bild laden. Die gesparten Daten lassen die Bilder nicht nur schneller laden, sondern auch den Nutzer aufatmen.

Am Ende des Vortrags kam die Frage auf, warum die Breakpoints eine 25% Margin haben – ab 25% wird zur nächsten Bildgröße gesprungen. Dies lässt sich aus heutiger Sicht nicht mehr eindeutig beantworten, hat sich aber als Standard durchgesetzt.

Lazy Loading

57% der mobilen Internetnutzer scrollen nicht. Das klingt schlecht für alle One-Pager Webseiten, kann aber als einen Vorteil bei der Web Performance Optimierung genutzt werden.

Durch so genanntes Lazy Loading werden im ersten Schritt nur Inhalte geladen, die der User auch sieht. Dies führe im Durchschnitt zu einer Ladezeitverbesserung von 3,5 Sekunden bei eine 3G Verbindung!

Preview Images / Platzhalter Bilder

Da Bilder, auch wenn sie sehr gut komprimiert sind, meist trotzdem den größten Anteil der übertragenen Daten stellen, ist die Nutzung von Platzhalter-Bildern (Preview Images) zu einer Lösung entwickelt worden.

Der Vorteil von Platzhaltern sind extrem kleine Datenmengen (z.B. kann ein Bild, das normalerweise 50 kilobytes groß ist, mit einem 979 bytes kleinen Vorschaubild ersetzt werden, bis das Originalbild komplett geladen ist), die dem Nutzer die visuellen Sicherheit geben, dass hier ein Bild geladen wird und das Layout sich während des Ladens nicht verändert.

3. Datenmengen von GIF, die komprimiert werden können

Im letzten Teil seines Vortrags beschäftigte sich Doug mit bewegten Bildern, also GIF oder andere Videoformate. GIF (Graphics Interchange Format) wurde wegen seiner damals (1987!) sehr effizienten Kompression von den Einzelbildern populär. Heutzutage ist insbesondere die Umwandlung von MP4 Videos, die beispielsweise auf einem Mobilgerät aufgenommen werden, zu GIF nicht mehr zeitgemäß. So wird zum Beispiel ein 1.4mb MP4 Video durch GIF auf 3.8mb aufgebläht.

Doch auf die visuell ansprechenden Loops, für die GIFs oft verwendet werden, möchten viele Webseitenbetreiber und Nutzer nicht verzichten. Hier stellte Doug eine Lösung über Video Tags vor:

<video autoplay loop muted playsinline controls =”false” src=”video.mp4”/>

Durch “autoplay” wird das Video, wie ein GIF, direkt abgespielt, per “loop” wiederholt es sich automatisch, mit “muted” wird kein Ton abgespielt und durch “playsinline” öffnet sich kein Vollbild-Video.

4. Auslieferung von Videos und was bei Performance beachtet werden muss

Um die 13,88% aller Videos im Netz werden noch während des Ladens abgebrochen. Das ergibt ungefähr 800.000.000 Stunden Videoabspielzeit pro Quartal, die nicht angesehen wird. Für Publisher bzw. Webseiten, die mit Video Content Geld verdienen, ist das ein erheblicher Teil. Ein Grund dafür könnten geographische Beschränkungen sein, wie zum Beispiel, dass die Tagesschau nicht aus Kenia abrufbar ist.

Der wahrscheinlich öfters auftauchende Fall ist, dass die Verzögerung bis zum Abspielen des Videos zu lange ist (ähnlich wie hohe Bounce Raten bei langsam ladenden Webseiten). So ergibt sich eine Erhöhung der Absprungrate bei Videos um 5,8% pro Sekunde nach zwei Sekunden initialer Wartezeit.

Lösungen:

  • Keine 3rd Party/Tracking Scripte als erstes Laden
  • Während Werbung Video buffern
  • Video in mehreren Auflösungen / Datenraten zur Verfügung stellen (mit geringer Auflösung schnell starten und – wenn die Bandbreite es zulässt – die Qualität verbessern, via MPEG-DASH oder HLS)

Quick win:

<video preload = ‘metadata’ src=’<URL>’ >

Somit wird ein Teil des Videos vorgeladen, jedoch nicht alles. Hier ist zu beachten, dass jeder Browser dieses Attribut anders interpretiert.

Übrigens: Viele der vorgestellten Tipps zum Optimieren der Web Performance von Webseiten sind in wao.io automatisiert worden. Wer die Auswirkung selber testen möchte, kann das hier machen.

TCP for web performance in HTTP/2

Talk II – Felix Hassert: 3. Geburtstag von HTTP/2

“Happy Birthday HTTP/2” als Titel, betrachtete Felix die Entwicklung von HTTP/2 (die 2. Version des Hypertext Transfer Protocol, auch h2 genannt) und seine Auswirkung für Developer, Server und User.

TL;DR
Es gibt keinen Grund, HTTP/2 nicht zu benutzen (-:

Warum wurde HTTP/2 eingeführt:

Probleme

In den 1990er Jahren bestanden Webseiten hauptsächlich aus HTML Code. Heutzutage hat sich der Verhältnis zu 3% HTML und 97% Bilder sowie andere Elemente gekehrt. Hierfür war HTTP/1 nicht geschaffen. Das Hauptproblem liegt im ineffizienten Nutzen des Transmission Control Protocols (TCP).

Problem 1: Connection handling – TCP Slow start

Wie man hier sehen kann, muss eine Verbindung sehr lange aufrecht erhalten und verwendet werden, um eine hohe Durchsatzrate zu erreichen.

Problem 2: Unidirectional messaging – head of line blocking

Mit HTTP/1 kann nur eine Antwort pro Verbindungsanfrage beantwortet werden, keine anderen Anfragen (Requests) werden bearbeitet. Dies führt zu langsamen Ladezeiten von komplexen Webseiten.

Lösungen mit HTTP

Da die Probleme nicht von heute auf morgen auftraten bzw. deren Gewichtung mit der Zeit und Komplexität von Webseiten zunahm, wurden immer wieder Lösungen entwickelt. Diese Lösungen sind jedoch nicht nachhaltig, weswegen es zur Entwicklung von HTTP/2 kam.

Generell: Eine Webseite auszuliefern, wurde sehr kompliziert für Entwickler (nicht Server).

HTTP/2 Lösungsansatz

HTTP/2 wurde entwickelt, um die Komplexität auf Seiten der Entwickler zurück zur Software zu verschieben. So wurden für die bekannten Probleme technische Lösungen gefunden:

Wie Multiplexing und HPACK (header compression) funktionieren und was dies für Ladezeiten von Webseiten bedeutet, ist hier in der Präsentation zu finden.

Probleme der Lösungen

1. Transport Layer Security (TLS) – weitläufiger bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL) – ist obligatorisch.
Dadurch ergeben sich Folgeprobleme, wie z.B. dass für jede Domain ein valides Zertifikat vorliegen muss, redirects richtig gesetzt sind und 3rd Party Tools auch sicher eingebunden sind (Stichwort: Mixed Content).

2. Request Bursts
Ohne Inlining, Sprites und Bundles entstehen noch mehr Requests – die alle gleichzeitig eintreffen. Reverse Proxies wie z.B. Varnish helfen hier.

3. Verbindungsprobleme
Verbindungen brauchen eine lange Lebenszeit, verlorene Pakete haben großen Einfluss auf h2 Geschwindigkeit und h2 ist ansich nur für die “last mile”, also client-end.

4. TCP head-of-line blocking
Auch hier empfehle ich die Slides (Seite 30 bis 43) von Felix Hassert, da das Thema ausführlich untersucht wurde. Interessante Erkenntnisse, wie zum Beispiel, dass sich in einem WebPageTest Wasserfall-Diagramm bei der Nutzung von h2 dennoch ein h1-typisches Bild versteckt, ist hier zu finden, denn die meisten Ressourcen werden erst dann nutzbar, wenn sie vollständig geladen sind:

Inwiefern lohnt es sich also, aus End-Nutzersicht h2 einzusetzen?

97% der Desktop und Mobile Nutzer in Deutschland surfen mit einem HTTP/2-fähigen Gerät. Die Geschwindigkeitsvorteile bei einer Netzwerkverbindung besser als oder gleich 3G sind eindeutig, weswegen es empfehlenswert ist, den Schritt zur Nutzung von HTTP/2  zu gehen. 38% der Webseitenbetreiber nutzen die Vorteile von HTTP/2, bei Kunden von wao.io sind es 82%.

Worauf also noch warten? Hier kann man die eigene Website gratis mit HTTP/2 beschleunigen und sichern!

Zur Blog-Startseite