Core Web Vitals are the three numbers Google uses to judge whether your site is fast enough for real users on real phones on real networks. In 2026 the bar is LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured at the 75th percentile of field data. Singapore sites have an advantage. Local network conditions are excellent. And a disadvantage. The bar set by big local brands is brutal. This is the practical playbook we use to pass.
-
01
Field data, not lab data
Lighthouse scores lie. Field data from CrUX or RUM is the only honest signal. Tune for the real 75th percentile, not for a synthetic average.
-
02
INP is the new boss
LCP and CLS are solved by image and layout discipline. INP punishes JavaScript bloat. If your site has more than ten third-party scripts you are already in trouble.
-
03
Singapore is fast, so users expect fast
Local mobile networks deliver excellent throughput. That means your site is judged against DBS and SIA, not against a slow site in a slow market. The bar is high.
Why this matters for Singapore teams
Singapore audiences have unusual expectations on web performance because the local benchmark is unusually high. A typical user opens DBS Paylah, a Singapore Airlines flight search and a Shopee product page on the same morning, all of which are tuned to under 1.5 seconds on 4G. When that same user lands on your marketing site and waits four seconds for a hero image, the relative slowness is jarring. The conversion penalty is steeper here than it would be in markets where slow sites are the norm.
The network conditions add another wrinkle. Most Singapore mobile traffic runs on 4G or 5G with excellent throughput but uneven latency, particularly in MRT tunnels, basement carparks and certain heartland HDB clusters. That means optimising for bandwidth alone is not enough. You have to design for variable round-trip time, which means edge-caching at Singapore POPs, aggressive preloading and minimising chains of dependent network requests.
Singapore audiences also use older devices in surprising places. A 50-something heartland shopper might browse on a five-year-old Android, and a 70-something condo resident on a four-year-old iPad. INP is brutal on older hardware. A script that runs in 80 milliseconds on a Pixel 8 takes 350 milliseconds on a 2019 Android, which fails the INP threshold instantly. You need to budget for the device, not just the network.
Finally, Singapore SMEs increasingly compete with much larger brands for the same Google real estate. Core Web Vitals are not the dominant ranking signal, but at the margin. When two pages have equally good content and backlinks. The faster page wins. For SMEs competing with multinational brands in the same SERP, CWV is one of the few levers where a small team can outwork a big one.
A pass-by-default architecture
The fastest way to pass Core Web Vitals is to start from an architecture that passes by default, then keep it passing through discipline. Here is the spine we use on every SGBP build.
Image discipline
Every image is served in AVIF or WebP with a JPEG fallback, sized at the exact pixel dimensions the layout needs, with loading="lazy" for below-fold and fetchpriority="high" for the LCP candidate. The hero image is preloaded with a <link rel="preload"> tag in the head, and the source set lists three to four breakpoints, not eight. Image CDNs like Cloudflare Images, Cloudinary or Sanity Asset CDN handle the format negotiation. Do not let editors upload 4 MB PNGs from Figma exports. Configure the CMS to refuse them.
Font discipline
Fonts are the second-biggest LCP culprit after images. Self-host fonts on your own domain, use font-display: swap, preload the one or two weights you actually need above the fold, and subset to Latin if you are not serving Cyrillic or extended Chinese characters. Variable fonts (Inter Variable, Geist Variable) cut payload by 30 to 60% over multiple static weights.
JavaScript discipline
Audit every third-party script. If you cannot answer “what conversion or business decision depends on this?” in one sentence, kill it. Move analytics to Plausible (one request, no main-thread cost) or load GA4 through server-side tagging via sGTM. Defer or lazy-load chat widgets and personalisation tools until after first interaction. Use route-level code splitting so your homepage does not deliver the product configurator’s bundle.
Layout discipline
CLS is solved by setting explicit width and height on every image, video and iframe, and by avoiding any layout that depends on lazy content shifting the page. Ad slots, embedded videos and dynamic widgets all need reserved containers. The number one CLS cause we see in audits is a third-party banner ad or cookie consent layer that pushes content down two seconds after first paint.
- Hero image preloaded with fetchpriority high and AVIF or WebP format
- Self-hosted fonts subsetted and font-display swap set
- No third-party script loaded above-fold without a measured business justification
- All images and videos have explicit width and height attributes
- Critical CSS inlined for first paint, rest deferred
- Cookie consent layer uses fixed position or skeleton placeholder to avoid CLS
- Cloudflare or Vercel edge caching enabled with cache headers tuned per route
- Real-user monitoring (CrUX, Vercel Speed Insights, Plausible Web Vitals) live
Implementation walkthrough
A typical Core Web Vitals sprint at SGBP runs four weeks on an existing site. Here is the actual sequence.
Week one is field-data triage. We pull 28 days of CrUX data through PageSpeed Insights API, layer in real-user data from Vercel Speed Insights or Plausible, and segment by template (homepage, product page, category page, blog) and device class (mobile, tablet, desktop). The top three pages by traffic that fail on at least one CWV are the targets.
Week two is image and font work. We replace every hero image with a properly sized AVIF, fix the source sets, preload the LCP candidate and switch any blocking custom fonts to swap with preload. This alone typically takes LCP from 3.2 seconds to 1.6 seconds on mobile.
<!-- Hero image with proper preload -->
<link rel="preload"
as="image"
href="/hero-mobile.avif"
imagesrcset="/hero-mobile.avif 600w, /hero-tablet.avif 1024w, /hero-desktop.avif 1920w"
imagesizes="100vw"
fetchpriority="high">
<picture>
<source srcset="/hero-mobile.avif 600w, /hero-tablet.avif 1024w, /hero-desktop.avif 1920w"
sizes="100vw" type="image/avif">
<img src="/hero-fallback.jpg" alt="..." width="1920" height="1080" fetchpriority="high">
</picture>
Week three is JavaScript triage. We pull the network waterfall, identify every third-party script, score each on business value vs main-thread cost, and either remove, defer or move to server-side. The biggest INP wins in 2026 come from moving GA4 to sGTM, replacing Hotjar with a lighter alternative or deferring it, and lazy-loading the chat widget until first scroll or first interaction.
Week four is layout stability and validation. We audit every dynamic element for CLS, fix the cookie consent layer if it shifts content, then watch the field data for 14 days to confirm the 75th-percentile metrics have actually moved. CrUX updates monthly, so the headline ranking number takes a full month to reflect the fix.
-
01
Field-data triage
Pull CrUX, Vercel Speed Insights and real-user data. Segment by template and device. List the three worst pages.
Deliverable. CWV audit doc with prioritised fix list
-
02
Image and font sprint
Replace hero image formats, fix preload, subset and self-host fonts, set explicit dimensions.
Deliverable. LCP improvement of at least 30%
-
03
JavaScript triage
Score every third-party script, remove or defer, move analytics to server-side tagging.
Deliverable. INP improvement of at least 25%
-
04
Layout stability fixes
Audit dynamic elements, fix consent banner, reserve space for ads and embeds.
Deliverable. CLS under 0.1 at the 75th percentile
-
05
Validation and handover
Watch field data for 14 days, write the before-after report, hand over a CWV runbook.
Deliverable. Before-after report and ongoing runbook
Common mistakes
The most common Singapore mistake is chasing a 100/100 Lighthouse score in a lab while ignoring field data. Lighthouse runs in a synthetic environment that does not reflect a real Singapore user on a 3-year-old Android in the MRT. CrUX and real-user monitoring tell the truth. Aim for the field-data thresholds at the 75th percentile and forget about Lighthouse score perfection.
The second mistake is treating CWV as a one-off project. Performance regresses constantly as marketing adds widgets, scripts and embeds. Without a performance budget enforced in CI, your site will be slow again in three months. We deliver every project with a Lighthouse CI check on each pull request that fails the build if LCP regresses past a threshold.
The third mistake is over-optimising the homepage and ignoring product and blog pages. Your homepage is rarely your highest-traffic page. The product pages, blog posts and comparison pages people land on from Google are the ones that need to be fast. Audit those first, fix those first.
The fourth mistake is letting the marketing team install a tag manager without governance. GTM containers grow uncontrolled. Analytics, retargeting pixels, A/B test libraries, heatmaps, scroll trackers. And each one taxes INP. We treat the tag manager as code: every new tag goes through a pull request, has a business owner and a removal date.
- -42%Median LCP after a four-week SGBP CWV sprint
- -38%Median INP improvement after JS triage
- +18%Conversion lift after CWV pass (typical SG e-commerce)
- 28 daysCrUX field-data window
Tools we deliver in
- Lighthouse
- PageSpeed Insights
- CrUX
- Vercel Speed Insights
- Cloudflare
- Plausible
- WebPageTest
- Sentry
- GTmetrix
- Next.js
- Astro
- Image CDNs
What it costs in Singapore (and what SGBP charges)
A focused Core Web Vitals remediation. Three priority templates, image/font/JS/layout fixes, field-data validation, before-after report. Runs S$5,000 to S$15,000 at most Singapore agencies. SGBP delivers the same scope at S$2,500 to S$6,000 because we run it as a productised four-week sprint with a fixed checklist and a defined deliverable.
Frequently asked questions
What are the Core Web Vitals targets in 2026?
The three Core Web Vitals are LCP, INP and CLS. To pass, you need LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, measured at the 75th percentile of real users over 28 days. INP replaced FID in March 2024 and is by far the hardest of the three to pass on JavaScript-heavy sites.
Do Core Web Vitals affect SEO rankings?
Yes, but as a tiebreaker rather than a primary ranking factor. Google uses Core Web Vitals as part of its page experience signals, alongside HTTPS and mobile-friendliness. The bigger effect is on conversion: a site that loads in 1.2 seconds converts roughly 15 to 25% better than one that loads in 3.5 seconds. So Core Web Vitals matter for the funnel even when SEO is neutral.
What is INP and why is it hard?
INP. Interaction to Next Paint. Measures the latency between a user tap or click and the next frame the browser paints. It penalises long JavaScript tasks that block the main thread. INP is hard because most marketing sites carry analytics, chat widgets, cookie consent, A/B test libraries and CMS preview scripts that all hog the main thread. Cutting INP requires triage of every third-party script.
How long does a Core Web Vitals fix project take?
A focused CWV remediation on an existing site typically takes two to four weeks. Week one is field-data analysis and the fix plan. Weeks two and three are image, font, JavaScript and CSS work. Week four is real-user measurement validation through CrUX or RUM. SGBP runs a fixed-scope CWV sprint for S$2,500 to S$6,000 with a written before-after report.
Is a 100/100 Lighthouse score worth chasing?
No. Field data from real users (CrUX, RUM) is what matters, not the Lighthouse lab score. Aim for the 75th-percentile pass thresholds in real user data: LCP under 2.5s, INP under 200ms, CLS under 0.1. A 95/100 Lighthouse with passing field data is fine. Chasing 100/100 Lighthouse usually means stripping legitimate functionality for no field-data gain.
If your Core Web Vitals are red in Search Console and you want the field data green inside four weeks, message us on WhatsApp or book a call. We run a fixed-scope sprint with a written before-after report and a runbook that keeps the gains.
