The short answer: Core Web Vitals are three measures that describe how a page feels to a real visitor: how fast the main content appears, how quickly the page responds when you tap and how much the layout jumps around while loading. They matter because slow, unstable pages lose visitors, and search engines take them into account.
You do not need to be technical to understand them. You need to know the three names, the targets and who is responsible.
Largest Contentful Paint (LCP)
How long until the biggest visible piece of content, usually a main image or headline, is shown. The published target for a good result is 2.5 seconds or less.
Common causes of a slow LCP: very large images, slow servers, scripts that block the page from drawing.
Interaction to Next Paint (INP)
How quickly the page reacts when someone taps or clicks. The target for a good result is 200 milliseconds or less.
Common causes of a slow response: heavy scripts, many plugins, large animations running at the same time.
Cumulative Layout Shift (CLS)
How much the content moves while the page loads, such as a button that jumps just before you tap it. The target for a good result is 0.1 or less.
Common causes: images without set dimensions, late-loading fonts, banners that push content down.
Real visitors, not your office connection
The measures are judged on data from real visitors, usually at the 75th percentile, which means that three out of four visits should meet the target. A page that is fast on your computer with a strong connection may be slow on a mid-range phone on a mobile network. Test on real phones.
How to check
- Run the page through a public speed testing tool for a quick view.
- Look at the Core Web Vitals report in the search tool for real-visitor data once the site has traffic.
- Test on a real phone on mobile data.
What usually fixes it
- Compress images and use modern formats, with the right size for each screen.
- Load images below the first screen only when needed.
- Remove plugins and scripts you do not need.
- Load fonts efficiently and keep the number of font files small.
- Use caching and a content delivery network.
Decide it at the design stage
Speed is cheaper to build in than to repair. A design that depends on heavy animation, many fonts and large video will always fight these targets. The decision belongs at the start. Our technical SEO checklist includes the related checks.
An illustration: a slow home page and what fixed it
Imagine a home page whose main image is a very large photo, loaded at full size on every phone. The first screen takes a long time to appear. The team resizes the image for each screen size, converts it to a lighter format and loads the images lower on the page only when the visitor scrolls to them. The first screen appears much sooner without changing how the page looks.
Who is responsible
Speed belongs to the designer, the developer and whoever adds content. A designer who chooses heavy effects, a developer who loads many scripts and an editor who uploads uncompressed photos can each undo the others' work. Agree the targets in the brief, check them before launch and re-check after major changes. A site's search visibility, covered in our SEO and GEO work, depends on this basic quality.
What to do this week
- Open your home page on a mid-range phone on mobile data and note how long the main content takes to appear.
- Run the page through a public speed test and note the three measures.
- Look at your largest images and check that each is sized for the screen it appears on.
- List every plugin and script, and remove any that nobody can explain.
- Share the results with whoever builds the site.
Where to start when everything is slow
If a site is slow, the list of possible fixes can be long. Start with the changes that tend to bring the largest gains.
- Images. Compress them, use modern formats and size them for the space they occupy. Large unoptimised images are the most common cause of slow pages.
- Scripts. Remove tools and plugins that are not earning their cost, and delay the ones that are not needed immediately.
- Fonts. Limit the number of typefaces and weights, and load them efficiently.
- Hosting and caching. A good server, caching and a content delivery network help pages arrive quickly.
- Layout stability. Reserve space for images, banners and embeds so that the page does not jump while loading.
Measure before and after each change so that you know what helped.
Talking to your developer about it
Performance is easier to improve when the business and the developer share a target. Ask for the real-visitor measurements, not only a laboratory score. Agree which pages matter most, usually the home page and the pages that receive paid traffic. Ask what the developer would change first and why, and what each change will cost in time.
Make performance part of the acceptance criteria for new work, so that a new feature is not accepted if it makes the key pages slower. Keeping this standard from the start is far cheaper than repairing a slow site later.
Why it matters to the business
Speed and stability affect how visitors feel about the business. A page that loads slowly or shifts while someone is trying to tap a button creates frustration, and frustrated visitors leave. For sites that depend on paid traffic, a slow page wastes money, because people who clicked the ad never see the offer.
Search engines also take these measurements into account as part of the overall experience of a page, although content quality and relevance remain very important. Treat performance as part of the quality of the service you offer online, not as a technical afterthought.
Keeping performance under control over time
Sites slow down gradually: a new plugin, a bigger image, an extra tracking tool. Prevent this with a simple routine. Check the key pages each month with a performance tool and with real-visitor data where it is available. Record the results in a sheet, and look for trends. When a number worsens, trace it to the most recent change and decide whether to fix or remove it.
Set a rule that every new script, plugin or large image must be justified and tested before it goes live. A small amount of discipline here protects both the user experience and the budget spent on bringing people to the site.
How we work
We design for speed, test on real phones before sign-off and keep the plugin list short. If your site feels slow, send us the address.