Core Web Vitals und Pagespeed

Hintergrundwissen zu den Core Web Vitals

Was ist Pagespeed

• ist und war immer nur ein Domain / Online Dienst bzw. Markenname von Google

• Metriken bezogen sich fast ausschließlich auf den Lighthouse Score

• Abkömmliche, wie Webserver Module “Pagespeed”, Pagespeed Service (CDN / Hosting) sind mittlerweile eingestellt

Wer ist dafür verantwortlich(und damit eine seriöse Quelle)?

• Lighthouse: Dave Chen, Vice President of Engineering Alphabet Inc.

• Core Web Vitals: Sowmya Subramanian, Director of Engineering for Search Ecosystem Alphabet Inc.

• Chrome UX Report: Bryan McQuade und Ilya Grigorik, User Experience Reporters Alphabet Inc.

Was sind die CoreWebVitals (CWV)

• CWV sind eine von Google definierte Sammlung von Metriken für Webperformance von Webseiten im Chrome-Browser.

• Sie werden für das Suchmaschinenmarketing von Webseiten (Mobil + Desktop) herangezogen, um die Nutzerfreundlichkeit anhand einer Reihe von Signalen zu bestimmen.

• CWV sind vorrangig für die Nutzerfreundlichkeit wichtig und werden von Google beim Ranking hinter die angebotenen Informationen gestellt. Diese Metriken werden erst relevant, wenn viele Seiten ähnliche Inhalte haben und Google eine Entscheidungshilfe für den Stellenwert der Sichtbarkeit benötigt.
  Understanding Google Page Experience | Google Search Central  |  Documentation  |  Google Developers

• CWV haben jedoch nicht nur eine Wirkung auf die Rankings, sondern wirken sich statistisch bewiesen auf den Umsatz einer Seite auf (web.dev: The business impact of Core Web Vitals)

• Metriken:

  • LCP = Largest Contentful Paint
    Bezeichnet die Zeit vom Beginn des Ladens der Seite bis zum Anzeigen des größten Inhaltselements im Viewport

  • FID = First Input Delay
    Gibt an, wie schnell eine Website auf User-Aktionen reagiert.

  • CLS = Cumulative Layout Shift
    Ist ein Maß für das Verschieben von Elementen während des Seitenaufbaus und beim Scrollen

  • FCP = First Contentful Paint
    Beschreibt die Zeit vom Beginn des Seitenladens bis zu dem Zeitpunkt, wenn das erste Mal etwas auf dem Display angezeigt wird, das als Inhalt wahrgenommen werden kann.

  • INP = Interaction to Next Paint:
    Bewertet die Reaktionsfähigkeit der Seite und misst die Latenz aller Interaktionen, die ein Benutzer mit der Seite vorgenommen hat (und meldet einen einzelnen Wert, unter dem (fast) alle Interaktionen lagen).

  • TTFB = Time to First Byte

Wo findet man Berichte zum Thema Performance und CWV?

Scoring - Lighthouse

• Standard seit 2016, interner Chrome Benchmark(Abweichungen zu anderen Browsern daher IMMER möglich) - offizielle Website: Overview - Chrome Developers

• unterteilt in diverse Audits (Performance, Accessibility, Best Practices, SEO, PWA etc.)

• Messung über Chrome Dev Tools (empfohlen von Google), Browser Extensions, web.dev Website, CI Stacks

Open

Scoring - Core Web Vitals

• Standard seit 2020, Basis für Nutzerfreundlichkeit, Geschwindigkeit, Visuelle Stabilität von Websites

• erste Erwähnung: Evaluating page experience for a better web  |  Google Search Central Blog  |  Google Developers

• Grob in 3 Teile unterteilt:

  • Ladegeschwindigkeit der Seite - Largest Contentful Paint (LCP)

  • Interaktivität der Seite - First Input Delay (FID)

  • Visuelle Stabilität - Cumulative Layout Shift (CLS)

• Hier kann man seine CWV sehen: Google zeigt sie erst an, wenn sie in statistisch signifikanter Menge vorliegen. Liegen für FID nicht genügend Daten vor, LCP und CLS wurden aber bestanden, dann gilt der CWV-Test auch als bestanden

  • PageSpeed Insights PageSpeed Insights (Achtung: CoreWebVitals werden immer auf Grundlage der Core Web Vitals-Messwerte über den letzten 28-tägigen Erhebungszeitraum berechnet.

  • WebPageTest WebPageTest

  • GA4 (entweder über Google Analytics Reporting API oder mit Google Tag Manager Vorlage) https://github.com/GoogleChrome/web-vitals#send-the-results-to-google-analytics:~:text=The%20recommended%20way%20to%20measure%20Web%20Vitals%20metrics%20with%20Google%20Tag%20Manager%20is%20using%20the%20Core%20Web%20Vitals%20custom%20template%20tag%20created%20and%20maintained%20by%20Simo%20Ahava.

    Open

    

  • Google Search Console

Scoring - Chrome UX Report

• Daten hinter den Felddaten in allen Berichten - offizielle Website: About CrUX - Chrome Developers

• Erfassung durch Google Chrome / Analytics seit 2017

Relevanz von Page Experience

Die Page Experience / Seitengeschwindigkeit ist wahrscheinlich der universellste SEO-Faktor, denn die Verbesserung der Page Experience / Seitengeschwindigkeit verbessert das Ranking, das Nutzererlebnis und auch die Conversionrate.

Es ist ein seltenes Beispiel für eine SEO-Maßnahme, die wirklich jedem etwas bringt.

Page Experience / Seitengeschwindigkeit und SEO

Im Bereich der Suchmaschinenoptimierung ist die Page Experience / Seitengeschwindigkeit von Seiten und Websites ein wesentlicher Bestandteil der Bewertung von Seiten durch die Suchmaschinen geworden.

Das liegt daran, dass Google keine Ergebnisse liefern möchte, die langsam laden und die Nutzer abschrecken. Sie versuchen, die relevantesten und am besten geeigneten Websites in ihren Ergebnissen zu präsentieren.

Mit dem Google Page Experience Update im Mai 2021 wurde dies ein noch wichtigerer Faktor.

Google berücksichtigt beim Ranking vor allem die angebotenen Informationen. Eine gute Nutzerfreundlichkeit bedeutet nicht, dass relevante Inhalte unwichtiger werden. Wenn allerdings viele Seiten ähnlich relevante Inhalte haben, bekommt die Nutzerfreundlichkeit einen wesentlich höheren Stellenwert für die Sichtbarkeit.
Understanding Google Page Experience | Google Search Central  |  Documentation  |  Google for Developers

Page Experience / Seitengeschwindigkeit und UX

Die Nutzererfahrung ist der Hauptgrund dafür, dass Suchmaschinen die Page Experience / Seitengeschwindigkeit einer Website für einen so wichtigen Faktor halten, und deshalb ist sie auch Teil ihrer Ranking-Algorithmen.

Es ist eine allgemein anerkannte Tatsache, dass im Internet niemand eine Aufmerksamkeitsspanne von mehr als ein paar Sekunden hat. Wenn eine Webseite also mehr als 3 Sekunden zum Laden braucht, kann es sein, dass die Mehrheit der Besucher nicht darauf warten will und eine andere Seite besucht.

Sie müssen den Inhalt wirklich wollen, um so lange zu warten.

Schnellere Websites sorgen für ein besseres Nutzererlebnis, und deshalb wollen Suchmaschinen diese Websites gegenüber langsamen Websites mit höheren Absprungraten bevorzugen.

Page Experience / Seitengeschwindigkeit und CRO

Der letzte der drei großen Vorteile einer schnelleren und gut zu bedienenden Website ist die Optimierung der Conversionrate.

Die CRO erhält oft einen großen Schub, wenn die Page Experience / Seitengeschwindigkeit verbessert wird, weil Sie keine Nutzer verlieren, die darauf warten, dass die Seite geladen wird.

Insgesamt wird die Verbesserung der Page Experience / Seitengeschwindigkeit also dazu beitragen, dass Seiten besser ranken, Nutzern ein besseres Erlebnis bieten und Chancen auf die so wichtige Conversions erhöhen.

Core Web Vitals im Detail

Time to First Byte (TTFB)

Time to First Byte (TTFB) ist die Zeit, die der Browser eines Nutzers benötigt, um das erste Byte des Seiteninhalts zu empfangen:

Weitere Informationen: Reduce server response times (TTFB)

Wie kann man TTFB verbessern?

• Optimieren Sie Ihren Server

• Leiten Sie Benutzer zu einem nahe gelegenen CDN um

• Cache-Assets

• Verringern Sie das Serverseitige Logging

• Servieren Sie HTML-Seiten zuerst im Cache

• Frühzeitiges Herstellen von Verbindungen zu Drittanbietern

• Optimieren Sie die Anwendungslogik des Servers, um Seiten schneller vorzubereiten. Wenn Sie ein Server-Framework verwenden, hat das Framework möglicherweise Empfehlungen, wie dies zu bewerkstelligen ist.

• Optimieren Sie die Art und Weise, wie Ihr Server Datenbanken abfragt, oder migrieren Sie zu schnelleren Datenbanksystemen.

• Rüsten Sie Ihre Server-Hardware auf, um mehr Speicher oder CPU zu erhalten.

First Contentful Paint (FCP)

Die Kennzahl "First Contentful Paint" (FCP) misst die Zeit zwischen dem Beginn des Ladens der Seite und dem Zeitpunkt, an dem ein Teil des Seiteninhalts auf dem Bildschirm gerendert wird.

Zum FCP-Inhalt gehören Text, Bilder (einschließlich Hintergrundbilder), <svg>-Elemente oder nicht-weiße <canvas>-Elemente.
Weitere Informationen: First Contentful Paint (FCP)

Beispiel

Wie kann man FCP verbessern?

Es gibt viele Möglichkeiten, die FCP zu verbessern. Dies ist von Standort zu Standort unterschiedlich, so dass Sie ein Lighthouse-Scoring durchführen und auf alle spezifischen Möglichkeiten oder Diagnosen achten können, die das Audit vorschlägt.

Im Allgemeinen sollten wir die folgenden Punkte beachten, um FCP zu verbessern:

• Beseitigen Sie Rendering-blockierende Ressourcen

• CSS verkleinern

• Ungenutzte CSS entfernen

• Vorab-Verbindung zu erforderlichen Ursprüngen

• Verkürzung der Server-Antwortzeiten (TTFB)

• Vermeiden Sie mehrfache Seitenumleitungen

• Wichtige Anfragen vorladen

• Vermeidung enormer Netzwerk-Payloads

• Statische Inhalte mit einer effizienten Cache-Richtlinie bereitstellen

• Vermeiden einer übermäßigen DOM-Größe

• Minimierung der kritischen Anforderungstiefe

• Sicherstellen, dass Text beim Laden von Webfont sichtbar bleibt

• Halten Sie die Anzahl der Anfragen niedrig und die Übertragungsgrößen klein

Largest Contentful Paint (LCP)

LCP ist eine Metrik, die zu messen versucht, wann eine Website für den Nutzer im Wesentlichen sichtbar ist und das größte Inhaltselement zeigt, das im Ansichtsfenster des Nutzers sichtbar ist.

• LCP misst die Ladeleistung

• Es wird betrachtet, wann das größte Element im Viewport gerendert wurde

• Bilder und Videoelemente werden für LCP berücksichtigt. Derzeit sind svg-Dateien ausgeschlossen, aber Bilder innerhalb von svg-Dateien werden weiterhin berücksichtigt

• Ein Element mit einem über die Funktion url() geladenen Hintergrundbild (im Gegensatz zu einem CSS-Gradienten) wirkt sich auf LCP aus.

• LCP wird auch von Block-Level-Elementen beeinflusst, die Textknoten oder andere Inline-Level-Text-Element-Kinder enthalten.

Weitere Informationen: Largest Contentful Paint (LCP)

Beispiele

Wie kann man LCP verbessern?

LCP wird hauptsächlich durch folgende Faktoren beeinflusst:

• Langsame Server-Antwortzeiten - verbessern Sie TTFB, um dies zu verbessern

• Rendering-blockierende JavaScript und CSS

• Ressourcen-Ladezeiten

• Client-seitiges Rendering

  Mehr Informationen: Optimize Largest Contentful Paint  |  Articles  |  web.dev

First Input Delay (FID)

Die Kennzahl First Input Delay (FID) hilft, den ersten Eindruck des Nutzers von der Interaktivität und Reaktionsfähigkeit Ihrer Website zu messen. FID misst die Zeit zwischen der ersten Interaktion eines Nutzers mit einer Seite (d. h. wenn er auf einen Link klickt, auf eine Schaltfläche tippt oder ein benutzerdefiniertes, JavaScript-gesteuertes Steuerelement verwendet) und dem Zeitpunkt, zu dem der Browser tatsächlich auf diese Interaktion reagieren kann.

• Messung der Interaktivität

• Hauptgrund für eine schlechte FID ist JavaScript

• Erfordert die Interaktion des Benutzers und ist daher sehr subjektiv

• Es konzentriert sich nur auf Eingabeereignisse von diskreten Aktionen wie Klicks, Antippen und Tastendrucken.

• Andere Interaktionen, wie Scrollen und Zoomen, sind kontinuierliche Aktionen und nicht Teil der FID
  In anderen Berichten wird anstelle der FID möglicherweise die Gesamtblockierzeit (TBT) gemessen.

Weitere Informationen: First Input Delay (FID)

Beispiel

 Wie kann man die FID verbessern?

Die FID kann wie folgt verbessert werden:

• Reduzieren Sie die JavaScript-Ausführungszeit

• Lange Tasks aufteilen

• Optimieren Sie Ihre Seite auf Interaktionsbereitschaft

• Verwenden Sie einen Webworker

Weitere Informationen: Optimize First Input Delay

Cumulative Layout Shift (CLS)

CLS misst die Gesamtsumme aller individuellen Layoutverschiebungen - für jede unerwartete Layoutverschiebung, die während der gesamten Lebensdauer der Seite auftritt. Eine Layoutverschiebung tritt immer dann auf, wenn ein sichtbares Element seine Position von einem Frame zum nächsten ändert.

• Misst die visuelle Stabilität der Seite

• Unerwartete Bewegung des Seiteninhalts, wenn der Benutzer dies nicht erwartet

• Layoutverschiebungen als Reaktion auf Benutzerinteraktionen (Klicken auf einen Link, Drücken einer Schaltfläche, Eingabe in ein Suchfeld usw.) sind im Allgemeinen in Ordnung, solange die Verschiebung nahe genug an der Interaktion erfolgt, so dass der Zusammenhang für den Benutzer klar ist.

Weitere Informationen: Cumulative Layout Shift (CLS)

Beispiele

Schlechte Benutzererfahrung:

Schlechte vs. gute Erfahrung:

 Wie kann man CLS verbessern?

• Fügen Sie immer Größenattribute für Ihre Bilder und Videoelemente ein oder reservieren Sie den benötigten Platz mit Hilfe von CSS-Seitenverhältnis-Boxen.

• Fügen Sie niemals Inhalte über bestehende Inhalte ein, es sei denn, Sie reagieren auf eine Benutzerinteraktion.

• Bevorzugen Sie Animationen zur Transformation gegenüber Animationen von Eigenschaften, die Layoutänderungen auslösen.

Weitere Informationen: Optimize Cumulative Layout Shift

Verbesserungsmöglichkeiten der Page Experience

Bildmaterial optimieren

Unkomprimiertes Bildmaterial führt zu längeren Ladezeiten. Dies ist nur logisch, wenn beim Aufbau der Webseite Megabyte an Daten geladen werden müssen. Dies führt dazu, das Nutzer meist die Seite bereits verlassen, bevor die Bilder überhaupt geladen wurden. Deshalb sollte man immer darauf achten, optimiertes Bildmaterial zu verwenden.

Was kann man tun, um das Bildmaterial zu optimieren?

Passende Bildgrößen verwenden

Soll das Bild in eine Box mit bspw. 300x300 px verwendet werden, so wäre es nicht sinnvoll, das originale Bildmaterial mit bspw. 5000x5000 px zu verwenden. Hier kann man das Bild auf die notwendige Größe reduzieren.

Bildmaterial verkleinern

Es gibt einige Online-Tools, mit denen sich Bildmaterial verkleinern lässt. Eines dieser Tools ist z.B. TinyPNG (TinyPNG – Compress WebP, PNG and JPEG images intelligently ). Solche Tools helfen, aus dem Bildmaterial noch mehr Einsparpotenzial zu holen.

Mit dem easyTemplate360 für den Shop5 (ab Version 2.0.19) haben wir zur einfachen Optimierung von Bildgrößen Tinify integriert. Damit können Bilder im Medienmanager über die Api an tinypng.com gesendet und verkleinert werden. Hier bestehen dann mehrere Möglichkeiten, wie das optimierte und verkleinerte Bildmaterial gespeichert werden soll.

 Bilder im WebP-Format verwenden

Optimiertes Bildmaterial kann immer noch ein wenig mehr optimiert werden, beispielsweise über das Bildformat WebP. Hier kann man im Durchschnitt noch bis zu 30% mehr einsparen: Comparative Study  |  WebP  |  Google Developers

Der JTL-Shop5 bietet hier bereits die Möglichkeit in den Bildeinstellungen:

Aktuell unterstützen aber noch nicht alle Browser dieses Bildformat.

Wie identifiziere ich zu große Bilder auf meiner Webseite?

 Dafür kann man die Entwicklerkonsole des Browser, beispielsweise Google Chrome oder Mozilla Firefox, verwenden. So gehen Sie vor:

1. Öffnen Sie bspw. den Chrome Browser.

2. Öffnen Sie Ihre Webseite.

3. Drücken Sie auf Ihrer Tastatur die F12-Taste.

4. Wechseln Sie auf den Reiter Network (Netzwerk).

5. Klicken Sie auf Img statt All und schauen Sie, dass Disable cache angeklickt ist.

6. Jetzt aktualisieren Sie die Seite neu (F5 oder den Aktualisieren-Button des Browsers klicken)

7. Da einige Seiten LazyLoading verwenden, sollten Sie einmal die komplette Seite durchscrollen.

8. Nun können Sie in der Entwicklerkonsole prüfen, welche Bilder in/mit welcher Größe geladen werden und optimiert werden könnten.

Artikelslider/Produktslider limitieren

Ein typischer Anwendungsfehler ist beispielsweise im Artikelslider/Produktslider keinen oder einen zu hohen Wert bei “Maximalanzahl Produkte” gesetzt zu haben. Nimmt man dort als Quelle eine Kategorie mit bspw. 10.000 Artikeln, so würden bei Seitenaufruf auch 10.000 Artikel im Artikelsldier/Produktslider geladen werden. Hier sollte man also darauf achten, eine Grenze der zu ladenden Produkte zu setzen.

Optimierungsmöglichkeiten bei den einzelnen Core Web Vitals Meldungen