Jedes Quartal analysieren wir intern stichprobenartig die Performance unserer Portale. Das ist wichtig, damit wir immer auf dem aktuellsten Stand sind, wie zufrieden Nutzer und auch Google mit der Portal-Performance sind.
Mit der Zeit kamen auch neue Metriken dazu wie der Cumulative Layout Shift (CLS), die Google dann besonders gewichtet. Alles um das Nutzererlebnis im World Wide Web kontinuierlich zu verbessern.
Nun wollten wir unsere Ergebnisse veröffentlichen und mit Euch teilen.
Wo nehmen wir die Daten her?
Als stichprobenartige Portale wurden einst Stellplatz, Hundehotel, Familienausflug, Monteurzimmer und Seehotel ausgewählt.
Für die durchschnittlichen Seitenladezeiten (in Sekunden) und die Requests pro Minute haben wir in unserer Server-Monitoring-Software Stackify die Daten der letzten 30 Tage. Diese werten wir immer zum Ende eines Quartals aus. Außerdem gibt es einen Wert für die Satisfaction (in Prozent), also inwiefern das Ziel von 2 Sekunden Seitenladezeit erreicht wurde.
Google Analytics hat bisher auch Daten für den Average Page Load (in Sekunden) und die Average Server Response (in Sekunden) geliefert, allerdings gibt es das bei GA4 aktuell nicht, weswegen hier die Daten für dieses Quartal nicht existieren.
Die restlichen Daten liefert Google Pagespeed. Der Score setzt sich zurzeit wie folgt zusammen:
First Contentful Paint 10%, Speed Index 10%, Largest Contentful Paint 25%, Total Blocking Time 30%, Cumulative Layout Shift 25%.
Es wird immer zwischen Mobil und Desktop unterschieden, sodass man mobil einen ganz anderen Score haben kann, weil beispielsweise die Total Blocking Time ganz anders bewertet wird. Denn für die mobilen Tests wird von einer langsameren mobilen Datenverbindung ausgegangen.
Was bedeuten die Google-Pagespeed-Metriken?
First Contentful Paint (FCP) – Wie schnell ist das erste Element beim Seitenladen zu sehen?
Speed Index (SI) – Wie schnell ist die Seite für einen Nutzer verwendbar?
Largest Contentful Paint (LCP) – Wie schnell wird das größte sichtbare Element geladen (zum Beispiel ein Bild)?
Total Blocking Time (TBT) – Wie lange muss ein Benutzer warten, bis er die Webseite verwenden kann?
Cumulative Layout Shift (CLS) – Wie stark verschieben sich Elemente während des Ladeprozesses, ohne dass der Nutzer etwas tut? Es soll vermieden werden, dass ein Nutzer auf etwas falsches Klickt, weil die Seite sich noch zum Beispiel durch geladene Bilder verschiebt.
Hier kann man jederzeit ein Portal oder eine URL bei Google Pagespeed untersuchen:
https://pagespeed.web.dev
Diese sieht man als Portalbetreiber in der Google Search Console in den Core Web Vitals und wird da auch auf Probleme aufmerksam.
Wir haben da in letzter Zeit auch viele Verbesserungen live gebracht, allerdings kann es lange dauern, bis Google alle Seiten neu indiziert hat und die Zahlen bei Google aktualisiert sind.
Hier kommt man zur Google Search Console, wo man seine Webseite auswählen kann:
https://search.google.com/search-console/welcome
Auswertung
Die Seitenladezeiten sind im Schnitt besser geworden!
Stellplatz ist 50% schneller geworden, Hundehotel und Monteurzimmer sind gleichgeblieben, auf Seehotel sind sie etwas schlechter geworden, aber immer noch sehr gut bei 0,5 s. Und zu guter Letzt gab es bei Familienausflug eine Verbesserung um 88% von 1,7 s auf 0,19 s! Hier haben wir in letzter Zeit viele Ressourcen in die Performance-Optimierung von großen Portalen gesteckt.
Pagespeed im Desktop:
Hundehotel, Monteurzimmer und Seehotel sind weiterhin super oder besser geworden. Stellplatz und Familienausflug sind allerdings schlechter geworden. Das wird vorallem durch Bilder auf der Startseite, die in einer Übergröße geladen werden, verursacht.
Pagespeed mobil:
Hier gab es eine leichte Verschlechterung und es gibt wieder bei Stellplatz und Familienausflug schlechtere Werte. Die Bilder auf der Startseite spielen mobil noch stärker ins Gewicht. Auf den Suchseiten und Eintragsseiten ist der Pagespeed Score aber besser.
Mobil gibt es da Verbesserungsmöglichkeiten für die Bilder, diese könnten in Formaten der nächsten Generation komprimiert werden (WebP oder AVIF statt PNG oder JPEG). Das wäre ein großer Umbau und würde sehr viel Zeit kosten, die wir aktuell in die Mehrsprachigkeit investieren.
Aufgabe für Portalbetreiber
Allerdings wäre es für den konkreten Fall für Euch als Portalbetreiber ausreichend, wenn die Bilder über den passenden width-Parameter in der Bild-Url in einer kleineren Größe geladen werden. Am besten genauso groß, wie es angezeigt wird (Rechtsklick – inspizieren oder F12). Im Beispiel wären das nur 230 statt 1250 Pixel:
Hinterlasse eine Antwort