Zum Inhalt springen

Performance-Modul

Core Web Vitals bei JERVIS: eigene Messung plus Google-Referenzwerte

JERVIS prüft bei jeder Seite zwei technische Werte mit einem echten Browser selbst: die Server-Antwortzeit (TTFB) und den Zeitpunkt des ersten sichtbaren Inhalts (FCP). Die drei Core Web Vitals, Googles Kennzahlen für Ladegeschwindigkeit, Interaktion und visuelle Stabilität einer Seite, misst JERVIS nicht mit einer eigenen Methode. LCP, INP und CLS ruft JERVIS stattdessen als Googles offizielle Schwellenwerte über die PageSpeed-Insights-Schnittstelle ab und ordnet sie für Ihre Seite ein. Diese Seite trennt beide Quellen klar: was JERVIS selbst erhebt und was aus Googles eigenen Daten stammt.

Kostenlos testen → Zum Full Audit
TTFB & FCP im echten Browser
JERVIS-Eigenmessung
LCP · INP · CLS Google-Referenz
Kein Schätzwert
Nutzen

Was bringt Ihnen die Core-Web-Vitals-Prüfung?

Eine langsame Seite kostet doppelt: Besucher springen ab, bevor Inhalte überhaupt sichtbar sind, und Google berücksichtigt genau diese Geschwindigkeit im mobilen Ranking. Diese Seite zeigt, wo Ihre Website tatsächlich bremst, mit harten Messwerten statt Bauchgefühl.

  • ⚡ Echte Bremsen statt Vermutungen

    Statt eines vagen "die Seite fühlt sich langsam an" zeigt der Report konkret, ob Server, Bilder oder Skripte die Ladezeit ausbremsen, mit Fundstelle und Empfehlung.

  • 📈 Googles eigene Maßstäbe im Blick

    LCP, INP und CLS sind die Werte, mit denen Google die Nutzererfahrung Ihrer Seite selbst bewertet. JERVIS ordnet Ihre Seite direkt gegen diese offiziellen Google-Schwellen ein.

  • 🎯 Bilder als größter Hebel

    Bilder sind meist der einfachste Hebel für spürbar bessere Ladezeit. Die Bild-Checks zeigen konkret, welche Bilder komprimiert oder in einem moderneren Format ausgeliefert werden sollten.

  • ✅ Priorität statt Zahlenwust

    Der Report priorisiert, welcher Fix den größten Effekt auf Ladezeit und Absprungrate hat, statt Sie mit einer unsortierten Liste von Messwerten allein zu lassen.

Eigene Messung

Was JERVIS technisch selbst misst: TTFB und FCP im echten Browser

JERVIS öffnet jede geprüfte Seite in einem echten Playwright-Browser und liest zwei Werte direkt aus der Navigation-Timing- und der Paint-Timing-API des Browsers aus. Kein Schätzwert, keine Simulation. Beide Werte fließen mit eigenem Gewicht in den JERVIS-Score der Seite ein.

JERVIS-Eigenmessung

TTFB, Time to First Byte

Misst die Zeit vom Seitenaufruf bis zur ersten Antwort des Servers. Eine auffällig langsame Antwort meldet JERVIS als Hinweis oder Warnung, je nach Ausprägung. Eine schnelle Serverantwort ist die Grundlage für alles, was danach lädt.

JERVIS-Eigenmessung

FCP, First Contentful Paint

Misst den Zeitpunkt, an dem der Browser den ersten sichtbaren Inhalt rendert. Ein spät erscheinender erster Inhalt meldet JERVIS als Hinweis oder Warnung. Der FCP liegt zeitlich immer nach dem TTFB.

Reihenfolge von TTFB und FCP beim Seitenaufruf Schematischer Zeitstrahl ohne Messwerte: nach dem Seitenaufruf antwortet zuerst der Server, das ist TTFB, danach rendert der Browser den ersten sichtbaren Inhalt, das ist FCP. FCP liegt damit zeitlich immer nach TTFB. Reihenfolge beim Laden einer Seite Seitenaufruf Start TTFB Time to First Byte erste Antwort des Servers FCP First Contentful Paint erster sichtbarer Inhalt zeitlich immer danach
Schematische Darstellung ohne Messwert: TTFB und FCP misst JERVIS beide selbst, FCP folgt dabei immer auf TTFB.
Google-Referenz

Die drei offiziellen Google-Schwellenwerte: LCP, INP und CLS

Für LCP, INP und CLS nutzt JERVIS keine eigene Messmethode. JERVIS ruft diese drei Werte über die Google PageSpeed Insights API ab (Lighthouse-Auswertung). Optional ergänzt JERVIS sie um Felddaten aus dem Google Chrome UX Report (CrUX), echte Nutzerdaten von Google selbst. JERVIS zeigt diese Werte für Ihre Seite an und ordnet sie ein, erhebt sie aber nicht selbst.

Wichtig: Diese drei Werte sind Googles offizielle Schwellenwerte, abgerufen über die PageSpeed-Insights-API von Google. JERVIS zeigt und ordnet sie ein, es handelt sich nicht um eine JERVIS-Eigenmessung.
  • LCP
    Largest Contentful Paint: Ladezeit des größten sichtbaren Elements, laut Google
    2,5sgut bis hierher
    0s4,0süber 4,0s
  • INP
    Interaction to Next Paint: Reaktionszeit auf Klicks und Eingaben, laut Google
    200msgut bis hierher
    0ms500msüber 500ms
  • CLS
    Cumulative Layout Shift: Summe der Layout-Verschiebungen, laut Google
    0,1gut bis hierher
    00,25über 0,25
Umsetzung

LCP, INP und CLS verbessern: die wirksamsten Hebel

Die drei Google-Schwellenwerte von oben, 2,5 Sekunden für LCP, 200 Millisekunden für INP und 0,1 für CLS, lassen sich mit gezielten Maßnahmen an Bild, Skript und Layout spürbar verbessern. Die folgenden Hebel wirken erfahrungsgemäß am stärksten.

  • LCP

    Largest Contentful Paint

    ✓ Hero-Bild komprimieren und wo möglich als AVIF ausliefern, moderne Formate reduzieren die Dateigröße spürbar gegenüber JPEG oder PNG.
    ✓ fetchpriority="high" ausschließlich auf dem tatsächlichen LCP-Element setzen, nicht großzügig auf mehrere Bilder verteilen.
    ✓ Server-Antwortzeit senken: Caching und ein CDN verkürzen die Zeit bis zur ersten Antwort, siehe TTFB oben.
    ✓ Kritisches CSS inline im Kopfbereich einbetten, damit der größte sichtbare Bereich ohne zusätzliche Render-blockierende Anfrage erscheint.
  • INP

    Interaction to Next Paint

    ✓ Lange JavaScript-Tasks in kleinere Abschnitte aufteilen, damit der Haupt-Thread zwischen den Häppchen für Eingaben frei bleibt.
    ✓ Event-Handler entschlacken: unnötige Berechnungen aus Klick- und Eingabe-Handlern entfernen oder auf einen späteren Zeitpunkt verschieben.
    ✓ Drittanbieter-Skripte wie Tracking oder Chat-Widgets verzögert laden, etwa mit defer oder erst nach der ersten Nutzerinteraktion.
  • CLS

    Cumulative Layout Shift

    ✓ width und height (oder aspect-ratio) auf jedem Bild setzen, damit der Browser den Platz schon vor dem Laden reserviert.
    ✓ Feste Platzhalter für dynamisch nachladende Inhalte reservieren, etwa für Werbebanner oder eingebettete Widgets.
    ✓ font-display (zum Beispiel swap) setzen und Web-Fonts vorladen, damit nachladende Schriftarten den Text nicht nachträglich verschieben.
    ✓ Keine Banner oder Elemente nachträglich über bestehendem Content einblenden, ohne vorher Platz dafür freizuhalten.
Bewertung

Wie JERVIS bewertet: Schweregrade und Bildchecks als Hebel

JERVIS ordnet jeden Befund einem von vier Schweregraden zu: kritisch, Warnung, Hinweis oder bestanden. Jeder Schweregrad zieht unterschiedlich stark am Score der Seite.

TTFB, FCP und die Bild- und Performance-Checks gehören zum Technik-Modul. Dieses Modul fließt mit spürbarem Gewicht in den Gesamtscore der Website ein. LCP, INP und CLS haben dagegen keine eigene JERVIS-Bewertung: sie folgen Googles eigener Drei-Zonen-Einteilung in gut, mittel und schlecht, die JERVIS lediglich als Referenz anzeigt.

Die vier JERVIS-Schweregrade in der Reihenfolge kritisch, Warnung, Hinweis, bestanden Vier gleich breite Segmente in einer Reihe: kritisch, Warnung, Hinweis und bestanden, jeweils in einer eigenen Farbe. Die Darstellung zeigt nur die Reihenfolge, keine Gewichtung und keinen Punktwert. Die vier JERVIS-Schweregrade kritisch Warnung Hinweis bestanden Reihenfolge laut Seitentext, ohne Gewichtsangabe
Schematische Darstellung der vier JERVIS-Schweregrade. Kein Punktwert, keine Gewichtung dargestellt.

Bild-Checks als zusätzlicher Hebel

  • 1

    Lazy Loading fehlt

    Bilder unterhalb des sichtbaren Bereichs ohne Lazy Loading (verzögertes Nachladen von Bildern beim Scrollen) meldet JERVIS als Hinweis, Logos und Navigations-Bilder sind davon ausgenommen.

  • 2

    Kein modernes Format

    Nur WebP, AVIF und SVG zählen als moderne Bildformate. JPEG, PNG und andere ältere Formate meldet JERVIS als Hinweis, moderne Formate können die Dateigröße spürbar reduzieren.

  • 3

    Großes Einzelbild

    Auffällig große Einzelbilder meldet JERVIS als Warnung.

Weitere Performance-Checks

✓ Auffällig große DOM-Größe (Anzahl der HTML-Elemente einer Seite): Hinweis oder Warnung, je nach Ausprägung
✓ Render-blockierende Skripte im Kopfbereich ohne async oder defer, als Warnung
✓ Veraltetes HTTP-Protokoll, HTTP/1.1 statt HTTP/2 oder HTTP/3, als Warnung, ebenfalls echte Browser-Messung
✓ Unverschlüsselte HTTP-Ressourcen auf einer HTTPS-Seite (Mixed Content), als kritischer Befund
Praxis-Hinweis: Mehr zu Bildformaten und dem gesamten Prüfkatalog des Technik-Moduls im Technik-Audit-Guide, mehr zu Alt-Texten und der ImageObject-Prüfung im Bild-SEO-Guide.
Beispiel

So sieht ein Performance-Befund aus

Ein Beispiel, wie JERVIS einen TTFB-Befund im Report darstellt. Die Werte sind ein realistisches, aber frei gewähltes Beispiel, keine echten Kundendaten.

Warnung

TTFB 2.150ms, auffällig langsam

Fundstelle: /kontakt/

Beschreibung: Die Serverantwortzeit liegt bei 2.150 Millisekunden und damit deutlich über dem für eine flüssige Ladezeit üblichen Bereich.

Empfehlung: Server-Caching prüfen und Hosting optimieren.

Was das für Sie bedeutet: Auf der Kontaktseite zählt jede Sekunde: Wer lange auf die erste Reaktion wartet, bricht den Kontaktversuch eher ab, bevor das Formular überhaupt sichtbar ist.

Warum das zählt

Warum ein guter Labor-Wert nicht automatisch ein guter Feld-Wert ist

TTFB und FCP misst JERVIS bei jedem Scan in einem einzelnen, kontrollierten Browserlauf: ein reproduzierbarer Wert, der sofort nach jeder Änderung wieder abrufbar ist. LCP, INP und CLS bezieht JERVIS dagegen über Googles PageSpeed Insights API. Diese Werte ergänzt JERVIS teils um CrUX-Felddaten aus echten Nutzersitzungen über einen längeren Zeitraum, über verschiedene Geräte, Netzwerke und Verbindungsqualitäten hinweg. Ein guter Wert im kontrollierten Browserlauf sagt deshalb noch nichts darüber aus, wie langsame Verbindungen oder schwächere Geräte die Seite tatsächlich erleben. Erst die Kombination aus der schnellen JERVIS-Eigenmessung bei jedem einzelnen Scan und den Google-Referenzwerten aus echten Nutzerdaten ergibt ein vollständiges Bild.

Umfang

Core Web Vitals im Free Scan vs. Full Audit

TTFB, FCP und die Bild-Checks sind Teil des Technik-Moduls, das im kostenlosen Website-Check enthalten ist.

✓ Free Scan: 5 Module (technisch, Barrierefreiheit, SEO, Text, GEO), bis zu 6 Seiten, TTFB und FCP sowie die Bild-Checks inklusive, ohne die Google-Referenzwerte LCP, INP und CLS
✓ JERVIS Audit: alle Seiten der Website, alle 12 Analyse-Module, zusätzlich die Google-Referenzwerte für LCP, INP und CLS einmal für die Startseite der Domain, nicht je Einzelseite
Umfang der Core-Web-Vitals-Prüfung im Free Scan im Vergleich zum JERVIS Audit Zwei Spalten im Vergleich. Links der Free Scan: 5 Module, bis zu 6 Seiten, TTFB und FCP sowie Bild-Checks inklusive, ohne die Google-Referenzwerte LCP, INP und CLS. Rechts der JERVIS Audit: alle Seiten der Website, alle 12 Analyse-Module, zusätzlich die Google-Referenzwerte für LCP, INP und CLS einmal für die Startseite der Domain. Umfang der Core-Web-Vitals-Prüfung im Vergleich Free Scan 5 Module technisch, Barrierefreiheit, SEO, Text, GEO 6 Seiten bis zu ✓ TTFB & FCP inklusive ✓ Bild-Checks inklusive LCP, INP, CLS: nicht enthalten JERVIS Audit 12 Analyse-Module Alle Seiten der Website statt bis zu 6 Seiten im Free Scan ✓ TTFB & FCP inklusive ✓ Bild-Checks inklusive ✓ LCP, INP, CLS: Startseite, einmal
Free Scan gegen JERVIS Audit: Modul- und Seitenzahl laut Seitentext, die Google-Referenzwerte LCP, INP und CLS laufen ausschließlich im JERVIS Audit.
Mehr als ein Score: JERVIS zeigt konkret, welche Skripte, welche Bilder und welche Server-Antworten ausbremsen. Mehr zum gesamten Technik-Modul im Technik-Audit-Guide, mehr zur mobilen Prüfung, da Google primär mobil misst, im Mobile-Optimierung-Guide. Der volle Funktionsumfang steht im JERVIS Audit.
Häufige Fragen

FAQ zu Core Web Vitals

Misst JERVIS LCP, INP und CLS selbst?
Nein. JERVIS misst mit einem echten Playwright-Browser ausschließlich TTFB und FCP selbst. Die drei Werte LCP, INP und CLS ruft JERVIS über die Google PageSpeed Insights API ab. Optional ergänzt JERVIS sie um CrUX-Felddaten, echte Nutzerdaten von Google. JERVIS zeigt und ordnet diese drei Google-Werte für Ihre Seite ein, erhebt sie aber nicht mit einer eigenen Messmethode.
Was ist der Unterschied zwischen TTFB und FCP?
TTFB (Time to First Byte) misst die Zeit bis zur ersten Antwort des Servers. FCP (First Contentful Paint) misst den Zeitpunkt, an dem der Browser den ersten sichtbaren Inhalt rendert, und liegt damit zeitlich immer nach dem TTFB. JERVIS meldet eine auffällig langsame Serverantwort und einen spät erscheinenden ersten Inhalt jeweils als Hinweis oder Warnung, je nach Ausprägung.
Wie hängen Bildformate mit der Ladezeit zusammen?
Moderne Bildformate wie WebP, AVIF und SVG können die Dateigröße gegenüber JPEG oder PNG spürbar reduzieren. JERVIS meldet fehlende moderne Formate als Hinweis und auffällig große Einzelbilder als Warnung. Zusätzlich prüft JERVIS, ob bei Bildern unterhalb des sichtbaren Bereichs Lazy Loading fehlt.
Ist die Performance-Prüfung im kostenlosen Website-Check enthalten?
Ja, teilweise. TTFB, FCP und die Bild-Checks sind Teil des Technik-Moduls, das im kostenlosen Website-Check enthalten ist. Der Free Scan prüft fünf Module (technisch, Barrierefreiheit, SEO, Text, GEO) auf bis zu sechs Seiten. Die Google-Referenzwerte für LCP, INP und CLS aus der PageSpeed Insights API laufen ausschließlich im JERVIS Audit, einmal für die Startseite der Domain, nicht je Einzelseite. Der JERVIS Audit prüft die Performance zusätzlich über die gesamte Website.
Warum haben LCP, INP und CLS keinen eigenen JERVIS-Score?
Weil JERVIS diese drei Werte nicht selbst misst, sondern von Google übernimmt. Sie folgen deshalb Googles eigener Drei-Zonen-Einteilung in gut, mittel und schlecht, statt in das JERVIS-Schweregrad-System aus kritisch, Warnung und Hinweis einzufließen. Nur TTFB, FCP und die weiteren technischen Checks fließen in den JERVIS-Score ein.
Wie stark zählt Performance im Gesamtscore der Website?
TTFB, FCP und die Bild- und Performance-Checks gehören zum Technik-Modul. Dieses Modul fließt mit spürbarem Gewicht in den Gesamtscore der Website ein, wenn auch geringer gewichtet als SEO-Audit und GEO-Prüfung.
Was bringt mir die Core-Web-Vitals-Prüfung konkret?
Eine langsame Seite kostet doppelt: Besucher springen ab, bevor Inhalte sichtbar sind, und Google berücksichtigt genau diese Geschwindigkeit im mobilen Ranking. JERVIS zeigt mit echten Messwerten und Googles offiziellen Referenzwerten, wo Ihre Website tatsächlich bremst, priorisiert nach dem größten Hebel, statt Sie mit rohen Zahlen allein zu lassen.
Wie verbessere ich den LCP meiner Seite am wirksamsten?
Die wirksamsten Hebel sind ein komprimiertes, wo möglich als AVIF ausgeliefertes Hero-Bild, das Attribut fetchpriority="high" ausschließlich auf dem tatsächlichen LCP-Element, eine kürzere Server-Antwortzeit über Caching und ein CDN sowie kritisches CSS inline im Kopfbereich der Seite.
Wie verhindere ich Layout-Verschiebungen (CLS) durch nachladende Banner oder Fonts?
Setzen Sie width und height oder aspect-ratio auf allen Bildern, reservieren Sie festen Platz für dynamisch nachladende Inhalte wie Banner, und nutzen Sie font-display zusammen mit vorgeladenen Web-Fonts, damit nachladende Schriftarten den Text nicht nachträglich verschieben.

Verwandte Themen: Ladezeit ist nur die halbe Miete: prüfen Sie auch, wie Ihre Site am Smartphone abschneidet, im Guide zur Mobile-Optimierung. Bilder sind meist der größte Hebel für den LCP, mehr dazu im Bild-SEO-Guide. Stand: Juli 2026, Schwellenwerte gemäß den offiziellen Google-Vorgaben (web.dev).

Schnell bleiben, sichtbar werden

Prüfen Sie Ihre Core Web Vitals auf echter Datenbasis. Der JERVIS Audit zeigt, wo Ihre Site bremst und welche Hebel Priorität haben.

Kostenlos testen → Full Audit ansehen
Ladezeit dauerhaft stabil: Autopilot PROTECT →
Kosten vorab klären: Preise für die Performance-Prüfung →