Core Web Vitals, Explained for Business Owners

Core Web Vitals sound like something only developers should care about. They are not. They are Google's attempt to measure, with numbers, the things your customers feel without naming: the page took ages, I tapped and nothing happened, the button jumped just as I went to press it.

The three measures

• LCP, Largest Contentful Paint. How long until the main thing on the page (usually the hero image or headline) is visible. Good is 2.5 seconds or less.
• INP, Interaction to Next Paint. How quickly the page responds when someone taps, clicks or types. Good is 200 milliseconds or less. It replaced the older FID measure in 2024 and is stricter, because it looks at every interaction, not just the first.
• CLS, Cumulative Layout Shift. How much the page jumps around while it loads. Good is 0.1 or less.

Google judges these on real visits, from Chrome users, at the 75th percentile. In plain terms: the page has to be good for most of your visitors on their actual phones, not just for you on office wifi.

Why it matters beyond Google

Core Web Vitals are one ranking signal among many, and a fast page with weak content will not outrank a slow page that answers the question better. But speed is also conversion. Every second a visitor waits is a second they can leave, and every jumping button is a mis-tap on the wrong thing. You feel slow pages in your enquiry numbers before you see them in rankings.

What usually breaks each one

• Slow LCP: an enormous, uncompressed hero image; a slow server; fonts and scripts that block the page from painting.
• Poor INP: too much JavaScript doing work on the main thread, often from chat widgets, tag managers, trackers and page builders stacked on top of each other.
• Bad CLS: images and embeds without set dimensions, cookie banners and promo bars that push content down, and web fonts that swap in at a different size.

What usually fixes them

• Serve images at the size they are shown, in a modern format, and load the hero first.
• Audit third-party scripts. Each one has a cost; keep the ones that earn it.
• Reserve space for everything that loads late, so nothing pushes content around.
• Choose a stack that renders on the server and ships little JavaScript. A lot of the speed work is decided by the platform, before anyone writes a line.

How to check yours

Run your page through PageSpeed Insights. The top section, labelled with field data, is what Google actually uses. The lab score underneath is a useful diagnostic, but do not chase a perfect 100 at the expense of real users.

Speed is a build decision

Most slow sites were not built slow on purpose; they were built on tools that made speed someone else's problem. At Pinn.Media the same team designs and engineers the site, so performance is part of the design rather than a fix afterwards. Book a discovery call and we will tell you which of the three is costing you most.