Core Web Vitals in Singapore: The 2026 Guide to LCP, INP and CLS

Last updated: 14 August 2026. Written by Adrian Tan, Singapore Digital Marketing (SDM).

Every few months a Singapore business owner forwards us the same screenshot: a PageSpeed Insights report, mostly red, with a note along the lines of “our developer says this is why we are not ranking”. Sometimes they are right. Far more often, the red score is a symptom of something that matters much more than rankings — a site that feels slow and unstable to the person holding the phone, which quietly costs enquiries and orders every single day.

Core Web Vitals are Google’s attempt to put numbers on that feeling. They are not a magic ranking lever, and Google says so in plain language. But they are the closest thing the industry has to an objective, field-measured definition of “does this page feel good to use”, and in a market as mobile-heavy as Singapore that is worth taking seriously.

This guide covers what the three metrics actually measure in 2026, what Google itself says about their weight in ranking, how the wider web is performing against them, and — the part most articles skip — a concrete diagnostic order for fixing them on the kind of WordPress, Shopify and Wix sites that most Singapore SMEs actually run. If you are earlier in the process and still deciding what to build, start with our guide to web design in Singapore first; this article assumes you already have a site and want it to perform.

What Core Web Vitals actually measure

Core Web Vitals are three field metrics collected from real Chrome users. Google’s own documentation is unambiguous about the thresholds and how they are assessed: each metric is evaluated at the 75th percentile of page loads, segmented by device type. In other words, three-quarters of your real visits must hit the target before the page is classed as “good”. An average will not save you; the slow quarter of your traffic is exactly what is being measured.

The one structural change worth knowing about: INP replaced First Input Delay as a Core Web Vital in March 2024, and all three metrics are now stable, with nothing in an experimental or pending state. This matters because INP is a much harder test than FID was. FID only measured the delay before the browser started handling your first interaction. INP measures the full round trip on every interaction, all the way to the next frame the user actually sees. A site that comfortably passed FID can fail INP badly, and a lot of Singapore sites did exactly that when the switch happened.

Do Core Web Vitals affect rankings? What Google actually says

This is where most advice goes wrong in both directions — either “speed is the number one ranking factor” or “Core Web Vitals do nothing”. Google’s page experience documentation is more careful than either camp:

“There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.”

And on the temptation to chase a perfect score, Google is blunter still: “Trying to get a perfect score just for SEO reasons may not be the best use of your time.”

Google frames page experience as a set of self-assessment questions rather than a scoreboard. Its published list asks whether your pages have good Core Web Vitals, are served securely over HTTPS, display well on mobile, avoid excessive ads that distract from the main content, avoid intrusive interstitials, and let visitors easily distinguish the main content from everything else. Notice that only the first of those six is a Core Web Vitals question.

The practical reading for a Singapore business: Core Web Vitals are a tiebreaker, not a trump card. If your content genuinely answers the query better than the competition, a mediocre LCP will not keep you off page one. If you are neck and neck with three other Singapore agencies, suppliers or clinics for the same term, the page that feels instant has an edge. And crucially — the conversion effect of a fast, stable page is measurable on your own analytics long before any ranking change shows up. That is the argument we make to clients: fix this for the revenue, and take the ranking benefit as a bonus. If you want the wider picture of what does move rankings, our technical SEO basics guide sets out the full hierarchy.

How the web is actually performing in 2026

It helps to calibrate against reality rather than against a perfect 100. Chrome UX Report (CrUX) data compiled through 2026 shows that a little over half of tracked origins pass all three Core Web Vitals — around 55–56%, up from roughly 50% in early 2024. Broken down by metric, the pattern has been consistent: LCP is the hardest to pass (high-60s percentage of origins), while CLS and INP sit higher (low-80s and mid-80s respectively).

Two caveats we would flag before anyone quotes those numbers in a board pack. First, different aggregators slice CrUX differently — mobile-only figures are markedly worse than the all-origins blend, with mobile pass rates for all three metrics reported in the high-40s in some analyses. Second, these are origin-level numbers; a single slow template can drag an otherwise healthy site’s origin score down. Treat them as a rough benchmark, not a target.

The useful takeaway is simply this: failing Core Web Vitals is normal, and passing them is a genuine differentiator. If roughly half the web fails, being in the passing half is not a heroic engineering achievement — it is a competitive position available to any Singapore SME willing to spend a focused fortnight on it.

Field data versus lab data — and why your PageSpeed score misleads you

The single most common confusion we untangle is between the two halves of a PageSpeed Insights report:

• Field data (the CrUX section at the top) is what Google actually uses. It is real Chrome users, on real devices and real networks, aggregated over a rolling 28-day window. It is the only data that counts for the page experience assessment.
• Lab data (the Lighthouse performance score, the big number out of 100) is a simulation on a throttled virtual device. It is a diagnostic tool. It is not your Core Web Vitals.

Consequences that catch people out: a brand new or low-traffic Singapore site will have no field data at all, because CrUX needs enough samples to report. That is not a failure; it just means you must rely on lab data plus your own real-user monitoring. And because the field window is 28 days rolling, a fix you deploy today will take up to a month to be fully reflected. We tell clients to expect roughly four weeks before the Search Console Core Web Vitals report moves, and not to panic in week two.

Fixing LCP: work the four-part breakdown, in order

LCP is where most Singapore sites lose, and it is also the most systematically fixable, because Google’s own guidance breaks it into four sequential parts with rough targets for each. Treating LCP as one number is why teams flail; treating it as four parts tells you exactly where to spend the money.

The rule behind the table: the vast majority of LCP time should be spent genuinely loading the HTML document and the LCP resource. Any time when neither is actively loading is pure waste, and pure waste is the cheapest thing to remove.

The four moves, in the order we run them

1. Stop lazy-loading the hero. The single most common self-inflicted wound in WordPress. A performance plugin adds loading="lazy" to every image, including the one that is the LCP element, guaranteeing it starts downloading late. Exclude the hero, and add fetchpriority="high" so the browser knows it matters.
2. Make the LCP resource discoverable in the raw HTML. If your hero lives inside a JavaScript slider or is set as a CSS background applied after render, the browser’s preload scanner cannot see it. Server-side rendering, or simply a plain <img> in the markup, fixes this outright.
3. Clear render-blocking work. Reduce or inline critical stylesheets, and get synchronous scripts out of the <head>. Long main-thread tasks block painting even after the image has arrived.
4. Then, and only then, attack TTFB. Eliminate redirect chains, get caching working at the edge, and reduce server processing. This is usually a hosting conversation, and it is the most expensive of the four — which is precisely why it should not be the first thing you buy.

The Singapore angle on TTFB

Singapore has an advantage almost no other market has: the country is small, densely connected, and sits on major submarine cable landing points, so network latency to a locally hosted origin is negligible. The problem is that a great many Singapore SME sites are not hosted anywhere near Singapore — they sit on a cheap shared plan in the US or Europe because that is what the reseller sold. Every uncached request then makes a round trip halfway around the world before the first byte arrives.

Two fixes, in order of cost: put a CDN in front so that static assets and, ideally, cached HTML are served from a Singapore or regional edge node; and if the origin itself is slow on uncached requests, move the origin closer. We have seen TTFB drop by well over half from the CDN change alone, before anyone touched a line of code. Hosting and CDN costs are covered in our breakdown of what a website actually costs in Singapore.

Fixing INP: the metric that punishes plugin sprawl

INP is a main-thread problem, not a bandwidth problem. It measures the worst-ish interaction latency across the visit — tap a menu, expand an accordion, add to cart — from the input event all the way through to the browser painting the next frame. If the main thread is busy running JavaScript when the tap lands, the paint waits, and the user perceives lag.

In our experience auditing Singapore SME sites, the culprits are remarkably consistent:

• Live chat and WhatsApp widgets loaded synchronously on every page. These are enormously popular in Singapore and are often the single largest third-party script on the site.
• Cookie consent banners that block the main thread while they enumerate scripts. PDPA-driven consent tooling has spread quickly since Singapore’s tracking-consent expectations tightened; done badly it is an INP disaster, and it usually causes a CLS problem too. Our guide to PDPA, marketing and tracking covers the compliance side.
• Page builders with heavy runtime JavaScript — sliders, mega-menus, animation libraries, and the four separate carousel plugins that accumulate over three years of “can you just add”.
• Tag Manager containers stuffed with a decade of tags nobody has audited, several firing on every interaction.

The remediation sequence we use:

1. Audit and delete. Before optimising anything, remove scripts nobody uses. On a typical audit, a quarter to a third of third-party tags turn out to be for tools the business stopped paying for.
2. Defer what is not needed for first interaction. Chat widgets, review badges and analytics enrichment can almost always load after the page is interactive, or on user intent (first scroll, or a tap on a placeholder button).
3. Break up long tasks. Where you own the code, yield to the main thread between chunks of work rather than running one 400ms block.
4. Re-test on a real mid-range Android device, not a MacBook. INP is a CPU-bound metric, and desktop testing hides almost every INP problem you have.

Fixing CLS: mostly a discipline problem

CLS is the easiest of the three to fix and the one that annoys users most viscerally — the tap that lands on the wrong button because an ad or banner pushed the layout down. The fixes are unglamorous and nearly always the same:

• Set explicit width and height attributes (or a CSS aspect-ratio) on every image, video and iframe, so the browser reserves the space before the file arrives.
• Reserve fixed space for anything injected late: consent banners, promo bars, sticky headers, embedded maps, review carousels.
• Preload web fonts and set font-display: optional or swap with a well-matched fallback, so the text does not reflow when the custom font lands.
• Never insert content above existing content once the page has painted, unless it is a direct response to a user action.

One Singapore-specific wrinkle worth naming: if your site serves multiple languages, text expansion between English, Chinese and Malay changes line counts and can shift layouts in ways that only show up in one locale. Test each language separately. Our multilingual SEO guide covers the wider implications of running more than one language version.

A realistic 30-day remediation plan

You do not need a rebuild. On most Singapore SME sites, a focused month of work moves a failing origin into the passing band. Here is the sequence we run, with the honest effort estimate for each.

Track the outcome in two places, not one: the Core Web Vitals report in Search Console for the search-facing view (see our Search Console setup guide if it is not configured), and your own conversion rate by device in GA4 for the business view. If speed work does not eventually show up in mobile conversion rate, it was cosmetic. Our GA4 setup guide covers getting that reporting trustworthy.

What Core Web Vitals will not fix

We would be doing you a disservice if we did not draw the boundary clearly. A perfect Core Web Vitals profile will not:

• Rank a page that does not deserve to rank. Relevance and content quality dominate. Google’s own guidance says so.
• Rescue a site that is not being crawled or indexed properly. If pages are blocked, duplicated or orphaned, speed is irrelevant — see duplicate content and our SEO audit walkthrough.
• Fix a weak offer. A fast page that fails to answer “why you, why now, what does it cost” converts a fraction of a percent faster than a slow one. The redesign checklist covers the messaging side.
• Survive a botched migration. Speed gains evaporate if you relaunch and lose your redirects — see website migration and SEO.

One forward-looking note: as AI assistants and answer engines fetch pages directly, a page that renders its main content server-side and quickly is easier for those crawlers to consume too. That is a side benefit of the same work rather than a separate project — we covered the crawler side in our piece on llms.txt and AI crawlers.

The honest summary

Core Web Vitals are worth fixing, for the right reason. Not because a red score is blocking your rankings — usually it is not — but because roughly half the web fails them, because the fixes are cheap and well-documented, and because the people you want to hear from are mostly on a phone, on the MRT, deciding in a few seconds whether your business looks like it has its act together.

Work the order: LCP by its four sub-parts, INP by deleting and deferring scripts, CLS by reserving space. Measure in the field, not in the lab. Give it a month before you judge it. And if the numbers move but the enquiries do not, the problem was never speed — it was the offer.

If you would rather not run this yourself, our web design and development team in Singapore handles Core Web Vitals remediation as part of build and maintenance work, and you can see the kind of outcomes we report in our client case studies.

Frequently asked questions

Are Core Web Vitals a ranking factor in Singapore specifically?

They work the same way everywhere — Google does not run a separate page experience system for Singapore. Google states there is no single page experience signal, and that its core ranking systems look at a variety of signals aligned with overall page experience. Treat Core Web Vitals as a tiebreaker between comparable pages rather than a primary ranking lever.

My PageSpeed score is 45 out of 100 but Search Console says my Core Web Vitals are good. Which do I believe?

Search Console. That number is your lab score from a simulated device, and it is a diagnostic tool. Search Console reports field data from real Chrome users, which is what Google’s page experience assessment uses. A poor lab score with good field data usually means the simulation is harsher than your actual audience’s devices and connections.

Why does my new website have no Core Web Vitals data at all?

The Chrome UX Report needs a minimum number of real visits before it will report an origin or a URL. New or low-traffic Singapore sites frequently have no field data. Rely on lab testing plus your own real-user monitoring until traffic builds, and check again after a couple of months.

How long after fixing things will my scores improve?

Field data is collected over a rolling 28-day window, so expect roughly four weeks before the change is fully reflected in Search Console. You will see lab scores improve immediately, which is a useful early signal that the deployment worked, but do not judge the project before the field window has turned over.

Does hosting in Singapore improve Core Web Vitals?

It can improve Time to First Byte, which is the largest single component of LCP for many sites, particularly if your origin is currently in the US or Europe and requests are not being cached at an edge. But a CDN in front of a distant origin usually delivers most of that benefit for less money and less disruption. Try the CDN first, then move the origin if uncached requests are still slow.

Do I need to rebuild my site to pass Core Web Vitals?

Usually not. Most failing SME sites we audit are failing for a handful of specific, fixable reasons — a lazy-loaded hero image, undimensioned images, and three or four heavy third-party scripts. A focused month of remediation clears it. A rebuild is only the right answer when the platform itself, or a page builder’s runtime, makes the fixes impossible.

Where this bites hardest: paid traffic. A campaign visitor did not choose you, they chose an ad, so a slow page costs you money twice. The rest of that build specification — message match, form design under the PDPA, and the pre-launch checks — is in landing page best practices for Singapore campaigns.