What Core Web Vitals are and why they matter
Core Web Vitals are a set of measurements Google uses to describe how a page feels to real visitors. They are part of the page experience signals, which are one of many inputs to ranking. They do not replace relevance, but between two similarly relevant pages a better experience can help, and slow, jumpy pages lose visitors whatever their ranking.
The three current metrics are Largest Contentful Paint, which measures how quickly the main content appears, Interaction to Next Paint, which measures how quickly the page responds to taps and clicks, and Cumulative Layout Shift, which measures unexpected movement of content. Interaction to Next Paint replaced First Input Delay as a Core Web Vital in 2024.
How to measure them correctly
There are two kinds of data. Field data comes from real users, collected in the Chrome User Experience Report and shown in Search Console and in PageSpeed Insights. Lab data comes from tools such as Lighthouse, which simulate a device and network. Google uses field data for assessment, so treat Search Console as the final judge and Lighthouse as the debugging tool.
Test on a mid-range mobile device profile, because most visitors are on phones, and test the templates that matter: home page, a service or category page, an article and a product or contact page. Scores vary between runs, so repeat tests and look at trends.
Fixing Largest Contentful Paint (LCP)
LCP is usually an image or a large block of text near the top of the page. A good result is 2.5 seconds or less. The time is made of four parts: how long the server takes to respond, how long before the browser discovers the main resource, how long that resource takes to download, and how long before it is rendered.
Improve each part. Use fast hosting and caching or static generation to lower the server response time. Make sure the main image is in the HTML and not hidden behind a script, and give it a high fetch priority. Compress it, serve a modern format at the right size and avoid lazy-loading it. Reduce render-blocking CSS and fonts that delay the first paint.
- Fast server response, caching or static pages, and a CDN
- The main image in the initial HTML with high fetch priority
- Right-sized, compressed WebP or AVIF images
- Inline or minimise critical CSS and avoid render-blocking scripts
- Preload the key font and use font-display settings that avoid invisible text
Fixing Interaction to Next Paint (INP)
INP looks at how long the page takes to respond after a user interaction, taking the slow end of all interactions during a visit. A good result is 200 milliseconds or less. Poor INP is almost always caused by too much JavaScript running on the main thread, so the page cannot respond because it is busy.
Reduce and split JavaScript, remove unused scripts and libraries, and delay third-party tags such as chat widgets, ad scripts and heavy analytics until they are needed. Break up long tasks, avoid expensive work inside click handlers and keep the page structure small. Frameworks that ship less client code, or that keep most rendering on the server, help a great deal.
Fixing Cumulative Layout Shift (CLS)
CLS measures how much visible content moves unexpectedly while the page loads. A good result is 0.1 or less. The usual causes are images and videos without dimensions, ads and embeds that load late and push content down, late-loading fonts that change text size, and banners inserted above existing content.
Always set width and height or an aspect ratio for images, video and embeds, so that space is reserved before they load. Reserve space for ad slots and cookie banners, load fonts with matching fallback metrics, and avoid inserting content above what the user is already reading unless it responds to a user action.
Platform notes: WordPress, Next.js and Astro
On WordPress, the biggest gains usually come from better hosting, full-page caching, image optimisation, fewer plugins and a lightweight theme. On Next.js, use the built-in image component, prefer server components, split client code and manage third-party scripts. On Astro, content pages are usually fast by default, so watch for large images, fonts and any interactive islands you add.
Whatever the platform, make one change at a time and measure, so that you learn what actually helps. Keep a baseline report and check Search Console after each release, because field data takes a few weeks to update.
A four-week plan to pass Core Web Vitals
Week one: collect field data from Search Console, group failing URLs by template and pick the three templates with the most traffic. Week two: fix loading, which means server response, the main image and render-blocking resources. Week three: fix responsiveness by trimming JavaScript, delaying third-party scripts and splitting long tasks. Week four: fix layout shift by setting dimensions, reserving space for embeds and banners and stabilising fonts.
Release each fix separately and record the lab scores before and after. Field data takes several weeks to update, so judge progress by trends and keep a log of changes next to the dates.
Common myths
One myth is that a perfect Lighthouse score guarantees good field data. It does not, because real users have different devices and networks. Another is that Core Web Vitals decide rankings on their own. They are one signal among many, and relevance remains more important. A third is that a faster home page is enough: Google assesses groups of similar pages, so templates such as articles, products and locations all need attention.
A fourth myth is that you must score green everywhere before anything else. Fix the templates that carry the most traffic and revenue first, and the benefits show up where they matter.
Monitor so that regressions are caught early
Performance slips when new features ship. Add checks to your process: run Lighthouse on key pages in your deployment pipeline, set budgets for image and script size, and review the Core Web Vitals report monthly. Real-user monitoring tools can alert you when a release harms a metric. The goal is to catch a problem in days, not months.
Related services