In a shopping app, images are the product surface rather than decoration. Users judge fabric, finish, colour and fit through pixels. That makes image optimization unusually constrained: a smaller response improves transfer time and can weaken the purchase decision, while a larger one preserves detail and wastes bandwidth, decode time and bitmap memory. Neither bytes saved nor request latency can serve as the success criterion on its own. This session covers how we rebuilt Android image delivery around that constraint, the five experiments we ran, and why the approach that shipped was the least sophisticated of them. The work started with observability, because "image load time" collapses several unrelated clocks into a single number that confirms a user waited without explaining why. We decomposed every load into preparation, fetch and render, correlated OkHttp and Cronet network events with the eventual Glide result even when format and domain transformations changed the URL in between, and did it without letting per-image telemetry become its own bandwidth and storage regression on a scrolling feed. That instrumentation let us test hypotheses rather than argue about them. Raising dispatcher concurrency reduced queue wait without improving total delivery, because concurrency reschedules work instead of creating bandwidth or decode capacity. Bandwidth-aware downscaling was rolled back, because connection classification was not stable enough to be trusted with image quality, and detail removed at request time cannot be recovered on the client. Low-quality placeholders bought an earlier first pixel at the cost of a second request competing with the real one. Multi-resolution cache reuse helped, but only in one direction. Prefetching image URLs discovered during API response deserialisation accelerated a future screen when the predicted cache key matched, and stole bandwidth from the critical path when it did not. What shipped was a rule. Measure the width of the rendered surface, round up to the nearest supported bucket, and request that variant. It removed waste without asking users to accept less product detail, and it reduced response size, decode cost and bitmap memory together rather than trading one against another. The rule is trivial. Making it safe required display width to reach the image layer, a bucket set that never upscales, predictable cache identities, and a CDN generating the same variants. Attendees will learn how to: Decompose an Android image load into preparation, fetch and render, and instrument it without the telemetry becoming its own performance problem Attribute a slow fetch to dispatcher admission, cold connection setup, time to first byte or payload transfer when OkHttp and Cronet split ownership of the request Tell apart optimizations that reschedule work from those that remove it, and why only the second kind compounds Design one-way cache reuse so a larger cached bitmap can serve a smaller surface without ever upscaling into a false cache hit Judge when speculative work such as prefetching is safe, and when backpressure lets it delay the very screen it was meant to accelerate The session is aimed at engineers who own an image-heavy Android surface and suspect their image pipeline is expensive, but cannot yet prove where the cost sits.