Image & Media Optimization

1Why images are the #1 lever here

On a travel/booking site the hero shot and the result-card thumbnails are the product. That means images are usually both the LCP element and the largest transfer — so optimizing them moves the metrics you're graded on more than almost anything else. Four overlapping disciplines, and you want all four: [MDN]

1. Right format — AVIF / WebP with a JPEG fallback. Same picture, far fewer bytes.
2. Right size — srcset/sizes so a phone never downloads a 2000px desktop image.
3. Right loading — lazy-load below the fold, but prioritize the LCP image (never lazy-load it).
4. Reserved space — width/height so the image can't shift layout (CLS).

2Right format — AVIF & WebP, with a fallback

Modern formats encode the same quality in dramatically fewer bytes: WebP ≈ 25–35% smaller than JPEG, AVIF ≈ 50% smaller. [web.dev] The <picture> element lets the browser pick the first format it supports — AVIF, then WebP, then a JPEG that always works:

<picture>
  <source type="image/avif" srcset="hotel.avif">
  <source type="image/webp" srcset="hotel.webp">
  <img src="hotel.jpg" alt="Pool at sunset" width="800" height="600">
</picture>

The browser stops at the first <source> whose type it supports; the <img> is the mandatory fallback (and carries the alt, width/height, loading attrs). [MDN]

3Right size — srcset & sizes

The other half of the win: don't ship a 2000px image to a 400px phone. srcset lists the same image at multiple widths; sizes tells the browser how wide the image will render so it can pick the smallest sufficient file before layout (the preload scanner needs sizes — Lesson 02). [web.dev]

<img
  srcset="hotel-400.jpg 400w, hotel-800.jpg 800w, hotel-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 33vw"
  src="hotel-800.jpg" alt="..." width="800" height="600">

Read the two attributes as inventory vs slot:

• srcset = the menu of files I have. hotel-800.jpg 800w means “this file is literally 800px wide.” The w is a width descriptor — just declaring what's on the shelf, all the same photo at different sizes.
• sizes = how wide the image will render, read like CSS (first match wins): “≤600px viewport → 100vw (full width); otherwise → 33vw (a 3-col grid).” You must tell the browser this because it picks the file before layout/CSS (the preload scanner — Lesson 02), so it can't otherwise know the slot is a third of the screen.
• src is only the fallback for ancient browsers; modern ones use the menu.

The browser's math: needed px = slot width (from sizes) × device pixel ratio → pick the smallest file ≥ that. Same markup, four devices:

Note the laptop pulls the tiny 400w file — in a 3-column grid the slot is only ~400px even on a big screen — while the phone pulls 1600w because its DPR is 3. That's the whole point: resolution switching serves each device the smallest sufficient file. [MDN]

Use srcset/sizes for the same photo at different sizes. When you instead want a different crop per breakpoint, that's a job for <picture>:

Scaling one wide pool shot down to a phone makes the subject a tiny strip — so on mobile you'd rather show a different, tighter crop. The browser can't make that editorial call by scaling; you declare it with <source media> (browser uses the first matching media):

<picture>
  <source media="(max-width: 600px)" srcset="hotel-square.jpg">  // phone: tight crop
  <img src="hotel-wide.jpg" alt="..." width="1200" height="600">  // desktop default
</picture>

(And <picture> + <source type> from §2 switches format — so <picture> handles format and art-direction; srcset/sizes handles resolution. You often combine them.)

Where does srcset go — and do I even need <picture>?

srcset works on both <img> and <source>. That's the whole answer to “why <picture>?”: a plain <img srcset sizes> already does resolution switching, so prefer it — and only reach for <picture> for the two things srcset structurally can't do:

In a <picture>, the browser reads <source>s top-to-bottom and uses the first whose type AND media both match, then applies that source's srcset/sizes; the <img> is the required fallback. Attributes split by role: srcset/sizes/type/media live on <source>; alt/width/height/loading/fetchpriority/decoding live only on the <img>. The kitchen-sink — all three axes at once: [MDN]

<picture>
  // AVIF, mobile crop (media) at 2 sizes (srcset/sizes)
  <source type="image/avif" media="(max-width:600px)"
          srcset="sq-400.avif 400w, sq-800.avif 800w" sizes="100vw">
  // AVIF, desktop wide crop
  <source type="image/avif"
          srcset="wide-800.avif 800w, wide-1600.avif 1600w" sizes="66vw">
  // WebP fallback (same two crops) ...
  <source type="image/webp" media="(max-width:600px)" srcset="sq-800.webp 800w">
  <source type="image/webp" srcset="wide-1600.webp 1600w">
  // JPEG floor — REQUIRED; carries alt/dims/loading/priority
  <img src="wide-800.jpg"
       srcset="wide-800.jpg 800w, wide-1600.jpg 1600w" sizes="66vw"
       alt="Pool at sunset" width="1600" height="900"
       fetchpriority="high" decoding="async">
</picture>

4Right loading — lazy below, prioritize the LCP image

This is the most-tested image trap in the round. Two opposite moves for two kinds of image:

// hero — the LCP element: prioritize, don't lazy-load
<img src="hero.avif" fetchpriority="high" width="1200" height="600" alt="...">

// thumbnails further down: lazy + async decode
<img src="card.avif" loading="lazy" decoding="async" width="300" height="200" alt="...">

Network-aware (adaptive) loading

A user on 2G in a data-capped market shouldn't get the same 1600px AVIF as someone on office fibre. Adaptive serving tunes quality/resolution — or whether to load an image at all — to the connection. Three mechanisms, most-robust first:

// JS: progressive enhancement on top of a sensible default
const c = navigator.connection;
if (c && (c.saveData || c.effectiveType === 'slow-2g' || c.effectiveType === '2g')) {
  img.src = lowResUrl;        // lighter image / skip hero video
}

5Reserved space — kill image CLS

An image with no dimensions loads, takes up space that wasn't reserved, and shoves the content below it down — that's layout shift (CLS, Lesson 03). The fix is to always let the browser reserve the box before the pixels arrive:

• Always set width and height (the intrinsic ratio). Modern browsers turn those attributes into an aspect-ratio and reserve the space — even while the image is still loading. [web.dev]
• For CSS-sized images, set aspect-ratio on the element so the box is reserved regardless.
• Give responsive images a fluid box: img{height:auto} with width/height attributes present keeps the ratio correct across breakpoints.

6At scale — don't hand-author, build a pipeline

The Lead answer isn't a perfectly hand-tuned <picture> — nobody maintains that across thousands of hotel photos and many teams. You make it automatic:

• Image CDN / on-the-fly transforms — Cloudinary, imgix, Cloudflare Images, Akamai Image Manager, or a homegrown service. One source upload → the CDN derives format (AVIF/WebP via content negotiation), size, quality, and crop per request from URL params, and caches at the edge. This is how a travel site serves the right image to every device without storing dozens of variants by hand. [web.dev]
• A framework <Image> component — Next.js next/image (and equivalents) bake in srcset generation, lazy-loading, blur placeholders, and required dimensions, so every dev gets it right by default. [Next.js]
• Placeholders for perceived speed — a tiny blurred (LQIP) or dominant-color block while the full image streams in (Lesson 04's perceived-performance idea).
• Govern it — a perf budget / Lighthouse check on image weight in CI (Lesson 05), and lint that bans dimensionless <img>, so it can't regress across teams.

7Check yourself — scenario quiz

Pick an answer; instant feedback. Push-back style, like the round.