How to Improve Core Web Vitals and Website Performance

To improve Core Web Vitals, first find which metric is failing for real visitors, then fix the cause and measure again. The current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). At the 75th percentile, the recommended good targets are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Review mobile and desktop separately. Google Search Central explains the metrics and thresholds.

A Lighthouse score is useful for diagnosis, but it is not a substitute for field data. Real-user conditions vary, and a green lab result does not guarantee that visitors have a good experience. Use field data to find the problem, lab tools to reproduce and investigate it, and field data again to judge the result.

1. Establish a real-user baseline

Open the Search Console Core Web Vitals report and PageSpeed Insights (PSI) for representative URLs.
Check whether PSI is showing URL-level or origin-level field data, and whether the results are for mobile or desktop. A URL may lack enough samples for its own result.
Record the affected metric, device segment, URL or page template, and whether the issue appears across the origin.
Prioritize by how many affected pages and visitors are represented, then investigate individual pages.

PSI combines CrUX field data with Lighthouse lab diagnostics. CrUX represents a trailing 28-day period, so recent changes may not immediately appear in its field results. CrUX does not cover every page or site: public field data requires sufficient samples and eligible public pages. If its data is absent or too aggregated to explain a problem, consider first-party real-user monitoring (RUM). RUM can capture page-level and interaction context that a high-level public dataset may not provide. See the PageSpeed Insights documentation and web.dev’s Web Vitals guidance.

2. Use lab measurements to diagnose

Use Lighthouse and browser developer tools to inspect controlled page loads, network waterfalls, JavaScript work, and layout behavior. Record the test conditions and compare like with like: device emulation, network settings, page state, and interactions can all change a lab result.

Lighthouse cannot measure INP without real user input. Total Blocking Time (TBT) can help expose blocking work in a lab run, but it is a diagnostic proxy, not INP. Field and lab results can differ because real devices, networks, active work, and interactions differ. The web.dev guidance puts it plainly: “While lab measurement is an essential part of delivering great experiences, it is not a substitute for field measurement.”

3. Improve LCP by finding the delayed stage

LCP measures when the largest visible image or text block renders. Identify the LCP element and inspect its request and rendering path. Break the observed delay into four stages: Time to First Byte (TTFB), resource load delay, resource load duration, and element render delay. The LCP optimization guide describes how to investigate each stage.

What the evidence shows	What to inspect	Potential direction
High TTFB	Redirect chains, server response, cache behavior, and delivery distance	Address the specific server, redirect, cache, or geographic issue shown by field and network data.
Long resource load delay	When the browser discovers the LCP resource and whether JavaScript controls its availability	Make the critical content discoverable and prioritized early where the evidence supports it.
Long resource load duration	The LCP resource size and delivery in the network waterfall	Improve the resource or its delivery based on the measured bottleneck.
Long element render delay	Browser work that occurs before the LCP element can display	Investigate rendering and main-thread work delaying that element.

If PSI and Lighthouse disagree, first check whether PSI is showing origin-level data while the lab run covers one URL. A high TTFB contributes time before later loading milestones, but infrastructure changes should follow evidence that identifies server response, redirects, caching, or delivery as the cause. The LCP guide cautions that meaningful improvement rarely comes from a quick fix to only one part of a page.

4. Improve INP by finding slow interactions

INP evaluates qualifying interactions throughout a visit and reflects the slowest interaction, sometimes excluding outliers. Start with field data. When available, RUM can help identify the interaction, whether it happened during or after page load, and whether it came from a click, keypress, or tap. CrUX provides a summary but may not give enough detail to locate the responsible code.

Use field or RUM data to find which page types and interactions have slow INP.
Reproduce the interaction and inspect the browser’s performance trace for work delaying the next paint.
Change the code or work associated with that interaction, then repeat the same interaction under comparable lab conditions.
Monitor field results to confirm that visitors’ INP improves and check for regressions on other interactions.

A lab trace can help find blocking work; it cannot establish field INP. TBT may point to main-thread blocking that is worth investigating, but it is not an equivalent measurement. See the INP optimization guide.

5. Reduce CLS by reserving space

CLS measures visual instability based on the fraction of visible content that shifts and how far affected elements move. Common causes include images without dimensions, ads or embeds without reserved space, dynamically inserted ads, embeds, or iframes, and web font changes.

Provide image dimensions or an equivalent reserved aspect ratio so later image loading does not move surrounding content.
Reserve space for ads, embeds, and other content that arrives after the initial render.
Inspect dynamic insertions and font swaps for movement of content already on screen.
Compare field data with a lab run: shifts later in a visitor’s page lifetime may not occur during a basic lab page load.

Use the CLS optimization guide to inspect and address layout shifts. Check the affected page state and timing; a page-load-only reproduction may miss a shift that occurs later.

6. Treat TTFB as a diagnostic

TTFB happens before First Contentful Paint and LCP, so a high value can add time to later loading metrics. It is not a Core Web Vital. web.dev gives 0.8 seconds or less as a rough guide for most sites, not a pass requirement. Interpret it in the context of how the site delivers content: a client-rendered app can depend heavily on early HTML, while a server-rendered page may still reach useful content sooner despite a higher TTFB. Investigate server response, caching, redirects, and geographic delivery only when field evidence points there. See web.dev’s TTFB guide.

7. Choose fixes by cause, reach, and risk

When several changes seem plausible, compare them against the actual failing segment. There is no universal ranking of fixes that works for every site.

Decision factor	Question to answer
Metric and cause	Which Core Web Vital fails, and which causal stage or interaction is responsible?
Scope	Does the issue affect mobile, desktop, one template, selected URLs, or the whole origin?
User experience	Will the change address the experience field data identifies?
Effort and risk	What implementation effort and regression risk does the change introduce?
Tradeoffs	Could the change improve one metric while harming another or changing page behavior?

Make one targeted change at a time where practical. Keep the before-and-after conditions comparable, watch relevant page templates and device segments, and use field data to determine whether the user experience changed.

8. A repeatable improvement checklist

Capture the field baseline for representative URLs, devices, and templates.
Confirm the metric, percentile, data level, and affected segment.
Use a lab run or browser trace to reproduce the issue and identify its cause.
Choose a fix tied to that cause; document expected benefit, effort, and risk.
Re-run comparable diagnostics and check that the page still behaves correctly.
Monitor field results after deployment; allow for the reporting window and sample coverage.
Repeat for the next highest-impact measured problem.

Inspect visual regressions with a screenshot

When a performance change alters rendering, compare screenshots of representative pages and states to spot missing content, unexpected movement, or changed styling. Screenshot comparisons complement metric data; they do not replace field measurement or diagnose the cause of a slow metric.

DIY browser example: with Playwright installed in a Node.js project, capture a page before and after a change. Save as compare.mjs and run with node compare.mjs:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1365, height: 900 } });
await page.goto('https://example.com', { waitUntil: 'networkidle' });
await page.screenshot({ path: 'page-after.png', fullPage: true });
await browser.close();

Install Playwright in the project with npm install -D playwright, then install its browser with npx playwright install chromium. The capture is a visual artifact, not a controlled CWV measurement. For repeatable comparison, keep viewport, browser, page state, consent choices, and capture timing consistent. A full-page capture may trigger lazy-loaded content differently from a viewport capture; use the same method in each comparison.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. For rendered-page comparisons, request the same format and capture settings each time. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

import requests

r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts cookie and consent banners like a visitor before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say which page verdict and billing status applied. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month without a card; paid plans start at $5 for 3,000 screenshots.

Common problems and fixes

Symptom	Likely reason	What to do
PSI has no URL field data	The URL lacks sufficient eligible CrUX samples.	Check whether PSI offers origin-level data; use first-party RUM for page-level diagnosis where needed.
Search Console and a lab run disagree	They represent different data sources, conditions, or page scopes.	Confirm URL versus origin data and mobile versus desktop, then use lab tools to investigate rather than overwrite field evidence.
Lighthouse looks good but INP is poor	Lighthouse has no real user interaction to measure as INP.	Use field data or RUM to identify slow interactions; use a trace to reproduce them. Treat TBT as a proxy only.
A faster LCP change does not improve the field result	The change may target the wrong stage, a different URL scope, or data still within the trailing reporting period.	Recheck the LCP element and four timing stages, confirm the affected segment, and monitor subsequent field data.
CLS is fine in a lab but poor in the field	Movement may happen after load or during states the lab run did not reach.	Inspect later page lifetime events, ads, embeds, fonts, and dynamic content; compare with field or RUM evidence.
TTFB is high, but adding infrastructure changes is unclear	TTFB alone does not identify the cause or establish a CWV failure.	Inspect redirects, server response, cache behavior, and delivery distance; intervene only where measurements implicate them.

Do Core Web Vitals affect Google rankings?

Google says its core ranking systems seek to reward content that provides a good page experience, but good Core Web Vitals or third-party reports do not guarantee top rankings. There is no single page-experience signal, and a relevant result can still appear when its page experience is subpar. Treat CWV as user-experience goals within a broader experience that includes useful content, security, mobile presentation, intrusive ads or interstitials, and clarity of main content—not as a ranking hack or substitute for useful content. Read Google’s page experience documentation.

FAQ

Is FID still a Core Web Vital?

No. INP replaced First Input Delay (FID) as the responsiveness Core Web Vital in March 2024. See web.dev’s Web Vitals overview.

Should I optimize every page separately?

Start with representative URLs and identify whether field data points to a shared template or an individual page. The right scope follows the evidence.

Will improving one metric always improve the others?

No. Measure each metric after a change and check for tradeoffs in affected page states and device segments.

How quickly will field data reflect a deployment?

PSI describes CrUX field data over a trailing 28-day period, so it reflects a window rather than an immediate before-and-after test. Use lab diagnostics for immediate checks and RUM when faster, more detailed field feedback is needed.