PERFORMANCE
Core Web Vitals sollte man verbessern, wenn sie ein echtes Nutzerproblem sichtbar machen: Der Hauptinhalt erscheint zu spät, Interaktionen reagieren verzögert oder das Layout verschiebt sich, während jemand die Seite benutzt. Sie sind kein Grund, eine halbe Website neu aufzubauen, nur um einen PageSpeed-Insights-Wert von 93 auf 100 zu bringen.
Kurzantwort
Googles drei Core Web Vitals sind LCP, INP und CLS. Als „gut“ gelten LCP bis 2,5 Sekunden, INP bis 200 ms und CLS bis 0,1. Die Core-Web-Vitals-Bewertung basiert auf realen Nutzerdaten und auf dem 75. Perzentil – nicht auf einem einzelnen Test auf dem eigenen Computer.
Was sind Core Web Vitals?
Core Web Vitals sind Kennzahlen für drei wichtige Aspekte der Seitenerfahrung: wie schnell der wichtigste sichtbare Inhalt erscheint, wie schnell die Seite auf eine Interaktion reagiert und wie stabil das Layout während des Ladens bleibt.
1. LCP – Largest Contentful Paint
LCP misst, wann das größte relevante Inhaltselement im sichtbaren Bereich gerendert wurde. Auf einer Unternehmenswebsite ist das häufig ein Hero-Bild, ein großer Textblock oder ein zentrales visuelles Element.
Typische Ursachen für einen schwachen LCP
- große, nicht optimierte Hero-Bilder
- langsamer Server oder hoher TTFB
- render-blockierendes CSS/JavaScript
- spät geladene Webfonts
- Hero-Medien, die erst über JavaScript gestartet werden
- zu viele externe Ressourcen
Was sollte man zuerst tun?
Identifiziere das tatsächliche LCP-Element und optimiere genau dessen Ladepfad. Eine allgemeine Liste von Performance-Tricks hilft weniger als die Frage, welches Element auf dieser konkreten Seite den LCP bestimmt.
2. INP – Interaction to Next Paint
INP beschreibt, wie reaktionsfähig eine Seite auf Nutzerinteraktionen ist. Gemessen wird die Verzögerung zwischen einer Interaktion – etwa Klick, Tap oder Tastatureingabe – und dem nächsten sichtbaren Update der Oberfläche.
Häufige Ursachen für einen hohen INP
- lange JavaScript-Aufgaben auf dem Main Thread
- zu viele Event Listener oder schwere Handler
- umfangreiche Third-Party-Skripte
- komplexe DOM-Updates
- schwere Widgets und Builder-Code
- unnötige Animationen während wichtiger Interaktionen
Praktische Regel
Wichtige Aktionen – Menü öffnen, Formular bedienen, Produktvariante wählen oder Checkout-Schritt wechseln – sollten sofort verständlich reagieren.
3. CLS – Cumulative Layout Shift
CLS misst unerwartete Layoutverschiebungen. Problematisch ist zum Beispiel, wenn ein Button nach unten springt, während jemand darauf klicken will, oder wenn ein Bild ohne reservierten Platz nachgeladen wird und den Text verschiebt.
Typische Ursachen
- Bilder oder Videos ohne feste Abmessungen beziehungsweise Seitenverhältnis
- Werbe- oder Cookie-Elemente, die nachträglich Platz einnehmen
- Webfonts mit stark abweichenden Fallback-Metriken
- dynamisch eingefügter Content oberhalb bereits sichtbarer Inhalte
- spät geladene Banner oder Widgets
Lab-Daten und Felddaten sind nicht dasselbe
Ein Lighthouse- oder PageSpeed-Test simuliert eine bestimmte Umgebung. Felddaten zeigen, was echte Nutzer über einen längeren Zeitraum erleben. Eine Seite kann im Labortest sehr gut aussehen und trotzdem Probleme in realen Daten haben – oder umgekehrt.
Welche Daten sind wichtiger?
Für die offizielle Core-Web-Vitals-Bewertung sind Felddaten entscheidend. Labordaten sind vor allem hilfreich, um Ursachen zu diagnostizieren und Änderungen zu testen.
Warum der 75. Perzentil wichtig ist
Google bewertet nicht nur den Durchschnitt. Das 75. Perzentil bedeutet vereinfacht: Mindestens 75 % der gemessenen Seitenaufrufe sollten innerhalb des guten Schwellenwerts liegen.
PageSpeed 100 ist kein Geschäftsziel
Ein Score von 100 kann angenehm sein, ist aber kein Selbstzweck. Eine Seite mit 95 Punkten, klarer UX, gutem Content und stabiler Conversion kann geschäftlich deutlich besser sein als eine extrem reduzierte 100-Punkte-Seite, die wichtige Funktionen verloren hat.
Was sollte man zuerst optimieren?
- Echte Probleme identifizieren: Felddaten, Search Console und wichtige Templates prüfen.
- Betroffene Seitentypen bestimmen: Homepage, Service-Seite, Produktseite, Checkout usw.
- Das konkrete Element beziehungsweise Skript finden: nicht pauschal alles reduzieren.
- Änderung umsetzen: Bilder, CSS, JS, Fonts oder Serverpfad gezielt verbessern.
- Regressionen vermeiden: Funktionalität und Conversion nach der Änderung testen.
Bilder und LCP
Hero-Bilder sollten in passender Größe ausgeliefert, sinnvoll komprimiert und nicht unnötig spät geladen werden. Das LCP-Bild sollte nicht versehentlich lazy-loaded sein, wenn es direkt im ersten Viewport benötigt wird.
Fonts
Zu viele Schnitte und externe Font-Abhängigkeiten können den Renderpfad verlangsamen. Nutze nur die tatsächlich benötigten Varianten und achte auf sinnvolle Fallbacks.
JavaScript
Nicht jedes Skript muss vor dem ersten sichtbaren Inhalt geladen werden. Prüfe, welche Funktionen wirklich sofort benötigt werden und welche später oder nur auf bestimmten Seiten geladen werden können.
Third-Party-Skripte
Chat-Widgets, Tracking, Heatmaps, Review-Widgets, Ads und externe Embeds können Performance beeinflussen. Entferne nicht blind alles, sondern bewerte Nutzen und Kosten jeder Integration.
Server und TTFB
Wenn der Server langsam antwortet, kann Frontend-Optimierung allein das Problem nicht vollständig lösen. Hosting, Caching, Datenbank, PHP-Version und Backend-Logik können Teil der Diagnose sein.
Core Web Vitals auf Mobilgeräten
Mobile Nutzer haben oft schwächere Geräte und instabilere Verbindungen. Deshalb sollte man nicht nur auf einem leistungsfähigen Desktop testen. Besonders wichtig sind Hero-Medien, große Skripte, Menüs, Formulare und Interaktionen auf kleinen Screens.
Core Web Vitals und SEO
Core Web Vitals sind Teil der Seitenerfahrung, aber sie ersetzen keine relevanten Inhalte, saubere Indexierung oder eine gute Seitenarchitektur. Eine schnelle Seite ohne passende Suchintention wird nicht allein wegen ihrer Performance ranken.
Wann lohnt sich eine größere technische Überarbeitung?
Wenn Performance-Probleme strukturell aus Theme, Builder, Plugin-Last oder veralteter Architektur entstehen und kleine Optimierungen immer neue Workarounds erzeugen, kann ein sauberer Neuaufbau langfristig sinnvoller sein.
Wann reicht eine gezielte Optimierung?
Wenn nur einzelne Medien, Skripte, Fonts oder Templates problematisch sind und die Architektur grundsätzlich gesund ist, sollte man zuerst diese Ursachen beheben statt die ganze Website neu zu bauen.
Aus der FreenetPro-Praxis: Ursache statt Score optimieren
Wir behandeln Core Web Vitals nicht als Wettbewerb um eine Zahl. Entscheidend ist, welches Element die reale Nutzererfahrung bremst und ob die Verbesserung gleichzeitig Technik, UX und Geschäftsziel unterstützt.
Checkliste
- ☐ echte Felddaten geprüft
- ☐ LCP-Element identifiziert
- ☐ INP-Probleme auf wichtigen Interaktionen getestet
- ☐ Layoutverschiebungen auf Mobil und Desktop geprüft
- ☐ Hero-Bilder und Fonts optimiert
- ☐ unnötige Third-Party-Skripte bewertet
- ☐ Serverantwort geprüft
- ☐ wichtige Templates separat getestet
- ☐ Änderungen nach dem Launch erneut gemessen
FAQ
Was sind gute Core Web Vitals?
Als gut gelten LCP bis 2,5 Sekunden, INP bis 200 ms und CLS bis 0,1 – jeweils auf Basis der entsprechenden Felddaten.
Sind Core Web Vitals ein Rankingfaktor?
Sie sind Teil der Seitenerfahrung, aber nur ein Signal unter vielen. Relevanz, Content, Indexierung und Autorität bleiben entscheidend.
Muss PageSpeed Insights 100 anzeigen?
Nein. Ein Score von 100 ist kein notwendiges SEO- oder Geschäftsziel.
Was ist wichtiger: Lab- oder Felddaten?
Felddaten zeigen reale Nutzung und sind für die Core-Web-Vitals-Bewertung maßgeblich. Labordaten helfen bei der Diagnose.
Wie kann ich LCP verbessern?
Identifiziere das LCP-Element und optimiere Bild, Serverantwort, CSS/JS und den Ladepfad dieses Elements.
Wie kann ich INP verbessern?
Reduziere lange JavaScript-Aufgaben, schwere Event-Handler und unnötige Skripte auf wichtigen Interaktionen.
Wie kann ich CLS verbessern?
Reserviere Platz für Medien und dynamische Elemente, stabilisiere Fonts und vermeide spätes Einfügen von Inhalt oberhalb sichtbarer Bereiche.
Performance soll die Nutzung verbessern
Die beste Optimierung ist nicht diejenige, die den schönsten Testwert erzeugt, sondern diejenige, die reale Ladezeit, Reaktionsfähigkeit und Stabilität für Nutzer verbessert – ohne wichtige Inhalte oder Funktionen zu opfern.