Deine langsamen Seiten hindern Dich am Geld verdienen!
Das ist zwar etwas überspitzt formuliert, aber schlechte Performance hat tatsächlich direkten Einfluss auf Konversionsraten und damit auch auf Deinen Umsatz. Denn Page Performance ist, als Google Rankingfaktor, nicht nur ein wichtiger Baustein im SEO, sondern auch großer Bestandteil der User Experience.
Lange Ladezeiten können Nutzer frustrieren und schlussendlich Konversionen kosten.
In einer viel zitierten Google Studie wird beschrieben, dass die Wahrscheinlichkeit eines Bounces um 90% steigt, wenn sich die Ladezeit von 1 Sekunde auf 5 Sekunden erhöht.
Verschaffe Dir deshalb in diesem Artikel einen Überblick über Page Performance und darüber, was Du tun kannst, um größere Probleme zu vermeiden.
Page Performance und Google
Die letzten Algorithmus-Updates des Suchmaschinen-Konzerns lassen vermuten, dass Performance Themen zukünftig noch wichtiger werden.
Von Juni bis August 2021 wurde beispielsweise das Page Experience Update ausgerollt, welches die neuen Rankingfaktoren Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) und First Input Delay (FID) einführte.
Diese lassen sich grob wie folgt erklären:
LCP
Dauer, bis das größte Element im initialen Viewport (First View) gerendert wurde.
CLS
Stabilität des Layouts einer Website während dem Ladevorgang.
FID
Dauer zwischen der ersten User Interaktion (z.B.: Klick) und der tatsächlichen Reaktion der Webseite.
Zusätzlich wurden erst im November 2021 zwei weitere KPIs vorgestellt, die dieses Set bald erweitern sollen – Smoothness und Responsiveness.
Das bestehende Set an Messwerten wird aber nicht nur regelmäßig erweitert sondern auch die Gewichtung der einzelnen Kennzahlen für Rankingprozesse angepasst.
Hier gut erkennbar an der Zusammensetzung des Google Performance Scores (= gewichteter Wert aller von Google zum Ranking herangezogenen Performance Metriken) vor und nach dem Page Experience Update:
Um bei Veränderungen schnell reagieren zu können, sollte man hier also seine Hausaufgaben machen, um bei Updates im besten Fall nur noch nachjustieren zu müssen.
Es gibt zwar auch Beispiele von Nachrichten-Portalen oder Online-Shops, die trotz schlechter Performance hohe Umsätze erzielen, aber mit fortschreitender Professionalisierung des Wettbewerbs und direkt optimierter Content-Management-Systeme wie Shopify könnte sich dies zukünftig ändern.
Zusammengefasst: Google und Nutzern ist Pagespeed wichtig, deshalb sollte man zumindest nicht schlechter als die Konkurrenz abschneiden um relevant und auffindbar zu bleiben.
Wie finde ich heraus, wie meine Webseite performt?
Heutzutage gibt es diverse Tools, welche versuchen, diese Frage so gut wie möglich zu beantworten. Hier möchte ich auf drei kostenfreie Analyse-Tools detaillierter eingehen, um Dir zu zeigen, wie Du eine initiale Performance-Bestandsaufnahme durchführen kannst.
1. Google Search Console (GSC)
Diese Tools verwenden teilweise verschiedene Datenquellen, weshalb es wichtig ist, vorher eine Differenzierung vorzunehmen:
| Felddaten | Labordaten |
| ● Anonymisierte, reale Nutzerdaten.
● Die Messung hängt von einer Vielzahl von Variablen ab (z.B. Browser, Gerät etc.) ● Bietet sich zur Erfolgsmessung von Maßnahmen an. |
● Simulierte Daten aus Tests mit bestimmten Geräten und mit vordefinierter Internetgeschwindigkeit.
● Messdaten aus einer kontrollierten Umgebung ● Bieten sich als Grundlage für Verbesserungen an. |
Durch Labortests lässt sich die korrekte Implementierung von Optimierungsmaßnahmen kurzfristig feststellen.
Felddaten sollten diese Maßnahmen dann durch langfristige Verbesserungen bei den Nutzerdaten widerspiegeln.
1. Google Search Console (GSC)
Die Google Search Console ist ein machtvolles Tool im Umgang mit Google und eine wertvolle Unterstützung bei der Performance-Optimierung.
Sie kann als erste Anlaufstelle – um den Zustand der eigenen Domain zu beurteilen – dienen.
| Praktisch: | Hier sieht man u.a., welche URLs Google als kritisch hinsichtlich der Core Web Vitals (CWV) betrachtet. |
| Achtung: | In diesem Performance-Bericht liegen nur Werte für URLs vor, zu denen Google genügend User-Daten in Chrome sammeln konnte (Felddaten). Heißt: nicht zu jeder URL liegen Ergebnisse vor. |
| Tipp: | Wurden Performance Verbesserungen durchgeführt, lässt sich hier anschließend eine Validierung bei Google beantragen. |
Im “Experience-tab” unter “Core Web Vitals” können die Messwerte eingesehen werden:
- Sind hier alle Daten im grünen Bereich, können Performance Maßnahmen depriorisiert werden.
- Im vorliegenden Beispiel sollten jedoch Kapazitäten für umfangreiche Optimierungen aufgewendet werden. Ansonsten können Rankingverluste die Folge sein und Positionen an die besser performende Konkurrenz übergehen.
Mehr als einen groben Überblick über die betroffenen Seiten erhältst Du hier jedoch leider nicht. Um die technischen Probleme zu identifizieren und tiefer in die Analyse gehen zu können, benötigst Du weitere Tools.
2. Lighthouse
Lighthouse ist ein von Google bereitgestelltes Tool, um einfach und schnell den Optimierungsstand einzelner URLs abzufragen.
| Praktisch: | Zu jedem identifizierten Problem bietet Google direkt Lösungsvorschläge an. |
| Achtung: | ● Hier wird in einer kontrollierten Testumgebung gemessen (Labdaten).
● Da der Test über den Browser läuft, haben Variablen wie Internetverbindung und Device Einfluss auf das Ergebnis! ● Zwischen mobilen und desktop Testdaten können teils gravierende Unterschiede bestehen → Da Google per default die mobile Version einer Webseite zum Ranking heranzieht, ergibt es Sinn, sich diese näher anzuschauen. |
| Tipp: | Schaut nach, mit welchem Endgerät eure Zielgruppe eure Domain hauptsächlich besucht (in Google Search Console oder Google Analytics). Dort haben Optimierungen die größten Auswirkungen auf die UX. |
Ein Lighthouse Audit kann entweder per Chrome Addon oder per Chrome Developer Tools durchgeführt werden.
In diesem Beispiel verwende ich die Chrome Dev-Tools und erhalte folgenden Bericht:
- Hier siehst Du die in der Testumgebung gemessenen Kennzahlen und wie diese von Google eingeschätzt werden: Grün („Good“), Orange („Needs Improvement“), Rot („Poor“).
- Der prominente Performance Score ganz oben ist ein konsolidierter, gewichteter Wert bestehend aus von Google zum Ranking herangezogenen Performance Indikatoren.
Scrollt man weiter nach unten, findet man den Opportunities-Bericht. Hier gibt Google direkt Empfehlungen dazu ab, wie die Page Performance verbessert werden kann.
- Der “Estimated Savings”-Wert stellt eine sehr grobe Schätzung dar und sollte eher als Priorisierung, statt als genau berechnetes Einsparpotential verstanden werden.
- Zu jeder empfohlenen Maßnahme kann man sich über den “Learn more”-Button eingehender informieren.
Nicht immer bilden die Lighthouse Opportunities das vorliegende Performance Problem genau ab. Oft muss noch tiefer in die Recherche eingestiegen werden.
Es lohnt sich jedoch, einen Blick darauf zu werfen und die dort empfohlenen Best-Practices einzuarbeiten.
3. Webpagetest
Webpagetest.org ist ein frei zugängliches Online-Tool mit dem sich einzelne Seiten und deren Ladeverhalten im Detail analysieren lassen. Hier kann man sich in Einzelheiten verlieren, aber auch wichtige neue Erkenntnisse gewinnen.
| Praktisch: | Neben den wichtigsten Performance KPIs wie den CWV, Document Completion Time oder FCP, gibt es hier auch:
● Einen Content Breakdown: Welche Inhalte werden in welchem Umfang auf der URL geladen? (JS, images, CSS etc.) ● Einen Domain Breakdown: Aus welchen Quellen stammen die geladenen Inhalte? (native vs. third party) ● Uvm. |
| Achtung: | Liegen Chrome Nutzer-Daten für die getestete URL vor, werden diese im webpagetest.org CWV-Bericht ausgewiesen (Felddaten). Andernfalls werden Labordaten in einer kontrollierten Testumgebung gemessen. |
| Tipp: | Ein einzelner Abschnitt reicht nicht aus, um die Möglichkeiten und Anwendungsbereiche dieses mächtigen Tools zu vermitteln.
Deshalb möchte ich auf folgendes Manual verweisen: https://nooshu.com/blog/2019/10/02/how-to-read-a-wpt-waterfall-chart/ Für den interessierten, angehenden Performance-Experten finden sich dort viele interessante Informationen, Anwendungsfälle und Problemszenarien – definitiv eine Leseempfehlung von mir. |
Webpagetest.org bietet sich sehr zur Analyse der Ladehierarchie an. Durch das hier erzeugte Wasserfalldiagramm (s.u.) kannst Du genau betrachten, welche Ressource zu welchem Zeitpunkt geladen wurde und welche anderen Assets sie dabei blockierte.
So lassen sich Abhängigkeiten aufdecken und problematische Ressourcen identifizieren, welche Du anschließend löschen oder optimieren kannst.
Page Performance Best Practices
In vielen Fällen genügen wenige Anpassungen, um die Ladegeschwindigkeit der eigenen Seite auf ein vernünftiges Maß zu verringern.
Im Folgenden habe ich die – meiner Meinung nach – wichtigsten Punkte aufgearbeitet, um Dir einen Überblick über potentielle Fallstricke und Optimierungsmöglichkeiten zu geben.
Achtung: Prüfe zuerst, ob die Maßnahmen bei Dir notwendig sind, bevor Du sie umsetzt.
Videos und Bilder optimieren
Fangen wir gleich mit dem Offensichtlichsten an. Bilder, GIFs und Videos sind oft die Ressource mit der größten Datenmenge.
Merke: Je geringer die Datenmenge ist, die der Browser herunterladen muss, desto schneller rendert auch die URL!
Deshalb bietet es sich an, hier mit der Optimierung zu beginnen.
Bilder
Komprimieren
Generell solltest Du versuchen, Bilder unter 300KB zu halten. Natürlich nur so lange die UX nicht darunter leidet und die Auflösung zu grob wird. Bilder können mit kostenlosen Online-Tools komprimiert werden, etwa TinyPNG.
Lazyloading
Außerhalb des First-View sollte zudem mit einem Lazyload-Attribut gearbeitet werden. Dies ist ein Attribut, welches dem Browser mitteilt, dass es sich hier um keine kritische Ressource handelt. Der Browser wartet daraufhin mit dem Download, bis der Nutzer zum Bild gescrollt hat.
Das Lazy-Attribut kann einfach zum entsprechenden img-Element hinzugefügt werden:
<img src=”https://www.beispiel-bildressource.de/bild-1.png” loading=”lazy” alt=”Das Laden dieser Bildressource ist aufgeschoben” width=”200″ height=”200″>
Preloading
Genau gegenteilig verhält es sich mit Bildern, welche sich im First-View der URL befinden. Diese sollten so schnell wie möglich geladen werden, um eine gute UX zu gewährleisten. Dies kannst Du durch Verwendung eines Preload-Attributs erreichen. Mit diesem teilst Du dem Browser mit, dass das Bild eine kritische Ressource darstellt und vor allen anderen geladen werden sollte.
Damit der Browser rechtzeitig reagieren kann, muss das Preload-Attribut im HTML <head> hinterlegt werden.
Das Bild-Element wird im Quellcode nicht bewegt, aber folgendermaßen im head referenziert:
<link rel=”preload” as=”image” href=”https://www.beispiel-kritische-bildressource.de/bild-1.png” imagesrcset=”kritische-bildressource_400px.png 400w, kritische-bildressource_800px.png 800w, kritische-bildressource_1600px.png 1600w” imagesizes=”50vw”>
Videos
Komprimieren
Auch Videos sollten so weit wie möglich komprimiert werden, um die Downloadmenge zu minimieren.
Kein Autoplay
Zudem sollten Videos nicht per Autoplay geladen und abgespielt werden. Das Video sollte erst nach Nutzerinteraktion laden – beispielsweise ausgelöst durch Klick auf einen Play-Button. So kann der Browser zuerst die für das Rendering wichtigen Ressourcen herunterladen. Der Besucher kann dann entscheiden, ob er das Video anschauen möchte oder nicht.
Thumbnail
Statt sofort das komplette Video zu laden, kann erst nur ein Thumbnail bereitgestellt werden. Mit diesem kann ebenso verfahren werden wie mit den anderen Bildern auf der URL:
- Befindet sich das Video im First-View, sollte das Thumbnail mit Preload im header referenziert werden.
- Befindet es sich unterhalb, sollte das Thumbnail mit dem Lazyload-Attribut versehen werden.
Generell empfehle ich bei der Verwendung von Videos eine Einbindung über YouTube. Dabei können die obigen Empfehlungen relativ einfach umgesetzt werden.
Third-Party Inhalte optimieren
Heutzutage ist die Einbindung neuer Funktionalitäten, Tracking Tools oder Pixel selbst für Laien kinderleicht geworden. Einfach den Code-Snippet des Anbieters kopieren und in den eigenen Header packen – Voila!
Hier kann man schnell den Überblick verlieren und nach ein paar Jahren weiß niemand mehr genau, welches Tracking-Pixel nun für was eigentlich gut war.
Das jedoch, vor allem im Header einer Website, jeder zusätzliche Code negative Auswirkungen auf die Ladezeit haben kann, geht dabei oft unter.
Um eine optimale Einbindung zu gewährleisten, sollte man folgende Punkte beachten:
Third-Party Audit
Generell bietet es sich an, von Zeit zu Zeit eine Bestandsaufnahme durchzuführen. In einem solchen Third Party Audit sollten alle Ressourcen identifiziert und auf den Prüfstand gestellt werden. Hierbei wird relativ schnell klar, wo sich Einsparpotential verbirgt. So habe ich bei einem Projekt beispielsweise gleich drei Facebook Pixel entdeckt, wobei nur einer notwendig war.
Für einen ersten Überblick bietet sich webpagetest.org an – oder einfach direkt in den Quelltext schauen. Hilfe kann man sich dabei von den Webdev- oder Tracking-Kollegen holen.
Defer / Async
Wenn nach einem Audit nur noch notwendige Ressourcen übrig geblieben sind, kann man sich daran machen, die Ladehierarchie zu optimieren. Initial müssen vor allem Inhalte im First-View geladen werden. Das sind beispielsweise Bilder, Texte, Fonts oder Navigationsleisten. Alles weitere, wie Java Script Integrationen oder Tracking Pixel, können später nachgeladen werden.
Hierzu kann das Async oder Defer Attribut verwendet werden:
- Das Defer Attribut verschiebt das Laden und Ausführen eines Skripts, bis alle anderen Website-Komponenten geladen wurden. Zudem werden alle Skripte mit diesem Attribut in der Reihenfolge ausgeführt, in der sie im Code auftauchen.
- Mit async werden Skripte zwar ebenso asynchron heruntergeladen, aber direkt ausgeführt, sobald sie heruntergeladen wurden.
Um hier nicht zu sehr in die Komplexität einzutauchen, empfehle ich Dir, das async Attribut zu verwenden.
Du kannst dabei folgendermaßen vorgehen:
Vorher:
Nachher:
Location
Apropos Google Tag-Manager. Dieser stellt eine praktische Lösung dar, Skripte Domainweit in den Body zu integrieren, statt in den Header. So gut wie jeder Anbieter behauptet, sein Skript müsse unbedingt im Header platziert werden. In Ihrer Funktion werden die meisten Trackingscripte aber auch ein Stockwerk weiter unten nicht eingeschränkt.
Einfach mal ausprobieren, denn im HTML-Body stört Third-Party den Ladevorgang gleich ein bisschen weniger. Zudem können Skripte durch den Tag-Manager auch ganz bequem nur auf speziellen URLs gefeuert werden – Ask your favorite webdev about it.
Fonts optimieren
Fonts sind meist nur ein kleines Problem, wenn es um Page Performance geht, aber etwas mit dem man sich durchaus einmal auseinandersetzen sollte. Selbst gehostete Schriftarten sind hierbei zu empfehlen und stören den Ladefluss am wenigsten.
Etwas schwieriger ist es dagegen mit Googlefonts. Bei der Verwendung dieser wird initial ein Skript ausgeführt, welches eine CSS-Datei lädt, welche dann wiederum die einzelnen woff-Dateien herunterlädt.
Klare Empfehlung hier: Skript rausschmeißen und das CSS inline integrieren. Dabei muss dieses einfach in ein style-tag überführt werden. Im Detail nachzulesen hier.
Tipps, um Deine Ladezeit zu verringern
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenWeiterführende Lektüre
Google hat einige wertvolle Ressourcen zum Thema Page Performance bereitgestellt, welche ich dir nicht vorenthalten möchte. Wenn du dich eingehender mit dem Thema Page Performance auseinandersetzen möchtest, kann ich dir folgende Artikel sehr ans Herz legen. Hier finden sich Informationen zu Messwerten, Maßnahmen & Implementierung dieser:
| Pagespeed Insights:
Wie man seine Webseiten mit dem Pagespeed Insights Tool analysiert und die Daten interpretiert, ist in folgender Doku ausführlich beschrieben. Das Tool bietet einen guten Startpunkt in die Optimierung der eigenen Page Performance. |
● developers.google.com/speed/docs/insights/v5/about |
| CWV:
Alle Infos zu und um Core Web Vitals, wurden auf folgenden Ressourcen zusammengefasst. Hier finden sich zudem Empfehlungen zur Optimierung der einzelnen Messwerte. |
● web.dev/vitals/ |
| Lazyload und Preload:
Mehr zum Thema Lazyload und Preload gibt es auch in den Google-Dokus. |
● web.dev/lazy-loading-images/ |
| Asynchrones Laden:
Informationen zur Verwendung von defer- oder async-attributen kann man unter folgendem Link nachlesen. |
● web.dev/efficiently-load-third-party-javascript/ |
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen
5 Stimmen, Bewertung: 4,00 von 5)
