Core Web Vitals: How to Improve Page Experience for Singapore Visitors

Core Web Vitals turn page experience into three scores Google reads from real visits: the time your main content takes to appear, the speed your page answers a tap or click, and the steadiness of your layout while it loads. Google's ranking systems use these scores, and in Singapore most page views come from phones, so a slow mobile page costs you visitors and some search ground. Ahrefs' Singapore database shows about 400 searches a month for "core web vitals". Below, you find what each metric measures, Google's good scores, the fix for each one and the tools that report them. Aemorph's guide to how search engines work explains how Google crawls, renders, indexes and ranks pages.

See Aemorph's technical SEO service

Written by Kevin Dam, founder of Aemorph, who has practised SEO since 2010 and sits on the Forbes Agency Council. Aemorph is a Google Partner. LinkedIn

What Are Core Web Vitals?

The three Core Web Vitals are Largest Contentful Paint (LCP), which times loading, Interaction to Next Paint (INP), which times responsiveness, and Cumulative Layout Shift (CLS), which scores visual stability. Google places each page in a "good", "needs improvement" or "poor" band for every metric, as listed on its web.dev Web Vitals page. A Singapore site faces exactly the same thresholds as a site anywhere else.

Core Web Vitals thresholds, as published by Google.

Sources: web.dev, October 2024 and others

What changed in March 2024?

Google swapped First Input Delay (FID) for Interaction to Next Paint as its responsiveness Core Web Vital on 12 March 2024. FID measured only how long the browser waited before it began processing the first interaction on a page. INP covers every click, tap and key press in a visit, right through to the frame that shows the result, so it reflects responsiveness for the whole session (web.dev, INP becomes a Core Web Vital). Advice that still names FID and its 100-millisecond limit is out of date.

How does Google decide whether a page passes?

A page passes when its 75th-percentile visit sits in the "good" band on all three metrics at once. In plain terms, at least three visits in four score that well or better. Google rates mobile and desktop separately, and phones carry the larger share of Singapore page views, so check the mobile result first. Metrics also pass through experimental, pending and stable stages, and only the stable ones form the Core Web Vitals. Aemorph's guide to mobile SEO covers mobile-first indexing and the checks a phone layout needs.

Core Web Vitals in Singapore: A Mobile-First Market With Real-User Data

Phones account for well over half of Singapore page views and Google dominates Singapore search, so the mobile Core Web Vitals result deserves the closest watch on a Singapore site. StatCounter recorded mobile at 56.86% of Singapore page views in September 2026, desktop at 41.56% and tablets at 1.58% (StatCounter, Singapore). In the same month Google held 92.16% of search engine market share in Singapore and Bing held 4.53%.

Sources: StatCounter, September 2026 and others

Country-level data in the Chrome UX Report (CrUX) shows how Chrome users in Singapore experience your pages, apart from visitors elsewhere. CrUX records real-user data at page and origin level from Chrome users who opted in (Chrome for Developers, CrUX methodology). When your buyers are in Singapore, judge your site on the Singapore figures.

Why Do Core Web Vitals Matter for Singapore SEO?

Google confirms its ranking systems use Core Web Vitals and recommends good scores "for success with Search", and Google held 92.16% of search engine market share in Singapore in September 2026. Google also cautions that good scores in Search Console or third-party tools do not guarantee a top position, since page experience is wider than these three metrics (Google Search Central, page experience).

Do Core Web Vitals decide rankings on their own?

Not on their own: Google aims to show the most relevant result even when its page experience is weak, so relevance comes first and Core Web Vitals sit beside it. Google lists Core Web Vitals alongside HTTPS, good display on mobile devices, restraint with ads, no intrusive interstitials and main content that is clearly separated from the rest. Apart from Core Web Vitals, Google says those other aspects bring no direct ranking gain, though they make a site more satisfying to use. A fast page with little substance still ranks below a slower page that answers the query well.

How do most websites score?

Under half of websites pass on phones: in June 2025, 48% of sites on mobile and 56% on desktop recorded a good overall Core Web Vitals result. These are worldwide figures from HTTP Archive's Web Almanac 2025, not Singapore figures. Singapore search data is tracked on Aemorph's AI search statistics for Singapore page.

Source: HTTP Archive, 2025

How Do You Improve Largest Contentful Paint (LCP)?

To bring LCP down, deliver the largest element on screen, usually the hero image or main heading, to the phone sooner: a faster server, an earlier download start, a smaller file and no code holding up the render. LCP considers images, poster images on videos, elements with a CSS background image and block-level elements containing text (web.dev, LCP).

What slows LCP down?

LCP has four parts, and whichever one runs longest shows you where to work: server response, the delay before the LCP file begins loading, the download time and the delay before it is painted. For a well-optimised page, Google's guide allocates roughly 40% of LCP to server response (time to first byte), under 10% to the load delay, roughly 40% to the download and under 10% to the render delay (web.dev, Optimise LCP). A long load delay generally means the browser spotted the image late, for instance because a script injects it or a stylesheet calls it.

How do you fix a slow LCP?

Tackle the four parts one by one: a faster response, early discovery of the LCP image, a smaller file and no render-blocking resources.

1. Reduce server response time. Serve pages through a content delivery network (CDN) with a node near your Singapore visitors and cache the HTML, so the first byte arrives sooner.
2. Never lazy-load the LCP image. Lazy loading postpones the very image LCP times. Reserve loading="lazy" for images lower on the page.
3. Raise the LCP image's priority. Set fetchpriority="high" on it, or preload it when it lives in a stylesheet, so its download starts with the HTML.
4. Render key content on the server. Content assembled by JavaScript in the browser paints later than content delivered in the HTML.
5. Compress the image. Serve WebP or AVIF sized to the layout. The Singapore image SEO guide explains formats and compression.

How Do You Improve Interaction to Next Paint (INP)?

INP falls when the main thread is free to show a visible reaction to each click, tap and key press within 200 milliseconds. INP tracks the interactions during a visit and reports the slowest, ignoring rare outliers on pages with many interactions (web.dev, INP).

What makes INP slow?

Each interaction runs through three phases, input delay, processing duration and presentation delay, and any slow phase raises INP. Input delay is the time before your event handler begins, often because another script is still running. Processing duration is the time the handler takes. Presentation delay is how long the browser spends on layout and painting the next frame, which lengthens on big or complex pages.

How do you fix a slow INP?

Divide long JavaScript tasks, keep event handlers minimal and keep the page structure compact.

1. Yield to the main thread often. Cut long tasks into smaller ones so the browser answers input in between; web.dev shows setTimeout as one way to yield (web.dev, Optimise INP).
2. Do less in each handler. Show the visitor the change first, then run analytics and other background work afterwards.
3. Keep the DOM small. A page with fewer elements lays out and paints more quickly after every interaction.
4. Delay off-screen rendering. The CSS property content-visibility allows the browser to skip rendering content outside the viewport until it is needed.
5. Avoid layout thrashing. Reading layout values right after changing styles makes the browser redo layout repeatedly; read first, then write.

How Do You Improve Cumulative Layout Shift (CLS)?

To cut CLS, reserve space for anything that loads late, so text and buttons stay exactly where the visitor first saw them. CLS groups shifts into session windows, each ending after a one-second gap or at five seconds in total, and reports the largest window. Shifts that happen within 500 milliseconds of the visitor's own input do not count, because the visitor expected them (web.dev, CLS).

What causes layout shifts?

Layout shifts mostly come from images, videos, ads, embeds and iframes without fixed dimensions, content pushed in above existing content, and web fonts that load at a different size from the fallback. Animations that alter an element's size or position also displace the content around them.

How do you fix CLS?

Reserve room for every late element and load fonts so text holds its position.

1. Declare width and height on images and videos, or set a CSS aspect-ratio, so the browser keeps the space free before the file arrives.
2. Reserve slots for ads, embeds and banners. Give each a fixed minimum height, and add new content beneath the visitor's reading position rather than on top of it.
3. Handle web fonts carefully. Preload key fonts, use font-display: optional where a late swap is not worth a shift, and apply size-adjust so the fallback font takes the same space.
4. Use transform animations. CSS transform moves an element without disturbing its neighbours.
5. Keep the back/forward cache available. web.dev lists back/forward cache eligibility among its CLS fixes (web.dev, Optimise CLS).

Which Other Performance Metrics Help You Diagnose Problems?

Time to First Byte (TTFB) and First Contentful Paint (FCP) help diagnose LCP, and Total Blocking Time (TBT) acts as INP's lab substitute; none of them is a Core Web Vital. Google labels these diagnostic metrics: they help you trace the cause of a poor Core Web Vitals result. Lighthouse, Google's lab tool, combines five metrics into a single performance score.

Lighthouse 10 performance score weights, from Chrome for Developers. Scores of 90 to 100 are good, 50 to 89 need improvement and 0 to 49 are poor.

Does a high Lighthouse score mean your page passes Core Web Vitals?

A strong Lighthouse score is not proof of a pass: Lighthouse measures one simulated load, whereas the Core Web Vitals assessment uses 28 days of real visits. Nobody clicks during a simulated load, so Lighthouse shows Total Blocking Time in place of INP. Treat Lighthouse as the tool for finding causes and the field data as the verdict.

Sources: Chrome for Developers and others

Which Tools Measure Core Web Vitals in Singapore?

For a Singapore site, five Google tools report Core Web Vitals: PageSpeed Insights, the Search Console Core Web Vitals report, Chrome DevTools, Lighthouse and the Chrome UX Report (CrUX). Field data reflects what real visitors experienced, while lab data is a controlled test you repeat as you fix.

Core Web Vitals tools compared.

How does the Search Console report group your pages?

Search Console clusters URLs that deliver a similar experience and gives each cluster the rating of its worst metric, so a single failing metric marks the cluster poor. A page short of its own data inherits the rating of its origin group. After fixing a group, press "Start Tracking" to start a 28-day validation (Search Console Help, Core Web Vitals report).

Why do field data and lab data disagree?

Field data records real Chrome visitors on their own devices and connections, and lab data records one simulated load, so the numbers rarely line up. CrUX draws only on Chrome users who opted in and leaves out Chrome on iOS, Android WebView and other Chromium browsers. A page also needs enough public traffic to appear in CrUX (Chrome for Developers, CrUX methodology). PageSpeed Insights' mobile lab test simulates a mid-tier phone (Moto G4) on a mobile network, so it reflects one device and one connection rather than the phones your Singapore visitors carry.

What happened to the Web Vitals Chrome extension?

Google ended support for the Web Vitals extension on 7 January 2025 and moved its features into the Chrome DevTools Performance panel. The real-time metrics view in that panel launched with Chrome 129 in September 2024 (Chrome for Developers blog). Any guide that still recommends the extension sends you to a tool without updates.

Sources: Google Search Console Help and others

Turn Core Web Vitals Into a Faster Singapore Site

Core Web Vitals improve fastest when you fix each problem in its page template and confirm it over 28 days of field data, since one template fix corrects every page that uses it. Open the Search Console report to find failing groups, use PageSpeed Insights and DevTools to pin down the cause, apply the fix and start validation. If you want an experienced team to handle this for your Singapore site, Aemorph's technical SEO service crawls the site, measures each template against Google's good thresholds and specifies every fix for your developers, who set the schedule.