Web Performance: Core Web Vitals richtig verstehen und verbessern

Schnelle Seiten werden von Menschen als angenehm erlebt und von Suchmaschinen als Qualitätssignal gewertet. Gleichzeitig kursieren viele Missverständnisse: Ein perfekter Testwert im Labor sagt wenig über das Erlebnis echter Besucher auf echten Geräten, und Performance ist nur eines von vielen Signalen für Rankings. Dieser Artikel erklärt die Messgrößen, die heute zählen, zeigt, womit du am meisten erreichst, und enthält ein Beispiel aus unserer eigenen Seite.

Die Messgrößen: Core Web Vitals

Die Core Web Vitals messen drei Aspekte des Nutzererlebnisses. Als „gut“ gelten diese Werte (Stand: Oktober 2026):

• LCP (Largest Contentful Paint): Wann ist das größte sichtbare Element fertig geladen, oft ein Titelbild oder eine große Überschrift? Gut: unter 2,5 Sekunden.
• INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Eingaben wie Klicks und Tastendrücke? Gut: unter 200 Millisekunden. INP hat 2024 den früheren Wert First Input Delay abgelöst.
• CLS (Cumulative Layout Shift): Springen Elemente beim Laden? Gut: unter 0,1.

Ergänzend ist die Server-Antwortzeit (TTFB) nützlich: Als gut gilt ein Wert von höchstens etwa 0,8 Sekunden. Sie ist keine Core Web Vital, beeinflusst aber LCP.

Labor- und Felddaten

Labordaten (zum Beispiel Lighthouse) entstehen in einer kontrollierten Umgebung: reproduzierbar, gut zum Finden von Ursachen. Felddaten stammen von echten Besuchern auf deren Geräten und Verbindungen, etwa aus dem Chrome User Experience Report, der Google Search Console (Bericht „Core Web Vitals“) oder eigenem Monitoring. Sie weichen oft ab. Wer nur den Lighthouse-Wert optimiert, löst womöglich nicht das Problem, das Besucher wirklich haben. Neue Websites haben anfangs keine Felddaten, weil zu wenige Besuche vorliegen.

Womit du am meisten erreichst

Bilder: Oft der größte Hebel. Moderne Formate (WebP, AVIF), passende Größen statt riesiger Originale, width und height setzen, Bilder unterhalb des sichtbaren Bereichs verzögert laden (loading="lazy"), das wichtigste Bild im oberen Bereich dagegen nicht verzögern und bei Bedarf priorisieren.

Schriften: Lade nur die Schriftschnitte, die du brauchst. Mit preload laden kritische Schriften früher, und eine Ersatzschrift mit passenden Maßen verhindert, dass Text beim Nachladen springt.

CSS und JavaScript: Entferne Unnötiges, lade Skripte mit defer oder async, teile große Pakete auf und binde Skripte von Drittanbietern (Tracking, Chat, Videos) nur ein, wenn sie sich lohnen. Jedes Skript kostet Zeit.

Server und Auslieferung: Aktiviere Kompression (gzip oder Brotli), nutze Caching mit langen Laufzeiten für Dateien mit Hash im Namen und kurzen Laufzeiten für HTML. Ein CDN kann die Entfernung zu Besuchern verkürzen. Statisch erzeugte Seiten sind oft schneller als jede Seite, die bei jedem Aufruf neu berechnet wird.

Reihenfolge: Beginne mit Messung, dann mit dem, was am meisten Zeit kostet. Meist sind das Bilder, danach Schriften und Skripte, zuletzt Feintuning.

Ein Beispiel aus unserer eigenen Seite

Auf einer unserer Seiten mit vielen Bildern zeigte ein Test mit gedrosselter Mobilverbindung einen Layout-Sprung (CLS 0,14, also knapp über dem Grenzwert). Die Ursache war die Schrift, die nach dem ersten Zeichnen nachlud und den Text umbrechen ließ. Die Lösung hatte zwei Teile: die Schriftdateien früh vorladen und eine Ersatzschrift mit denselben Zeilenmaßen definieren. Danach lag der Wert bei 0. Das ist ein Einzelfall, aber er zeigt das Prinzip: erst messen, die Ursache finden, dann gezielt eingreifen.

Mythen

• „Ein Lighthouse-Wert von 100 heißt, alles ist gut.“ Er sagt nur etwas über einen Testlauf aus. Prüfe auch Felddaten.
• „Performance entscheidet über das Ranking.“ Sie ist ein Signal unter vielen. Inhaltliche Relevanz zählt in der Regel stärker. Sie verbessert aber Nutzererlebnis und Absprungraten.
• „Ein Plugin löst alles.“ Optimierungs-Plugins helfen, ersetzen aber keine saubere Umsetzung.

Performance-Checkliste

1. Core Web Vitals und TTFB messen (Labor und Feld).
2. Bilder prüfen: Format, Größe, Abmessungen, Lazy Loading, wichtigstes Bild nicht verzögern.
3. Schriften: wenige Schnitte, früh laden, Ersatzschrift mit passenden Maßen.
4. Skripte reduzieren, Drittanbieter prüfen, defer/async nutzen.
5. Kompression und Caching einrichten.
6. Layout-Sprünge suchen (Elemente ohne feste Größe, nachgeladene Inhalte).
7. Ergebnisse in Search Console und PageSpeed Insights beobachten.
8. Ein Performance-Budget festlegen und bei jeder Änderung prüfen.

Kurz beantwortet

Welche Kennzahl ist am wichtigsten? Das hängt vom Problem ab. Meist sind es LCP und CLS, bei interaktiven Anwendungen auch INP.

Wie oft sollte ich messen? Nach jeder größeren Änderung und regelmäßig im Betrieb, zum Beispiel monatlich in der Search Console.

Lohnt sich das für kleine Websites? Ja. Gerade dort sind Bilder, Schriften und Skripte oft mit wenig Aufwand deutlich zu verbessern.

Fazit

Gute Performance entsteht durch Messen, die richtigen Hebel und Pflege, nicht durch einen einmaligen Testwert. Wenn du Unterstützung bei Webentwicklung und Optimierung möchtest, findest du unser Angebot unter Entwicklung.