Image Optimization: WebP, AVIF, and Responsive Images

Your marketing team ships a beautiful new campaign page, and three weeks later you notice bounce rates climbing on mobile. The culprit is almost never the copy. It is a hero image weighing 1.8 MB, a customer logo wall served at full resolution, and a screenshot that loads at desktop dimensions on a phone. Image optimization on the web is the single highest-leverage performance fix most B2B teams ignore, because images are usually the largest payload on the page and the easiest to get wrong. The good news: modern formats and responsive delivery let you cut that weight by half or more without touching design quality.

This is a practitioner’s guide to doing it right. We will cover format selection, responsive delivery, the markup that ties it together, and the operational discipline that keeps it from regressing the next time someone uploads a PNG straight from Figma.

Why image optimization web work pays off first

Before tooling, understand the economics. On a typical B2B marketing site, images often account for 50 to 70 percent of total page weight. That weight directly drags down Largest Contentful Paint, because your hero image is frequently the LCP element itself. Fixing it improves the metric Google measures and the experience your buyers feel.

There is also a compounding effect. Faster pages get crawled more efficiently, convert better, and reduce your CDN bandwidth bill. We treat image work as part of the same discipline as the rest of Core Web Vitals optimization, not a one-off cleanup. If you only do one performance project this quarter, make it this one.

Takeaway: images are usually your biggest payload and your LCP element at the same time. Optimizing them is the rare fix that improves speed, SEO, and conversion in a single pass.

Choose the right format: WebP, AVIF, or stay with what you have

Format choice is where most of the savings live. Here is the decision framework we use.

AVIF

AVIF is the most efficient widely supported format available today. It typically produces files 30 to 50 percent smaller than WebP at comparable visual quality, and it handles both photographic content and flat graphics well. Use AVIF as your primary modern format. The tradeoffs: encoding is slower, and a small slice of older browsers and email clients still cannot render it.

WebP

WebP is the dependable fallback. It is smaller than JPEG and PNG, supports transparency and animation, and enjoys near-universal browser support at this point. Serve WebP as the fallback below AVIF and you cover essentially every visitor.

When to keep JPEG, PNG, or SVG

• Use SVG for logos, icons, and any flat vector artwork. It scales infinitely and is usually tiny. Never export a logo as a raster PNG when an SVG exists.
• Keep JPEG only as the universal last-resort fallback, or where a pipeline cannot yet generate modern formats.
• Avoid PNG for photographs. Reserve it for cases that genuinely need lossless raster with transparency, and even then test WebP first.

The practical rule: generate AVIF and WebP from every source asset, keep an original JPEG or PNG as the final fallback, and use SVG anywhere the source is vector.

Serve responsive images, not one file for every screen

Format is half the battle. The other half is not sending a 2400-pixel-wide image to a 390-pixel-wide phone. Responsive delivery solves two distinct problems, and they require different markup.

Resolution switching with srcset and sizes

When the same image just needs to appear at different sizes, use a single img with a srcset of width descriptors and a sizes attribute that tells the browser how wide the image will render. The browser then picks the smallest file that still looks sharp on that device and pixel density.

A clean implementation looks like this:

<img
  src="hero-800.jpg"
  srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1600.avif 1600w"
  sizes="(max-width: 768px) 100vw, 800px"
  width="1600"
  height="900"
  alt="Dashboard showing pipeline velocity by segment"
  loading="lazy"
  decoding="async"
/>

Three details matter here. Always set explicit width and height so the browser reserves space and you avoid layout shift. Get the sizes value right, because a wrong one silently forces oversized downloads. And reserve loading="lazy" for below-the-fold images only.

Format negotiation and art direction with picture

When you need the browser to choose between formats, or to swap in a differently cropped image at certain breakpoints, use the picture element with multiple source entries. The browser walks the sources top to bottom and uses the first it supports.

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="100vw" />
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" sizes="100vw" />
  <img src="hero-1600.jpg" width="1600" height="900" alt="Product overview" />
</picture>

This pattern gives you AVIF first, WebP next, and a JPEG fallback, all from one block of markup. Art direction works the same way: add a media attribute to a source to serve a tighter crop on mobile.

Get the loading priorities right

Optimized formats still hurt you if they load in the wrong order. A few rules carry most of the weight.

1. Eager-load the LCP image. Your hero or above-the-fold image should not be lazy-loaded; doing so delays the very element Google times. Add fetchpriority="high" to it.
2. Lazy-load everything below the fold. Logos in the footer, screenshots deep in a long page, and blog inline images should all use loading="lazy".
3. Preload the hero when it is set via CSS background or loaded late by a framework. A link rel="preload" with the right type and imagesrcset pulls it forward.
4. Always decode async so image work does not block the main thread.

This sequencing is where image work overlaps directly with the broader Core Web Vitals playbook. The formats reduce bytes; the priorities reduce the time those bytes block rendering.

Build a pipeline so it does not regress

A one-time cleanup feels great until a content editor uploads a 4 MB PNG next month. The durable fix is automation. You want every image transformed at build or request time, with no manual steps for the people producing content.

There are three common approaches, in rough order of how much we reach for them:

• Build-time generation. If you are on a modern framework, let the framework do it. Astro’s built-in image component, for example, generates AVIF and WebP, sets width and height, and emits responsive srcset automatically. This is one reason we build most B2B sites on Astro: the fast path and the correct path are the same path.
• Image CDN. A transformation CDN resizes, reformats, and caches on the fly from a single source upload. This is the right call when non-technical teams upload images frequently or when you have a large existing library.
• Pre-commit or asset-pipeline scripts. For static assets in the repo, a script that converts and compresses on commit keeps oversized files from ever shipping.

Whatever you choose, the goal is the same: nobody has to remember to optimize anything. The system does it.

A checklist to enforce

Use this as a pull-request or QA gate before any page goes live:

• Hero/LCP image is eager-loaded with fetchpriority="high", not lazy.
• Every img has explicit width and height.
• AVIF and WebP are generated, with a raster or SVG fallback.
• sizes reflects the actual rendered width at each breakpoint.
• Below-the-fold images use loading="lazy" and decoding="async".
• No single image exceeds a sane byte budget (we typically flag anything over 200 KB for review).
• Logos and icons are SVG, not raster.

How you organize these assets also depends on your page structure. We cover the layout side of that in the B2B website architecture that converts, where image-heavy sections like logo walls and product tours need deliberate handling.

Measure, then keep measuring

Ship the changes, then verify with field and lab data. Lab tools like Lighthouse show you per-image savings and flag missing dimensions. Field data from real users tells you whether LCP actually moved. Watch for the common regressions: a new campaign page with an unoptimized hero, a CMS that strips your srcset, or a redesign that reintroduces background-image heroes without preload.

In our engagements, the teams that hold their gains are the ones that wired image optimization into the build and the review process rather than relying on individual diligence. Discipline beats heroics here every time.

Where to start

If your site is image-heavy and you have never audited it, begin with the LCP image on your top five pages. Convert them to AVIF with a WebP fallback, set explicit dimensions, fix the loading priority, and measure. That alone often produces a visible speed improvement. Then automate so it sticks.

If you would rather have a team that does this work end to end, that is what we do. Explore our services or reach out and we will audit your image pipeline, find the heaviest pages, and build the delivery system that keeps them fast.