Talaria

In the request · 3 min read · Updated 2026-08-14

Web Vitals from real users

LCP, INP, and CLS are how Chrome defines a usable page. Talaria records them from the browser SDK as spans on real sessions — not a lab crawl.

Server p95 can be healthy while the page feels broken. Images shift, the largest paint arrives late, or the main thread ignores a click. Core Web Vitals exist because lab scores and origin timers do not describe that experience.

The problem

A synthetic Lighthouse run on a warm cache in a London office is not your customer on a mid-range phone. Real-user monitoring (RUM) measures the session that actually happened. Without it, frontend regressions hide behind a green PHP waterfall.

What it is

Chrome’s Core Web Vitals are three field metrics with published good / needs-improvement / poor thresholds:

  • LCP (Largest Contentful Paint) — when the main content appears. Good is 2.5s or less.
  • INP (Interaction to Next Paint) — how quickly the page responds to clicks, taps, and keys. Good is 200ms or less. INP replaced FID as a Core Vital.
  • CLS (Cumulative Layout Shift) — visual stability. Good is 0.1 or less.

Percentiles matter more than averages. p75 is the conventional reporting line for field vitals (Search Console and CrUX). p95 shows how bad the tail is on slower devices.

Web Vitals

storefront

production

LCP

p75

2.1s

p50 1.4s · p95 3.6s

INP

p75

140ms

p50 80ms · p95 280ms

CLS

p75

0.08

p50 0.02 · p95 0.18

LCP, INP, and CLS at p50 / p75 / p95 from browser spans. These are the three Core Web Vitals the SDK emits.

What it gives a team

  • A frontend health check that does not require guessing from server duration.
  • A way to see whether a CSS or hero-image change moved CLS or LCP after a release.
  • Correlation in spirit with session replay: vitals tell you the page felt wrong; replay shows what the user saw.

How Talaria does it

The JavaScript browser SDK installs a PerformanceObserver-based integration and emits spans named webvital.lcp, webvital.inp, and webvital.cls when tracing is on. The dashboard Web Vitals page reads percentiles from those spans. PHP, Dart, and Flutter have no Web Vitals — they are a browser-only signal.

How to read it

  • Watch p75 against Chrome’s good thresholds before chasing p95.
  • LCP regressions: hero media, fonts, or a slow origin TTFB you will see on the server waterfall — vitals will not name the PHP query.
  • INP regressions: long tasks, expensive click handlers, hydration.
  • CLS regressions: images without dimensions, injected banners, web fonts swapping late.

Turn it on

Use @newtalaria/browser with enableTracing or tracesSampleRate > 0. Load a real page in a real browser. Headless crawls that never paint will not produce LCP.

What this is not

This is not a full RUM product: no funnels, no session search by vital, no CrUX crawl of the public web. It is not Lighthouse CI. Flutter has its own frame timings; they are not Core Web Vitals and are not this page.

Related guides

  • Signals · 3 min

    What SDK-native APM actually is

    Application performance from inside your process — transactions, RED, and release health — without a host agent or an observability maze.

  • In the request · 3 min

    Distributed tracing with W3C Trace Context

    One trace ID from the browser, through PHP, into the query that failed — carried on a standard header named traceparent.

  • Triage loop · 3 min

    From error to trace to replay

    Performance without grouping is a chart. Grouping without traces is a stack. Replay without either is a video. Talaria joins all three on one issue.

Turn tracing on

Opt into enableTracing on an official SDK, then inspect transactions next to the issues they belong to.