Quality & design

Why a slow website costs you customers: Core Web Vitals explained

By Nicola Palummo · September 14, 2026 · 7 min read

Why does website speed actually matter?

Speed matters because it acts before anything else: if the page makes someone wait, they leave before they read your message, see your proof, or find the button to contact you. A slow site does not convert poorly, it converts what no one ever saw. Speed is not a detail for technical people, it is the first condition for the rest of your site to have a chance.

The wait hurts most on the phone, where the majority of people land and where the connection is least stable. Someone looking for a CPA or an attorney from their phone, in a hurry, does not wait for the page to finish assembling itself: they go back to the Google results and open the next site. That person was not less interested. You lost them to a problem that had nothing to do with the quality of your work.

The link between speed and conversions is easy to grasp: every second of waiting is one more chance to reconsider, get distracted, or change pages. Google research on the topic is blunt: a 0.1 second improvement in mobile load time lifted real business metrics, with retail shoppers spending 9.2% more and travel sites seeing 10% higher booking rates (Google, Milliseconds Make Millions). A site that shows up fast keeps the person while their attention is highest, which is right away.

What are the Core Web Vitals (LCP, INP, CLS)?

The Core Web Vitals are three public metrics Google uses to measure the quality of a page's experience: LCP measures how long the main content takes to appear, INP measures how responsive the page is to your taps, and CLS measures how stable the page stays instead of "jumping" while it loads. Together they tell you whether the experience is fast, responsive, and stable, the three things a person actually feels.

The term is worth breaking down, because it anchors the whole guide. Core Web Vitals is the set of indicators Google chose as the central signals of user experience, measured on real-world data from the people who visit your site. They are not impressions, they are numbers anyone can verify, for free, on their own domain. Each of the three answers a question the visitor asks without realizing it.

• LCP (Largest Contentful Paint): "how long until it shows up?" The time the main element (usually the large image or the headline) takes to become visible. Good is under 2.5 seconds.
• INP (Interaction to Next Paint): "does it respond when I tap?" The delay between your tap or click and the page's visible reaction. Good is under 200 milliseconds.
• CLS (Cumulative Layout Shift): "does it stay put?" How much elements move while the page loads, those jumps that make you click the wrong thing. Good is under 0.1.

Those thresholds are the ones Google publishes: above them, the experience drops from "good" to "needs improvement" or "poor". A concrete case makes CLS click: you are about to tap "Book now" and at the last second a banner loads and pushes the button down, so you tap the wrong thing. That small jump, multiplied across every visitor, is friction that pushes people away at the exact moment of action. The Core Web Vitals put a number on these micro-frustrations.

How do you measure your site's speed?

You measure speed with two free Google tools: PageSpeed Insights to analyze a single page on the spot, and Search Console to see how every page of the site behaves over time, on real visitor data. All you need is the site address and a few minutes: you get a score, the three Core Web Vitals, and a list of what is slowing things down.

The fastest route is to paste a page address into PageSpeed Insights: it returns two snapshots, the lab test (a simulated run) and the field data (real numbers collected from Chrome users, where available). For a professional firm, it pays to test the pages that truly matter: the home page, the services page, and the contact page, which is the path that leads to a consultation request.

Search Console adds the big-picture view: in the page experience section you can see how many of your URLs come back "good", "needs improvement", or "poor", grouped by issue. Passing all three is not a given: only 43% of sites had good Core Web Vitals for INP on mobile in 2024 (HTTP Archive Web Almanac 2024), so this is a real bar, not a formality. Measuring before you touch the code keeps you from optimizing what already works and ignoring the real bottleneck.

What are the most common causes of a slow site?

The most frequent causes are three: oversized images, weak hosting, and too much code or too many plugins. In the vast majority of cases, a site is slow for these reasons, not because of its complexity. The good news is that they are all fixable, and often the biggest one, images, is also the simplest to solve.

Images are almost always the first culprit. A photo uploaded at full camera resolution can weigh several megabytes and on its own drags down LCP: the browser has to download the whole thing before the page looks ready. The same goes for background videos and carousels stuffed with uncompressed images, common on sites that want to "make a splash" and end up making the visitor wait.

Hosting is the second cause: a cheap server shared with hundreds of other sites responds slowly to requests, and that delay stacks onto everything else. The third is excess code, typical of sites built by piling up plugins and themes full of features no one uses: every add-on loads scripts the browser has to run, and many of those slow down responsiveness, hurting INP. The more a site is assembled in layers, the heavier it gets, without anyone noticing until it is too late.

How do you improve Core Web Vitals without sacrificing design?

You improve the Core Web Vitals by working on the causes: compress and resize images, choose adequate hosting, strip out useless code and plugins, and put content ahead of decorative effects. Speed is not bought with a last-minute trick, it is designed in from the start. And a fast site is not a bare site: polished design and speed coexist, you just have to set the right priorities.

Optimizing images is the move with the best effort-to-result ratio. It means exporting them at the size they actually appear (you do not need a 4000-pixel photo for a 600-pixel-wide slot), compressing them, and using modern formats like WebP, which weigh far less at the same visual quality. On the home page of a photo-heavy firm, this alone can move LCP from "poor" to "good" without removing a single image.

The other moves round it out: hosting sized to your real traffic, lean code instead of a stack of plugins, and the discipline to reserve space for elements that load later, so the page does not "jump" and CLS stays low. This is where the starting choice weighs in: a custom-built site is born optimized, while a template filled in a hurry drags in weight you will never use. We covered this comparing a custom site and a template, where performance is one of the advantages of a project designed from scratch.

Speed, finally, works alongside the other elements that make a site effective. A fast but confusing site does not convert, and a clear but slow one never gets seen: both things count. You will find the other elements that turn a visit into a contact in the UX elements of a website that converts, and the reason all of this has to be thought through from the phone first in why your site should be designed mobile-first.

Article by

DigitiNexus — Web & Design Agency

We are a team of designers and developers specialized in SEO, Next.js and digital growth for professional firms, small businesses and startups, in the US and beyond. We build websites that bring real traffic and real clients.

(written by Nicola Palummo - cofounder)

Work with us