Web Performance Metrics Testers Should Measure

Measure Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) as your primary user experience metrics. Collect field data from real visitors and use controlled lab runs to reproduce problems and catch regressions. Add First Contentful Paint (FCP) and Time to First Byte (TTFB) to investigate loading delays; use Total Blocking Time (TBT) as a lab diagnostic for possible responsiveness issues. Assess Core Web Vitals at the 75th percentile, and inspect distributions and page groups instead of trusting one average or score.

1. The metrics to measure

Metric	What it tells you	Good	Role and limitations
LCP	When the largest visible content element appears	≤ 2.5 s	Core Web Vital; can be measured in field and lab data.
INP	How responsive a page is across a visitor’s interactions	≤ 200 ms	Core Web Vital; requires interaction data. A page-load-only test cannot measure it directly.
CLS	Unexpected visual movement during a visit	≤ 0.1	Core Web Vital; field and lab measurement are possible, but a lab run without later interactions may miss shifts.
FCP	When the first foreground content appears	≤ 1.8 s	Supporting loading diagnostic, not a Core Web Vital.
TTFB	How long until the server begins responding	≤ 0.8 s	Supporting diagnostic for server and network delay; PageSpeed Insights labels it experimental.
TBT	Main-thread blocking during page load	No Core Web Vital threshold	Lab diagnostic that can help identify potential INP causes. It is not INP.

These good thresholds are categorical guidance, not targets from a newly conducted benchmark. Check the current [Chrome PageSpeed Insights metric guidance](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring/) when setting internal reporting thresholds. The distinction between field metrics, lab metrics, and diagnostic proxies is explained in [web.dev’s Web Vitals overview](https://web.dev/articles/vitals) and [measurement guide](https://web.dev/articles/vitals-measurement-getting-started).

2. Field data and lab data answer different questions

Field data records what real visitors experience across their devices, networks, locations, cache states, and interactions. It tells you whether the experience is good for users in production and how it varies across visits. Chrome UX Report (CrUX) is an aggregated source of field experience; your own real user monitoring (RUM) can provide more detailed pageview-level telemetry.

Lab data comes from a controlled test run. It helps reproduce a problem, inspect its causes, and compare builds under more consistent conditions. Lighthouse and Chrome DevTools are useful for local diagnostics; WebPageTest lets testers specify device or network conditions. A lab run is only a sample of conditions and interactions, so it cannot replace field measurement.

When the readings disagree, compare the test conditions before concluding that one is wrong. Device speed, network, location, cache state, page content, and interactions can all differ. Field status can also shift with visitor mix, browser changes, network conditions, or upstream service latency, even without a code change. As the [Web Vitals guidance](https://web.dev/articles/vitals) puts it, “Only field measurement can accurately capture the complete picture.”

3. Use the 75th percentile and inspect the distribution

Assess each Core Web Vital at the 75th percentile: the recommended guidance expects at least 75% of page visits to meet the good threshold for each vital. An average or median can hide a slow tail. Review the distribution and the share of visits in good, needs-improvement, and poor ranges.

Segment results by page group and, when your data permits, by user conditions such as device or geography. A sitewide aggregate can obscure a template or audience segment with a recurring problem. Compare like with like: keep the metric definition, percentile, page group, and collection window consistent.

4. A practical measurement workflow

1. Choose representative pages. Include important templates and journeys, such as landing pages, product pages, and pages with complex interaction. Use page groups to find patterns instead of assuming one URL represents the whole site.
2. Check available field data. Run the URL through [PageSpeed Insights](https://pagespeed.web.dev/). When available, it shows CrUX field data alongside Lighthouse lab information. A URL may not have enough field data for every metric.
3. Find sitewide patterns. Use the Search Console Core Web Vitals report to identify groups of similar URLs affected by a problem. For an individual URL’s status, use a page-level test; Search Console is intended for group-level diagnosis.
4. Reproduce and diagnose in the lab. Use Chrome DevTools’ Performance panel or Lighthouse. For repeatable comparisons, hold device and network conditions constant. Use WebPageTest when you need to specify those conditions.
5. Investigate the symptom with supporting metrics. For slow LCP, inspect FCP and TTFB to help separate early rendering delay from response-start delay. For poor responsiveness, inspect TBT and main-thread work as clues, then validate with interaction and field data. Check whether visual shifts happen later in the visit.
6. Collect your own RUM if you need detail. The web-vitals JavaScript library is one implementation option. Send its measurements to an analytics or reporting endpoint; collecting values without reporting them does not create a usable monitoring view. Follow the [web.dev measurement guide](https://web.dev/articles/vitals-measurement-getting-started) for field measurement details.
7. Validate fixes over time. Retest with the same lab conditions to check for regressions, then monitor field data to see whether users improve. Search Console describes a 28-day validation session, so this is a monitoring window rather than an instant retest.

5. Capture visual evidence for a performance investigation

Metrics explain timing and stability; a screenshot can help a team see what was on screen at a particular capture point. Use it as visual evidence alongside measurements, not as a substitute for LCP, INP, CLS, or field data. For a repeatable manual capture, open Chrome DevTools, set the desired device emulation, load the page, and capture the viewport or full page using the browser’s screenshot command. Keep viewport, page state, and capture timing consistent when comparing results.

For automated visual evidence, [ScreenshotNeo](https://screenshotneo.com) is a website screenshot API and MCP server. Its API can return PNG, JPEG, WebP, or PDF captures; options include full-page capture with lazy images loaded, device and viewport settings, waiting for a selector or network idle, and custom CSS or JavaScript. Consult the [ScreenshotNeo API documentation](https://screenshotneo.com/docs/) for parameters and response details.

6. Or skip the browser setup

Send one GET request to capture a URL. This runnable cURL example saves a WebP file:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000 shots. [Create a free ScreenshotNeo account](https://screenshotneo.com/account/sign-up/).

7. Common mistakes and troubleshooting

Symptom or mistake	Likely cause	What to do
A Lighthouse score is treated as the site’s complete user experience.	A controlled lab run cannot represent every visitor’s device, network, location, or interactions.	Pair lab diagnostics with field data and report the collection context.
TBT is reported as INP.	TBT is a lab metric based on a different calculation; it is only a diagnostic proxy.	Label TBT accurately and use interaction-capable field measurement to assess INP.
The page looks fine in the lab but has poor CLS in production.	The shift may happen later in the visit or after an interaction not exercised by the lab run.	Inspect field data and reproduce the later page state or interaction.
The median looks good but users still report slowness.	A slow tail is hidden by the median or average.	Review the 75th percentile and the full distribution, segmented by page group.
PageSpeed Insights shows no field value for a URL.	There may not be enough CrUX data for that URL or metric.	Use lab diagnostics for immediate investigation and consider site RUM for pageview-level coverage.
A field status changes after a release with no obvious related code change.	Traffic mix, networks, browser changes, or upstream services may have changed.	Compare page groups and user conditions over the same reporting windows; inspect recent changes without assuming causation.
A visual comparison differs between runs.	Viewport, page state, cache, network, or capture timing may differ.	Make those conditions consistent and treat the screenshot as visual context, not a metric measurement.

8. Performance, reliability, and cost considerations

Repeatability matters more than a single fast-looking run. Keep lab device and network settings stable when comparing code changes, and record the page group, test conditions, and collection window with results. Use field data to judge real visitor experience; lab runs are faster feedback for diagnosis but are sensitive to test setup and page state.

For production RUM, choose an endpoint and reporting approach that can handle the volume and dimensions you need, such as page group and device category. The cited guidance does not specify provider prices or a universal telemetry cost, so evaluate those against your traffic and retention needs rather than assuming a particular budget.

For visual captures, ScreenshotNeo’s cache TTL is configurable, and cache hits are not billed. Its published plans range from 1,000 free shots per month with no card, through paid tiers of $5 for 3,000, $15 for 15,000, $39 for 60,000, $99 for 250,000, and $249 for 1,000,000; yearly billing gives two months free. Every feature is on every plan. These are screenshot-capture costs, not a replacement for RUM or performance testing.

9. Frequently asked questions

Can I measure INP without waiting for real visitors?

A page-load-only lab run cannot directly measure INP because INP depends on interactions. Use interaction-capable measurement and field data to assess the metric.

Should I optimize FCP if it is good but LCP is poor?

FCP and LCP describe different points in loading. A good FCP does not guarantee that the largest content appears quickly; use both to narrow down where the delay occurs.

Does a screenshot prove that a page passed its Core Web Vitals?

No. A screenshot records visual output at a capture point. Core Web Vitals require metric measurements, and INP in particular requires interaction data.

How long does Search Console validation take?

Google describes a 28-day validation session. It is intended to observe whether an issue returns over time, not to provide an immediate pass or fail after a code change.