LCP, INP, and CLS
from real users.

Lab data (from Lighthouse or synthetic audits) is measured in a controlled environment on a simulated device and connection. Field data is collected from real users on their actual devices and connections. Google's Page Experience ranking signal uses field data, not lab data, which is why tracking real-user vitals matters for SEO.

Google's Core Web Vitals assessment determines a URL's status ("Good," "Needs Improvement," or "Poor") based on the 75th percentile. If your p75 LCP is under 2.5 seconds, 75% of your users see a "Good" load. Tracking p75 aligns your monitoring to what actually affects your ranking.

Add the module script tag to your page's and call SiteQwalityRUM.init({ applicationId, clientToken }). The bundle is 5.7 kB gzipped over the wire and loads as a deferred ES module, so it never blocks rendering. Vitals are measured with the web-vitals library on top of the browser's native PerformanceObserver API. No framework required, and there is an npm package if you would rather import it.

Per page. The snippet captures the current URL for every event so you can view LCP, INP and CLS for the homepage, product pages, checkout, and any other route separately.

Yes. Device type (desktop, mobile, tablet), browser and operating system are derived from the request User-Agent on every event, and you can also filter by URL. Combine them to understand, for example, why mobile LCP is higher than desktop. Segmenting by connection type is not available: the script does not read the Network Information API.

Neither, today. There is no vitals alert rule, no p75 threshold to configure and nothing that fires when field data crosses one. There are also no deployment markers: nothing records a release against the timeline, and there is no before-and-after comparison for a specific deploy. An earlier version of this page advertised both, which was wrong. Alerting today covers uptime, cron, TLS, DNS and browser checks, not Core Web Vitals.

Aggregate measurements are kept for 458 days, a little over 15 months, on every plan including the free tier. Paying more does not extend it and downgrading does not shorten it, so it is the same window for everybody by default. You can ask for less: a retention ceiling is set per RUM application through the API (settings.retention.observe_days on PUT /rum/{app_id}), the floor is one day, and lowering it also applies to measurements already stored for that application rather than only to new ones. There is no control for this in the dashboard yet, so today it is an API call. The overview's time-range selector offers up to 30 days, so reading further back means querying the API directly.