Find more room to optimize images for constrained devices.
Image optimization is a problem developers have been working on for decades.
Modern formats and dedicated image services have already made assets considerably smaller. But through its work on streaming and media applications, REDspace began to see signs that those systems were still leaving performance on the table.
To investigate, REDspace developer Ali Hashemi created Kusana, an experimental asset-processing system.
The results showed there was more room to optimize than expected.
The limits of one-size-fits-all image optimization.
A well-optimized media application can still end up pushing hundreds of large images to a device with limited memory and processing power.
That’s especially challenging on older televisions and set-top boxes. A modern streaming device may handle a large image without much trouble, but devices with smaller CPUs and limited memory have far less room to work with, and they are often the ones receiving the least optimization.
The application team may not control those images either. News and sports applications, for example, can pull assets from advertisers or external content providers. Streaming services may receive artwork from third-party metadata systems. Those images can arrive at resolutions far beyond what the application needs.
REDspace had seen teams deal with that problem manually. Engineers would identify an oversized asset and ask the provider to replace it. Another large image could appear later and restart the process.
Image services already help by resizing assets or delivering them in formats such as Webp. But during the development of Kusana, Hashemi found consistent savings left behind even on assets those services had already processed..
Part of the reason is structural. Services at that scale are built for consistency across billions of assets, not the best possible outcome on any single one. Those are different goals, and they produce different results.
“What surprised me was how much room was still there, but 'good across the board' and 'the best you can do for this particular image' turn out to be two very different numbers,” Hashemi says.
No single approach is the right answer for everything passing through.. A photograph with a wide range of colours has different characteristics from a simple logo.
That discovery became the basis for Kusana’s approach. Handling assets individually rather than uniformly and fast enough for a live application. That is what Kusana was built to do.
Designing for high-volume image processing.
If Kusana were ever placed between a media application and its image assets, potentially every request would pass through it.
The processing layer therefore had to be fast enough to avoid becoming another bottleneck.
Hashemi chose Rust as the foundation. The language offers performance close to C and C++, along with memory safety and a memory-management model that doesn’t rely on garbage collection. That helps reduce the risk of performance spikes when traffic is high.
“I didn’t want to have a proof of concept that just proved it works,” Hashemi says. “I had in mind that this could be used by millions of users with the highest possible traffic, so I wanted to support that from the base.”
That foundation left room to do more per asset than a general-purpose pipeline can afford to. Every image gets its own treatment, produced at request time.
It can also resize an asset for the dimensions the application actually needs. A source image that’s thousands of pixels wide can be requested at a width of 300 pixels and processed on the fly.
Beyond traditional image assets, Kusana also supports compressed textures, extending its potential to WebGL and WebGPU applications, games, and platforms such as Roku, Android TV, and Apple TV. Optimizing these assets can reduce memory usage, processing demands, and delivery costs on constrained devices without requiring changes to the original assets.
Kusana can act as a proxy for an externally hosted asset. The application provides the remote URL, and Kusana retrieves the image before processing the version to be delivered to the device. The original file stays untouched.
That means a development team can optimize an image supplied by an advertiser, metadata provider, or other external source without waiting for the owner to replace it.
Handling remote assets solves one problem. Fitting a new service into an existing media stack creates another.
Large applications may already rely on services such as Akamai or Cloudinary. Rewriting image requests across multiple platforms just to evaluate another approach can create enough friction to stop a pilot before it starts.
Kusana can understand existing URL patterns used by those services. That makes it possible to point current requests toward Kusana for evaluation without first changing image references throughout an application.
The architecture also includes three interconnected caching layers designed to work together for efficient and reliable asset delivery while preventing stale images from being served. Telemetry tracks how requests move through the layers and whether they result in a hit, miss, or soft/hard revalidation. Each layer is also backend-agnostic, allowing it to integrate with existing cloud providers, storage systems, CDNs, or other connected infrastructure.
Together, those choices were intended to make Kusana practical under the same conditions REDspace sees across real media applications.
Testing against real OTT traffic.
REDspace evaluated Kusana using image requests captured from a real OTT application running on Comcast hardware.
The test reproduced a normal user session. As the application was navigated, the device downloaded 446 images through its existing image service.
Those requests transferred approximately 18 MB of image data.
The same assets were then processed through Kusana.
On the older Comcast device, the amount of image data transferred fell by approximately 61%.
Individual files showed how those reductions added up. One image that had originally required roughly 500 KB was reduced to around 30 KB.
REDspace repeated the test on newer hardware. The existing image service was already returning better-optimized assets to that device, but Kusana still reduced the amount of transferred image data by approximately 49%.
The reduction in file size could be substantial even when the visual difference remained subtle. In one example, an image of roughly 240 KB was reduced to around 40 KB.
Smaller assets give constrained devices less data to download and process. At the scale of a major media application, the bandwidth savings can add up quickly. Across millions of requests, reductions of roughly 50% can translate into terabytes less data moving through a CDN.
The exact financial impact depends on an organization’s traffic and CDN agreement. But reducing bandwidth at that scale creates a clear opportunity to lower delivery costs alongside the performance gains.
Exploring where Kusana could go next.
Kusana remains an experimental REDspace project, but its early tests have shown that established image-delivery systems can still leave meaningful room for further optimization.
The architecture was also designed to work with more than images. Future development could extend the same processing pipeline to assets such as video or audio. As REDspace continues to evaluate Kusana, the project could eventually become a capability that can be tested with more media clients facing the same performance and delivery challenges.
