Core Web Vitals & Modernisierung — LCP, INP, CLS

Core Web Vitals sind die drei Feldmetriken, mit denen Google Lade-, Interaktions- und Stabilitätsqualität misst. Für dich als Betreiber einer Dienstleister-Webseite sind sie gleichzeitig Conversion-Hebel und technische Voraussetzung dafür, dass Crawler und generative Pipelines Inhalte unter Zeitdruck noch vollständig sehen. Dieser Beitrag erklärt die Mechanik von LCP, INP und CLS, zeigt, wie WordPress und Builder sie systematisch verschlechtern, und warum der nachhaltige Fix oft im SSR/SSG-Stack liegt — nicht in einem weiteren Caching-Plugin.

Was messen LCP, INP und CLS — und welche Schwellen gelten?

Antwort zuerst: LCP misst, wann der größte sichtbare Inhalt erscheint; INP, wie lange Interaktionen brauchen; CLS, wie stark das Layout springt — „gut“ laut web.dev heißt LCP < 2,5 s, INP < 200 ms, CLS < 0,1 (75. Perzentil).

LCP — Largest Contentful Paint

LCP markiert den Zeitpunkt, an dem das größte Content-Element im Viewport (häufig Hero-Bild, H1-Block oder großer Textblock) fertig gerendert ist. Alles, was den kritischen Pfad verzögert — langsamer Server, blockierendes CSS, späte Bilder, Fonts ohne font-display — verschiebt LCP nach rechts. Google wertet Werte unter 2,5 s als gut, 2,5–4,0 s als verbesserungswürdig und darüber als schlecht (Optimize LCP).

INP — Interaction to Next Paint

INP ersetzt FID als Interaktionsmetrik: Erfasst wird die Verzögerung von Klick, Tippen oder Tastatur bis zum nächsten sichtbaren Frame. Lange Main-Thread-Tasks durch schweres JavaScript, synchrones Tracking und Builder-Runtime treiben INP hoch. Gut ist < 200 ms (Optimize INP).

CLS — Cumulative Layout Shift

CLS summiert unerwartete Layout-Verschiebungen: Bilder ohne Breiten-/Höhen-Attribute, spät ladende Ads/Embeds, Webfonts die Text umbrechen. Gut ist < 0,1 (Optimize CLS). CLS killt Vertrauen („du klickst den falschen Button“) — unabhängig davon, ob LCP schon „grün“ ist.

Warum gehören Core Web Vitals zur Modernisierung?

Antwort zuerst: Weil schlechte CWV oft Architekturprobleme sind — PHP-Monolith, Pagebuilder-DOM, Plugin-Zoo — und keine Einstellung, die du im Theme-Customizer dauerhaft „wegklickst“.

Bei Modern Stack sind LCP, INP und CLS deshalb Teil von Webseite-Modernisierung: Du tauschst die fragile Auslieferungsschicht, behältst Inhalte und URLs, und misst Field + Lab vor und nach dem Cutover. Eine Verzögerung von nur 100 ms kann Conversion spürbar senken; für KI-Crawler mit Timeouts ist Latenz zusätzlich ein Retrieval-Risiko. Wer nur am Theme dreht, ändert selten die Architektur — siehe auch Webarchitektur im KI-Zeitalter und WordPress im KI-Zeitalter.

Wie WordPress und Pagebuilder LCP, INP und CLS brechen

Antwort zuerst: WordPress rendert oft dynamisch über PHP und Plugins; Pagebuilder erzeugen tief verschachteltes DOM mit globalem CSS/JS — genau die Kombination, die LCP streckt und den Main Thread blockiert.

WordPress-Mechanik gegen LCP

Klassische WordPress-Installationen verarbeiten Anfragen über PHP und MySQL. Pro Seitenaufruf entstehen Datenbankabfragen, Plugin-Hooks und zur Laufzeit zusammengesetztes HTML. Caching kaschiert Time-to-First-Byte, löst aber nicht:

1. Render-blockierende Stylesheets aus Theme + Pagebuilder + Plugin-CSS.
2. Späte Hero-Bilder ohne Priorität (fetchpriority), falsche Formate oder ohne feste Abmessungen.
3. Third-Party-Skripte (Chat, Pixel, Cookie-Banner), die den kritischen Pfad teilen.
4. Font-Swaps, die Text und Layout nach dem ersten Paint verschieben.

Dazu kommt oft eine unsichtbare Warteschlange: Security-Plugins, Formular-Builder, Sliders und „Optimization“-Plugins, die selbst wieder CSS und JavaScript nachladen. Jedes einzelne Modul mag lokal harmlos wirken — in Summe verschiebt es den Largest Contentful Paint in denselben Bereich, den Google als verbesserungswürdig einstuft.

Im internen Vergleich Next.js vs WordPress liegen typische WordPress-LCP-Werte bei 2,5–4,0 s — also genau im „Needs Improvement“-Band von web.dev oder darüber. Das ist kein peinlicher Einzelfall, sondern die empirische Norm vieler Dienstleister-Webseiten mit Theme plus Builder plus Tracking.

Pagebuilder-Mechanik gegen INP und CLS

Pagebuilder wie Elementor und Divi speichern Layouts als tief verschachtelte Container. Das erzeugt:

• DOM-Tiefe und Selektor-Kosten — mehr Layout- und Style-Arbeit vor dem Paint.
• Globale CSS-/JS-Pakete, auch wenn die Seite nur drei Sektionen nutzt.
• Widget-Runtime auf dem Client — Slider, Animationen, Forms — die INP belasten.
• Bilder ohne stabile Box, Overlays und „lazy everything“, die CLS und LCP gleichzeitig verschlechtern.

Deshalb sind Elementor-Migration, Divi-Migration und die übergeordnete Pagebuilder-Ablösung Performance-Projekte — nicht nur Design-Refactorings. Markup wird nicht 1:1 übernommen, sondern in schlanke React-/MDX-Strukturen übersetzt.

Vergleich: Monolith vs. SSG/Edge

Reicht Caching oder ein CDN?

Antwort zuerst: Nein, allein selten — ein CDN verkürzt Latenz und verbessert oft TTFB, entfernt aber weder Pagebuilder-HTML noch Plugin-JavaScript.

Caching-Plugins speichern fertige HTML-Antworten; sie ändern nicht die Größe des CSS-Bundles, die Anzahl der DOM-Knoten oder die Main-Thread-Arbeit nach dem Hydrate-/Widget-Start. Edge-Auslieferung beschleunigt Bytes auf dem Draht — sie ersetzt keine saubere HTML-Struktur. Deshalb gehört Hosting nach Migration in die Feinjustierung, nachdem der Stack selbst schlank ist.

Wann CDN trotzdem sinnvoll ist: immer als Schicht über gutem Markup — nie als Ersatz für Migration, wenn Lab und Field trotz Cache bei LCP > 2,5 s bleiben.

Wie Next.js SSG und Edge LCP, INP und CLS reparieren

Antwort zuerst: Next.js liefert vorkompiliertes oder edge-nahes HTML ohne PHP-Plugin-Kette — messbar oft als LCP von ~0,8 s statt 2,5–4,0 s.

Hybride Rendering-Strategien (Next.js Caching/Rendering):

• Static Site Generation (SSG): Seiten werden im Build als HTML vorkompiliert und über CDN/Edge ausgeliefert — LCP profitiert sofort, weil der Origin nicht PHP rendern muss.
• Incremental Static Regeneration / On-Demand Revalidation: einzelne Seiten aktualisieren sich ohne Full-Rebuild.
• Server-Side Rendering (SSR): dynamische Pfade entstehen nahe am Request — ohne den gesamten Plugin-Stack.

Technische Hebel im Zielstack SSR/SSG-Stack und Next.js:

1. Servergerendertes oder statisches HTML statt PHP+Plugin-Zoo → schnellerer LCP.
2. Bild-Pipeline mit Größen, modernen Formaten und Layout-Reserven → LCP + CLS.
3. Weniger Client-JS (Inseln statt Builder-Runtime) → besseres INP.
4. Font-Strategie mit font-display und reserviertem Platz → CLS.
5. Edge-Headers und Caching im Stack nativ → stabiles TTFB ohne Plugin-Zoo.

// Prinzip: kritisches Hero-Bild priorisieren + Layout-Box reservieren
export function HeroImage({ src, alt, width, height }) {
  return (
    <img
      src={src}
      alt={alt}
      width={width}
      height={height}
      fetchPriority="high"
      decoding="async"
    />
  )
}

Referenzmethode Vorher/Nachher: Mallorca Expats und Alexandre Liard — schlankes HTML, messbare CWV nach Migration, ohne im alten Builder weiter zu „optimieren“.

Praktische Fix-Reihenfolge — was du zuerst angehst

Antwort zuerst: Messen → Render-Blocker und Hero für LCP → Layout-Reserven für CLS → JS-Budget für INP → wenn der Builder die Ursache ist, migrieren statt Cache-Plugins stapeln.

Schritt 1 — Baseline (Lab + Field)

Lab (Lighthouse/WebPageTest) auf Startseite, Top-Leistung, Kontakt. Field aus CrUX/Search Console, falls vorhanden. Ohne Baseline weißt du nicht, ob der Fix wirkte — und ob Field von Lab abweicht (häufig Third-Party auf Mobil).

Schritt 2 — LCP zuerst auf den Conversion-URLs

Priorisiere URLs mit Anfragen und Umsatz: Startseite, Leistungen, Kontakt, Top-3–5 Landingpages. Hero-Bild priorisieren, kritisches CSS reduzieren, serverseitiges HTML sicherstellen. Ziel: unter 2,5 s, ideal Richtung ~0,8 s nach Stack-Wechsel.

Schritt 3 — CLS absichern

Breite/Höhe für Bilder und Embeds, Fonts ohne Layout-Sprung, keine späten Banner über dem Fold ohne reservierten Platz. CLS-Fixes sind oft schnell und schützen Conversion, während du INP noch säuberst.

Schritt 4 — INP über JavaScript-Budget

Tracking hinter Consent, Chat-Widgets verzögern, Builder-Animationen streichen, lange Tasks splitten. Jedes synchron geladene Skript konkurriert mit Klick und Tippen.

Schritt 5 — Architekturentscheidung

Wenn trotz CDN und Optimierung LCP im Band 2,5–4,0 s bleibt und der DOM-Baum Pagebuilder-Ballast ist: WordPress-Migration oder Pagebuilder-Ablösung — nicht das fünfte Caching-Plugin. Baukästen: Wix-/Jimdo-Migration.

Die Entscheidung ist pragmatisch: Feintuning lohnt, solange einzelne Ursachen messbar und isolierbar sind. Sobald Theme, Builder und Plugins sich gegenseitig blockieren, wird jede weitere Optimierung teurer als ein sauberer Cutover — und die Field-Daten bleiben im gelben Band.

Messung (Lab+Field)
  → LCP: Hero, CSS, Server-HTML
    → CLS: Maße, Fonts, reservierte Boxen
      → INP: JS-Budget, Third-Party
        → Migration, wenn Builder/Plugin-Zoo die Ursache bleibt

Was der Census zu Performance und Extrahierbarkeit sagt

Antwort zuerst: In 6.675 Audits der AI-Readiness-Studie laufen 69,4 % auf Legacy-CMS; Agent-Ready liegt bei Ø 25/100 — Performance und Extrahierbarkeit hängen oft am Stack.

Weitere Benchmarks derselben Stichprobe: llms.txt 15,6 %, JSON-LD 41,9 %, Sitemap 73,5 %, robots 72,5 %. Der Engpass liegt also selten nur an „fehlender Sitemap“, sondern an Markup und Auslieferung. CWV-Modernisierung legt die technische Basis; GEO & AI-Sichtbarkeit und zitierfähige Inhalte kommen danach.

Wie hängen CWV und KI-Sichtbarkeit zusammen?

Antwort zuerst: Langsame, laute Seiten erhöhen Crawl-Timeout- und Extraktionsrisiko; zitierfähige Inhalte brauchen trotzdem Substanz — CWV allein erzeugt keine Brand Mentions.

Generative Pipelines extrahieren Passagen unter Zeitlimits. Seiten mit 3–4 s LCP und Pagebuilder-Rauschen verlieren gegen klare, schnelle Konkurrenz. Princeton GEO (Aggarwal et al., arXiv:2311.09735) zeigt Cite-/Stats-/Quote-Hebel — aber nur auf technisch extrahierbarer Basis. Technisches AI-Readiness (CWV, Crawl, Markup) ist nicht dasselbe wie nachgewiesene Marken-Nennung in ChatGPT; beides kann Ziel sein, darf aber nicht vermischt werden. Reihenfolge: Stack/CWV → optional Redesign → Knowledge Graph / llms.txt → Conversion.

Lab oder Field — was zählt für Core Web Vitals?

Antwort zuerst: Ranking und reale Nutzerqualität folgen Field Data (CrUX); Lab ist dein Debug-Werkzeug vor dem Go-Live — beides brauchst du, keines ersetzt das andere.

Lab (Lighthouse, WebPageTest) läuft unter kontrollierten Bedingungen: festes Gerät, festes Netz, keine echte Nutzerstreuung. Ideal, um Hero-Bilder, CSS-Blocker und JS-Tasks zu isolieren. Field (Chrome UX Report / Search Console) aggregiert echte Besuche — oft mobil, oft über schwächere Netze, oft mit Consent- und Chat-Skripten, die im Lab „aus“ sind. Weicht Field nach Migration noch ab, liegt die Ursache selten am CDN, sondern an Third-Party, an zu großen Formular-Skripten oder an Bildern ohne feste Maße auf Unterseiten, die du im Lab nicht getestet hast.

Praxis bei Modern Stack: Lab muss vor Cutover „grün genug“ sein; Field bestätigt in den folgenden Wochen, ob LCP stabil unter 2,5 s bleibt und Richtung ~0,8 s wandert. Ohne diesen Doppelcheck optimierst du ein Labor — nicht deine Webseite.

Was prüfen wir vor und nach Go-Live?

Antwort zuerst: Vor Cutover Lab auf den Top-Templates; nach Go-Live dieselben URLs plus Field (CrUX/Search Console) und Redirect-Stichproben — kein Soft-404, kein Ranking-Blindflug.

Checkliste: LCP/INP/CLS Lab auf Start, Leistung, Kontakt; Field-Baseline; Bild-/Font-Reserven; Third-Party hinter Consent; Redirect-Map; robots/sitemap. Technical SEO und Rankingverlust vermeiden gehören zum Cutover. Preise und Paketkontext: Preise & Pakete.

Wann lohnt Modernisierung für CWV — und wann reicht Feintuning?

Antwort zuerst: Feintuning reicht bei sauberem Markup und LCP knapp über 2,5 s; Modernisierung lohnt, wenn Builder/Plugin-Zoo LCP systematisch in 2,5–4,0 s hält.

Feintuning zuerst: gutes Theme ohne Builder, wenige Plugins, Bilder schon optimiert, Lab zeigt klare Einzelursache (ein Hero, ein Skript).

Modernisierung: Elementor/Divi-Ballast, Plugin-Konflikte, trotz CDN schlechte Field-Daten, fragile Forms, paralleles GEO-/Conversion-Ziel. Dann ist CWV kein „Score grün färben“, sondern Infrastrukturentscheidung — Inhalte behalten, fragile Schicht tauschen.

Checkliste vor dem Kick-off

Antwort zuerst: Ohne Zugänge, Top-URLs und Lab-/Field-Baseline startest du blind — mit vollständiger Checkliste siehst du nach dem Cutover klar, ob LCP unter 2,5 s oder Richtung ~0,8 s liegt.

Domain und Hosting-Zugang, Search-Console-Zugriff für Field/CrUX, Liste der Top-URLs nach Klicks und Anfragen, bekannte Third-Party-Skripte (Chat, Pixel, Consent), Screenshot der aktuellen Lab-Werte (LCP/INP/CLS mobil), Klarheit ob Elementor/Divi oder klassisches Theme, und ob Migration oder nur Feintuning das Ziel ist.

Kurz: Core Web Vitals modernisieren heißt Mechanik verstehen, Builder-Ursachen benennen und in der richtigen Reihenfolge fixen — bis der Stack LCP Richtung ~0,8 s liefert. Anfrage stellen