Image Performance in 2021: What to Prioritize

Images remain the biggest contributor to page weight for most sites, yet they're often the last thing engineers optimize. In the latest Smashing Podcast episode, Addy Osmani breaks down a practical workflow for getting images under control, from choosing the right format to automating compression.

Vlad: "Start with the format. We should default to next-gen formats like AVIF and WebP where browser support allows, with JPEG as a fallback. These formats deliver much better compression than legacy JPEG or PNG at similar quality."

Frank: "Does that mean abandoning JPEG entirely?"

Vlad: "No, but it does mean being smarter about when we use it. For photographic content where AVIF offers superior compression, that's the container format which will accelerate rendering and make the main thread work less. The encoding pipeline matters as much as the format choice — things like mozjpeg can give significantly better compression than standard JPEG encoders."

Sizing: One Image Is Not Enough

Serving a single large image to every visitor ignores the range of screens and connection speeds your users actually have.

  • The amount of JPEG data delivered on mobile pages has increased 20-30 percent year over year even as device pixel ratios have grown.
  • To manage this, we should adopt the srcset and sizes attributes to supply different versions of an image based on viewport width and resolution.
  • Content delivery networks like Cloudinary can resize on the fly so you can generate new sizes without rebuilding assets.

With responsive images, you're matching the files delivered to what the layout actually needs. The key number is the intrinsic size of the image in CSS pixels, not the raw pixel dimensions.

Storyblok

A Loading Strategy: Lazy, But Not Too Lazy

Your loading choice could add a few hundred milliseconds to the "time to render the first meaningful content on screen" figure just because you're waiting for a large image at the top of the page.

I'd recommend in general keeping the initial experience light. If you need heavy JavaScript or third-party scripts, pull them in only after the content is already visible. Always keeping an eye to what's performant, accessible, and user-friendly.

The Two-Attribute Way: loading and decoding

The modern approach doesn't need a JavaScript library. A few HTML attributes make lazy-loading almost trivial:

  • loading="lazy" on <img> elements defers off-screen images until the user scrolls close to them.
  • decoding="async" allows the browser to decode images off the critical path so rendering isn't blocked.
  • Critical images above the fold should use fetchpriority="high" (where supported) to signal they should be fetched with urgency. This new API can meaningfully improve LCP when used carefully.

Wes: "Why not lazy-load everything? If I lazy-load my hero image, it stays fast, right?"

Jake: "The risk is that if your hero image is above the fold and you mark it lazy, you delay LCP even worse than if you'd just fetched it. Lazy-loading exists moves the rendering cost out of the initial page load into scroll, but only for below-the-fold screenshots. Hero images should always be eager."

Modern browsers also have their own heuristics in Chromium — with the native lazy-loading, the distance threshold for loading off-screen content adjusts basically depending on network conditions and whether data-saver is active.

What About Height and Layout Stability?

Part of image performance is future-proofing for interactions. Adding explicit width and height attributes on images reserves the layer-out space while loading, even when giving them a responsive width: 100% in CSS goes together with height: auto. Reserving space prevents content shifting as images arrive after other content — that shift penalty harms Web Vitals scores.

The need to supply decode hints like heavy image from page speed? Chrome is adding built-in lazy images via the auto-sizing feature, which can avoid layout shifts totally in cases where host isn't responsive.

Automation Is the Future

If the image strategy in your team now includes a manual step for compressing or converting image files, you're basically a constraint on being able. The real "step by step" answer, Osmani argues, is the tooling: components that, at build time or runtime, compress, resize, and convert images into next-gen formats automatically.

An image CDN, for example, exposes transformation URLs. You request your image with parameters, as easy as the URL changing, and the server returns the tuned result. An automatic workflow should probably always remove metadata like EXIF from images, since that's not user-visible — another quick fraction to offer as a default.

If you integrate this further, a network-based "image optimization" layer may use your images' real log data. It could cycle over different compressions and compare loading performance with A/B tests, picking the least version that still looks good in real-world metrics.

Practical Tooling in Short

What if you are at 2021 working on

  • eleventy-plugin-respimg, or if you use a typical component like gatsby-image or next/image — relying on lower-level like sharp or imagemin then integrates with a pipeline that defaults to production build.
  • In project works best when you can run via CLI one folder in and output an optimized version.
  • Measure, measure, measure — when testing, always test with throttling networks, not just your dev machine's local cache. Performance that's good in fast connection is irrelevant.

The workflow described isn't about "the part coming down to" one command either — many tools display baseline and overlay views compare to evaluate changes given an acceptable visual quality.

One tip for people starting clean: an incremental approach is far more

Upcoming in Image Optimization

Native image lazy-loading is no longer experimental in most engines. The next wave could be better native handling of container queries and picture combinations for width density descriptors, now supported more consistently.

A well prepared setup (WebP maybe soon AVIF) is deliver on web requests by robots. It's plain but powerful: The difference between optimization in 2021 vs earlier years

Why Image Optimization Demands More Than a “Save for Web” Habit

Images have been central to the web for decades, and our brains process them faster than text, yet the field has become surprisingly dynamic. Addy Osmani, Engineering Manager on Google Chrome and author of the Smashing book Image Optimization, notes that he never intended to write a book on the topic. The project began as a simple article and expanded over roughly two years as the tooling and formats around images kept shifting, forcing constant last-minute updates to chapters as browsers evolved. New support for WebP, AVIF, JPEG XL, and native lazy loading has made it difficult for even dedicated developers to stay current.

The basic rules of thumb — JPEG for photos, PNG for graphics, and running exports through a tool like ImageOptim — are now just table stakes, Osmani argues. Modern optimization must factor in codec choice, user environment, device constraints, and network quality. Compression itself splits into lossless, which reproduces the original file exactly on decompression, and lossy, which trades some fidelity for much smaller file sizes. Lossy compression can be likened to a fax machine: the result conveys the same essence but loses the perfect original. The ongoing challenge for codec designers is squeezing out maximum quality while keeping file sizes reasonable.

Beyond the JPEG/PNG Binary: Choosing a Common Denominator

JPEG was built for lossy photographic compression and has characteristic banding artifacts, while PNG was designed to reproduce non-photographic images without data loss. Around 2010, WebP started beating both on compression, but even reaching full browser support took considerable time. Osmani points out that true support also requires more than just browser decoding; it demands operating system integration, CMS support, and a portable file that users can easily share — something like iOS handling HEIC files and converting them to JPEG for sharing when needed.

For sites where storing multiple format variants is costly, Osmani suggests reassessing which format makes sense as the default. Many developers have relied on catching users with the picture tag and a JPEG fallback. These days, serving WebP as the primary format is worth considering for most audiences, barring users on very old browsers. For a forward-looking, single-format choice, JPEG XL is promising — though not yet shipping in any browser, it offers general-purpose high fidelity, lossless support, progressive decoding, lossless JPEG transcoding, and is royalty-free. It was developed from roots in Google’s PIK and Cloudinary’s FUIF and is expected to outperform WebP generation one.

  • JPEG XL: ideal for general medium-to-high fidelity use cases; major potential successor to the current default.
  • AVIF: best when hitting very low bitrates matters more than absolute fidelity; based on the AV1 video codec standardized by the Alliance for Open Media.
  • Storage considerations: Fewer formats can mean less cost, but an image CDN can offload the maintenance.

Costs and Tooling: When To Go Static, When To Go CDN

The decision between a static build-time pipeline and a commercial image CDN depends largely on scale, budget, and the skills of the content creators. A developer with a small blog and minimal images can probably handle the job at build time with something like sharp and a couple of npm packages. For projects with hundreds of thousands of images, a slide-sharing service for instance, an image CDN becomes a convenience that might pay for itself in saved engineering hours, even if the subscription fee looks significant at first. Osmani recounts hesitating to use Cloudinary on personal projects because of cost, only to realize it saved him the time he would otherwise spend debugging custom pipelines.

For teams that cannot justify a CDN, running images through a static converter or a set of scripts at deployment might be enough. Others can use CDN features like automatic quality detection, which examines each image’s content and serves the optimal quality setting without a hard-coded value. Whatever the approach, keeping the codebase flexible enough to switch between a custom pipeline and a third-party service is sensible hygiene when depending on external services.

The Risks of Batch Conversion and Generational Loss

Batch converting an inherited set of legacy images to a modern format can be a viable strategy, but the risk of generational loss increases with each compression step. Re-encoding an already-lossy JPEG into a new format can degrade fine detail. If the goal is preserving family photos, a lossless or high-fidelity modern format and acceptable storage overhead may occupy a better position on the trade-off curve. For product catalogs, user expectations about texture and clarity matter; taking a smaller sample of images and running a more careful set of quality experiments there, before rolling out a full batch conversion, helps avoid mishaps.

Osmani recommends using metric-driven comparisons such as DSSIM to quantify perceptual difference between source and output and to pinpoint the right quality parameter before batch running. Time-poor editors can still get a good result by hand-picking a few images and converting them at recommended quality settings, then eyeballing the difference.

Modern Formats Have Learned From the GIF Problem

Animated GIFs dominate as a de facto video container despite severe technical shortcomings: a 256-color palette limit, bitmap storage, and inefficiency for animation. The remedy is obvious in hindsight — serve a muted, autoplaying video element where a clip of animation is needed, and use imagery with modern animation support. Offering CMS users a way to upload video instead of falling back on GIFs, or adding an automated pipeline that converts GIF uploads, reduces a whole class of bloated heritage. The matter of format efficacy also affects everyday compression. Legacy formats carry baggage because they were not conceived for web delivery; optimizers such as ImageOptim strip extraneous text, metadata, and other information that the web does not need. Osmani sees these tools remaining useful — though newer formats are more resilient to the generational loss that occurs when a file is re-compressed repeatedly while resurfacing as a meme across social networks.

Core Web Vitals: A Practical Lens on Image Usage

Google’s Core Web Vitals propose three metrics to track: largest contentful paint (LCP), cumulative layout shift (CLS), and first input delay (FID). They may influence Google Search ranking as part of the page-experience signals. Images are the largest element on many pages — hero shots, product shots, banner landscapes — so their technical choices strongly influence these metrics.

For LCP:

  • Request your hero or main image as early in the parse as possible, even as far up the document as the head via link rel="preload".
  • Make sure your images use a modern format and a custom srcset. Over-engineering srcset with 10 versions for a single image yields diminishing returns; more than three device-pixel-ratio candidates are rarely visible to a user.
  • Keep the quality levels honest — test lower values at any given quality setting to find the sweet spot between size and perceived sharpness.
  • Stick to lazy loading where possible. Native loading="lazy" is built into Chromium and Firefox, requires no JavaScript library, and remains tuned to the thresholds used for the cheapest, most standard use case.

For CLS:

  • Set explicit width and height dimensions on all images and on any element that might shift — ads, iframe content, dynamic modules.
  • Responsive design had removed dimensions from sites, but dimension-free layout defeats the browser’s ability to reserve space and contributes directly to visual instability.
  • Use CSS aspect-ratio support or classic aspect-ratio boxes to create space for fluid galleries and card-based interface patterns.

For FID:

  • Treat heavy image workloads as indirect culprits for slow interaction. On low-end hardware and constrained connections, a wall of images competes with JavaScript bundles for bandwidth and CPU time, blocking the main thread.
  • Reorder requests so that above-the-fold, necessary resources appear first and below-the-fold images wait for later.

Signals Like Save-Data and Content Negotiation

Rather than assembling large picture markup fragments for every possible fallback, content negotiation removes that burden from the client. An image CDN can read the browser’s supported MIME types in the Accept header and respond with the right format automatically — with no role for client-side logic in picking the representative variation. This keeps the HTML clean and lowers developer overhead.

Like Accept headers, client hints such as Save-Data convey a user’s explicit preference for reduced data use on metered, slow, or unreliable networks. High-traffic sites can also use that signal to conditionally serve lighter experiences — smaller images, stricter caching — or to turn off non-essential JavaScript components and deliver a stripped-down, functional page to users in low-connectivity environments.

Osmani closes with a slice of web history: Tim Berners-Lee uploaded the first web image in 1992 while working at CERN. The subject, however, was not a cat. It was a photo of the all-female parody pop band “Les Horribles Cernettes,” known for singing about particle accelerators and liquid nitrogen. The subject remains more charming than prescient — image types, compression, and standards have changed beyond recognition since.