Core Web Vitals checklist for marketing sites

Core Web Vitals are not a nice-to-have. They are a user experience signal: pages that render quickly, respond quickly, and do not jump around feel trustworthy.

This checklist is intentionally short. If you do these well, you cover the majority of real-world issues on small business marketing sites.

If you want a structured review (budgets, redirects, caches, and form delivery) see: Performance + Launch QA.

1) LCP (Largest Contentful Paint): make the hero cheap

In most marketing layouts, LCP is the hero headline block or hero image.

• Keep the hero layout simple (no heavy sliders).
• If you use a hero image, compress it and size it correctly.
• Set explicit width and height on images to avoid layout shifts later.
• Avoid loading non-critical widgets before the main content.

Practical defaults:

• One primary hero visual (or a lightweight SVG treatment).
• Lazy-load anything below the fold.
• Keep third-party scripts to the absolute minimum.

2) INP (Interaction to Next Paint): protect the main thread

INP gets worse when the browser is busy running JavaScript during user interactions.

• Do less JavaScript. Prefer static HTML and progressive enhancement.
• Split long work into smaller chunks (no long tasks).
• Defer non-critical scripts. Load interactivity only where it adds value.

If you need interactivity, keep it scoped and measurable. For example, only hydrate a form enhancement or a small calculator instead of the whole page.

3) CLS (Cumulative Layout Shift): reserve space for everything

CLS is usually caused by assets loading late without reserved space.

• Always set image dimensions.
• Avoid injecting banners or UI above existing content.
• Reserve space for embedded media and iframes.
• Prefer stable fonts (or load fonts in a way that avoids reflow).

If you must use web fonts, use font-display: swap and limit families/weights.

4) TTFB (Time to First Byte): cache what you can

TTFB is mostly a hosting + caching problem.

• Use a CDN and cache static assets aggressively.
• Avoid slow server-side rendering for pages that can be static.
• Reduce backend round trips (fewer APIs on the critical path).

For Astro sites, this is usually straightforward: ship static output where possible, and keep server endpoints small and fast.

5) Third-party scripts: treat them like a performance tax

Every added tag is a tradeoff. Before adding a script:

• Confirm what business question it answers.
• Confirm it is allowed (privacy requirements and approvals).
• Measure the impact (Lighthouse + real-user signals).

Quick self-check (10 minutes)

• Open the page on a phone. Does it feel instant?
• Scroll fast. Does anything jump?
• Tap links and menu items. Do they respond immediately?
• Run Lighthouse once on mobile throttling and check the main issues.

If you want help tightening this up without overengineering, start here: Contact and share the URL and goals.