Hinter den Kulissen: Wie wir den Pagespeed von GrowthUp verbessert haben

Das erwartet euch in diesem Artikel

  • Warum war GrowthUp so langsam?
  • Wie konnten wir das ändern?
  • Was könnt ihr daraus mitnehmen?

Als wir im vergangenen Jahr mit GrowthUp gestartet sind, waren wir total begeistert von der Performance der Seite. Das Template wurde extra für unsere Ansprüche gebaut und die Website war entsprechend schnell.

Doch mit der Zeit merkten wir, dass sich der Pagespeed immer weiter verschlechterte. Wir fügten neue Widgets, Plugins, Bilder und Informationen hinzu, die in ihrer Gesamtheit dem Pagespeed nicht wirklich zuträglich waren. Wir haben uns lange nur auf die Inhalte konzentriert und technische SEO-Aspekte fast gänzlich außen vor gelassen. Wir mussten also etwas tun, wenn wir verhindern wollten, dass unser Magazin, welches über gute Websites schreibt, selbst zu einer schlechten Website wird.

Was ist eigentlich Pagespeed?

Wichtig war zunächst, die für uns wichtigsten Parameter zu definieren und abzustecken. Im Endeffekt haben wir uns auf die folgenden drei geeinigt.

Ladezeit: Zeit, die vergeht, bis der komplette Seiteninhalt geladen ist. Die Rechnung beginnt, wenn der User zur Seite navigiert und endet beim “Document Complete Event”.

Time to First Byte: Die Zeitspanne, die vergeht, bis der Browser nach einem Request die erste Reaktion vom Server erhält.

Render-Start: Zeit, zu der das erste Mal etwas auf dem Bildschirm etwas angezeigt wird. Vorher sieht der User nur eine leere weiße Seite.

Ladezeit (gesamt) Time to First Byte Render-Start
Vorher 23,292 Sek. 0.422 Sek. 0,900 Sek.

Anhand dieser drei Metriken haben wir dann zwei zentrale Maßnahmen durchgeführt.

HTTP/2 & Lazy Loading – Das haben wir optimiert

Zum einen sind wir auf einen HTTP/2 fähigen Webserver umgestiegen. Bei HTTP/2 handelt es sich um den Nachfolger von HTTP/1.1, welcher deutlich schneller ist, da nicht mehr für jede einzelne Ressource ein eigener Handshake durchgeführt werden muss. Somit werden pro angefragte Ressource ca. 50 – 150 Millisekunden gespart. Die TCP-Connection bleibt in der Regel solange bestehen, bis alle Ressourcen vom Dokument übermittelt wurden. Das untenstehende Bild stellt diesen Vorgang grafisch dar.

Grafik: Http/2

Abb. 1: HTTP/1.1 und HTTP/2 im Vergleich (© https://www.getssl.in/index.php/http2-and-ssl-certificates/).

Eine Voraussetzung für den Wechsel auf HTTP/2 ist, dass eure Website auf HTTPS läuft – aber das sollte ja mittlerweile wirklich zum guten Ton gehören. Insgesamt verbessert HTTP/2 in Verbindung mit dem Apache-Modul ALPN den Pagespeed und hat somit auch einen Einfluss auf das Ranking, denn mit dem angekündigten Speed-Update von Google soll die Geschwindigkeit einer Seite ab Juli ein Ranking-Faktor für die mobile Suche sein.

Wichtig: Beim Wechsel des Webservers müsst ihr darauf achten, dass dieser nicht nur HTTP/2, sondern auch weiterhin HTTP/1.1 kann, da der Googlebot ausschließlich HTTP/1.1 versteht.

Zum anderen haben wir die JavaScript-Technologie Lazy Loading eingebunden. Hier werden die Bilder erst dann geladen, wenn sie in den sichtbaren Bereich des Users gelangen – also während des Scrollens. Somit werden also immer nur jene Bilder geladen, welche vom Nutzer tatsächlich gesehen werden können. Dies veranschaulich die untenstehende Grafik.

Grafik: Lazy Loading

Abb. 2: So funktioniert Lazy Loading (© https://medium.com/@ahmadali1/deciding-whether-or-not-you-should-use-lazy-loading-principles-a1afef05b721).

Lazy Loading kann zwar dazu führen, dass die entsprechenden nachgeladen Bilder nicht im Bilderindex landen (da der Googlebot auf einer Website keine Aktionen durchführt, also auch nicht scrollt), aber das ist bei uns in den meisten Fällen nicht so schlimm. Viele der betroffenen Bilder sind Logos unserer Konferenzpartner oder Screenshots, die sich in der Bildersuche sowieso nicht so gut machen. Wir konnten das Ganze also ohne Bedenken einbauen.

Wie haben sich unsere Optimierungen auf die Seitenladezeit ausgewirkt?

Die gesamte Ladezeit für neue Besucher wurde deutlich verbessert. Auch die Time to First Byte konnte um etwa ein Drittel verbessert werden. Lediglich der Render-Start wurde etwas verlangsamt, was im Vergleich aber zu verschmerzen ist. Zurückzuführen ist das auf Lazy Loading, da somit die JavaScript-Datei größer geworden ist.

Ladezeit (gesamt) Time to First Byte Render-Start
Vorher 23,292 Sek. 0.422 Sek. 0,900 Sek.
Nachher 3,576 Sek. 0.282 Sek. 1,033 Sek.
Änderung in %  – 84,65 % – 33,18 % + 14,78 %

Insgesamt haben wir es also geschafft, den Pagespeed von GrowthUp mit zwei Maßnahmen deutlich zu verbessern (auch wenn es natürlich immer noch besser geht). Mithilfe dieser Optimierung der Seitenladezeit durch HTTP/2 (A) und Lazy Loading (B) konnten wir auch unsere Sichtbarkeit verbessern. Dies zeigt der Sistrix-Sichtbarkeitsindex in der unterstehenden Abbildung.

Screenshot: Sichtbarkeit bei SISTRIX

Abb. 3: Die Sichtbarkeit von GrowthUp (© https://de.sistrix.com/growthup.de).

Wir werden auch weiterhin daran arbeiten, hier und bei anderen SEO-Dingen noch besser zu werden – und euch auch weiterhin darüber auf dem Laufenden halten.

Über den Autor

Carolin Kocher

Redakteurin
Nach meinem Bachelorstudium Management, Communication & IT (Schwerpunkt Medien) am MCI Management Center Innsbruck und meinem Auslandssemester an der Copenhagen Business School arbeite ich nun bei der Agentur LEAP/ in Berlin und unterstütze dort das SEO-Consulting-Team.
Kommentare