Core Web Vitals in Plain Language: Three Numbers That Matter

Core Web Vitals are three measures of what a visit feels like, as documented by the Chrome team on web.dev. Largest Contentful Paint, LCP, times how quickly the main content, usually the hero image or headline block, becomes visible: good is 2.5 seconds or under. Interaction to Next Paint, INP, times how quickly the page visibly responds after a tap or click: good is 200 milliseconds or under. Cumulative Layout Shift, CLS, scores how much visible content jumps around as the page loads: good is 0.1 or under. Read them from field data, real visitors over the last 28 days, fix the worst one first on the template that earns the money, and ignore any tool that grades you on only one of the three.

LCP is the number visitors mean when they say a page is slow. On a product page it is usually the main product image; on a landing page, the hero image or the headline block. It runs late when the image is enormous, when the browser discovers it late because it is buried in a slider or loaded by script, or when the server and theme delay everything ahead of it. The fixes are correspondingly plain: shrink and prioritise the main image, as the images guide details, remove render-blocking extras, and keep the template lean. Judge progress on the field figure for the template, not on one hand-timed load on your own phone.

INP measures the delay between a visitor's action, opening a filter, choosing a variant, tapping add to cart, and the page visibly answering. A page can load quickly and still feel broken if every tap is followed by a thoughtful pause while scripts think. Heavy third-party tools, oversized theme scripts and busy main-thread work are the usual causes, which is why the audit in the script budget belongs in every INP investigation. Visitors rarely describe INP in words; they describe it as the site feeling laggy or ignoring them, and they act on the feeling by leaving tasks half done. Test your own key interactions on a mid-range phone and count the pauses honestly.

CLS is the trust number. It grows when images arrive without reserved space, when banners, cookie notices and review widgets push content down after it rendered, and when fonts swap and reflow text. Its worst harm is not aesthetic: a visitor reaches for a button, the page shifts, and they tap the wrong thing, an ad, a delete, a different product. That moment reads as the site tricking them, and it happens on pages whose owners have never seen the shift because their fast connection loads everything before they look. Reserve space for every late-arriving element, size images in the markup, and treat any element that inserts itself above existing content as a CLS suspect until proven innocent.

Work on the template with the most buying traffic first, usually product or the main landing template, and within it, on the vital furthest from its web.dev threshold relative to its traffic. A failing LCP on the product template outranks a failing CLS on a quiet information page, because the cost of a problem is its size multiplied by the visitors who meet it. Fix one vital at a time where you can, re-measure the field data over the following weeks, and log the change, because several simultaneous speed changes leave you unable to say which one earned the improvement, and therefore unable to defend it when a later addition takes it away.

Field data is a trailing average of real visits, so it improves slowly after a fix: expect weeks, not a morning, for a repair to show fully, a lag explained in measuring speed with field data. Lab tests, run on demand under controlled throttling, answer immediately and are the right tool while fixing, as long as you remember they describe a simulated visitor, not your population. Pages with too little traffic may show no field data at all; there the lab result on a mid-range mobile profile, plus your own device testing, is the working standard. Confusing the two, celebrating a lab pass while field data still fails, is the commonest self-deception in speed work.

Good enough is all three vitals passing on field data for your main templates, with the thresholds as documented on web.dev: LCP 2.5 seconds or under, INP 200 milliseconds or under, CLS 0.1 or under. Passing does not end the work, because new apps, images and content erode it monthly, but it changes the work from rescue to maintenance. Chasing perfection beyond the thresholds on a small store is usually a poor trade against product, content or offer work with a clearer payoff. Note also what the vitals do not measure: a fast, stable page with a confusing offer still fails commercially. The vitals are the floor of the experience, and the rest of this bench, layout, browsing and paying, is the house built on it.