PageSpeed Optimierung

Autor: Sergej Semjonow
44 likes

Als offizieller Rankingfaktor ist die Ladegeschwindigkeit bei der Optimierung einer Website heute unerlässlich. Unser Workshop zeigt, worauf es dabei ankommt.

PageSpeed (auch Ladezeit oder Seitenladegeschwindigkeit) ist die zeitliche Angabe, wie schnell eine Webseite und deren Inhalte laden und auf den unterschiedlichen Endgeräten angezeigt werden. Dabei wird die Dauer vom Absenden eines Requests bis zur vollständigen Auslieferung aller Seiteninhalte und dessen Aufbereitung gemessen.

Dass die Seitengeschwindigkeit das Ranking bei Google beeinflusst, wurde in der Vergangenheit von vielen Suchmaschinenoptimierern vermutet. Seit Juni 2018 wurde dieser Faktor offiziell von Google bestätigt. Die Optimierung der eigenen Ladezeiten hat bspw. folgenden Vorteil: Positive Usersignale werden an Google gesende. Der User freut sich, weil im Idealfall das, wonach er gesucht hat, schnell angezeigt wird.
Der Google-Bot prüft rund um die Uhr Websites und hat somit nur ein kurzes Zeitfenster für jede Seite eingeplant. Dieses Fenster ist von bestimmten Faktoren abhängig. Je langsamer eine Website lädt, desto wahrscheinlicher ist es, dass wichtige Seiten vom Google-Bot nicht gecrawlt werden. Das kann wiederum negative Auswirkungen auf die Indexierung, Positionierung und Aktualisierung (Stichwort: Freshness) haben. Neben den wichtigsten Rankingfaktoren wie Mobile First, Suchintention der User & User Experience, Voice Search, SERP-Snippet-Optimierungen, strukturierten Daten, Seiten­struktur sowie internem und externem Linkbuilding ist die Ladegeschwindigkeit ein offiziell von Google bestätigter Rankingfaktor.

Wichtige Tools und deren Einfluss auf SEO

Obwohl der PageSpeed im Grunde selbsterklärend und intuitiv verständlich ist, gibt es bezüglich der Optimierung eine Vielzahl granularer Hebel, die man beachten sollte. Im Folgenden werden nützliche und kostenlose Tools mit Praxisbeispielen für sowohl erfahrene als auch Einsteiger-SEOs dargestellt.
Vorab: Wie mit vielem im Bereich SEO ist auch die Optimierung des PageSpeed kein Sprint. Du solltest also immer mal wieder ein Auge auf die Performance und die neuesten Entwicklungen haben. Das Grundprinzip beim Laden einer Seite und weitere Begrifflichkeiten:

  • First Paint (FP) = passiert etwas?
  • First Contentful Paint (FCP) = der erste Inhalt, der zu sehen ist.
  • First Meaningful Paint (FMP) = das Grundgerüst der Website.
  • Time to Interacive (TTI) = die Zeit, die vergangen ist, bis der User die erste Interaktion mit der Website machen kann.

Google Pagespeed Insights

Als praktischer Start in diese Thematik empfiehlt sich der Test mit Google Pagespeed Insights.

Eine Ergebnisseite via Google Pagespeed Insights

Dieses Google-Tool zeigt mithilfe einer Anzeige von 0 bis 100, wie der Gesamteindruck der eingegebenen Website ist. So kannst du die größten Baustellen der Website erkennen – u.a. auch die Technik, die bei der Ladegeschwindigkeit eine Rolle spielt. Mit den Empfehlungen zur geschätzten Einsparung in Sekunden bekommt man gute Anhaltspunkte, an denen angepackt werden sollte. In der Abbildung oben ist auf den ersten Blick zu erkennen, dass die Bilder oder Ressourcen besser komprimiert werden sollten. Obwohl der mobile Index als Hauptindex ernannt wurde, sollte die Ladegeschwindigkeit der Website zusätzlich auf der Desktop-Variante getestet und ggf. angepasst werden. Keine Sorge, falls du eine Punktzahl von 100 nicht erreichen solltest. Deine Website ist mit 85 Punkten im grünen Bereich und somit schnell. Google selbst unterscheidet bei der Benchmark-Studie von 2018 folgende durchschnittliche PageSpeed-Zeiten und gibt die wahrscheinliche Absprungrate (engl. Bounce Rate) der User an.

www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/

Tipp: Vergleiche die Punktzahlen von Seiten deiner direkten Mitbewerber, um die Ladegeschwindigkeit deiner Website besser beurteilen zu können.

testmysite.withgoogle.com

Für mobile Websites gibt es ein alternatives Tool, das im Februar 2019 erneuert wurde: testmysite.withgoogle.com. Auch dieser Service dient dem ersten groben Überblick über die Performance einer beliebigen mobilen Seite. Die Wartezeit beträgt in etwa eine Minute.

Analyse von amazon.de mit testmysite.withgoogle.com

Die mobile Site von Amazon.de erzielt eine Ladezeit von 1,4 Sekunden im 4G-Netz in Deutschland. Hierbei kann man die Geschwindigkeit von 4G auf 3G ändern. Scrollt man weiter nach unten, wird einem die Möglichkeit geboten, den PageSpeed mit bis zu 9 Mitbewerbern gleichzeitig zu vergleichen.

PageSpeed-Vergleich der Mitbewerber-Domains

Im Anschluss kann man sich die Auswirkung einer schnelleren Seite auf das eigene Business berechnen lassen. Dazu muss man seine Besucherzahl, die Conversion-Rate in Prozent und den durchschnittlichen Bestellwert preisgeben.

Berechnung einer Umsatzsteigerung bei optimierter Websitegeschwindigkeit

Im letzten Step werden konkrete Optimierungsvorschläge genannt. Zudem kann man hier weitere Unterseiten der eigenen Website eingeben und diese analysieren lassen. Die Analyse ist derzeit auf 10 Seiten gleichzeitig beschränkt.

Optimierungsvoschläge für die analysierte Domain/Unterseiten

Webpagetest.org

Als weitere nützliche Website zur PageSpeed-Analyse hat sich Webpagetest.org erwiesen.

Die Startseite von Webpagetest.org

Zu Beginn solltest du dir kurz Gedanken über deine Zielgruppe machen und weitere Einstellungen treffen:

  • Woher kommen meine User bzw. von wo wird meine Seite aufgerufen?
  • In welchem Browser soll der PageSpeed analysiert werden?
  • Mit welcher Internetverbindung soll getestet werden (Kabel, DSL, 4G, 3G etc.)? 
  • Wie oft soll die Website nacheinander analysiert werden? Wir empfehlen, drei Runs einzustellen, um die Analyse ein Stückchen valider darzustellen.
Analyseergebnis der PageSpeed Performance von Amazon.de

Zugegeben, man bekommt hier einen Overload an Informationen. Doch bedenke: Für kleinere Websites ist nicht alles in dieser Ansicht von Relevanz. Du solltest dich daher auf das Benotungssystem in der oberen rechten Ecke und auf die ersten beiden Spalten konzentrieren.

Die Benotung erfolgt von A bis F, wobei A für „sehr gut“ und F für „mangelhaft“ steht. Schaut man sich nun das F an, erkennt man in der oben stehenden Tabelle, dass die Zeit, die der Server zum Antworten benötigt, mit 0,940 Sekunden deutlich zu hoch ist. Es ist wichtig zu wissen: Für Google gilt bereits eine First Byte Time von über 0,200 Sekunden als langsam.

Wie tief im Verzeichnis liegen meine Files? Was hat „excessive DOM-Usage“ damit zu tun?

Viele Tools erzielen ähnliche Ergebnisse und geben dementsprechend verwandte Empfehlungen. Beim folgenden Ana­lysetool aus dem Chrome-Browser wird deshalb ausschließlich auf die DOM-Usage ein eingegangen. DOM (Document Object Model) ist das Bindeglied zwischen einem dynamischen JavaScript und dem HTML. Beim JavaScript/DOM werden alle dynamisch ausgerufenen Elemente, die verändert, hinzugefügt und gelöscht werden können, zu Objekten. Die Ladezeit einer Website kann durch eine große Anzahl an DOM-Elementen negativ beeinflusst werden.

Unabhängig von der Anzahl an Tools, die man zur Analyse verwendet, sollte der Fokus auf die Optimierung relevanter Hebel gelegt werden. Selbst die Verbesserung von nur einigen Punkten, die weiter unten aufgezählt sind, kann eine starke Auswirkung auf den PageSpeed haben und den User zufriedenstellen. Welche Bereiche das sind und wie man jeweils vorgehen sollte, wird im Folgenden näher erklärt.

https://developers.google.com/web/tools/lighthouse/audits/dom-size

Um zu sehen, ob der DOM-Baum einer Website optimiert werden sollte, kannst du im Chrome-Browser wie folgt vorgehen:

  • Rechtsklick,
  • Untersuchen (ganz unten),
  • Audits (ganz rechts),
  • Run Audits (ggf. Einstellungen und Eingrenzungen treffen).
  • Das Ergebnis: Je nachdem, ob man die Empfehlungen von Google überschritten hat oder nicht, werden einem die exakten DOM-Größen unter „Passed audits“ oder „Opportunities“ angezeigt.
Tatsächliche DOM-Anzahl

Welche Ressourcen werden gesendet?

Überlege dir, welche CSS du verwenden willst und ob diese optimiert werden kann. Der Browser muss das jeweilige HTML-Dokument zuerst downloaden, parsen und letzten Endes anwenden, bevor das individuelle und seiteneigene Stylesheet den Feinschliff einsetzt. Wir empfehlen die Verwendung eines Lightweight-CSS-Frameworks wie bspw. spectre oder bulma.io., weil diese mit wenig Code umsetzbar sind und dennoch komplexe Layouts darstellen können. Simple Erklärungen und weitere Frameworks findest du auf TutorialZone. Mithilfe eines Asset-Management-Systems wie Browserify oder Webpack kann eine intelligente und automatisierte Selektierung stattfinden, welche Libraries benötigt und im Frontend ausgegeben werden. Sowohl Browserify als auch Webpack bündeln jeweils die entsprechenden Formate und übergeben nur die notwendigen Ressourcen.

Vereinfachte Funktionsweise von Webpack für HTTP/2

Wie werden die Ressourcen gesendet?

Eine schnelle Auslieferung der angefragten Inhalte ist eine der wichtigsten Kriterien für User und Suchmaschinen. Darunter fällt unter anderem die Migration auf HTTP/2, die es erlaubt, mehrere Anfragen gleichzeitig und zusammengefasst an den Server zu übertragen. Ressourcen können im HTML-Code mithilfe von „rel=preload“ frühzeitig aufgerufen werden, bevor der Browser diese selbst erkennt. Ein weiterer Ansatz ist „rel=preconnect“. Hierbei wird die Wartezeit überdeckt, die auftritt, wenn Ressourcen von Drittanbieter-Domains geöffnet werden. 

HTML-Beispiel zum Vorladen eines Bildes

Nicht alles auf deiner Website muss zwingend von deinem Server geladen werden. Du kannst Elemente und Ressourcen von einem anderen Netzwerk, einem sog. Content Delivery Network (CDN), laden lassen.
Die Vorteile davon sind:

  • User im Land X erhalten ihre Antwort von Content Delivery Networks (CDNs) im Land X.
  • Es erfolgen weniger Requests an den eigenen Server.
  • Inhalte werden schnell bereitgestellt.
  • Besonders sinnvoll für international aufgestellte Websites.

Wie viele Daten werden gesendet?

Neben den Ressourcen und der Art und Weise, wie diese verschickt werden, spielt es eine Rolle, wie viele Daten gesendet werden. Folgende Punkte helfen dir dabei, die Anzahl an Daten zu limitieren.
Entferne in allen textbasierten Ressourcen nicht benötigten weißen Inhalt, wie zum Bespiel Zeilenumbrüche und unnötige Leerzeichen. Dabei wird die Dateigröße signifikant reduziert, ohne einen Einfluss auf die Funktionalität zu nehmen. Das Entfernen von leeren Zeilen ist in jedem Fall ratsam. Auch wenn du Komprimierungen wie GZip oder Brotli verwendest, ist es sinnvoll, den Code zu minifizieren. Verwende eine Minify Library, um Ressourcen sauber zu verkleinern. Das Asset-Management-Tool Webpack benutzt beispielsweise schon eine Minfiy Library.

Damit nicht immer wieder Daten neu an denselben User geschickt werden müssen, solltest du das Browser-Caching verwenden. Hierbei sagt man dem jeweiligen Browser, dass sich bestimmte Elemente einer Seite nicht verändern werden und diese im Zwischenspeicher hinterlegt werden können. Die Aktivierung findet manuell in der .htaccess-Datei statt:

Aktivierung des Browser Cachings von einem Apache-Server


In den runden Klammern stehen alle Formate, die gecached werden sollen. Der Ausdruck „max-age=2592000“ gibt die Dauer der Speicherung in Sekunden an. Das entspricht genau 30 Tagen. Um auf Nummer sicher zu gehen, solltest du zusätzlich mit dem MD5-Hash arbeiten. Diese Ergänzung merkt, falls Änderungen an den Inhalten vorgenommen werden und fragt in diesem Fall erneut beim Server an. Alternativ zur manuellen Aktivierung kannst du auch Erweiterungen für dein CMS verwenden.

Was sind Komprimierungen und warum sind diese wichtig für die Ladegeschwindigkeit


Inhalte wie Bilddateien, JS- und CSS-Ressourcen können serverseitig mithilfe von Brotli verkleinert werden. Die Komprimierung mit GZIP kann die Dateigröße von Bildern nicht verringern. Ziel ist es, die angeforderten Dateien verdichtet an den Client zu übergeben. Eine Umstellung der Komprimierungen kannst du bei deinem Serverdienstleister in Auftrag geben. Im Normalfall kennen sich die Kollegen damit bereits aus und können diesen Punkt zeitnah umsetzen. Alle serverseitigen Kompressionen sind abwärtskompatibel. Das heißt beispielweise: Wenn Brotli von einem Browser nicht unterstützt wird, bekommt der Browser GZip zugeschickt.

Neben den serverseitigen Optimierungen gibt es wirksame Ansätze, die du selbst durchführen kannst, um die Ladegeschwindigkeit zu verbessern. Bilder und weitere Medien machen einen Großteil der zu übertragenden Datenmenge aus. Bevor du also Bilder hochlädst, solltest du diese komprimieren. Dazu gibt es online eine Reihe von kostenlosen Tools wie bspw. Compressor.io.

Fazit

Als offizieller Rankingfaktor ist die Ladegeschwindigkeit bei der Optimierung einer Seite in der heutigen Zeit unerlässlich. Ziel ist es, den mobilen User glücklich zu machen.

Checkliste: PageSpeed-Optimierung

  • Tests mit PageSpeed Insights, testmysite.withgoogle.com, webpagetest etc.,
  • Bilder sind komprimiert,
  • Lazy Loading ist aktiviert,
  • Ressourcen werden mit rel=preload vorgeladen,
  • Skripte werden im Footer geladen,
  • http/2 wird verwendet,
  • Lebensdauer des http-Caches ist erhöht,
  • serverseitige Komprimierung und ein Fallback ist aktiv (GZip/Brotli),
  • Verwendung eines Asset Management Systems (Webpack/ Browserify),
  • Verwendung von Lightweight CSS wie spectre, bulma.io etc.,
  • halte dich an die von Google empfohlenen DOM-Größen,
  • Möglichst wenige Weiterleitungen via 301,
  • verwende Content Delivery Networks (CDNs), falls du international aufgestellt bist,
  • Verwendung moderner Bildformate wie WebP, JPEG 2000 oder JPREG XR.

Falls du weitere Insights zu den Themen PageSpeed und SEO gewinnen willst, empfehlen wir dir, einen Blick in das kostenlose eology-Whitepaper „Search Engine Optimization für mehr Web-­Traffic“ zu werfen.

Der Autor Sergej Semjonow ist SEO Consultant bei der eology GmbH. Er berät und unterstützt Kunden strategisch bei allen Projekten rund um SEO.

Diese Artikel könnten Sie auch interessieren: