# Core Web Vitals for SaaS Sites

> Core Web Vitals measure loading, responsiveness and layout stability. Where SaaS sites usually fail, how to read field data, and how much effort it deserves.

Source: https://comppound.com/blog/core-web-vitals-for-saas-sites (published 2026-10-30)

Core Web Vitals are Google's three measures of how a page feels to real visitors: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. For a SaaS site, they matter most on pages that win you customers, such as your homepage, pricing and landing pages, and the bulk of the problems tend to come from third-party scripts and heavy hero sections.

Treat them in proportion. [Google's page experience documentation](https://developers.google.com/search/docs/appearance/page-experience) says good Core Web Vitals align with what its ranking systems reward, but that great page experience alone doesn't guarantee good rankings, and it can't make up for weak content. Fix real problems on important templates, and don't turn a perfect lab score into a project.

## What the three metrics measure

[Google's thresholds on web.dev](https://web.dev/articles/vitals) are measured at the 75th percentile of page visits, split between mobile and desktop.

| Metric | What it measures | Good | Poor |
| --- | --- | --- | --- |
| Largest Contentful Paint (LCP) | How long until the main content appears | 2.5 seconds or less | More than 4 seconds |
| Interaction to Next Paint (INP) | How quickly the page responds to clicks and taps | 200 milliseconds or less | More than 500 milliseconds |
| Cumulative Layout Shift (CLS) | How much the layout jumps around | 0.1 or less | More than 0.25 |

INP replaced First Input Delay as a Core Web Vital in 2024, so older guides may mention a metric that no longer applies.

## Field data and lab data measure different things

This distinction clears up a lot of confusion.

**Field data** comes from real Chrome users, through the Chrome User Experience Report. It's what Search Console's Core Web Vitals report shows, and it's what matters for Google's assessment. It has a delay, as it's collected over a rolling 28-day period, so a fix won't appear in it right away.

**Lab data** comes from a simulated test, such as a Lighthouse run. It's good for debugging, since it's immediate and repeatable. A lab test can't measure INP, because no real person is clicking, so it uses a proxy instead.

So you might score poorly on Lighthouse while real users are fine, particularly if your visitors are office workers on fast connections. Or the opposite can be true. If your site lacks enough traffic for field data, PageSpeed Insights will tell you so. That's common on a small SaaS site. Use lab tests to catch regressions, and don't lose sleep over small changes in the score.

## Where SaaS sites typically go wrong

Say you run a 30-person SaaS selling sales enablement software, and your marketing site is built on Next.js. Here are the usual suspects.

**Hero videos and animated demos.** Your hero is probably the LCP element. A large autoplay video or a heavy animation delays it. Use a compressed poster image, and only load the video once the page is ready. Don't lazy-load the hero image, since that delays exactly what's being measured. Use `fetchpriority="high"` on it instead.

**Marketing scripts.** Analytics, heatmaps, chat widgets, A/B testing, session replay, intent data and ad pixels all pile up, as each was added by someone with a good reason. Together, they can slow the page and hurt INP. Read [whether your SaaS website should have a chatbot](/blog/should-your-saas-website-have-a-chatbot) with this cost in mind. List every tag, ask who still uses it, and remove the ones nobody can defend. Load the rest later where you can.

**A/B testing tools that hide the page.** Client-side testing tools often hide content until they've loaded, to avoid flicker. That delays LCP for every visitor, including those not in a test.

**Too much client-side JavaScript.** When a marketing site is built with the same components as the product, it may ship a large bundle for a page that's mostly text. That hurts INP, as the browser's busy processing JavaScript when someone tries to click. Use server components and static rendering for marketing pages, and keep interactive parts small. Our guide to [JavaScript SEO](/blog/javascript-seo-for-saas-sites-built-on-react-and-nextjs) covers the rendering side.

**Cookie banners and announcement bars.** Elements that appear late and push content down are classic causes of CLS. Reserve space for them, or overlay them without moving the content.

**Images and embeds without dimensions.** Screenshots of the product and customer logos without set widths and heights will cause jumps as they load. Next.js's `Image` component handles much of this, but only if you use it consistently.

**Web fonts.** A brand font that swaps in late can shift text, and can delay LCP if it's the hero heading. Preload the key fonts, and use a fallback font with similar metrics. `next/font` helps with this.

## How to prioritize the work

Search Console groups URLs with similar problems, and that's your best starting point.

1. **Open the Core Web Vitals report.** Look at mobile first, then desktop. Note which issue affects which group of URLs.
2. **Open the example URLs in PageSpeed Insights.** Field data sits at the top, with diagnostics below. They'll usually name the LCP element and show which scripts are the heaviest.
3. **Fix by template.** On a SaaS site, one fix to a landing page template can improve hundreds of pages.
4. **Order by business value.** Pricing, your homepage and your top landing pages come before old blog posts.
5. **Validate and wait.** Mark the fix as validated in Search Console, then allow for the 28-day data window.

Also consider who's visiting. B2B buyers may mostly be on desktop at work, whereas your ads might bring in mobile visitors with poorer connections. Check your analytics to see where the slow experience really affects people.

## The conversion argument is often stronger than the SEO one

Rankings are only part of the case. A pricing page that takes several seconds to show its plans, or a demo button that doesn't respond for half a second, costs you conversions, whatever the rankings do. Our post on [page speed and SaaS conversions](/blog/page-speed-and-saas-conversions) goes further.

Don't rely on general statistics about how much each second costs. Those numbers come from other businesses in other markets. If you want a number for your own site, compare conversion rates for faster and slower sessions, or test a change on a landing page. [A/B testing with low traffic](/blog/a-b-testing-with-low-traffic) explains how to do that when volumes are small.

## When to stop

Going back to the sales enablement SaaS, suppose your pricing and landing pages are now in the "good" range, and the only warnings left are on a few old blog posts. It's time to stop and do something else. Moving from "good" to "better" is rarely worth more than writing a comparison page you lack.

Keep what you've gained by making speed part of your process:

- Set a budget for bundle size or Lighthouse scores, and check it automatically in your deployment pipeline.
- Have someone approve every new third-party script, and record who asked for it.
- Review your tag manager every quarter, since tags accumulate quietly.
- Re-check the report after each redesign.

Core Web Vitals are one line on [a technical SEO checklist](/blog/technical-seo-checklist-for-saas-companies-a-step-by-step-guide). If you need a plan that weighs them against everything else competing for engineering time, [see how we approach SEO for B2B SaaS](/services/seo-growth).

## Frequently asked questions

### Are Core Web Vitals a ranking factor?

Google says good Core Web Vitals align with what its ranking systems reward, but great page experience alone doesn't guarantee top rankings. Relevance and content quality come first.

### What is a good Core Web Vitals score?

LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of real visits.

### Why does Search Console show different results from Lighthouse?

Search Console uses field data from real Chrome users over a rolling period. Lighthouse runs a simulated test on one load. Use field data to judge, and lab tests to debug.

### How long do Core Web Vitals fixes take to show?

Field data is collected over a rolling 28-day window, so improvements appear gradually. Lab tools will show the effect immediately, which helps you confirm the fix worked.

## About Comppound

Comppound runs SEO and AI search for B2B SaaS companies: a person sets the plan and reviews samples and every high-risk page, and AI speeds up production.

- [Check a page free](https://comppound.com/tools/seo-checker): Check one of your pages before you change anything else
- [See pricing](https://comppound.com/pricing): Want the content written, reviewed and published for you?