Core Web Vitals: Warum Ladezeit den Umsatz beeinflusst

Ein mittelständischer Hersteller stellt seinen Konfigurator online. Die Seite sieht gut aus, das Team ist zufrieden – nur bestellt kaum jemand. Die Analyse zeigt: Auf dem Smartphone dauert es 4,8 Sekunden, bis das erste Produktbild erscheint. Bis dahin ist ein Drittel der Besucher wieder weg. Kein Designfehler, kein Textproblem. Ladezeit.

Kurz gesagt: Google misst die gefühlte Geschwindigkeit einer Seite mit drei Kennzahlen – LCP, INP und CLS. Sie entscheiden mit über Ranking, vor allem aber über Absprünge und Abschlüsse. Dieser Beitrag erklärt, was hinter den Werten steckt, welche fünf Ursachen fast immer dahinterstecken und welche Stellschrauben in Contao tatsächlich etwas bringen – mit Code, Zahlen und einem Praxisfall zum Mitrechnen.

Der wirtschaftliche Zusammenhang ist gut belegt. In der von Google beauftragten Untersuchung „Milliseconds Make Millions" (Deloitte und 55) wurden 37 Marken-Websites mit über 30 Millionen Sitzungen ausgewertet. Ergebnis: Schon 0,1 Sekunden kürzere mobile Ladezeit gingen im Handel mit rund 8 Prozent höheren Conversions und etwa 9 Prozent höherem durchschnittlichem Bestellwert einher; im Reisebereich lagen die Conversions rund 10 Prozent höher, bei Informations- und Lead-Seiten sank die Absprungrate um gut 8 Prozent. Das sind Korrelationen aus Felddaten, keine Garantien – die Richtung ist aber über Branchen hinweg konsistent.

Beim Ranking ist Nüchternheit angebracht: Die Core Web Vitals sind ein Signal unter vielen und ersetzen keine inhaltliche Relevanz. Zum Unterscheidungsmerkmal werden sie vor allem dann, wenn mehrere Seiten inhaltlich vergleichbar sind. Der eigentliche Hebel liegt im Nutzerverhalten: Wer zwei Sekunden auf ein leeres Bild starrt oder beim Tippen ins Leere klickt, springt ab – und Absprünge kosten Umsatz, unabhängig von jeder Google-Formel. Ein Blick in die Feldstatistiken zeigt zudem, dass bis heute nur etwa die Hälfte der mobilen Seitenaufrufe alle drei Werte im grünen Bereich hält. Wer hier sauber arbeitet, hebt sich messbar ab.

Die Ursachen wiederholen sich erstaunlich zuverlässig. Fünf Kandidaten erklären den Großteil schlechter Werte:

• Zu große Bilder: unkomprimierte JPEG/PNG-Dateien, viel zu breit ausgeliefert, ohne moderne Formate.
• Renderblockierende Ressourcen: umfangreiche CSS- und JavaScript-Dateien, die vor dem ersten Bildaufbau geladen werden müssen.
• Schriften: extern geladene Webfonts, die den Text verzögern oder nachträglich umbrechen lassen.
• Drittanbieter-Skripte: Tracking, Maps, Chat, Consent-Tools – sie blockieren den Hauptthread und verschlechtern vor allem INP.
• Langsame Server-Antwort: ein hoher TTFB (Time to First Byte) durch schwaches Hosting, fehlendes Caching oder aufwendige Datenbankabfragen.

Bemerkenswert ist, dass der Flaschenhals meist nicht das CMS ist, sondern das, was darum herum eingebaut wurde. Ein aufgeräumtes Contao mit sauberen Templates ist schnell; langsam wird es durch Slider mit Megabyte-Bildern, drei Analytics-Tools und ein Consent-Skript, das den halben Seitenaufbau verzögert.

Typisches Szenario aus der Praxis – so läuft ein solcher Fall ab; die Zahlen stehen beispielhaft für eine übliche Ausgangslage.

Ein Onlineshop für Arbeitskleidung klagt über schwache Mobilzahlen. Der erste Blick in PageSpeed Insights zeigt: LCP 4,6 Sekunden, INP 340 Millisekunden, CLS 0,28 – alle drei Werte im roten Bereich. Die Ursachenanalyse dauert eine Stunde:

• Das Kategoriebild wird als 3,2-MB-JPEG in Originalgröße ausgeliefert und zusätzlich per Lazy Loading verzögert – der LCP-Killer.
• Ein Consent-Tool lädt vor dem Seitenaufbau vier Skripte nach, darunter zwei Tracking-Pixel – Hauptursache für den INP.
• Der Rabatt-Banner wird per JavaScript oben eingeschoben, sobald er geladen ist, und schiebt den gesamten Inhalt nach unten – das erklärt den CLS.

Die Maßnahmen sind unspektakulär: Bildgrößen in Contao konfigurieren und WebP ausliefern, fetchpriority="high" für das Kategoriebild, Lazy Loading nur unterhalb des Falzes, Consent-Skripte erst nach Einwilligung laden, für den Banner eine feste Höhe reservieren. Aufwand: ein Arbeitstag.

Das realistische Ergebnis nach dem nächsten Datenfenster: LCP unter 2,5 Sekunden, INP im grünen Bereich, CLS nahe null. Die spannendere Zahl steht aber in der Webanalyse – die Absprungrate auf Mobilgeräten sinkt spürbar, weil Besucher nicht mehr auf ein leeres Bild starren. Genau das ist der Punkt: Die Core Web Vitals sind nicht das Ziel, sie sind das Messgerät.

Zuerst gilt es, das LCP-Element zu identifizieren – in PageSpeed Insights wird es benannt. Meist ist es das Titelbild oder die Headline im sichtbaren Bereich. Danach greifen vier Hebel:

• Bild richtig ausliefern: modernes Format (WebP oder AVIF), passende Abmessungen, Qualität um 80 Prozent, responsive Varianten über srcset. Ein 1920 Pixel breites Bild in webp landet häufig unter 200 Kilobyte statt bei zwei Megabyte.
• Priorität setzen: das Hero-Bild bekommt fetchpriority="high" und wird ausdrücklich nicht per Lazy Loading verzögert. Lazy Loading gehört unter den Falz, nicht darüber.
• Serverantwort verkürzen: TTFB unter etwa 0,8 Sekunden, erreichbar durch Seiten-Caching, aktuelle PHP-Version mit OPcache und komprimierte Auslieferung (Brotli oder gzip).
• Kritisches CSS zuerst: nur das Nötige blockierend laden, den Rest nachziehen; ungenutzte Stile entfernen.

Wer nur eine Maßnahme umsetzen kann, sollte bei den Bildern beginnen: In fast jedem Projekt sind sie der größte Einzelposten.

Konkret im Markup sieht das so aus – das Hero-Bild wird priorisiert geladen, alle weiteren Bilder verzögert:

<!-- Hero: hohe Priorität, KEIN lazy loading -->
<img src="/files/hero-1600.webp"
     srcset="/files/hero-800.webp 800w, /files/hero-1600.webp 1600w"
     sizes="(max-width: 900px) 100vw, 1600px"
     width="1600" height="900"
     fetchpriority="high" decoding="async" alt="…">

<!-- Alle Bilder unterhalb des sichtbaren Bereichs -->
<img src="/files/teaser.webp" loading="lazy" decoding="async"
     width="800" height="450" alt="…">

Ein häufiger Fehler: Das Theme setzt loading="lazy" pauschal auf alle Bilder – auch auf das Titelbild. Der Browser lädt es dann bewusst später, und genau dieses Bild ist der LCP. Ergebnis: ein künstlich verschlechterter Wert, der sich mit einer einzigen Template-Zeile beheben lässt.

INP misst die Zeit von der Eingabe bis zur sichtbaren Reaktion – gerechnet wird über alle Interaktionen einer Sitzung. Schlechte Werte entstehen, wenn der Hauptthread des Browsers mit langen JavaScript-Aufgaben belegt ist. Wirksam sind:

• weniger JavaScript ausliefern und ungenutzte Bibliotheken entfernen – jede eingesparte Zeile ist gewonnene Zeit;
• lange Aufgaben in kleinere Stücke zerlegen, damit der Browser zwischendurch reagieren kann;
• Drittanbieter-Skripte verzögert oder erst nach Einwilligung laden, statt sie im Kopfbereich zu blockieren;
• aufwendige Event-Handler entschlacken und teure Layout-Berechnungen vermeiden;
• Animationen bevorzugt über CSS statt über JavaScript umsetzen.

In der Praxis ist INP häufig ein Consent- und Tracking-Problem. Ein schlankes, serverseitig ausgeliefertes Cookie-Banner schlägt jedes nachgeladene Skript-Monster – und verbessert nebenbei den ersten Bildaufbau.

Layoutsprünge entstehen, wenn Platz erst reserviert wird, nachdem etwas geladen ist. Die Gegenmittel sind unspektakulär, aber zuverlässig: Bilder und Videos bekommen feste width- und height-Angaben oder ein aspect-ratio, damit der Browser den Raum vorab kennt. Werbeflächen, Banner und Consent-Hinweise erhalten reservierte Container statt nachträglich eingeschobener Blöcke. Schriften werden lokal eingebunden und mit font-display: swap sowie einem passenden Fallback konfiguriert, damit der Text nicht springt, wenn die Webfont eintrifft.

Ein häufig übersehener Fall: nachgeladene Hinweisleisten oder „Sticky"-Elemente, die sich oben einblenden und den gesamten Inhalt nach unten schieben. Solche Elemente gehören überlagernd positioniert, nicht in den Fluss des Dokuments.

Contao bringt die nötigen Werkzeuge bereits mit – sie müssen nur konsequent genutzt werden:

• Bildgrößen definieren (Layout → Bildgrößen) und im Template zuweisen, statt Originaldateien auszuliefern. Contao erzeugt daraus automatisch skalierte Varianten samt srcset.
• WebP als Ausgabeformat in der Bildgrößen-Konfiguration setzen; die Redaktion lädt weiterhin normale Bilder hoch.
• Produktionsmodus aktivieren: im Debug-Modus werden Assets einzeln und unkomprimiert ausgeliefert – live gehören sie kombiniert und minifiziert.
• Seiten-Cache nutzen: den integrierten HTTP-Cache (Symfony HttpCache) beziehungsweise einen vorgelagerten Reverse Proxy aktivieren und die Cache-Zeit je Seite sinnvoll setzen.
• Aktuelle PHP-Version mit OPcache und ausreichend Arbeitsspeicher; das senkt den TTFB oft spürbarer als jede Frontend-Optimierung.
• Schriften lokal hosten statt über externe Dienste – das ist zugleich datenschutzfreundlich.
• Erweiterungen prüfen: jede Extension bringt eigenes CSS und JavaScript mit. Nicht genutzte Module deaktivieren.

Kleine Regel mit großer Wirkung: Das Titelbild eines Blogbeitrags oder einer Startseite wird nie per Lazy Loading geladen – genau dieses Bild ist in aller Regel der LCP.

Die Bildgrößen werden dabei nicht im Template hart verdrahtet, sondern zentral konfiguriert – so gelten sie überall gleich:

# config/config.yaml
contao:
  image:
    sizes:
      _blog_teaser:
        width: 800
        height: 450
        resize_mode: crop
        formats:
          jpg: [webp, jpg]
          png: [webp, png]
      _blog_hero:
        width: 1920
        height: 1280
        resize_mode: crop
        densities: "1x, 2x"
        formats:
          jpg: [webp, jpg]

Contao erzeugt daraus automatisch die skalierten Varianten samt srcset und liefert WebP aus, wo der Browser es unterstützt. Die Redaktion lädt weiterhin ganz normale Bilder hoch und muss nichts beachten – der wichtigste Vorteil dieser Lösung.

Zum Cache: Im Produktionsmodus kombiniert und minifiziert Contao die Assets automatisch. Wer zusätzlich den HTTP-Cache aktiviert, spart den kompletten PHP-Durchlauf für anonyme Besucher:

# .env.local
APP_ENV=prod
APP_DEBUG=0

# Seiten-Cache in den Seiteneinstellungen je Seite setzen,
# z. B. 300 Sekunden für Standardseiten, 0 für Formularseiten.

Einmalige Optimierung genügt nicht; jede Erweiterung, jedes neue Skript kann Werte verschlechtern. Bewährt hat sich eine Kombination aus drei Quellen: PageSpeed Insights für die Diagnose einzelner Seiten (Feld- und Labordaten), der Core-Web-Vitals-Bericht der Search Console für den Überblick über alle URL-Gruppen und – bei größeren Projekten – eine eigene Messung im Feld über die web-vitals-Bibliothek, die echte Nutzerwerte erfasst.

Zwei Punkte sind dabei wichtig: Erstens wirken Verbesserungen im Feld verzögert, weil die Bewertung auf einem 28-Tage-Fenster beruht – Geduld gehört dazu. Zweitens lohnt ein einfaches Performance-Budget: eine Obergrenze für Seitengewicht und JavaScript, die vor jedem Release geprüft wird. So bleibt die mühsam erarbeitete Geschwindigkeit auch nach dem nächsten Relaunch erhalten.

Core Web Vitals sind keine SEO-Folklore, sondern eine gut messbare Beschreibung dessen, was Besucher als schnell und angenehm empfinden. Die Schwellenwerte – 2,5 Sekunden, 200 Millisekunden, 0,1 – sind ambitioniert, aber erreichbar. Der Weg dorthin führt selten über spektakuläre Umbauten und fast immer über solide Handwerksarbeit: passende Bildformate, weniger JavaScript, reservierte Layoutflächen, ein sauber konfiguriertes CMS und ein Hosting, das schnell antwortet. Der Aufwand zahlt sich doppelt aus – in besseren Rankings und in mehr Abschlüssen.

Die wichtigsten Fragen zu Ladezeit, Core Web Vitals und ihrer Wirkung – kurz beantwortet.