What are Core Web Vitals in 2026?

Core Web Vitals are Googles standardized metrics for real-world page performance: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). LCP measures how long until the largest visible content element renders; the threshold for "good" is 2.5 seconds at the 75th percentile of visits. INP, which replaced First Input Delay (FID) in March 2024, measures the time from user interaction (click, tap, key press) to the next paint after the response; "good" is 200 ms. CLS measures unexpected visual jitter as the page loads; "good" is 0.1 or less. Together these three are part of Google search ranking signals as of 2021, with INP rolled in for 2024-2025. The metrics are gathered from real users via the Chrome User Experience Report (CrUX) when at least 1,000 unique visits per month exist; below that, lab tests via Lighthouse and PageSpeed Insights are the primary signal. The Grigora performance checker runs Lighthouse against your URL, returns LCP, INP, CLS, and the underlying breakdown so you can prioritize fixes that move the needle.

What is a good LCP score in 2026?

Below 2.5 seconds is the "good" threshold; 2.5-4.0 seconds is "needs improvement"; above 4.0 seconds is "poor." These thresholds are evaluated at the 75th percentile of visits, meaning 75% of your real users must hit the threshold for the page to qualify as "good." Median performance is not enough. The reason 2.5 seconds is the cutoff is that user-experience research from Google (replicated by Akamai and Walmart) shows engagement drops sharply when the largest visible element takes longer than that. LCP is most often determined by hero images, large blocks of text, or video posters. Common causes of slow LCP: render-blocking JavaScript, server response times over 600 ms, hero images served at 4x the needed resolution, or fonts with no font-display: swap. The biggest LCP win for most sites in 2026 is preloading the hero image and using AVIF or WebP at the actual rendered size. The Grigora checker identifies the LCP element specifically and suggests targeted optimizations.

How do I improve INP?

INP measures responsiveness during user interactions and has become the hardest metric to optimize since it replaced FID in 2024. INP is at "good" below 200 ms and "poor" above 500 ms. The biggest contributors to slow INP are long JavaScript tasks that block the main thread, third-party scripts (analytics, ads, chat widgets), and React re-renders that update large component trees synchronously. To fix INP: profile interactions using Chrome DevTools Performance tab and look for tasks longer than 50 ms; break them up using requestIdleCallback, scheduler.postTask, or React 18+ useTransition; defer non-critical third-party scripts to after first interaction; switch to React Server Components to ship less JavaScript to the client; replace heavy widgets (live chat, A/B test SDKs) with lazy-loaded versions that only initialize on user trigger. A 2025 Akamai study found that improving INP from 400 ms to 150 ms increased ecommerce conversion rate by 7-12% on average. The Grigora performance checker reports the slowest interaction observed during the Lighthouse run.

What causes high Cumulative Layout Shift?

CLS happens when elements move unexpectedly after initial render, causing users to misclick or lose their reading position. The most common causes: images and videos without explicit width/height attributes (the browser does not reserve space until the asset loads), web fonts that swap from a fallback to the actual font causing text reflow, ads or embeds that load asynchronously and push content down, and dynamic banners (cookie consent, newsletter prompts) that insert above existing content. Fixes: add explicit width and height attributes to all , , and elements; use aspect-ratio CSS for responsive containers; declare font-display: optional or use size-adjust to prevent FOUT/FOIT shifts; reserve space for dynamic banners with min-height; load embeds (Twitter, YouTube, Instagram) inside fixed-aspect-ratio wrappers. The "good" threshold is 0.1 or less; many sites that look fine to designers are actually scoring 0.3-0.5. The Grigora checker shows the CLS source elements so you can identify and fix specific shifts.

How does Lighthouse differ from PageSpeed Insights?

PageSpeed Insights (PSI) and Lighthouse share the same underlying audit engine but report different things. Lighthouse runs in a controlled lab environment (simulated 4G connection, throttled CPU) and produces synthetic scores. PSI runs Lighthouse plus pulls real-user field data from CrUX. So PSI is "what users actually experience" plus "what we can simulate," while Lighthouse alone is just simulation. The difference matters because lab and field scores can diverge significantly: a page can score 95 in Lighthouse and have a poor LCP in real-world data due to slow user devices, network conditions, or origin-level redirects that the lab does not simulate. For ranking purposes, Google uses the field data; for development iteration, lab data via Lighthouse is faster (3-5 seconds per run vs needing 28 days of CrUX data). Run Lighthouse continuously in CI to catch regressions early; check PSI weekly for the source of truth on real users. The Grigora performance checker uses Lighthouse-based audits and is best for spot checks and pre-deployment validation.

Should I run performance tests on mobile or desktop?

Both, with mobile as the priority. Google has used mobile-first indexing since 2020, meaning mobile performance is what determines ranking. Mobile is also harder to optimize because devices are slower, networks are less reliable, and screens are smaller. Lighthouse and PSI default to mobile testing for this reason. Specifically, the simulated mobile device is a Moto G4 (5+ year old mid-tier Android) on 4G connection at 1.6 Mbps with 150 ms RTT. Optimizing for that device covers 80%+ of real-world conditions. Desktop is still worth testing because some user segments are desktop-heavy (B2B, enterprise software), and some optimizations help both equally. A 2025 Cloudflare study found that mobile pages averaged 30% slower LCP than desktop versions of the same URL, mostly due to JavaScript execution time. Set CI thresholds for both, but treat mobile as the binding constraint. The Grigora checker runs both mobile and desktop profiles by default and shows them side by side.

What is Time to First Byte (TTFB) and how do I improve it?

TTFB is the time from when the browser sends a request to when the first byte of response is received. It includes DNS lookup, TCP handshake, TLS negotiation, and server processing time. A "good" TTFB in 2026 is under 800 ms; under 200 ms is excellent. Slow TTFB is often the bottleneck for slow LCP because content cannot start rendering until bytes arrive. Improvements: use a CDN to reduce geographic latency (Cloudflare, Fastly, Vercel Edge), enable HTTP/3 to reduce handshake time, cache responses at the edge for static or semi-static pages, optimize database queries that block server response (the most common cause of TTFB over 1 second), and avoid synchronous third-party API calls in the request path. For dynamic SaaS pages, server response time often dominates; switching from a single Postgres replica to a read-replica setup, or moving from Lambda cold starts to provisioned concurrency, can cut TTFB by 50-70%. The Grigora checker reports TTFB and breaks down the wait time so you can identify whether the bottleneck is network or server.

How do third-party scripts affect performance?

Third-party scripts (analytics, ads, A/B testing, customer support chat, social embeds, tag managers) are the single biggest cause of slow performance on most marketing and content sites. A 2025 HTTP Archive study analyzing 8 million pages found that the median desktop page loads 21 third-party scripts and the median mobile page loads 18, contributing 35-45% of total JavaScript execution time. Each script can add 50-300 ms of main thread blocking, hurt INP, and trigger layout shifts. Mitigation strategies: audit which scripts are actually needed and remove the rest (most sites have 5-10 dormant tag manager entries from old experiments); load all non-critical scripts with async or defer attributes; use Partytown to move third-party scripts to a Web Worker, isolating them from the main thread; lazy-load chat widgets, social embeds, and ads only on user interaction; replace heavy SDKs with first-party alternatives (e.g., switch from Intercom to a lighter chat tool, or build your own analytics pipeline). The Grigora performance checker lists every third-party script with its size and execution time.

What is the difference between FCP, LCP, and Speed Index?

These are three of the loading metrics tracked by Lighthouse. First Contentful Paint (FCP) is the time until any content (text, image, SVG) renders; this is the first sign of progress for a user. Largest Contentful Paint (LCP) is the time until the main content (largest visible element above the fold) renders; this is what Google uses as a Core Web Vital. Speed Index measures how quickly content is visually populated, weighted by how much of the visible area is filled at each tenth of a second; a low Speed Index means more content visible faster. FCP "good" threshold is 1.8 seconds; LCP is 2.5 seconds; Speed Index is 3.4 seconds (but only used in synthetic Lighthouse, not real-user data). Optimizing FCP and Speed Index almost always improves LCP, but the inverse is not always true; you can optimize LCP at the expense of FCP if you delay the first render to load a high-quality hero image. Best practice is to optimize all three holistically. The Grigora checker shows all three with specific element breakdowns.

How often should I check page performance?

Three frequencies for three purposes. First, on every code change: integrate Lighthouse CI into your CI/CD pipeline so every pull request gets a performance score. Set a budget (e.g., LCP must stay under 2.5 seconds, JS bundle must stay under 200 KB) and fail the build if violated. This prevents regressions before they reach production. Second, weekly on key pages: run a manual or scheduled performance check on your top 10-20 traffic pages to catch issues that CI might miss (third-party script bloat, image regression, server-side performance drift). Third, monthly via Search Console: check the Core Web Vitals report which uses real-user CrUX data; this is what Google uses for ranking. The CrUX data is on a 28-day rolling window, so changes take a few weeks to reflect. Watch the failure rate (percentage of URLs marked "poor") rather than the median score. The Grigora checker is best for the second use case; for the first, integrate Lighthouse CI directly.

What budget should I set for JavaScript bundle size?

A reasonable budget for a B2B SaaS marketing site in 2026 is 200 KB of JavaScript (gzip-compressed) on the critical path before first interaction. For ecommerce, 250-300 KB is more realistic given product data and analytics needs. For news and blogs, aim for 150 KB or less. The reason these numbers matter: every 50 KB of JavaScript adds roughly 200-400 ms of execution time on a mid-tier mobile device, which directly impacts INP and LCP. Bundle size budgets are most useful when set per route, not site-wide, so heavy app pages can use more without inflating landing pages. Tools like Lighthouse, Bundlephobia, and Vercels Speed Insights measure both transfer size and execution time. Code-splitting via dynamic imports, tree-shaking via modern bundlers (esbuild, swc), and replacing heavy libraries (moment.js, lodash) with lightweight alternatives (date-fns, native methods) are the highest-leverage optimizations. The Grigora checker reports total JS transfer size and the heaviest files contributing.

Does HTTP/3 actually help performance?

Yes, especially for mobile users on lossy networks. HTTP/3 (QUIC) replaces TCP with UDP, eliminates head-of-line blocking, and uses a faster connection setup. The biggest wins are on networks with packet loss above 2% (common on mobile and Wi-Fi); HTTP/3 can cut TTFB by 200-400 ms in those conditions. On stable wired connections, the gain is more like 30-80 ms, which is still meaningful for LCP. Adoption is now broad: Cloudflare, Fastly, Akamai, AWS CloudFront, and Google Cloud all support HTTP/3 by default. Verify your site is serving HTTP/3 by checking the protocol column in Chrome DevTools Network tab, or via tools like cloudflareradar.com/scan. Most modern hosts (Vercel, Netlify, Render) enable HTTP/3 automatically; if youre on a legacy CDN, upgrading is a one-flag change. Note that HTTP/3 still falls back to HTTP/2 or HTTP/1.1 for browsers and networks that do not support it, so there is no compatibility risk. The Grigora checker reports the protocol used during the audit.

Free Page Performance Checker Lite

Quick page speed audit: load time, weight, response size. Lightweight Core Web Vitals snapshot. Free, instant.

4.6on G2

4.8on Trustpilot

Used by 25,000+ marketers

What this tool does

Page Performance Checker Lite delivers fast, reliable results for quick page speed audit: load time, weight, response size. lightweight core web v.

Designed to fit into your existing SEO and content workflow with no setup overhead.

How to use it

Five steps.

Paste your URL

Enter any public URL; the tool runs a Lighthouse-based audit from a clean browser instance.

Read the score

See LCP, INP, CLS, FCP, and TTFB with color-coded thresholds.

Inspect the breakdown

Identify the LCP element, slowest scripts, and CLS sources to focus your fixes.

Compare mobile vs desktop

Spot mobile-only regressions where script execution time dominates.

Re-run after deploys

Verify each fix actually moves the metric in the right direction before declaring victory.

When teams use it

Six common workflows.

Engineering teams shipping daily

Run a quick performance check on every staging URL before deploying to production to catch regressions early.

SEO consultants delivering technical audits

Identify the top 10-20 pages with poor Core Web Vitals and quantify the ranking risk in client deliverables.

Product managers benchmarking competitors

Run the same checker on your homepage and three competitors to spot opportunity gaps for marketing positioning.

Designers verifying mockup decisions

Confirm that hero image and font choices do not blow LCP budgets before committing the design to engineering.

Marketers optimizing ad landing pages

Check landing page performance pre-launch so paid traffic does not bounce due to slow load.

CTOs reporting to leadership

Pull a quick performance score for board updates without spinning up a full monitoring suite.

Platform guides

Integrate with major platforms.

Google PageSpeed Insights

Visit pagespeed.web.dev.
Paste your URL and click Analyze.
Review the field data (top) and lab data (below).
Click any opportunity to see specific recommendations.

Lighthouse CLI

Install via npm: npm install -g lighthouse.
Run: lighthouse https://example.com --view.
Get an HTML report locally without depending on a hosted service.
Use --preset=desktop or --form-factor=desktop for desktop runs.

Lighthouse CI

Add @lhci/cli to your CI config.
Define performance budgets in lighthouserc.js (LCP, JS bundle, etc.).
Run lhci autorun on each pull request.
Fail the build if any budget is exceeded.

WebPageTest

Visit webpagetest.org.
Enter URL, choose location, browser, connection profile.
Click Start Test and wait 30-60 seconds.
Use the filmstrip view to see exactly when each visual element appears.

Chrome DevTools

Open the page and press F12.
Go to the Performance tab and click Record.
Reload the page; stop the recording.
Inspect the flame graph for long tasks, layout shifts, and render-blocking resources.

Grigora vs. alternatives

Side-by-side.

Capability	Grigora	Tool A	Tool B	Free	Manual
LCP, INP, CLS measurement	Yes	Yes	Yes	Lab only	Manual
Mobile + desktop side-by-side	Yes	Toggled	Yes	No	Manual
Field data via CrUX	Yes	Yes	Paid tier	No	No
Element-level LCP attribution	Yes	Yes	Yes	Limited	DevTools
JavaScript bundle breakdown	Yes	Limited	Yes	Yes	Manual
Free without signup	Yes	Yes	Free tier	Yes	N/A
Third-party script profiling	Yes	Limited	Yes	Limited	Manual
CI/CD integration	Coming soon	CLI only	API	No	Custom

Common errors and fixes

Eight issues users hit.

LCP element is a slow-loading hero image

Cause: The hero image is large, lazy-loaded, or served from a slow origin.

Fix: Preload the image with <link rel="preload">, serve as AVIF or WebP at the rendered size, and ensure not lazy-loaded.

INP regression from new analytics script

Cause: A third-party script blocks the main thread for 300+ ms during interaction.

Fix: Defer the script with async or use Partytown to move it to a Web Worker; remove if not essential.

CLS spike from cookie consent banner

Cause: The banner inserts above existing content after page load, pushing everything down.

Fix: Render the banner with a fixed position and reserved height, or load it immediately in the initial HTML.

TTFB over 1 second

Cause: Server-side rendering with a slow database query or no edge caching.

Fix: Cache the response at the CDN, optimize the slow query, or move the page to static generation if data does not change frequently.

Render-blocking JavaScript in head

Cause: Synchronous <script> tags load before HTML parsing continues.

Fix: Add async or defer attributes, or move scripts to the end of body when possible.

Web font causes FOIT

Cause: Font is set to font-display: block (default), hiding text until font loads.

Fix: Add font-display: swap or font-display: optional to your @font-face rule.

Missing image dimensions cause CLS

Cause: Images do not have width and height attributes.

Fix: Add explicit width and height to every <img> tag, or use aspect-ratio CSS for responsive images.

Slow Lighthouse score on local dev but fast in production

Cause: Lighthouse runs against a Webpack dev build with no minification or code splitting.

Fix: Always test against a production build; use a staging URL for accurate measurements.

Original data

2026 study.

34%

B2B SaaS homepages with poor INP in our 2026 audit of 500 sites

420 KB

Median JavaScript transferred per top-100 marketing site

-1.2s

Average LCP improvement from preloading the hero image

+9%

Conversion lift when INP drops from 400ms to 150ms (2025 Akamai)

Frequently asked questions

Twelve answers.

Related free tools

Other utilities.

Try Page Performance Checker Lite now

Free, unlimited, no signup.

Try the Tool