What do the three metrics mean?
Google’s Core Web Vitals documentation defines three current metrics.
| Metric | Plain-English question | Current “good” threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | How long before the main content appears? | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly does the page respond after a user interacts? | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much does the layout jump unexpectedly? | 0.1 or less |
These thresholds are assessed at the 75th percentile. That means the experience needs to be good for most visits, not only for one fast device on one clean connection.
Mobile and desktop can differ. A page can also pass one metric and fail another. Diagnose the metric that is actually weak.
LCP: when the useful page feels late
Largest Contentful Paint usually reflects how quickly the largest visible content element appears.
For a service page, that might be the main heading or hero image. On a product page, it might be the product image. A slow LCP can leave the buyer staring at an incomplete page while the information they came for has not appeared.
Common causes include oversized images, slow server responses, render-blocking resources, fonts and client-side rendering. The right fix depends on the measured page and template. “Compress every image” is not a diagnosis.
Check whether the delay affects an important path. A slow article illustration and a slow appointment page do not carry the same commercial risk.
INP: when the page ignores the buyer
Interaction to Next Paint measures the delay for user interactions across a page visit. It reports one value that represents the slower interactions most users experienced, while leaving out rare extremes.
The problem is easy to recognize. Someone taps the menu, changes a product option or opens a form, but the page appears to ignore them. Long JavaScript tasks, heavy third-party code and complex interaction handlers can contribute.
Lighthouse does not measure INP because its standard run does not include real user interaction. It reports Total Blocking Time as a lab clue. Real-user field data is still needed to judge INP.
Focus on interactions tied to the next step: menu use, form controls, booking tools, product options, filters and checkout actions.
CLS: when the page moves under the user’s hand
Cumulative Layout Shift measures unexpected visual movement.
You have seen the problem when a button moves as you tap it, text jumps after a font loads or a late banner pushes the page down. Images without reserved space, injected content and font swaps can contribute.
Not every movement is bad. A layout change caused by the user’s deliberate action may be expected. CLS focuses on unexpected shifts that make the page harder to use.
The fix should stabilize the page without hiding useful content or breaking accessibility.
Field data and lab data answer different questions
Field data records real visits. Lab data records a controlled test.
| Evidence | Best question | Important limitation |
|---|---|---|
| Chrome UX Report (CrUX) | What did eligible Chrome users experience over time? | Aggregated and unavailable for some low-volume URLs |
| Search Console Core Web Vitals | Which URL groups show a real-user problem? | Groups similar pages and may omit sparse URLs |
| PageSpeed Insights field section | What does CrUX report for this URL or origin? | Uses a rolling window rather than today’s release alone |
| Lighthouse lab test | What might be causing the problem in this test environment? | It does not measure INP; Total Blocking Time is only a lab clue |
| First-party real-user monitoring | Which users and templates experience the issue? | Requires careful implementation and privacy controls |
Google’s explanation of lab and field data differences is direct: environments and user behavior vary. A mismatch does not mean one tool is broken.
Why PageSpeed scores disagree
PageSpeed Insights can show field data from CrUX and lab data from Lighthouse on the same page. Those panels use different samples and time windows.
The field view may stay poor after yesterday’s fix because it reflects a rolling period. A lab run may be fast because it did not reproduce the slow user’s device, location or interaction. A low-traffic URL may have no field result at all.
Use the disagreement as a clue. For INP, compare field data with interaction traces or Total Blocking Time as a diagnostic—not as the same metric:
| Pattern | Likely next check |
|---|---|
| Field poor, lab good | Segment real devices, locations, templates and third-party behavior |
| Field good, lab poor | Re-run consistently and confirm whether the lab condition affects real users |
| Both poor | Trace the weak metric on the affected template |
| No URL field data | Check origin data, similar templates or privacy-safe first-party monitoring |
Do not average the two into a new score. They answer different questions.
When is a performance project justified?
A project makes sense when four conditions are present:
- Important path: the issue affects a page or template tied to a qualified buyer action.
- Repeatable evidence: field data or repeated tests show a real pattern.
- Scoped cause: the team can name the likely code, asset or delivery constraint.
- Validation path: the release can be tested and reversed if it causes harm.
If those conditions are missing, investigate before buying a broad rebuild.
Google treats Core Web Vitals as part of page experience. Passing them does not guarantee rankings. Failing them does not prove why traffic changed. Relevance, usefulness and the wider search system still matter.
Fix the smallest repeatable cause
Start with the template that carries the business risk.
Record the weak metric, affected URL group and real buyer action. Use Lighthouse or a performance trace to locate likely causes. Make a contained change. Re-test the lab condition, then allow the field window to show what real users experience.
| Before | Change | Lab check | Field check | Rollback condition |
|---|---|---|---|---|
| Metric, template and sample | Exact code or asset change | Did the diagnosed cause improve? | Did the user pattern improve? | What requires reversal? |
This is slower than chasing a plugin score. It is also much easier to defend.
Protect the right path in each industry
The metrics stay the same. The page that deserves priority changes.
| Industry | Critical path to test | Commercial record to protect |
|---|---|---|
| Home Services | Service page, mobile menu, call and estimate request | Qualified calls and booked jobs |
| Healthcare | Provider, service, location and appointment request | Appropriate and fulfilled appointments |
| Legal | Practice-area, attorney and consultation request | Prospective-client enquiries and accepted matters |
| B2B SaaS | Product, use case, pricing, demo and signup | Qualified demos and pipeline |
| eCommerce | Category, product, cart and checkout | Completed orders, returns and repeat purchases |
Healthcare measurement must avoid protected health information. Legal paths and labels need jurisdiction and advertising review. Performance events should describe the action, not expose confidential details.
Decide what to fix before paying for speed
If an important template has a proven performance constraint, review Mindflow’s Organic SEO service and the broader technical SEO decision guide.
If all you have is a red score, contact Mindflow with the affected URL, device type and field-data screenshot. Mindflow can help decide whether the page needs a deeper performance review. Faster pages do not guarantee better rankings.
You can also review the Mindflow methodology to see how a measured problem becomes a priority.