The three numbers, in plain words
Core Web Vitals are the measurements Google collects from real Chrome visitors to judge how a page feels to use. They aren't abstract lab scores. Each one maps to a moment of frustration you've felt on someone else's website this week.
- LCP (Largest Contentful Paint) is how long the biggest thing on screen takes to show up. On a marketing site that's nearly always the hero image or the headline. This is the staring-at-a-blank-page feeling. Good is under 2.5 seconds.
- CLS (Cumulative Layout Shift) is how much the page jumps around while it loads. The button that moves right as your thumb lands on it. Good is under 0.1.
- INP (Interaction to Next Paint) is how long the page takes to visibly react after a tap or a click. The did-that-menu-even-open pause. It replaced FID in March 2024, and good is under 200 milliseconds.
These numbers feed into search ranking, which is why marketing teams hear about them. But rank is the second reason to care. The first is that every one of those moments is a visitor quietly deciding whether your business feels competent.
Where marketing sites lose the points
Marketing sites fail these metrics in remarkably consistent ways. Four places cover most of it:
- The hero image. A 2 MB PNG exported straight from the design file, served at desktop size to phones, sometimes buried inside a JavaScript carousel that has to boot before the image even starts downloading. This is the most common LCP problem there is.
- Web fonts. Five weights of a display face, loaded in a way that either hides all the text until the fonts arrive or swaps them in with a visible reflow.
- Embeds and banners. Ads, video embeds, cookie notices, and chat bubbles that inject themselves without any reserved space and shove everything below them. That shoving is your CLS score.
- Third-party tags. Analytics, ad pixels, heatmaps, session recorders, A/B tools. Each one felt free when it was added. Together they own the main thread, and a busy main thread is exactly what makes INP miss.
If your site runs on WordPress or Shopify, the same four problems wear platform-specific costumes. I keep a separate WordPress speed checklist and a note on Shopify performance for those.
The fixes that pay
Core Web Vitals optimization has a short list of fixes that earn their time on almost every marketing site. Start here before anything clever.
Serve images like you mean it. Right dimensions for the viewport, a modern format, and explicit sizing so the browser can lay out the page before the file arrives. I've spent a good chunk of my day job comparing GIF, WebP, and AVIF on compression and browser support, and the short version is: AVIF or WebP for photos, and anything shipping as an animated GIF should almost certainly be a video file instead. Then give every image its dimensions:
<img src="hero.avif"
width="1600" height="900"
fetchpriority="high"
alt="Product dashboard on a laptop">The width and height attributes don't force the rendered size; your CSS still controls that. They hand the browser the aspect ratio so it can reserve the space, which deletes a whole category of layout shift for free. And fetchpriority="high" on the one image that is your LCP tells the browser to stop being polite about fetching it. That attribute alone is often worth a few hundred milliseconds.
Stop letting fonts hold the text hostage. Cut the weights you don't use, preload the one file the headline needs, and let the fallback font show while the real one loads:
@font-face {
font-family: 'Marketing Serif';
src: url('/fonts/marketing-serif.woff2') format('woff2');
font-weight: 400 700;
font-display: swap; /* fallback text now, real font when ready */
}font-display: swap means visitors read your headline in a system font for a beat instead of staring at invisible text. Pick a fallback with similar proportions and most people never notice the swap happened.
Reserve space for everything that arrives late. Give video embeds an aspect-ratio, give the ad slot and the announcement banner a min-height, and render the cookie notice as an overlay instead of something that pushes the page down. CLS fixes are rarely hard. They're just nobody's job until someone makes them a job.
Make third parties wait their turn. Nothing in the tag manager needs to run before first paint. Defer it all, load the chat widget on first interaction or after the browser goes idle, and audit the container a couple of times a year. Tag containers only ever grow; if yours has been live for a few years, odds are something in it no longer earns its keep.
The fixes that rarely pay
Knowing what to skip matters just as much, because these show up in every audit tool and rarely move the numbers on a marketing site:
- Micro-minification. Squeezing a 30 KB stylesheet down to 27 KB while a 2 MB hero ships untouched. The work isn't wrong, but doing it first is a sprint spent on the smallest file on the page.
- Rewriting the frontend. A framework migration takes months and usually ships the same images, the same fonts, and the same tag manager. The metrics follow the assets, not the framework.
- Chasing a perfect Lighthouse score. Lighthouse is a lab estimate. The gap between 92 and 100 is often invisible to real visitors, and once your field data reads "good", the remaining points are decoration.
- Server tuning when the server was never slow. If the HTML arrives in a few hundred milliseconds, switching hosts won't rescue an LCP that's late because of a giant image behind a carousel.
Measuring without fooling yourself
Web performance has a measurement trap: the tools that are easiest to run are the least like your visitors. Two habits keep it honest.
Trust field data over lab data. PageSpeed Insights (opens in a new tab) shows two very different things on one page: field data from real Chrome users over the previous 28 days, and a lab simulation run on one synthetic device. The field section is your grade. The lab section is a debugging tool for reproducing what the field section complains about. Optimizing the lab number while ignoring the field number is studying for the wrong exam. Google's own web.dev/vitals (opens in a new tab) is the reference worth reading on how the two relate.
Test more than the homepage. The homepage gets the design attention, but ad traffic lands on campaign pages and search traffic lands on blog templates. A fast homepage can hide a slow everything-else. Test one URL per template, and test it the way a stranger arrives: cold cache, mid-range phone, throttled connection.
Making it stick
A one-time performance fix decays. The next hero image gets exported at full size, the next campaign adds two tags, and six months later the site is back where it started. The cure is making web performance a number that someone, or something, watches every week.
At my day job as Web Lead at Universe, the setup that works is boring on purpose: automated WebPageTest scripts run against the key templates on a schedule, the results land in Metabase dashboards, and a regression shows up as a bend in a chart instead of a complaint a quarter later. You don't need that exact stack. A written budget (say, hero under 200 KB and LCP under 2.5 seconds on the pricing page) plus any automated check in CI that fails the build when the budget is blown gets you most of the value.
This is also work I take on outside the day job. Core Web Vitals optimization is part of the performance and accessibility service I offer businesses in Chicago and its suburbs, and the triage above is roughly what the first week looks like. If your PageSpeed report is a wall of orange and you're not sure which third of it matters, get in touch and we'll read the field data together.