Core Web Vitals and Website Speed: What Moves the Numbers
What the three metrics measure, what they did on our own rebuilds, where the load time usually goes, and how to check your own site.
Before a visitor reads your headline or looks at your prices, they experience your load time. A page that appears at once reads as competent; a page that stutters reads as the opposite, and good copy rarely wins back a first impression spent watching a blank screen. Google measures that experience with three numbers it calls Core Web Vitals, and this post covers what they mean, what moved them on our own projects, and where the time usually goes.
The three numbers, and Google's targets
Google's Core Web Vitals page defines the three metrics and the targets for a good experience.
- Largest Contentful Paint (LCP): how fast the main content appears. Google's target is within the first 2.5 seconds of the page starting to load.
- Interaction to Next Paint (INP): how quickly the page responds to a tap or click. It replaced First Input Delay in 2024. The target is under 200 milliseconds.
- Cumulative Layout Shift (CLS): how much the layout jumps while it loads. The target is a score under 0.1.
They count for search too. Google says good Core Web Vitals, with the rest of page experience, align with what its core ranking systems seek to reward. They are one signal among many, and the more useful way to read them is as a description of the first few seconds a visitor spends with you.
What the numbers did on real sites
We measure every rebuild with the same instrument on the same day, before and after. So instead of industry averages, here is what moved on our own projects.
- Florida Green Improvements: homepage largest contentful paint on mobile from 11.62s to 3.46s, homepage weight from 29,834 KiB to 1,839 KiB, mobile performance score 59 to 90.
- Renewed Bodyworks: homepage largest contentful paint on mobile from 8.48s to 3.19s, and 79% less homepage weight, 9,813 KiB to 2,029 KiB.
- Prodani Miami: largest contentful paint from 768ms to 352ms and product-page layout shift from 0.075 to 0.012, over five interleaved runs per page with the cache disabled.
- Zahav Medspa: a Lighthouse performance score of 99/100 on desktop with a layout shift of zero, re-runnable by anyone against zahavmedspa.com.
Each case study has the method written down, including the figures that moved the wrong way. We also run the same checks on this site. In October 2026 they found our About page weighing 3.7MB on a phone, almost all of it four team photos shipped at up to twenty times the size they were shown. Resized to the size on screen, the page dropped to 852KB.
Where the time usually goes
Across those rebuilds, the same few causes accounted for most of the gap.
- Media served at upload size. One 5.6MB hero video re-encoded to 375KB was three quarters of Prodani's homepage saving on its own, and our own team photos were the same mistake.
- Scripts and stylesheets loading before the page can paint. Anything the first screen does not need belongs after it.
- Fonts fetched from a third party on the critical path. Self-hosted, subsetted files, with the hero face preloaded and nothing else.
- The main image loading late. Lazy loading is right below the fold and wrong for the largest image on the first screen, which should load first.
- Nothing reserving space for content that arrives late, which is what layout shift measures. Fixed-size slots for images, video and anything that types itself in.
What we do on every build
We build every site static-first. The HTML arrives complete, so the page is readable before a single script runs.
- Ship less JavaScript: every kilobyte is parsed on the visitor's phone, not on our machines.
- Serve modern image formats such as WebP and AVIF, sized for the screen that shows them, with a smaller file for phones.
- Pre-render the pages, so the first paint does not wait on the network.
- Load what sits below the fold lazily, and the first screen's main image eagerly.
- Measure before and after with the same tool, three runs at least, and keep the numbers.
How to check your own site
Run PageSpeed Insights at least twice on a warmed-up page and treat a single run as noise; one of our own measurements this month read 15 seconds on the first run and 5 on the next two. Mobile is where the problems show, because mobile is where the throttling is. If you have field data, read that first; the lab score is a proxy. To keep measuring after launch, Apogee Watcher re-runs PageSpeed tests across your pages on a schedule, with field data beside them.
If your site is slow, the fix is rarely one trick. It is measuring, cutting what the first screen does not need, then measuring again. That is also what the case studies above are, and what a website rebuild with us includes.