Website performance for marketers

What Core Web Vitals mean for your leads, what usually slows B2B marketing websites down, and which fixes to ask your developers for first.

Kalle Bertell

By Kalle Bertell

Published · 7 min read

Every campaign you run ends on a web page. If that page is slow to appear, jumps around while it loads, or hesitates when someone clicks, part of the budget you spent to get the visit is wasted before the visitor has read a word.

This guide is for marketing teams who own their company website but don't write its code. It explains which numbers matter, where to find them, what usually makes B2B marketing sites slow, and how to brief your developers so the fixes with the biggest effect come first.

Why speed is a marketing problem

Website speed is usually treated as a technical detail. For a marketing team it affects three things you are measured on:

  • Paid traffic. Google Ads counts landing page experience as one of the components of Quality Score, and a page that takes too long to become usable loses visitors you have already paid for.

  • Organic search. Google's ranking systems use page experience signals, including Core Web Vitals. Google is clear that relevance comes first, so a fast page with weak content won't outrank a better answer. But where many pages are equally helpful, a good page experience can contribute to success. See Google's page experience guidance.

  • First impressions. When a buying committee compares suppliers, your website is part of that comparison. A site that feels sluggish or unstable is not the impression you want to leave.

What are Core Web Vitals?

Google's Core Web Vitals describe how a page feels to real visitors. Each one has a "good" threshold, and a page passes when at least 75% of real visits meet it.

Metric

What it measures

Good

Largest Contentful Paint (LCP)

How quickly the main content, usually the hero image or headline, appears

2.5 seconds or less

Interaction to Next Paint (INP)

How quickly the page responds when someone clicks, taps or types

200 milliseconds or less

Cumulative Layout Shift (CLS)

How much the layout jumps around while it loads

0.1 or less

INP replaced an older metric, First Input Delay, in March 2024. If an agency report or an article still talks about FID, it was written before that change.

Lab data and field data are not the same thing

Tools report two kinds of numbers, and it helps to know which one you are looking at:

  • Field data comes from real Chrome users visiting your site over the last 28 days. This is what Google uses, and what your visitors actually experience.

  • Lab data is a single simulated test run, for example the score at the top of PageSpeed Insights. It is useful for finding causes and checking fixes, but a lab score of 95 doesn't guarantee a good field result, and a lab score of 60 isn't a failure if real visitors are doing fine.

Pages with little traffic often have no field data of their own. In that case, PageSpeed Insights shows data for the whole site instead, and Search Console groups similar pages together, which is still enough to find the problems worth fixing.

Where to look

You don't need special tools. Three free ones cover most of what you need:

  1. Google Search Console, Core Web Vitals report. Shows which groups of pages are poor, need improvement or are good, separately for mobile and desktop, and which metric is failing. Start here.

  2. PageSpeed Insights. Paste in a single URL to see its field data (when available) and a lab test with a list of likely causes.

  3. Your analytics. Use it to decide which pages matter. A slow page with ten visits a month is a lower priority than a slightly slow pricing page or a landing page receiving paid traffic.

What usually slows B2B marketing websites down

These are the causes we run into most often on marketing sites, and they line up with Google's own advice on improving Core Web Vitals. Most of them were added for a good reason, one at a time.

Third-party scripts

Analytics, tag managers, ad pixels, chat widgets, heatmaps, A/B testing tools and cookie banners all run code in your visitors' browsers. Each one seems harmless when it is added, but together they add up, and they hurt INP in particular because their code competes with your own page for the browser's attention. We cover this in detail in How third-party scripts slow your site.

Heavy hero media

Autoplaying background videos, large uncompressed images and carousels in the first screen push LCP up. Hero images should be served in a modern format such as WebP or AVIF, at the size they are displayed, and loaded with priority rather than lazily.

Fonts

Several font families, many weights and fonts loaded from a third-party server all delay text from appearing, and can make the layout shift when the font finally arrives.

Page builders and plugins

Visual page builders and plugin-heavy setups can load code for components a page doesn't use. Marketers get flexibility; visitors can end up downloading code they don't need.

Things that appear late

Cookie banners that push content down, announcement bars, embedded forms and video players without reserved space all cause layout shift. The usual fix is to reserve the space before the element loads.

Slow servers and missing caching

If the server takes a long time to send the first byte of the page, everything else is delayed. Caching pages close to visitors on a content delivery network (CDN) is a common fix.

How to improve Core Web Vitals: what to fix first

Rather than working through a tool's list from the top, combine two questions: which pages matter most, and which metric is failing on them.

What you see

Likely cause

Typical fix

Poor LCP on landing pages

Large hero image or video, slow server, render-blocking scripts

Optimize and prioritize the hero image, cache pages on a CDN, defer non-essential scripts

Poor INP across the site

Too much JavaScript, especially third-party tags and widgets

Remove unused tags, load chat and testing tools later or on interaction

Poor CLS on specific templates

Banners, embeds or images without reserved space, late-loading fonts

Reserve space, set image dimensions, adjust font loading

Every page is slow, whatever you fix

The platform or theme itself

Consider whether the platform is the real limit (see below)

Give your developers the list of pages, the failing metric and the business reason, not just a screenshot of a score. If your team doesn't have the engineering time, a performance audit of your top landing pages can turn this into a prioritized list of fixes.

When the platform itself is the limit

Sometimes the honest answer is that no amount of tuning will get you there. The signs:

  • Pages fail Core Web Vitals even after images, fonts and scripts have been addressed.

  • Every page loads large amounts of code for features it doesn't use.

  • Your team can't control how and when scripts load.

  • Each fix takes weeks because changes to the theme are risky.

That is when a rebuild becomes a reasonable business decision. When Perk rebuilt its marketing site, its components had drifted across several rewrites. The rebuild from Next.js to Astro took 13 weeks, and its most important pages met the launch targets on the first day: a mobile PageSpeed lab score of 70 or more, and 95 or more on desktop. Because those are lab numbers, the team also set up real-user monitoring before the switch to track field data. You can read how the Perk rebuild was approached. If a headless CMS is on your shortlist for the rebuild, read headless CMS pros and cons first.

Keeping the site fast after launch

Performance tends to slip quietly. A new chat widget here, a new pixel there, a heavier hero video for a campaign. Three habits prevent this:

  1. Agree on a performance budget for your key pages, for example "LCP under 2.5 seconds on mobile for the top ten landing pages", and check it monthly.

  2. Review new tools before they go live. Our guide to third-party scripts has a checklist for this.

  3. Re-run a short audit every quarter with our website performance audit checklist.

Checklist

Monthly speed check

  • Search Console's Core Web Vitals report shows no new poor or "needs improvement" groups

  • The top ten landing pages meet the performance budget on mobile

  • Pages that receive paid traffic pass all three Core Web Vitals, where field data exists

  • Every tool added since the last check has an owner and a review date

  • Each new problem has an owner and a date for the fix

Next steps

Start with the Core Web Vitals report in Search Console and your top ten landing pages. If third-party scripts turn out to be the problem, continue with How third-party scripts slow your site. For a structured review, use the website performance audit checklist.

Make your key pages fast

Our senior engineers improve Core Web Vitals and keep third-party scripts from slowing down the pages that matter.

See our Growth Engineering service

Related guides