Performance ist mehr als ein guter Score. Eine Website muss schnell sichtbar werden, auf Eingaben direkt reagieren und beim Laden stabil bleiben. Genau dafür sind die Core Web Vitals gedacht: Sie übersetzen technische Lade- und Interaktionsprobleme in Messwerte, die näher an der realen Nutzererfahrung liegen als reine Dateigrößen oder Serverzeiten.
Für Unternehmen ist das relevant, weil Performance direkt in Wahrnehmung, Conversion, SEO und Wartbarkeit hineinspielt. Eine schöne Website, die auf Mobilgeräten spät lädt, beim Scrollen ruckelt oder durch nachladende Elemente springt, fühlt sich nicht hochwertig an. Deshalb gehört Performance-Optimierung zu den Grundlagen moderner Webentwicklung und zu einer messbaren Qualitätsstrategie wie in unserem Beitrag Qualität ist messbar: Performance, Barrierefreiheit und SEO.
Was sind Core Web Vitals?
Google beschreibt Core Web Vitals als Messwerte für reale Nutzererfahrung in drei Bereichen: Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität. Die aktuellen Core Web Vitals sind:
- Largest Contentful Paint (LCP): misst, wann der größte sichtbare Inhalt im Viewport geladen ist. Gut ist ein LCP von höchstens 2,5 Sekunden.
- Interaction to Next Paint (INP): misst die Reaktionsfähigkeit über Interaktionen hinweg. Gut ist ein INP von höchstens 200 Millisekunden.
- Cumulative Layout Shift (CLS): misst unerwartete Layoutverschiebungen. Gut ist ein CLS von höchstens 0,1.
Für die Bewertung wird laut web.dev und Google Search Central das 75. Perzentil verwendet. Eine Seite sollte also nicht nur im besten Testlauf schnell sein, sondern für den Großteil der echten Seitenaufrufe gut funktionieren.
LCP optimieren: Hauptinhalt früher sichtbar machen
LCP ist oft der wichtigste erste Performance-Hebel, weil Nutzer sehr schnell merken, ob der Hauptinhalt einer Seite sichtbar wird. Der LCP-Kandidat ist häufig ein Hero-Bild, eine große Überschrift, ein Textblock oder ein Produktbild.
Praktische Maßnahmen:
- Serverantwort beschleunigen: TTFB verbessern, Caching nutzen, unnötige Weiterleitungen vermeiden und dynamische Seiten nicht teurer rendern als nötig.
- Hero-Bilder priorisieren: das wichtigste Bild nicht lazy-loaden, sondern früh ausliefern, korrekt dimensionieren und bei Bedarf mit
fetchpriority="high"priorisieren. - Moderne Bildformate nutzen: WebP oder AVIF mit passenden Größen,
srcsetundsizesausliefern, statt ein großes Desktop-Bild an jedes Gerät zu senden. - Render-blockierende Ressourcen reduzieren: kritisches CSS schlank halten und nicht benötigtes JavaScript aus dem initialen Pfad entfernen.
- CDN und Edge-Caching einsetzen: statische Assets nah an den Nutzern ausliefern und wiederholte Abrufe vermeiden.
Wichtig ist: LCP wird nicht durch einen einzelnen Trick gelöst. Oft entsteht ein schlechter LCP aus mehreren kleinen Bremsen: langsamer Server, zu großes Bild, blockierende Fonts, zu viel Client-JavaScript und fehlendes Caching.
INP optimieren: Interaktionen schnell beantworten
INP hat First Input Delay als Core Web Vital ersetzt und ist strenger, weil nicht nur die erste Interaktion betrachtet wird. Gemessen wird, wie lange es dauert, bis die Seite nach einer Nutzeraktion wieder sichtbar reagiert. Das betrifft Klicks, Taps und Tastatureingaben.
Typische Ursachen für schlechten INP:
- große JavaScript-Bundles
- lange Tasks im Main Thread
- teure Event-Handler
- unnötige Re-Renders
- Third-Party-Skripte, die zur falschen Zeit arbeiten
- komplexe DOM-Strukturen
Praktische Optimierung bedeutet hier vor allem: weniger Arbeit im kritischen Moment. Code-Splitting, serverseitiges Rendering, schlanke Komponenten, Debouncing, Web Worker für teure Berechnungen und ein klarer Umgang mit Hydration helfen spürbar. Interaktionen sollten nicht erst warten müssen, bis ein ganzes App-Bundle geparst, kompiliert und ausgeführt wurde.
CLS optimieren: Layout stabil halten
CLS misst, ob sichtbare Inhalte unerwartet springen. Das passiert zum Beispiel, wenn Bilder ohne feste Maße laden, Werbeplätze nachträglich eingefügt werden, Fonts Text neu umbrechen oder Banner oberhalb des Inhalts erscheinen.
Gute Gegenmaßnahmen:
- Breite und Höhe für Medien setzen: Bilder, Videos und Embeds brauchen feste Abmessungen oder ein stabiles
aspect-ratio. - Platz für dynamische Inhalte reservieren: Ads, Cookie-Banner, Empfehlungsboxen und Formularhinweise dürfen den bestehenden Inhalt nicht unkontrolliert verschieben.
- Fonts stabil laden:
font-displaybewusst wählen, Fallback-Fonts metrisch passend konfigurieren und nur benötigte Schnitte laden. - Animationen richtig umsetzen: Layout-Eigenschaften wie
top,left,widthundheightvermeiden, wenntransformausreicht.
Visuelle Stabilität wirkt unscheinbar, ist aber entscheidend für Vertrauen. Wenn ein Button im Moment des Klicks wegspringt, fühlt sich die Website defekt an.
Bilder: meistens der größte Hebel
Bilder sind auf vielen Websites der größte Performance-Faktor. Ein Bild sollte nur so groß übertragen werden, wie es im jeweiligen Viewport sinnvoll ist. Das klingt banal, wird aber oft falsch umgesetzt.
Eine robuste Bildstrategie umfasst:
- responsive Varianten mit
srcsetundsizes - WebP oder AVIF, sofern sinnvoll unterstützt
- echte Bildmaße im Markup
- Lazy Loading für Bilder außerhalb des ersten Viewports
- Priorisierung des LCP-Bildes
- sinnvolle Kompression statt sichtbarer Artefakte
Bei redaktionellen Websites, Landingpages und Produktseiten lohnt sich ein eigener Blick auf das erste große Bild. Wenn genau dieses Asset zu spät kommt, nützt es wenig, wenn weiter unten alles perfekt lazy-loaded ist.
Fonts: wenige Schnitte, klare Ladepriorität
Webfonts können Branding stärken, aber sie können auch LCP und CLS verschlechtern. Problematisch sind viele Schriftschnitte, externe Font-Anbieter ohne gute Caching-Strategie und Fallbacks, die deutlich andere Metriken haben.
In der Praxis helfen:
- nur benötigte Schriftschnitte und Zeichensätze laden
- Fonts selbst hosten, wenn das Projekt davon profitiert
- wichtige Fonts preloaden, aber nicht pauschal alle
font-displaybewusst konfigurieren- Fallback-Fonts so wählen, dass Text beim Wechsel nicht stark springt
Der beste Font-Stack ist nicht der mit den meisten Varianten, sondern der, der zur Marke passt und zuverlässig schnell rendert.
JavaScript: weniger Arbeit im Browser
JavaScript ist häufig der Grund, warum eine Seite sichtbar geladen wirkt, aber noch nicht gut bedienbar ist. Große Bundles müssen heruntergeladen, geparst, kompiliert und ausgeführt werden. Auf schnellen Entwicklergeräten sieht das harmlos aus; auf durchschnittlichen Mobilgeräten wird daraus ein echtes INP-Problem.
Sinnvolle Maßnahmen:
- nicht jede UI als Client-Komponente bauen
- Routen und schwere Features per Code-Splitting trennen
- ungenutzte Abhängigkeiten entfernen
- lange Tasks identifizieren und aufteilen
- Hydration minimieren
- teure Berechnungen verschieben oder in Web Worker auslagern
Performance-Optimierung ist hier auch Produktarbeit: Welche Interaktion muss sofort verfügbar sein? Welche Funktion darf später laden? Welche Bibliothek ist bequem, aber für den konkreten Zweck zu groß?
Caching: schnell ist auch Wiederholung
Caching entscheidet, ob wiederkehrende Nutzer und Suchmaschinen-Crawler unnötig dieselbe Arbeit auslösen. Statische Assets sollten langfristig gecacht und über Hash-Dateinamen versioniert werden. HTML und API-Antworten brauchen eine bewusstere Strategie, weil sie sich häufiger ändern.
Bewährte Muster:
- lange Cache-Zeiten für versionierte CSS-, JS- und Bilddateien
- CDN-Caching für öffentliche Inhalte
stale-while-revalidate, wenn leicht veraltete Inhalte akzeptabel sind- gezielte Revalidierung nach Content-Updates
- Kompression mit Brotli oder gzip
Caching ersetzt keine saubere Architektur, aber es verhindert, dass jede Anfrage wie der erste Seitenaufruf behandelt wird.
Third-Party-Skripte: jedes Script braucht einen Grund
Analytics, Consent-Tools, Chat-Widgets, A/B-Testing, Karten, Video-Embeds und Werbenetzwerke können Performance stark beeinflussen. Sie laufen oft außerhalb der eigenen Codequalität, belegen aber denselben Main Thread und dieselbe Netzwerkverbindung wie die Website selbst.
Deshalb sollte jedes Third-Party-Skript regelmäßig geprüft werden:
- Wird es wirklich gebraucht?
- Lädt es vor oder nach dem Hauptinhalt?
- Kann es erst nach Consent oder Interaktion geladen werden?
- Gibt es eine leichtere Alternative?
- Blockiert es Rendering oder Interaktionen?
web.dev empfiehlt, Third-Party-JavaScript regelmäßig zu auditieren und effizient zu laden. In der Praxis ist das oft einer der ehrlichsten Performance-Tests: Wenn ein Tool keinen klaren geschäftlichen Nutzen hat, sollte es nicht dauerhaft Ladezeit kosten.
Labordaten vs. Felddaten
Ein häufiger Fehler ist, nur auf einen Lighthouse-Lauf zu schauen. Labordaten sind nützlich, weil sie reproduzierbar sind und beim Debugging helfen. PageSpeed Insights weist aber ausdrücklich darauf hin, dass Labordaten reale Engpässe nicht vollständig abbilden. Felddaten aus dem Chrome User Experience Report zeigen dagegen echte Nutzererfahrung über einen zurückliegenden Zeitraum, sind aber weniger detailliert für die Fehlersuche.
Beides hat seinen Platz:
- Labordaten: ideal für Entwicklung, Pull Requests, Regressionen und konkrete Diagnosen.
- Felddaten: entscheidend für die Frage, wie echte Nutzer die Website erleben.
- RUM-Daten: eigene Real-User-Monitoring-Daten helfen, Seiten, Geräte, Länder und Nutzergruppen genauer zu verstehen.
Professionelle Performance-Arbeit kombiniert diese Perspektiven. Ein guter Lighthouse-Score ist ein Startpunkt, aber Core Web Vitals müssen im Feld stabil bleiben.
Eine pragmatische Performance-Checkliste
Für die meisten Websites lohnt sich dieser Ablauf:
- PageSpeed Insights für wichtige Seitentypen prüfen: Startseite, Landingpage, Blogartikel, Kontakt, Produkt- oder Leistungsseite.
- LCP-Element identifizieren und gezielt optimieren.
- JavaScript-Budget setzen und unnötige Client-Arbeit entfernen.
- Bilder und Fonts systematisch prüfen.
- Layoutverschiebungen durch feste Größen und reservierte Flächen verhindern.
- Third-Party-Skripte auditieren.
- Caching-Regeln für Assets, HTML und APIs kontrollieren.
- Nach dem Release Felddaten beobachten, nicht nur den Laborscore.
So wird Performance kein einmaliges Projekt, sondern Teil der normalen Qualitätssicherung.
