Trends der Website Performance-Optimierung
© Peak Ace AG
Schnelle Webseiten sind wichtiger denn je. Laut einer aktuellen Nielsen-Studie ist die Erwartungshaltung klar: 40 Prozent aller Besucher verlassen eine Webseite, wenn diese nicht innerhalb von drei Sekunden lädt. Wir werfen daher einen Blick auf aktuelle Themen der Performance-Optimierung.
Neue Bildformate braucht das Web!
Bereits heute werden mehr als 60 Prozent des Traffics im World Wide Web durch Bilder verursacht, vor allem durch Formate wie JPEG, PNG und GIF. Nun sind aber all diese Dateiformate relativ alt und nicht immer wirklich effizient. Dennoch sind sie, aufgrund der Kompatibilität und teils auch wegen ihrer uniquen Features, wie Transparenz bei PNGs, meist alternativlos.
Google ist stets bemüht, den nächsten Schritt zu gehen und mit neuen Ansätzen für Innovation und schneller ladende Seiten zu sorgen. Und das selbstverständlich nicht uneigennützig, denn schnelle Webseiten machen auch Googles das Leben leichter! So wundert es auch wenig, dass Google bereits vor einigen Jahren ein neues Bildformat vorgestellt hat, was auf den Namen WebP hört. Es vereint alle Vorteile der vorgenannten, „alten“ Dateiformate, ist aber insgesamt deutlich effektiver.
Das Problem bei WebP ist weiterhin die insgesamt schwache Adaptionsrate – so wird das Format aktuell nur von Chrome, Opera und dem Android Webbrowser unterstützt. Auch zur Anzeige unter Windows ist ein extra Viewer notwendig, was nicht optimal ist.
Dennoch lässt sich WebP nutzen, beispielsweise über serverseitiges On-the-Fly Replacement (hier beschrieben) - bei entsprechender Unterstützung durch den Browser (und den Accept-Header image/webp).
Als Alternative – und viel einfacher umsetzbar – veröffentlichte Google im März 2017 einen neuen JPEG-Encoder mit dem Namen „Guetzli“. Die Vorteile liegen auf der Hand: Guetzli schafft es zum einen, bestehende und bereits optimierte JPEG-Bilder noch einmal um 35 Prozent zu verkleinern, ohne Qualitätseinbußen in Kauf zu nehmen, und zum anderen muss sich der Anwender sowie Webseitenbetreiber keinerlei Gedanken über Kompatibilität machen. JPEGs sind de facto Standard und funktionieren überall. Insbesondere, wer bildlastige Webseiten betreibt, sollte sich Guetzli genauer anschauen!
HTTPS und HTTP/2 – ein längst überfälliges Protokollupdate
Seit dem Release des aktuellen HTTP/1.1-Standards Ende der 90er Jahre hat sich am eigentlichen HTTP-Protokoll wenig getan. Verglichen mit der Tatsache, wie schnelllebig das Internet und zugehörige Technologien sonst sind, scheint das eher verwunderlich. Auch hier gehörte Google wieder einmal zu den treibenden Kräften und forcierte mit „SPDY“ die deutlich schnellere Entwicklung eines neuen Standards, der schlussendlich in Teilen als „Vorlage“ für HTTP/2 diente.
Mit HTTP/2 wird ebenfalls dafür gesorgt, dass die signifikant gestiegene Anzahl von Dateien pro Webseitenaufruf, und damit auch das deutlich größere Datentransfervolumen, weiterhin performant bewältigt werden kann. Da sich die Browserhersteller einstimmig darauf geeinigt haben, HTTP/2-Verbindungen nur für gesicherte Verbindungen (aka HTTPS) zu erlauben, steht der Verwendung des neuen Protokolls in jedem Fall auch eine entsprechende HTTPS-Migration bevor, insofern besagte Webseite noch nicht auf HTTPS betrieben wird. HTTP/2 selbst lässt sich dann relativ einfach implementieren, wenn die Webserver auf aktuellen Unix-Distributionen betrieben werden. Ein Fallback-Mechanismus sorgt zudem dafür, dass Endgeräte, die (noch) kein HTTP/2 unterstützen, die jeweilige Webseite weiterhin problemlos ausliefern können.
HTTPS-Migrationen sind alles andere als trivial – ein checklistenmäßiges Vorgehen und ein Vier-Augen-Prinzip, idealerweise mit einem Sparringpartner, der bereits erfolgreiche HTTPS-Migrationen durchgeführt hat, sind zwingend notwendig. Dabei kann diese Checkliste hilfreich sein. Denken Sie aber unbedingt daran, nicht nur HTTPS zu briefen, sondern direkt abzufordern, auch auf HTTP/2 zu wechseln. Denn HTTPS auf dem „alten“ Protokoll ist in jedem Fall langsamer, primär bedingt durch den Overhead der Zertifikatsvalidierung.
Die Optimierung des Critical Path Renderings
Viele Optimierungen sind heutzutage absolute Must-Have‘s und bedürfen (eigentlich) gar keiner Diskussion. Spielt Ladegeschwindigkeit eine Rolle, habe ich beispielsweise gar keine andere Wahl, als mich damit auseinanderzusetzen, wie viel JavaScript ich wo und wann lade. Genauso kümmere ich mich um effizientes Caching sowie durchoptimierte Bilder.
Die gesonderte Optimierung des Critical Path Renderings ist ein komplexes, aufwendiges Thema, dem (leider) häufig noch zu wenig Aufmerksamkeit geschenkt wird. Gemeint ist hier der direkt sichtbare Bereich (ohne zu scrollen) – abhängig von der jeweiligen Auflösung des Endgerätes, mit dem auf die Seite zugegriffen wird.
Google selbst empfiehlt dabei, das Mark-Up so zu strukturieren, dass direkt sichtbare Elemente, wie das Logo, sofort geladen werden und alles andere bei entsprechender (Scroll-) Interaktion nachgeladen wird. Das klingt erst einmal relativ einfach, die Praxis schaut aber in der Regel anders aus. Das größte Augenmerk sollte hier bei der Verwendung des CSS liegen, denn selbiges ist maßgeblich für die Darstellung verantwortlich. Einen hervorragenden Einstieg gibt es hier – dort wird detailliert beschrieben, wie mit vergleichsweise überschaubarem Aufwand herauszufinden ist, für welche Auflösung welche CSS-Anweisungen notwendig sind. Damit bewaffnet teilt man das CSS in zwei Blöcke: Alle relevanten Notationen für den Critical Path werden zukünftig als Inline-CSS direkt in die Seite eingebunden (damit wird der zusätzliche http-Request vollständig eingespart) und alle CSS-Notationen für den nicht sichtbaren Bereich werden asynchron nachgeladen. Selbstredend geht auch hier noch deutlich mehr – so wäre es im Sinne einer wirklich guten, komplett responsiven Seite auch wichtig, z. B. Bilder in verschiedenen Größen auszuliefern.
Neue Bildformate braucht das Web!
Bereits heute werden mehr als 60 Prozent des Traffics im World Wide Web durch Bilder verursacht, vor allem durch Formate wie JPEG, PNG und GIF. Nun sind aber all diese Dateiformate relativ alt und nicht immer wirklich effizient. Dennoch sind sie, aufgrund der Kompatibilität und teils auch wegen ihrer uniquen Features, wie Transparenz bei PNGs, meist alternativlos.
Google ist stets bemüht, den nächsten Schritt zu gehen und mit neuen Ansätzen für Innovation und schneller ladende Seiten zu sorgen. Und das selbstverständlich nicht uneigennützig, denn schnelle Webseiten machen auch Googles das Leben leichter! So wundert es auch wenig, dass Google bereits vor einigen Jahren ein neues Bildformat vorgestellt hat, was auf den Namen WebP hört. Es vereint alle Vorteile der vorgenannten, „alten“ Dateiformate, ist aber insgesamt deutlich effektiver.
Das Problem bei WebP ist weiterhin die insgesamt schwache Adaptionsrate – so wird das Format aktuell nur von Chrome, Opera und dem Android Webbrowser unterstützt. Auch zur Anzeige unter Windows ist ein extra Viewer notwendig, was nicht optimal ist.
Dennoch lässt sich WebP nutzen, beispielsweise über serverseitiges On-the-Fly Replacement (hier beschrieben) - bei entsprechender Unterstützung durch den Browser (und den Accept-Header image/webp).
Als Alternative – und viel einfacher umsetzbar – veröffentlichte Google im März 2017 einen neuen JPEG-Encoder mit dem Namen „Guetzli“. Die Vorteile liegen auf der Hand: Guetzli schafft es zum einen, bestehende und bereits optimierte JPEG-Bilder noch einmal um 35 Prozent zu verkleinern, ohne Qualitätseinbußen in Kauf zu nehmen, und zum anderen muss sich der Anwender sowie Webseitenbetreiber keinerlei Gedanken über Kompatibilität machen. JPEGs sind de facto Standard und funktionieren überall. Insbesondere, wer bildlastige Webseiten betreibt, sollte sich Guetzli genauer anschauen!
HTTPS und HTTP/2 – ein längst überfälliges Protokollupdate
Seit dem Release des aktuellen HTTP/1.1-Standards Ende der 90er Jahre hat sich am eigentlichen HTTP-Protokoll wenig getan. Verglichen mit der Tatsache, wie schnelllebig das Internet und zugehörige Technologien sonst sind, scheint das eher verwunderlich. Auch hier gehörte Google wieder einmal zu den treibenden Kräften und forcierte mit „SPDY“ die deutlich schnellere Entwicklung eines neuen Standards, der schlussendlich in Teilen als „Vorlage“ für HTTP/2 diente.
Mit HTTP/2 wird ebenfalls dafür gesorgt, dass die signifikant gestiegene Anzahl von Dateien pro Webseitenaufruf, und damit auch das deutlich größere Datentransfervolumen, weiterhin performant bewältigt werden kann. Da sich die Browserhersteller einstimmig darauf geeinigt haben, HTTP/2-Verbindungen nur für gesicherte Verbindungen (aka HTTPS) zu erlauben, steht der Verwendung des neuen Protokolls in jedem Fall auch eine entsprechende HTTPS-Migration bevor, insofern besagte Webseite noch nicht auf HTTPS betrieben wird. HTTP/2 selbst lässt sich dann relativ einfach implementieren, wenn die Webserver auf aktuellen Unix-Distributionen betrieben werden. Ein Fallback-Mechanismus sorgt zudem dafür, dass Endgeräte, die (noch) kein HTTP/2 unterstützen, die jeweilige Webseite weiterhin problemlos ausliefern können.
HTTPS-Migrationen sind alles andere als trivial – ein checklistenmäßiges Vorgehen und ein Vier-Augen-Prinzip, idealerweise mit einem Sparringpartner, der bereits erfolgreiche HTTPS-Migrationen durchgeführt hat, sind zwingend notwendig. Dabei kann diese Checkliste hilfreich sein. Denken Sie aber unbedingt daran, nicht nur HTTPS zu briefen, sondern direkt abzufordern, auch auf HTTP/2 zu wechseln. Denn HTTPS auf dem „alten“ Protokoll ist in jedem Fall langsamer, primär bedingt durch den Overhead der Zertifikatsvalidierung.
Die Optimierung des Critical Path Renderings
Viele Optimierungen sind heutzutage absolute Must-Have‘s und bedürfen (eigentlich) gar keiner Diskussion. Spielt Ladegeschwindigkeit eine Rolle, habe ich beispielsweise gar keine andere Wahl, als mich damit auseinanderzusetzen, wie viel JavaScript ich wo und wann lade. Genauso kümmere ich mich um effizientes Caching sowie durchoptimierte Bilder.
Die gesonderte Optimierung des Critical Path Renderings ist ein komplexes, aufwendiges Thema, dem (leider) häufig noch zu wenig Aufmerksamkeit geschenkt wird. Gemeint ist hier der direkt sichtbare Bereich (ohne zu scrollen) – abhängig von der jeweiligen Auflösung des Endgerätes, mit dem auf die Seite zugegriffen wird.
Google selbst empfiehlt dabei, das Mark-Up so zu strukturieren, dass direkt sichtbare Elemente, wie das Logo, sofort geladen werden und alles andere bei entsprechender (Scroll-) Interaktion nachgeladen wird. Das klingt erst einmal relativ einfach, die Praxis schaut aber in der Regel anders aus. Das größte Augenmerk sollte hier bei der Verwendung des CSS liegen, denn selbiges ist maßgeblich für die Darstellung verantwortlich. Einen hervorragenden Einstieg gibt es hier – dort wird detailliert beschrieben, wie mit vergleichsweise überschaubarem Aufwand herauszufinden ist, für welche Auflösung welche CSS-Anweisungen notwendig sind. Damit bewaffnet teilt man das CSS in zwei Blöcke: Alle relevanten Notationen für den Critical Path werden zukünftig als Inline-CSS direkt in die Seite eingebunden (damit wird der zusätzliche http-Request vollständig eingespart) und alle CSS-Notationen für den nicht sichtbaren Bereich werden asynchron nachgeladen. Selbstredend geht auch hier noch deutlich mehr – so wäre es im Sinne einer wirklich guten, komplett responsiven Seite auch wichtig, z. B. Bilder in verschiedenen Größen auszuliefern.