Images are responsible for the majority of page weight on most websites. They’re also the single biggest variable in your LCP score — Largest Contentful Paint, the Core Web Vitals metric Google uses to assess whether your page loaded fast enough to rank. Astro handles image optimization at the framework level. Here’s what that actually does, and what the before-and-after numbers look like.
Why Images Break Core Web Vitals
The threshold Google sets for a “good” LCP score is 2.5 seconds. Most pages fail because of one avoidable problem: a large, unoptimized image that takes too long to load.
The pattern is consistent. A photographer, a restaurant, a product company uploads a 4MB PNG straight from their camera or design tool. It goes on the homepage. The page now has to download 4MB before the largest visible element paints. On a fast desktop connection, that’s inconvenient. On a mid-range Android phone on a 4G connection, the LCP score hits 5, 6, 8 seconds. Google measures mobile performance. That’s the number that affects rankings.
There are four image problems that come up repeatedly on audits:
Wrong format. JPEG and PNG are the defaults in most CMSes. WebP achieves 25–34% smaller file sizes than JPEG at equivalent quality. AVIF goes further — 50% smaller than JPEG — but browser support is still catching up. Serving WebP instead of JPEG on every image is a free performance gain most sites aren’t taking.
Wrong size. A 3000px wide image being displayed at 800px wide is still downloading as a 3000px image. The browser resizes it visually, but the full bytes came over the wire. Responsive image srcset attributes fix this by telling the browser which size to download based on the device. Most WordPress and page builder setups get this partially right at best.
No lazy loading. Images below the fold shouldn’t load until the user scrolls toward them. The browser supports this natively with loading="lazy". If your images don’t have it, they’re all downloading on page load, whether the user reaches them or not.
No explicit dimensions. Images without width and height attributes cause Cumulative Layout Shift — the page jumps as images load and the browser recalculates layout. CLS is another Core Web Vitals metric. Images without dimensions reliably fail it.
Astro’s Image component addresses all four by default.
What Astro’s Image Component Does
The <Image> component in Astro is a wrapper around Sharp, a high-performance Node.js image processing library. When you use it, Astro does the following at build time:
Format conversion. Astro converts images to WebP by default. You can specify AVIF. You never have to touch an image export setting.
Responsive resizing. You define the display dimensions. Astro generates multiple versions of the image at different sizes and produces the correct srcset attribute automatically. The browser downloads only the size it needs.
Lazy loading by default. Every <Image> component adds loading="lazy" unless you explicitly override it. For above-the-fold images, you override with loading="eager" — and Astro supports fetchpriority="high" to signal the browser that this image is LCP-critical.
Explicit dimensions. Astro enforces width and height on every image. The build fails if they’re missing. No CLS from missing dimensions.
The result is that image optimization is not a task you remember to do. It’s a constraint the framework enforces. An Astro developer can’t accidentally ship a 4MB PNG at display size — the build pipeline prevents it.
The Numbers: What This Looks Like in Practice
The performance benchmarks for well-built Astro sites are consistent. Astro sites score 95–100 on Lighthouse mobile as a baseline, with LCP times of 0.3–0.8 seconds for content-heavy pages when deployed to a CDN.
For comparison, a typical WordPress page built with Elementor scores 30–45 on Lighthouse mobile. Elementor sites average an LCP of 4–6 seconds on mobile. We’ve audited sites where a single unoptimized hero image added 3.2 seconds to LCP on its own.
Those aren’t edge cases. They’re what unmanaged image pipelines produce.
The impact on Core Web Vitals pass rates is measurable. HTTP Archive data from 2025 puts WordPress Core Web Vitals pass rate at 43% on mobile. Astro’s benchmarks show roughly 60% of Astro sites passing Core Web Vitals. The image handling difference accounts for a meaningful portion of that gap.
What LCP Score Actually Affects
Google’s Core Web Vitals are a confirmed ranking signal. A site that passes all three metrics — LCP under 2.5s, FID under 100ms, CLS under 0.1 — is treated as a positive quality signal in search ranking. A site that fails is not penalized in isolation, but it’s competing at a disadvantage against sites that pass.
For Google Ads, the connection is more direct and more expensive. Quality Score — the metric Google uses to determine how much you pay per click — is partly determined by landing page experience. Landing page speed is a component of that. A landing page with an LCP of 0.4 seconds gets a higher Quality Score than a page with an LCP of 5 seconds. A higher Quality Score means a lower cost per click for the same ad position.
We cover this in more detail in our article on Astro JS for landing pages, but the short version: slow images don’t just hurt rankings, they raise your ad spend.
Astro Image Optimization vs WordPress
WordPress generates responsive images for uploaded media by default. It creates multiple sizes, serves srcset, and handles dimensions. That’s not nothing — vanilla WordPress is better than no optimization.
The gap shows up in format conversion and enforcement. WordPress doesn’t convert images to WebP by default on most hosts. You need a plugin: Imagify, ShortPixel, or WebP Express, typically at $5–$20/month depending on volume. Even with a plugin, the conversion happens reactively — when someone views the page, not at build time. The conversion quality and consistency depends on the plugin’s configuration.
The bigger gap is enforcement. WordPress does not stop you from uploading and embedding a 12MB TIFF. It will generate some responsive sizes and display the image. The original 12MB file is still there on the server and may still be served in some contexts. No build step fails. No CI check catches it.
Astro’s build-time image processing means the optimization happens once, at deploy, and the output is always the correct format at the correct size. There’s no runtime overhead. There’s no plugin to configure and forget to update. The CDN serves pre-processed, optimized images on every request.
The Plugin Stack Problem
A typical WordPress media optimization setup involves: a caching plugin, a CDN configuration, an image optimization plugin, and potentially a lazy load plugin if the theme doesn’t handle it. Each plugin adds a configuration surface, an update dependency, and an occasional incompatibility.
We’ve seen setups where the lazy load plugin conflicted with the image optimizer, resulting in images that loaded neither lazily nor in WebP — just the original file, not lazy, in JPEG. The site “had the plugins” and still had an LCP of 6.1 seconds.
Astro’s approach collapses this into the framework. One component, one build step, deterministic output.
Remote Images and CDN Integration
Astro’s image optimization works for local images (files in your project) natively. For remote images — images hosted on a CDN, pulled from a CMS API, or fetched from a product catalog — there’s a configuration step.
You define trusted domains in your Astro config. Astro can then download and process those images at build time, running the same format conversion and resizing pipeline. For a site pulling product images from a headless CMS, this means the images get WebP conversion and responsive sizing even though they originate externally.
For high-volume catalogs — thousands of product images — build time increases. This is manageable with incremental builds and caching strategies, but it’s a variable to discuss with your developer before you specify the architecture.
There’s also the option of a dedicated image CDN: Cloudinary, Imgix, or Cloudflare Images. These services handle format conversion and resizing at the CDN edge on request, rather than at build time. They’re effective and worth the cost ($20–$100/month depending on volume) for image-heavy sites. Astro integrates with Cloudinary and Imgix as image service providers.
What to Ask Before Approving an Image-Heavy Project
Before you sign off on a site build — Astro or WordPress — get specific answers to these questions:
Are images being served in WebP or AVIF? If the answer is “we’ll add a plugin,” ask how image optimization is handled at build time and what happens when a non-technical team member uploads an unoptimized image.
What is the hero image LCP target? Get a specific number. Under 2.5 seconds on mobile is the Core Web Vitals threshold. Under 1.5 seconds is good. Under 0.8 seconds is what well-configured Astro sites achieve.
How are remote images handled? If the site pulls images from a CMS or product feed, is optimization happening at build time, CDN edge, or not at all?
What’s the enforcement mechanism? On a well-built Astro site, the build fails if images are missing required attributes. On a WordPress site with a plugin stack, what stops someone from uploading a 6MB JPEG and embedding it directly?
These are reasonable questions for any developer to answer. If the answer is vague, the image pipeline is probably vague.
FAQ
Does Astro image optimization work automatically, or do I need to configure it?
The <Image> component works out of the box for local images. Format conversion, responsive sizing, and lazy loading are defaults. For remote images from external domains, you add those domains to your Astro config. A small amount of setup, but not configuration-heavy. Your developer should have this running from day one of the project.
What’s the difference between WebP and AVIF, and which should my site use? WebP gives you 25–34% smaller files than JPEG at equivalent quality. AVIF gives you up to 50% smaller files, but browser support is around 92% globally as of 2026 — slightly lower than WebP’s 96%+ support. For most sites, WebP is the safe default. AVIF is worth using if you want the extra compression and your analytics show a user base on modern browsers. Astro can serve AVIF with a one-line configuration change.
My WordPress site already has an image optimization plugin. Is that enough? Depends on the plugin and how consistently it’s used. Plugins like Imagify and ShortPixel do genuine WebP conversion and are effective when configured correctly. The gaps are in enforcement (nothing stops uploading unoptimized images), plugin stack conflicts, and runtime processing vs. build-time processing. If your WordPress Lighthouse score is above 85 on mobile and LCP is under 2.5 seconds, your current setup is probably fine. If it’s not, the plugin alone is unlikely to fix it.
Does image optimization affect my Google search rankings? Indirectly and directly. Faster LCP is a confirmed Core Web Vitals signal that feeds into Google’s Page Experience ranking factors. The effect size is debated — Google has been careful to say it’s one signal among hundreds — but a site with an LCP of 0.4 seconds and one with 5 seconds are not equivalent from Google’s perspective. For competitive queries where all other factors are close, page speed is a tiebreaker.
Can I use external images from my CMS in Astro and still get optimization? Yes, with configuration. You whitelist the CMS domain in your Astro config, and Astro fetches and processes the images at build time. Alternatively, you use an image CDN like Cloudinary that handles optimization at the edge. If your CMS is something like Sanity or Storyblok, they also have their own image transformation APIs that Astro integrates with. Your developer should be specifying which approach before the project starts.
If your current site is scoring under 70 on Lighthouse mobile and you want to understand what a proper image optimization architecture looks like, our custom WordPress development service includes build-time optimization and performance floors in the spec. Or see our fixed-price packages for a defined scope that includes performance targets.