Cloudinary Media Developer study materials
Cloudinary Media Developer study resources

Cloudinary Media Developer: Cloudinary delivery, formats and responsive media

Cloudinary Media Developer · Work through your exam, one topic at a time.

All guide sections

Cloudinary delivery, formats and responsive media

Select a representation for its actual use

A hero image, small thumbnail and zoom view can need different dimensions and crops even when they share one source. Delivery transformations can create relevant variants under the supported configuration. Automatic format and quality parameters address different decisions: f_auto chooses an eligible representation according to its supported client/content logic, while q_auto addresses quality/compression under its actual behavior. A browser advertising AVIF support does not guarantee that every request must return AVIF regardless of content or settings.

Match resolution to layout

Responsive media requires knowledge of the intended rendered size and relevant pixel density. Srcset candidates and sizes help the browser choose among supplied image resources; they are not a substitute for accurate layout assumptions. Breakpoint generation can support candidate selection, while automatic width/DPR features depend on supported SDK, client-hint or other integration behavior. Do not assume every browser sends every hint. Serving a huge source to a tiny box can waste bytes even when the chosen format is modern.

Understand the delivery path

A CDN can serve a cached representation without fetching it again from the original source, reducing some transfer and origin work. The actual cache key, URL version, requested transformations and freshness behavior matter. Overwriting an original under the same identifier and requesting invalidation is different from publishing a versioned URL. An invalidation request is not proof that every browser, proxy and edge immediately forgot a representation. Preserve old immutable/versioned resources during transitions when existing pages may still reference them.

Evaluate size, quality and user outcomes together

A smaller byte count is useful only if the representation meets its visual, functional and accessibility needs. Progressive presentation, low-quality placeholders and lazy loading can support particular experiences, but should not delay the main visible content indiscriminately. Image geometry, encoded size, network conditions and page rendering all contribute to the outcome. Video codec and adaptive-streaming choices have their own supported negotiation and player requirements. These are bounded delivery concepts and do not execute a media request or guarantee a universal best format, compression ratio or current commercial plan. General HTTP/CDN questions on this page are explicit prerequisites, not Cloudinary proprietary configuration commands.