Performance-Optimierungen: Die Trends 2019
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, sowohl als Unternehmen als auch
in Form von Mitarbeitern wie Ilya Grigorik, seines Zeichens Web-Performance-Koryphäe der ersten Stunde. Und das selbstverständlich nicht uneigennützig, denn schnelle Webseiten machen auch Googles Infrastruktur (Crawling & Co.) 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 (sprich kleinere Dateigröße bei vergleichbarer Qualität).
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, sowohl als Unternehmen als auch
in Form von Mitarbeitern wie Ilya Grigorik, seines Zeichens Web-Performance-Koryphäe der ersten Stunde. Und das selbstverständlich nicht uneigennützig, denn schnelle Webseiten machen auch Googles Infrastruktur (Crawling & Co.) 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 (sprich kleinere Dateigröße bei vergleichbarer Qualität).
Das Problem bei WebP ist 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 der 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.
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.
Spätestens seit Google im Chrome Browser sowohl nicht sichere Form-Fields bei der Eingabe als „unsicher“ markiert als auch in der Browserzeile ein entsprechender Hinweis auftaucht, sollte jeder Seitenbetreiber das Thema HTTPS auf der Agenda haben. Aktuelle Zahlen von Searchmetrics zeigen, dass rund 45 Prozent der Top Ten Ergebnisse bereits via HTTPS ausgeliefert werden - Tendenz steigend.
Dies wirkt sich insbesondere auf die On-Site-Conversion aus, wenn entsprechende Conversion-Elemente eine Benutzereingabe verlangen. Weiterhin scheint es durchaus denkbar, dass Google perspektivisch auch entsprechende Hinweise zu nicht sicheren URLs direkt auf der Suchergebnisseite anzeigt, was sich mit Sicherheit negativ auf die SERP CTR auswirken würde.
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.
Dies wirkt sich insbesondere auf die On-Site-Conversion aus, wenn entsprechende Conversion-Elemente eine Benutzereingabe verlangen. Weiterhin scheint es durchaus denkbar, dass Google perspektivisch auch entsprechende Hinweise zu nicht sicheren URLs direkt auf der Suchergebnisseite anzeigt, was sich mit Sicherheit negativ auf die SERP CTR auswirken würde.
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.
Performance Extreme: Optimierung des Critical Path Renderings
Viele Optimierungen sind heutzutage absolute Must-Have‘s und bedürfen (eigentlich) gar keiner Diskussion. Spielt Ladegeschwindigkeit eine Rolle (und das sollte nunmehr für jede Webseite der Fall sein), 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, Bilder in verschiedenen Größen auszuliefern oder gar das DOM (Document Object Model) entsprechend aufzuräumen.
In diesem Sinne: Happy Optimizing!
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, Bilder in verschiedenen Größen auszuliefern oder gar das DOM (Document Object Model) entsprechend aufzuräumen.
In diesem Sinne: Happy Optimizing!
Zum Autor
Bastian Grimm (Vorstand & Director Organic Search, Peak Ace AG) verantwortet als Director Organic Search bei der Peak Ace AG die Bereiche Suchmaschinenoptimierung sowie Performance Content Marketing und blickt dabei auf mehr als fünfzehn Jahre Erfahrung im Online Marketing zurück.
Die Peak Ace AG ist eine 2008 gegründete, international tätige Performance Marketing Agentur mit Sitz in Berlin. Mit mehr als 60 Mitarbeitern realisiert sie Kampagnen in bis zu 20 Sprachen auf Muttersprachlerniveau und gehört zu den am schnellsten wachsenden Technologieunternehmen Deutschlands.
Die Peak Ace AG ist eine 2008 gegründete, international tätige Performance Marketing Agentur mit Sitz in Berlin. Mit mehr als 60 Mitarbeitern realisiert sie Kampagnen in bis zu 20 Sprachen auf Muttersprachlerniveau und gehört zu den am schnellsten wachsenden Technologieunternehmen Deutschlands.