Core Web Vitals: what actually moves the numbers

Core Web Vitals get treated as a checklist of optimisations to apply. They are better understood as three questions about how a page behaves: how quickly does the main content appear, how quickly does the page respond when someone interacts with it, and does the layout stay still while it loads.

Largest Contentful Paint

LCP measures when the largest visible element finishes rendering — usually a hero image, a heading block or a video poster. The common mistake is optimising everything on the page instead of finding what the LCP element actually is and shortening its path.

1. Identify the LCP element with field data rather than guessing from a lab test
2. Make sure it is discoverable in the initial HTML, not injected by JavaScript
3. Preload it if it is an image, and serve a correctly sized modern format
4. Remove render-blocking resources ahead of it in the critical path
5. Check the server response time — no amount of frontend work fixes a slow origin

Interaction to Next Paint

INP replaced First Input Delay because it measures the whole interaction, not just the initial delay. It reflects how much work the main thread is doing when a user taps or clicks.

• Reduce the amount of JavaScript shipped and parsed on each route
• Break long tasks up so the main thread can respond between chunks
• Avoid layout-triggering work inside scroll and resize handlers
• Keep animation state out of framework state where a re-render per frame would result
• Defer non-essential third-party scripts, which are frequently the largest contributor

That fifth point is worth emphasising. Analytics, chat widgets, tag managers and advertising scripts routinely account for more main-thread work than the site's own code. Measure them individually before defending them.

Cumulative Layout Shift

CLS is the most straightforward to fix and the most often ignored. Content moving under a user's finger as they reach for a button is a genuine usability failure, not just a metric.

• Set width and height on images and video so space is reserved before they load
• Reserve space for anything injected later: banners, embeds, dynamic components
• Use font-display and metric-adjusted fallbacks so text does not reflow on font swap
• Never insert content above existing content once the page has painted

Lab data and field data

Lab tools run a page under fixed synthetic conditions. Field data records what real users on real devices and networks experienced. They disagree often, and when they do, the field data is the one that matters — for both users and ranking.

Use lab tools to diagnose and iterate quickly, because they are repeatable. Use field data to decide what to work on and whether the work helped. A site that looks excellent in a lab test and poor in the field usually has a problem that only appears on mid-range mobile hardware.

Where the effort usually pays

In our experience the ordering is fairly consistent: server response time and render-blocking resources for LCP; third-party scripts and bundle size for INP; images and injected content for CLS. Start there before reaching for micro-optimisations.