Alle Artikel

Design

Wie beeinflusst Ladegeschwindigkeit die Nutzererfahrung?

Was die Core Web Vitals LCP, INP und CLS messen, welche Grenzwerte als gut gelten und welche typischen Ursachen langsame Websites haben

Elijah NhekVeröffentlicht am 4 Min. Lesezeit
Hand hält ein Smartphone mit einer ladenden Website vor einem unscharfen Café-Hintergrund
Inhalt dieses Artikels

Ladegeschwindigkeit prägt den ersten Eindruck einer Website, noch bevor jemand einen Satz gelesen hat. Wenn der Hauptinhalt lange auf sich warten lässt, Schaltflächen träge reagieren oder der Text beim Laden verrutscht, wirkt die Seite unzuverlässig. Google fasst diese Erfahrung in drei Kennzahlen zusammen, den Core Web Vitals. Sie zeigen ziemlich genau, wo es hakt.

Die drei Core Web Vitals im Überblick

Laut web.dev, der Entwicklerplattform von Google, gelten diese Werte als gut:

Kennzahl Was sie misst Gut
LCP, Largest Contentful Paint Wann der grösste sichtbare Inhalt geladen ist bis 2,5 Sekunden
INP, Interaction to Next Paint Wie schnell die Seite auf Klicks, Tippen und Tastatur reagiert bis 200 Millisekunden
CLS, Cumulative Layout Shift Wie stark sich Inhalte beim Laden verschieben bis 0,1

Gemessen wird beim 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Vereinfacht gesagt: Drei von vier Besuchen sollten die Grenzwerte einhalten. INP hat 2024 den früheren Wert First Input Delay (FID) als Core Web Vital abgelöst. Für INP nennt web.dev ausserdem eine Zwischenstufe: Über 200 bis 500 Millisekunden gelten als verbesserungswürdig, darüber als schlecht.

Was die Werte für Ihre Besucher bedeuten

Hinter den Abkürzungen stecken alltägliche Situationen:

  • LCP: Jemand öffnet Ihre Website auf dem Smartphone und sieht zunächst nur eine leere Fläche, wo das grosse Titelbild hingehört.
  • INP: Jemand tippt auf "Menü" und es passiert scheinbar nichts. Also tippt die Person noch einmal.
  • CLS: Jemand will auf "Offerte anfragen" tippen, doch im letzten Moment schiebt sich ein Banner hinein und der Finger landet woanders.

Jede dieser Situationen kostet Geduld. Aus unserer Sicht ist das der wichtigste Grund, sich mit Ladezeit zu beschäftigen, unabhängig von Suchmaschinen.

Felddaten und Labordaten: zwei Blickwinkel

web.dev unterscheidet zwei Arten von Messungen:

  • Felddaten stammen von echten Besuchen und zeigen die Vielfalt an Geräten und Netzen. Quellen sind der Chrome User Experience Report (CrUX), PageSpeed Insights und der Core-Web-Vitals-Bericht in der Google Search Console.
  • Labordaten entstehen unter kontrollierten Bedingungen, etwa mit Lighthouse oder den Chrome DevTools. Sie eignen sich, um Probleme während der Entwicklung zu finden.

Ein Detail ist wichtig: Lighthouse kann INP nicht messen, weil im Labor niemand klickt. Es verwendet stattdessen die Total Blocking Time als Annäherung. Laut web.dev zeigt nur die Feldmessung das vollständige Bild. Liegen für Ihre Website noch keine Felddaten vor, helfen Labormessungen als Orientierung.

Typische Ursachen für einen langsamen LCP

web.dev teilt die Zeit bis zum LCP in vier Teile: die Antwortzeit des Servers, die Verzögerung bis die wichtige Ressource geladen wird, deren Ladedauer und die Verzögerung bis zur Darstellung. Daraus ergeben sich typische Ursachen und Lösungen:

  • Langsamer Server: Viele Weiterleitungen, fehlendes Caching oder ein weit entfernter Server verlängern die erste Antwort. Abhilfe schaffen effektives Caching, weniger Weiterleitungen und ein Content Delivery Network (CDN).
  • Zu grosse Bilder: Ein Titelbild in voller Kameraauflösung bremst jede Seite. Bilder sollten in passender Grösse, komprimiert und in modernen Formaten ausgeliefert werden.
  • Das wichtigste Bild wird zu spät entdeckt: Wird das Titelbild erst über CSS oder JavaScript geladen, beginnt der Download spät. Es sollte direkt im HTML stehen oder vorgeladen werden. Mit fetchpriority="high" lässt sich dem Browser signalisieren, dass dieses Bild Vorrang hat.
  • Lazy Loading am falschen Ort: Verzögertes Laden ist für Bilder weiter unten sinnvoll. Das LCP-Bild selbst sollte laut web.dev nicht verzögert geladen werden.
  • Blockierende Dateien: Grosse CSS-Dateien und synchrone Skripte im Kopfbereich halten die Darstellung auf.

Typische Ursachen für einen schlechten INP

Wenn eine Seite träge reagiert, liegt das laut web.dev vor allem an langen Aufgaben im Hauptthread des Browsers. Solange der Browser mit einem grossen Skript beschäftigt ist, kann er nicht auf einen Klick reagieren.

Mögliche Quellen solcher Aufgaben sind grosse Mengen JavaScript, zum Beispiel umfangreiche Frameworks, Animationen, Chat-Widgets, eingebettete Karten oder mehrere Tracking-Skripte gleichzeitig. Die Lösung ist selten ein einzelner Trick. Meist hilft es, nicht benötigte Skripte zu entfernen, grosse Aufgaben aufzuteilen und Drittanbieter-Elemente erst zu laden, wenn sie gebraucht werden.

Typische Ursachen für einen hohen CLS

Layoutverschiebungen sind oft am einfachsten zu beheben. web.dev nennt diese häufigen Ursachen:

  • Bilder ohne Grössenangabe: Der Browser weiss nicht, wie viel Platz er reservieren soll. Abhilfe: width und height angeben oder aspect-ratio in CSS verwenden.
  • Werbung, Einbettungen und iframes: Auch hier vorab Platz reservieren.
  • Nachträglich eingefügte Inhalte: Banner oder Hinweise, die oben in den Inhalt geschoben werden. Besser ist es, sie als Überlagerung anzuzeigen oder Platz freizuhalten.
  • Webschriften: Wenn die Ersatzschrift deutlich anders aussieht als die eigentliche Schrift, springt der Text beim Wechsel. Passende Ersatzschriften und das Vorladen wichtiger Schriften helfen.
  • Animationen: Animationen mit transform verschieben das Layout nicht, Animationen von Eigenschaften wie top oder left hingegen schon.

So gehen Sie vor

  • Prüfen Sie Ihre wichtigsten Seiten mit PageSpeed Insights, besonders die Ansicht für Mobilgeräte.
  • Wenn Sie die Google Search Console nutzen, schauen Sie in den Bericht zu den Core Web Vitals.
  • Beginnen Sie mit dem schlechtesten der drei Werte und dort mit der Startseite und Ihren wichtigsten Leistungsseiten.
  • Testen Sie nach jeder Änderung erneut.

Ladezeit hängt eng mit der Darstellung auf dem Smartphone zusammen. Lesen Sie dazu auch Was ist Responsive Design? Warum Technik und Gestaltung zusammengehören, beschreiben wir im Artikel Eine schöne Website genügt nicht.

Fazit

Ladegeschwindigkeit ist kein abstrakter Technikwert, sondern spürbare Nutzererfahrung. Die Core Web Vitals geben klare Ziele vor: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1. Die häufigsten Ursachen sind zu grosse Bilder, zu viel JavaScript und fehlende Platzreservierungen, und sie lassen sich meist gezielt beheben. Wenn Sie wissen möchten, wie Ihre Website abschneidet und was sich verbessern lässt, finden Sie unter Leistungen unseren Ansatz.

Häufige Fragen

Was ist ein guter Wert für die Ladezeit?
Google beschreibt drei Kennzahlen: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1. Gemessen wird beim 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop.
Warum zeigt Lighthouse andere Werte als PageSpeed Insights?
Lighthouse misst im Labor unter festen Bedingungen. PageSpeed Insights zeigt, sofern vorhanden, zusätzlich Felddaten echter Besuche. Beide sind nützlich, aber nur Felddaten zeigen das ganze Bild.
Wird meine Website durch bessere Werte automatisch besser gefunden?
Das lässt sich nicht garantieren. Gute Werte verbessern vor allem das Erlebnis für Ihre Besucherinnen und Besucher.

Quellen

Elijah Nhek

Software Engineer und Gründer von WEBLILO in Luzern. Entwickelt Websites und Software für Unternehmen in der Schweiz

LinkedIn(öffnet in neuem Tab)

Fragen zu Ihrem eigenen Projekt?

Wir beraten Sie persönlich und unverbindlich

Projekt besprechen