Core Web Vitals on mobile in SEA, what to fix first
Mobile internet in Jakarta averages 62.54 Mbps. Singapore hits 142 Mbps. Your desktop Lighthouse score means nothing if real users on 4G can't load your LCP image.
You run PageSpeed Insights on your office laptop in Singapore. Lighthouse gives you a 95. Green across the board. You deploy, you move on.
Three weeks later Search Console shows 60% of your mobile URLs failing Core Web Vitals. LCP is 4.2 seconds. INP is 380 milliseconds. The pages that scored green in lab data are red in field data, and the field data is what Google uses for rankings.
The gap is not a bug in the tooling. The gap is Indonesia's mobile internet, which averages 62.54 Mbps and ranks 74th out of 101 countries . It is the difference between your fiber connection and the 4G tower your customer is using on a bus in Surabaya. A page passes Core Web Vitals when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less . In the audits I run for SMEs and Series A startups in Southeast Asia, mobile CWV scores are almost always worse than desktop, and if you only have time to optimize one version, do mobile first.
This post is the fix-priority framework I use when running technical audits for SMEs and Series A startups in Southeast Asia. It assumes you have one developer, maybe two, and you need to decide what moves the needle before the next funding round.
Why mobile failures cost more in this region
Over 60% of Google searches happen on mobile, and Google now uses mobile scores as the primary ranking signal, including for desktop results . That is true globally. In Southeast Asia the mobile-first reality is sharper.
Singapore's mobile internet averages 142 Mbps. Malaysia hits 93.65 Mbps. Indonesia sits at 62.54 Mbps. The Philippines is worse. If your hero image is 800 KB and your LCP element depends on three render-blocking scripts, your page will pass in Singapore and fail everywhere else in the region.
The Vodafone Italy case study gets cited everywhere, and the numbers hold. By running an A/B test specifically focused on optimizing Web Vitals, Vodafone found that a 31% improvement in LCP led to 8% more sales, a 15% improvement in their lead to visit rate, and a 11% improvement in their cart to visit rate . That test controlled for everything except speed. No design changes, no copy changes, just faster LCP.
The business case is clear. The question is what to fix when you cannot fix everything this quarter.
The fix-priority table for mobile in slower networks
I rank fixes by two variables. Impact on the metric in field conditions (not lab), and implementation cost for a small team. The table below is what I hand to clients after the audit.
| Metric | Fix | Impact (mobile, slower network) | Effort | Do this quarter |
|---|---|---|---|---|
| LCP | Preload LCP image with fetchpriority="high" | High | Low | Yes |
| LCP | Convert hero images to WebP or AVIF, resize to actual display dimensions | High | Low | Yes |
| LCP | Eliminate render-blocking CSS/JS above the fold | High | Medium | Yes |
| LCP | Reduce TTFB with server-side caching or CDN | Medium | Medium | If TTFB > 600ms |
| INP | Defer or async non-critical third-party scripts | High | Low | Yes |
| INP | Break up long JavaScript tasks (>50ms) | Medium | High | No, unless INP > 500ms |
| INP | Remove or lazy-load chat widgets, heatmaps, A/B tools until after interaction | High | Low | Yes |
| CLS | Set explicit width and height on images and embeds | High | Low | Yes |
| CLS | Reserve space for dynamic content (ads, carousels) with min-height | Medium | Low | Yes |
| CLS | Avoid inserting content above existing content after page load | High | Medium | Yes |
LCP is usually the first failure on mobile in this region. A 2 MB PNG hero image that looks fine on your MacBook takes 6 seconds to paint on a mid-range Android phone on a congested 4G tower in Jakarta.
Start with the LCP image. Preload it, compress it, serve it in a modern format. That trio of fixes costs you an afternoon and moves LCP from failing to passing on half your pages.
INP replaced First Input Delay in March 2024. INP is stricter because it measures responsiveness across the entire visit, not only the first interaction a user makes . The single biggest INP killer I see in SME audits is third-party scripts. Marketing adds a chat widget, then a Facebook pixel, then a heatmap tool, then an A/B testing SDK. Each one adds work to the main thread. Each third-party script adds weight and work to the main thread, and on average, third-party scripts account for 57% of JavaScript execution time on commercial sites .
Defer them. Load them after the page is interactive. If the script is not critical to first paint, it does not belong in the `<head>`.
CLS is the easiest to fix and the one founders ignore because layout shift feels minor. It is not. A button that moves 200 pixels down while the page loads means a click on "Buy Now" turns into a click on an ad or a footer link. Reserve space for every image, every embed, every dynamically injected element. Use explicit width and height attributes in your HTML. If you are loading an ad or a carousel, set a min-height so the container does not collapse and then expand.
What you measure and where you measure it
Google uses only CrUX field data for rankings, not Lighthouse lab data. Lab data is useful for diagnosis but it is not the score that matters. It is perfectly possible to score 100 in Lighthouse and still fail Core Web Vitals in CrUX if your real users have a worse experience than the simulated environment assumes .
Start with Google Search Console. The Core Web Vitals report shows you which URL groups are failing in field data. That is your prioritization input. Pick the group with the highest traffic or the highest conversion value.
Use PageSpeed Insights to diagnose individual URLs. The tool shows both CrUX field data (if available) and Lighthouse lab data. The field data is what you are fixing for. The lab data tells you why it is failing.
Test on a real device. Not the simulator. A $200 Android phone on a throttled 4G connection. If your LCP passes on that device, it will pass in CrUX.
Set up monthly monitoring. The Core Web Vitals report in Search Console surfaces issues as they appear in field data, and catching a regression early, before it compounds, is significantly easier than explaining a traffic drop after the fact . Add a recurring calendar task. Check the report. If a URL group that was passing is now failing, find out what changed. A new script, a heavier image, a plugin update. Roll it back or fix it.
Tools and the 28-day lag
CrUX data aggregates over a 28-day rolling window. If you fix LCP today, you will not see the improvement in Search Console for two to four weeks. That lag frustrates every founder I work with.
Use Real User Monitoring if you need faster feedback. Tools like SpeedCurve, Debugbear, or even a lightweight setup with the PerformanceObserver API will show you field data from your actual users within hours. You can segment by device, by country, by connection type. That granularity matters in Southeast Asia, where a page that passes in Singapore often fails in Jakarta.
RUM is not required to pass Core Web Vitals. Search Console and PageSpeed Insights are free and sufficient for the audit-fix-monitor loop. RUM is the upgrade you add when you are shipping frequently and you need to catch regressions before they hit the 28-day aggregate.
If you are running an agency retainer or managing a high-velocity product, instrument RUM. If you are a Series A founder with one part-time dev, stick with Search Console and fix the table above first.
When you cannot fix everything
You cannot. No SME I work with has the engineering budget to chase a perfect CWV score across every URL. The question is what gets you to passing on the pages that matter.
Traffic concentration helps. In the SME audits I run, 80% of organic traffic usually lands on 20% of URLs. Fix those 20%. Let the long tail sit in "needs improvement" until you have time or until those pages start driving revenue.
Conversion pages get priority over blog posts. A product page that fails LCP costs you sales. A blog post that fails LCP costs you a session that might have turned into a newsletter signup. Fix the product page first.
Mobile-first does not mean mobile-only. If your desktop traffic converts at 4x the rate of mobile, you still fix mobile, but you test the fix on both. Some optimizations (preloading images, deferring scripts) help both. Some (responsive image sizing) only help mobile. Do not break desktop to pass mobile.
The technical SEO post I published in May covers the broader stack (crawl budget, indexation, schema, hreflang). Core Web Vitals sit inside that stack. They are not the whole practice. Relevance and content quality still win the query. Core Web Vitals are part of Google's page experience signals and act as a meaningful tiebreaker between pages that are otherwise close in quality .
If you are launching AI search alongside organic search (and you should be), the same LCP and INP fixes that help you pass CWV also improve the experience for bot crawlers that render JavaScript. Faster TTFB, lighter JavaScript, stable layouts are not just ranking signals, they are retrieval signals. The consultancy work I do with Series A and Series B clients in Jakarta and Singapore treats AI visibility and SEO as one practice, and Core Web Vitals optimization is part of that shared foundation.
Fix LCP first, then INP, then CLS. Measure in field data, not lab. Test on the devices and networks your customers actually use.