Website performance and Core Web Vitals basics

A page can have the best content on the web and still lose visitors if it takes too long to appear, ignores taps or jumps around while loading. Google measures these experiences with a set of metrics called Core Web Vitals and uses them as part of how it understands page experience. This lesson explains what they measure, how they are measured and what usually fixes them.

The three Core Web Vitals

Each Core Web Vital captures one part of what a visitor feels.

A page passes when it meets the "good" threshold for all three at the 75th percentile of visits. That means three in four visits must have a good experience, which keeps the target meaningful for visitors on slower phones and networks.

INP replaced an older metric, First Input Delay, in 2024. FID only measured the delay before the first interaction was handled; INP measures responsiveness across all interactions during a visit, which reflects real use far better.

Lab data and field data

There are two ways to measure performance, and they often disagree.

Field data comes from real visitors. Google collects it from Chrome users who have opted in, in the Chrome User Experience Report, and it is what Search Console's Core Web Vitals report and the top of PageSpeed Insights show. It reflects real devices, networks and behaviour, and it is the data Google's systems use.

Lab data comes from a test run in a controlled environment, such as Lighthouse. It is repeatable and great for debugging, but it simulates one device on one connection and does not interact with the page the way people do.

PageSpeed Insights shows both on one screen: field data for the URL or origin at the top, and a Lighthouse lab run below.

What usually fixes each metric

LCP is mostly about getting the main content to the screen fast. A slow server response delays everything, because nothing can render until the HTML arrives. After that, the LCP element itself must be found and fetched early: use a normal <img> in the HTML for the hero image, serve it at the right size in an efficient format, do not lazy-load it, and consider fetchpriority="high". Render-blocking CSS and JavaScript in the head also delay it.

INP is mostly about JavaScript. When a visitor taps a button, the browser has to run the event handler and repaint the screen. If the main thread is busy with a long JavaScript task, the response waits. Breaking long tasks into smaller ones, removing unnecessary scripts (third-party tags are frequent culprits) and doing less work in each interaction all help.

CLS is mostly about reserving space. Images and videos without width and height, ads and embeds inserted above content without a reserved slot, and web fonts that swap and change text size all cause content to jump. Give media dimensions, reserve space for late-loading elements and avoid inserting content above what the visitor is reading.

How much performance matters for rankings

Google's guidance is balanced on this. Page experience signals, including Core Web Vitals, are part of what its ranking systems consider, but relevance and helpful content come first. A slow page with the best answer can still outrank a fast page with a weak one. Performance matters most when several pages are similarly relevant and useful, and it always matters for visitors, who leave slow pages whatever their rankings.

Mobile first

Google mainly uses the mobile version of a site for indexing and ranking, and most visitors on many sites use phones on variable networks. Test and fix performance on mobile first. A page that is fast on an office desktop can be painfully slow on a mid-range phone over a mobile connection.