
Google misst nicht „schönes Design“, sondern Nutzererlebnis. Core Web Vitals sind dafür ein praxisnaher Proxy.
In diesem Guide bekommst du:
- klare Zielwerte (was „gut“ bedeutet)
- wie du richtig misst (Felddaten vs. Lab)
- die häufigsten Ursachen pro Metrik
- konkrete Quick-Fixes, die in der Praxis am meisten bringen
Kurzüberblick: Zielwerte
Als grobe Orientierung (Google „good“):
| Metrik | „Gut“ | „Verbesserungswürdig“ | | --- | --- | --- | | LCP | < 2,5s | 2,5–4,0s | | INP | < 200ms | 200–500ms | | CLS | < 0,1 | 0,1–0,25 |
Wichtig: Entscheidend sind Felddaten (echte Nutzer). Eine Seite kann in Lighthouse gut aussehen und im Feld trotzdem Probleme haben (z.B. durch reale Geräte, echte Netzwerke, Third-Party-Skripte).
Richtig messen (ohne dich zu verrennen)
Es gibt zwei Datenarten:
- Felddaten (Real User Monitoring / CrUX): echte Nutzer, echte Geräte → relevant für Google.
- Lab-Daten (Lighthouse/DevTools): Simulation → ideal zum Debuggen.
Tools, die sich bewährt haben:
- Google Search Console: Core Web Vitals Bericht (Gruppierung nach URL-Mustern)
- PageSpeed Insights: Lab + Felddaten (CrUX), gute Hinweise
- Chrome DevTools: Performance-Panel, Coverage, Network-Wasserfall
Wenn du Next.js nutzt, sind außerdem hilfreich:
- Bundle-Analyse / Skript-Gewicht (was lädt überhaupt?)
- Monitoring in der Realität (z.B. über Web-Vitals-Messung im Frontend)
Die drei wichtigsten Werte (mit Praxis-Fixes)
LCP (Largest Contentful Paint)
Worum geht’s? Wie schnell der wichtigste Inhalt sichtbar ist.
Typisch ist das: Hero-Bild, großer Heading-Block oder ein Above-the-fold-Element.
Typische Ursachen:
- zu große/ungünstig geladene Bilder (Hero)
- hoher TTFB (Server antwortet langsam)
- Render-Blocking durch CSS/JS
- zu viel Above-the-fold (Slider, Videos, große Animationen)
Quick-Fixes (die meistens sofort helfen):
- Hero-Bild richtig ausliefern (Größe, Format, Priorisierung). In Next.js:
next/image, sinnvollesizes, und nur dortpriority, wo es wirklich Above-the-fold ist. - TTFB senken: Caching/CDN, Server-Performance, unnötige Datenabfragen vermeiden. (Siehe auch: Caching/CDN & TTFB).
- Render-Blocking reduzieren: kritische Styles früh, Rest nachladen; unnötige CSS/JS entfernen.
- Third-Party entschärfen: Chat, Maps, Tracking erst nach Consent und ggf. erst nach Interaktion laden.
Wenn du tiefer rein willst: LCP-Bilder in Next.js richtig optimieren.
INP (Interaction to Next Paint)
Worum geht’s? Wie schnell die Seite auf Interaktionen reagiert (Klick, Tippen).
Typische Ursachen:
- zu viel JavaScript (Download + Parsing + Ausführung)
- „lange Tasks“ im Main Thread (z.B. riesige Bundles)
- Third-Party-Skripte (Tag Manager, Widgets, Heatmaps)
- teure React-Renders (zu große Komponentenbäume, unnötige Re-renders)
Quick-Fixes:
- JS reduzieren: Features/Libs entfernen oder ersetzen; nur laden, was wirklich gebraucht wird.
- Code splitten: dynamische Imports für selten genutzte Komponenten (z.B. Slider, Karten).
- Third-Party lazy laden: erst nach Consent und möglichst nach Interaktion.
- Renders stabilisieren: schwere Komponenten memoizen, Props stabil halten, unnötige State-Updates vermeiden.
Debug-Ansatz:
- Chrome DevTools → Performance: nach „Long tasks“ schauen.
- Network → große JS-Dateien identifizieren.
CLS (Cumulative Layout Shift)
Worum geht’s? Springt das Layout beim Laden?
Typische Ursachen:
- Bilder/Medien ohne fest reservierten Platz (Width/Height oder Aspect Ratio)
- Fonts ohne sauberes Loading (Layout-Switch durch spätes Font-Laden)
- Widgets/Embeds, die nachträglich Inhalt einfügen (Consent, Chat, iFrames)
Quick-Fixes:
- Platz reservieren: für Bilder/Videos/iFrames feste Dimensionen oder
aspect-ratio. - Fonts stabil laden:
font-display: swapund möglichst nur notwendige Schriftschnitte. - Consent/Widgets: Container mit fixer Höhe reservieren oder erst nach User-Interaktion einblenden.
Wenn du CLS-Probleme hast, ist das oft „ein paar kleine Details“ – aber die Details sind entscheidend.
Priorisierung: Was bringt am meisten?
Wenn du nur begrenzte Zeit hast, ist das hier oft das beste 80/20:
- Hero/LCP fixen (Bild + Above-the-fold + TTFB)
- Third-Party reduzieren (besonders auf Mobile)
- CLS eliminieren (Platz reservieren, Fonts)
- JS-Gewicht senken (INP wird meistens automatisch besser)
10 Maßnahmen, die fast immer helfen
- Bilder korrekt dimensionieren und komprimieren.
- Hero-Elemente priorisieren (aber nicht „alles“ als
priority). - Fonts sauber laden (kein Layout-Springen, nur nötige Schnitte).
- Third-Party-Skripte radikal prüfen (brauchen wir das wirklich?).
- Tracking/Consent so bauen, dass es nicht blockiert oder springt.
- JS-Bundles verkleinern (unnötige Dependencies raus).
- Code splitting / lazy loading für selten genutzte UI.
- Caching/CDN nutzen (TTFB ist häufig der versteckte Bremsklotz).
- Mobile Performance als Standard nehmen (nicht als „später“).
- Nach dem Fix erneut messen: Lab und Felddaten beobachten.
Next.js Quick Wins (typisch bei App Router/React)
- Nutze
next/imagekonsequent und gib sinnvollesizesan. - Vermeide große Client Components „nur weil’s einfacher ist“: je mehr im Client, desto mehr JS.
- Third-Party nur dort einbauen, wo es wirklich gebraucht wird (z.B. Maps nicht auf jeder Seite).
Wenn du dich tiefer mit Next.js & SEO/Performance beschäftigen willst: Next.js SEO im App Router.
Was du davon als Business mitnehmen solltest
Wenn deine Seite schneller und stabiler wird, steigen meist:
- Verweildauer,
- Conversion (Anfragen/Käufe),
- organische Sichtbarkeit.
Praktisch heißt das: Core Web Vitals sind nicht „nur SEO“. Sie sind ein Conversion-Hebel – besonders auf Mobile.
Mini-Checkliste vor dem nächsten Release
- LCP: Hero-Bild optimiert + TTFB ok?
- INP: Keine langen Tasks, kein unnötiges JS/Third-Party?
- CLS: Reservierter Platz für Medien/Widgets, Fonts stabil?
- Tracking: Consent sauber, Events geprüft?
- Mobile: einmal real auf einem normalen Handy testen (nicht nur Desktop-Lighthouse)
Nächster Schritt
Wenn du möchtest, machen wir einen Performance-Check und priorisieren die Maßnahmen nach Aufwand/Impact.


