Web Performance

Why it matters

Users experience a slow or jumpy page as a broken one: they tap the wrong button when the layout moves, tap twice when nothing seems to happen, or leave. Functional tests rarely catch this, because on a fast office laptop the page eventually works.

Performance also regresses quietly: a heavier image, a new third-party script or a banner inserted at the top can slow a page down without failing a single test case. A tester who knows the metrics and thresholds turns "it feels slow" into a measured, reproducible defect.

The three Core Web Vitals and their thresholds

Each Core Web Vital measures one part of the experience, and web.dev defines three bands for each: good, needs improvement and poor.

• LCP (Largest Contentful Paint), loading: the time from the start of navigation until the largest image, text block or video in the viewport is rendered. Good: 2.5 s or less. Poor: above 4.0 s.
• INP (Interaction to Next Paint), responsiveness: the delay from a click, tap or key press to the next frame the browser paints; over the whole visit, the slowest interaction counts, ignoring rare outliers. Good: 200 ms or less. Poor: above 500 ms. INP replaced First Input Delay (FID) in 2024.
• CLS (Cumulative Layout Shift), visual stability: a score without a unit for content that moves unexpectedly, taken from the largest burst of layout shifts; shifts right after the user's own input are not counted. Good: 0.1 or less. Poor: above 0.25.
• Judging a page: each metric is read at the 75th percentile (p75) of visits, the value that 75% of visits stay at or below, separately for mobile and desktop, and the page passes only when all three are good. The limits are exact boundaries: an LCP of 2,500 ms is good, 2,501 ms is not.
• Example: at the 75th percentile, a product page with LCP 3.1 s, INP 180 ms and CLS 0.18 fails, because LCP and CLS need improvement although INP is good.

Lab data and field data

Lab data is measured in a controlled environment: one device profile, one network setting, usually an empty cache. Two lab tools matter most: the DevTools Performance panel, and Lighthouse, the audit tool in Chrome DevTools that loads the page under simulated mobile or desktop conditions and reports the metrics and a score. Lab data is repeatable, available before release and shows the cause: the LCP element, the script that blocked the main thread, the element that moved.

Field data comes from real users on their own devices and networks, also called real user monitoring (RUM). The Chrome User Experience Report (CrUX) collects it for public pages with enough Chrome traffic and reports the 75th percentile over the previous 28 days; Google's PageSpeed Insights web page shows it for a URL next to a Lighthouse lab run, and teams can collect their own with the open-source web-vitals library. Field data shows what users actually get, but it arrives late, does not exist for staging and rarely explains the cause.

• INP needs real interactions, so a lab tool that only loads the page cannot report it. Lighthouse shows Total Blocking Time (TBT), the total time long tasks blocked the main thread while the page loaded, as a lab proxy: a high TBT warns that interactions may be slow, but it is not INP.
• Lab and field values for the same page usually differ: real users have other devices, warm caches and other screen sizes, and therefore other LCP elements, and they scroll and click.
• Use field data to decide whether a problem exists and how big it is; use lab data to find the cause, compare builds before release and confirm a fix. The Lighthouse score (0 to 100) is a lab summary, not the Core Web Vitals assessment.

Testing page speed step by step

Treat a performance check like any other test: chosen pages and interactions (search, product, checkout; filter, add to cart), fixed conditions, an expected result and evidence. Test mobile and desktop separately.

• Fix the conditions: an incognito window without extensions, a stated build and environment, Lighthouse's mobile setting or stated CPU and network throttling, and one load with an empty cache and one with a warm cache.
• Run Lighthouse several times and use the median (the middle value once the results are sorted), because results vary between runs. Record the metric values and the LCP element, not only the score.
• Record key interactions in the Performance panel with CPU throttling: long tasks on the main thread show what a slow click waits for, and the Layout shifts track shows which element moved. Images without dimensions, late banners and web fonts are common causes of layout shifts.
• In the Network panel, check the largest files, compression (Content-Encoding), cache headers of static files and how long the HTML document takes, since server time is part of LCP.
• Compare with a baseline: the previous build under the same conditions, or a budget the team agreed, such as LCP at most 2.5 s with the mobile setting. The difference is your finding.

Try it: Response Time Analyzer Try it: Response Size Analyzer Try it: Cache Header Analyzer

Worked example: a product page that fails its Core Web Vitals

PageSpeed Insights shows field data for a shop's product page on mobile: LCP 3.1 s, INP 180 ms, CLS 0.18. To find the causes, the tester runs Lighthouse five times on staging and records a Performance trace:

• Lab LCP (4.4 s) is worse than field LCP (3.1 s) because of the throttling and the empty cache; both point the same way, which is what matters.
• Finding 1: the 2.4 MB LCP image has loading="lazy", so the browser requests it late. Evidence: the LCP element and the waterfall.
• Finding 2: the promo banner is inserted above the price after the first render, with no space reserved, and pushes the content down. Evidence: the trace and a screen recording.
• INP is good in the field, so TBT alone does not justify a responsiveness defect; it is noted as a risk to recheck.
• After the fixes, confirmation testing repeats the same lab runs (LCP 2.2 s, CLS 0.02). Field values improve gradually, because CrUX covers the previous 28 days.

Product page /p/1042, staging, build 5.8.0
Lighthouse in DevTools, mobile, incognito, 5 runs, median

  Metric   Median   Good up to   Observation
  LCP      4.4 s    2.5 s        LCP element: hero image, 2.4 MB
  TBT      620 ms   -            lab proxy for INP, no CWV threshold
  CLS      0.21     0.1          shift when the promo banner appears

Network  hero.jpg  2.4 MB  loading="lazy"  request starts at 1.9 s
Trace    layout shift at 2.6 s: banner inserted above the price

Frequently asked questions

References

• Web VitalsGoogle (web.dev)The Core Web Vitals (LCP, INP, CLS): what they measure and the thresholds for a good user experience.
• What are browser developer tools? — MDNMDN Web Docs (Mozilla)An introduction to the developer tools built into browsers — the inspector, the JavaScript console and the debugger — for examining a page while testing it.