A Core Web Vitals checklist for marketing websites

Core Web Vitals are three numbers Google collects from real Chrome visitors: how fast the main content appears, how quickly the page responds to a tap or click, and how much the layout jumps around. This Core Web Vitals checklist is the one we run on every marketing site we build or take over, in the order that usually pays back fastest. If you would rather hand it over, it is the core of our technical SEO and performance service.

01The three Core Web Vitals and their targets

Google's Web Vitals guidance sets a "good" threshold for each one, measured at the 75th percentile of page loads, separately for mobile and desktop:

INP replaced First Input Delay as a Core Web Vital in 2024. It is stricter, because it looks at every interaction during a visit rather than only the first one.

02Start with field data, not a lab score

Lighthouse and PageSpeed Insights run one simulated page load. Useful for debugging, but it is not what Google uses. The Chrome UX Report collects data from real Chrome users, and that field data is what appears in Search Console's Core Web Vitals report.

• Open Search Console's Core Web Vitals report and note which URL groups fail, and on which device
• Check the same pages in PageSpeed Insights; the top section is field data, the bottom is the lab run
• Fix the failing template, not the single URL; a slow blog template fails every post at once
• Remember field data trails behind your fixes, so expect a few weeks before the report turns green

03LCP: make the main content arrive first

On marketing pages the LCP element is almost always the hero heading or the hero image. Everything on this list is about getting that one thing on screen sooner, as covered in depth in Optimize Largest Contentful Paint.

• Find the LCP element for mobile and desktop; they are often different
• If it is an image: serve it in AVIF or WebP at the size it is shown, never lazy load it, and give it fetchpriority="high"
• If it is text: preload the font files it uses and hold a short font swap so the text does not change shape late
• Never fade the hero heading in from invisible; an animation that starts at zero opacity delays LCP by its full length
• Cut render blocking CSS and JavaScript in the head; inline the small amount of CSS the first screen needs
• Put the site on a CDN and cache HTML at the edge where you can; server response time comes before everything else

04INP: keep the main thread free

Poor INP almost always means too much JavaScript running when someone taps. Marketing sites collect it over time: tag managers, chat widgets, A/B testing tools, analytics, heavy sliders. Google's INP optimisation guide explains the mechanics; this is the practical list.

• List every third party script and who owns it; remove the ones nobody can name a reason for
• Load chat, video and heatmap tools only after the visitor interacts, or after the page is idle
• Break long JavaScript tasks into smaller ones so the browser can respond in between
• Avoid layout heavy work in scroll and pointer handlers; let CSS do the animation where it can
• Test on a mid range Android phone, not only on a new laptop

05CLS: reserve space for everything

Layout shift is the easiest metric to fix and the most annoying one for visitors. The usual causes are listed in Optimize Cumulative Layout Shift.

• Give every image, video and embed a width and height, or an aspect ratio in CSS
• Reserve space for cookie banners, promo bars and ads instead of pushing content down when they load
• Use a font loading strategy that does not reflow text when the web font arrives
• Animate with transform and opacity, not with properties that move other elements

06Motion and 3D without failing the vitals

Animation and WebGL do not have to cost you the vitals. We ship motion and 3D on sites that score green, by following four rules:

• Keep the hero heading as plain HTML outside any canvas, so it can be the LCP element
• Load 3D libraries and scenes after the first interaction or once the browser is idle, never in the initial bundle
• Give every canvas a fixed box so it cannot shift the layout when it appears
• Pause animations that are off screen, and respect the reduced motion setting

We go deeper on each of these, from which CSS properties are cheap to animate to loading WebGL on idle, in our guide to website animation performance.

07After launch: make the Core Web Vitals checklist a routine

Most sites pass on launch day and drift out over the following year as scripts, campaigns and heavier images arrive. What keeps them green is routine, not heroics:

• Set a performance budget, such as maximum JavaScript and image weight per template, and check it in your build
• Review Search Console's Core Web Vitals report every month
• Make adding a third party script a decision with an owner, not a copy and paste
• Build new pages from a design system whose components are already optimised, so new pages are fast by default

If a site keeps failing however much you tune it, the problem is usually the foundations, and that is one of the few good reasons for a rebuild. We wrote about the others in how often you should redesign your website.

08How much do Core Web Vitals matter for SEO?

Less than many audits suggest, and more than nothing. Google's documentation on Core Web Vitals and search says they align with what its ranking systems seek to reward, while its page experience guide is clear that good scores do not guarantee top rankings and that relevance comes first.

Our view: treat the vitals as a tie breaker in search and as a conversion problem everywhere else. A slow landing page wastes the ad budget sent to it, whatever it ranks. Which platform you build on matters less than how carefully the site is put together, a point we make in our Webflow vs WordPress comparison.