Real users, real speed.
Lab scores lie. LogClip measures Core Web Vitals and API latency from the browsers of real visitors — so you optimize the experience people actually get, not a synthetic one.
Speed as your visitors actually got it.
4 stops, each one a real screen from the console.
Six numbers, and the share of people who had a good time
Every vital at p75 — what a typical visitor actually felt, not a lab average on a fast laptop. Beneath them the health scores, which open the audit behind them rather than asking you to trust a number on its own.
Every request your visitors made, timed from their side
Each counter carries its move against the previous fortnight, which is the part worth reading — traffic falling while the error rate climbs is a different story from either number alone. These timings come from the browser, so they include the round trip the visitor really had.
One row per route, and the worst request is one click away
Routes are id-templated, so every product page is one line rather than ten thousand. Watch opens the session containing the slowest instance of a request, already seeked to it — which turns a row in a table into the visit it happened to.
Sorted by requests, with the one failing endpoint carrying the only red slice on the page.
Where the slow ones are
The same data as a map: bubbles sized by requests, coloured by p95, with a table per country under it. Distant markets read slower because the round trip is longer — the page says so rather than letting you mistake geography for a regression.
Everything under web vitals
Core Web Vitals and API performance measured from real visitors — every endpoint, every page, on one timeline.
Six vitals at p75
TTFB, FCP, CLS, INP, LCP and navigation timing, each at the 75th percentile real visitors felt, with the share of visits in the good band.
Health scores
Performance, accessibility and AI visibility as 0–100 scores on the overview, with a link through to the full audit.
Every API call, timed in the browser
The tracker times each first-party request from the visitor's side, so the numbers include the network the visitor actually had.
Per-endpoint p50 / p95 / p99
Routes are id-templated, so /products/123 and /products/456 are one row — with status mix and error rate beside them.
Watch the slowest instance
Every endpoint row has a Watch link that opens the session containing the worst request of that shape, at that request.
Fourteen days per endpoint
Expand a row for its own latency and traffic trend — a regression on one route shows up even when the overall p95 is flat.
By region
A world map of request volume coloured by p95, then a table per country. Far regions read slower; now you see by how much.
Third parties excluded
Analytics, CDNs and ad pixels are kept out of the endpoint list so your API is judged on its own.
Vitals as signals
A poor vital comes back as a suggested signal, so the visits that felt it are tracked, filtered and replayed like any other pattern.
Why it matters.
Field, not lab
LCP, INP, CLS, TTFB and FCP measured at the p75 your real users feel, with the share of 'good' experiences.
API performance in context
Response times, error rates and traffic across every endpoint your visitors hit — tied to the sessions that hit them.
Speed meets behavior
A slow load isn't an abstract metric here — it's linked to the rage clicks and the abandonment it caused.
Minutes, not quarters.
Measured from real sessions
Vitals and request timings arrive with the recording. Nothing to configure, nothing synthetic.
Find what is slow for whom
Sort endpoints by p95 or errors; switch to the region view to see where the slow ones are.
Watch it, then fix it
Open the slowest instance as a replay, ship the fix, and watch the p75 and good share recover.