Bastian Heynen Online Marketing
Online Marketing Manager

Google will mehr Speed – So werden Websites schneller


Ein schnelleres Netz hält mehr Menschen im Internet und bringt sie dazu, mehr Seiten anzuklicken. Je mehr Menschen Zeit im Internet verbringen, desto mehr Umsatz werden sie ultimativ auch für Google generieren. Schließlich werden sie früher oder später auf eine Display-Anzeige oder Ähnliches klicken. Dies ist der Grund für Googles Speed-Besessenheit.


2017 – Jahr des Mobile-First-Index, Jahr der Speed-Besessenheit

Von Google Chrome, über die Highspeed-Internetlösung Google Fiber, bis zum selbstfahrenden Auto – damit man nicht nur an Kreuzungen mit Ampel ins Internet geht (ja, Google hat hierzu Daten) – alles bei Google dient dazu die Menschen häufiger ins Internet zu bringen und sie dort dauerhafter zu halten. Aus diesem Grund ist es nicht verwunderlich, dass die Geschwindigkeit einer Seite höchstwahrscheinlich eine Rolle für das Ranking spielt.*

Im Jahr 2017 wird bei Google der Mobile Index zum Standard-Index. Dies wird für Firmen und Organisationen ohne mobil-optimierte Seiten unangenehme Folgen haben. Bereits 2016 haben wir negative SEO-Auswirkungen auf non-mobile Sites feststellen können.

Sind aber alle notwendigen UX- und Design-Bedingungen für Mobile erfüllt, sollte die Seite generell schneller gemacht werden. Doch was heißt „schnell“? Eine Gesamtladezeit unter 2 Sekunden ist für durchschnittliche Seiten ein gutes Ziel. Aber schneller ist noch besser. Natürlich gibt es bei stärker auf außergewöhnliches Design abzielenden Webseiten mit enormer Bilddichte immer Trade-Offs, die man in punkto Geschwindigkeit eingehen muss. Zielt man auf ein gutes Ranking ab, sollten diese aber nicht überwiegen.

In punkto Geschwindigkeit gibt es einige Schrauben, an denen man aus SEO- und UX-Sicht drehen kann:


First Byte Time

Die First Byte Time ist eine wichtige Kennzahl für eine Webseite. Hierbei handelt es sich um die Zeit, die man zum Laden des ersten Bytes benötigt (Back-End Processing + Redirects). Hier zählt auch die geographische Nähe: Stellt also sicher, dass ihr die First Byte Time von dort aus testet, wo sich eure Nutzer befinden und nicht immer nur von eurem Standort oder aus Australien, wenn eure wichtigsten Kunden aber in Belgien sitzen.

Es gibt zwar keinen definitiven Beweis für den Effekt auf das Ranking bei Google, sehr wohl aber eine Korrelation zwischen gutem Ranking und der First Byte Time.* Ihr solltet hier 500 ms oder weniger anstreben. Idealerweise erreicht ihr einen Wert unter 300 ms.

Wie? Sorgt dafür, dass ihr ein gutes Hosting habt. Wenn ihr weit vom Kunden entfernt seid, solltet ihr über ein Content Delivery Network (CDN) nachdenken. Mehr dazu gibt es hier.

Vermeidet auf jeden Fall endlose Redirect-Schleifen! Diese spielen in die First Byte Time mit rein.


Server Requests und Minifizierung

Jede einzelne Datei stellt einen Request an den Server dar. CSS und JS kann man aber oft zusammenfassen, so kann man die Anzahl der Dateien insgesamt deutlich reduzieren. Prüft also zunächst, ob ihr überhaupt viele veschiedene Dateien braucht. Was ist die Anzahl der Server Requests? Kann man diese reduzieren?

Habt ihr das getan, so könnt ihr die verbliebenen Dateien minifizieren. Google empfiehlt den YUI Compressor für CSS und JavaScript. Was dieser genau macht könnt ihr hier nachlesen.


Keep Alive Enabled

Enabled Keep Alive, damit mehrere Files auf einmal heruntergeladen werden können. Habt ihr dies nicht sichergestellt, wird für jede Datei eine neue Verbindung zwischen Server und Client aufgebaut. Dies führt zu längeren Ladezeiten und sollte deswegen vermieden werden.


Komprimierung von Transfer: GZIP

Benutzt auf jeden Fall GZIP für HTML, CSS und JavaScript über 150 Bytes. GZIP sorgt für die Komprimierung der Daten, die dann vom Browser wieder entpackt werden.

Wenn ihr tiefer in die Materie eintauchen wollt, lest diesen Beitrag von Infinite Partitions über den DEFLATE Algorithmus, der GZIP zugrunde liegt.

In naher Zukunft dürfen wir uns sicher über den vermehrten Einsatz von Brotli freuen.


Komprimierung von Bildern

Komprimiert die Bilder, damit sie web-tauglich sind. Oft habe ich beim Stöbern im Netz auf eigentlich sehr guten Seiten schon einzelne Pages mit Bildern über 1 MB gefunden. Das ist ein absolutes No-Go, denn solche Bilder lassen sich meist ohne Qualitätsverlust ganz einfach herunterrechnen.

Wenn ihr kein Photoshop habt, dann benutzt Seiten wie compressjpg.com. Bei Photoshop reicht oft eine Qualität von 50. Tastet euch sonst in kleinen Schritten langsam nach oben bis ihr ein akzeptables Niveau bei Qualität und Größe erreicht habt.

Hier mal ein und dasselbe Bild (links nicht optimiert mit 84 KB, rechts nach Optimierung mit compressjpg auf 42 KB):

Nicht-optimiertes BildOptimiertes Bild mit compressjpg

Hier handelt es sich nur um ein sehr kleines Bild. Bei einer Webseite mit vielen und großen Bildern können die Unterschiede zwischen Komprimierung und Nicht-Komprimierung deutlich dramatischer sein.

Denkt auch daran: Ihr könnt kleinere Images auch in CSS Sprites kombinieren.


Cache von statischem Content

Fügt eurem Content einen Expire Header hinzu. Dieser macht dem Browser klar, dass der Content für eine gewisse Zeit im Cache gespeichert werden kann, bevor er wieder beim Server neuere Versionen anfragen muss. Somit muss der Content nicht jedes mal neu geladen werden. Überlegt euch genau, welche Zeiten hier angebracht sind. Google empfiehlt mindestens eine Woche (das sind 10080 Minuten, 604800 Sekunden).

Zum Schluss: Da ihr auch eine gute Mobile Experience garantieren wollt, ruft doch einmal die Webseite mit Drosselung auf Regular 3G auf (In Chrome: F12 -> Network -> Throttling). Wie würdet ihr euch fühlen als Smartphone- oder Tablet-Nutzer? Zufrieden? Oder geht da noch mehr? Denkt daran, dass es mobil nicht nur um Ladezeiten allein, sondern durchaus auch um MB-Zahlen geht (in Deutschland drehen Mobilfunkanbieter sehr schnell den Hahn zu).

 

 

* Korrelationen zwischen Metriken und Rankings bei Google

Kommentare
1

Hans Jung

Hallo Bastian, hier fehlen mir noch die Punkte HTTP/2 (setzt https voraus) und .webp (https://github.com/sergejmueller/sergejmueller.github.io/wiki/WebP:-JPEG-Nachfolger). Gerade bei den von dir angesprochenen Seiten mit zahlreichen Bildern, mehreren CSS und JS Files, bietet HTTP/2 einen deutlichen Geschwindigkeitsvorteil. Und mit .webp als alternatives Bildformat für kompatible Browser, werden die Ladezeiten (u.a. auf Android-Geräten) merklich verkürzt. Viele Grüße Hans

am 01.12.2016

2

Bastian Heynen

Hallo Hans, danke für die Ergänzung. :) Wir hatten kurz überlegt HTTP/2 mit aufzunehmen. Wir wollten möglichst für alle einfach umsetzbare Schritte aufzeigen. Und das große Fass IE wollten wir nicht aufmachen ;) Viele Grüße aus dem Kern, Bastian

am 01.12.2016

Kommentar hinzufügen
Vor und Zuname
E-Mail
E-Mail bei weiteren Kommentaren
Mein Kommentar