Bei der Web-Performance-Optimierung machen Sie Ihre Website für echte Nutzer messbar schneller, stabiler und reaktionsfreudiger. Den Maßstab setzt Google mit drei Kennzahlen, den Core Web Vitals: Ladezeit des Hauptinhalts (LCP), Reaktionszeit auf Eingaben (INP) und visuelle Stabilität (CLS). Wer diese drei Werte mit echten Nutzerdaten misst, die Ursache Phase für Phase eingrenzt und die Maßnahmen nach Wirkung ordnet, verbessert gezielt die Erfahrung, die Besucher und Kunden tatsächlich haben. Wer nur eine Checkliste abarbeitet, treibt dagegen oft bloß einen Lighthouse-Score nach oben. Dieser Leitfaden zeigt Ihnen, wie Sie dabei vorgehen, welche Grenzwerte gelten und wo sich der Aufwand wirklich lohnt.

Kurz gesagt

• Drei Werte zählen: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 gelten als „gut“, gemessen am 75. Perzentil aller Seitenaufrufe.
• Felddaten vor Labordaten: Echte Nutzerdaten (CrUX, RUM) zeigen, ob es ein Problem gibt. Lighthouse hilft Ihnen, die Ursache zu finden.
• Ein schlechter LCP-Wert hat meist eine von vier Ursachen: Serverantwort, verzögerter Ladebeginn, Ladedauer oder verzögertes Rendern. Prüfen Sie zuerst, welche davon dominiert.
• 100/100 ist kein Ziel: Von 50 auf 80 Punkte bringt mehr für Ihre Nutzer als von 96 auf 99.
• Performance ist ein Prozess: Ohne laufendes Monitoring schleichen sich mit jedem neuen Skript, Plugin oder Tracking-Tag Rückschritte ein.

Inhaltsverzeichnis

• Was Web-Performance heute konkret bedeutet
• Richtig messen: Feld- und Labordaten
• LCP verbessern: die vier Phasen
• INP: schnelle Reaktion auf jede Eingabe
• CLS: Layout-Sprünge vermeiden
• Prioritäten setzen statt 100 Punkte jagen
• Unsere Sicht: Performance ist eine Marketingaufgabe
• Web-Performance mit Xpert Marketing angehen
• Häufige Fragen zur Web-Performance-Optimierung
• Quellen

Was Web-Performance heute konkret bedeutet

„Die Seite ist langsam“ beschreibt viele verschiedene Probleme. Der Hauptinhalt erscheint spät, ein Button reagiert verzögert, oder Text springt nach unten, weil ein Banner nachlädt. Google hat diese Erfahrungen in drei Kennzahlen gefasst. Das Ziel der Initiative ist laut dem Chrome-Team, dass Websitebetreiber keine Performance-Experten sein müssen, um die Nutzererfahrung ihrer Seite zu verstehen.

Diese Grenzwerte gelten laut Googles Dokumentation zu PageSpeed Insights am 75. Perzentil. Mindestens drei von vier Seitenaufrufen müssen also jeden der drei Werte erfüllen, damit die Seite die Bewertung besteht. Das ist bewusst streng gewählt: Ein guter Durchschnitt kann sehr frustrierende Besuche auf älteren Smartphones oder in schwachen Mobilnetzen verdecken. Wie Google die Schwellen hergeleitet hat, beschreibt der Artikel zur Definition der Core-Web-Vitals-Grenzwerte.

Wichtig für ältere Audits: INP hat im März 2024 den früheren Wert First Input Delay (FID) als Core Web Vital abgelöst. Ein Bericht, der noch FID ausweist, bildet die heutige Bewertung nicht mehr ab.

Warum das für Ihr Geschäft zählt

Google empfiehlt Websitebetreibern ausdrücklich, gute Core Web Vitals zu erreichen, um in der Suche erfolgreich zu sein und Nutzern eine gute Erfahrung zu bieten. Allerdings gleicht Performance keinen schwachen Inhalt aus. Schnelle Seiten verschaffen Ihnen eher die Voraussetzung, dass Besucher bleiben, Formulare abschicken und Kampagnenbudgets nicht auf Absprungseiten verpuffen. Für B2B-Unternehmen heißt das: Eine langsame Landingpage drückt jede KPI, die dahinter liegt, vom Lead bis zur Opportunity.

Richtig messen: Feld- und Labordaten

Der häufigste Fehler in der Web-Performance-Optimierung ist, im falschen Werkzeug nach der Wahrheit zu suchen. Es gibt zwei Arten von Daten, und sie beantworten unterschiedliche Fragen.

Felddaten stammen von echten Nutzern. Google sammelt sie im Chrome User Experience Report (CrUX) und zeigt sie in PageSpeed Insights und in der Google Search Console an. Sie beantworten die Frage: Haben meine Nutzer ein Problem?

Labordaten erzeugt Lighthouse in einer simulierten, kontrollierten Umgebung. Sie beantworten die Frage: Warum ist die Seite langsam?

Widersprechen sich beide, liegt meist kein Fehler vor. Sie messen schlicht verschiedene Dinge. Bewerten Sie die Qualität deshalb anhand der Felddaten und nutzen Sie die Labordaten zur Diagnose.

Seite und Domain getrennt betrachten

PageSpeed Insights zeigt Felddaten für die einzelne URL und für die gesamte Origin (Domain). Die Werte können stark voneinander abweichen. Die Startseite ist oft besonders langsam, weil neue Besucher sie „kalt“, also ohne Cache, laden. Vergleichen Sie beide Ebenen, bevor Sie handeln. Ist nur eine Vorlage betroffen, etwa die Produktdetailseite, lohnt sich ein gezielter Eingriff. Ist die ganze Domain rot, liegt die Ursache eher im Hosting, im Theme oder in seitenweit geladenen Skripten.

Eigene Nutzerdaten mit RUM

CrUX-Daten in PageSpeed Insights und der Search Console sind ein gleitender Durchschnitt über 28 Tage. Ein Deployment, das am Montag den INP-Wert verschlechtert, sehen Sie dort erst Wochen später deutlich. Deshalb empfiehlt Google zusätzlich Real User Monitoring (RUM), entweder über einen spezialisierten Anbieter oder über die Open-Source-Bibliothek web-vitals, die Messwerte pro Seitenaufruf liefert. Senden Sie diese Werte an Ihr Analytics-Setup, idealerweise zusammen mit Seitentyp, Gerät und Kampagnenquelle. Dann sehen Sie nicht nur, dass etwas langsamer wird, sondern auch wo und für wen. Wenn Sie Ihr Tracking ohnehin neu aufsetzen, ist serverseitiges Tracking ein guter Moment, die Datenqualität und die Zahl der Browser-Skripte gleich mit zu verbessern.

LCP verbessern: die vier Phasen

LCP ist in der Praxis der Wert, an dem die meisten Websites scheitern. Laut web.dev lässt er sich in vier Abschnitte zerlegen. Erst wenn Sie wissen, welcher Abschnitt die Zeit frisst, wissen Sie auch, welche Maßnahme hilft.

1. Time to First Byte (TTFB): Zeit, bis der Browser das erste Byte des HTML erhält.
2. Ladeverzögerung der Ressource: Zeit zwischen TTFB und dem Moment, in dem der Browser beginnt, das LCP-Element (meist ein Bild) zu laden.
3. Ladedauer der Ressource: Wie lange die Datei selbst zum Herunterladen braucht.
4. Renderverzögerung: Zeit zwischen fertig geladener Ressource und ihrer Anzeige.

In Chrome DevTools und Lighthouse zeigt die Auswertung „LCP by phase“ diese Aufteilung direkt an. Google bündelt seine Empfehlungen zunehmend in solchen zusammengefassten Insights, die Messdaten und konkrete Hinweise verknüpfen, statt in vielen Einzelaudits, die isoliert betrachtet in die Irre führen können.

Maßnahmen nach Phase

Wenn TTFB dominiert: Reduzieren Sie Weiterleitungen, besonders Ketten aus HTTP zu HTTPS zu www zu Sprachversion. Liefern Sie HTML über ein CDN näher am Nutzer aus und cachen Sie Seiten, die nicht für jeden Besucher individuell sind. Ein häufiger Stolperstein sind URL-Parameter aus Kampagnen (etwa utm_source), die den Cache umgehen. PageSpeed Insights weist TTFB als experimentellen Wert aus, gut sind höchstens 800 ms. Ein hoher TTFB macht einen guten LCP-Wert schwer bis unmöglich.

Wenn die Ladeverzögerung dominiert: Der Browser entdeckt das Hero-Bild zu spät. Das passiert, wenn es per CSS-Hintergrund, per JavaScript-Slider oder per Lazy Loading eingebunden ist. Binden Sie das LCP-Bild als normales <img> im HTML ein und geben Sie ihm fetchpriority="high". Die wichtigste Regel: Laden Sie das LCP-Element niemals per Lazy Loading. Lazy Loading ist für Bilder unterhalb des sichtbaren Bereichs sinnvoll, beim Hauptbild verzögert es den Ladebeginn garantiert.

Wenn die Ladedauer dominiert: Die Datei ist zu groß. Nutzen Sie moderne Formate wie WebP oder AVIF, liefern Sie per srcset passende Größen für Mobilgeräte aus und komprimieren Sie konsequent. Ein 2.400 Pixel breites Bild auf einem 390 Pixel breiten Smartphone-Display ist verschenkte Ladezeit.

Wenn die Renderverzögerung dominiert: Das Bild ist da, wird aber nicht gezeichnet. Typische Gründe sind render-blockierendes CSS und JavaScript im <head>, A/B-Testing-Tools, die die Seite bis zur Variantenauswahl ausblenden, oder Webfonts, auf die der Text-LCP wartet. Laden Sie kritisches CSS inline, verschieben Sie nicht benötigtes JavaScript mit defer und prüfen Sie, ob jedes Tool im <head> wirklich dorthin gehört. Ein großer Abstand zwischen TTFB und First Contentful Paint ist ein deutliches Signal für solche blockierenden Ressourcen.

INP: schnelle Reaktion auf jede Eingabe

INP bewertet nicht nur den ersten Klick, sondern die Interaktionen während des gesamten Besuchs: Menü öffnen, Filter setzen, Formularfeld ausfüllen, „In den Warenkorb“ tippen. Ein schlechter Wert entsteht fast immer, weil der Hauptthread des Browsers mit JavaScript beschäftigt ist, wenn der Nutzer etwas tut.

Die wirksamsten Hebel in der Praxis:

• Lange Tasks aufteilen: Rechenintensive Funktionen in kleinere Stücke zerlegen und dem Browser dazwischen Zeit geben, auf Eingaben zu reagieren.
• Sofort sichtbares Feedback geben: Erst die Oberfläche aktualisieren (Button-Zustand, Ladeindikator), dann die aufwendige Logik ausführen.
• Drittanbieter-Skripte prüfen: Chat-Widgets, Heatmaps, Consent-Banner und mehrere parallel laufende Tracking-Pixel konkurrieren um denselben Hauptthread. Jedes Skript braucht einen klaren Zweck und einen Verantwortlichen.
• JavaScript-Menge senken: Ungenutzten Code entfernen, Bibliotheken nur dort laden, wo sie gebraucht werden.
• DOM schlank halten: Sehr große Seiten mit Tausenden Elementen machen jede Aktualisierung teurer.

INP lässt sich im Labor nur eingeschränkt nachstellen, weil echte Interaktionen fehlen. Genau hier zahlt sich RUM aus: Es zeigt, welche Interaktion auf welcher Seite langsam ist.

CLS: Layout-Sprünge vermeiden

Nichts wirkt unprofessioneller als ein Button, der in dem Moment wegspringt, in dem Sie ihn antippen. CLS ist meist am einfachsten zu beheben:

• Feste Maße für Bilder und Videos: Geben Sie width und height oder ein aspect-ratio an, damit der Browser den Platz vorab reserviert.
• Platz für dynamische Inhalte reservieren: Cookie-Banner, Werbeflächen, eingebettete Social-Posts und Newsletter-Leisten brauchen einen festen Container, statt Inhalte nach unten zu schieben.
• Webfonts kontrolliert laden: Wählen Sie Ersatzschriften mit ähnlichen Maßen, damit der Wechsel zur Webfont den Text nicht neu umbricht.
• Keine Inhalte über bestehende einfügen: Hinweise und Aktionsbanner gehören nicht nachträglich an den Seitenanfang.

Prioritäten setzen statt 100 Punkte jagen

Der Lighthouse-Performance-Score ist ein hilfreicher Indikator, aber kein Geschäftsziel. Die Punktzahl folgt einer log-normalen Verteilung realer Websitedaten: Der Sprung von 50 auf 80 Punkte ist vergleichsweise einfach, der von 96 auf 99 erfordert unverhältnismäßig viel Aufwand. In den Score fließen zudem nur Metriken ein, nicht die Liste der Empfehlungen selbst.

Bewährt hat sich diese Reihenfolge:

1. Felddaten prüfen: Welche der drei Kennzahlen fällt durch, auf welchen Vorlagen, auf Mobil oder Desktop?
2. Nach Umsatzrelevanz ordnen: Zuerst Seiten mit Kampagnentraffic, Formularen und Checkout, dann den Rest.
3. Ursache diagnostizieren: LCP nach Phase, INP nach Interaktion, CLS nach verschiebendem Element.
4. Schnelle Erfolge umsetzen: Lazy Loading vom Hero-Bild entfernen, Bildgrößen korrigieren, Maße setzen, überflüssige Skripte streichen.
5. Strukturelle Themen planen: Hosting, Caching-Strategie, Theme- oder Framework-Wechsel.
6. Monitoring einrichten: Performance-Budgets definieren und jede Veröffentlichung dagegen prüfen.

Verknüpfen Sie die Ergebnisse mit Ihren Marketing-KPIs. Eine Optimierung ist dann erfolgreich, wenn neben den Core Web Vitals auch Absprungrate, Formularabschlüsse oder Kosten pro Lead in die richtige Richtung gehen.

Unsere Sicht: Performance ist eine Marketingaufgabe

In vielen Unternehmen landet Web-Performance als Ticket bei der Entwicklung, oft erst, wenn die Search Console rot leuchtet. Wir sehen das anders. Die meisten Performance-Probleme entstehen nicht im Code, sondern durch Marketingentscheidungen: das Video im Header, das fünfte Tracking-Pixel, das A/B-Testing-Tool, das Chat-Widget für die Kampagne. Jede einzelne Entscheidung ist nachvollziehbar. In der Summe kosten sie Ladezeit, Reaktionsfähigkeit und am Ende Conversions.

Deshalb verbinden wir bei Projekten Strategie, Kreation und Technologie von Anfang an. Wir fragen nicht nur, wie eine Landingpage schneller wird, sondern welche Elemente überhaupt zum Ziel beitragen. Ein schlankes, klares Landingpage-Design ist fast immer auch ein schnelles. Und wir messen mit echten Nutzerdaten, nicht mit einem Score, den man einmal im Quartal für eine Präsentation erzeugt.

Unser Rat an Marketingteams: Setzen Sie ein Performance-Budget so selbstverständlich fest wie ein Mediabudget. Neue Skripte und Formate kommen nur hinzu, wenn klar ist, was sie bringen und was sie kosten.

— Xpert

Web-Performance mit Xpert Marketing angehen

Sie wollen wissen, wo Ihre Website Ladezeit und Leads verliert? Wir analysieren Ihre Core Web Vitals mit Feld- und Labordaten, priorisieren die Maßnahmen nach Geschäftswirkung und setzen sie um, vom Bild-Workflow bis zum Tracking-Setup. Bei größeren Vorhaben übernimmt unser Team für Web-Entwicklung und E-Commerce auch Relaunch oder Plattformwechsel. Einen Überblick über unsere Leistungen in Web, Tech, Data & Analytics und Digital Marketing finden Sie auf unserer Leistungsseite. Sprechen Sie uns an, wir finden gemeinsam den Hebel mit der größten Wirkung.

Häufige Fragen zur Web-Performance-Optimierung

Warum öffnet sich meine Website so langsam?

Die häufigsten Ursachen sind zu große Bilder, eine langsame Serverantwort, viele Weiterleitungen und JavaScript, das das Rendern blockiert. Prüfen Sie Ihre URL in PageSpeed Insights und sehen Sie sich in der LCP-Auswertung an, welche Phase am längsten dauert. So erkennen Sie, ob Hosting, Bildgröße oder Skripte das Problem sind.

Wie teste ich die Performance meiner Website?

Starten Sie mit PageSpeed Insights: Es zeigt Felddaten echter Nutzer und einen Lighthouse-Labortest in einem Bericht. Die Google Search Console fasst die Core Web Vitals für alle Seiten nach Gruppen zusammen. Für schnelle Rückmeldung nach jeder Änderung ergänzen Sie eigenes Real User Monitoring, zum Beispiel mit der Bibliothek web-vitals.

Sind die Core Web Vitals ein Rankingfaktor?

Google empfiehlt ausdrücklich gute Core Web Vitals für den Erfolg in der Suche. Sie ersetzen aber keine relevanten Inhalte: Eine schnelle Seite mit schwachem Inhalt rankt nicht automatisch besser. Sinnvoller ist es, Performance als Grundlage für Nutzererfahrung und Conversion zu sehen.

Ist WordPress für eine schnelle Website noch zeitgemäß?

Ja, WordPress kann gute Core Web Vitals erreichen. Langsam wird es meist durch schwere Themes, Page-Builder und viele Plugins, die auf jeder Seite Skripte laden. Ein schlankes Theme, gutes Caching, optimierte Bilder und ein strenger Umgang mit Plugins bringen oft mehr als ein Systemwechsel.

Wie lange dauert es, bis Verbesserungen sichtbar werden?

Im Labortest sehen Sie Änderungen sofort. Die Felddaten in PageSpeed Insights und Search Console beruhen auf einem 28-Tage-Zeitraum, deshalb zeigt sich der volle Effekt dort erst nach rund vier Wochen. Mit eigenem RUM erkennen Sie die Wirkung schon nach wenigen Tagen.

Quellen

• Web Vitals, web.dev
• About PageSpeed Insights, Google for Developers
• How the Core Web Vitals metrics thresholds were defined, web.dev
• Advancing Interaction to Next Paint, web.dev
• Understanding Core Web Vitals and Google search results, Google Search Central
• Optimize Largest Contentful Paint, web.dev
• Optimize Largest Contentful Paint (TTFB-Diagnose), web.dev
• Getting started with measuring Web Vitals, web.dev
• Moving Lighthouse to insights, Chrome for Developers
• Lighthouse performance scoring, Chrome for Developers