Core Web Vitals on Astro: how we ship green LCP, INP, and CLS

Passing Core Web Vitals on Astro comes down to four habits: inline the critical CSS, optimize every image at build time, ship almost no JavaScript, and load fonts without shifting the layout. Do those and you land in the green on LCP, INP, and CLS — the three metrics Google measures from real users. This very site does, and below is the exact playbook.

Why this matters before we get technical

Speed is not vanity. Users with a good Core Web Vitals experience convert at roughly twice the rate of users with a poor one, and moving every metric from Poor to Good has been tied to conversion lifts around 25%. On the bounce side, mobile bounce rates climb to nearly 53% once load time crosses three seconds. And the opportunity is wide open: as of July 2025, only 44% of WordPress sites pass all three Core Web Vitals on mobile.

The three metrics and their 2025 thresholds

Core Web Vitals are three field metrics, scored at the 75th percentile of real-world page loads. A site “passes” a metric when at least 75% of visits meet the good threshold.

• Largest Contentful Paint (LCP) — how long until the biggest visible element renders. Good ≤ 2.5s, poor > 4.0s. Usually your hero image or headline.
• Interaction to Next Paint (INP) — how quickly the page responds to taps and clicks across the whole session. Good ≤ 200ms, poor > 500ms. INP replaced First Input Delay in March 2024 because FID only measured the first interaction and missed lag later in a session.
• Cumulative Layout Shift (CLS) — how much the layout jumps while loading. Good ≤ 0.1, poor > 0.25. Caused by images without dimensions, late-loading fonts, and injected banners.

Source: Google Search Central — Core Web Vitals.

Lever 1 — Inline the critical CSS for a fast LCP

LCP is mostly a render-blocking-resources problem. If the browser has to fetch an external stylesheet before it can paint, your largest element waits. Astro builds static HTML and can inline the styles a page actually uses, so the first response carries everything needed to paint above the fold — no extra round trip. We keep our token system in src/styles/tokens.css lean and let the framework inline per-page critical CSS, which is the single biggest LCP win on a content site.

Lever 2 — Optimize every image at build time

Unsized and unoptimized images wreck two metrics at once: heavy hero images blow LCP, and images without width/height attributes cause layout shift that spikes CLS. Astro’s image pipeline solves both — it generates modern formats (AVIF/WebP), emits correct width and height so the browser reserves space, and produces responsive srcsets. The rule on every build: no raw <img> to a full-resolution file, and never an image without intrinsic dimensions.

Lever 3 — Ship almost no JavaScript (islands for INP)

INP is where most stacks quietly fail, because a heavy JavaScript bundle keeps the main thread busy and every tap waits behind it. Astro’s default is zero client-side JS — pages are HTML and CSS until you explicitly opt in. When a component genuinely needs interactivity, we ship it as an island with a client:* directive, so only that widget hydrates and the rest of the page stays static. The result is that good INP is the starting state, not something we claw back. The average mobile page now takes 8.6 seconds to load, much of it JavaScript execution — shipping less of it is the most reliable speed lever there is.

Lever 4 — Load fonts without shifting the layout (CLS)

Web fonts are the most common cause of a creeping CLS score: text renders in a fallback, the web font arrives, and everything reflows. We self-host fonts (no third-party connection), preload the one or two weights used above the fold, set font-display: swap, and tune fallback metrics so the swap doesn’t move text. Combined with sized images, that keeps CLS comfortably under 0.1.

How this site proves it

We don’t ask clients to take performance on faith. Sitewright runs the same playbook it sells — static Astro on Cloudflare’s edge, inlined CSS, build-time images, island-only JavaScript, self-hosted fonts — and ships green Core Web Vitals as the default state, not a tuned demo. It is the live proof of the stack. The payoff compounds: position-1 results are 10% more likely to pass Core Web Vitals than position-9 results, so the speed work and the ranking work are the same work.

FAQ

What are the current Core Web Vitals thresholds? At the 75th percentile of real users: LCP ≤ 2.5s, INP ≤ 200ms, and CLS ≤ 0.1. “Needs improvement” runs to 4.0s, 500ms, and 0.25 respectively; anything beyond is “poor.”

Did INP really replace FID? Yes. INP replaced First Input Delay in March 2024. FID only measured the delay before the browser responded to the first interaction; INP measures the full latency of interactions across the whole visit, so it catches sluggishness FID missed.

Why is Astro good for Core Web Vitals specifically? Because it ships HTML and CSS with zero JavaScript by default, then lets you add interactivity as isolated islands. That keeps the main thread free (good INP) and the payload small (good LCP) without you fighting a framework’s runtime.

Do Core Web Vitals actually affect rankings and revenue? They are a confirmed ranking signal, and the business case is stronger: good-CWV users convert at about double the rate, and a 1-second delay can cut conversions by 7%.

We’re on WordPress and failing CWV. What’s the fastest path to green? Often a re-platform. Only 44% of WordPress sites pass all three on mobile. You can migrate to Astro without losing rankings, and give your team a CMS they can still edit without a developer.

The bottom line

Green Core Web Vitals on Astro is not luck or a plugin — it’s four deliberate choices made at build time. Inline the CSS, optimize the images, ship islands instead of bundles, and load fonts without the shift. See how we run a revamp end to end, with passing Core Web Vitals written into the scope.