Playable ad file size budgets by network
Networks cap playable builds differently, some near 2MB, others closer to 5MB under MRAID. A production checklist for compression without losing feel.
Every network that accepts playable ads publishes a file size limit, and almost none of them publish the same one. Some hold builds to roughly 2MB to guarantee a fast load on weak connections. Others allow closer to 5MB under standard MRAID delivery, and a handful of premium or rewarded placements tolerate larger builds because the viewer has already committed to watching before the playable loads. A pipeline that targets one number and hopes it clears every network is the single most common cause of last-minute rework in playable delivery.
Build to the tightest constraint, not the average
Design the master build against the tightest limit a studio expects to submit to, then treat any looser network's extra headroom as a bonus rather than a baseline. Building to an average and then shrinking an already-finished playable for the strictest network almost always costs more time than designing conservatively from the start. Compression applied after the fact hits whichever asset compresses easiest, not whichever asset can afford to lose quality.
Where the size actually goes
Texture atlases are usually the largest single line item in a playable build. They are also the easiest thing to over-provision, early in production, before anyone has measured what the final scene needs on screen. Combining sprites into a single atlas rather than shipping dozens of individual images cuts both file size and load-time overhead. Trim atlas resolution to the actual on-screen pixel size rather than the resolution of the source art, and you recover space at no visible cost in most cases.
Audio is the trade-off teams get wrong most often. A short compressed sound cue for a tap or a success chime costs almost nothing. A looping background track, even compressed, can rival the texture budget on a tight build, and it is rarely the element a completion-rate test shows players missing. Cut or shorten background audio before you cut a core interaction asset; under deadline pressure that is usually the right call.
Code and framework overhead is the third major line item, and the one production teams have least room to negotiate once a game engine or playable framework is chosen. Which is why the framework choice at the start of a production cycle matters more to final file size than any compression pass bolted on later.
A QA matrix, not a single pass
Check file size compliance against each destination network's actual limit, not against a single internal target, because a build that clears one network's cap can still bounce from another's.
A workable matrix tracks four things per network. The file size limit. Whether the network wants MRAID or a proprietary wrapper, whether it counts compressed or uncompressed size, and the load time you observe on a throttled connection rather than studio wifi. That last column catches more rejections than the size number itself, since a build can be small and still load slowly if the assets arrive in the wrong order.
The result is worth protecting
A companion piece here, Why Staged Loading Beats Compression for Playable Ads, made the case that perceived load time matters more than raw file size once a build sits inside a network's limit, sequencing what the player sees first rather than shrinking everything equally. The two disciplines work together: get under the tightest network's ceiling first, then use staged loading to make whatever size remains feel instant. Treat file size as a compliance checkbox that you clear once and forget, and you will rebuild the same playable for a second network mid-campaign instead of once at the start.
Keeping the budget honest over time
A file size budget set at the start of a production cycle drifts upward as the build goes through revision rounds. One more particle effect here. A slightly higher resolution background there. None of it looks significant on its own, and the cumulative effect over several iteration passes can push a build past a limit it originally cleared comfortably, which nobody notices until a late-stage submission bounces. Check build size against the target at every iteration rather than only at final submission, because that is the cheapest way to avoid a last-minute scramble for savings under deadline pressure, when the easiest cuts to make are usually the ones with the most visible impact on feel.
