Web performance,without the guesswork.

Core Web Vitals are the subset of web performance signals Google treats as essential for user experience and feeds into ranking. Each one captures a different moment: how fast the main content appears, how quickly the page responds to input, and how much the layout jumps around.

A page is considered to pass only when all three are in the good range at the 75th percentile of real visits. Lab tools can estimate them, but the official assessment always uses field data from real users.

LCP is the loading Core Web Vital. It answers the question a visitor cares about most: when does the page look ready? The clock starts when navigation begins and stops when the biggest above-the-fold element paints.

Because the largest element is usually a hero image or headline, LCP is dominated by how fast the server responds and how quickly that one resource can be delivered and decoded.

INP is the responsiveness Core Web Vital. It observes every click, tap and key press during a visit, measures the delay until the next frame is painted, and reports close to the worst one. A low INP means the interface feels instant.

INP replaced First Input Delay in March 2024. Unlike FID, which only looked at the first interaction's input delay, INP covers the full interaction including event processing and rendering, so it reflects real sluggishness far better.

CLS is the visual stability Core Web Vital. Every time an element shifts without a user action, the browser scores it by how much of the viewport moved and how far. CLS sums the worst burst of those shifts during the visit.

It is the metric behind the familiar frustration of tapping a button that jumps the instant a late banner or image loads. Unlike the time-based vitals it has no unit: lower is better, and 0 means nothing moved.

FCP marks the transition from a blank screen to the first visible sign that the page is loading. It is not a Core Web Vital itself, but it is a strong early indicator and a common diagnostic for a slow LCP.

A fast FCP reassures visitors that something is happening. If FCP is slow, the cause is almost always upstream: server time, DNS, redirects or render-blocking resources.

TTFB captures everything that happens before rendering can even begin: DNS lookup, connection setup, TLS handshake, redirects, and the server producing the response. It is the foundation every other loading metric sits on.

A high TTFB caps how fast FCP and LCP can ever be, which is why it is the first thing to check when a page feels slow. Server logic, database queries and cold caches are the usual culprits.

FID was the original responsiveness Core Web Vital. It only measured the input delay of the very first interaction, and only that delay, not the work or rendering that followed, so a page could score a good FID yet still feel sluggish.

Google retired FID on 12 March 2024 in favour of INP, which measures the full interaction across the whole visit. FID is included here for context: you may still see it in older reports and tools.

TBT is a lab metric and the closest lab proxy for INP. It sums the blocking portion (everything over 50 ms) of every long task after FCP, showing how much a page would ignore input while scripts run.

Because it is measured in a controlled lab run, TBT is stable and great for catching regressions in CI before they reach real users as a poor INP.

Speed Index records the loading filmstrip and scores how fast pixels above the fold become visually complete. Two pages with the same LCP can have very different Speed Index if one fills in gradually and the other pops in all at once.

It is a Lighthouse lab metric, useful for comparing perceived loading speed between builds, but it is not measured on real users.

TTI estimated the point at which the main thread had been quiet long enough for the page to handle interactions dependably. It was once a headline Lighthouse score.

Lighthouse dropped TTI from its scoring in version 10 (2023) because TBT and INP describe responsiveness more reliably. It appears here for context with older audits.

Page Load (the window load event) is the oldest performance milestone. It is easy to understand and still useful as a coarse signal, but it says nothing about when the page looked or felt usable, which is why the Core Web Vitals exist.

fastmon records it alongside the vitals so you keep the familiar number while seeing the metrics that actually track experience.

In a single-page application, clicking a link swaps content client-side instead of loading a fresh document, so the classic load event never fires again. Route Load measures those soft navigations: how long a view change takes from click to painted content.

Without it, SPAs look artificially fast because only the very first load is measured. fastmon detects soft navigations and times each route change so the numbers reflect what visitors actually wait for.

While a long task runs, the browser cannot handle clicks, scrolls or paints, which is exactly what a visitor perceives as jank. Long Animation Frames (LoAF) is the newer API that goes further, attributing a slow frame to the script and even the source line responsible.

Long tasks are the raw material behind a poor INP or TBT. Finding and breaking them up, or moving work off the main thread, is the most direct way to make an interface feel fast.

Individual metrics are precise but hard to track at a glance across many pages. The Experience Score rolls them into one figure so a team can see the health of a page, a segment or a whole site at once, then drill down when it drops.

It never replaces the underlying vitals: it points you at where to look, and the metric cards tell you why.

When a page finishes measuring, the tracker packs the metrics, timings and any errors into a compact payload and sends it, typically via the Beacon API, so delivery does not block or slow the page.

You can inspect exactly what a beacon contains with the fastmon Beacon Inspector browser extension, which is part of how fastmon keeps what it collects transparent.

The tracker is the snippet that does the measuring. It hooks into standard browser APIs (the Performance API, PerformanceObserver, error events) and is aligned with the same web-vitals library Google uses, so the numbers are comparable to Chrome's.

It is small and loads without blocking rendering, so adding monitoring does not itself hurt the performance you are trying to measure.

To count unique visitors and connect the pages of one visit, some identifier is needed. Stitch is derived at the edge and rotates on a 24-hour basis, so it can group a session but cannot follow anyone across days, sites or devices.

It is how fastmon avoids the double-counting and orphaned sessions of pure cookieless approaches while still setting no cookies and building no long-lived profiles.

A session ties together the pages, timings and errors of a single visit so you can follow a journey rather than isolated hits. It is the unit behind metrics like pages per session and where in a flow people drop off.

In fastmon a session is bounded by the short-lived Stitch identifier, so it reflects one visit and does not become a permanent profile.

The pageview is the atomic unit of analytics. Each one carries its metrics, timings and context, and many together make up a session and the traffic totals.

fastmon counts soft navigations in single-page apps as pageviews too, so SPA traffic is not undercounted the way it is with tools that only see full document loads.

Not every site needs the same depth. Light keeps data to the essentials, Standard is the balanced default, and Full unlocks the richest diagnostics like detailed attribution and resource timing.

The mode is a deliberate lever over the privacy and data trade-off, chosen by you rather than assumed, and it maps directly to what a visitor's device is asked for.

TTFB tells you the server was slow, but not why. With the Server-Timing header your backend can report its own phases (database, cache, rendering) and the browser exposes them to the tracker.

That connects a slow field TTFB to the exact backend step responsible, closing the gap between frontend symptom and backend cause.

The same URL can be fast or slow depending on where it was served from. Recording cache status per request shows your real hit rate and surfaces resources that keep missing the cache and hitting the origin.

It turns caching from a hopeful configuration into something you can actually verify against real traffic.