Core Web Vitals in plain terms: the speed users actually feel

Site speed isn't a number. It is a feeling. A user doesn't know the page loaded in so many milliseconds, but they do feel "that was fast" or "that was slow". Core Web Vitals are Google's attempt to measure that feeling with three metrics.

They influence search ranking too, but the main reason to care is the user.

The three metrics

LCP: how long until the main content appears

When does the largest visible element — usually the hero image or main heading — render? That is the moment the page feels like it has arrived.

Google's target: under 2.5 seconds.

INP: how quickly the page responds to me

When a user clicks or taps, how long before the page reacts? It is measured across the whole visit, not only at the start.

Google's target: under 200 milliseconds.

CLS: does the page move under my finger

You go to tap a button, an image loads, everything shifts down and you tap something else. CLS measures those unexpected shifts.

Google's target: under 0.1.

Improving LCP

• Make the main image lighter. Modern formats such as WebP and AVIF cut file size substantially.
• Send the right size. A two-thousand-pixel image for a phone four hundred pixels wide is waste.
• Prioritise the main image and keep lazy loading for images further down.
• Speed up the server response. If the server is slow, no other optimisation makes up for it.
• Load fonts properly. Host them yourself and don't leave text invisible while the font arrives.
• Render content on the server. A page that has content without running JavaScript appears sooner.

Improving INP

The culprit is almost always too much JavaScript.

• Ship less code. Every library you add runs on your user's weakest phone.
• Make interactive only what needs to be. The whole page needn't come alive in the browser — only the interactive parts.
• Break up heavy work so the browser can respond to the user in between.
• Review third-party scripts. Analytics, chat and ad tools are often the largest load.

On this site, decorative motion is driven by one small shared script and attributes in the HTML, so page components don't have to be rebuilt in the browser.

Improving CLS

• Set dimensions on images and video so the browser reserves the space.
• Reserve room for late content: banners, ads, notices.
• Don't insert content above existing content.
• Animate only transform and opacity. Animating size and position disturbs layout.
• Choose a fallback font with matching metrics so text doesn't jump when the real font arrives.

Where to measure

There are two kinds of data, and the difference matters:

Lab data. A tool such as Lighthouse measures the page under simulated conditions. Good for finding problems and testing changes.

Field data. The experience of real users on real devices and connections. This is what Google uses for ranking, and it appears in Search Console.

A performance budget

Speed erodes over time: a library here, a large image there. The way to keep it is to set limits and check them automatically:

• The home page's JavaScript must not exceed a set size.
• LCP in automated tests must not rise above a set value.

If a change breaks the limit, it stops before release. That is the quality gate logic again.

For users in Iran

A few points matter more in the Iranian market:

• Host resources yourself. A font or library served from abroad may be slow or unavailable.
• Take file size seriously. Mobile data isn't always fast or cheap.
• Design for an unstable network. A PWA with sensible caching stays usable on a weak connection.

The takeaway

Speed isn't a one-off project. It is a habit: light images, little JavaScript, stable layout and limits checked automatically. The result is better for users and better for being found in search.

Related: being visible in AI answers.