How to Pass Core Web Vitals on Your Indie SaaS Site in a Weekend

A slow marketing site and signup page cost you signups before search rankings ever move. Fix Core Web Vitals on the few pages that matter: home, pricing, signup, and your top organic page. Measure with real-user (field) data when you have it, use lab tools and a throttled phone when you do not, then cut the usual indie culprits in order of payoff: the hero image, fonts, third-party scripts, layout shift, heavy JavaScript, and slow first-byte times. You can do a useful pass in a weekend without a rebuild.

Why does page speed matter for signups and search?

Most visitors decide in seconds. On a phone, a heavy hero video, a chat widget, and a late-loading font can make the page feel broken even when the product is fine. That is a conversion problem first. Search is the second reason, and it needs honest framing.

Google's guidance on page experience in Search results is clear: Core Web Vitals are used by ranking systems, but there is no single "page experience signal", and relevance still wins. For many queries there is lots of helpful content; a better page experience can help when quality is similar. Getting a perfect score in a report just for SEO is not the best use of a solo founder's weekend. Fix speed so people can sign up. Treat ranking as a bonus.

If your funnel dies after signup instead of before it, speed is not your first fire. Pair this work with fixing the first ten minutes after signup once the landing page loads cleanly.

What are Core Web Vitals in plain words?

Per Google's Web Vitals overview, three metrics cover loading, interactivity, and visual stability. A page "passes" when all three hit the good threshold at the 75th percentile of visits, usually checked separately for mobile and desktop:

• Largest Contentful Paint (LCP): how soon the main content shows. Good: 2.5 seconds or less.

• Interaction to Next Paint (INP): how soon the page reacts after a tap or click. Good: 200 milliseconds or less.

• Cumulative Layout Shift (CLS): how much the layout jumps while loading. Good: 0.1 or less.

INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. If an old checklist still talks only about FID, update it.

A running example (made up)

Everything in this example is invented: the product, the founder, and every number. Loadfern is a small SaaS that turns a spreadsheet of client deliverables into a shared status page for freelance designers. The founder, Mira, has about 90 paying users. Her marketing site is a Framer template with a full-bleed hero video, three web font weights, a chat widget, a heatmap script, and an embedded Calendly. Pricing and signup live on the same origin. PageSpeed Insights shows poor mobile LCP on the home page and no URL-level field data yet, only origin-level hints. Over one weekend she audits five URLs and ships a short fix list.

Field data vs lab data: which numbers should you trust?

Field data is what real Chrome users experienced. It comes from the Chrome User Experience Report (CrUX) and shows up in PageSpeed Insights and Search Console's Core Web Vitals report. Google's PageSpeed Insights overview says real-user metrics cover a trailing 28-day collection period, and a URL needs enough samples to appear. If the page or whole origin is too quiet, PSI may show no field data. That is normal for a young indie site. It is not a failing grade.

Lab data is a simulated run (Lighthouse inside PSI or Chrome DevTools) on a fixed device and network profile. Lab is great for finding what to fix. It is a poor substitute for claiming "we pass Core Web Vitals" in public, because real phones, caches, and click paths differ. Lighthouse also cannot score INP the way the field does (no real user input); Total Blocking Time is a lab proxy for interactivity problems.

When you have no field data:

1. Run PageSpeed Insights on each important URL anyway and read the lab section.

2. Open the same URL on a real mid-range phone on cellular or a throttled profile, not only on your laptop Wi-Fi.

3. Watch signup yourself once, then ask one or two people to try it on their phones while you stay quiet. That habit pairs well with watching real people sign up on their phones before a launch.

CrUX updates on a rolling window, so a Friday fix will not flip Search Console green on Monday. Plan a re-check after the 28-day window has absorbed the change.

How do you run a 30-minute audit on the pages that matter?

Do not start with the blog archive. Audit the URLs that sit on the money path:

1. Home / landing

2. Pricing (if separate)

3. Signup or "Start free"

4. Your top organic landing page from Search Console (if you have one)

5. Optional: the logged-out docs or comparison page that already gets traffic

For each URL, paste it into PageSpeed Insights, save the mobile field row if it exists, save the mobile lab LCP/CLS and the top opportunities, then note the LCP element (often the hero image or H1 block). Write one sheet with columns: page, metric, before, change, after, date. Mira's first sheet (made-up numbers) looked like this after the audit, before fixes:

Thirty minutes is enough to know whether you have an image problem, a script problem, or a server/TTFB problem. Do not optimize everything you see in Lighthouse on day one.

What are the usual indie culprits, ranked by payoff?

Fix in this order unless your audit points somewhere else. The table below is a working map from culprit to metric.

Hero media (usually the biggest LCP win)

Google's guide to optimizing LCP is blunt: never lazy-load the LCP image, and give the likely LCP image a high fetch priority so the browser starts it early. Discover the image from the HTML (a normal <img> with src/srcset), not only from a late JavaScript carousel. Serve a modern format and a size that matches the display width. Autoplay background video is a common Framer/Webflow habit that costs more than it sells; a compressed still that looks intentional usually signs people up just as well.

A practical hero checklist you can finish in an hour:

• Export the current hero at 2x the largest display width, then compress to WebP or AVIF and keep a JPEG fallback if you must.

• Confirm the LCP image appears in the initial HTML, not only after a client-side framework paints.

• Add width and height (or CSS aspect-ratio) so the browser reserves space.

• Set fetchpriority="high" on that one image; leave other images alone or lower priority.

• Remove loading="lazy" from the LCP image if a template added it.

• If the hero is a video, try a still frame first for a week and watch signup rate before you bring video back.

Fonts

Two weights of one family beat five weights of two families. Preload only the face used above the fold. If text is your LCP element, a slow webfont can delay the paint; system font stacks for body copy are underrated on marketing pages.

Third-party scripts and embeds

Chat widgets, heatmaps, session replay, multiple analytics tags, and "book a demo" embeds fight for the main thread. Keep one analytics path you actually open. Load chat after the first interaction or after a timeout. For YouTube or Calendly, show a static preview that loads the real embed on click (a facade). Mira deleted the heatmap script she had not opened in six weeks and moved Calendly behind a button (made-up actions, same pattern you can use).

Layout shift

CLS loves cookie banners that push content, announcement bars injected late, images without dimensions, and fonts that reflow the hero. Reserve space in CSS before the banner paints. Set explicit dimensions on images and embeds.

INP and JavaScript

Signup buttons that feel dead often share a page with a large client-rendered bundle. Defer non-critical scripts, split long tasks, and keep the click handler on "Create account" thin. You do not need a full SPA rewrite to make the button respond.

Platform notes (keep them boring)

Whatever built the site, the rules are the same: the LCP image must be discoverable early, small enough, and high priority. In HTML that means a normal image tag with dimensions and fetchpriority="high", as in the optimize-LCP guidance above. Page builders often wrap heroes in backgrounds or late-loaded components; if PSI says your LCP element is a background image, preload that file from the document head or switch to a real <img> in the first paint. If your host offers a one-click image CDN for the marketing site, use it for heroes and ignore it for now on authenticated app screens.

Hosting, CDN caching, and TTFB

Marketing pages should be cacheable at the edge when their content is mostly static. Long redirect chains (ad → link shortener → www → locale) burn LCP before HTML arrives. Keep this about speed, not about shaving hosting bills.

What does a simple before/after sheet look like?

After fixes, Mira's sheet (still made-up numbers, labelled as such) looked like this. Use your own lab or field numbers; do not copy these.

Write the date. Re-run the same PSI URL after deploys. When field data exists, add a second row for CrUX mobile LCP/INP/CLS and expect the 28-day window to lag.

Should you chase a 100 Lighthouse score?

No. A 100 is a lab artifact on a quiet machine. Real users have warm caches, cold caches, ad blockers, and uneven networks. Google's page-experience docs already warn that perfect report scores do not guarantee top rankings. Ship the fixes that move LCP, INP, and CLS on the pages that take money. Ignore advice that trades away clarity (tiny unreadable text, removed consent UI you legally need) just to green a circle.

A 14-day plan you can finish without a rebuild

Times below are planning guesses, not measurements.

How should you re-check after Google's 28-day CrUX window?

Put a calendar reminder ~30 days after your main deploy. Open the same PageSpeed Insights URLs and Search Console's Core Web Vitals report. Compare field mobile LCP, INP, and CLS to your sheet. If lab improved but field did not, look for regressions you shipped since (new marketing section, new tag, a "temporary" popup). If field improved on home but signup did not, you optimized the wrong URL first. Keep the sheet; it is the only memory you will trust later.

Search Console groups similar URLs. A template change can move a whole group. When a group flips from "poor" to "need improvement" or "good", note the date next to the deploy that likely caused it. Do not thrash daily. CrUX is a slow mirror.

Common traps

• Optimizing the blog while signup is slow. Money path first.

• Lazy-loading the hero because a template said so. That often hurts LCP on purpose.

• Stacking three analytics tools "just in case". One you read beats three you ignore.

• Declaring victory from one green Lighthouse run on desktop. Check mobile lab, then field when it appears.

• Shipping a new page-builder section that reintroduces a 2 MB image. Add a size check to your release habit.

• Waiting for CrUX before fixing anything. Lab plus a real phone is enough to start.

FAQ

Does a poor Core Web Vitals score mean Google will demote my whole site?

Not in the cartoon way Twitter threads describe. Core Web Vitals feed into page experience, which is one of many signals, and Google still prefers the most relevant result. Fix the pages people land on and convert on.

My PSI report says "no data" for real users. Am I stuck?

No. Insufficient CrUX samples are common under low traffic. Use lab diagnostics, test on a phone, and optionally add your own real-user measurement later. Origin-level data, when shown, is a blunt average across the whole site, so treat it as a hint.

Is a full Next.js or Webflow rebuild required?

Usually not. Most indie wins are asset weight, font restraint, third-party diet, and not lazy-loading the LCP image. Rebuild when the architecture itself blocks those fixes, not as step one.

How do I know the work helped signups?

Track the same funnel you already care about: landing view → signup start → activated account. Speed work without a conversion check is theater. If you are still choosing early metrics, start with tracking the product metrics that matter before your first 100 users.

Where to start this weekend

Open PageSpeed Insights on your home and signup URLs. Write down the LCP element and the top two opportunities. Compress or replace the hero, cut one third-party script, and reserve space for the cookie banner. That afternoon often beats a month of vague "we should improve performance" talk.

When the product behind the faster page is ready for more indie founders to find it, launch it on IndieHunt.