Core Web Vitals & page speed
Core Web Vitals measure real-world loading (LCP), responsiveness (INP) and visual stability (CLS). Good is LCP ≤2.5s, INP ≤200ms and CLS ≤0.1, assessed at the 75th percentile of real visits. They matter most on Nepal's mobile networks, where slow pages lose visitors before ranking matters.
Core Web Vitals are Google's attempt to measure what a page actually feels like to use, from real visits rather than a lab simulation. They form part of Google's page experience signals.
For a Nepali site they deserve more attention than they get internationally, for a straightforward reason: your median visitor is on a phone on mobile data. A page that scores well in a lab test on a fast desktop connection can still be losing most of its real audience.
The three metrics and their thresholds
Each metric has a 'good', 'needs improvement' and 'poor' band. Critically, you are assessed at the 75th percentile of real page loads — meaning 75% of visits must hit the good threshold, so you cannot pass by optimising for your own fast device.
- LCP — Largest Contentful Paint: how long until the largest visible element renders. Good ≤2.5s, poor >4.0s.
- INP — Interaction to Next Paint: how quickly the page responds visually to user interactions across the whole visit. Good ≤200ms, poor >500ms. INP replaced First Input Delay as the responsiveness metric in 2024.
- CLS — Cumulative Layout Shift: how much visible content moves unexpectedly. Good ≤0.1, poor >0.25. It is a unitless score, not a time.
- Measured separately for mobile and desktop. Mobile is usually the harder and more important one.
Improving LCP
LCP is almost always either a large image or a slow server. Diagnose which before optimising, because the fixes are entirely different.
- Identify the LCP element first — PageSpeed Insights names it. Optimising anything else is wasted work.
- If it is an image: compress it, serve WebP or AVIF, size it correctly for the viewport, and preload it.
- Never lazy-load the LCP image. This is a common own-goal — lazy loading is right for below-the-fold images and actively harmful for the hero.
- Reduce server response time (TTFB): cache, use a CDN, and avoid slow database calls on the critical path.
- Eliminate render-blocking CSS and JavaScript in the head; inline critical CSS and defer the rest.
- Self-host fonts or preconnect to the font host, and use font-display: swap so text renders immediately.
Improving INP
INP is a JavaScript problem in nearly every case. It measures the delay between a user interacting and the browser painting the visual response, across all interactions in a visit — so a single janky menu can sink the score.
- Cut the amount of JavaScript. The cheapest long task is the one you never ship.
- Break up long tasks: anything holding the main thread over 50ms blocks interaction. Yield to the main thread between chunks of work.
- Move heavy computation off the main thread with a web worker.
- Defer non-essential third-party scripts — analytics, chat widgets, ad tags and tag managers are habitual offenders.
- Render the visual feedback for an interaction before doing the heavy work behind it, so the page feels responsive.
- Avoid large, expensive re-renders in response to simple interactions.
Improving CLS
CLS is the easiest of the three to fix and the most irritating to users — it is what causes you to tap the wrong thing because the page jumped.
- Always set width and height attributes (or CSS aspect-ratio) on images, videos and iframes so the browser reserves the space.
- Reserve space for ads, embeds and anything injected after load. Never let content insert above existing content.
- Avoid inserting banners, cookie notices or promotional bars above content that has already rendered.
- Preload fonts and use font-display: swap with a well-matched fallback so the swap does not reflow the layout.
- Use CSS transforms for animation rather than animating properties that trigger layout.
Field data versus lab data
This distinction causes a lot of confusion. Lab data comes from a simulated load on a standardised device — reproducible, useful for debugging, and not what you are assessed on. Field data comes from real Chrome users and is what Core Web Vitals assessment actually uses, via the Chrome UX Report.
A page can score 100 in a lab test and still fail Core Web Vitals, because real users are on slower devices and networks than the test simulates. That gap is particularly wide for Nepali audiences.
Field data is aggregated over a rolling window, so improvements take weeks to appear in your assessment. Do not conclude a fix failed because the report did not move overnight.
- PageSpeed Insights — shows both field and lab data for a URL.
- Search Console Core Web Vitals report — field data grouped across your whole site. This is the one to act on.
- Chrome DevTools Lighthouse and the Performance panel — for debugging individual problems.
- Chrome UX Report — the underlying field dataset.
How much this actually affects rankings
Honestly: it is a real but modest signal, and it will not rescue a page that does not deserve to rank. Google has been consistent that great page experience does not outrank genuinely more relevant content.
The reason to care anyway is the business case, not the ranking case. On a slow mobile connection, a heavy page loses visitors before any ranking factor applies — they leave. Speed improvements typically show up in engagement and conversion well before they show up in position.
So treat Core Web Vitals as a user-experience project with an SEO side effect, and prioritise it accordingly on a mobile-first market like Nepal.
Key takeaways
- ✓Good is LCP ≤2.5s, INP ≤200ms, CLS ≤0.1 — assessed at the 75th percentile of real visits.
- ✓LCP is usually a big image or slow server; identify the actual LCP element before optimising anything.
- ✓Never lazy-load the hero image — it is the most common self-inflicted LCP failure.
- ✓INP is a JavaScript problem: ship less, break up long tasks, defer third-party scripts.
- ✓You are assessed on field data from real users, not lab scores — and it updates over weeks, not overnight.
Explore the data behind this guide
Core Web Vitals & Page Speed — FAQ
What are Core Web Vitals?+
Three metrics measuring real-world page experience: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). They form part of Google's page experience signals and are assessed from real Chrome user data.
What is a good LCP, INP and CLS score?+
Good is LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Poor is LCP above 4 seconds, INP above 500 milliseconds and CLS above 0.25. Assessment uses the 75th percentile of real page loads, separately for mobile and desktop.
What replaced First Input Delay?+
Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness Core Web Vital in 2024. INP is stricter because it measures responsiveness across all interactions during a visit rather than only the first one.
Why does my Lighthouse score say 100 but Core Web Vitals fail?+
Lighthouse is lab data from a simulated load; Core Web Vitals assessment uses field data from real Chrome users on real devices and networks, which are slower than the simulation. The gap is especially wide for audiences on mobile data, as in Nepal.
How long do Core Web Vitals take to improve after a fix?+
Field data is aggregated over a rolling window, so expect weeks rather than days before an improvement is reflected in Search Console. A fix that does not move the report overnight has not failed.
Do Core Web Vitals really affect rankings?+
They are a genuine but modest signal, and Google has been clear that page experience does not outrank more relevant content. The stronger argument is commercial: on a slow mobile connection a heavy page loses visitors outright, which shows up in engagement and conversion before rankings.
Related guides
Sources & data note
This guide describes documented, widely-accepted practice as published by Google Search Central, web.dev and schema.org, which are cited above. Search and AI systems change continually: treat specific thresholds and crawler names as current guidance and verify against the official documentation before relying on them. Nepal-specific observations — market conditions, Devanagari search behaviour, what local competitors do — are our own analysis rather than published findings, and are not separately sourced. Guides are written from primary sources — Nepali government departments, operators, park authorities and standards bodies — and each guide lists the sources used for its own facts. Rules, fees and prices in Nepal change; treat figures as current at the review date shown on each guide and verify anything money- or visa-critical with the issuing authority before you rely on it.
- Core Web Vitals — thresholds and definitionsGoogle / web.dev ↗
- Largest Contentful Paint (LCP)Google / web.dev ↗
- Interaction to Next Paint (INP)Google / web.dev ↗
- Cumulative Layout Shift (CLS)Google / web.dev ↗
- PageSpeed InsightsGoogle ↗
- Chrome UX Report (field data behind Core Web Vitals)Google ↗
- Google Search Central — page experience and Core Web VitalsGoogle ↗