Is your website fast on your users' phones?

Open a product page on a phone, select an option, and try to continue. If the button reacts late, an image pushes the price down, or the screen freezes while a script loads, you have found a problem. The last report's score does not change that experience.

A test on the team's laptop helps investigate. Deciding what to improve requires considering who uses the site, on which devices, and on which pages. A checkout with little traffic may deserve more attention than the homepage.

Use lab tests to investigate and visits to prioritize

Lighthouse runs a test under controlled conditions. Field data comes from actual visits, with differences in devices, networks, and behavior. The web.dev guide to lab and field data explains why the results can disagree.

We suggest starting with a question about use. Where does someone wait or repeat an action? Then find the measurement that helps investigate that delay.

Separate mobile and desktop. Separate pages with different jobs, too. A domain-wide average can hide a slow registration page among hundreds of simple content pages.

If the sample is still too small, record that limitation. Missing data does not mean the page passes. Use controlled tests to locate problems while collecting observations from visits.

Understand what each metric answers

The good-experience thresholds for Core Web Vitals are LCP at most 2.5 seconds, INP at most 200 milliseconds, and CLS at most 0.1, evaluated at the 75th percentile. For each metric, at least 75% of measured visits should meet the threshold.

LCP observes when the largest visible text block or image appears. INP measures the visual response to interactions. CLS quantifies unexpected content shifts. These answer different questions. A page can appear quickly and still be difficult to use.

Connect the user's report to an investigation:

Report	First place to look
"The main photo takes ages"	Which element determines LCP and when its load starts
"I tapped and nothing happened"	Work performed during the interaction
"The button moved"	Content inserted without reserved space

This table guides the search. It does not prove the cause.

Fix the delay you actually found

If the main image determines LCP, check that it appears in the initial HTML and avoid loading="lazy" on it. Serve a file suited to its display size. These recommendations come from the LCP optimization guide.

Before converting every image format, inspect the loading sequence. A small image discovered late still arrives late. Record when the browser requests it so you can tell whether your change addressed the delay you observed.

For a slow interaction, identify what keeps the main thread busy. The INP optimization guidance includes reducing and splitting long tasks. Visual feedback after a tap matters, but it does not remove the time needed to complete a query.

For a product filter, measure the button's response and the arrival of results separately. Improving the first does not prove that the second improved. Your records need to distinguish them.

Build the budget around the page

A catalog and an image editor need different amounts of code. Prefer a budget tied to the page you are working on. Record transferred bytes and the duration of important interactions before changing the implementation.

After the fix, repeat the same scenario under comparable conditions. Record the change and monitor new visits. If traffic changed alongside the deployment, do not attribute every difference to the code.

Include the complete task in acceptance criteria. A person should be able to open the product, choose an option, and submit the form without losing what they entered. A report helps locate the delay. Completing that task gives the improvement its purpose.