March 30, 2026 Technical SEO Performance

Core Web Vitals for SaaS: Why Your Website Is Losing Rankings to Faster Competitors

Q: What is a good LCP score for a SaaS website?

Google considers LCP under 2.5 seconds as 'Good.' Between 2.5s and 4s needs improvement, and over 4s is poor. Most SaaS sites we audit have LCP between 3-6 seconds — well into the 'poor' range. The biggest culprits are unoptimized hero images, render-blocking JavaScript, and client-side rendering frameworks that delay meaningful content display.

We've audited over 70 funded SaaS websites. The pattern is consistent: most have terrible page speed. Heavy JavaScript bundles, unoptimized images, layout shifts everywhere. Google measures all of this — and it's costing you rankings and conversions.

68%

of SaaS sites we audited fail at least one Core Web Vital

4.2s

average LCP across audited SaaS homepages

53%

of mobile visitors leave if load time exceeds 3 seconds

What Are Core Web Vitals?

Core Web Vitals are three specific metrics Google uses as ranking signals. They measure real user experience — not just server response time. Since 2021, they've been part of Google's page experience signals, and with every algorithm update, their weight has increased.

Metric	What It Measures	Good	Needs Work	Poor
LCP (Largest Contentful Paint)	How fast the main content loads	≤ 2.5s	2.5–4s	> 4s
INP (Interaction to Next Paint)	How fast the page responds to clicks/taps	≤ 200ms	200–500ms	> 500ms
CLS (Cumulative Layout Shift)	How much the page layout jumps around	≤ 0.1	0.1–0.25	> 0.25

        Why this matters for SaaS specifically: Your marketing site is the first impression. If it's slow, visitors assume your product is slow too. B2B buyers are evaluating multiple tools — the one that loads instantly gets more attention.
    

The 7 Most Common Speed Killers on SaaS Websites

After auditing dozens of SaaS sites — from seed-stage to Series C — these are the issues we find most frequently. They're ordered by impact.

Issue #1 — Most Common

Unoptimized Hero Images and Videos

The biggest LCP killer. SaaS sites love large hero images and product screenshots. But a 2MB PNG hero image means visitors wait 3-5 seconds just for the above-the-fold content.

What we find: Hero images in PNG format (should be WebP/AVIF), no explicit width/height attributes (causes CLS), no lazy loading on below-fold images, and autoplaying background videos that download 10-50MB on page load.

Fix

Convert all images to WebP or AVIF format (60-80% smaller than PNG)
Add width and height attributes to every <img> tag
Use loading="lazy" on all images below the fold
For hero images, use fetchpriority="high" and preload with <link rel="preload">
Replace background videos with animated WebP or a static image + play button

<!-- Before: 2MB PNG, no dimensions, blocks LCP -->
<img src="/hero-dashboard.png" alt="Dashboard">

<!-- After: 200KB WebP, dimensions set, prioritized -->
<img src="/hero-dashboard.webp" alt="Dashboard"
     width="1200" height="675"
     fetchpriority="high">

Issue #2 — Critical

Render-Blocking JavaScript Bundles

SaaS marketing sites built with React, Next.js, or Vue often ship massive JavaScript bundles. The browser can't paint anything until it downloads and parses these scripts. We regularly see 500KB-2MB of JavaScript on a marketing homepage that's essentially a brochure.

What we find: No code splitting (entire app ships on homepage), analytics/chat/tracking scripts in the <head> without async/defer, unused JavaScript from npm packages, and client-side rendering of static content.

Fix

Add async or defer to all third-party scripts (analytics, chat widgets, tracking pixels)
Implement code splitting — only load JS needed for the current page
Audit your bundle with npx webpack-bundle-analyzer or Next.js's built-in analyzer
Move to SSG (Static Site Generation) for marketing pages — no JS needed to render content
Lazy-load chat widgets, video embeds, and interactive demos

<!-- Before: Blocks rendering -->
<script src="https://analytics.example.com/tracker.js"></script>
<script src="https://chat.example.com/widget.js"></script>

<!-- After: Non-blocking -->
<script async src="https://analytics.example.com/tracker.js"></script>
<script defer src="https://chat.example.com/widget.js"></script>

Issue #3 — Sneaky

Web Font Loading Causing Layout Shifts

Almost every SaaS site uses custom fonts (Inter, Poppins, DM Sans). When these load late, text reflows and the entire layout shifts — killing your CLS score. We see CLS scores of 0.3-0.5 on sites that look perfectly stable visually — because the shift happens in the first 500ms.

Fix

Use font-display: swap in your @font-face declarations
Preload your primary font: <link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
Self-host fonts instead of loading from Google Fonts (eliminates DNS lookup + connection time)
Use size-adjust CSS property to match fallback font metrics to your custom font

/* Prevent layout shift from font loading */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

Issue #4 — Hidden Cost

Third-Party Script Overload

SaaS sites stack third-party scripts: Google Analytics, Hotjar, Intercom, HubSpot, Segment, Sentry, Amplitude, LinkedIn Insight, Facebook Pixel, Google Ads. Each one adds 50-200KB and fires network requests. Ten scripts = 1-2MB of extra JavaScript + 20+ extra network requests.

Fix

Audit every third-party script — remove ones nobody checks
Use Google Tag Manager to lazy-load scripts after page load
Replace heavy tools with lightweight alternatives (Plausible instead of GA4, Crisp instead of Intercom)
Load non-critical scripts on user interaction (scroll, click) instead of page load
Set a script budget: no more than 3-4 third-party scripts on marketing pages

Issue #5 — Framework Tax

Client-Side Rendering on Marketing Pages

This is the SaaS-specific trap. Your product is a web app built with React/Vue/Angular. So your marketing site uses the same framework. But marketing pages don't need client-side rendering — they're static content. CSR means the browser downloads JavaScript, executes it, and only then renders your page. Googlebot might not wait.

The real cost: We've measured LCP differences of 2-4 seconds between CSR and SSG for identical content. That's the difference between Google ranking you and ignoring you.

Fix

Use SSG (Static Site Generation) for all marketing pages, blog posts, and documentation
In Next.js: use generateStaticParams and avoid 'use client' on marketing pages
Consider a separate static site for marketing (Astro, Hugo, plain HTML) decoupled from the app
If stuck with CSR, implement server-side rendering (SSR) at minimum

Issue #6 — Quick Win

No CDN or Poor Caching Headers

Some SaaS sites serve everything from a single origin server. No CDN means visitors in different regions get wildly different load times. And without proper cache headers, browsers re-download the same assets on every page visit.

Fix

Deploy on a CDN (Vercel, Cloudflare Pages, Netlify, AWS CloudFront)
Set Cache-Control: public, max-age=31536000, immutable for static assets (CSS, JS, images)
Use content hashing in filenames (e.g., app.a1b2c3.js) for safe long-term caching
Set shorter cache for HTML pages: Cache-Control: public, max-age=3600, s-maxage=86400

Issue #7 — Death by Popup

Chat Widgets and Cookie Banners Causing CLS

Intercom, Drift, Crisp — they all inject floating elements that shift your page layout. Cookie consent banners that slide in from the bottom push your entire footer up. These micro-shifts add up and tank your CLS score.

Fix

Reserve space for chat widgets with CSS (fixed positioning doesn't cause CLS, but the button appearing can)
Use overlay-style cookie banners (positioned with position: fixed) instead of banners that push content
Delay chat widget initialization by 3-5 seconds — most visitors don't need it immediately
Pre-allocate space: min-height on sections where dynamic content will appear

How to Measure Your Core Web Vitals

Don't guess — measure. Here's the toolkit:

1. Google PageSpeed Insights

Go to pagespeed.web.dev and enter your URL. You get two types of data:

Field data (real users) — from Chrome User Experience Report. This is what Google actually uses for ranking. Only available for sites with enough traffic.
Lab data (simulated) — from Lighthouse. Useful for debugging but not what Google ranks on.

2. Google Search Console

The Core Web Vitals report in GSC groups your URLs into Good, Needs Improvement, and Poor. This is the most direct view of how Google sees your site speed. Check it monthly.

3. Chrome DevTools Performance Tab

For developers: open DevTools → Performance → Record a page load. You'll see exactly which resources block rendering, where layout shifts happen, and what causes slow interactions.

⚠️ Common mistake: Testing only on fast Wi-Fi with a powerful laptop. Google tests on simulated mid-range mobile devices with 4G connections. Use Chrome DevTools to throttle your network and CPU for realistic results.

A Real-World Optimization Checklist

Use this checklist to systematically improve your SaaS site's Core Web Vitals:

Quick Wins (under 1 hour)

Add async or defer to all third-party <script> tags
Add width and height attributes to all <img> tags
Add loading="lazy" to images below the fold
Add fetchpriority="high" to your hero/LCP image
Preload your primary web font
Check for and remove unused third-party scripts

Medium Effort (1-4 hours)

Convert images from PNG/JPG to WebP format
Self-host Google Fonts
Implement code splitting for JavaScript
Move chat widget initialization to delayed loading
Set up proper cache headers for static assets
Add <link rel="preconnect"> for critical third-party origins

Significant Effort (1-2 weeks)

Migrate marketing pages from CSR to SSG
Deploy on a CDN if not already
Implement responsive images with <picture> and srcset
Audit and reduce JavaScript bundle size by 50%+
Implement route-based code splitting

The SEO Impact: What Faster Sites Actually Get

Speed isn't just a nice-to-have. Here's what the data shows:

Ranking boost: Google has confirmed Core Web Vitals as a ranking signal. Sites that pass all three metrics have a measurable advantage, especially in competitive SERPs where content quality is similar.
Lower bounce rate: A 1-second improvement in LCP reduces bounce rate by 7-12% on average.
Better crawl efficiency: Faster sites get crawled more frequently by Googlebot. More pages indexed = more search visibility.
Higher conversion rates: Shopify reported a 7% increase in conversion for every 100ms improvement in LCP. SaaS trial signups follow the same pattern.

        The compound effect: Better speed → more crawling → more indexed pages → better rankings → more traffic → more conversions. It's not just about the ranking signal — it's about the entire user journey.
    

SaaS-Specific Gotchas

A few things we see specifically on SaaS marketing sites that general speed guides miss:

Product Demo Embeds

Interactive product demos (Storylane, Navattic, Arcade) embed iframes that load their own JavaScript. Lazy-load these — use an IntersectionObserver to only load the iframe when it's about to scroll into view.

Pricing Page Calculators

Dynamic pricing calculators with sliders, toggles, and currency selectors often import heavy charting libraries. Load these on interaction, not on page load.

Customer Logo Carousels

20 high-res customer logos in a carousel = 20 image requests on page load. Use CSS sprites or inline SVGs. Even better: show 6 static logos and skip the carousel — they rarely engage visitors.

Video Testimonials

Embedding YouTube or Vimeo videos on your homepage adds 500KB+ of JavaScript from their players. Use lite-youtube-embed or similar — it loads a thumbnail first and only loads the player on click.

Not Sure Where Your Site Stands?

We'll audit your Core Web Vitals, find what's slowing you down, and give you a prioritized fix list — free.

Get Your Free Speed Audit →

Frequently Asked Questions

What are Core Web Vitals and why do they matter for SaaS websites?

Core Web Vitals are three performance metrics Google uses as ranking signals: Largest Contentful Paint (LCP) measures how fast your main content loads, Interaction to Next Paint (INP) measures responsiveness to user input, and Cumulative Layout Shift (CLS) measures visual stability. For SaaS websites, these directly affect both search rankings and conversion rates — slow sites lose visitors before they even see your product.

What is a good LCP score for a SaaS website?

Google considers LCP under 2.5 seconds as "Good." Between 2.5s and 4s needs improvement, and over 4s is poor. Most SaaS sites we audit have LCP between 3-6 seconds — well into the "poor" range. The biggest culprits are unoptimized hero images, render-blocking JavaScript, and client-side rendering frameworks that delay meaningful content display.

Does page speed actually affect SaaS conversion rates?

Yes, significantly. Research consistently shows that every additional second of load time reduces conversions by 7-12%. For a SaaS site getting 10,000 monthly visitors, shaving 2 seconds off load time could mean 15-25 more trial signups per month. Google's own data shows 53% of mobile visitors abandon sites that take over 3 seconds to load.

How do I check my SaaS website's Core Web Vitals?

Use Google PageSpeed Insights (pagespeed.web.dev) for a quick check — it shows both lab data and real-user field data from the Chrome User Experience Report. Google Search Console has a Core Web Vitals report showing which URLs pass or fail. For deeper analysis, use Chrome DevTools Performance tab, Lighthouse audits, or web.dev/measure.

What causes high CLS on SaaS websites?

The most common CLS issues on SaaS sites: (1) Images and videos without explicit width/height attributes. (2) Web fonts causing Flash of Unstyled Text — text reflows when the custom font loads. (3) Dynamically injected banners, chat widgets, or cookie consent bars that push content down. (4) Ads or third-party embeds that load after the page renders.

Should I use SSR or SSG for better Core Web Vitals on my SaaS site?

Static Site Generation (SSG) generally produces the best Core Web Vitals because pages are pre-built and served from a CDN with no server processing. For SaaS marketing pages, pricing pages, and blog posts, SSG is ideal. Use Server-Side Rendering (SSR) only for pages that need real-time data. Avoid pure Client-Side Rendering (CSR) for any public-facing page — it kills LCP because the browser has to download, parse, and execute JavaScript before showing any content.