Core Web Vitals get treated as a compliance checkbox — a score to chase in a Lighthouse report, disconnected from anything a visitor actually feels. That’s backwards. The three metrics Google measures (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift) are trying to quantify the same three things that make a site feel fast or feel broken. Fix them in the wrong order and you’ll spend a week on work nobody notices.
LCP: how long until the page feels there
Largest Contentful Paint measures when the biggest visible element — almost always a hero image or a headline block — finishes rendering. On most Singapore SME sites we audit, the largest single cause is an unoptimised hero image: a 3–4MB JPEG straight off a phone, serving the same file to a 4-inch screen and a 27-inch monitor.
- Serve modern formats (AVIF/WebP) at the actual rendered size, not the upload size.
- Mark the hero image as a high-priority fetch instead of lazy-loading it — lazy-loading the one image everyone waits for is a common self-inflicted wound.
- Check server response time (TTFB) before touching the front end. A CDN edge and a host with a Singapore or nearby region will often close more of the gap than any client-side fix.
- Trim render-blocking CSS and fonts. A single unoptimised Google Fonts import can add several hundred milliseconds before anything paints.
INP: how the page responds once someone touches it
Interaction to Next Paint replaced First Input Delay as the responsiveness metric, and it’s stricter — it measures the worst interaction on the page, not just the first one. The usual culprit is JavaScript: a heavy analytics or chat-widget bundle blocking the main thread right when someone taps a menu or an “add to cart” button.
- Audit third-party scripts first. Tag managers, chat widgets and review-carousel plugins are the most common source of long tasks on WordPress sites.
- Break up long-running JavaScript with smaller tasks, or defer anything that isn’t needed for the first interaction.
- Avoid layout thrashing in event handlers — reading and writing to the DOM in the same tick is a quiet but frequent cause of jank.
CLS: does the page hold still
Cumulative Layout Shift is usually the cheapest of the three to fix and the most annoying when it’s wrong — a page that jumps as an image, an ad slot, or a font loads in is the fastest way to make a fast site feel unstable.
- Always set explicit width and height (or an aspect-ratio box) on images and embeds, so the browser reserves space before the asset arrives.
- Use font-display: swap or, better, preload the font file so text doesn’t reflow when a web font finally loads.
- Never inject a banner, cookie notice, or promo bar above existing content after the page has settled.
A practical order of operations
When a site fails all three, this is the order we work in: hosting and TTFB first, because everything else is downstream of it; then LCP, because it’s the one visitors consciously notice; then CLS, because it’s usually a few lines of CSS; then INP, which tends to need the most careful profiling and pays off the least in raw ranking terms but the most in how the site actually feels to use.
And measure with field data, not just a lab score. Lighthouse runs once, on one connection, with no real user behind it. The Chrome UX Report and Search Console’s Core Web Vitals panel show what’s actually happening across your real visitors — on real Singapore mobile networks, on real mid-range Android phones — which is the only version of “fast” that Google’s ranking systems, and your customers, are responding to.
Leave a Reply