Load Times and Your Websites

Google doesn't care about your load time as a single number anymore. They care about three specific things, and they've given them a name: Core Web Vitals.

What Core Web Vitals Actually Measure

There are three metrics. Each one captures a different part of what makes a page feel fast or slow to the person using it.

Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element to render. That's usually a hero image, a heading, or a large block of text. It's the moment the user feels like the page has "loaded" even if things are still happening in the background. Google wants this under 2.5 seconds.

Cumulative Layout Shift (CLS) measures how much the page moves around while it's loading. You've felt this one. You start reading, an ad loads above your content, everything shifts down, and you lose your place. Or you're about to tap a button and it jumps because a font finished loading. CLS quantifies that frustration. Google wants this under 0.1.

Interaction to Next Paint (INP) measures how fast the page responds when you do something. Click a button, tap a link, type in a field. INP captures the delay between your action and the browser actually updating the screen. This replaced First Input Delay in March 2024 because FID only measured the first interaction. INP measures all of them and reports the worst case. Google wants this under 200 milliseconds.

Why These Three

The old way of measuring performance was synthetic. Run Lighthouse, get a score, feel good or bad about the number. The problem is that Lighthouse runs on your machine, with your connection, under lab conditions. Your users aren't using your machine.

Core Web Vitals are field metrics. They come from real users on real devices over real connections. Google collects them through Chrome and surfaces them in the Chrome User Experience Report. When Google says your LCP is 3.4 seconds, that's the 75th percentile of actual visits. Not a lab test. Not a best case.

This matters because a site can score 95 in Lighthouse and still have bad CWV in the field. The lab doesn't have the slow Android phone on a 3G connection that makes up a chunk of your real traffic.

LCP: The Usual Suspects

LCP problems almost always come from one of four places.

Slow server response. If your TTFB (time to first byte) is over a second, your LCP can't possibly be under 2.5 seconds. The page hasn't even started rendering yet. This is a hosting and caching problem, not a frontend problem.

Render-blocking resources. CSS and synchronous JavaScript in the head of your document block the browser from painting anything until they've finished loading. Every stylesheet and script tag in the head is a gate the browser has to pass through before it can show your user anything.

Unoptimized images. If your LCP element is an image (and it often is), and that image is a 2MB uncompressed JPEG, you're waiting for 2MB to download before the page feels loaded. Format, compression, sizing, and preloading all matter here.

Client-side rendering. If your page ships an empty div and then fetches content via JavaScript, the browser can't paint the LCP element until the JavaScript has loaded, executed, fetched data from an API, and rendered the result. That's a lot of sequential work.

CLS: Death by a Thousand Shifts

CLS is the metric that catches you off guard because the problems are often invisible during development. You're on a fast machine with cached assets. Everything loads instantly and nothing shifts. Your user on a slower connection sees every shift.

Images and videos without dimensions. If you don't set width and height attributes (or use CSS aspect-ratio), the browser doesn't know how much space to reserve. The image loads, the browser figures out the size, and everything below it jumps.

Web fonts loading late. The browser renders text in a fallback font, then swaps to your custom font when it finishes loading. If the custom font has different metrics, text reflows and surrounding elements shift. font-display: swap is the right behavior for perceived performance, but it causes layout shift if the fallback and final font aren't size-matched.

Dynamically injected content. Banners, cookie notices, ads, newsletter popups. Anything that inserts itself into the document flow after the initial render pushes content around. If it has to exist, reserve space for it.

INP: The One Nobody Thinks About

INP is the newest metric and the one most developers haven't internalized yet. It measures responsiveness across the entire visit, not just the first click.

Heavy JavaScript on the main thread is the primary cause. If a click handler triggers a large computation, a complex re-render, or a synchronous API call, the browser can't update the screen until that work finishes. The user clicks and nothing happens for 300 milliseconds. That's a failed INP.

Third-party scripts are a common culprit. Analytics, chat widgets, A/B testing tools, tag managers. Each one adds JavaScript that competes for the main thread. Individually they're fine. Together they're a tax on every interaction.

Long tasks are the mechanism. The browser's main thread processes work in tasks. A task longer than 50 milliseconds is a "long task" and it blocks interaction response. Breaking long tasks into smaller chunks (using requestAnimationFrame, setTimeout, or yielding to the main thread) keeps the browser responsive.

How to Measure

PageSpeed Insights shows both lab data (Lighthouse) and field data (CrUX) for any URL with enough traffic. The field data is what matters for rankings. The lab data is useful for diagnosing problems.

Chrome DevTools has a Performance panel that records real interactions and shows you exactly where time is being spent. For INP debugging, this is the most useful tool. Record a session, click around your site, and look for long tasks in the flame chart.

Google Search Console has a Core Web Vitals report that groups your pages by status. It tells you which URLs have problems and what category the problem falls into. This is the view you want to check regularly because it shows trends over time.

The web-vitals JavaScript library lets you capture CWV data from your own users and send it to your analytics. This is the most accurate source because it's your traffic, not Google's sample.

The Ranking Signal

Google has been using CWV as a ranking signal since 2021. It's not the dominant signal. Relevant content still outranks fast irrelevant content. But when two pages are roughly equal in content quality, the faster one wins. It's a tiebreaker, and tiebreakers matter in competitive search results.

More practically: bad Core Web Vitals create a ceiling. You can do everything else right with your SEO and still lose positions because your LCP is 4 seconds on mobile. Fixing performance doesn't guarantee better rankings, but bad performance guarantees a handicap.

Start With Measurement

Don't guess. Run your site through PageSpeed Insights and look at the field data. If you don't have enough traffic for field data, use the lab numbers as a starting point but know they're optimistic.

Fix the worst metric first. If your LCP is 5 seconds, CLS and INP don't matter yet. Get the page rendering fast. Then stabilize the layout. Then make interactions responsive.

Performance isn't a one-time fix. Every new feature, every new third-party script, every image your content team uploads is a potential regression. Measure continuously or you'll drift back to where you started.