What developers told us about image optimization

During the summer of 2019, Google's Web DevRel team ran a survey on image optimization techniques. The goal was to understand why most sites skip what look like straightforward performance wins. Responses came in through Web Fundamentals and the @ChromiumDev Twitter account, with the freeform feedback compiled below. The survey response data has been omitted due to methodological flaws.

Why the feedback matters

  • Web developers can find practical details on optimization techniques others have used, including costs, benefits, and common pitfalls.
  • Image service and CDN providers may spot unmet needs worth building toward.
  • Framework, build tool, and CMS developers can get ideas for features that would help users ship optimized images by default.

Common themes in the comments

Respondents raised several recurring points about why image optimization is hard in practice, even when the techniques are well understood. Many noted that the effort required to implement responsive images, format negotiation, and compression pipelines is usually manual and repetitive.

Other themes that came up repeatedly:

  • Format adoption lags in part because of inconsistent browser support and concern about fallback behavior.
  • CMS workflows and content editing interfaces often strip or ignore optimization metadata.
  • Build-time tooling exists but is not universally integrated, so many developers end up writing custom scripts.
  • CDNs and image services ease the burden, but cost and lock-in are cited as real constraints.

Several developers also said that documentation, while thorough, tends to focus on individual techniques rather than showing how to combine them coherently. Advice on sequencing — when to resize, when to compress, when to serve WebP — was requested more than once.

Notable suggestions and concerns

A few respondents shared concrete ideas about what would make image optimization simpler:

  • Better tooling that tracks image weight during development so regressions surface early.
  • More prescriptive guidance for handling images in responsive layouts, beyond specifying srcset and sizes.
  • Tighter integration between image libraries and content management platforms so editors can't accidentally bypass optimization.
  • Clarity on when the tradeoff of using a paid image CDN is actually justified.

Takeaways

No single solution emerged from the survey. For some, the gap is knowledge; for others, it is tooling or infrastructure. But the overall message is consistent: image optimization is rarely one decision, and developers would benefit from more comprehensive workflows, not just isolated tips.

What practitioners told us: format gripes, workflow pain and browser gaps

WebP remains the format developers most want to use — and the one they feel least able to adopt. The recurring complaint is ecosystem support, not the format itself. Respondents pointed to missing export options in Photoshop and Figma (though Sketch does support WebP), WordPress themes that don't handle it, and Apple's Safari lagging behind. Several noted that Google Docs cannot display WebP files. One developer put it bluntly: "First fix browser compatibility and update legacy browsers or add legacy fixes, then people will be more inclined to adopt to new image types like WebP." Another suggested the push for adoption should target tool and theme authors, so that "non-developers don't need to fiddle with it."

SVG earned praise where it is used, especially for vector-heavy sites and animated graphics. One respondent highlighted gatsby-image as a fix for many image workflow problems but argued the browser should take on more of that responsibility itself. Others expressed interest in documentation for building SVG animations with lottie.js. For raster content, the common practice is large, low-weight JPEGs plus SVGs "when necessary to provide quality for responsive design." One developer asked for help educating users to stop uploading GIFs.

Lazy loading divides users; background images complicate the markup

Opinions on lazy loading split sharply. Some developers find it essential for keeping users engaged without loading high-quality images early, and one asked for guidance on using the Intersection Observer API instead of older techniques. Others reported serious breakage: one team "converted from lazy loading a long time ago" after users described sites with millions of images as "NOT LOADING"; another respondent asked for the native lazy load attribute to work with background-image. Several replies noted that frameworks should handle asset processing better out of the box.

A recurring theme is that <img> markup does not fit every real-world need. One developer said they usually load images as CSS backgrounds instead, because the tag is "problematic and difficult to control fine-grained details about" with user-submitted content. Using <div> with background-image styling allows background-size, background-position and prevents right-click saving. The downside is that this approach complicates lazy loading and responsive handling.

Responsive images: reflow, crop and connection limits

Page reflow was a frequent pain point when combining CSS width rules, responsive images and art direction from <picture> or adaptive images. One developer described resorting to a "negative padding hack" to reserve a fixed aspect-ratio box, and asked for better native handling of responsive image layout. Another wanted the browser itself to auto-crop from a single large upload: "writing a simple picture tag that browsers will automatically create the multiple src attributes would be a winning feature."

Sizing also drew complaints about volume and cost. One respondent said their workflow generates roughly 12 sizes per image and asked for a way to generate fewer. Another cited intrinsicsize as less useful than leveraging height/width attributes. A performance issue surfaced where showing 60 thumbnail cards on scroll triggered the browser's six-connection-per-domain limit, blocking both thumbnails and the next AJAX request. The same developer noted they would prefer HTTP/2 but "most of our customers use IE11," so they are exploring domain sharding or moving AJAX off the main domain.

High resolution versus web delivery

Organizations working with print-quality originals feel the tension acutely. A document management company handles millions of high-resolution TIFF or PDF scans. Academic publishing workflows struggle because authors must supply print-grade files, yet those same files require downscaling for the web — leading to mixed messages and complex processing pipelines. Smaller operations asked how to compress images "without losing DPI quality."

For others, the answer to expensive multi-size pipelines is a single, oversized, well-compressed file. "You need around 1000 pixels wide images for mobile (500px render width) and that is also the size you need for large/desktop non-retina displays," one developer said, calling image-resizing CDNs "a very bad solution" compared with handling resizing in the CMS. Cloudflare customers reported automatic scaling that matches the user's display without extra markup. Cloudinary users appreciated easy srcset generation but warned the service "gets expensive, really fast. This feels like a major hole in the development experience."

Content management and the cost of constant change

CMS authors routinely upload images at arbitrary sizes and formats, leaving developers unsure whether to force max-width or scale content. Self-serve systems make it hard to add controls that work automatically "without affecting resolution," and images often look wrong on mobile versus desktop. WordPress specialists said the hardest problems are dependence on plugins or CDNs for WebP, correctly coded srcset in themes, slow lazy-loading plugins and lazy-loading background images.

A wider frustration is that the goalposts move. One developer described saving images, checking the site, then finding months later that new guidance demands more compression or a different format — work their small-business clients cannot fund repeatedly. "Writing the code to call different image sizes for different devices is also time consuming," they said, asking for a system that stays consistent longer.

Another response took aim at Lighthouse's "Keep Request Counts Low And File Sizes Small" audit. Over HTTP/2 with a single hostname, roughly 35 tiny WebP files (mostly 1–2 KB or less) load quickly, but the audit flags the request count anyway. "I could load a sprite but then more CSS computing needs to be done," the developer noted, asking the audit to account for HTTP/2 multiplexing.

Beyond the mechanics, several comments touched on the human and editorial side: the web still has too many decorative images that don't add to content, quality versus file size is a hard balance when both affect SEO and UX, and cross-browser unpredictability means "the simplest solutions are often the safest." One survey participant wrote a blog post in response, suggesting the community is actively thinking beyond the survey itself.