It's common to see claims like "every extra second costs you so many percent of sales". There are serious studies on the subject, but their numbers hold for the context of whoever measured them and don't automatically transfer to your site. What can be said with confidence is simpler: pages that are slow, or that shift around while loading, frustrate the person on the other side, especially on a phone. And Google has a public way to measure this: Core Web Vitals.
In this post I explain the three metrics in practical terms and what usually sits behind a slow site.
Field data and lab data
Before the metrics, one distinction that clears up a lot of confusion. Lab data is a simulation: Lighthouse loads the page under controlled conditions and gives it a score. Field data is what real Chrome users actually experienced, collected in the CrUX report and shown in PageSpeed Insights and Search Console.
A score of 100 on your laptop doesn't guarantee a good experience for someone opening the site on a mid-range phone with a weak signal. web.dev recommends looking at the 75th percentile of visits, with mobile and desktop measured separately. In other words, the goal is for the vast majority of people to have a good experience, not just the average visitor.
The three metrics at a glance
| Metric | What it measures | Good |
|---|---|---|
| LCP (Largest Contentful Paint) | when the main content appears | up to 2.5 s |
| INP (Interaction to Next Paint) | how long the page takes to respond to a tap or click | up to 200 ms |
| CLS (Cumulative Layout Shift) | how much the layout moves on its own | up to 0.1 |
LCP: has the main content appeared?
LCP marks the moment the largest visible element, usually the hero image or the headline block, finishes rendering. web.dev breaks that time into four parts: the server response, the delay before the browser starts downloading that resource, the download itself, and the delay before it is painted on screen.
The most common culprits:
- a huge hero image, with no versions for different screen sizes and no modern format such as WebP or AVIF;
- lazy loading applied to the main image itself, delaying exactly what should come first;
- an image discovered late because it comes from CSS or is inserted by JavaScript;
- a slow server, or no caching;
- a page that only builds its content after downloading and running a lot of JavaScript.
INP: did the page respond?
INP replaced the old FID as a Core Web Vital in 2024. It measures the time between an interaction (tapping a button, opening a menu, typing) and the next frame that shows the result on screen. That time has three phases: the wait until the browser can handle the event, the processing itself, and the visual update.
The problem is almost always too much JavaScript competing for the same main thread: third-party scripts (chat widgets, ad pixels, tag managers), long tasks that don't hand control back to the browser, and pages with an enormous number of elements. The fix starts with a very non-technical question: does this script really need to be here?
CLS: has the page stopped moving?
CLS measures unexpected layout shifts. It's the button that drops down at the exact moment you were about to tap it. The most frequent causes, according to web.dev itself, are images without a defined width and height; ads, embeds and banners inserted after loading; font swaps that change the size of the text; and animations using properties that affect layout instead of transform.
The fix is usually to reserve space: dimensions or aspect-ratio on images, a fixed area for anything that loads later, and a fallback font with proportions close to the final font.
What really makes a site slow
In practice, small and mid-sized business sites are rarely slow for a single reason. The pattern I run into most is accumulation: an off-the-shelf theme that loads every page's assets on every page, a background video at the top, a carousel, photos uploaded straight from a phone, fonts with many weights, and several marketing scripts installed over the years with nobody remembering why.
A concrete example: a WhatsApp button can be a simple link, which weighs practically nothing, or a third-party widget that downloads JavaScript on every visit. I go into this in WhatsApp on landing pages.
And conversion?
The relationship is real, but indirect. Someone arriving from Google or Instagram on a phone wants to understand the offer and find a way to get in touch quickly. Every bit of friction (content that takes a while, a button that doesn't respond, a layout that jumps) is one more chance to give up. Performance doesn't replace a clear offer or a well-built page, as I explained in a landing page that converts. It removes obstacles from the path.
If you want to know the effect in your case, measure it: record inquiries before and after the improvements, comparing periods with the same kind of traffic.
How I handle performance in a project
A lot is decided during design: how many fonts, whether the top of the page has a video or an image, which scripts are essential. In development, I use images in the right sizes and formats, fonts hosted on the site itself with few weights, and as little JavaScript as possible on initial load.
Before delivery, I test with PageSpeed Insights. After launch, I follow the field data in Search Console once the site has enough traffic to show up in it. I explain this work in more detail on the websites page.
If your site feels slow and you want to know where to start, you can send me the address through the contact page.