An image CDN can resize, compress, transform, and deliver images close to the people viewing them. The strongest results come from combining those delivery capabilities with correct page markup. A small file still arrives late if the browser cannot discover it, and a quickly delivered image can still move the page if its space was never reserved.
Build the workflow around the image's purpose: what visitors need to see, how large it appears, and when they need it. This guide develops that process without assuming a particular provider. If the delivery architecture is new to you, start with our explanation of how a content delivery network works.
Start with an inventory of image roles
Group assets by their job on the page. A homepage hero, product thumbnail, documentation screenshot, decorative texture, and user avatar have different requirements. Record the largest displayed width, common aspect ratios, transparency requirements, and whether a mobile layout changes the crop. Identify images visible at first load separately from those far down the page.
Choose representative samples before changing a global setting. Include detailed photography, smooth gradients, small lettering, and transparent edges. These reveal different compression problems. Keep the original source files so that future sizes and formats can be generated from a suitable master. Repeatedly recompressing a previously compressed derivative makes the workflow harder to control.
Match the file to the displayed size
A browser should not need the same image payload for a narrow card and a wide presentation panel. Generate a practical set of widths that reflects the site's components. For example, a catalog might use a small family of candidates for cards and another for product detail pages. Treat those widths as design decisions, not universal recommendations.
Account for device pixel density when deciding how much detail is useful. An image displayed at 400 CSS pixels wide may need a larger source on a dense screen. However, supplying an unlimited maximum resolution can increase transfer and decoding work without an obvious improvement. Compare the displayed result at realistic viewing sizes rather than judging every image at extreme zoom.
Describe responsive candidates accurately
The srcset attribute lists available sources. With width descriptors, each w value must match that file's actual pixel width. The sizes attribute describes the intended layout width under relevant media conditions, helping the browser select a candidate. The browser also considers factors such as pixel density. Keep the ordinary src as a suitable fallback.
For example, sizes="(min-width: 64rem) 50vw, 100vw" describes a half-viewport image on larger screens and a full-viewport image elsewhere. It is only appropriate if the layout behaves that way. A centered container with a maximum width needs a description that reflects the cap. MDN's responsive images guide explains these attributes and the distinction between resolution switching and art direction.
Test candidate selection at several viewport widths using a fresh page load. Inspect the downloaded file and its dimensions in browser developer tools. Simply shrinking a window after a large image has loaded does not reliably recreate a new mobile visit, because a browser can continue using an available larger resource.
Separate format choice from quality choice
AVIF and WebP are useful options for many web images, while JPEG and PNG remain appropriate fallbacks or source formats for particular requirements. SVG suits many diagrams and icons because it describes shapes rather than a fixed grid of pixels. Choose formats according to the content and the browsers you support, then compare actual output.
Do not treat a quality value as interchangeable across encoders and formats. Create a small comparison set and inspect texture, lettering, gradients, skin tones, and edges where relevant. Record which settings meet the visual requirement at an acceptable file size. A provider's automatic mode can be a starting point, but retain a way to review exceptions and change the policy.
Delivering multiple formats also requires a consistent selection mechanism. A picture element can offer supported source types with an image fallback. If the same URL negotiates a format through request headers, ensure the CDN and downstream caches keep the representations separate. Confirm the returned content type matches the actual file.
Make the hero discoverable and important
The image that dominates the first viewport may become the Largest Contentful Paint element. Put its source information in the initial HTML whenever the page architecture allows. A hero introduced only after JavaScript finishes, or discovered through a late stylesheet, can start downloading later than necessary. Faster image hosting cannot remove that discovery delay.
Do not apply loading="lazy" to the hero or another likely LCP image. Use normal eager loading and consider fetchpriority="high" for the main visual after checking the loading behavior. Fetch priority is a hint about relative importance; it is not a substitute for early discovery. Avoid marking a whole gallery high priority, which gives the browser little useful distinction.
If preloading is justified, verify that it requests the candidate the page actually uses. Responsive preloads need corresponding source information, and unnecessary hints can compete with other critical resources. Our guide to CDNs and Core Web Vitals explains how to diagnose the relevant loading stages.
Reserve space before any image arrives
Include correct width and height attributes so the browser can establish the image's aspect ratio. Responsive CSS can still use max-width: 100% and height: auto. The dimensions describe the proportion; they do not require the image to overflow a small screen at its original size.
Keep resolution variants at the same aspect ratio unless the design intentionally changes the crop. For art direction, ensure the appropriate ratio is reserved at each breakpoint. Review skeletons, blurred previews, and error states against the final dimensions. A placeholder that changes height when the final image arrives can undermine the stability it was intended to provide.
Lazy load images that can wait
Native loading="lazy" is a useful starting point for images well below the initial viewport. It lets the browser defer their requests until they approach the visible area. Keep dimensions on these images too. Otherwise a long page of initially empty image boxes can produce both layout movement and confusing loading behavior.
Review real journeys through the page. A gallery that users scroll quickly needs different consideration from an occasional image in a long reference article. Test keyboard navigation, browser search, slow connections, and routes that open near an anchored section. The practical question is whether the image appears when needed without forcing every visitor to download the entire collection immediately.
Control transformation and cache variants
Every combination of width, crop, format, and quality can become a distinct derivative. A small approved set is easier to review and cache than an unrestricted stream of arbitrary transformations. Many image systems support signed transformation URLs or other controls. Evaluate those features when user input can influence requested dimensions or source locations.
Use versioned image paths when the underlying content changes, or define a reliable purge process. Keep original identity and transformation options in the cache key where they affect the response. For header-based content negotiation, configure the appropriate variation behavior, commonly involving Vary: Accept, and verify the provider's actual treatment. Our HTTP caching guide for CDNs covers the broader policy decisions.
Validate a small rollout before expanding it
Choose one representative template and record image bytes, selected candidate dimensions, request start time, cache behavior, and visual quality. Compare first visits and repeat visits. Include a slow mobile connection and at least one wide layout. Check that transformed URLs fail clearly when an original is missing and that the page remains understandable through meaningful alternative text.
Then review maintenance costs. Can editors preview crops? Can developers explain why a particular variant exists? Can a source image be replaced without leaving stale content indefinitely? These questions determine whether the initial improvement remains manageable as the content library grows. Capture the conventions in the implementation notes alongside our developer delivery resources.
Build an image pipeline around the page
An effective image CDN workflow combines appropriate source dimensions, reviewed compression, accurate responsive markup, intentional priority, and predictable caching. Start with the most important visible image and expand the pattern to other components. Measure the experience after the change, preserve the visual information visitors need, and make the successful settings easy for future pages to reuse.
