Core Web Vitals for SaaS marketing sites: what to fix first

The three metrics in plain words

Core Web Vitals are three measurements Google publishes to describe how a page feels to a real visitor. They are documented on web.dev. For a SaaS marketing site, they are a useful checklist, because speed affects both first impressions and sign-ups.

• Largest Contentful Paint (LCP) is how long it takes for the biggest thing on screen, usually the hero image or headline, to show up. Google's "good" mark is 2.5 seconds or less.
• Interaction to Next Paint (INP) is how quickly the page reacts when someone clicks, taps or types. It replaced an older metric called First Input Delay in March 2024. "Good" is 200 milliseconds or less.
• Cumulative Layout Shift (CLS) is how much the page jumps around while it loads. You know the feeling: you go to tap a button and an ad pushes it down. "Good" is 0.1 or less.

Google judges these on real visitors, at the 75th percentile. That means three out of four visits should meet the mark, not just your fast laptop on office wifi.

How to measure

Measure before you change anything, or you will not know what helped. There are two kinds of data.

Field data comes from real users. The best free place to see it is PageSpeed Insights, which shows the real-user numbers for your URL when there is enough traffic. Google Search Console also has a Core Web Vitals report for your whole site.

Lab data comes from a test run on one device with set conditions. Lighthouse, which is built into Chrome DevTools and also runs inside PageSpeed Insights, gives you this. It is repeatable and tells you what to fix, but it is a simulation.

Use both. Field data tells you if you have a problem. Lab data helps you find the cause. Test on a throttled mobile profile too, because a marketing site is often opened on a phone.

Write down your starting numbers for your three or four most important pages: home, pricing, and the pages you send ad traffic to.

Fix images first

On many marketing sites we look at, images are the main cause of a slow LCP. They are also the easiest to improve.

• Use the right size. A 4000-pixel-wide photo shown in a 800-pixel box wastes bandwidth. Export at the size you need, and use responsive images (srcset) for different screens.
• Use modern formats. WebP and AVIF are usually much smaller than PNG or JPEG at similar quality, and all major browsers support them.
• Do not lazy-load the hero image. Lazy-loading is great for images below the fold. For the main image at the top, it makes the page slower. Load it right away, and give it fetchpriority="high" so the browser knows it matters.
• Compress screenshots. Product screenshots on SaaS sites are often huge PNGs. Resize them and convert them.
• Replace video with an image where you can. A looping background video in the hero costs a lot. If you keep it, give it a still poster image that loads fast.

Always set width and height (or an aspect ratio) on images. That also helps layout shift, which we come to next.

Fonts and layout shift

Fonts cause two problems: slow text and jumping text.

• Use fewer fonts and fewer weights. Each file is a request. Two weights of one family cover most designs.
• Serve fonts from your own domain. It avoids an extra connection to another server.
• Preload the main font used above the fold, and use font-display: swap so text shows at once in a fallback font.
• Match the fallback font's size. If your fallback and your custom font have different sizes, the text jumps when the real font arrives. CSS tools like size-adjust can reduce that.
• Subset your fonts. If you only write in Latin letters, do not ship every alphabet.

Other causes of layout shift are easy to find once you know them:

• Images and videos with no size set.
• Cookie banners and announcement bars that push content down after load. Reserve their space, or overlay them.
• Embeds, like maps or videos, that load late. Give them a box of the right size first.
• Content injected above existing content by a script.

The web.dev guide to CLS covers each cause in more detail.

Third-party scripts

This is the part marketing teams often do not see, because the scripts are added one at a time. Analytics, tag managers, chat widgets, heatmaps, A/B testing tools, ad pixels, review badges. Each one is small. Together they can make a page slow and sluggish to click, which is what INP measures.

What to do:

1. List every script on the page. The Network tab in DevTools shows them. You may find ones that nobody remembers adding.
2. Remove what you do not use. A heatmap tool nobody has opened in six months is pure cost.
3. Load the rest later. Use async or defer, and load chat widgets only after the visitor interacts or after the page is idle.
4. Do not hide the page behind an A/B tool. Some tools hide the page until they decide which version to show. That hurts LCP.
5. Check again after marketing adds something. Make this a habit. A single new tag can undo a month of work.

Framework choices

The framework matters, but less than what you put on the page. A fair summary:

• Static or server-rendered sites (Astro, Next.js with static pages, and similar) send ready HTML. They tend to do well on LCP out of the box.
• Heavy client-side apps that build the page in the browser need more care. Large JavaScript bundles hurt both LCP and INP.
• Framer and similar builders can produce fast sites, and are easy to edit. You have less control over the final code.
• Page builders with many plugins, as often seen on WordPress sites, can add a lot of extra code. They can be fast, but only with discipline.

Any of these can be fast or slow. Choose by who edits the site and what the page needs to do. Then check the numbers.

A pre-launch check

Before any launch, we run through this list:

1. Run PageSpeed Insights on the home, pricing and one landing page. Look at mobile first.
2. Check the LCP element. Is it what you expect, and is it loaded early?
3. Scroll while the page loads, on a slow connection, and watch for jumps.
4. Click the menu, the main button and a form field. Does the page respond at once?
5. Open the Network tab and look for large files and unknown scripts.
6. Test on a real mid-range phone, not only on a desktop.
7. Save the results, so you can compare after your next change.

This is part of how we build a marketing website: we aim for a site that passes Core Web Vitals, and we check it before launch. We also build our own products, which you can see in the Lab. If you are on a SaaS team and want a second opinion, read about our SaaS design agency work or send us the URL of your slowest page for a free design review.