Website speed and Core Web Vitals: what to measure and how to fix it

Core Web Vitals are three measurements Google uses to describe how a page feels to real visitors: LCP (how quickly the main content appears), INP (how quickly the page reacts when someone taps, clicks or types) and CLS (how much the layout jumps while it loads). Most slow sites suffer from the same short list of causes: oversized images, web fonts, scripts that block rendering, third-party tags, elements that appear without reserved space, and a slow server response. Fix those in order of impact, and judge the result by field data from real visitors, because a single lab test on a fast office connection can hide the problem.

#What LCP, INP and CLS measure in plain words

Largest Contentful Paint (LCP) marks the moment the biggest visible element in the first screen finishes rendering. On most pages that is the hero image, a product photo or the main heading. It answers the visitor's first question: has the page actually loaded?

Interaction to Next Paint (INP) looks at the interactions during a visit, such as opening a menu, adding to the cart or typing in a search box, and measures how long the page takes to show a visible response. It replaced an older metric, First Input Delay, which only looked at the first interaction. A poor INP feels like a page that ignores you for a moment after every click.

Cumulative Layout Shift (CLS) adds up how much visible content moves unexpectedly. The classic example is reaching for a button just as a banner loads above it and pushes it down, so you tap the wrong thing.

Google publishes a "good", "needs improvement" and "poor" threshold for each metric and assesses them at a high percentile of real page loads, so the slower visits count. The thresholds have changed before, so check the current values in Google's official Web Vitals documentation on web.dev before you set targets.

#Lab data and field data are different things

Lab data comes from a test you run on demand: Lighthouse in Chrome DevTools, PageSpeed Insights' lab section, or WebPageTest. It loads the page once under controlled conditions. Lab tests are repeatable, which makes them good for debugging and for checking a fix before release. They cannot measure INP properly, because nobody is clicking, so they report proxies such as Total Blocking Time instead.

Field data comes from real visitors on their own devices and networks. Google's Chrome User Experience Report (CrUX) collects it from Chrome users who have opted in, and it is what PageSpeed Insights shows at the top and what Search Console's Core Web Vitals report is built on. Field data is the score that matters, but it is aggregated over weeks, so a fix shows up slowly. Low-traffic pages may have no field data at all.

A practical approach uses both:

• Use Search Console to find which groups of pages fail in the field.
• Reproduce the problem in a lab tool, with network and CPU throttling switched on to imitate an ordinary phone.
• Fix, verify in the lab, release, then watch the field data over the following weeks.
• For faster feedback, collect your own field data with the open-source web-vitals JavaScript library and send it to your analytics.

#Common causes of a slow LCP and how to fix them

Images

The LCP element is usually an image, and it is often far larger than it needs to be. Serve modern formats such as WebP or AVIF, resize images to the size they are displayed at, and use srcset so phones download a smaller file. Never lazy-load the image in the first screen. Mark it with fetchpriority="high" so the browser fetches it early. Lazy-load the images further down the page instead.

Fonts

Web fonts can hide text until they arrive. Use font-display: swap or optional, preload the one or two font files the first screen needs, host them yourself where the license allows, and limit the number of weights. Every extra weight is another download.

Render-blocking scripts and CSS

A script in the page head without defer or async stops the browser from rendering until it has downloaded and run. Defer what is not needed for the first screen, split large JavaScript bundles so each page loads only its own code, and inline the small amount of CSS the first screen needs when the rest is large.

Server response and caching

Nothing renders until the HTML arrives. The time to first byte depends on the server, the database queries behind the page and the distance to the visitor. Cache full pages where the content allows it, cache expensive queries, add the missing database indexes, and serve static files with long cache headers from a CDN. A site that has outgrown its plan may also need more resources; our article on when to move from shared hosting to a VPS covers that decision.

#Common causes of a poor INP

INP suffers when the browser's main thread is busy and cannot respond. The usual causes:

• Third-party tags. Analytics, chat widgets, ad scripts, heatmaps and tag managers all run on the same thread as your page. Audit them once a year, remove the ones nobody reads, and load the rest after the page is interactive.
• Heavy event handlers. A click that triggers a large re-render or a slow calculation blocks the next paint. Show visual feedback first, then do the heavy work, and break long tasks into smaller pieces.
• Too much JavaScript overall. Large frameworks hydrating a whole page on a mid-range phone take time. Render more on the server and ship less code to the browser.

#Common causes of layout shift

CLS is usually the easiest metric to fix, because the causes are visible once you look for them:

• Images and videos without width and height attributes or a CSS aspect-ratio, so the browser cannot reserve space.
• Cookie banners, promotional bars and embeds inserted above existing content. Reserve their space or show them as an overlay.
• Ads and iframes that resize after loading. Give their containers a fixed minimum size.
• Web fonts that swap in with very different dimensions. Pick a fallback font with similar metrics, or adjust it with the CSS size-adjust descriptor.
• Content injected by JavaScript after load, such as "related products" blocks, without a placeholder of the right height.

#How much speed work is worth doing

Core Web Vitals are one of many signals Google uses, and relevant content still matters more for ranking. The stronger reason to care is your visitors: a page that loads quickly and responds at once is easier to use and easier to buy from. Measure that for your own site by comparing conversion or bounce rates between faster and slower page groups in your analytics, before and after a fix.

Speed also decays. New tags, larger images and extra plugins arrive one at a time. Add a lab check to your release process so a change that hurts performance is caught before it ships, and review the field data as part of regular website maintenance after launch.

#How PN Scripts can help

PN Scripts builds and maintains web applications in many stacks, and a performance review can be part of that work: finding what slows your pages down in the field, fixing it in order of impact and keeping it fixed with checks in the release process. If your site needs that kind of attention, see our custom web development page.