Redesign oder Neuaufbau? Germany Core Web Vitals als Entscheidungsgrundlage für kleine Unternehmen

Problem und Symptome
Viele kleine Unternehmen erkennen Probleme anhand von Symptomen – diese sind jedoch noch keine Entscheidungskriterien:

• • Hohe Absprungraten, insbesondere auf mobilen Seiten, lange Ladezeiten in Analytics.

• • Sichtbare Verschiebungen von Layout-Elementen beim Laden (z. B. „springen“ die Schaltflächen), was die Conversion beeinträchtigt.

• • Interaktive Elemente reagieren träge (Beschwerden über interne Verzögerungen oder langsame Checkout-Schaltflächen).

• • Die Search Console meldet schlechte Core Web Vitals-Pfade oder keine CrUX-Felddaten-Berichterstattung (zu wenige Stichproben).

Diese Symptome stehen in direktem Zusammenhang mit den Core Web Vitals: Largest Contentful Paint (LCP) misst die wahrgenommene Ladezeit, Interaction to Next Paint (INP) misst die Interaktivität und Cumulative Layout Shift (CLS) misst die visuelle Stabilität. Für die Bewertung nutzt Google das 75. Perzentil der Seitenaufrufe; dies ist relevant, da es die Erfahrung von 3 von 4 Besuchern widerspiegelt. (web.dev)

Was gemessen werden muss – und wie
Wichtige Quellen und Hilfsmittel:

• • Google Search Console – Core Web Vitals-Bericht: Übersicht darüber, welche Seiten/Cluster Probleme aufweisen. (wichtig für die Priorisierung von Domains und Seiten). (developers.google.com)

• • PageSpeed Insights (PSI): liefert Felddaten (CrUX, 28-Tage-Fenster) und Lab-Diagnosen über Lighthouse. Gut geeignet für eine schnelle Überprüfung einzelner URLs. (developers.google.com)

• • Chrom Benutzererfahrung Report (CrUX) / BigQuery-API: für umfangreichere Analysen, Segmentierungen (Land, Gerät usw.). (developer.chrome.com)

• • Lab-Tools: Lighthouse, Web-Vitals-JS-Bibliothek zur Ursachenermittlung bei Interaktionsproblemen. Lab-Daten simulieren Probleme, Felddaten zeigen die tatsächliche Nutzererfahrung. (developers.google.com)

Konkrete Kennzahlen (verifizierte Schwellenwerte)

• • LCP: “Gut” ≤ 2500 ms (75. Perzentil).

• • INP: “Gut” ≤ 200 ms (75. Perzentil).

• • CLS: “Gut” ≤ 0,10 (75. Perzentil).
    Google klassifiziert Erlebnisse in „Gut“, „Verbesserungswürdig“ und „Schlecht“ und bewertet eine Seite/Origin als „bestanden“, wenn für alle drei Metriken das 75. Perzentil im Bereich „Gut“ liegt. Die Felddaten stammen aus CrUX (28-Tage-Aggregation). (web.dev)

Geschäftliche Auswirkungen (nachgewiesene Ergebnisse)
Die Performance wirkt sich direkt auf die Konversionsrate, die Nutzerbindung und den Umsatz aus. Eine viel beachtete, von Google in Auftrag gegebene Analyse (Deloitte / Fifty‑Five, „Milliseconds Make Millions“, 2020) stellte fest, dass bereits kleine Verbesserungen der Ladezeit auf Mobilgeräten einen messbaren positiven Effekt auf den Funnel-Fortschritt und die Conversions hatten; die Studie dokumentiert unterschiedliche Auswirkungen je nach Branche und Funnel-Schritt. Das heißt: Investitionen in Ladezeit und Interaktion können messbar wirtschaftlich sein – aber der Effekt ist stark kontextspezifisch. (deloitte.com)

Wichtige Klarstellung: Core Web Vitals sind Signale im Rahmen des Page-Experience-Rankings von Google, aber nicht der einzige Faktor – Relevanz, Inhalt und Autorität bleiben entscheidend für die Sichtbarkeit in den Suchergebnissen. Gute Vitals fördern die Sichtbarkeit und das Vertrauen der Nutzer, garantieren jedoch allein noch kein Top-Ranking. (developers.google.com)

Prioritäten: Jetzt / Nächste Schritte / Später
Jetzt (geringer Aufwand, hohe Hebelwirkung)

• • Messen und priorisieren: Search Console Core Web Vitals + PSI für Seiten mit hohem Traffic. Erfassen Sie LCP/INP/CLS p75 für Mobilgeräte und Desktop. (developers.google.com)

• • Schnelle Win-Fixes: Bildoptimierung (responsive Formate, LCP-Bild vorab laden), Schriftarten optimieren (font-display), kritisches CSS inline einfügen, Skripte von Drittanbietern asynchron laden oder verzögert laden. (Empfehlung)

• • Überprüfen Sie die HTTPS-/Basic-Sicherheit; sichere Seiten sind Teil der Page Experience. (developers.google.com)

Nächste Schritte (mittlerer Aufwand)

• • Debugging: Nutzen Sie Lighthouse-Audits und die web-vitals-Bibliothek, um festzustellen, welche Elemente LCP/INP/CLS beeinflussen. (developers.google.com)

• • Fokus auf kritische Pfade: Optimieren Sie die Server-Antwortzeit (TTFB), den Einsatz von CDNs und die Caching-Header und vermeiden Sie unnötige Render-Blocking-Skripte. (Empfehlung)

• • Mithilfe von UX-Tests an entscheidenden Punkten des Trichters (Produktdetail, Checkout) messen Sie Veränderungen der Konversionsrate vor und nach Optimierungen. (Empfehlung, gestützt auf Erkenntnisse von Deloitte). (deloitte.com)

Später (höherer Aufwand / strategisch)

• • Entscheidung zum technischen Replatforming: Wenn das CMS/der Stack die Optimierung dauerhaft verhindert (z. B. teilweise serverseitig nicht zwischenspeicherbar, umfangreiche JS-Abfragen), dann einen Neuaufbau prüfen. (Empfehlung)

• • Architekturwechsel: z. B. zu serverseitigem Rendering/Hybrid-Rendering, schlankem Frontend-Framework, Headless-CMS + CDN, sofern langfristige Skalierbarkeits- und Performance-Ziele dies rechtfertigen. (Empfehlung)

Entscheidungskriterien: Redesign vs. Neuaufbau
Wägen Sie diese Punkte unter formalen Gesichtspunkten ab:

1. 1. Messbare Zielabweichungen: Liegen LCP/INP/CLS auf Top-Funnel-Seiten (p75) deutlich außerhalb des Bereichs „Good“? Wenn ja, wie hoch ist das Potenzial (Traffic × Conversion) für Umsatzsteigerungen? (Fakt: Metriken und p75 messen; geschäftlicher Wert kontextspezifisch.) (web.dev)

1. 1. Technische Schuld: Ist das CMS/Theme so veraltet, dass Hotfixes nur vorübergehend Abhilfe schaffen? Weist das System tiefgreifende Render-Blocking-Probleme auf, die sich nicht durch Optimierungsmaßnahmen beheben lassen? (Empfehlung)

1. 1. Wartbarkeit & Kosten: Wie hoch sind die Entwicklungskosten für iteratives Refactoring im Vergleich zu einer geplanten Neuentwicklung? Berücksichtigen Sie dabei Risiken, Know-how und die Markteinführungszeit. (Empfehlung)

1. 1. Integrationen & Funktionen: Soll die Website neue Funktionen erhalten (z. B. personalisierte KI-Funktionen, komplexe Integrationen), die ein moderner Tech-Stack deutlich einfacher und leistungsfähiger unterstützt? (Empfehlung)

1. 1. SEO & Sichtbarkeit: Sind relevante Seiten von Search-Console-Warnungen betroffen? Verfügen Sie in CrUX über einen ausreichenden Traffic-Stichprobenumfang, um Felddaten zu validieren? (Fakt: CrUX benötigt genügend Stichproben, andernfalls zeigt PSI „Origin-Level“ oder keine Daten an). (developers.google.com)

Verifizierte Fakten (kurz)

• • Core Web Vitals = LCP, INP, CLS; „Good“-Schwellenwerte: LCP ≤ 2,5 s; INP ≤ 200 ms; CLS ≤ 0,1 (75. Perzentil). (web.dev)

• • PageSpeed Insights verwendet CrUX-Felddaten (28 Tage) sowie Lighthouse-Labordaten; PSI zeigt Verteilungen und p75-Werte an. (developers.google.com)

• • Google nutzt die Page Experience (einschließlich Core Web Vitals) als eine Reihe von Signalen in seinen Ranking-Systemen, doch die Relevanz spielt weiterhin die entscheidende Rolle. (developers.google.com)

• • Studien (z. B. Deloitte / „Milliseconds Make Millions“, im Auftrag von Google) belegen messbare Conversion-Gewinne durch bessere Ladezeiten; die Ergebnisse variieren je nach Branche und Position im Funnel. (deloitte.com)

Berufliche Empfehlungen (separat)

• • Lesen Sie zuerst: Investieren Sie maximal 1–2 Tage in die Datenerhebung (Search Console, PSI, einfache CrUX-Abfrage), bevor Sie einen technischen Kostenvoranschlag anfordern. (Empfehlung)

• • Priorisieren Sie Seiten mit hohem Traffic und kritische Funnels – optimieren Sie diese zuerst. (Empfehlung)

• • Wenn mehr als 50 % Ihrer Conversions von Seiten stammen, deren p75-LCP deutlich über 4 s liegt oder deren INP über 500 ms beträgt, sollten Sie ernsthaft über einen Neuaufbau nachdenken; andernfalls ist ein gezieltes Redesign meist kosteneffizienter. (Faustregel; auf Zahlen basierend)

• • Vergessen Sie die Wartung nicht: Dokumentierte Tests, CI/CD, automatisierte Lighthouse-Checks und monatliches Monitoring verhindern Rückfälle. (Empfehlung)

Kurze Checkliste (konkret)

• • [ ] Search Console: Bericht „Core Web Vitals“ öffnen, Top-Seiten exportieren. (developers.google.com)

• • [ ] PageSpeed Insights: p75-Werte für die Top-10-URLs (mobil/Desktop) prüfen (Screenshots speichern). (developers.google.com)

• • [ ] CrUX / BigQuery oder PSI Origin-Fallback prüfen: Sind genügend Samples vorhanden? (developer.chrome.com)

• • [ ] Lab-Audit: Lighthouse für die Zielseite (Mobil/Desktop) durchführen, die Top-5-Audits priorisieren. (developers.google.com)

• • [ ] Quick-Wins: LCP-Bild vorab laden, kritisches CSS, Drittanbieter-Inhalte minimieren, font-display:swap. (Empfehlung)

• • [ ] Business-Rechnung: Schätzen Sie den kurzfristigen Umsatzzuwachs (Traffic × Conversion × Wert) bei einer angenommenen Verbesserung der Conversion-Rate; vergleichen Sie dies mit der Kostenschätzung für ein Redesign im Vergleich zu einem Neuaufbau. (Empfehlung)

• • [ ] Langfristplan: Wenn technische Schulden und Feature-Roadmap miteinander kollidieren → Neuaufbau in Phasen planen (MVP → Iterationen). (Empfehlung)

Abschluss
Nutzen Sie Daten als Ausgangspunkt: Die Core Web Vitals bieten eine klare, messbare Entscheidungsgrundlage. Für viele kleine Unternehmen ist ein gezieltes Redesign (Top-Seiten + technische Engpässe) wirtschaftlicher; ein kompletter Neuaufbau lohnt sich, wenn technische Schulden, Wartungsaufwand und zukünftige Anforderungen einen schnellen Return durch Leistung und Funktionalität erwarten lassen. Beginnen Sie mit der Messung und Priorisierung – erst dann sollten Sie das Budget und den Weg festlegen. (developers.google.com)

Wenn Sie möchten, kann ich als Nächstes eine kurze To-Do-Liste für die Messungen Ihrer Top-5-Seiten erstellen (welche Tools, welcher Zeitaufwand, welche Datenexporte).