When to use WebP over JPEG in production

Choosing between WebP and JPEG is not a universal call — it depends on your audience’s browser distribution, your CDN’s header-negotiation capability, and whether the 25–35% payload reduction justifies adding a fallback branch to your build pipeline. This page gives you a concrete decision matrix and a complete, annotated implementation, building on the quantitative tradeoffs documented in AVIF vs WebP Compression Benchmarks and the broader context in Core Media Fundamentals & Next-Gen Formats.

Prerequisites

Before switching your production pipeline to WebP-first delivery, confirm every item below is in place:

Format selection diagram

The diagram below maps the key decision points — browser share, content type, and transparency — to the right output format.

WebP vs JPEG production decision flowchart A flowchart showing the decision path from browser share and content type to the correct image format: WebP, AVIF+WebP, or JPEG fallback. Start: new image asset WebP-capable browsers >90% of sessions? No Serve JPEG only (IE11 / legacy IoT) Yes Needs alpha transparency or animation? Yes WebP (lossless or lossless alpha) No AVIF supported by CDN and >80% of clients? Yes AVIF + WebP + JPEG stack No WebP (lossy) + JPEG fallback

Exact solution: <picture> fallback with annotated CDN config

The most robust production pattern combines a declarative HTML fallback with edge-level Accept header negotiation. Use <picture> when your HTML is the authoritative source of truth; use CDN negotiation when you serve images from a centralised asset origin and want to keep markup clean.

Step 1 — Encode WebP variants

# cwebp flags explained:
#   -q 82         quality 82 — sweet spot between SSIM fidelity and file size for photos
#   -m 4          compression method 4 — good CI speed/quality tradeoff (0=fast, 6=slowest)
#   -mt           enable multi-threading to parallelise block encoding
#   -sharp_yuv    use higher-quality YUV conversion (reduces colour fringing on edges)
cwebp -q 82 -m 4 -mt -sharp_yuv -o output/hero.webp input/hero.jpg
// Node.js via Sharp — integrate into your existing asset pipeline
const sharp = require('sharp');

sharp('input/hero.jpg')
  .webp({
    quality: 82,        // mirrors cwebp -q 82
    effort: 4,          // 0–6 scale; mirrors cwebp -m 4
    smartSubsample: true, // higher-quality chroma subsampling, analogous to -sharp_yuv
  })
  .toFile('output/hero.webp')
  .then(info => console.log(`WebP written: ${info.size} bytes`))
  .catch(err => console.error('Conversion error:', err));

Step 2 — HTML <picture> element

<picture>
  <!--
    Browsers parse <source> elements top-to-bottom and use the first match.
    type="image/webp" gates this source on WebP decode support — Safari 13 and
    IE11 skip it entirely and fall through to the <img> src.
  -->
  <source srcset="/assets/hero.webp" type="image/webp">

  <!--
    <img> is the universal fallback AND the element browsers use for LCP scoring.
    loading="eager" + fetchpriority="high" tell the browser this is the LCP candidate.
    Explicit width/height prevent CLS by reserving layout space before the image loads.
  -->
  <img
    src="/assets/hero.jpg"
    alt="Hero banner showing dashboard interface"
    loading="eager"
    fetchpriority="high"
    width="1200"
    height="600"
  >
</picture>

Warning: Setting fetchpriority="high" on more than one <img> per page can starve CSS and other critical resources. Reserve it for the single above-the-fold LCP image. See using fetchpriority to optimise critical media for the full starvation-risk analysis.

Step 3 — Nginx CDN/origin content negotiation

When your CDN or origin server serves images at a stable URL (e.g. /assets/hero.jpg), use Accept header inspection at the edge to transparently serve the .webp variant to capable clients without changing HTML.

location ~* \.(jpg|jpeg)$ {
  # Vary: Accept tells downstream caches to maintain separate cache entries
  # for WebP-capable vs legacy clients. Without this header, a CDN may serve
  # a cached WebP response to a client that sent no Accept: image/webp header.
  add_header Vary Accept always;

  set $img $uri;

  if ($http_accept ~* "image/webp") {
    # Rewrite internal path to the .webp variant.
    # Assumes hero.jpg and hero.webp share the same base name in the asset store.
    set $img "${uri%.*}.webp";
  }

  # try_files falls back to the original $uri if the .webp file is absent,
  # so missing variants degrade gracefully rather than serving a 404.
  try_files $img $uri =404;
}

Tradeoff: CDN negotiation keeps markup clean but introduces a Vary: Accept cache split. Confirm your CDN (Cloudflare, Fastly, CloudFront) supports header-based cache partitioning before enabling this pattern, and check that setting max-age on Cache-Control headers for CDN media assets is still correct under the two-key cache.

Verification steps

1 — HTTP header inspection

# Confirm WebP is served to a capable client and the Vary header is present
curl -sI -H "Accept: image/webp,*/*" https://example.com/assets/hero.jpg \
  | grep -E "Content-Type|Vary|Cache-Control"

# Expected output:
# Content-Type: image/webp
# Vary: Accept
# Cache-Control: public, max-age=31536000, immutable

2 — Chrome DevTools Network panel

Open DevTools → Network tab → filter by Img. Select hero.jpg in the request list. Confirm:

  • Type column shows image/webp
  • Size reflects a smaller payload than the original JPEG (typically 25–35% reduction)
  • Initiator shows the <picture> element, not an XHR or dynamic import

3 — Lighthouse CI headless audit

# Run Lighthouse against the deployed URL; --only-categories limits noise
npx lighthouse https://example.com \
  --only-categories=performance \
  --output=json \
  --output-path=./lh-report.json \
  --chrome-flags="--headless"

# Inspect LCP and total transfer size:
cat lh-report.json | jq '.audits["largest-contentful-paint"].displayValue'
cat lh-report.json | jq '.audits["total-byte-weight"].displayValue'

4 — WebPageTest filmstrip check

Submit the URL to WebPageTest with Connection: Cable and enable Capture Response Bodies. Verify in the waterfall that the hero image resolves before the 2.5 s LCP budget and that the file size for hero.jpg (even though the URL shows .jpg) reflects WebP byte savings.

Expected performance deltas

Metric Typical improvement
LCP (mobile, 4G) −18% to −32%
Total image transfer size −25% to −35% per asset
CLS Neutral (requires explicit width/height)
Time to First Byte No change (encoding is build-time)

Common mistakes and fixes

1 — Omitting Vary: Accept from the CDN response

Without Vary: Accept, a CDN edge node caches whichever variant it receives first and serves it to all subsequent clients regardless of their Accept header. A client that sent Accept: image/webp may get a cached JPEG, or vice versa.

Fix: Always set Vary: Accept on every response for a URL that serves both JPEG and WebP. Confirm the CDN respects it by checking the response headers with curl -sI.

2 — Missing type="image/webp" on the <source> element

Without the type attribute, all browsers — including those without WebP support — attempt to decode the <source> URL. Safari 13 and IE11 will fail silently, leaving users with a broken image.

Fix: Always pair <source srcset="..."> with type="image/webp". The type attribute is the gate that makes <picture> safe across the browser matrix.

3 — Encoding at quality: 100 (or cwebp -q 100) for “safety”

WebP at quality 100 produces files that are often larger than the equivalent JPEG, defeating the purpose of the format switch. Quality 100 disables lossy compression entirely.

Fix: Use quality 80–85 for photographic content. Run a visual diff against the JPEG at your chosen quality using cwebp -psnr or ImageMagick compare -metric PSNR — a PSNR above 40 dB is perceptually transparent for most viewers.

4 — Applying fetchpriority="high" to multiple images

The preload vs prefetch guide for video and image assets documents this in detail: marking more than one resource as high-priority starves the browser’s network scheduler, and CSS/font fetches can be delayed, increasing Total Blocking Time.

Fix: Apply fetchpriority="high" only to the single above-the-fold LCP image. All other images should use loading="lazy" with no explicit fetchpriority.

5 — Skipping the JPEG fallback in the asset manifest

If .webp generation fails silently in CI (disk space, codec error), clients receive a 404 for the image URL if no fallback JPEG exists.

Fix: In your CI asset manifest, assert that both hero.jpg and hero.webp exist before the build is marked successful. Use try_files $img $uri =404; in Nginx (as shown above) so the origin degrades to JPEG rather than a hard 404 if a .webp file is missing.