On this page
- What are the Core Web Vitals thresholds?
- How are the thresholds measured?
- Why are the thresholds harder to meet on mobile networks in Tanzania?
- Where does the LCP time go?
- Which build choices pass?
- What does an LCP budget look like in milliseconds?
- What the NEMBO desk prepares
- Sources and status
- Frequently asked questions
What are the Core Web Vitals thresholds for a mobile website?
Google's good thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, each judged at the 75th percentile of page loads and segmented across mobile and desktop [1]. The slowest quarter of visits, not the average, decides whether a page passes.
A page that loads in 1.8 seconds on the developer's phone can still fail Core Web Vitals, because each threshold is applied to the visit at the 75th percentile, not to the average. In Tanzania a single site is opened on many networks and handsets, and the slowest quarter of visits sets the result. This note sets out the thresholds, how they are measured, why mobile conditions make them harder and the build choices that pass.
What are the Core Web Vitals thresholds?
Google publishes three good thresholds: Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less and Cumulative Layout Shift (CLS) of 0.1 or less 1. LCP above 4.0 seconds is poor 2, and so is INP above 500 milliseconds 5. Google states that it highly recommends good Core Web Vitals for success with Search 6.
| Metric | What it measures | Good threshold |
|---|---|---|
| LCP | Loading: when the largest visible element renders | 2.5 seconds or less |
| INP | Responsiveness to user input | 200 milliseconds or less |
| CLS | Visual stability while the page loads | 0.1 or less |
How are the thresholds measured?
Each metric is judged at the 75th percentile of page loads recorded in the field, segmented across mobile and desktop 15. The field source is the Chrome UX Report (CrUX), which reports a 28-day rolling average and separates phone, tablet and desktop 7. At the 75th percentile, at least 75 per cent of page loads were measured at or below the stated value 7.
Only some visits count. A user is aggregated in CrUX when usage statistic reporting and history sync are on, no sync passphrase is set and the platform is desktop Chrome or Chrome on Android 8. Because the window is 28 days, a fix reaches the field data gradually over that period.
Why are the thresholds harder to meet on mobile networks in Tanzania?
The slowest quarter of visits decides the result, and those visits come from the weakest connections and handsets. In March 2026 the Tanzania Communications Regulatory Authority reported population coverage of 94.32 per cent for 4G, 93.94 per cent for 3G and 32.83 per cent for 5G, with 111,795,302 mobile subscriptions 9. On those figures 67.17 per cent of the population sits outside 5G coverage (100 minus 32.83), so a page tuned for a fast connection is exposed to 4G and 3G visits.
Coverage is not throughput, so field data from CrUX is the measure of a site's real position. The build lesson is in the waiting, not the bytes: the median site with poor LCP spends almost four times as long waiting to start the image download as downloading it 4.
Where does the LCP time go?
LCP divides into four subparts that add up to the total: time to first byte (TTFB), resource load delay, resource load duration and element render delay 3. The web.dev guide gives approximate shares of about 40 per cent, under 10 per cent, about 40 per cent and under 10 per cent, and warns against turning them into millisecond targets 3.
| Subpart | Guide share | Median p75, good origins (ms) |
|---|---|---|
| TTFB | About 40% | 600 |
| Resource load delay | Under 10% | 350 |
| Resource load duration | About 40% | 160 |
| Element render delay | Under 10% | 230 |
The four medians sum to 1,340 milliseconds (600 + 350 + 160 + 230), an arithmetic total of separate medians, not a measured median LCP 4.
Which build choices pass?
- Make the LCP image discoverable in the initial HTML through src or srcset, and preload it if CSS or JavaScript is the only reference 3.
- Set fetchpriority high on the likely LCP image, on one or two images at most 3.
- Use a CDN, avoid redirects and avoid unique URL parameters that stop edge caching 3.
- Shrink render-blocking stylesheets, avoid synchronous scripts in the head and prerender so content does not wait on JavaScript 3.
- Break up long main-thread tasks so that input is handled quickly 3.
What does an LCP budget look like in milliseconds?
Source: web.dev, Web Vitals, 31 October 2024; web.dev, Common misconceptions about how to optimize LCP, 20 August 2024.
Note: illustrative figures for a fictional page. The last bar is an arithmetic sum of four separate medians. No financial statements are involved. Nothing here is an offer or a guarantee of a Core Web Vitals result or a ranking.
What the NEMBO desk prepares
The desk builds the site under the Build package, from TZS 3,500,000 or USD 4,500, with 50 per cent starting the work: up to nine pages in fifteen working days, bilingual in English and Kiswahili 10. Three performance gates apply, LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, on a throttled mobile profile, and a build that misses any of the three is not delivered 10.
The gate is a test profile, not field data, and CrUX needs its 28-day window to show the live result 7. Google Analytics and Search Console are verified before handover 10. The desk promises no ranking and no authority's decision.
A mobile site built to pass the three gates
The desk builds each page to LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 on a throttled mobile profile.
See the website deskSources and status
Accurate as at 17 October 2026. Every figure below was read at the source named, on the date shown.
- 1Web Vitalsweb.dev, 31 October 2024. Accessed 17 October 2026.
- 2Largest Contentful Paint (LCP)web.dev, 4 September 2025. Accessed 17 October 2026.
- 3Optimize Largest Contentful Paintweb.dev, 31 March 2025. Accessed 17 October 2026.
- 4Common misconceptions about how to optimize LCPweb.dev, 20 August 2024. Accessed 17 October 2026.
- 5Interaction to Next Paint (INP)web.dev, 2 September 2025. Accessed 17 October 2026.
- 6Understanding Core Web Vitals and Google search resultsGoogle Search Central, 10 December 2025. Accessed 17 October 2026.
- 7CrUX APIChrome for Developers, 13 October 2026. Accessed 17 October 2026.
- 8CrUX methodologyChrome for Developers, 20 June 2024. Accessed 17 October 2026.
- 9Communications Sector Performance Report for the quarter ending March 2026Tanzania Communications Regulatory Authority, Quarter ending March 2026. Accessed 17 October 2026.
- 10Build: a website with online payment, measured before handoverNEMBO, undated. Accessed 17 October 2026.
Figures to confirm before you act
- The current Core Web Vitals thresholds and definitions, with Google on web.dev and Search Central.
- The field results of the live site at the 75th percentile, in the CrUX report or Search Console, with Google.
- Network coverage and quality at the Client's main customer locations, with the mobile operator and the Tanzania Communications Regulatory Authority.
- The date of the post-launch field check, which falls 28 days or more after launch, in the written quote with NEMBO.
This article is general information based on official sources available at the date of publication. It is not legal, tax, valuation or financial advice. Laws and notices change. Verify with the issuing authority or consult Zatra Consultants Limited before acting.
Frequently asked questions
What are the Core Web Vitals thresholds?
Good values are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, each at the 75th percentile of page loads and segmented across mobile and desktop [1]. LCP above 4.0 seconds is poor, and so is INP above 500 milliseconds [2][5].
What does the 75th percentile mean for a page?
At least 75 per cent of page loads were measured at or below the stated value [7]. The average visit does not decide the result. The slowest quarter of visits must still meet the threshold, so a page needs margin on weak connections.
Where does the field data come from?
From the Chrome UX Report, a dataset of real Chrome users on desktop Chrome and Chrome on Android who have usage statistics and history sync on [8]. It reports a 28-day rolling average, with phone, tablet and desktop as separate form factors [7].
Does Google rank pages by Core Web Vitals?
Google states that it highly recommends good Core Web Vitals for success with Search and that page experience aligns with what its core ranking systems seek to reward [6]. It does not state that any score guarantees a position.
Which LCP subpart should be fixed first?
The one furthest from the guide's shares: about 40 per cent for TTFB, under 10 per cent for load delay, about 40 per cent for load duration and under 10 per cent for render delay [3]. The shares are guidelines, not millisecond targets.
Is a lab test enough to pass?
No. A throttled mobile profile tests the build before launch, but the threshold is applied to field data over a 28-day window [7]. The result is checked in Search Console or the CrUX report after launch.
