Web Development
Core Web Vitals, and why your site is slow
Three metrics, a handful of causes, and the fixes that actually move them. Most slow sites are slow for the same small set of reasons.
Core Web Vitals are three metrics Google uses to measure real user experience: Largest Contentful Paint (how quickly the main content appears), Interaction to Next Paint (how quickly the page responds to input), and Cumulative Layout Shift (how much the page moves while loading). They are a ranking input, but the stronger argument for fixing them is that they measure things that directly affect whether people stay.
The three metrics
| Metric | Measures | Good | Needs work |
|---|---|---|---|
| LCP | Time until the largest visible element renders | Under 2.5s | Over 4s |
| INP | Responsiveness to user interaction | Under 200ms | Over 500ms |
| CLS | Unexpected layout movement | Under 0.1 | Over 0.25 |
These thresholds are measured on real visitors, not in a lab, and at the 75th percentile — so a site that is fast for you on office fibre can still fail on the mid-range Android phones and mobile data most Indian users actually have.
Why LCP is usually bad
Almost always one of five things:
- An enormous hero image, unoptimised, in the wrong format
- Render-blocking CSS or JavaScript in the head
- Slow server response — the browser cannot start until bytes arrive
- Fonts that block text from painting
- Content assembled client-side, so the page arrives empty and fills in later
What actually fixes it
- Serve images in AVIF or WebP, sized to their display size, with width and height set
- Preload the LCP image; lazy-load everything below the fold — but never the LCP image itself
- Use font-display: swap so text renders in a fallback immediately
- Render server-side or statically where you can
- Cache properly and put a CDN in front
Why INP is usually bad
INP measures whether the page responds when someone taps. Poor scores come from JavaScript occupying the main thread when the user tries to interact.
- Too much JavaScript, much of it for features on other pages
- Third-party tags — analytics, chat widgets, marketing pixels, A/B testing
- Expensive work running on every scroll or input event
- Large component trees re-rendering on each state change
Third-party scripts deserve particular scrutiny. Most sites accumulate them and never remove any. Audit what is loading and ask, for each one, whether it earns its cost — a tag for a tool nobody has opened in a year is pure loss.
Why CLS is usually bad
CLS is the easiest to fix and the most irritating to users — it is what makes you tap the wrong thing because the page moved. Causes are almost always:
- Images without width and height, so nothing reserves their space
- Ads or embeds injected into unreserved space
- Web fonts swapping at a different size to the fallback
- Banners inserted above existing content after load
Set explicit dimensions on every image and iframe, reserve space for anything injected, and match fallback font metrics to the web font.
Measuring it properly
Lighthouse runs a simulated test on your machine and is useful for diagnosis, not for judging reality. Google ranks on field data — real visitors, real devices, real networks.
- Search Console Core Web Vitals report: your actual field data, grouped by page type
- PageSpeed Insights: field data at the top, lab diagnosis below
- Chrome DevTools Performance panel: for finding the specific cause
Fix by page template rather than by page. Every product page shares one template, so one fix moves thousands of URLs.
How much does this matter for rankings?
Less than performance vendors imply, and more than developers hope. Core Web Vitals is one input among many, and excellent scores will not rescue thin content. Between two comparable pages it can be the difference.
The stronger argument is commercial. Slow pages lose visitors before they see anything, and that cost is immediate and measurable regardless of what any algorithm does.
Where to start
- Pull field data from Search Console and find the worst-performing template
- Fix CLS first — it is cheap and immediately noticeable
- Then LCP: images, then render-blocking resources, then server response
- Then INP: audit third-party scripts and remove what is not earning its place
- Set a performance budget so the problem does not quietly return
That last point is the one most teams skip. Without a budget enforced in the build, performance decays with every release — and you are back here in eighteen months.