Lighthouse and real-user website performance

A lab run answers how a particular page performed under a particular test setup. Field data answers how observed visitors experienced the site across their devices, networks and journeys. Both are useful, but they are not interchangeable. A fast local connection can hide a large download, while a controlled mobile test may reveal a bottleneck that affects only part of the audience. Begin a performance report by naming the measurement method, URL, environment and time period.

Largest Contentful Paint, or LCP, measures when the main visible content loads. Interaction to Next Paint, or INP, measures responsiveness to user interactions. Cumulative Layout Shift, or CLS, measures unexpected movement in the layout. Google’s good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, evaluated at the 75th percentile. Keep the underlying values visible; an aggregate score can conceal which problem needs work.

Before using a field result, establish whether it describes the specific URL or a broader origin, the device category and the reporting period. A low-traffic page may not have a public field result. That is a coverage limitation, not a failing score. Where appropriate, first-party real-user measurement can add useful journey detail, subject to the site’s privacy choices. A change released today will not instantly replace a field dataset that still contains earlier visits.

Keep the device emulation, network settings, location, page state and test method consistent. Run enough checks to distinguish a repeatable issue from one unusual result. Lighthouse’s performance score is a weighted diagnostic and can vary with conditions. Its normal page-load audit does not directly establish real-user INP across all interactions. Test the navigation, filters, forms and other work users actually do after loading. Preserve the trace or measurement that explains the suspected cause.

For slow LCP, inspect when the main content is discovered, transferred and rendered. For sluggish interactions, inspect the work running when a person clicks or types. For layout movement, inspect late-loading content, media dimensions and interface changes. Do not enable every optimization at once: changing several causes together makes results harder to interpret. Start with the repeated template or component that affects important journeys. Include third-party scripts in the investigation where they are present.

Record the before-and-after method, the affected templates and the measured timings. Check a representative set of pages, including a heavy page and a page with an important interaction. Verify that images remain readable, forms complete, keyboard focus is visible and private content is not incorrectly cached. Then review later field evidence when enough new observations exist. A performance engagement should report both the improvement it demonstrated and any remaining gap in real-user coverage.