Your cart is empty

SEO

Current Quickstarts

joomla 4 quickstart packages
Various extensions can be selected!

-  English translation coming soon!  -

 

Core Web Vitals

When it comes to measuring the speed of a website, one comes across the term "Core Web Vitals" from Google, see "Google Search Console" (GSC). These were introduced in 2021. They are now considered another ranking factor, which is why you should definitely deal with them. But what exactly is meant by the "Core Web Vitals"?

The "Core Web Vitals" are a combination of 3 individual metrics:

  • Largest Contentful Paint (LCP)
  • First Input Delay (FID) 
  • Cumulative Layout Shift (CLS)

 

These metrics are used to analyze load speed, responsiveness, and visual stability of a page, and then generate the "Core Web Vitals" report.
This results in a rating for each URL:

  • good
  • optimization required
  • poor

 
This rating, in turn, is necessary for the "User Experience Report". Without this rating, a URL cannot be displayed in the "User Experience Report".
At this point it should be mentioned that the data from the "Core Web Vitals" report is usually only imported into the "User Experience Report" after a few days. Accordingly, the rating of a URL can be displayed there with a slight delay.

A "good" Core Web Vitals rating is required for a "good" status in the Usability Report.

But let's take a look at the "Core Web Vitals" in detail!

 

What are the Core Web Vitals?

 
Largest Contentful Paint (LCP)
This metric indicates how quickly a page loads on a screen (smartphone, tablet, desktop) and the visitor sees the portion of the page visible to them without scrolling the page. The speed (loading time) is therefore measured.

First Input Delay (FID)
This metric indicates how quickly a website responds to user input (such as tapping a button or entering data into a field). -> Responsiveness (interactivity)

Cumulative Layout Shift (CLS)
This metric indicates whether the layout of the page shifts in a way that impacts the visitor's experience of the website. It also indicates the number of shifts that the visitor sees. So the visual stability on the page is measured (layout shift).

Thresholds for the individual ratings

  good optimization
required
poor
LCP ≤ 2.5 s 2.5 - 4 s > 4 s
FID ≤ 100ms 100 - 300ms > 300ms
CLS ≤ 0.1 0.1 - 0.25 > 0.25

 

Note: Since "Mobile Web" and "Desktop Web" have different limitations for users (e.g. device, viewport size, network connection, etc.), both versions are analyzed independently. Accordingly, there are values for mobile devices as well as for desktop computers.

 

How to measure Core Web Vitals?

 
The following providers can display the Core Web Vitals:

  • Google Search Console
  • Google PageSpeed Insights
  • Semrush Site Audit
  • GTmetrix
  • Lighthouse

There are also the following options:

  • Chrome DevTools
  • Chrome UX Report
  • Web Vitals Extension

 

Please note! It may be that some tools show errors while others don't show errors. For example, the "Google Search Console" shows a page's performance based on the real-world usage data from the CrUX report, while Lighthouse uses the so-called "lab data". Because "lab data" is collected in a controlled environment, it can be used to troubleshoot performance issues during the development phase of a website. Bottlenecks in the real world may not be captured. Thus, the information each report provides is different.

 

Bad Core Web Vitals?

What if a page doesn't meet the advertised performance metrics from Core Web Vitals?
Still, a page's content and its correspondence to the information a user is looking for is certainly a very strong signal for ranking. Good performance metrics are useless if no one is interested in the information on a web page and a page is therefore not clicked on in the first place. On the other hand, the "Core Web Vitals" shouldn't be so bad that visitors leave the website immediately, for example because it takes a long time to load.

 

Optimize Core Web Vitals!

Improving the metrics of a website requires web development skills. It can therefore make sense to contact a specialist if you do not have this knowledge. Below are some tips on possible causes of bad "Core Web Vitals" and how to optimize them.
 

Optimate Largest Contentful Paint (LCP)

Possible causes for bad LCP values:

  • Slow server / long response time
  • JS und CSS block rendering
  • Slow loading resources such as images, videos, widgets, social media buttons, newsletters...

 
Optimization measures:

  • Use a suitable server with modern and fast technology
  • Combine and compress JS and CSS files and remove unnecessary files
  • Asynchronous loading of resources
  • Optimize images and videos in terms of number, size and format. Use lazy load
  • Show placeholders instead of videos
  • Minimize http requests
  • Use caches
  • Use Content Delivery Network (CDN) if the website has a lot of international visitors
  • Load unnecessary widgets and co. later

 

Optimate First Input Delay (FID)

Mögliche Ursachen für schlechte FID-Werte:

  • Lange Hauptthread-Aufgaben im JavaScript
  • Lange JS-Ausführungszeit
  • Große JavaScript-Pakete
  • JavaScript, welches das Rendering blockiert

 
Optimierungsmaßnahmen:

  • Anzahl der geladenen Skripte reduzieren
  • Längere Tasks in kleinere Tasks aufteilen
  • Ausführungszeit von JavaScipt reduzieren
  • Third-party Tags: Wenn möglich, laden on demand

 

Optimate Cummulative Layout Shift (CLS)

Mögliche Ursachen für schlechte CLS-Werte:

  • Bilder, Videos und Iframes ohne Größenangaben
  • Werbeanzeigen, die das Layout verschieben
  • Cookie-Banner
  • Webfonts, die FOIT bzw. FOUT verursachen

 
Optimierungsmaßnahmen:

  • Bilder, Videos und Iframes mit Größenatrributen versehen
  • Inhalte nicht überlagern
  • CSS-Eigenschaft "font-display" nutzen
  • Fonts preloaden. Achtung: Performance verschlechtert sich

 

More performance values

 
Außer den "Web Core Vitals" gibt es eine Reihe weiterer Performance-Werte, die bei der Analyse einer Seite von Nutzen sind.
 

Total Blocking Time (TBT)

"Total Blocking Time" (Gesamtsperrzeit) misst die Gesamtzeit, in der eine Seite blockiert wird. In dieser Zeit kann der Benutzer nicht mit der Seite interagieren. Diese Metrik wurde von Lighthouse eingeführt. Sie kann als Ersatz für die FID-Metrik angesehen werden, wie sie beispielsweise in PageSpeed Insights verwendet wird.

TBT hat einen großen Einfluss auf die Bewertung einer Seite und ist damit eine der wichtigsten zu optimierenden Metriken. Durch deren Optimierung kann die Reaktionsfähigkeit einer Seite wirkungsvoll verbessert werden.

Genaugenommen ist "Total Blocking Time" die Gesamtzeit zwischen "First Contentful Paint" (FCP) und "Time to Interactive" (TTI), bei der der Main-Thread lange genug blockiert war, um die Reaktionsfähigkeit der Eingabe zu verhindern. Der Main-Thread wird vom Browser verwendet, um HTML zu analysieren, das DOM zu konstruieren, CSS und JS auszuführen, sowie Benutzerereignisse zu verarbeiten und weitere Aufgaben auszuführen. Der Main-Thread gilt als "blockiert", wenn einer der Tasks länger als 50ms andauert. Ein laufender Task kann vom Browser nicht unterbrochen werden. Solange der Main-Thread blockiert ist, kann eine Webseite nicht auf Eingaben von Benutzern reagieren (z.B. Mausklicks, Tastaturklicks, ... usw.).
Die Zeiten, welche die 50ms jeweils überschreiten, werden als Sperrzeiten (Blockierzeiten) bezeichnet. Aus ihrer Summe ergibt sich die Gesamtsperrzeit einer Seite.

Grenzwerte für "Total Blocking Time" (TBT)

  Gut Mäßig Schlecht
TBT < 300ms 300 - 600ms > 600ms

 

Optimierungsmaßnahmen

Um die "Total Blocking Time" (TBT) zu minimieren, gibt es mehrere Möglichkeiten. Im Prinzip greifen hier die gleichen Verbesserungsmaßnahmen (JS-Optimierung) wie für die "First Input Delay"-Metrik. Details siehe oben auf der Seite unter der Überschrift "Core Web Vitals optimieren!"!

Unterschied zwischen "Total Blocking Time" und "First Input Delay"

Wie bereits erwähnt wurde, ist "Total Blocking Time" (TBT) ein Ersatz für "First Input Delay" (FID), welches zu den "Core Web Vitals" gehört. FID ist eine Feldmetrik, für deren Messung echte Benutzerdaten herangezogen werden. Diese stammen aus dem Chrome User Experience Report (CrUX), dessen Daten von echten Chrome-Benutzern gesammelt werden.

Unterschied zwischen "Total Blocking Time" und "Time to Interactive"

"Time to Interactive" (TTI) ist ein weiterer Wert, der sich auf die Interaktivität einer Seite bezieht:

  • TTI signalisiert, wenn eine Seite vollständig interaktiv ist
  • TTI betrachtet eine Seite als vollständig interaktiv, sobald der Main-Thread mind. 5s frei von langen Tasks (Aufgaben) war

TBT hingegen gibt genau an, welche JS-Aufgaben am längsten zur Ausführung benötigt haben.

 

Time To First Byte (TTFB)

"Time to First Byte" (TTFB) ist die Gesamtzeit vom Start einer Anfrage (Request) bis zum Erhalt des ersten Bytes der Antwort. Sie ist die Summe aus Weiterleitungsdauer (Redirect Duration) + Verbindungsdauer (Connection Duration) + Backend-Dauer (Backend-Duration). Diese Metrik ist einer der Schlüsselindikatoren für die Webperformance.

Erklärungen:

  • Redirect Duration: Zeit für Weiterleitung von example.com zu www.example.com, oder http zu https, oder zu einer mobilen Version oder einer Sprachversion einer Seite
  • Connection Duration: Zeit, die benötigt wird, um eine Verbindung zum Server herzustellen, um die Anforderung an die Seite zu senden. Die Verbindungsdauer ist meist die Kombination aus Sperrzeit, DNS-Zeit, Verbindungszeit und Sendezeit der Anfrage.
  • Backend Duration: Nach der Anfrage generiert der Server eine Antwort für die Seite. Die Zeit, die dazu benötigt wird, wird als Backend-Dauer bezeichnet.


Optimierungsmaßnahmen
:

  • Optimierung des Codes
  • Nutzung von Caching
  • Aktualisieren der Serverhardware
  • Feinabstimmung der Webserverkonfiguration

 

First Paint

Als "First Paint" bezeichnet man den Zeitpunkt, an dem der Browser mit dem Rendern einer Seite beginnt. Der Browser zeigt dann lediglich eine leere Seite an. Für den Besucher der Webseite ist das ein Indikator dafür, dass die Seite nun geladen wird. Ansonsten hat "First Paint" keine weitere Relevanz.

 

First Contentful Paint (FCP)

"First Contentful Paint" misst, wie schnell Besucher einer Webseite das erste Inhaltselement (d. h. Text, Bilder, Videos usw.) angezeigt bekommen. Hierbei kann es sich z.B. um Überschriften, Texte, Bilder ... usw. handeln.

Genaugenommen ist "First Contentful Paint" die Gesamtzeit vom Beginn des Ladens einer Seite bis zum Rendern von Inhalten auf dem Bildschirm. Inhalt der schnell ausgeliefert wird (niedrige FCP-Zeit), trägt zu einer positiven Nutzererfahrung bei.

 

DOM Interactive Time

Als "DOM Interactive Time" bezeichnet man den Zeitpunkt, an dem der Browser das Laden und Parsen von HTML abgeschlossen hat, und die DOM-Baumstruktur erstellt wurde. DOM = Document Object Model

 

DOM Content Loaded Time

Als "DOM Content Loaded Time" bezeichnet man den Zeitpunkt, an dem das DOM bereit ist, und es keine Stylesheets gibt, die die JS-Ausführung blockieren.

Falls keine Stylesheets die JS-Ausführung blockieren und auch kein Parser JavaScript blockiert, dann ist "DOM Content Loaded Time" übrigens dasselbe wie "DOM Interactive Time".

Wichtig: Es ist wichtig, dass die Stil- und Skriptreihenfolge optimiert und das Parsen von JavaScript verzögert wird. Ansonsten kann es zu Verzögerungen beim Rendern kommen.

Alternative Ausdrücke: DOM Loaded, DOM Ready

 

Onload Time

Unter "Onload Time" versteht man den Zeitpunkt, an dem die Verarbeitung einer Seite abgeschlossen ist und somit alle Ressourcen (z.B. CSS, Bilder, ... usw.) heruntergeladen wurden. Dann löst die Seite das JS-Triggerereignis "windows.onload" aus.

Allerdings kann es JavaScript geben, das nachfolgende Anforderungen für weitere Ressourcen auslöst. "Onload Time" kann eine Seite deshalb unter Umständen langsamer als auch schneller angeben als sie in Wirklichkeit ist. "Fully Loaded Time" ist da aussagekräftiger.

 

Fully Loaded Time

Als "Fully Loaded Time" versteht man den Zeitpunkt, nachdem alle der folgenden Ereignisse eingetreten sind:

  • First Contentful Paint hat "gefeuert"
  • Onload hat "gefeuert"
  • Netzwerk und CPU sind im Leerlauf (5,25s)

In älteren Berichten wird die vollständig geladene Zeit gemessen, wenn:

  • Onload hat "gefeuert"
  • Netzwerk ist inaktiv (2s)

Es gibt eine feste Zeit von 30s, nachdem Onload "gefeuert" wurde.

Wenn die oben genannten Bedingungen erfüllt sind, verwendet beispielsweise GTmetrix die maximalen Werte von

  • First Paint
  • First Contentful Paint
  • Onload Time
  • Largest Contentful Paint
  • Total Time to Interactive
  • Last request captured

 
Im Wesentlichen wartet GTmetrix mit dem Abschluss eines Tests, bis Ihre Seite die Datenübertragung beendet, was zu konsistenteren Seitenladezeiten führt.

Dennoch kann es zu verschiedenen Problemen kommen, auf die an dieser Stelle nicht näher eingegangen werden soll. Die "Fully Loaded Time" ist deshalb möglicherweise kein optimaler Indikator für die vom Benutzer wahrgenommene Performance. Man sollte sich deshalb besser auf  die Optimierung der 6 Leistungsbewertungsmetriken konzentrieren.

"Fully Loaded Time" in Legacy-Berichten

Legacy-Berichte (veraltet) haben eine etwas andere Definition für die "Fully Loaded Time", da sie die Metrik "Time to Interactive" nicht messen. Unter "Fully Loaded Time" versteht man hier den Zeitpunkt nach 2 Sekunden Netzwerkinaktivität nachdem das Onload-Ereignis ausgelöst wurde.

Aufgrund der unterschiedlichen Definitionen wird die "Fully Loaded Time" in einem Legacy-Bericht möglicherweise nicht mit der Zeit im neuen Bericht (z.B. von GTmetrix) übereinstimmen.

Notes

All prices quoted in Euro include the statutory German VAT of currently 19%. The final price can change after entering the billing information, for example if the order is placed as a company. The prices refer to the creation of the Quickstart packages.
More

Joominator.de gehört nicht zu The Joomla! Project ™ und wird auch nicht durch dieses unterstützt. Die Verwendung des Joomla!® -Namens, -Symbols, -Logos und der zugehörigen Marken ist im Rahmen einer von Open Source Matters, Inc. gewährten beschränkten Lizenz gestattet.
Joominator.de is not affiliated with or endorsed by The Joomla! Project™. Use of the Joomla!® name, symbol, logo and related trademarks is permitted under a limited license granted by Open Source Matters, Inc.

Joomla Logo