Blog

What if I told you that swapping three attributes in your `` tag could cut image payload by 50 to 80 percent and shave whole seconds off your Largest Contentful Paint?

You do not need a new hosting provider or a front-end rewrite. You need to serve the right image format (WebP / AVIF), in the right size, at the right time, with a simple responsive setup that browsers already understand.

If your site still sends only JPEG and PNG, you are paying a speed tax on every pageview you get.

You are going to see exactly how to set up responsive images with WebP and AVIF so that:
– Chrome, Edge, Firefox, and Android get tiny AVIF or WebP files.
– Safari falls back gracefully to WebP or JPEG/PNG.
– You do not maintain three separate media libraries.
– Core Web Vitals improve, and SEO follows the speed.

No theory. Just the practical setup that makes money by loading faster, converting better, and ranking higher.

—

Why WebP and AVIF matter for speed and SEO

Your images are probably the heaviest part of your pages. For content sites, they often account for 50 to 80 percent of transfer weight. For product pages and SaaS landing pages with hero illustrations, it can be worse.

AVIF and WebP change the math:

Format	Typical size vs JPEG	Transparency	Animation	Browser support (current)
JPEG	100%	No	No	All
PNG	150-300%	Yes	No	All
WebP	~60-70% of JPEG size	Yes	Yes	All modern browsers
AVIF	~40-60% of JPEG size	Yes	Yes (limited)	Most modern browsers (not all old Safari)

So for every 1 MB of JPEG, you can often send 400-600 KB of AVIF. Across a full page with 10 hero and product images, that adds up to megabytes saved.

Why this makes money:

Lower weight = faster Largest Contentful Paint = better user experience = more conversions and better rankings.

You do not get bonus points for “pixel perfect” images that load in 4 seconds. You get paid when users see the first meaningful content fast enough that they do not bounce.

—

Core building blocks: <picture>, srcset, and sizes

You only need three ideas to unlock responsive AVIF/WebP:

– Multiple formats through `` and ``.
– Multiple sizes through `srcset`.
– Smart selection through `sizes`.

If you miss any of these, you leave speed on the table.

The basic responsive AVIF + WebP + JPEG pattern

Here is a realistic pattern for a hero image that must load fast and look sharp:

“`html
“`

Here is what is happening in business terms:

– Modern Chrome on a mobile device gets a small AVIF file.
– Safari that supports WebP but not AVIF gets WebP.
– Older browsers get the JPEG.
– Every browser picks the smallest file that looks good on that device.

This single snippet improves speed on cheap Android phones, mid-range laptops, and 5K iMacs without you doing user agent hacks.

The browser, not your backend, should decide which size and format to load.

So your job is to give the browser good options. That is what `srcset` and `sizes` are for.

—

How srcset really works for responsive images

Most teams copy-paste `srcset` from a blog post and hope. If you understand what it actually does, you can design it for speed, not guesswork.

There are two main patterns:

– Width descriptor: `400w`, `800w`, `1200w`.
– Density descriptor: `1x`, `2x`.

For responsive designs, you want width descriptors. That lets the browser match physical viewport width, zoom level, and pixel density.

Width descriptor with srcset + sizes

In the example:

“`html
srcset=”
/images/hero-400.avif 400w,
/images/hero-800.avif 800w,
/images/hero-1200.avif 1200w,
/images/hero-1600.avif 1600w
”
sizes=”(max-width: 600px) 100vw,
(max-width: 1200px) 80vw,
1200px”
“`

You are saying:

– There are 4 versions of this image: 400, 800, 1200, and 1600 pixels wide.
– On viewports up to 600px wide, the image will be 100 percent of viewport width.
– Between 601 and 1200px, the image will use about 80 percent of viewport width.
– Past 1200px, it will be 1200px wide on screen.

The browser uses this to choose the best candidate. So if the viewport is 390px wide on an iPhone, 2x pixel density, and the image is 100vw, it needs around 780 CSS pixels worth of data. It then picks the 800w source. That saves bandwidth while still looking sharp. You do not need to second guess it.

If your srcset does not have realistic sizes, the browser cannot pick the right file. It will often fall back to the biggest one.

So you speed up the site by teaching `sizes` how your layout behaves.

—

Where AVIF and WebP actually win (and where they do not)

Not every image gains equally from AVIF and WebP. You need to be strategic so you do not waste time or introduce visual issues.

High-impact targets

• Hero images and banners.
• Product photos and feature illustrations.
• Blog post hero images and embedded charts.
• Onboarding and dashboard screenshots in SaaS.
• Icons and simple UI images (WebP is usually enough).

These drive your Largest Contentful Paint and visual stability. They pull the user in or push them away.

You start with these, not the logo in the footer.

Where AVIF can be tricky

AVIF is impressive, but it can cause issues if you are not careful:

– Banding in gradients, especially with aggressive compression.
– Strange artifacts on text-heavy screenshots.
– Slower encoding time on your build or upload.

You do not want your clean analytics dashboard screenshots to look slightly off. That hurts trust, which hurts conversions.

A simple rule:

Use AVIF when it gives at least 25-30 percent extra savings over WebP at the same visual quality. Otherwise stop at WebP.

For some UI screenshots, WebP at quality 80-85 is often good enough, with stable rendering and predictable size.

—

Implementing WebP and AVIF without burning your dev budget

You have two main paths:

– Let an image/CDN service handle it.
– Handle it in your own build or backend pipeline.

If you have a marketing site with static assets, build-time conversion is fine. If you run a multi-user SaaS where customers upload avatars, screenshots, and slide decks, you want on-the-fly processing.

Using an image CDN (Cloudflare Images, Imgix, Cloudinary, etc.)

If you already run behind a CDN with an image service, you can offload almost all of the complexity.

The typical pattern:

– Store one high quality source (JPEG/PNG).
– Request different formats and widths by query parameters or URL patterns.
– Let the service negotiate the format based on `Accept` headers.
– Use `srcset` with parameterized widths.

Example with a fictitious image CDN:

“`html
“`

From a business view:

– Designers upload one file.
– Developers stop worrying about pre-generating variants.
– Marketing gets consistent quality and speed across campaigns.

The key is to standardize the widths so caching is effective. You do not want arbitrary `w=417` `w=786` requests across the site that kill cache hit rates.

Handling conversions in your own pipeline

If you want control or you are avoiding third-party cost, you can run AVIF/WebP conversion yourself.

A common stack:

– Node with sharp or Squoosh for converting and resizing.
– A build or upload step that produces AVIF, WebP, and JPEG/PNG.
– A convention for filenames: `image-400.avif`, `image-400.webp`, `image-400.jpg`.

Example Node script with sharp:

“`js
const sharp = require(“sharp”);

async function buildResponsiveSet(inputPath, basename) {
const widths = [400, 800, 1200, 1600];

for (const width of widths) {
const jpegOut = `public/images/${basename}-${width}.jpg`;
const webpOut = `public/images/${basename}-${width}.webp`;
const avifOut = `public/images/${basename}-${width}.avif`;

await sharp(inputPath)
.resize(width)
.jpeg({ quality: 80, mozjpeg: true })
.toFile(jpegOut);

await sharp(inputPath)
.resize(width)
.webp({ quality: 80 })
.toFile(webpOut);

await sharp(inputPath)
.resize(width)
.avif({ quality: 50 }) // test this visually
.toFile(avifOut);
}
}

buildResponsiveSet(“src/images/hero-source.png”, “hero”)
.catch(console.error);
“`

Then you encode those files into the `` block you saw before.

This is simple enough for a static Gatsby/Next/Eleventy build. For a SaaS that allows uploads, you trigger the conversion when a user uploads a new file.

You win when designers, developers, and content writers do not have to think about image formats. The pipeline should do the work once.

So invest in a script or a service, not manual exports from Figma every time.

—

Dealing with Safari and partial AVIF support

Support is no longer a guessing game. Most modern browsers support AVIF. Some older Safari versions still do not.

The order of `` elements in `` solves this:

“`html “`

The browser will:

– Use AVIF if it supports that type.
– Fall back to WebP if it does not support AVIF but supports WebP.
– Fall back to whatever is in `` if it supports neither.

You do not need any user agent detection. You only need that correct order.

Always put the smallest, most modern format first in <picture>. Let older browsers fall down the ladder.

Safari on macOS and iOS users get WebP or JPEG. They still see the same design. They just get slightly larger files than Chrome users. That is acceptable, and it is temporary as Safari support improves.

—

Lazy loading and priority: do not starve the hero image

If you have moved to AVIF/WebP but your LCP is still weak, the next problem is timing. Many teams break their speed by lazy loading the wrong images.

Here is the rule that saves your Core Web Vitals:

– Never lazy load the image that contains or influences LCP.
– Lazy load images below the fold.
– Preload the main hero image when needed.

Correct approach for the main hero:

“`html
“`

And then the matching `` without `loading=”lazy”`:

“`html “`

Then for images further down the page:

“`html

“`

If you add `loading=”lazy”` to hero images to please Lighthouse, you sometimes hurt real users. LCP may stall while the browser waits to load what looks like the main content.

Your hero image is not “just another image”. Treat it as a first-class resource with preload and no lazy loading.

So reserve lazy loading for secondary and below-the-fold content.

—

Maintaining aspect ratio and preventing layout shift

You can have the fastest AVIF files in the world and still fail if your images cause layout shift. Google tracks Cumulative Layout Shift, and unstable designs drive users away.

The fix is simple:

– Always include `width` and `height` attributes that reflect the intrinsic aspect ratio.
– Let CSS scale the element, but keep the ratio.

Example:

“`html

“`

In CSS:

“`css
img {
max-width: 100%;
height: auto;
}
“`

The browser can reserve the correct vertical space before the image finishes loading. No jumping content, no layout shift penalties.

Every responsive image must declare its aspect ratio. Let CSS handle visual size, not the HTML attributes.

This tiny detail can make a visible difference in Core Web Vitals, with almost no extra work.

—

Choosing sensible breakpoints and widths

Your srcset widths should match your layout, not guesswork. You do not need 15 variations for each image. That only complicates your pipeline.

A practical approach for most marketing and SaaS sites:

Viewport type	Typical CSS width on screen	Suggested image widths
Mobile full-width hero	100vw	400, 800, 1200
Desktop hero with margins	70-90vw	800, 1200, 1600
Content images in article	600-800px max	400, 800
Small cards / avatars	150-300px	150, 300, 450

You can standardize around a shared set: `[320, 480, 640, 800, 1024, 1280, 1600]`. You do not need to use every value for every image. Pick 2-4 per image type.

This keeps:

– CDN caches efficient.
– Build scripts simple.
– Dev handoffs predictable.

Standard widths are boring. That is good. Predictable image URLs support caching and long-term speed.

Resist the urge to micro-tune every image. It is better to be 90 percent right with a simple system than chase the last 10 percent manually.

—

Where teams usually go wrong with responsive WebP/AVIF

If you already tried AVIF/WebP and did not see big wins, the problem is usually in one of these areas:

1. Only replacing single JPEG with single AVIF

You take a 2000px wide JPEG, convert it to AVIF, keep a single source, and call it a day. Mobile devices still have to download a large file and then scale it down.

Why this hurts:

– Mobile data plans waste bandwidth.
– Decode time is higher.
– LCP does not improve as much as it could.

You need both format and responsive sizing.

2. Wrong quality settings

If you push AVIF quality too low, images look off. If you play it safe and push quality too high, the file savings are small.

Target ranges that usually work:

Format	Quality range (typical)	Use case
JPEG	75-85	Fallback only
WebP	75-85	General purpose, Safari, older Android
AVIF	40-60	Hero, product, large visuals

Then you inspect a small set of images visually on a real screen. That takes one focused afternoon, but it sets the base for your whole site.

3. Forgetting about SEO attributes

When restructuring your markup with `` and ``, you must not forget:

– The `alt` attribute on ``.
– If images are links, the anchor content.

Search engines still use alt text for understanding context. Conversion-driven pages still need accessible markup for real users. Your format work should not break that.

The <img> tag is still the SEO anchor. <picture> and <source> are just wrappers for better delivery.

So treat the `` element as the canonical representation in your content editing workflow.

—

Putting this into a repeatable process

If this stays as a one-time refactor, you will lose the gains as soon as the next campaign launches. You need a process your team follows without thinking too much about it.

For static marketing sites

You can standardize a pipeline like this:

1. Designer exports 1 high-resolution PNG or JPEG (2x or 3x target max width).
2. Build script converts it into AVIF, WebP, and JPEG at fixed widths.
3. Component library contains a generic `` React/Vue/Svelte component.
4. CMS entries reference the logical image name, not the actual format.

Example React component:

“`jsx
function ResponsiveImage({ baseName, alt, aspectRatio = “16/9” }) {
const widths = [400, 800, 1200, 1600];
const webpSet = widths
.map(w => `/images/${baseName}-${w}.webp ${w}w`)
.join(“, “);
const avifSet = widths
.map(w => `/images/${baseName}-${w}.avif ${w}w`)
.join(“, “);
const jpgSet = widths
.map(w => `/images/${baseName}-${w}.jpg ${w}w`)
.join(“, “);

return ( );
}
“`

Marketing teams only pass `baseName` and `alt`. The component handles formats and widths. That is how you keep speed best practices alive across months and new content.

For SaaS products with user uploads

Your flow is slightly different:

1. User uploads an image (PNG/JPEG).
2. Backend accepts the upload and stores original.
3. Background job generates WebP and AVIF at standard widths.
4. Application stores metadata (paths, widths).
5. Frontend template creates `` using that metadata.

You do not expose AVIF/WebP complexity in the UI. Users see “Upload profile picture” and “Upload screenshot.” You handle the rest.

Your users cannot break your performance if the upload pipeline enforces format and size standards.

This matters for B2B SaaS where customers can upload enormous 8 MB screenshots. Without a pipeline, one customer can slow down another customer`s dashboard.

—

How to measure the impact so this effort gets budget

Executives and non-technical founders do not care about file formats. They care about speed, rankings, and revenue. So you must connect AVIF/WebP work to those numbers.

You can measure impact across three tools:

Tool	Metric	Why it matters
Lighthouse / PageSpeed Insights	LCP, “Serve images in modern formats”	Shows improvement on lab benchmarks.
Chrome User Experience Report / RUM	Real user LCP and CLS	Shows real-world gains across devices.
Analytics / A/B testing	Bounce rate, signup rate, checkout completion	Translates speed into money.

A simple test you can run:

– Pick one high-traffic landing page.
– Implement AVIF/WebP + `` + responsive sizes only on that page.
– Keep a control page similar in content and traffic.
– Compare speed metrics and conversion for 2-4 weeks.

It is common to see:

– 30-60 percent drop in transferred image bytes.
– 200-600 ms better LCP on mid-range mobile devices.
– Several percentage points improvement in conversion on paid traffic.

You do not need improbable claims. You only need enough improvement to justify making this the standard for the rest of the site.

If a one-time image format project improves your conversion by even 5 percent on paid traffic, it can pay for itself many times over.

So when someone suggests that “we will get to AVIF later,” you have a concrete, measured answer, not hand-waving about performance.

—

You do not need a perfect setup to get the gains. You need a clear baseline:

– Use `` with AVIF, WebP, and JPEG in that order.
– Use `srcset` with width descriptors and realistic `sizes`.
– Standardize widths and a pipeline so nobody does this by hand.
– Protect your hero images with preload and no lazy loading.
– Track the difference in LCP and conversions before and after.

Once that is in place for your key pages, every new image you add can follow the same rules, and your site stays fast as you grow content, traffic, and revenue.