A SaaS landing page should load its main message quickly, respond without delay, and stay still while a visitor reads or clicks. Measure the real page first, find which Core Web Vital is failing, and fix that path before running a general “speed optimization” project.
What are the three Core Web Vitals?
Google's current Web Vitals guidance defines three Core Web Vitals:
- Largest Contentful Paint (LCP) measures loading performance. A good result is 2.5 seconds or less.
- Interaction to Next Paint (INP) measures responsiveness. A good result is 200 milliseconds or less.
- Cumulative Layout Shift (CLS) measures visual stability. A good result is 0.1 or less.
Evaluate the 75th percentile of page visits, split by mobile and desktop. A fast laptop test is useful for debugging, but it does not replace field data from real visits.
Start with field data
Open the deployed landing page in PageSpeed Insights. Check the “Discover what your real users are experiencing” section before the lab score.
Google's Core Web Vitals tools workflow recommends using field data to find the pages and metrics that need attention, then using Lighthouse and browser performance tools to diagnose the cause.
Ask three questions:
- Is the failing data for this exact URL or the whole origin?
- Does the problem affect mobile, desktop, or both?
- Which one of LCP, INP, or CLS is outside the good range?
This keeps the work tied to a user problem. It also prevents a team from shrinking every icon while the real delay comes from the server or a large hero image.
Fix LCP: make the main content easy to find
On a SaaS landing page, the LCP element is often a hero heading or image. Inspect the element reported by PageSpeed Insights or Chrome DevTools instead of guessing.
If the hero image is the LCP element:
- include it in the initial HTML;
- avoid lazy-loading it;
- serve an image close to its displayed size;
- use a modern compressed format where it works;
- give it high fetch priority when it is clearly the main visual.
<img
src="/dashboard-hero.avif"
width="1200"
height="675"
fetchpriority="high"
alt="Dashboard showing a completed weekly report"
/>
Do not preload every image. That makes resources compete with each other. Google's LCP optimization guide recommends making the LCP resource discoverable in the HTML and prioritizing it without taking bandwidth away from other critical files.
If the LCP element is text, inspect server response time, blocking stylesheets, and web fonts. A fast image cannot repair a slow HTML response.
Fix INP: reduce work after a click
INP covers interactions across the visit. On a landing page, common problems include a pricing toggle, signup modal, chat widget, or menu that waits behind a long JavaScript task.
Start by recording a slow interaction in the browser Performance panel. Look for a long task that begins near the click or key press.
Then reduce the work:
- load optional widgets after the main page is ready;
- split large tasks so the browser can update between them;
- remove JavaScript shipped for components the page does not use;
- keep event handlers small;
- avoid rebuilding a large part of the page for one simple interaction.
A delayed pricing toggle is not only a technical score problem. It makes the visitor wonder whether the control worked.
Fix CLS: reserve space before content arrives
CLS problems often appear when a hero image, embedded demo, cookie banner, or web font changes the layout after the visitor starts reading.
Give images and videos an intrinsic size or an aspect ratio:
.hero-demo {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}
Reserve space for banners and embedded tools when their size is known. Avoid inserting a signup bar above content that is already visible. Google's CLS guide lists images without dimensions and dynamically injected content among the common causes of layout shifts.
Test the page beyond its initial load. Some shifts happen only after a visitor accepts a cookie notice, opens a menu, or waits for a widget.
Retest the same path
After each change:
- Run a local performance trace to confirm the intended cause changed.
- Deploy the fix.
- Check the live page with PageSpeed Insights.
- Monitor field data as new visits are collected.
Keep a short note with the page, metric, suspected cause, change, and result. This gives the next developer evidence instead of a vague instruction to “make the site faster.”
Core Web Vitals are useful because each metric points to a different part of the first visit. Fix the failed experience the metric describes, and keep the landing page's main promise visible throughout the work.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)