If your website rankings have flatlined and you can’t figure out why, Core Web Vitals might be the culprit. I’ve seen this pattern dozens of times with Singapore business owners who come to us frustrated. Their content is solid, their keywords are on point, but Google keeps pushing them down. When we dig into the technical layer, the answer is often sitting right there in their page experience scores.
This guide breaks down what Core Web Vitals actually measure, how to diagnose problems on your own site, and the specific fixes that move the needle. No fluff, just the practitioner stuff.
What Core Web Vitals Actually Measure
Core Web Vitals are three specific metrics Google uses to evaluate how your website feels to a real person using it. Not how it looks. Not how clever your copy is. How it performs in the browser when someone clicks through from a search result.
Google rolled these into its Page Experience ranking signals back in 2021, and they’ve only become more important since. Think of it this way: if your website were a hawker stall, Core Web Vitals measure how fast you serve the food, whether you respond when someone calls out an order, and whether the plates stop sliding around on the tray.
Here are the three metrics you need to know cold.
Largest Contentful Paint (LCP)
LCP measures how long it takes for the biggest visible element on your page to fully render. This is usually your hero image, a featured video thumbnail, or a large block of text above the fold.
Google’s threshold: under 2.5 seconds. Anything between 2.5 and 4 seconds needs improvement. Above 4 seconds is poor.
Here’s what most people get wrong about LCP. They assume it’s just about image size. It’s not. LCP is affected by server response time (TTFB), render-blocking resources, client-side rendering delays, and resource load order. A 50KB hero image can still have a terrible LCP if your server takes 1.8 seconds to respond and three render-blocking CSS files queue up before it.
Interaction to Next Paint (INP)
As of March 2026, Google officially replaced First Input Delay (FID) with Interaction to Next Paint. If you’re still optimising for FID, you’re working on a deprecated metric.
INP measures the responsiveness of your page across all user interactions during a visit, not just the first click. Every tap, click, and keyboard input gets measured. Google then reports the worst interaction (at the 75th percentile) as your INP score.
Target: under 200 milliseconds. If your INP is above 500ms, your site feels sluggish and Google knows it.
INP is harder to fix than FID was because it captures the full lifecycle of an interaction: the input delay, the processing time, and the presentation delay. Heavy JavaScript is almost always the villain here.
Cumulative Layout Shift (CLS)
CLS measures visual stability. When elements on your page jump around as it loads, that’s layout shift. You’ve experienced this yourself: you’re about to tap a button on your phone and suddenly an ad loads above it, pushing everything down. You tap the wrong thing. Infuriating.
Target: under 0.1. Google calculates this by multiplying the impact fraction (how much of the viewport shifted) by the distance fraction (how far it moved). Multiple small shifts add up.
Why These Metrics Hit Harder in Singapore
Singapore has excellent internet infrastructure, which means your visitors have high expectations. A user on a 1Gbps fibre connection notices a 3-second load time more acutely than someone on a rural connection who’s used to waiting.
Mobile usage in Singapore sits above 90% for most local search queries. Google evaluates Core Web Vitals based on mobile performance first. If your site runs beautifully on desktop but chokes on a mid-range Android phone, your scores will reflect the mobile experience.
I’ve audited sites for Singapore SMEs where the desktop LCP was 1.8 seconds but mobile LCP was 5.2 seconds. The business owner had no idea because they only ever checked their site on their office MacBook. That gap was costing them page-one positions for competitive local keywords.
How to Measure Your Core Web Vitals Properly
There are two types of data you need to understand: lab data and field data. Most people only look at one, and that’s a mistake.
Field Data (Real User Metrics)
Field data comes from actual Chrome users visiting your site. Google collects this through the Chrome User Experience Report (CrUX). This is the data Google actually uses for ranking decisions.
Where to find it:
- Google Search Console: Go to Experience > Core Web Vitals. This shows you which URLs pass or fail, grouped by issue type.
- PageSpeed Insights: Enter any URL and look at the top section labelled “Discover what your real users are experiencing.” If you see “not enough data,” your site doesn’t have sufficient Chrome traffic for CrUX reporting.
Lab Data (Simulated Testing)
Lab data comes from controlled tests run in a simulated environment. It’s useful for debugging specific issues but doesn’t reflect real-world conditions.
- Lighthouse (in Chrome DevTools): Press F12, go to the Lighthouse tab, run an audit. Note that Lighthouse cannot measure INP because it simulates a single page load with no real user interactions.
- WebPageTest.org: Lets you test from Singapore-based servers, which is critical if your hosting is local. You can simulate 4G mobile connections to get realistic results.
Always prioritise field data for decision-making. Use lab data for diagnosis and debugging.
Fixing LCP: The Specific Steps
Start by identifying your LCP element. In Chrome DevTools, run a Lighthouse audit and look for the “Largest Contentful Paint element” diagnostic. It will tell you exactly which element is being measured.
Reduce Server Response Time
If your Time to First Byte (TTFB) is above 800ms, fix this before anything else. For WordPress sites on shared hosting in Singapore, I regularly see TTFB of 1.2 to 2 seconds. Switching to a VPS or managed WordPress host with a Singapore data centre can cut this in half overnight.
If you’re on a decent host already, check whether your CMS is running uncached database queries on every page load. A persistent object cache (Redis or Memcached) often solves this.
Optimise the LCP Resource
If your LCP element is an image:
- Convert to WebP or AVIF format. AVIF gives roughly 30% better compression than WebP for photographic images.
- Add explicit width and height attributes to the img tag.
- Use
fetchpriority="high"on the LCP image so the browser prioritises it. - Do NOT lazy-load your LCP image. This is a common mistake. Lazy loading your hero image delays it because the browser waits until it enters the viewport before requesting it.
Eliminate Render-Blocking Resources
Inline your critical CSS (the CSS needed for above-the-fold content) and defer the rest. For JavaScript, use defer or async attributes on script tags that aren’t needed for initial render.
Fixing INP: Where Most Sites Struggle
INP problems are almost always caused by heavy JavaScript execution. Here’s how to diagnose and fix them.
Identify Long Tasks
Open Chrome DevTools, go to the Performance tab, and record a session where you interact with your page. Look for long tasks (marked with red corners) that exceed 50ms. These are blocking the main thread and causing input delay.
Common Culprits in Singapore Sites
- Chat widgets: Tawk.to, Zendesk, and similar tools often inject heavy scripts. Delay their initialisation until after user interaction or load them in a web worker.
- Analytics overkill: I’ve seen Singapore ecommerce sites running Google Analytics, Facebook Pixel, TikTok Pixel, Hotjar, and Microsoft Clarity simultaneously. Each one adds main-thread work. Audit whether you actually use the data from all of them.
- Third-party review widgets: Google Reviews carousels and Trustpilot widgets can add 200-400ms of processing time.
Break Up Long Tasks
If you have custom JavaScript that runs for more than 50ms, break it into smaller chunks using requestAnimationFrame or the newer scheduler.yield() API. This lets the browser handle user input between chunks instead of making the user wait.
Fixing CLS: Quicker Wins
CLS fixes are often the fastest to implement and the most satisfying.
Reserve Space for Dynamic Content
Every image, ad, embed, and iframe on your page needs explicit dimensions. For responsive images, use CSS aspect-ratio or the width/height HTML attributes (modern browsers calculate the ratio automatically).
Avoid Injecting Content Above Existing Content
If you have a cookie consent banner, notification bar, or promotional strip that pushes page content down when it appears, it causes layout shift. Use a sticky or overlay approach instead so existing content stays put.
Preload Web Fonts
When custom fonts load late, the browser swaps from a fallback font to your custom font, causing text to reflow. Add <link rel="preload" href="font.woff2" as="font" crossorigin> in your document head. Combine this with font-display: optional if you’re willing to sacrifice the custom font on very slow connections to prevent any shift at all.
How Core Web Vitals Connect to Your Broader SEO Strategy
Core Web Vitals are a ranking factor, but they’re a tiebreaker, not a trump card. If your content is thin and you have no backlinks, perfect Core Web Vitals won’t save you. But when you’re competing against sites with similar content quality and authority, page experience becomes the deciding factor.
I’ve seen this play out clearly in competitive Singapore niches like insurance comparison, tuition services, and F&B. Two sites with comparable content and link profiles, but the one with passing Core Web Vitals consistently holds the higher position.
Core Web Vitals should be a standard checkpoint in any proper technical SEO audit, alongside crawlability, indexation, internal linking, and structured data. They’re not separate from SEO. They are SEO.
Fast, stable pages also earn more backlinks naturally. Journalists, bloggers, and content curators are more likely to reference a page that loads cleanly on mobile. If you’re building linkable assets or running digital PR campaigns, poor page performance undermines the whole effort.
Frequently Asked Questions
Has Google replaced First Input Delay with something else?
Yes. As of March 2026, Interaction to Next Paint (INP) officially replaced FID as the responsiveness metric in Core Web Vitals. INP measures all interactions during a page visit, not just the first one. If your tools still report FID, they need updating.
How often does Google update Core Web Vitals data?
CrUX field data is collected over a rolling 28-day window. So if you make improvements today, expect to see the changes reflected in PageSpeed Insights and Search Console within about four to six weeks.
Do Core Web Vitals matter for sites with low traffic?
If your site doesn’t generate enough Chrome traffic, it won’t have CrUX field data. Google may fall back on page-level signals or similar-origin data. But the performance improvements still benefit your users directly, which affects bounce rate and engagement.
Can a WordPress site pass Core Web Vitals?
Absolutely. But it depends heavily on your theme, plugins, and hosting. I’ve seen WordPress sites score in the green across all three metrics after switching to a lightweight theme, removing five or six unnecessary plugins, and moving to managed hosting with a Singapore server location. It’s very achievable.
Is it worth hiring someone to fix Core Web Vitals?
If you can handle image compression and plugin cleanup yourself, start there. But INP issues involving custom JavaScript, third-party script conflicts, or server-side rendering problems usually need a developer or technical SEO specialist who can read a performance trace and knows what to prioritise.
What to Do Next
Run your top five landing pages through PageSpeed Insights right now. Look at the field data first. If any of the three Core Web Vitals show amber or red, you know where to start.
If you’d rather have someone walk through your site’s performance data with you and build a prioritised fix list, that’s exactly what we do at Best SEO. Drop us a note through our contact page and we’ll take a look at your numbers together. No obligation, just clarity on what’s holding your site back.