Every audit I run opens with Core Web Vitals, because they sit in the rare overlap between what Google measures and what customers feel. The advice online is mostly recycled generalities, so here is what genuinely shifts the numbers.
LCP is nearly always the hero image
Largest Contentful Paint usually lands on the big image or headline block at the top of the page. Three fixes, in the order I try them.
- Serve the right format at the right size. Run every image through a resize and WebP or AVIF conversion with explicit width, height and quality settings. The saving over an unoptimised JPEG is usually substantial, and on image-heavy catalogue sites it is the single biggest win available.
- Preload the hero and never lazy-load it. Lazy-loading the first image on the page is the most common self-inflicted wound I see. It happens because a plugin applies lazy loading to everything by default and nobody exempts the top of the page.
- Cut render-blocking CSS and JavaScript. One stylesheet, deferred scripts. A whole framework loaded so that a logo strip can scroll is a tax paid on every single visit.
INP punishes JavaScript you forgot about
Interaction to Next Paint measures how long the main thread makes people wait. The pattern I see in audit after audit is a site carrying three carousel libraries, two abandoned chat widgets, a tag manager stuffed with pixels from campaigns that ended years ago, and jQuery sitting alongside a modern framework doing the same job twice. Deleting the unused half is dull work. It is also free performance.
CLS is about reserving space
Layout shift comes from images with no dimensions, banners injected after load, and fonts that swap late. Set width and height attributes on everything. Reserve a slot for anything that arrives dynamically. Use font-display: swap with a fallback that has similar metrics so the reflow is small.
Test on the network your customers actually use
A score achieved on office fibre tells you very little. Most Indian traffic arrives on a mid-range Android phone over a patchy 4G connection, and that is the condition worth designing for. I hold builds to a sub-two-second load on a throttled connection rather than a green score in a lab run.
Use field data, not lab data
PageSpeed Insights reports both. The field data comes from real Chrome users and is the one Google acts on. Fix whichever field metric is worst, then wait. The reporting window rolls over 28 days, so a fix you ship today will not show up tomorrow, and people give up on good changes because of that lag. Performance work pays out slowly and quietly, which is exactly why so few competitors bother with it.
Web consultant and developer, working since 2010 on search, performance, custom builds and AI product media.