Sie haben das sicherlich auch schon erlebt: Sie rufen eine Website auf, und sehen bereits rasch Bild und Text, aber die Seite reagiert einfach nicht auf Ihre Aktivität: keine Reaktion beim Versuch des Scrollens, keine Reaktion bei Klick auf einen Link. Und auch noch später reagiert die Seite immer wieder sehr zäh. So etwas ruft Ärger hervor, weil unbekannt ist, wie lange die Wartzeit ist, und warum man überhaupt auf Reaktivität der Seite warten muss.

Schon aus Eigennutz ist die Suchmaschine Google stark daran interessiert, ihre Besucher und Besucherinnen zu gut funktionierenden Websites zu führen, die dazu noch wertvollen Inhalt anbieten. Das mit dem Inhalt ist eine eigene komplexe Angelegenheit. Für die Performance-Messung von Websites zieht Google Daten heran, die als Felddaten und/oder auch als Labdaten erfasst werden.

Felddaten sind solche Messwerte, die bei realen Benutzern und Benutzerinnen auftreten, wenn sie eine Website besuchen. Labdaten werden dagegen unter Verwenden von Tools gemessen, um einen Seitenaufbau in einer konsistenten, kontrollierten Umgebung zu simulieren. Das Google Pagespeed Tool zeigt beide Arten unter der Bezeichnung Core Web Vitals-Messwerte für Webseiten an.

Wesentliche Core Web Vitals-Messwerte

Der Google Artikel Nutzerorientierte Leistungsmesswerte fasst Messwerte zusammen, die vom Google Pagespeed Tool für Websites angezeigt werden.

• First Contentful Paint (FCP):
  • Misst die Zeit vom Beginn des Ladens der Seite bis zu dem Zeitpunkt, zu dem ein beliebiger Teil des Seiteninhalts auf dem Bildschirm gerendert wird. (Lab, Feld)
• Largest Contentful Paint (LCP):
  • Misst die Zeit vom Beginn des Ladens der Seite bis zum Rendern des größten Textblocks oder Bildelements auf dem Bildschirm. (Lab, Feld)
• First Input Delay (FID):
  • Misst die Zeit ab der ersten Interaktion von Nutzern mit der Website (wenn er/sie auf einen Link klickt, auf eine Schaltfläche tippt oder ein benutzerdefiniertes, mit JavaScript gesteuertes Steuerelement verwendet) bis zu dem Zeitpunkt, zu dem der Browser tatsächlich auf diese Interaktion reagieren kann. (Feld)
• Zeit bis Interaktivität (Time to Interactive, TTI):
  • Gibt die Zeit vom Beginn des Ladens der Seite bis zu ihrer visuellen Darstellung, dem Laden der ersten Skripts (falls vorhanden) und der Fähigkeit an, zuverlässig auf Nutzereingaben zu reagieren. (Lab)
• Total Blocking Time (TBT):
  • Misst die Gesamtzeit zwischen FCP und TTI, während der der Hauptthread lange genug blockiert wurde, um die Reaktionsfähigkeit von Eingaben zu verhindern. (Lab)
• Cumulative Layout Shift (CLS):
  • Misst die kumulative Punktzahl aller unerwarteten Layoutverschiebungen, die zwischen dem Laden der Seite und dem Wechsel ihres Lebenszyklus in „Ausgeblendet“ auftreten. (Lab, Feld)
• Time to First Byte (TTFB):
  • Misst die Zeit, die das Netzwerk benötigt, um auf eine Nutzeranfrage mit dem ersten Byte einer Ressource zu antworten. (Lab, Feld)

Interaction to Next Paint (INP)

Neu ist ab März 2024 nun der Core Web Vitals-Messwert Interaction to Next Paint (INP), der First Input Delay ersetzen wird. INP ist ein Messwert, mit dem die Reaktionszeit einer Seite auf Nutzerinteraktionen insgesamt bewertet wird. Dazu wird im Gegensatz zum First Input Delay die Latenz aller Klick-, Tipp- und Tastaturinteraktionen während der Lebensdauer des Besuchs eines Nutzers auf einer Seite erfasst. Der endgültige INP-Wert ist dann die längste beobachtete Interaktion, wobei Ausreißer ignoriert werden sollen.

Für INP werden dabei die folgenden Interaktionstypen beobachtet:

• Klicken mit der Maus
• Tippen auf ein Gerät mit Touchscreen
• Drücken einer Taste auf einer physischen oder auf einer Bildschirmtastatur

Wie kann der INP-Messwert optimiert werden?

Bereits während des Ladens einer Seite kann die INP von Bedeutung sein. Lädt zum Beispiel eine Seite noch das für die sogenannten Event Handler benötigte JavaScript, und ein Nutzer führt eine Interaktion wie einen Klick auf einen Button aus, kann es zu Verzögerungen kommen. Für eine gute Nutzererfahrung sollten Websites eine Interaction to Next Paint von maximal 200 Millisekunden anstreben. Das zu erreichen erfordert allerdings ein gewisses technisches Verständnis.

Zur Verbesserung der INP bereits während des Startvorgangs einer Webseite bieten sich verschiedene Maßnahmen wie zum Beispiel das Entfernen nicht benötigten JavaScript-Codes, das Aufteilen von Code oder das Entfernen von langsamem Code an, der von Drittanbietern stammt. Das können Skripte für Tracking oder Anzeigen sein.

Nach dem Start einer Seite könnte das verzögerte Ausführen von Aufgaben, die nicht rasend wichtig sind, eine sinnvolle Verbesserungsmaßnahme sein. Und natürlich sollte grundsätzlich nach langsamem JavaScript-Code von Drittanbietern gesucht werden. Vielleicht gibt es besseren Ersatz dafür?

Erste Hinweise

Kürzere Seiten benötigen vermutlich auch weniger HTML-Knoten (kleiners DOM). Unterteilen Sie sehr lange Seiten in Unterseiten.

Vermeiden Sie Page Builder, wenn es möglich ist. Natürlich bringen Plugins wie Elementor oder Divi viele Gestaltungsmöglichkeiten mit, aber gewünschte Darstellungen lassen sich vielleicht auch anders erreichen. Page Builder vergrößern das DOM enorm, damit die Möglichkeiten nutzbar sind.

Reduzieren Sie das Menü für Smartphones. Erweiterte (Advanced) Menüs benötigen relativ viel Rechenpower, vielleicht genügt ein einfacheres Menü für Mobilgeräte?

Technisch Interessierte finden genauere Informationen zur INP-Optimierung im Google Developer Bereich.

Einen möglicherweise einfacher verständlichen Artikel finden Sie im Blog der Entwickler des Themes Blocksy.