Core Web Vitals and What They Actually Cost a Business

A clinic owner we spoke with last year had a website that looked fine on her own laptop. Fast Wi-Fi, new machine, everything loaded in a blink. But her front desk kept hearing the same thing from new patients: "I tried to book online but the page kept jumping around and I gave up." She wasn't losing patients to a competitor with a better website. She was losing them to a page that took too long to become usable and shifted under their thumb the moment they tried to tap a button.

That is Core Web Vitals in real life. Not a Google score. Not a technical badge. It is the gap between someone wanting to give you their business and actually managing to do it.

What the three metrics actually measure

Google boiled page experience down to three things, and each one maps to a real moment a visitor lives through.

Largest Contentful Paint (LCP) measures how long it takes for the main content, usually a hero image or headline, to actually appear. If that takes more than two or three seconds on a mobile connection, a good chunk of visitors have already left before they've seen what you offer.

Interaction to Next Paint (INP) measures how responsive your site feels when someone taps a menu, fills a form, or clicks "book now." A site that looks loaded but ignores the first tap for a second or two feels broken, even if it isn't.

Cumulative Layout Shift (CLS) measures how much things move around while the page is loading. This is the one that causes people to hit the wrong button, close an ad by accident, or abandon a form because the field jumped just as they started typing.

None of these are abstract. Each one is a specific point where a visitor decides whether your business feels trustworthy and competent, or clunky and not worth the trouble.

Why this quietly costs money

Nobody files a complaint when a page is slow. They just leave. That is what makes Web Vitals expensive: the cost is invisible unless you go looking for it.

A realtor's listing page that shifts around while photos load will lose the visitor right as they're deciding whether to request a viewing. A clinic's booking form that lags on every keystroke will get abandoned halfway through. A retailer's product page that takes four seconds to show the "add to cart" button will see people bounce back to search results and land on a competitor instead.

Google also uses these signals as part of how it ranks pages, particularly on mobile. Two businesses with similar content and similar backlinks, one with a fast, stable site and one without, will not rank the same. Over time, that difference compounds. You end up paying more for ads to make up for organic traffic you should have gotten for free.

The usual causes, and they're rarely dramatic

We've audited a lot of sites that were built quickly, by agencies chasing a deadline or by business owners using a page builder that promised speed and quietly delivered the opposite. The problems tend to repeat:

• Images uploaded at full camera resolution and simply squeezed into a smaller box with CSS, instead of being properly resized and compressed
• Fonts and scripts loading from five different third-party services, each adding its own delay before anything shows up
• Pop-ups, cookie banners, and embedded widgets that load after the page renders and push everything else down the screen
• Plugin-heavy CMS builds, often WordPress, carrying years of add-ons that nobody has cleaned out
• No image dimensions set in the code, so the browser doesn't know how much space to reserve before the image arrives

None of these are exotic problems. They're the accumulated result of small shortcuts, taken over time, by whoever built or maintained the site last.

What fixing it actually involves

Improving Web Vitals is rarely one big change. It's a series of specific, unglamorous fixes: compressing and resizing images properly, loading fonts locally instead of pulling them from external servers, deferring non-critical scripts until after the main content renders, setting explicit width and height on every image and embed so the layout doesn't jump, and trimming the plugin or dependency list down to what's actually needed.

For webapps and custom-built sites, it also means being deliberate about how much JavaScript ships to the browser on first load, and making sure interactive elements respond immediately rather than waiting on a bloated script to finish executing.

This is technical work, but it isn't mysterious. Any competent development team can run a site through PageSpeed Insights or Chrome's own Web Vitals report and get a clear list of what's slowing things down. The harder part is prioritising the fixes that actually move the needle instead of chasing a perfect score for its own sake. A business doesn't need a 100 out of 100. It needs a site that loads fast enough and stays stable enough that people finish what they came to do.

Where this fits into the bigger picture

We build websites, webapps, and CRM systems for clients across Canada and India, and performance is never treated as a separate task tacked on at the end. It's part of how the thing is built in the first place, because retrofitting speed into a site that was never designed with it in mind is always more expensive than doing it right from the start.

If your site was built a few years ago, or built cheaply and quickly, there's a good chance it's carrying some of these issues without anyone noticing. The good news is that most of it is fixable without a full rebuild.

If you'd like us to take an honest look at how your site actually performs for real visitors, not just on your own fast connection in the office, get in touch through /contact or start a conversation at /start.