Web-Performance,ohne Raterei.

Core Web Vitals sind die Teilmenge der Performance-Signale, die Google als essenziell für die Nutzererfahrung wertet und ins Ranking einfließen lässt. Jede Metrik erfasst einen anderen Moment: wie schnell der Hauptinhalt erscheint, wie schnell die Seite auf Eingaben reagiert und wie stark das Layout springt.

Als bestanden gilt eine Seite nur, wenn alle drei im 75. Perzentil echter Besuche im grünen Bereich liegen. Labor-Tools können sie schätzen, die offizielle Bewertung nutzt aber immer Felddaten echter Nutzer.

LCP ist das Lade-Core-Web-Vital. Es beantwortet die Frage, die Besucher am meisten interessiert: Wann sieht die Seite fertig aus? Die Uhr startet mit der Navigation und stoppt, sobald das größte Element oberhalb der Falz gezeichnet ist.

Weil das größte Element meist ein Hero-Bild oder eine Überschrift ist, wird LCP davon bestimmt, wie schnell der Server antwortet und wie schnell diese eine Ressource geliefert und dekodiert werden kann.

INP ist das Reaktions-Core-Web-Vital. Es beobachtet jeden Klick, Tap und Tastendruck während eines Besuchs, misst die Verzögerung bis zum nächsten gezeichneten Frame und meldet nahezu den schlechtesten Wert. Ein niedriger INP bedeutet, die Oberfläche fühlt sich sofort an.

INP hat First Input Delay im März 2024 abgelöst. Anders als FID, das nur die Eingabeverzögerung der ersten Interaktion betrachtete, deckt INP die komplette Interaktion inklusive Event-Verarbeitung und Rendering ab und bildet echte Trägheit deutlich besser ab.

CLS ist das Core-Web-Vital für visuelle Stabilität. Jedes Mal, wenn sich ein Element ohne Nutzeraktion verschiebt, bewertet der Browser, wie viel des Viewports sich wie weit bewegt hat. CLS summiert den schlimmsten Schub dieser Verschiebungen während des Besuchs.

Es ist die Metrik hinter dem bekannten Ärger, wenn ein Button im Moment des Antippens wegspringt, weil ein spätes Banner oder Bild lädt. Anders als die zeitbasierten Vitals hat es keine Einheit: kleiner ist besser, und 0 heißt, nichts hat sich bewegt.

FCP markiert den Übergang vom leeren Bildschirm zum ersten sichtbaren Zeichen, dass die Seite lädt. Es ist selbst kein Core Web Vital, aber ein starker Frühindikator und ein häufiges Diagnosemittel für einen langsamen LCP.

Ein schneller FCP signalisiert Besuchern, dass etwas passiert. Ist FCP langsam, liegt die Ursache fast immer davor: Serverzeit, DNS, Weiterleitungen oder render-blockierende Ressourcen.

TTFB erfasst alles, was passiert, bevor das Rendern überhaupt beginnen kann: DNS-Auflösung, Verbindungsaufbau, TLS-Handshake, Weiterleitungen und die Erzeugung der Antwort durch den Server. Es ist das Fundament, auf dem jede andere Lade-Metrik aufsetzt.

Ein hoher TTFB begrenzt, wie schnell FCP und LCP je sein können, weshalb es das Erste ist, was man bei einer langsamen Seite prüft. Server-Logik, Datenbankabfragen und kalte Caches sind die üblichen Verdächtigen.

FID war das ursprüngliche Reaktions-Core-Web-Vital. Es mass nur die Eingabeverzögerung der allerersten Interaktion, und nur diese Verzögerung, nicht die folgende Arbeit oder das Rendering, sodass eine Seite einen guten FID erreichen und sich trotzdem träge anfühlen konnte.

Google hat FID am 12. März 2024 zugunsten von INP abgelöst, das die komplette Interaktion über den gesamten Besuch misst. FID steht hier zur Einordnung: In älteren Reports und Tools kann es noch auftauchen.

TBT ist eine Labor-Metrik und der nächste Labor-Stellvertreter für INP. Es summiert den blockierenden Anteil (alles über 50 ms) jeder langen Task nach dem FCP und zeigt, wie lange eine Seite Eingaben ignorieren würde, während Skripte laufen.

Weil es in einem kontrollierten Labordurchlauf gemessen wird, ist TBT stabil und ideal, um Regressionen in der CI zu fangen, bevor sie echte Nutzer als schlechten INP treffen.

Speed Index nimmt den Lade-Filmstreifen auf und bewertet, wie schnell die Pixel oberhalb der Falz visuell vollständig werden. Zwei Seiten mit gleichem LCP können sehr unterschiedliche Speed-Index-Werte haben, wenn eine sich nach und nach füllt und die andere auf einen Schlag erscheint.

Es ist eine Lighthouse-Labor-Metrik, nützlich um die gefühlte Ladegeschwindigkeit zwischen Builds zu vergleichen, wird aber nicht an echten Nutzern gemessen.

TTI schätzte den Punkt, ab dem der Main-Thread lange genug ruhig war, damit die Seite Interaktionen verlässlich verarbeiten konnte. Es war einst eine zentrale Lighthouse-Kennzahl.

Lighthouse hat TTI in Version 10 (2023) aus der Bewertung entfernt, weil TBT und INP die Reaktionsfähigkeit zuverlässiger beschreiben. Es steht hier zur Einordnung älterer Audits.

Page Load (das window-Load-Event) ist der älteste Performance-Meilenstein. Er ist leicht verständlich und als grobes Signal weiterhin nützlich, sagt aber nichts darüber, wann die Seite nutzbar aussah oder sich so anfühlte, weshalb es die Core Web Vitals gibt.

fastmon erfasst ihn neben den Vitals, sodass die vertraute Zahl bleibt, während die Metriken sichtbar werden, die Erfahrung wirklich abbilden.

In einer Single-Page-Application tauscht ein Klick den Inhalt client-seitig aus, statt ein frisches Dokument zu laden, sodass das klassische Load-Event nie wieder feuert. Route Load misst diese Soft-Navigationen: wie lange ein Ansichtswechsel vom Klick bis zum gezeichneten Inhalt dauert.

Ohne das wirken SPAs künstlich schnell, weil nur der allererste Ladevorgang gemessen wird. fastmon erkennt Soft-Navigationen und misst jeden Route-Wechsel, sodass die Zahlen abbilden, worauf Besucher wirklich warten.

Während eine lange Task läuft, kann der Browser keine Klicks, Scrolls oder Paints verarbeiten, was Besucher genau als Ruckeln wahrnehmen. Long Animation Frames (LoAF) ist die neuere API, die weiter geht und einen langsamen Frame dem verantwortlichen Skript und sogar der Quellzeile zuordnet.

Long Tasks sind das Rohmaterial hinter einem schlechten INP oder TBT. Sie zu finden und aufzubrechen, oder Arbeit vom Main-Thread zu verlagern, ist der direkteste Weg zu einer schnell wirkenden Oberfläche.

Einzelne Metriken sind präzise, aber über viele Seiten hinweg schwer auf einen Blick zu verfolgen. Der Experience Score fasst sie zu einer Zahl zusammen, sodass ein Team die Gesundheit einer Seite, eines Segments oder einer ganzen Site auf einmal sieht und bei einem Einbruch gezielt tiefer geht.

Er ersetzt nie die zugrunde liegenden Vitals: Er zeigt, wo man hinschauen sollte, und die Metrik-Karten sagen, warum.

Wenn eine Seite mit dem Messen fertig ist, packt der Tracker Metriken, Timings und etwaige Fehler in eine kompakte Nutzlast und sendet sie, typischerweise über die Beacon-API, sodass die Zustellung die Seite nicht blockiert oder verlangsamt.

Was ein Beacon genau enthält, lässt sich mit der fastmon Beacon-Inspector-Browsererweiterung prüfen, Teil davon, wie fastmon transparent hält, was es erfasst.

Der Tracker ist das Snippet, das die Messung macht. Er hängt sich in Standard-Browser-APIs ein (Performance-API, PerformanceObserver, Error-Events) und ist auf dieselbe web-vitals-Library abgestimmt, die Google nutzt, sodass die Zahlen mit denen von Chrome vergleichbar sind.

Er ist klein und lädt ohne das Rendering zu blockieren, sodass das Hinzufügen von Monitoring nicht selbst die Performance beschädigt, die du messen willst.

Um eindeutige Besucher zu zählen und die Seiten eines Besuchs zu verbinden, braucht es einen Identifier. Stitch wird am Edge abgeleitet und rotiert im 24-Stunden-Takt, sodass er eine Sitzung gruppieren, aber niemandem über Tage, Sites oder Geräte folgen kann.

So vermeidet fastmon das Doppelzählen und die verwaisten Sitzungen rein cookiefreier Ansätze und setzt trotzdem keine Cookies und baut keine langlebigen Profile.

Eine Session verbindet die Seiten, Timings und Fehler eines einzelnen Besuchs, sodass du einer Journey folgen kannst statt isolierten Treffern. Sie ist die Einheit hinter Metriken wie Seiten pro Session und der Frage, wo in einem Flow Menschen abspringen.

In fastmon ist eine Session durch den kurzlebigen Stitch-Identifier begrenzt, sodass sie einen Besuch abbildet und kein dauerhaftes Profil wird.

Der Pageview ist die atomare Einheit der Analyse. Jeder trägt seine Metriken, Timings und seinen Kontext, und viele zusammen ergeben eine Session und die Traffic-Summen.

fastmon zählt auch Soft-Navigationen in Single-Page-Apps als Pageviews, sodass SPA-Traffic nicht unterzählt wird wie bei Tools, die nur volle Dokument-Ladevorgänge sehen.

Nicht jede Site braucht dieselbe Tiefe. Light beschränkt Daten auf das Nötigste, Standard ist die ausgewogene Voreinstellung, und Full schaltet die reichste Diagnostik frei, etwa detaillierte Attribution und Resource Timing.

Der Modus ist ein bewusster Hebel über den Datenschutz- und Daten-Kompromiss, von dir gewählt statt angenommen, und er bildet direkt ab, was das Gerät eines Besuchers abgefragt wird.

TTFB sagt, dass der Server langsam war, aber nicht warum. Mit dem Server-Timing-Header kann dein Backend seine eigenen Phasen melden (Datenbank, Cache, Rendering), und der Browser reicht sie an den Tracker weiter.

Das verbindet einen langsamen Feld-TTFB mit genau dem verantwortlichen Backend-Schritt und schließt die Lücke zwischen Frontend-Symptom und Backend-Ursache.

Dieselbe URL kann schnell oder langsam sein, je nachdem woher sie ausgeliefert wurde. Den Cache-Status pro Request zu erfassen zeigt die echte Trefferquote und deckt Ressourcen auf, die den Cache immer wieder verfehlen und den Origin treffen.

Das macht aus Caching statt einer hoffnungsvollen Konfiguration etwas, das sich an echtem Traffic verifizieren lässt.