Seit einigen Jahren predige ich, dass Seiten zu langsam sind und man dadurch nicht nur Besucher sondern auch Google vergrault. Oft hört man ein einfaches ,,Aber sie lädt doch schnell genug, guck‘ mal“. Klar, mit einer Glasfaserleitung oder 4G in der Großstadt sind TTFB (Time to first byte) Werte von 800ms und die Gesamtladezeiten gerade noch erträglich, aber was passiert auf dem Land oder unterwegs mit Edge/GPRS?
Also, in dem Beitrag befasse ich mich ein wenig mit gängigen Tools, CDNs, Render Blocking CSS/JS sowie dem neuen HTTP/2 Protokoll. Später lest ihr hier etwas über Caching, Lazyload usw. Übersicht:
Ist Pagespeed ein Google Rankingfaktor?
Bereits im Jahre 2010 hat Google angekündigt, die Ladezeit als
Ranking Faktor mit in den Suchalgorithmus einfließen zu lassen. Daraufhin kam das Pagespeed Tool PageSpeed Insights, mit der ihr auf simple Art und Weise testen könnt, wie Google eure Seite bewertet. Vier Jahre später hat searchmetrics eine
Korrelation zwischen Position und guter Geschwindigkeit aufgezeigt. Mit damals 0,07 war die Korrelation zwar recht gering, aber da dieser Faktor unmittelbar Einfluss auf die Usability, also der Benutzbarkeit einer Seite, hat, wird der Pagespeed indirekt zu einem der einflussreichsten Faktoren bei der Suchmaschinenoptimierung.
Mit welchen Pagespeed-Tools du deine Homepage testen kannst
Für die Anfänger: Googles PageSpeed Insights
Das
Pagespeed Tool von Google hat zwar keinerlei Auswahlmöglichkeiten (was z.B. Standort angeht), dafür gibt der resultierende (Mobil)-Score einen guten und groben Einblick in Googles Bewertungssystem. Grob gesagt: Mit einem 80+ Score könnt ihr nicht allzu schlecht sein.
Darüber hinaus zeigt Google euch direkt Maßnahmen zur Optimierung (der häufigste Punkt wird wohl das Deferen von Javascript sein). Ganz nützlich ist die Liste der unkomprimierten Bilder, die ihr einfach durch z.B.
TinyPNG jagen könnt.
Ebenfalls für Anfänger: Pingdom
Hat ebenfalls bis auf den Standort nicht viele Konfigurationsmöglichkeiten, dafür ist es recht flott und zeigt einem eine recht simple Waterfall-Analyse des Ladevorgangs. Auch ganz praktisch ist die Anzeige der Anteilsverteilung von Requests / Gesamtgrößen (Content Breakdown). Ähnlich zu Googles Tool werden euch auch hier Optimierungsvorschläge wie Komprimierung oder Bildoptimierung angezeigt.
Link:
Pingdom Website Speed Test
Für die Fortgeschrittenen: GTmetrix
GTmetrix von gt.net verwendet u.A.
YSlow für die Pagespeed Analyse und liefert in der kostenlosen Version ähnliche Vorschläge wie Pingdom. Nach einer Registrierung gibt’s auch Timings und Videos vom Seitenaufbau. Leider wird hier nur mit einem Firefox Browser aus Canada getestet, womit man den lokalen Pagespeed (sofern man nicht gerade in Canade agiert) im Prinzip vergessen.
Für die lokalen Fortgeschrittenen: Chrome Entwicklertools
Die oft unterschätzte und vergessene Geheimwaffe aller SEOs sind die in den Chrome bereits eingebauten Developer Tools. Mit der Tastenkombi
STRG+Umschalt+i könnt ihr jede Seite auf’s tiefste prüfen. Neben dem HTML/CSS Inspector, gibt es den Reiter
Network, der für diesen Artikel hier von Relevanz ist.
Vorab gesagt: Ist eure Leitung mies oder ihr sitzt in Australien und testet eine Seite mit deutschem Serverstandort, bekommt ihr keine zuverlässigen Geschwindigkeitswerte. Testet ihr hingegen eine deutsche Seite aus Deutschland und habt auch noch eine gute Leitung, könnt ihr genauere Daten erhalten.
Interessant bei den Devtools ist, dass ihr eine
Mobile-Ansicht bekommt (einstellbar auf alle Größen) und noch eure Netzwerkgeschwindkeit drosseln könnt (EDGE, GPRS etc.). Auch seht ihr Sachen wie verwendete Protokolle (HTTP 1.1 / 2), Initiatoren von Dateien, Wasserfallanalysen, Statuscodes uvm.
Für die Experten: Webpagetest.org
Das wohl fortschrittlichste Tool ist
webpagetest.org. Hier werden im Advanced Testing Durchgang drei Tests hintereinander durchgeführt, die die Ladeperformance auf Herz und Nieren prüfen. Erwähnenswerte Features sind dabei:
- Standort-, Verbindungs-, Browser- und Gerätewahl
- Waterfall und Verbindungsanalyse
- Exakte Unterteilung von Before Render / Before on Load und After on Load
- Anzeige von CPU-, Bandbreiten- und Browserauslatung
- Bildanalyse (Komprimierung)
- Content Breakdown (ähnlich zu Pingdom)
- Auflistung aller Header
- Videos vom Ladeaufbau
Der Nachteil des Tools liegt vermutlich in der Unübersichtlichkeit, da man keine fancy Übersicht mit klaren Optimierungsvorschlägen bekommt. Für die Techies unter uns, die mit dem Datenbestand jedoch etwas anfangen können, ist es hingegen ein einziger Segen. Und das kostenlos.
Boosten auf höchstem Niveau: Ist ein CDN notwendig?
Mit einem CDN (Content Delivery/Distribution Network) kannst du deine Ressourcen auf Cloudservern auf der ganzen Welt verteilen und die Auslieferung vom nächstgelegenen Server gewährleisten.
Du hast nur eine kleine Seite und lieferst Inhalte dort aus, wo sich auch dein Server befindet
Dann brauchst du vermutlich kein CDN. Schande über mein Haupt, ich nutze auch kein CDN, aber ich fokusiere mich auch nicht auf den australischen oder japanischen Markt.
Mehrere Märkte, viel Volumen
Allein schon, wenn du Besucher aus Deutschland und den Vereinigten Staaten hast, wird es aufgrund der Serverlocation für dich schwer werden, einen soliden TTFB Wert zu garantieren. Dann heißt es: Entweder einen zweiten Server anschaffen oder über die Auslieferung durch ein CDN nachdenken.
Ob deine Werte im grünen Bereich liegen, kannst du einfach mit
keyCDNs Performance Tool testen. Wenn der Time to first Byte Wert über 400ms beträgt, hast du in diesem Land ein Problem und dadurch einen
Rankingnachteil gegenüber deiner Konkurrenz.
Komplex, aber wichtig: Rendering analysieren und Elemente nachladen
Stackoverflow und andere Foren sind voll mit Fragen, wie sie Googles Pagespeed Score auf 100/100 pushen können. Dabei sind die Aufgaben wie Bildoptimierung, Komprimierung und Antwortzeit meist noch einfach lösbar. Wobei die meisten dann doch verzweifeln ist folgendes:
JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten „above the fold“ (ohne Scrollen sichtbar) beseitigen
Googles Infoseite zur Lösung des Problems (
Link) ist mehr als spärlich und kratzt lediglich an der Oberfläche des Problems.
Dauerthema Javascript nachladen
Jede kleinste Seite nutzt heute meist ein Framework wie Bootstrap oder Foundation welches für die eigene Javascript Library jQuery voraussetzt. Hier ein kleines Beispiel der Ladegrößen, die geladen werden müssen um die beiden Frameworks nutzen zu können:
| Foundation 6.3.1 |
121kB Foundation + 252kB jQuery.js = 373kB |
| Bootstrap 3.3.7 |
37kB Bootstrap + jQuery 95kB = 132kB |
Lädt man nun diese Ressourcen nicht nach, muss der Browser nach dem Laden des bodys diese Menge herunterladen. Die Frage, die sich Google dabei zurecht stellt, ist: Braucht man 100-300kB Javascript um dem User den ersten Screen anzuzeigen?
Meist lautet die Antwort:
Nein – Deswegen sollte man sich auf folgenden, magischen Begriff konzentieren:
Above the fold – Sichtbare Inhalte priorisieren und Critical CSS definieren
Ich kann’s nicht oft genug wiederholen: Besucher glücklich, Google glücklich. Deswegen ist Googles Optimierungsvorschlag mit den renderblockenden Elementen keine Foltermaßnahme des Unternehmens sondern tatsächlich eine für den Nutzer relevante Angelegenheit.
Warum muss der Besucher eine ganze Seite, inklusive Scriptmist und Bildern, die 4000px weiter unten erscheinen, laden, wenn sein Viewport zunächst nur 360x560px anzeigen kann? Genau, ist Unsinn. Also geht man wie folgt vor (simple Veranschaulichung):
- Man schaut sich die Seite in verschiedenen Viewports an (Easy going)
- Nun entscheidet man anhand dessen, was man ohne Gescrolle sieht, welche Elemente zu priorisieren sind und schaut, in welchen Dateien diese angesprochen werden (Puh, schon schwieriger)
- Den Code der priorisierten Elemente (CSS, JS) verschiebt man in den HTML Quellcode, damit diese mit dem DOM geladen werden (Holy Shit!)
- Den Rest lädt man nach
Die Lösung: HTTP/2
Das Hypertext Transfer Protocol (HTTP) in der Version 1.1 ist nun seit 18 Jahren der herrschende Webstandard. Wird langsam mal Zeit, diesen etwas aufzufrischen.
HTTP/2 heißt der Nachfolger und unterstützt u.A.
Multiplexing und
Server Push.
Warum ist das die Lösung?
Ganz einfach: Die Problematik mit dem kritischem CSS und dem ganzen sequentiellen und späterem Laden von Ressourcen sind auf die Beschränkungen von HTTP 1.1 zurückzuführen. Googles
SPDY legte im Jahr 2012 den Grundstein für HTTP/2 und mittlerweile kann man durch Verwendung des neuen Protokolls schon
beinahe auf die oben genannten Maßnahmen verzichten. Nichtsdestotrotz hat man nach wie vor Probleme, den Pagespeed ohne CDN auf internationaler Ebene schnell genug zu halten.
Wer oder was unterstützt das HTTP/2 Protokoll?
Da die modernen Browser das neue Protokoll nur in Verbindung mit einem SSL Zertifikat unterstützen, solltet ihr so oder so auf HTTPS umsteigen. Wenn man auf der Seite mit Kundendaten hantiert (Registrierungen, Bestellung etc.), ist eine HTTPS Seite nicht nur aus Nutzersicht ein Vertrauenssignal, sondern auch aus der von Google. Denn seit gut drei Jahren zählt ein SSL Zertifikat zu einem (wenn auch schwachen) Ranking Faktor.
Solltet ihr auf HTTP/2 umsteigen und der Browser eurer Besucher unterstützt das Ganze nicht, sorgt euch nicht, dann nutzt der Browser nämlich einfach wieder das alte 1.1 Protokoll.
Warum HTTP/2 schneller ist
Bei HTTP 1.1 hat der Browser für jeden Request eine eigene TCP Verbindung aufbauen müssen. Resultat davon waren die klassischen Wasserfälle, die man beim Laden aus der Dev-Console oder von den oben genannten Speedtools kennt. Bei zu vielen Dateien lädt der Browser diese nur sequentiell anstatt gleichzeitig. Das neue Protokoll kann jedoch mit nur
einer einzigen TCP Verbindung alle Daten parallel übertragen (genannt Multiplexing). Einen keinen Geschwindigkeitsvergleich zwischen dem alten und dem neuen Protokoll könnt ihr hier testen:
Akamai HTTP/2 Demo
Lesenswertes zum Thema
Fazit?
Bei mir bestanden nie wirklich Zweifel, ob Pagespeed für Google relevant ist oder nicht. Ein top Pagespeed ist nach wie vor für alle ein erstrebenswertes Unterfangen. Deswegen: Steigt auf HTTP/2 um, nutzt (wenn nötig) CDNs und lasst eure Besucher nicht mehr warten. Wenn ihr unbedingt einen Google Pagespeed Score von 100 haben wollt, müsst ihr natürlich etwas mehr Aufwand reinstecken. Aber seid gewarnt: Spätestens beim 99/100, wenn die
eigene Google Analytics.js Datei ein Cachingproblem anzeigt, wird’s spaßig für euch.
Bald gibt’s hier noch etwas über Caching zu lesen, aber das reicht für’s Erste.
Chenqui!
Teilen 