Measuring What Matters: Essential Metrics for User-Centric Performance (Measuring What Matters Essential Metrics For User Centric Performance)

Measuring What Matters: Essential Metrics for User-Centric Performance

User-centric performance measurement focuses on whether people can achieve their goals quickly, easily, reliably, and satisfactorily—not merely whether a system generates traffic or loads technically. The strongest measurement systems combine behavioral data, user perceptions, business outcomes, and technical performance.

User behavior metrics

These show what users actually do:

• Task completion rate: Percentage of users who successfully complete a defined task.
• Time on task: How long users need to achieve their goal.
• Error rate: Frequency of failed actions, validation errors, or system errors.
• Error recovery rate: Percentage of users who recover from an error and finish the task.
• Feature adoption: Percentage of eligible users who use a feature during a defined period.
• Funnel abandonment: Where users drop out of a multi-step process.
• Time to value: Time between sign-up or entry and the user’s first meaningful outcome.

Behavioral metrics are most useful when tied to a specific user goal—for example, “complete checkout” rather than simply “increase clicks.” GitLab’s UX framework identifies task completion, time on task, errors, first-click accuracy, and feature adoption as core behavioral measures. handbook.gitlab

User perception metrics

Analytics reveal what happened; attitudinal metrics help explain why:

• Customer Satisfaction Score (CSAT): How satisfied users are with an experience.
• Perceived ease of use: How easy users feel the product is to use.
• Customer Effort Score (CES): How much effort users believe they needed to expend.
• Perceived efficiency: Whether users feel the product saves time.
• Net Promoter Score (NPS): Likelihood that users would recommend the product.
• Perceived usefulness: Whether the product solves a meaningful problem.

A product can have high task completion but still feel frustrating or unnecessarily difficult. That is why behavioral and attitudinal measures should be assessed together. handbook.gitlab

Retention and value metrics

These indicate whether the product delivers continuing value:

• Activation rate: Percentage of new users who complete the first meaningful action.
• Retention rate: Percentage of users who return and remain active after a defined period.
• Churn rate: Percentage of users who stop using the product.
• DAU/WAU/MAU: Daily, weekly, and monthly active users.
• Stickiness: Often approximated as DAU / MAU.
• Cohort retention: Retention tracked separately for groups based on sign-up date or another shared characteristic.
• Referral rate: How often users recommend or invite others.

A useful structure is to define one North Star Metric representing delivered user value, then identify two or three input metrics that teams can influence. For example, a collaboration product might use “weekly successful collaborations” as its North Star, with activation, feature adoption, and retention as supporting metrics. youtube

Technical performance metrics

For digital products, technical speed should be measured from the user’s perspective:

User experience	Useful metrics
Initial visibility	First Contentful Paint (FCP), Largest Contentful Paint (LCP)
Responsiveness	Interaction to Next Paint (INP), Total Blocking Time (TBT)
Stability	Cumulative Layout Shift (CLS)
Server responsiveness	Time to First Byte (TTFB)
Smoothness	Frame consistency and animation responsiveness
Reliability	Crashes, failed requests, downtime, and error rates

Web performance should be measured both in controlled lab tests and through real-user monitoring, since devices, networks, personalization, and user interactions can significantly change the experience. web.dev

A practical measurement set

Most teams can begin with five metrics:

1. One value metric: The primary outcome users come to achieve.
2. One behavioral metric: Task completion rate or time on task.
3. One perception metric: CSAT, CES, or perceived ease of use.
4. One retention metric: Cohort retention or repeat usage.
5. One reliability or performance metric: Error rate, INP, LCP, or uptime.

Good metrics should be clear, normalized, comparable over time, segmented by relevant user groups, and actionable. Avoid relying on total page views, downloads, registered users, or session length alone; these can grow without demonstrating that users are receiving meaningful value. youtube

Example

For an online expense-reimbursement service:

• North Star: Successfully reimbursed claims per active employee.
• Behavior: Claim-completion rate and median time to submit.
• Perception: Post-submission ease-of-use score.
• Retention: Percentage of employees submitting another claim within 90 days.
• Technical: Error rate and INP during receipt upload.
• Diagnostic: Drop-off rate at receipt verification.

This combination shows not only how many people enter the process, but whether they can complete it, how the experience feels, whether they return, and whether technical problems prevent success.

Concepts used throughout this chapter

📦 Lab vs field
Controlled, repeatable diagnostics versus real-user measurement under authentic devices, networks, and contexts.

📦 Core Web Vitals (CWV)
LCP, INP, and CLS—loading, responsiveness, and visual stability, assessed at the 75th percentile of real users.

📦 FID (retired)
First Input Delay measured only the first interaction’s input delay; INP replaced it as a Core Web Vital in 2024.

📦 RUM
Real User Monitoring: first-party telemetry of what users actually experience in production.

📦 CrUX
Chrome User Experience Report—public field data from eligible Chrome users, used by tools such as PageSpeed Insights and Search Console.

📦 Performance budget
Enforceable limits for user metrics and causes (weight, third parties, errors) that gate releases and prevent regression.

📦 Attribution
Debugging context attached to vitals—such as the LCP element or INP interaction target—so teams fix causes, not averages.

These concepts matter because this chapter turns measurement into a decision system: lab explains capability, field verifies reality, Core Web Vitals quantify loading/responsiveness/stability, and budgets keep improvements from silently eroding.

Lab Testing and Field Measurements

In user-centric performance, lab testing measures a product under controlled, repeatable conditions, while field measurement observes performance in users’ real environments. Lab results are generally better for identifying the cause of a problem; field results are better for understanding whether the product works in everyday use. MIT

Lab testing

Lab testing places users, tasks, devices, and conditions under a defined protocol.

Typical measures include:

• Task-completion rate.
• Time on task.
• Error frequency and recovery.
• Navigation or click paths.
• First-click accuracy.
• Perceived usability and workload.
• Satisfaction after completing a task.
• Comparison between design versions.

Strengths

• High control and repeatability.
• Easier comparison of competing designs.
• Better isolation of specific interface problems.
• More efficient observation and recording.
• Useful for prototypes and controlled A/B-style experiments.

Limitations

• Participants may behave differently because they know they are being observed.
• Artificial tasks may not reflect real priorities or interruptions.
• A quiet test room cannot reproduce every workplace, social, environmental, or technical condition.
• Results may overestimate usability if the real context is more demanding.

Research comparing lab and field usability testing found no universal winner: the methods can produce similar results in favorable conditions, but differences emerge when users face difficult conditions, poor usability, or competing tasks. PubMed

Field measurements

Field measurement takes place where users normally work, travel, shop, communicate, or operate the product. It may involve direct observation, contextual interviews, diary studies, remote telemetry, or in-the-wild usability testing.

Useful field measures include:

• Real-world task success.
• Actual completion time.
• Interruptions and task switching.
• Environmental or network conditions.
• Device and platform differences.
• Frequency and severity of errors.
• Workarounds and manual steps.
• Repeat usage and retention.
• Reliability, latency, crashes, and failed requests.
• User comments about usefulness and fit with their workflow.

Strengths

• Captures authentic behavior and context.
• Reveals problems caused by distractions, infrastructure, policies, or surrounding tools.
• Shows whether users can integrate the product into real routines.
• Helps explain unexpected analytics or support trends.
• Particularly valuable for mobile, workplace, industrial, healthcare, and location-dependent products.

Limitations

• Less control over variables.
• More difficult to compare participants directly.
• Data may be noisier and harder to interpret.
• Testing can take longer and cost more.
• Privacy, consent, and data-security requirements are more significant.

Field studies are strongest for realism, whereas lab experiments are strongest for precision and control. MIT

What to measure

Question	Lab measures	Field measures
Can users complete the task?	Completion rate under a defined scenario	Completion rate during real work
How efficiently do they work?	Time on task, clicks, keystrokes	Time including interruptions, switching, and workarounds
What goes wrong?	Observed errors and failed interactions	Production errors, support requests, abandoned tasks
How does it feel?	Satisfaction, workload, perceived usability	Long-term satisfaction, trust, frustration, perceived value
Does it perform reliably?	Controlled response time and device tests	Real latency, connectivity variation, crashes, and failures
Does it deliver value?	Immediate task outcome	Repeat use, retention, adoption, and business or user outcomes

Recommended approach

Use the two methods as a cycle rather than choosing only one:

1. Start in the lab to identify obvious usability problems and compare design alternatives.
2. Measure in the field to test behavior under authentic conditions.
3. Return to the lab to investigate the causes of important field problems.
4. Validate changes in production using analytics, feedback, and performance monitoring.
5. Segment results by device, user experience, accessibility needs, location, connectivity, and task type.

For example, a mobile expense app may achieve a 95% submission rate in a lab. Field measurement might reveal that users abandon submissions when photographing receipts in poor lighting or on weak mobile networks. The lab identifies the interface problem; the field exposes the environmental and technical conditions that make it important.

The key principle is: lab testing explains capability; field measurement verifies real-world performance. A credible user-centric assessment normally needs both.

Core Web Vitals: Key Metrics

Core Web Vitals (CWV) are Google’s user-centered metrics for evaluating three parts of a webpage experience: loading, responsiveness, and visual stability. The current set includes LCP, INP, and CLS. web.dev

Metric	Measures	Good target
Largest Contentful Paint (LCP)	How quickly the main visible content—such as a hero image, heading, or large text block—appears	≤ 2.5 seconds
Interaction to Next Paint (INP)	How quickly the page responds visually to clicks, taps, and keyboard interactions throughout the visit	≤ 200 milliseconds
Cumulative Layout Shift (CLS)	How much visible content moves unexpectedly while the page loads or is used	≤ 0.1

What each metric tells you

• LCP — loading: “Can users see the important content quickly?”
• INP — responsiveness: “Does the interface respond promptly when users interact?”
• CLS — stability: “Can users read and click without the page unexpectedly moving?”

INP replaced First Input Delay (FID) as a Core Web Vital in 2024. Unlike FID, which measured only the first interaction, INP evaluates interaction responsiveness across the user’s visit. Dynatrace

How CWVs are assessed

Measure real-user data at the 75th percentile, separately for mobile and desktop. A page generally needs to meet the “good” threshold for all three metrics to receive an overall good CWV assessment. web.dev

Lab tools such as Lighthouse and Chrome DevTools are useful for diagnosing problems, while field data from real users reveals actual performance across devices, networks, and locations. PageSpeed Insights, Chrome User Experience Report data, and Search Console can help monitor these results. web.dev

Typical improvement actions

• Improve LCP: Optimize images, reduce render-blocking resources, improve server response time, and prioritize above-the-fold content.
• Improve INP: Reduce long JavaScript tasks, limit main-thread work, and make event handlers faster.
• Improve CLS: Reserve space for images and advertisements, avoid inserting content above existing content, and stabilize fonts and layout dimensions.

CWVs are valuable technical indicators, but they should be combined with user-centered outcomes such as task completion, abandonment, satisfaction, and conversion. A fast page is not necessarily a useful or successful page.

Largest Contentful Paint (LCP)

LCP measures how quickly the main visible content appears after a user opens a page. It records when the largest image, video frame, or text block within the viewport finishes rendering, making it a strong indicator of perceived loading speed. web.dev

What counts as LCP?

The LCP element is often:

• A hero or banner image.
• A prominent heading or text block.
• A product image.
• A video poster or first visible video frame.
• A large image loaded through CSS.

LCP is different from First Contentful Paint (FCP): FCP measures when any content first appears, while LCP estimates when the page’s primary content becomes visible. web.dev

LCP thresholds

LCP result	Experience
2.5 seconds or less	Good
More than 2.5 to 4 seconds	Needs improvement
More than 4 seconds	Poor

Evaluate the 75th percentile of page loads, segmented at least by mobile and desktop, so the result represents most users rather than only the average experience. web.dev

What causes a slow LCP?

LCP usually consists of four delays:

1. Server response delay: The browser waits for the initial HTML response.
2. Load delay: The browser discovers or begins requesting the LCP resource late.
3. Resource load time: The image, video, font, or other content takes too long to download.
4. Render delay: The resource is ready, but JavaScript, CSS, or other work delays its display. Chrome Developers

How to improve LCP

• Improve server response time and use effective caching or a content delivery network.
• Optimize and properly size the LCP image.
• Use modern image formats and appropriate compression.
• Preload only the critical LCP resource when discovery is delayed.
• Avoid lazy-loading the above-the-fold LCP image.
• Remove render-blocking CSS and unnecessary JavaScript.
• Reduce long main-thread tasks.
• Ensure important text is displayed promptly while web fonts load.
• Avoid excessive redirects and chains of critical requests.

Use lab tools such as Lighthouse to diagnose the cause, then confirm the improvement with real-user field data. A page may perform well in a controlled test but still have poor LCP for users on slower devices or networks.

FID, INP, and CLS

These metrics cover two different parts of the experience: responsiveness—how quickly the page reacts to input—and visual stability—whether content stays where users expect it.

First Input Delay (FID)

FID measured the delay between a user’s first interaction and the browser beginning to process it. It captured only the initial input delay, such as the time between tapping a button and the browser starting its event handler.

FID was useful for detecting pages blocked by JavaScript during startup, but it did not measure the full interaction or later interactions. FID has now been retired as a Core Web Vital and replaced by INP. Chrome Developers

Interaction to Next Paint (INP)

INP measures how quickly the page responds visually to user interactions throughout the visit. It includes the input delay, event-handler processing, rendering work, and the time until the next screen update appears. web.dev

Examples include:

• Clicking a navigation menu.
• Typing into a search field.
• Tapping an add-to-cart button.
• Opening a dialog or dropdown.
• Selecting a filter or tab.

INP score	Responsiveness
≤ 200 ms	Good
> 200 to 500 ms	Needs improvement
> 500 ms	Poor

A good INP is assessed at the 75th percentile of real page visits, usually separated into mobile and desktop data. web.dev

Improving INP

• Break up long JavaScript tasks.
• Reduce unnecessary JavaScript and third-party scripts.
• Keep event handlers small and efficient.
• Defer nonessential work until after the interaction.
• Avoid excessive DOM updates.
• Use efficient rendering and animation techniques.
• Reduce main-thread blocking during page load.

Cumulative Layout Shift (CLS)

CLS measures unexpected movement of visible content. A high CLS score means that buttons, text, images, or other elements shift after appearing, potentially causing users to lose their place or click the wrong control. web.dev

Common causes include:

• Images or videos without reserved dimensions.
• Ads or banners inserted above existing content.
• Late-loading fonts changing text dimensions.
• Dynamically injected notifications.
• JavaScript changing layout after the page is visible.

CLS score	Visual stability
≤ 0.1	Good
> 0.1 to 0.25	Needs improvement
> 0.25	Poor

CLS is a unitless score, not a time measurement. It considers both how much of the viewport is affected and how far the affected content moves. New Relic

Improving CLS

• Set explicit width and height attributes on images and videos.
• Reserve space for ads, embeds, and dynamic content.
• Avoid inserting content above already visible content.
• Preload or stabilize important fonts.
• Prefer transform and opacity for animations instead of changing layout properties.
• Use placeholders with the same dimensions as the final content.

The practical distinction

• FID: Did the browser begin responding to the first interaction quickly?
• INP: Does the page respond quickly to interactions throughout the visit?
• CLS: Does the page remain visually stable while users read and interact?

In current Core Web Vitals reporting, focus on INP and CLS; FID is mainly relevant when interpreting older reports or historical performance data.

Beyond the Core Web Vitals

LCP, INP, and CLS are essential, but they do not explain every performance problem. Supporting metrics help diagnose causes, while product and business metrics show whether technical improvements actually benefit users.

Supporting metrics

Metric	What it helps explain
First Contentful Paint (FCP)	When users first see any page content
Time to First Byte (TTFB)	Server, network, and backend response delay
Total Blocking Time (TBT)	Main-thread blocking during lab tests
Speed Index	How quickly visible content appears progressively
Resource weight	JavaScript, CSS, image, font, and third-party payload size
Long tasks	JavaScript work that blocks the main thread
Error and failure rate	Whether requests, scripts, or key workflows fail
Conversion, abandonment, and task success	Whether performance affects user outcomes

FCP and TTFB are particularly useful when diagnosing LCP: TTFB can reveal server delay, while FCP can reveal render-blocking or early-rendering problems. TBT is mainly a lab diagnostic, not a replacement for field INP. web.dev

Interpreting and acting on reports

When interpreting reports:

1. Start with field data and identify the affected page, device, geography, browser, and user segment.
2. Check the 75th percentile rather than relying on averages.
3. Separate “what users experienced” from “what caused it.”
4. Use lab tools to reproduce and isolate the cause.
5. Prioritize issues affecting important journeys, not just pages with the lowest score.
6. Form a hypothesis, make one targeted change, and re-measure.
7. Confirm that the change improves both performance and a user outcome such as completion or conversion.

Avoid treating a Lighthouse score as the objective. The goal is not “100”; the goal is faster, more responsive, more stable experiences for real users.

Lab tools

Lighthouse: performance auditing

Lighthouse provides automated audits for performance, accessibility, SEO, best practices, and progressive web app features. Its performance report includes metrics, diagnostic audits, opportunities, and links to recommended improvements. Chrome Developers

Use Lighthouse for:

• Pull-request or build checks.
• Repeatable baseline comparisons.
• Detecting render-blocking resources.
• Finding oversized images and unused JavaScript.
• Investigating LCP, CLS, FCP, TBT, and related lab metrics.
• Testing pages that have little or no field traffic.

Run it with consistent conditions—same URL, device emulation, network profile, authentication state, and test repetitions. Treat individual runs as noisy; compare medians or trends. In CI, use numberOfRuns (for example 3 or 5) and assert budgets so regressions fail the build rather than arrive as surprises.

Chrome DevTools Performance panel

The Performance panel records a browser trace containing network activity, CPU work, JavaScript execution, rendering, layout, paint, and user interactions. It is the tool to use when Lighthouse identifies a symptom but you need to locate the exact blocking activity. Chrome Developers

A practical workflow is:

• Record the page load or a slow interaction.
• Inspect the Insights view for LCP phases, render-blocking requests, layout-shift culprits, and long tasks.
• Use the main timeline and flame chart to identify the responsible script, style recalculation, layout, or paint.
• Correlate the trace with the Network panel and the affected DOM element.
• Record again after the fix.

Chrome DevTools also offers AI assistance for recorded performance profiles. It can explain selected insights or trace activities and suggest possible improvements; use it as an analysis aid, then verify every suggestion against the trace and your code. Chrome Developers

WebPageTest: realistic testing and advanced analysis

WebPageTest is useful for realistic, advanced testing across locations, browsers, devices, connection profiles, and repeated runs. Its filmstrip shows what users see over time, while the waterfall shows request dependencies, timing, priorities, and resource delays. Shopify Performance

Use it when you need to investigate:

• Slow performance from a particular country or region.
• Mobile-device and slow-network behavior.
• First view versus repeat view.
• CDN, DNS, TLS, server, and connection timing.
• Image discovery and request prioritization.
• Third-party scripts and waterfall bottlenecks.
• Visual progress rather than only a final score.

Field tools

Capturing Core Web Vitals with web-vitals.js

The web-vitals library measures Core Web Vitals in the browser and sends results to your analytics or observability system. A minimal implementation is:

<script type="module">
  import {onCLS, onINP, onLCP}
    from 'https://unpkg.com/web-vitals@4?module';

  function sendToAnalytics(metric) {
    navigator.sendBeacon('/rum', JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      path: location.pathname
    }));
  }

  onCLS(sendToAnalytics);
  onINP(sendToAnalytics);
  onLCP(sendToAnalytics);
</script>

The official library also provides an attribution build, which can include information such as the LCP element or resource and useful debugging context. Google Developers

In production, add privacy-safe dimensions such as:

• Page template and route.
• Device class and connection type.
• Browser and operating system.
• Country or region.
• Release version.
• Logged-in versus anonymous state.
• Experiment or feature flag.

Do not send URLs, user identifiers, form contents, or other personal data unless your privacy design explicitly permits it.

CrUX and external data

The Chrome User Experience Report (CrUX) represents the experience of eligible real Chrome users on popular websites. It provides field data for LCP, INP, CLS, and other dimensions through tools such as PageSpeed Insights, Search Console, the CrUX API, and BigQuery. Chrome Developers

CrUX is valuable for:

• Benchmarking against the public web.
• Checking whether performance problems affect real users.
• Validating whether a release changed field performance.
• Comparing mobile and desktop experiences.
• Reviewing historical trends.

CrUX has coverage and eligibility limits, so it may not represent every user or every page. Use it alongside first-party RUM, which can include your complete audience and product-specific dimensions.

RUM beyond Web Vitals

Real User Monitoring should also capture:

• Route-change or SPA navigation timing.
• API latency and failed requests.
• JavaScript errors and promise rejections.
• Long tasks and long animation frames.
• Interaction latency by feature.
• Search, checkout, login, or upload completion.
• Rage clicks, retries, and abandonment.
• Crashes, offline states, and connectivity changes.
• Accessibility-related failures where measurable.

The useful question is not simply “Is INP poor?” but “Which interaction, for which users, on which release, is slow—and does that prevent task completion?”

Budgets, alerts, and continuous monitoring

Performance budgets convert quality goals into enforceable limits. Define budgets for both user metrics and causes:

• LCP: 75th percentile ≤ 2.5 seconds.
• INP: 75th percentile ≤ 200 milliseconds.
• CLS: 75th percentile ≤ 0.1.
• JavaScript transfer: agreed maximum by route.
• Total page weight: agreed maximum by device class.
• Third-party requests: approved list and maximum cost.
• Error rate: maximum acceptable percentage.
• Key workflow success: minimum completion rate.

Use three alert levels:

• Warning: the metric is approaching its limit.
• Regression: the metric has worsened beyond an agreed percentage.
• Critical: a Core Web Vital or important workflow has crossed a failure threshold.

Lighthouse CI can enforce lab budgets on every pull request. A representative lighthouserc.json asserts score and metric gates:

{
  "ci": {
    "collect": {
      "url": ["http://localhost:3000/", "http://localhost:3000/blog"],
      "numberOfRuns": 3,
      "settings": { "preset": "desktop" }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "uses-responsive-images": "off"
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

In this pattern, error fails the build when a budget is missed; warn logs without blocking. Metric-based maxNumericValue budgets are usually more reliable than score-only gates because they avoid log-normal score noise. Pair CI assertions with production RUM alerts on p75 LCP, INP, and CLS so regressions are visible before CrUX’s longer rolling window catches up.

Continuous-monitoring example

A practical system might work as follows:

1. Lighthouse runs on every release for a representative set of pages.
2. WebPageTest runs nightly from several locations and connection profiles.
3. web-vitals.js sends anonymized LCP, INP, and CLS data from production.
4. A dashboard segments results by release, route, device, and geography.
5. An alert fires when mobile INP worsens by 15% for two consecutive periods.
6. The team uses DevTools to trace the affected interaction.
7. After reducing a long JavaScript task, the team validates both the trace and field data.
8. The change is retained only if performance improves without reducing task success or conversion.

This creates a feedback loop: Lighthouse detects, DevTools diagnoses, WebPageTest stress-tests, RUM validates, and budgets prevent regression.

The mappings that get confused most often

❌ FID and INP measure the same thing
✓ FID measured only the first interaction’s input delay; INP covers full interaction latency across the visit

❌ A strong lab score proves field performance is good
✓ Lab explains causes under controlled conditions; field data verifies real devices, networks, and behavior

❌ A Lighthouse score of 100 is the product goal
✓ The goal is faster, more responsive, more stable experiences for real users—not a perfect audit grade

❌ Averages are enough for Core Web Vitals
✓ Assess the 75th percentile, segmented at least by mobile and desktop

❌ CrUX alone is complete RUM
✓ CrUX is valuable public field data with coverage limits; first-party RUM covers your full audience and product dimensions

❌ Supporting metrics replace Core Web Vitals
✓ FCP, TTFB, TBT, and weight diagnose causes; LCP, INP, and CLS remain the user-facing anchors

Checklist: measure what matters

1. Define one North Star value metric plus one behavioral, one perception, one retention, and one reliability/performance metric.
2. Map the highest-value journeys and name the field signals that prove those journeys succeed or fail.
3. Collect Core Web Vitals in the field (LCP, INP, CLS at p75) and keep FID only for historical comparison.
4. Run lab diagnostics (Lighthouse, DevTools, WebPageTest) to explain field regressions—not to replace them.
5. Add attribution dimensions: route/template, device class, connection, release, and interaction target where privacy allows.
6. Set performance budgets for vitals and causes (JS weight, third parties, errors) with warning, regression, and critical alerts.
7. Gate releases with Lighthouse CI assertions (numberOfRuns + metric budgets) and validate wins in production RUM.
8. Close the loop: every performance fix must also protect or improve a user outcome such as completion, conversion, or satisfaction.

If you cannot answer these eight items, you are still optimizing scores instead of measuring what users need.

What this chapter locks in

1. User-centric measurement combines behavior, perception, retention/value, and technical performance—not traffic vanity alone.
2. Lab testing explains capability; field measurement verifies real-world performance; credible programs need both.
3. Core Web Vitals center on LCP, INP, and CLS at the 75th percentile; FID is retired and INP is the responsiveness standard.
4. Supporting metrics and lab tools diagnose causes; RUM, CrUX, and attribution show which users and interactions are affected.
5. Budgets, alerts, and continuous monitoring turn metrics into enforceable product quality—not a one-time audit.

The goal is not a green dashboard. It is evidence that real users can complete important work quickly, easily, reliably, and satisfactorily.

Next: we treat Core Web Vitals as product requirements—so LCP, INP, and CLS become acceptance criteria, not after-the-fact reports.