A familiar scene: the developer shows a Lighthouse score of 95. The same week, support receives messages saying the site is slow. Both can be true, because they are not measuring the same thing.
Lighthouse is a lab test: one device profile, one connection speed, one page load. Your real users are on different phones, different networks, with browser extensions and often a weak signal.
Lab and field
The data Google uses in ranking is field data, not the lab score: real measurements collected from Chrome users. You can reach it through the Core Web Vitals report in Search Console and the top section of PageSpeed Insights.
A practical rule: the lab test is a diagnostic tool, field data is the report card. The lab shows what is broken, the field tells you how much it matters.
What LCP actually measures
LCP measures when the largest visible piece of content gets painted. Usually that is a hero image or a large heading.
Bad LCP has four classic causes: a slow server response, critical CSS arriving late, the image being discovered late, and the image being far heavier than it needs to be.
The mistake we see most is loading the hero image through JavaScript. The browser cannot see it in the initial HTML, so it starts downloading late.
INP: newer and harsher
INP measures how long it takes for the screen to respond after a user interacts. It is stricter than the old FID metric, because it looks at every interaction across the page rather than only the first one.
The main cause of bad INP is heavy JavaScript. If the browser is busy while a menu opens, a filter applies or an item goes into the cart, the tap is wasted and the user presses again.
In e-commerce the cost lands directly on conversion: a button pressed twice means either two orders or an abandoned cart.
What changes on mobile
A site that is fine on desktop can collapse on mobile, because a phone processor runs the same JavaScript far more slowly. The LCP element changes too; an image that stays small on desktop fills the screen on a phone.
That is why we run speed work from mobile. Fixing mobile fixes desktop; the reverse is not true.
Where to start
Order matters, because starting in the wrong place burns effort without moving the result.
- Images. Correct dimensions, modern formats, priority on the hero image. On most sites this alone is the biggest win.
- Fonts. Text staying invisible until the font loads delays LCP directly.
- Third party scripts. A chat widget, a heatmap, three separate analytics tools. Each looks innocent; together they drown the page.
- Server response time. Caching and hosting; this step usually belongs to the software team.
- JavaScript volume. Removing unused code is the actual cure for INP.
The link between speed and conversion
Treating speed as an SEO job alone is incomplete. A slow page hits you twice: as a ranking signal in search, and as direct abandonment on the user side.
On mobile in particular, a delay at the payment step ends in an abandoned cart. That is why we read speed measurements alongside the conversion funnel: where the delay is, and how many people drop at that step.
When a page needs to be faster, the priority order should follow commercial logic: product and cart pages first, then categories, and corporate pages last.
Practical rules for images
Images sit at the centre of the problem on most sites, and four rules solve most of it:
- Serve the image at the size it occupies on screen; do not drop a 3000 pixel file into a 600 pixel slot
- Use modern formats, the file size difference is significant
- Give the hero image priority and never lazy load it
- Serve different versions for different screen sizes
Apply those four and LCP recovers on its own for most sites, without changing a single line of JavaScript.
A measurement routine
A one off test is not enough, because field data accumulates over a 28 day window. The routine looks like this: check the Core Web Vitals report weekly, verify with a lab test after significant changes, and if real user monitoring is in place, read it alongside conversion.
Track the outcome of speed work through the share of pages rated good in field data, not through a single score.
Pruning third party scripts
The script list on a site turns into a junk drawer nobody looks at: a heatmap trialled years ago, a chat tool no longer used, two separate analytics setups.
Pruning works like this: list every script, then write down who actually uses that tool. Anything without an owner gets removed. Of what remains, the non critical ones load late, after the page is usable.
That single exercise usually delivers the fastest INP win on a site, and it touches nothing in the design.
Common mistakes
- Optimising the one page you measure and forgetting the other templates
- Applying lazy loading to the hero image, which needs to load immediately
- Measuring on staging and never checking the difference in production
- Changing everything at once and never learning what worked
Speed is not a job you finish once. A new campaign page, a new script or one heavy image can undo all of it. Building the measurement routine is worth more than a single round of optimisation.