Core Web Vitals für Kanzleien — LCP, CLS und INP

Was Google seit dem Page-Experience-Update wirklich misst#

Google hat das Page-Experience-Signal in zwei Schritten scharf geschaltet: Im Juni 2021 wurden die Core Web Vitals offizieller Ranking-Faktor für die Mobile-Suche, im Februar 2022 zog die Desktop-Suche nach. Am 12. März 2024 hat INP (Interaction to Next Paint) den älteren Wert FID (First Input Delay) als drittes Core Web Vital abgelöst — die offizielle Bekanntmachung findet sich in der Google-Search-Central-Dokumentation zur Page Experience.

Für eine Kanzlei-Website klingt das nach einem Entwickler-Thema. Es ist aber ein Wettbewerbs-Thema: Bei zwei vergleichbaren Treffern in der lokalen Suche („Steuerberater Forchheim", „Steuerkanzlei Bamberg") gewichtet Google die Seite mit besseren Web-Vitals höher, sobald Inhalt und Relevanz vergleichbar sind. Das ist kein Ersatz für gute Inhalte. Es ist ein Tie-Breaker — und bei lokalen Suchen mit fünf bis zwölf relevanten Mitbewerbern entscheidet der Tie-Breaker oft, wer auf Platz drei und wer auf Platz acht landet.

Die drei Werte im Überblick#

Die folgende Tabelle fasst zusammen, was die drei Core Web Vitals messen und wo die Schwellen 2026 liegen. Die Werte sind die offiziellen Schwellen von web.dev — Core Web Vitals und werden vom Chrome User Experience Report (CrUX) als Field-Datenbasis verwendet.

Vital	Was es misst	Gut	Verbesserung nötig	Schlecht
LCP (Largest Contentful Paint)	Zeit bis das größte sichtbare Element fertig geladen ist	≤ 2,5 s	≤ 4,0 s	> 4,0 s
CLS (Cumulative Layout Shift)	Wie stark sich Inhalte beim Laden verschieben	≤ 0,1	≤ 0,25	> 0,25
INP (Interaction to Next Paint)	Reaktionszeit auf Klick, Tipp oder Tastendruck	≤ 200 ms	≤ 500 ms	> 500 ms

Google bewertet eine Seite als „gut" in den Core Web Vitals, wenn alle drei Werte im grünen Bereich liegen — gemessen am 75. Perzentil echter Besucher (das heißt: 75 % der Besucher müssen die Schwelle einhalten, nicht der Durchschnitt). Eine Seite mit gutem LCP und gutem CLS, aber rotem INP, fällt durch.

LCP: Was die größte Bremse auf Kanzlei-Seiten verursacht#

LCP misst, wann das größte sichtbare Element der Seite gerendert ist. Auf Kanzlei-Websites ist das meistens entweder ein Hero-Foto (Team, Bürogebäude, Stadt-Panorama) oder ein großer Überschriften-Block. Die folgende Tabelle ordnet die häufigsten LCP-Verursacher nach unserer Erfahrung aus rund 40 Audits zu — die Reihenfolge ist die typische Häufigkeit.

LCP-Verursacher	Wie häufig	Größter Hebel zur Lösung
Unkomprimierte Hero-Fotos (1–4 MB JPG/PNG)	sehr häufig	Konvertierung in WebPWebP · zum GlossarModernes Bildformat — 25–35 % kleiner als JPEG bei gleicher Qualität./AVIFAVIF · zum GlossarNoch effizienteres Bildformat als WebP — 30–50 % kleiner, in Top-Browsern verfügbar. + width/height setzen + responsive srcset
Custom-Fonts ohne font-display: swap	häufig	Selbst-gehostete Schrift mit swap oder optional einbinden
Externe Google-Fonts-CDN-Aufrufe	häufig	Auf selbst-gehostete Variante via next/font umstellen
Render-blockierende Drittanbieter-Skripte (DATEV-Portal-Widget, Chat)	mittel	async / defer setzen oder lazy laden nach Interaktion
CMS-Theme-CSS in voller Breite (200–500 KB)	mittel	Critical-CSS extrahieren, Rest asynchron nachladen
Hosting im Drittland (US-Region)	selten	EU-Region oder Edge-Caching (VercelVercel · zum GlossarHosting-Plattform für moderne Web-Apps — Standard-Heimat für Next.js-Sites mit EU-Region., CloudflareCloudflare · zum GlossarUS-Anbieter für CDN, WAF, DDoS-Schutz und Turnstile — Privacy-by-Design-Ausrichtung.)

Wer das Mandantenportal-Thema vertiefen möchte: Wir haben dazu einen eigenen Praxis-Leitfaden — siehe DATEV-Mandantenportal Integration in die Kanzlei-Website.

CLS: Warum Cookie-Banner und Web-Schriften die häufigste Ursache sind#

CLS misst kumulativ, wie weit sich Inhalte beim Laden verschieben. Ein Layout-Shift entsteht immer dann, wenn ein Element auf der Seite seinen Platz erst nach dem ersten Render bekommt. Die häufigsten CLS-Verursacher auf Steuerkanzlei-Websites sind in dieser Reihenfolge:

1. Cookie-Banner, die nach 300–800 ms nachgeladen werden. Das Banner schiebt den gesamten Seiteninhalt nach unten. CLS-Werte zwischen 0,15 und 0,40 sind typisch.
2. Web-Fonts ohne size-adjust oder font-display: optional. Die Schrift wechselt nach dem Laden — Zeilen-Höhen springen, Überschriften rutschen.
3. DATEV-Portal-Banner ohne reservierte Höhe. Wenn das Widget erst nach Server-Antwort gerendert wird, springt der darunterliegende Inhalt mit.
4. Bilder ohne width/height-Attribute. Der Browser kennt die Platz-Anforderung nicht und schiebt nach.
5. Dynamisch eingefügte Hinweisboxen. „Wir nutzen Cookies", „Neue Mandanten-Aktion", „Mitarbeiter-Bewerbung offen" — alles, was nach Render erscheint, kostet CLS.

Für die rechtliche Seite des Cookie-Themas siehe unseren Artikel DSGVO-konforme cookielose Steuerkanzlei-Website.

INP: Der jüngste Vital und der unterschätzteste#

INP misst, wie schnell die Seite auf jede Benutzer-Interaktion reagiert — vom ersten Klick bis zum letzten Tastatur-Tipp im Kontakt-Formular. Wenn FID nur den ersten Tipp gemessen hat, schaut INP über den gesamten Besuch und berichtet das schlechteste der gemessenen 98 Prozent. Das ist eine deutlich härtere Messlatte.

Typische INP-Probleme auf Kanzlei-Websites:

• Alte WordPress-Plugins mit jQuery 1.x/2.x: ContactForm 7, alte Slider, Map-Plugins. Jeder Klick zieht 200–400 KB JavaScript durch eine einzige Verarbeitungs-Schleife.
• Unoptimierte Formulare: Live-Validierung, die bei jedem Tastendruck synchron rechnet. Auf älteren Smartphones fühlt sich die Tastatur „laggy" an.
• Echtzeit-Bewertungs-Widgets: Provenexpert, ProvenExpert-Konkurrenz, Trustami. JavaScript wird bei Klick geladen, die UI friert für 300–800 ms ein.
• Third-Party-Chat-Widgets: Tawk.to, Drift, Crisp. Die initiale Interaktion ist oft die langsamste.

Mess-Tools im Vergleich#

Vier Tools, die Sie ohne Lizenz und ohne IT-Kenntnisse nutzen können. Jedes hat eine eigene Stärke — und einen blinden Fleck.

Tool	Datentyp	Stärke	Schwäche
PageSpeed Insights (pagespeed.web.dev)	Lab + Field (28 Tage)	Schnellster Überblick, zeigt beide Datenquellen parallel	Einzel-Test, kein Trend-Verlauf
Chrome Web Vitals Extension	Real-Time im eigenen Browser	Werte während des Surfens sichtbar, nützlich beim Debugging	Misst nur Ihren eigenen Besuch, nicht andere
Lighthouse CLI	Lab (synthetisch)	Reproduzierbar, automatisierbar, CI-fähig	Keine Field-Daten, simuliert nur eine Mobile-Verbindung
Chrome UX Report (CrUX)	Field, 28 Tage rollend	Echte Werte realer Besucher — Googles Ranking-Datenquelle	Erst ab ca. 1.000 Besuchen pro Monat verlässlich

Wenn Sie nur ein Tool nutzen wollen: PageSpeed Insights. Es kombiniert beides — den Lighthouse-Lab-Lauf für die schnelle Diagnose und die CrUX-Field-Daten für das, was Google tatsächlich von Ihrer Seite sieht.

Lab-Daten vs. Field-Daten — was zählt fürs Ranking?#

Diese Unterscheidung ist die wichtigste, die Sie aus diesem Artikel mitnehmen sollten.

• Lab-Daten entstehen aus einem einzelnen synthetischen Test (Lighthouse, WebPageTest). Sie sind reproduzierbar, schnell und gut zum Debugging. Sie fließen aber nicht ins Google-Ranking ein.
• Field-Daten stammen aus dem Chrome User Experience Report. Echte Chrome-Nutzer auf echten Geräten in echten Netzen — gemessen über 28 Tage rollend. Diese Daten nutzt Google für das Ranking.

Ergebnis: Eine Seite mit Lighthouse-Score 95 kann im echten CrUX-Bericht trotzdem rot sein, wenn 26 % der Besucher mit alten Smartphones an schwachen Netzen unterwegs sind. Umgekehrt kann eine Seite mit Lighthouse-Score 75 im Feld grün sein, weil die echten Besucher überwiegend Desktop-Nutzer mit Glasfaser sind.

Lighthouse-CLI in der Praxis#

Für reproduzierbare Messungen — etwa vor und nach einem Deployment, oder als Grundlage für die Mandanten-Berichts-PDF — eignet sich die Lighthouse-Kommandozeile. Sie ist Teil des Node.js-Ökosystems und auf jedem Mac und Windows-Rechner in 5 Minuten installiert.

# Einmal-Lauf für die Startseite (Mobile-Profil, wie Google es nutzt)
npx lighthouse https://kanzlei-musterstadt.de \
  --form-factor=mobile \
  --throttling-method=simulate \
  --output=html \
  --output-path=./report-startseite.html

# Alle Unterseiten in einem Rutsch (Bash-Beispiel)
for path in / /team /kontakt /karriere /tätigkeitsfelder; do
  npx lighthouse "https://kanzlei-musterstadt.de${path}" \
    --form-factor=mobile \
    --output=json \
    --output-path="./lh-$(echo $path | tr / -).json" \
    --quiet
done

Das Resultat ist ein HTML-Bericht, den Sie einer Mandantin oder einem Mandanten als PDF weitergeben können — oder ein JSON, das Sie für eigene Auswertungen weiterverarbeiten. Im CI-Lauf (GitHub Actions, GitLab) prüfen wir die Werte automatisch bei jedem Deployment und blockieren den Release, wenn Performance unter 90 oder LCP über 2 Sekunden fällt.

Bild-Optimierung mit Next.js#

Bilder sind in 70 % unserer Audits die größte LCP-Bremse. Wenn die Kanzlei-Website auf Next.jsNext.js · zum GlossarReact-Framework für SSG/SSR/ISR — der aktuelle Standard für moderne Kanzlei-Sites. läuft, ist die Lösung ein einzeiliger Tausch:

import Image from "next/image";
import heroFoto from "./team-empfang.jpg";

export function Hero() {
  return (
    <Image
      src={heroFoto}
      alt="Empfangsbereich der Steuerkanzlei in Musterstadt"
      priority
      sizes="(max-width: 768px) 100vw, 1200px"
      placeholder="blur"
    />
  );
}

Was Next.js dabei automatisch macht:

• WebP- und AVIF-Variante generieren (60–80 % kleiner als JPG bei gleicher Qualität)
• width und height aus dem Import-Objekt setzen → CLS = 0 für dieses Element
• Blur-Platzhalter rendern, während das Bild lädt → wahrgenommene Performance steigt
• Mit priority als LCP-Kandidat markieren → Browser priorisiert den Download

Performance-Budget für eine Kanzlei-Website#

Ein Performance-Budget ist eine selbst gesetzte Obergrenze pro Asset-Kategorie. Wer sich daran hält, kommt automatisch in den grünen Bereich aller drei Vitals. Die folgenden Werte verwenden wir bei FA² als Standard für jede neu gebaute Kanzlei-Site:

Asset-Kategorie	Budget (Mobile)	Anmerkung
HTML	≤ 30 KB komprimiert	Statisch vor-gerendert, kein Server-Roundtrip pro Besucher
CSS (Critical)	≤ 14 KB inline	Erstes Render unter 1 Sekunde möglich
CSS (Total)	≤ 50 KB komprimiert	Rest asynchron nachgeladen
JavaScript (Initial)	≤ 80 KB komprimiert	Genug für Navigation + Cookie-freie Analytics
JavaScript (Total)	≤ 200 KB komprimiert	Inkl. Lazy-Loaded Module
Bilder (Hero, above fold)	≤ 150 KB	WebP/AVIF, responsive srcset
Web-Schriften	≤ 60 KB total	Maximal zwei Schnitte, woff2 + subset
Drittanbieter-Skripte	0 KB im initialen Render	Lazy-laden nach Interaktion
LCP-Ziel	≤ 1,8 Sekunden	Liegt unter Googles Grün-Schwelle von 2,5 Sekunden
INP-Ziel	≤ 150 ms	Polster auf Googles Grün-Schwelle von 200 ms
CLS-Ziel	≤ 0,05	Polster auf Googles Grün-Schwelle von 0,1

Das Budget ist bewusst konservativ — wir wollen Reserve haben, wenn ein Mandant uns nach Go-Live um ein zusätzliches Widget bittet (DATEV-Login, Karriere-Banner). Für Bestands-Websites mit WordPress liegt das Realistische bei JavaScript-Total ≤ 350 KB und LCP ≤ 2,5 Sekunden. Auch das ist ein deutlicher Fortschritt gegenüber Branchen-Durchschnitt.

Edge-Caching als letzte Meile#

Selbst die saubere Code-Basis verliert an Geschwindigkeit, wenn die Datenpakete vom Server in Falkenstein bis zum Smartphone in Bayreuth jedes Mal 300 Kilometer fahren. Edge-Caching löst das, indem die statischen Inhalte einer Website an hunderten Punkten weltweit zwischengelagert werden — bei Cloudflare an 320 Standorten, bei Vercel an 40+.

Konkret bringt das auf einer Kanzlei-Site:

• TTFB (Time To First Byte) sinkt von 400–800 ms auf 30–80 ms. LCP profitiert direkt um 200–500 ms.
• Server-Last sinkt um 90 %. Auch ein Mandanten-Ansturm nach einem Lokalzeitung-Artikel überfordert die Site nicht.
• DDoS-Schutz als Nebeneffekt — bei Vercel und Cloudflare im Standard enthalten.

Für eine statisch vor-gerenderte Next.js-Site (wie unsere Standard-Architektur im Mandanten-Boost) ist das Edge-Caching ohne Zusatzaufwand aktiv: jeder HTML-Snapshot liegt automatisch am nächstgelegenen Edge-Knoten, der Browser bekommt die Antwort in unter 100 Millisekunden.

Was Sie selbst tun können — eine 60-Minuten-Checkliste#

Wenn Sie diesen Artikel mit dem eigenen Auftritt vergleichen wollen, hier ist die kürzeste sinnvolle Selbst-Diagnose:

1. PageSpeed Insights aufrufen und Ihre Startseite + zwei Unterseiten messen (Mobile + Desktop).
2. Drei Werte notieren: LCP, CLS, INP — jeweils aus dem Feld-Daten-Block oben im Bericht.
3. Google Search Console öffnen (sofern eingerichtet) → Bereich „Core Web Vitals" → den 28-Tage-Trend ansehen.
4. Hero-Bild prüfen: Rechts-Klick → „Bild speichern" → wenn die Datei größer als 300 KB ist, ist hier ein Hebel.
5. Cookie-Banner prüfen: Wenn ein Banner vorhanden ist, ist CLS nach unserer Audit-Erfahrung typischerweise rot. Die cookielose Architektur ist nicht für alle Sites realistisch, aber bei reinen Kanzlei-Sites fast immer.
6. DATEV-Widget prüfen: Wenn das Mandanten-Login-Widget direkt im Hero geladen wird (nicht erst beim Klick), ist hier 300–800 ms LCP-Hebel.

Wer keine Lust auf Selbst-Diagnose hat: unser URL-Audit macht genau das in 60 Sekunden, kostenlos, ohne Anmeldung — und zeigt die drei Werte im Vergleich zu sieben weiteren Performance-Kriterien.

Wenn Sie über eine Neu-Schaltung Ihrer Kanzlei-Website nachdenken, ist der Mandanten-Boost das Paket mit den vertraglich garantierten Vitals-Werten. Lassen Sie uns das in einem Erstgespräch besprechen — Kontakt finden Sie unter /#kontakt.

Zum Weiterlesen#

Verwandte Insights aus unserem Korpus:

• DSGVO-konforme cookielose Steuerkanzlei-Website — die rechtliche und technische Begründung für das Banner-freie Design, mit Lighthouse-Vergleich
• Schema.org für Steuerberater — der LocalBusiness-Markup-Leitfaden — strukturierte Daten als zweiter Hebel neben den Vitals
• DATEV-Mandantenportal Integration in die Kanzlei-Website — wie das Portal Performance-neutral eingebunden wird

Quellen#

• Google web.dev — Core Web Vitals (LCP, INP, CLS) — abgerufen 2026-05-29
• Google web.dev — Largest Contentful Paint (LCP) — abgerufen 2026-05-29
• Google Search Central — Page Experience — abgerufen 2026-05-29
• Google Search Central — Introducing INP (FID-zu-INP-Wechsel) — abgerufen 2026-05-29
• Chrome UX Report (CrUX) — Dokumentation — abgerufen 2026-05-29

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung. Core-Web-Vitals-Schwellen und Mess-Methodik ändert Google laufend; maßgeblich ist die jeweils aktuelle web.dev-/Search-Central-Dokumentation.

Bei Rückfragen zur Performance Ihrer Kanzlei-Website schreiben Sie uns gerne an kontakt@fahoch2.de oder nutzen Sie unser URL-Audit.