“The website is slow” can describe several experiences. The main image might take too long to appear. A menu might ignore a tap for a moment. A button might move just as someone tries to press it.
These problems need different fixes. Core Web Vitals give you a useful vocabulary for separating them before you buy another plugin, change hosting or start a redesign.
Three metrics, three different questions
Google's Web Vitals guide defines three measures:
- Largest Contentful Paint (LCP): how long it takes for the largest eligible image or text block in the viewport to render.
- Interaction to Next Paint (INP): how quickly the page gives a visual response to interactions such as clicks, taps and key presses.
- Cumulative Layout Shift (CLS): how much visible content unexpectedly moves as the page is used.
The recommended “good” thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. CLS is a score, not a duration.
Assess these at the 75th percentile of real visits, separating mobile and desktop. In practical terms, a good result should describe at least three quarters of the measured experiences, rather than a single fast test on your own computer.
A high overall performance score does not automatically mean every one of these measures is healthy.
Read field data before choosing a fix
Field data comes from actual visits. Lab data comes from a controlled test. Both are useful, but they answer different questions.
Start with PageSpeed Insights and Search Console's Core Web Vitals report when data is available. Then use a browser performance recording or lab audit to investigate the cause. Check whether a report describes the exact URL or a broader origin-level group before treating it as evidence about one page.
A small or newly launched website may not have enough public field data. That is an information gap, not a passing result. Use repeatable lab tests and realistic manual checks while you collect evidence.
Google explains these differences in its guide to lab and field data. Keep your comparison conditions consistent: the same page, device profile, connection and cache state.
If loading is slow, inspect the critical content
Imagine a service page whose main photograph appears late. Compressing every image in the media library might help eventually, but first identify the actual LCP element and inspect its loading sequence.
Ask when the browser discovers the image, when the server begins responding and whether other work delays rendering it. An image hidden behind JavaScript can start loading late even when its file is small.
For an above-the-fold LCP image, make it discoverable early and avoid lazy-loading it. Serve dimensions appropriate to the layout, use an efficient format and apply priority hints selectively. Prioritizing every image defeats the purpose.
If the delay is in the initial server response, investigate backend work and caching. For personalized pages, checkout and account areas, caching needs rules that preserve the correct user's data.
These checks follow the breakdown in web.dev's LCP optimization guide: server response, resource discovery and loading, and the delay before rendering.
If taps feel ignored, investigate main-thread work
A page can appear complete while its JavaScript keeps the browser busy. A filter button may trigger a large calculation, update hundreds of elements or compete with third-party scripts.
Record the slow interaction and inspect the work around it. Look for expensive handlers, repeated rendering and long tasks. Remove unnecessary work before trying to conceal the delay with animation.
Useful changes may include loading nonessential features later, reducing the amount of rendered content, breaking up long tasks or moving suitable calculations to a worker. The right choice depends on the trace.
INP measures the visual response to an interaction; it is not a timer for an entire remote operation. A form can acknowledge a click promptly and still need time to send data. Show a clear pending state, then give an honest completion or error message.
See web.dev's INP optimization guide for the distinction between input delay, processing and presentation.
If the layout jumps, reserve space early
Layout instability often starts with content whose size is unknown until it loads: an image, embed, banner or font.
Give images explicit dimensions or an appropriate aspect ratio. Reserve space for embeds and dynamic components. Avoid inserting a promotional banner above content someone is already reading.
Review font loading too. A replacement font with different proportions can change line breaks and move surrounding content. Test with a cold cache rather than relying on the fonts already stored in your browser.
The CLS optimization guide explains these common causes. On your own site, reproduce the movement and identify which element changed size before changing unrelated CSS.
Prioritize the pages that matter
Build a short action list around important journeys: a landing page, a service page, a product page or the contact form. For each issue, record the affected page, evidence, proposed change and a repeatable check.
After a release, compare lab results immediately and follow field data as it accumulates. Do not expect a rolling real-user report to reflect a new release instantly.
Good performance supports a useful website, but it does not guarantee search rankings. Google makes that distinction in its Core Web Vitals guidance.
If you have a slow page and a report full of warnings, send me the URL. I can help turn the evidence into a focused improvement plan.
Last updated Oct 25, 2026
