Core Web Vitals are Google's ranking signals for page experience: three metrics that together measure how a real user experiences page load, interactivity, and visual stability. Sites that pass CWV consistently outrank sites that fail, with the gap widening on competitive queries where ranking margins are thin. The conceptual framework is well-documented in Core Web Vitals explained; this piece is the applied Thai-market companion that covers what changes when the audience is on 4G rather than fast WiFi.
The three metrics in 2026
Largest Contentful Paint (LCP) measures how long after the user clicks a link the largest visible element finishes rendering. Usually the hero image, headline, or above-the-fold media block. Good threshold: under 2.5 seconds at the 75th percentile of real users. Needs improvement: 2.5 to 4 seconds. Poor: over 4 seconds. LCP is the metric most commonly failed by Thai sites because hero images served at full desktop resolution to 4G connections produce LCP values in the 4 to 8 second range.
Interaction to Next Paint (INP) measures how long after a user interaction (click, tap, keypress) the page visibly responds. INP replaced First Input Delay (FID) as the responsiveness metric in March 2024 because it captures the full interaction-to-response cycle rather than only the initial delay. Good threshold: under 200 ms. Needs improvement: 200 to 500 ms. Poor: over 500 ms. INP failure on Thai sites typically traces to JavaScript-heavy interaction handlers, particularly from social media embeds, chat widgets (LINE chat plugins are a common offender), and analytics scripts loading synchronously.
Cumulative Layout Shift (CLS) measures how much visible content moves around unexpectedly during page load. Caused by images without dimensions, late-loading fonts, banner ads that push content down, or DOM injections that shift the layout. Good threshold: under 0.1. Needs improvement: 0.1 to 0.25. Poor: over 0.25. CLS failure on Thai sites typically comes from social media embeds and ad units that load asynchronously and shift content as they arrive.
To pass CWV overall, a site has to hit the good threshold on all three metrics at the 75th percentile of real-user measurements (field data from Chrome's Crux dataset). Hitting two out of three is not passing. The 75th-percentile requirement means the metrics measure not the median experience but the worse-than-median experience, which is exactly the segment most affected by Thai network variability.
Why Thai network conditions make CWV harder
The Thai mobile network mix is the structural reason CWV optimisation calibrated for Western markets underperforms locally.
The 4G majority sits at variable signal quality. Bangkok-central 4G runs at speeds comparable to mid-tier US connections; provincial 4G runs closer to what US users experienced on 3G a decade ago. The same physical handset connects to both qualities depending on tower distance, building density, and concurrent load. CWV measurement at the 75th percentile catches the weaker signal areas, not the strong ones.
The 5G urban concentrate looks fast in synthetic tests but represents only about 25 percent of the actual audience. A site optimised against 5G testing harnesses passes the dev-team benchmark while failing real-user field data because the field data is dominated by the 4G majority.
The 3G rural minority is still meaningfully present. Eight percent is not the headline number but it is the bottom of the 75th-percentile distribution. Sites that ignore 3G performance entirely watch their CWV scores drop because the long tail of slow connections drags the percentile downward.
The home WiFi share is genuinely tiny because Thai browsing happens overwhelmingly on mobile. The site can be blazing fast on a 100 Mbit Bangkok home WiFi connection and still fail CWV if the mobile experience is poor. Designing for the WiFi case while neglecting mobile is the most common architectural mistake in Thai-market sites.
The implication for performance budgets
Standard Western performance budgets assume better network conditions than Thai sites actually face. The practical adjustment.
Image weight budget. Western performance guidance often allows 200 to 500 KB above-the-fold image weight. Thai-market sites need to be tighter: 100 to 200 KB for the above-the-fold image budget produces materially better LCP outcomes on 4G connections.
JavaScript execution budget. Western guidance often allows 200 to 300 KB of JavaScript bundled into the initial load. Thai sites need this under 150 KB to reliably pass INP at the 75th percentile, particularly because mobile CPU throttling on mid-range Thai handsets compounds the JavaScript parse-and-execute cost.
Third-party script budget. Western sites often run six to eight third-party scripts (analytics, ads, social embeds, chat, tracking pixels). Thai sites should aim for three to four because the network round-trip overhead for additional third-parties compounds against the 4G connection budget.
Font budget. Western practice often loads four to six font weights and styles. Thai sites should typically load two to three to avoid font flash and font-related layout shifts. Subset fonts to Thai + Latin characters when serving bilingual content.
How to audit LCP for Thai-network reality
The standard PageSpeed Insights tool runs the audit on a simulated Moto G4 with a throttled 4G connection. That is a reasonable approximation of Thai conditions but on the optimistic side. A more accurate audit approach combines three measurement layers.
PageSpeed Insights field data (the Crux dataset) gives the 28-day rolling real-user measurement for sites with enough traffic to qualify. This is the most accurate Thai-user data available for established sites and should be the primary reference point.
WebPageTest configured with a Bangkok or other Thai test location and a throttled 4G connection profile produces the most accurate synthetic test of Thai-network conditions. The free tier allows enough runs to baseline current state and verify improvements.
Real User Monitoring (RUM) tools (Sentry, New Relic, DataDog RUM) installed on the production site capture the actual user-experience distribution including the geographic spread, device mix, and network type breakdown. RUM data is the most authoritative source for performance work because it measures the actual users you serve rather than synthetic substitutes.
The improvement levers for LCP are well-established and not Thai-specific: serve appropriately-sized responsive images, use modern formats (WebP and AVIF with JPEG fallback), preload the LCP image, eliminate render-blocking resources before the LCP element, and reduce server response time. The Thai-specific calibration is the budget that produces good LCP on 4G connections, not the levers themselves.
How to audit and improve INP
INP measurement requires real-user data because the metric depends on which interactions a user actually performs. PageSpeed Insights field data shows INP for sites with sufficient traffic; for sites below the Crux threshold, RUM data is the only reliable source.
The improvement levers for INP on Thai sites concentrate on JavaScript execution and third-party script management.
Defer non-critical JavaScript out of the initial load. Analytics, tracking pixels, retargeting scripts, and most third-party widgets can load after the user has interacted with the page rather than blocking the initial parse-and-execute.
Use async or defer attributes on third-party script tags so they do not block HTML parsing. Most third-party providers support both but use synchronous loading by default in their default install snippets.
Audit social media embeds carefully. Facebook, Twitter, Instagram, and LINE chat embeds are common Thai-site additions and consistently among the worst INP offenders. Replace embedded widgets with lighter alternatives (linked images for social posts, click-to-load chat triggers for LINE) where possible.
Break up long-running JavaScript tasks. Functions that take more than 50 ms to execute block the main thread and produce INP failures. Profile main-thread work with Chrome DevTools Performance tab and split functions that exceed the 50 ms threshold.
How to audit and improve CLS
CLS measurement is well-supported in PageSpeed Insights field data and lab tests. The metric is more predictable than LCP or INP because layout shifts are deterministic for a given page rather than depending on connection variability.
The improvement levers are simpler than for LCP or INP.
Specify explicit dimensions on all images, videos, and iframes. Width and height attributes (or aspect-ratio CSS) reserve the layout space before the media loads, eliminating the shift when it arrives.
Preload critical fonts and use font-display: swap or font-display: optional rather than the default font-display: auto. This prevents the layout shift that happens when a fallback font is swapped for the loaded font.
Reserve space for ad units and embedded widgets that load asynchronously. A min-height container that approximately matches the expected ad dimensions prevents the layout shift when the ad eventually loads.
Audit for late-loading DOM injections from third-party scripts. Some analytics and personalisation scripts inject elements into the DOM after page load which causes CLS failures. The audit shows these injections as layout shift events at specific timestamps in the page lifecycle.
Common Thai-site Core Web Vital failure modes
- Desktop-resolution hero images served to mobile. The single most common LCP failure. Fix with responsive images and proper sizing.
- Embedded LINE chat widgets blocking initial render. Common Thai-site addition that consistently fails INP. Replace with click-to-load triggers.
- Multiple Facebook embed widgets per page. Each widget adds 200-400 ms to interaction handling. Use linked images instead.
- Synchronously-loaded analytics tag managers. GTM loaded synchronously rather than async blocks the entire interaction handling layer.
- Web fonts without font-display swap. Default font-display auto produces CLS as fonts load and replace fallbacks.
- Images without explicit dimensions. Reserve layout space with width/height attributes or aspect-ratio CSS.
- Third-party ad units without reserved containers. Ads loading async into unreserved space cause CLS.
- Heavy JavaScript frameworks for content sites. A Next.js SPA for a content-marketing site usually has worse CWV than a static HTML build of the same site.
- Optimising against synthetic tests rather than field data. Synthetic tests on fast connections pass while real Thai users experience slow loads.
- No mobile performance budget. The team optimises desktop performance and assumes mobile follows, when actually the mobile profile is the binding constraint.
The honest version of CWV for Thai sites
Core Web Vitals optimisation done well on Thai-market sites requires calibrating against the 4G majority that actually visits, not against the WiFi conditions that developers test on. The work is not technically harder than equivalent CWV work in Western markets, but it requires more conservative performance budgets and stricter discipline around third-party scripts and media weight. Sites that take this seriously consistently outperform competitors who ship Western-calibrated optimisation; sites that do not under-perform their search potential without an obvious cause, often for years. The wider Thai SEO market context that explains why this matters more in 2026 than in previous years is in the state of Thai SEO in 2026.
Our technical SEO work for Thai clients includes Core Web Vitals audits calibrated to the local network reality plus performance budget definitions that account for the actual 4G majority audience. The integrated SEO marketing agency programme treats performance work as a foundational layer rather than an afterthought. The technical depth that this rests on runs through our technical SEO service. For sites where the performance work is part of a wider rebuild, the SEO Bangkok engagement typically combines the technical audit with the content and architecture work that pays off alongside it. A discovery conversation with our Bangkok SEO consultancy typically begins with a baseline CWV audit against the Thai user base to identify whether the current performance is the binding constraint on rankings.
Common questions
Why do Thai sites typically fail Core Web Vitals?
Three structural reasons. Thai mobile network conditions are slower and more variable than the conditions used in many CWV testing setups, so sites optimised against typical testing harnesses pass synthetic tests while failing real-user field measurements. Thai sites tend to carry heavier media assets (large hero images, video backgrounds, embedded social widgets) that compound the network disadvantage. The optimisation work itself tends to be calibrated for fast-network markets and produces worse results on slower Thai networks.
What are the Core Web Vitals thresholds in 2026?
LCP good under 2.5 seconds, needs improvement 2.5 to 4 seconds, poor over 4 seconds. INP (which replaced FID in March 2024) good under 200 ms, needs improvement 200 to 500 ms, poor over 500 ms. CLS good under 0.1, needs improvement 0.1 to 0.25, poor over 0.25. To pass overall, a site needs to hit the good threshold on all three metrics at the 75th percentile of real-user measurements.
What does the Thai mobile network mix look like?
Approximately 65 percent of Thai users browse on 4G connections at variable signal quality. Approximately 25 percent are on 5G, concentrated in Bangkok and major urban centres. Approximately 8 percent are still on 3G, particularly in rural and remote provinces. Approximately 2 percent are on home WiFi at any given moment. The 65 percent 4G majority is the audience that Core Web Vitals optimisation must serve.
What is the most common Thai-site Core Web Vitals failure mode?
Large hero images causing LCP failure is the single most common pattern. Thai sites often use hero images at full desktop resolution served to mobile devices on 4G connections, producing LCP values of 4 to 8 seconds where the threshold for good is 2.5 seconds. The fix is responsive images at appropriate resolutions, modern image formats like WebP or AVIF, and proper image sizing with lazy loading.
