What you will take away
- Field data from real users is the only score that counts.
- Images and third-party scripts cause most of what is slow.
- Reserve space for anything that loads late, and layout shift disappears.
What the three metrics actually measure
Largest contentful paint is when the main content appears - usually a hero image, a heading or a block of text. Interaction to next paint is how quickly the page responds when a user taps or clicks. Cumulative layout shift is how much the content moves around while loading.
Together they approximate the experience of a real person on a mid-range phone on an ordinary connection, which is why they correlate with conversion far better than a total load time figure ever did.
Fixing the largest contentful paint
- Identify the element that is the LCP, which is frequently not the one the team assumes.
- Serve images in a modern format at the size actually displayed, with width and height set.
- Preload the hero image and the fonts it depends on; do not lazy-load anything above the fold.
- Remove render-blocking CSS and JavaScript from the critical path, inlining only what is needed for the first screen.
- Cache HTML at the edge where the content allows it - server response time is a large share of the number.
Fonts deserve specific attention: a font that blocks rendering delays the text that may itself be the LCP element. Use a display strategy that shows fallback text immediately.
Responsiveness and layout stability
Poor interaction latency almost always means the main thread is busy running JavaScript. Ship less of it, split bundles so a route loads only what it needs, defer non-essential work, and break long tasks so the browser can respond between them.
Layout shift has one root cause: content arriving without space reserved for it. Set dimensions on images and embeds, reserve space for banners and advertisements, and never insert content above what the user is already reading.
Every layout shift is a promise the page broke. The user had aimed at something and it moved.
Third-party scripts are usually the ceiling
Analytics, tag managers, chat widgets, advertising and testing tools frequently outweigh the entire application in cost, and they are outside your control at runtime. Audit them, attribute the cost of each, and load what remains asynchronously and after the content.
Set a performance budget and enforce it in the pipeline, because scripts are added one at a time by people who are not measuring the total. A budget check on a pull request is the only mechanism we have seen hold long term.
Measure the field, not the lab
A perfect score on a fast laptop means very little. Collect real-user measurements from your actual audience, segment by device class and connection, and watch the seventy-fifth percentile rather than the median.
Then tie it to something commercial - conversion rate or bounce by performance bucket. That is the chart that gets performance work funded, and it is usually more persuasive than any tooling score.