Frontend interview: How would you design a privacy-safe responsive image pipeline with Client Hints?

Prompt and scope

A content site serves images to phones, tablets, and desktops at different widths and DPR values. Product wants lower first-view transfer, while the CDN is worried that a cache entry for every Width and DPR will fragment the cache. Legal asks for only necessary device information. Design the pipeline, explain the behavior without Client Hints, prevent CLS and duplicate downloads, and define how you would measure the result.

This tests browser resource selection, HTTP caching, performance, accessibility, and progressive enhancement. Width, DPR, and traffic are variables to measure; do not promise a fixed percentage gain without data.

What the interviewer is testing

• Whether you can describe the real rendered slot with srcset and sizes so the browser chooses a candidate.
• Whether you can connect Accept-CH, later requests, Vary, and the CDN cache key into one data flow.
• Whether you recognize privacy, fingerprinting, and cache-explosion risks from high-cardinality hints.
• Whether you provide a JavaScript-independent fallback, dimension reservation, alt, and a measurement loop.

Questions to clarify first

1. Is the image content, decoration, or an art-directed hero? That changes alt and picture-element handling.
2. What are the CSS slot widths and aspect ratios at each breakpoint? sizes must describe the slot, not blindly the viewport.
3. Can the CDN key on normalized width, format, and quality values? How many width candidates are allowed?
4. What is the target browser support for Client Hints, modern formats, and responsive preloading?
5. What are the baselines for first-view metrics, cache hit rate, image bytes, and errors?

A 30-second answer framework

Use native responsive images first, then add Client Hints as server/CDN progressive enhancement. The browser uses srcset and sizes to choose a candidate; if the server varies a response using hints, it advertises Accept-CH and makes the cache policy reflect the fields that really affect the response. Allow only bucketed widths and normalized DPR, with safe defaults and a no-hints path. Validate with LCP, CLS, image bytes, hit rate, and errors, and check that high-entropy hints are truly necessary.

Step-by-step answer

1. Define a finite candidate set and slot

Generate a finite width set per image, such as 320, 640, 960, and 1280 (example values, not a universal standard), while preserving the source aspect ratio. Express the expected display width at each layout breakpoint in sizes; the browser also considers DPR, network, and its own policy. Keep src as a required fallback.

<img
  src="/img/card-640.jpg"
  srcset="/img/card-320.jpg 320w, /img/card-640.jpg 640w, /img/card-960.jpg 960w, /img/card-1280.jpg 1280w"
  sizes="(min-width: 66rem) 33vw, (min-width: 44rem) 50vw, 100vw"
  width="640"
  height="400"
  alt="Article cover"
  loading="lazy"
  decoding="async"
>

2. Use picture for format and art direction

Use the picture element when format selection or a different mobile crop is required, and finish with an img-element fallback that has src. Keep format and width selection separate; a fixed preload should not force the wrong resource.

3. Keep the Client Hints loop minimal

The response may use Accept-CH to request hints the server truly uses, such as DPR or Width. Whether and when a browser sends them depends on browser policy, permissions, and support. Ignore unknown hints and declare only fields that actually change a cacheable response.

Accept-CH: DPR, Width
Vary: Accept, DPR, Width

Vary is a semantic declaration, not permission to create unlimited variants. Map Width to finite buckets, normalize DPR, or put the normalized result in the CDN key; never concatenate arbitrary raw parameters into an upstream URL.

4. Handle privacy, permissions, and input safety

Client Hints are request metadata, not credentials. Prefer low-entropy hints that solve a stated problem, and avoid requesting device model data for profiling. Bound and allowlist width, quality, and format parameters; an image transformer must also defend against SSRF, open redirects, and oversized work.

5. Preserve progressive enhancement and accessibility

When hints are absent, denied, or miss the CDN, srcset/sizes and a server default still load an image. Set width and height, or an equivalent aspect-ratio box, to reduce CLS. Use loading="eager" or fetchpriority="high" sparingly for an above-the-fold LCP image; lazy-load below-the-fold images; provide meaningful alt text for content images.

6. Build a reversible measurement plan

Split comparable traffic and content into control and treatment. Record LCP, INP, CLS, image transfer bytes, decode time, hit rate, error rate, actual displayed width, and device class. If hit rate drops or duplicate downloads rise, reduce hint dimensions, widen buckets, or roll back Client Hints before adding more variants.

High-quality sample answer

I would put browser-native selection first: provide a finite srcset, an accurate sizes, intrinsic dimensions, and accessible alt text. Use the picture element only when format or art direction requires it, with a reliable img-element fallback. The server can advertise Accept-CH for hints it actually uses, but the first request must work when hints are unsupported, denied, or not yet available.

If a response changes by hint, I would restrict the CDN key to normalized width buckets, DPR buckets, format, and allowlisted quality. Vary would list only fields that affect the representation. Raw width and network values can have high cardinality, so they should not create one cache object each. I would not request device model data without a concrete need and would never treat a hint as authentication. Finally, I would run a same-content A/B test on LCP/CLS, bytes, hit rate, and errors before expanding rollout.

Common failure modes

• Always writing sizes="100vw" and ignoring multi-column layouts, producing oversized candidates.
• Explaining Accept-CH without the later-request, permission, Vary, and cache-key story.
• Creating a CDN variant for every raw width, DPR, or network value.
• Requiring client JavaScript to measure first, harming first paint and fallback behavior.
• Using a fixed preload link that conflicts with responsive selection and downloads twice.
• Ignoring alt, dimension reservation, parameter allowlists, or high-entropy privacy risk.

Follow-up questions and reference answers

Is more Vary always more correct?

No. It should identify request fields that change a cacheable representation. High-cardinality fields create variants and lower hit rate, so normalize them or use a finite server policy.

Why add Client Hints when srcset already exists?

srcset and sizes let the browser choose using its slot knowledge and are usually the first choice. Client Hints are an optional supplement when a server or CDN must transform a response using device or network metadata; they do not replace the fallback.

Will the first HTML request contain Width?

Do not assume it. Accept-CH negotiation affects later requests, and sending is subject to browser support and permissions. The first request must therefore stand alone.

How do you know a cache bucket is too fine-grained?

Track hit rate, variant count, edge storage, and request volume per bucket. Merge neighboring widths and compare bytes and LCP; converge when the performance gain is smaller than cache cost.

When should high-entropy hints be avoided?

When the product only needs coarse width, format, or data-saving behavior. Device model hints add fingerprinting surface and cache dimensions and should not be enabled merely because they might help.

How do you verify responsive preload does not duplicate a download?

Capture network traces in browsers with and without responsive-preload support. Confirm that preload and the final img-element choice resolve to the same URL; otherwise let HTML srcset remain the sole reliable path.