Performance

Images are still the #1 performance killer in 2026. A 2MB hero photo kills Lighthouse, delays paint, tanks Core Web Vitals. The fix used to be a nightmare: manual Photoshop exports, separate WebP/AVIF versions, handwritten srcset attributes, pray you don't miss a breakpoint. Astro 5 nuked that entire workflow. One line of code, build handles everything: WebP + AVIF generation, responsive srcsets, lazy-loading, picture-element fallback chains. Real sites drop 15–25 Lighthouse points and cut image bytes by 40–60% with zero extra effort. Velocity X uses this pipeline for every portfolio thumbnail, hero image, and blog cover. The tool is simple. The impact is enormous.

Why Image Weight Still Ruins Sites

Modern images are bloated. A smartphone shot is 3–8MB raw. You shrink it, optimize it, and it's still 200–500KB. Throw 5 of those on a page and you've got 1MB of image bytes before any JavaScript even runs. Mobile networks choke. LCP breaks. Users bounce.

The old fix was dumb: resize everything yourself, export to WebP by hand, export to AVIF by hand (or don't, because AVIF tools are painful), write multiple `` tags, pray CSS breakpoints match your srcset breakpoints. Developers either skipped it or burned 2 hours per page.

Astro 5 changes the game. Drop your original image file into the project, import it, use the `` component, and the build pipeline handles everything: detects format, generates WebP + AVIF at 10 different widths, stacks them in a fallback chain, lazy-loads below the fold. No manual steps. No config file. Just works.

How Astro's Image Pipeline Works

Astro ships with Sharp (the industry-standard image processor) baked into the framework. When you use `` with a local file, Astro's build step runs the image through Sharp at compile time (not at request time), generates the variants, and outputs optimized files to the build folder.

{`import { Image } from 'astro:assets';
import heroShot from '../assets/hero.jpg';


`}

Behind the scenes, Astro generates four versions of your image: WebP at 320px, 640px, 960px, 1280px. If the browser supports AVIF, it gets that too (5 more files at the same widths, 10 total). The HTML output is a `` element that lists all formats in fallback order: AVIF (best compression) → WebP (universal support) → original JPG (if JS fails). The browser picks whichever it supports and only downloads one file.

astro-compress (in Velocity X's build) further minifies images at pack time. AVIF encoding goes deep; you lose visually imperceptible detail but cut bytes by 50–70%. JPGs compress to 60–75 quality without visible loss.

Responsive Sizes + Lazy-Loading

The real power is in the `sizes` attribute. It tells the browser which image width to load based on viewport size. Pair that with `widths` (the breakpoints you generate), and every screen gets the exact image size it needs. No oversized mobile images. No undersized desktop views.

{`widths={[320, 640, 960, 1280, 1920]}
sizes="(max-width: 640px) 100vw, (max-width: 960px) 90vw, (max-width: 1280px) 80vw, 1280px"
loading="lazy"
`}

Add `loading="lazy"` and images below the fold don't download until the user scrolls near them. Hero images use `loading="eager"` (blocks LCP, intentional). Thumbnails use `lazy`. The browser's Native Image Lazy Loading API does the heavy lifting; no JavaScript intersection observers needed.

CDN Considerations — Netlify vs. Cloudinary

Astro outputs optimized images to your build folder. If you're on Netlify (like Velocity X), the Netlify Image CDN automatically serves those images through a geographically distributed cache. Requests from Australia hit Sydney, requests from the US hit Virginia. No extra config — it's automatic.

For advanced use cases (user-uploaded images, dynamic resize-on-request), Cloudinary or Imgix are better bets. But for a portfolio site or marketing site with fixed images, Astro's static pipeline + Netlify's CDN is bulletproof.

Six FAQs

Does AVIF work in all browsers?

No. Safari added AVIF support in 2023, but older iOS still uses WebP. That's why `` fallback chains exist: browser gets AVIF if it can handle it, WebP as a safe second, JPG as a last resort. Everyone gets a format they understand.

What if I'm using remote images (from Supabase, Cloudinary)?

The Astro `` component is for local files only. For remote URLs, use a regular `` tag and let your CDN handle optimization. Or fetch the image at build time and cache it locally (Netlify Blobs are good for this).

Does the build get slower with image optimization?

Yes, slightly. Sharp takes 0.5–2 seconds per image depending on size and format. A 30-image page takes 30–60 seconds extra build time. On a fast machine, that's negligible. CI/CD pipelines might notice.

Can I set a global quality level for all images?

Yes. Astro's config accepts `quality` in the image integration. Set it once, applies to all images: `quality: 75` for JPG, `quality: 80` for AVIF. Lower = smaller bytes, slightly softer detail.

What resolution should the source image be?

Bigger is always safer. If your largest breakpoint is 1280px, source at least 2560px (2× DPI for Retina). Astro will downscale perfectly. Upscaling looks worse.

How much do images really improve Lighthouse?

On a typical portfolio site, 15–25 points. Sometimes 30. Depends on how many images and how bloated the originals are. A site that went from hand-resized JPGs to Astro's pipeline typically sees LCP drop 1–3 seconds and CLS near zero.

The Bottom Line

Images don't have to be a performance bottleneck anymore. Astro 5's pipeline removes the tedium: one component, automatic format generation, responsive srcsets baked in. The result is faster sites, better Lighthouse scores, and browsers that download only what they need. For a deeper dive into the performance architecture that makes this work, read our guide on Partytown for Third-Party Scripts. When you're ready to rebuild with performance as the foundation, check Velocity X pricing to see what that looks like in practice.