Core Web Vitals and page speed metrics

Core Web Vitals are the three field metrics Google uses to describe real user experience: LCP for loading, INP for responsiveness, and CLS for visual stability. Around them sits a second tier of diagnostic metrics — FCP, TBT, TTFB — that do not rank your site but tell you why a Core Web Vital is failing.

This page covers all of them, the thresholds for each, and how to work from a bad score back to its cause.

The thresholds at a glance

Every metric below is judged at the 75th percentile of real page loads. That matters more than it sounds: if three quarters of your visits are fast and the slowest quarter is terrible, you fail. A handful of quick tests on your own laptop proves nothing.

The three ranking metrics are the scoreboard. The other three are the diagnostics you actually fix.

Lab data vs field data

This distinction causes more confusion than anything else in web performance, so it is worth being precise.

Field data (also called RUM, Real User Monitoring) is collected from actual visits on actual devices. The Chrome User Experience Report — CrUX — is the public dataset Google itself ranks on, and it is what PageSpeed Insights shows at the top of a report. It reflects your real audience: their phones, their networks, their locations. It is also slow to move, because CrUX reports a rolling 28-day window. Ship a fix today and the field number will not fully catch up for a month.

Lab data is a synthetic test on a fixed device profile with a defined CPU and network throttle. Lighthouse and WebPageTest produce lab data. Because the environment is constant, a regression is almost certainly a code change rather than someone's flaky Wi-Fi — which makes lab data the right thing to gate a CI build on.

Use both, for different jobs:

• Field data tells you whether you have a problem. It is the only data that reflects your real users, and the only data Google ranks on.
• Lab data tells you what the problem is. It is reproducible, it gives you a waterfall and a call tree, and it catches regressions before users meet them.

A site can have green lab scores and red field scores — usually because the test profile is faster than the median real device, or because the tested URL is not the one people land on. The reverse also happens: field data looks fine because most traffic hits a cached homepage, while a slow checkout page ruins the experience for the people who matter most.

Practical rules:

• Run lab tests on one throttling profile (mobile slow 4G is the common default) so numbers stay comparable over time.
• Take the median of 3–5 runs, never a single sample.
• Test representative URLs — home, a product page, a long article — not just the landing page.
• Wire lab tests into CI and fail builds on regressions.
• Never draw a conclusion about real users from lab data alone.

LCP — Largest Contentful Paint

LCP measures how long until the largest text block, image, or video poster in the viewport finishes rendering. It is Google's primary proxy for perceived load speed.

A slow LCP almost always has one of three causes: the server is slow (see TTFB below), the hero asset is too heavy, or render-blocking resources are stalling layout.

How to fix it:

• Identify which element is actually the LCP candidate — Lighthouse names it explicitly. Developers routinely optimise the wrong image.
• Lower TTFB first. LCP can never be faster than the first byte.
• Preload the hero image with <link rel="preload" as="image"> and serve it in AVIF or WebP.
• Set explicit width and height so layout does not push LCP later. This helps CLS at the same time.
• Never lazy-load the hero image. Lazy-load only below-the-fold media.
• Strip render-blocking JavaScript and inline the CSS needed above the fold.

INP — Interaction to Next Paint

INP measures the latency between a user interaction — click, tap, key press — and the next visual update the browser paints. It reports the worst observed interaction on the page, so one slow click can dominate the score.

INP captures felt responsiveness after load: exactly the moments when a user decides whether the site works. Slow interactions usually trace back to long JavaScript tasks blocking the main thread, layout thrash, or expensive event handlers.

How to fix it:

• Break long tasks (over 50 ms) into smaller chunks with scheduler.yield() or setTimeout.
• Defer non-critical scripts and remove unused JavaScript.
• Move heavy work out of click, input, and keydown handlers into requestIdleCallback or a Web Worker.
• Use passive event listeners for scroll and touch so the browser can paint sooner.
• Hydrate framework components lazily — full-page hydration is a common INP killer.
• Watch TBT in the lab as your early-warning proxy.

CLS — Cumulative Layout Shift

CLS scores how much visible content moves unexpectedly while the page loads and is used. Good is 0.1 or less.

Layout shifts cause misclicks, lost reading position, and a generally unstable feel. Unlike pure load metrics, CLS measures friction users notice every single time a button jumps under their finger.

How to fix it:

• Always set width and height, or aspect-ratio, on images, videos, and iframes.
• Reserve space for ad slots, embeds, and injected banners with min-height containers.
• Never insert DOM above existing content unless it is a direct response to a user action.
• Preload critical fonts, and choose font-display carefully to limit FOIT/FOUT shifts.
• Animate with transform and opacity rather than properties that trigger reflow.

FCP — First Contentful Paint

FCP is the moment the browser paints the first piece of content — text, image, SVG, or non-blank canvas. It is when users stop staring at a blank screen.

FCP is not a ranking metric, but a poor FCP almost always coincides with poor metrics that are. It usually points at render-blocking resources or a slow server, and fixing it tends to drag LCP along with it.

How to fix it: reduce TTFB, inline critical CSS, defer non-essential stylesheets and scripts, preload key fonts with font-display: swap, and get render-blocking third-party tags out of the document head.

TBT — Total Blocking Time

TBT sums the portion of every long task (over 50 ms) that falls between FCP and Time to Interactive. It is lab-only and it is the closest synthetic proxy for INP.

A high TBT means the main thread is busy parsing, compiling, or executing JavaScript while the user is trying to interact. Because it runs in the lab, TBT surfaces during CI long before users feel the lag — which makes it the right gate to keep responsiveness regressions out of production.

How to fix it:

• Profile long tasks in the DevTools Performance panel.
• Code-split routes and defer non-critical bundles with dynamic import().
• Move heavy work off the main thread with Web Workers.
• Audit third-party scripts — analytics, chat widgets, A/B tools — and load them after interaction.
• Ship less client JavaScript. Nothing else moves TBT as reliably.

TTFB — Time To First Byte

TTFB measures the time from request to the first byte of response. It covers DNS lookup, TCP and TLS handshakes, request travel, server processing, and any CDN edge work.

TTFB is the floor for every other loading metric. A slow server delays LCP, FCP, and the start of script execution. Crawlers see the same slowness when fetching your pages, which affects how much of your site gets crawled.

How to fix it:

• Serve cacheable HTML and assets from a CDN so users connect to a nearby edge.
• Add full-page or fragment caching for dynamic content that is not per-user.
• Profile slow database queries, N+1 loops, and synchronous external API calls.
• Enable HTTP/2 or HTTP/3 and modern TLS to cut handshake overhead.
• Turn on compression for HTML.
• Measure from multiple regions — a fast TTFB in your own city proves very little.

FID — First Input Delay (retired)

FID measured the delay between a user's first interaction and the browser beginning to process the handler. It was a Core Web Vital from 2020 until 12 March 2024, when Google replaced it with INP.

Treat FID in older audits and dashboards as historical context only. INP is a stricter test because it samples the slowest interaction across the whole page lifecycle rather than just the first one — a site with a green FID can still post a poor INP.

If you still have FID instrumentation: replace dashboards and alerts with INP targets, keep watching TBT as the lab proxy, and re-instrument RUM using the web-vitals library, which reports INP by default.

Lighthouse

Lighthouse is Google's open-source auditing tool, built into Chrome DevTools and the engine behind PageSpeed Insights. It produces lab data across performance, accessibility, best practices, and SEO.

The single most common mistake is treating the Lighthouse performance score as the goal. It is a weighted composite of lab metrics on one synthetic profile — useful as a diagnostic, meaningless as a target. Google ranks on field data, not on your Lighthouse score.

Use Lighthouse for what it is good at: the opportunities and diagnostics sections, which name specific resources and specific costs. The score is a headline; the waterfall is the story.

A workflow that actually finds the cause

1. Start in the field. Open PageSpeed Insights or Search Console's Core Web Vitals report and confirm which metric fails, on which template, on which device class. Do not fix anything yet.
2. Reproduce in the lab. Run Lighthouse on a failing URL with mobile throttling. If the lab looks fine while the field fails, your test profile is too generous or you are testing the wrong page.
3. Work backwards down the stack. A bad LCP with a bad TTFB is a server problem, not an image problem. Fix the floor before the ceiling.
4. Change one thing. Re-run the median of 3–5 lab runs. Confirm the metric moved.
5. Wait for the field to catch up. CrUX is a rolling 28-day window. Real confirmation takes weeks, and that is normal.

Sitecheck runs PageSpeed Insights as part of every scan, so lab metrics and their diagnostics are recorded on each run rather than tested once and forgotten — which is what makes regressions visible.

See also

• Web performance: delivery, caching, and uptime
• Technical SEO: crawling and indexing
• Web security