Core Web Vitals explained in plain language

If you have ever run your website through a speed test, you have probably seen three cryptic abbreviations: LCP, INP and CLS. They are the Core Web Vitals, a set of measurements Google uses to describe how a page feels to a real visitor. They sound technical, but each one maps to something you already understand from experience: how long you wait to see the page, how quickly it responds when you tap, and whether things jump around while you are trying to read.

This guide translates the jargon into plain language, explains what good scores look like and walks through practical fixes you can apply or hand to a developer. You do not need to become a performance engineer to make a real difference.

Why page experience matters

A slow or jumpy website costs you in three ways. First, visitors leave. People rarely wait patiently for a business they do not yet trust, especially on a phone. Second, those who stay are less likely to contact or buy, because friction erodes confidence. Third, Google considers page experience as one signal among many when ranking results, so a poor experience can hold back your visibility, particularly when competitors are otherwise equal.

It helps to keep perspective. Great content and relevance still matter most; Core Web Vitals will not rescue a page that does not answer the question. But when two pages are comparable, the faster, more stable one tends to win both the ranking and the customer.

The three metrics

Largest Contentful Paint (LCP): how fast does the main content appear?

LCP measures how long it takes for the biggest visible element, usually a hero image, a large heading or a block of text, to render. In everyday terms, it answers: how long until the page looks mostly loaded?

Google’s guidance treats an LCP of 2.5 seconds or less as good, between 2.5 and 4 seconds as needing improvement and over 4 seconds as poor. These are measured at the 75th percentile of real visits, meaning most of your visitors should meet the target, not just the lucky ones.

Interaction to Next Paint (INP): how quickly does the page respond?

INP replaced an older metric called First Input Delay in 2024. It measures how long the page takes to visibly respond after a user interacts, whether by tapping a menu, pressing a button or typing in a field. It looks at interactions across the whole visit, not only the first one.

A good INP is 200 milliseconds or less. Between 200 and 500 needs improvement, and above 500 is poor. In practice, bad INP feels like tapping a button and wondering whether it registered. It is usually caused by heavy JavaScript hogging the browser.

Cumulative Layout Shift (CLS): does the page stay still?

CLS measures unexpected movement of content as the page loads. You know the experience: you go to tap a link, an image loads above it, the page jumps and you tap the wrong thing. CLS scores the total amount of such shifting.

A good CLS is 0.1 or less. Between 0.1 and 0.25 needs improvement, and above 0.25 is poor. It is a unitless score rather than a time, calculated from how much of the screen moved and how far.

Lab data versus field data

When you test a page, you will see two kinds of numbers. Lab data comes from a simulated test run under fixed conditions, such as in Lighthouse. It is repeatable and great for debugging, but it is only a model. Field data comes from real users visiting your site over the previous weeks, collected in Chrome’s user experience reports. It reflects actual devices and networks and is what Google uses for ranking signals.

Small or new sites may lack enough traffic to have field data. In that case, rely on lab tests to find problems and treat the thresholds as targets. Where field data exists, trust it as the final judge, and remember that improvements take a few weeks to appear in it.

How to measure your own site

You can get a useful picture in minutes with free tools.

1. PageSpeed Insights. Enter your URL and read the mobile results first. It shows field data if available, then lab data and specific opportunities.
2. Google Search Console. If your site is verified, the Core Web Vitals report groups URLs by status and shows which templates have problems.
3. Lighthouse in Chrome DevTools. Useful for developers testing changes before launch.
4. A real phone on a normal connection. Numbers matter, but so does how the page feels.

Test several key pages, not just the homepage: a service page, a blog post and the contact page. Different templates have different problems.

Fixing LCP

Slow LCP is the most common issue on small business sites, and the usual culprit is the hero image.

Resize and compress images. Many sites upload a photo straight from a camera or phone, several megabytes in size, and display it at a fraction of that dimension. Serve images at the size they appear, compressed, in a modern format like WebP or AVIF.

Do not lazy-load the main image. Lazy loading is great for images below the fold, but the hero image should load immediately and ideally be prioritized so the browser fetches it first.

Improve server response. Slow hosting delays everything. A good host, caching and a content delivery network, which serves files from locations near your visitors, can cut time significantly. Static or pre-rendered pages are generally fastest.

Reduce render-blocking resources. Large stylesheets and scripts loaded in the page head can delay display. Inline critical styles, defer non-essential scripts and trim unused code.

Preload important assets. Fonts and hero images can be preloaded so the browser starts fetching them early.

Simplify the top of the page. Autoplaying video, carousels and complex animations at the top of the page often slow LCP. A static image or plain heading is faster and often clearer.

Fixing INP

INP problems come from the browser being busy when the user acts. They are typically a JavaScript issue.

Remove unnecessary scripts. Every chat widget, tracker, pop-up tool and plugin adds code that competes for the browser’s attention. Audit what you use, and delete what you do not.

Defer or delay third-party scripts. Load tools like analytics, chat and heatmaps after the page is interactive, or only when needed.

Break up long tasks. Developers can split heavy work into smaller chunks so the browser can respond between them.

Keep the page structure small. Very large, deeply nested pages with thousands of elements are slower to update.

Optimize event handlers. Menus, filters and forms should respond immediately with visible feedback, doing heavy processing afterward.

If your site is built on a page-builder platform loaded with plugins, INP can be difficult to fix without simplifying. A leaner build with limited JavaScript often resolves it.

Fixing CLS

Layout shifts have simple causes and usually simple fixes.

Set dimensions for images and video. Always specify width and height, or an aspect ratio, so the browser reserves space before the file loads.

Reserve space for ads, embeds and banners. Cookie notices, promotions and embedded maps that appear late and push content down cause shifts. Give them a fixed container or overlay them without moving the layout.

Handle fonts carefully. Web fonts that swap in after text has rendered can change the size of lines. Use font-display settings, preload key fonts and choose fallback fonts with similar metrics.

Avoid injecting content above existing content. Late-loading banners, notices and recommendations that appear at the top of the page push everything down. Insert them below, or reserve space.

Be wary of animations. Animate with transforms rather than properties that change layout.

A practical order of attack

If you are not sure where to start, work through this sequence:

1. Measure a handful of key pages on mobile and note the failing metrics.
2. Fix images first. Compress, resize, set dimensions and use modern formats. This often improves LCP and CLS at once.
3. Audit third-party scripts. Remove or defer anything that is not earning its place.
4. Check hosting and caching. Upgrade or add caching if server response is slow.
5. Address layout shifts from banners, fonts and embeds.
6. Re-measure and repeat. Improvements compound.

Common myths

“A perfect score means high rankings.” Scores are one signal among many. Aim for good, not perfect.

“Plugins fix speed.” Caching and optimization plugins help, but they cannot compensate for an overloaded theme or huge images.

“Speed only matters on mobile.” It matters everywhere, though mobile is usually more demanding.

“You must pass on every page.” Prioritize pages that bring in visitors and enquiries.

“It is a one-time job.” Performance degrades as you add content, plugins and tracking, so check regularly.

What to ask your developer or agency

If someone else manages your site, these questions get useful answers:

• What are our current LCP, INP and CLS on mobile for our key pages?
• What is causing the slowest elements?
• Are images being served in modern formats and the right sizes?
• Which third-party scripts are loaded, and do we need them all?
• Is the site pre-rendered or cached, and are we using a content delivery network?
• How will you test and monitor after changes?

A good partner will answer clearly and show you evidence, not just reassurance.

Building speed in from the start

Fixing performance after launch is harder than building it in. When planning a new site, ask for a lightweight architecture, static or pre-rendered pages where possible, an image pipeline that automatically sizes and compresses files, minimal JavaScript and a careful approach to third-party tools. These choices cost little at the start and save considerable pain later.

Final thoughts

Core Web Vitals sound technical but describe something simple: a page that loads quickly, responds promptly and stays put. Measure your key pages, fix the biggest culprits, usually images and scripts, and keep checking as the site evolves. Your visitors will feel the difference even if they never see a number. If you would like us to run a performance review and give you a prioritized list of fixes, we would be happy to help.