Build Size, Load Time and the Slow Death of a Playable
Playable ad file size limits are not a submission technicality. They decide whether a player ever sees the mechanic you spent weeks building.
A playable ad that takes six seconds to load has already lost most of the audience it exists to convert, and it lost them before a single frame of gameplay rendered. Every network's playable ad file size limits exist because of this exact failure mode, not as an arbitrary submission hurdle. Treating them as a late-stage compliance check rather than a design constraint from day one is the single most common reason playables underperform their own creative quality.
The problem is physics, not policy
Network file size caps vary, but most sit somewhere in the region of 2 to 5 megabytes for the initial payload, with some networks allowing streamed or cached assets beyond that ceiling under specific conditions. The number itself matters less than what it stands in for: how long a user on a mid-tier Android device on a mobile network connection waits before anything interactive appears on screen. A playable that clears a network's size limit on fast office wifi during QA can still take four or five seconds to first frame on the device and connection profile most of its actual audience is using; file size and real-world load time correlate, but they aren't the same thing, and testing only on ideal conditions hides the gap until performance data comes back weak.
The cost of that gap isn't gradual. Attention on a playable ad does not decay smoothly across a loading screen; it drops off a cliff after roughly two to three seconds of unresponsive screen time, at which point a meaningful share of users have already swiped past or closed the ad. A playable can have a genuinely excellent core mechanic and well-tuned pacing, plus a strong end card, and still convert poorly if the first three seconds go on a static loading state. Most of the audience that would have appreciated the mechanic never saw it.
Where the bloat actually comes from
Three sources account for most oversized playable builds, in order of how often they cause a genuine problem: uncompressed or over-resolution art assets (background imagery and character sprites in particular) exported at a resolution far beyond what a phone screen inside an ad unit actually displays; audio files included at unnecessarily high bitrate or, worse, included as a full music loop when a short stinger would serve the same purpose; and unused code and asset remnants left over from earlier iterations of the playable that never got stripped from the final build.
Discipline, not cleverness, solves the first two. Export art at the actual display resolution the ad unit will render at, not the resolution the source design file happened to use, and compress audio aggressively, testing perceived quality on an actual phone speaker rather than studio monitors. The third needs a build-hygiene step most teams skip under deadline pressure: a final pass that removes every asset the shipped scene doesn't reference, which a bundler can often flag automatically if the tooling supports it.
A build size budget by network
Rather than optimising after the build already exceeds a limit, set a budget before production starts:
- Meta Audience Network and Google's playable formats typically expect initial payloads in the low single-digit megabytes; budget for 1.5 to 2 megabytes as a working target, leaving headroom before the network's hard cap for the inevitable late additions during QA.
- AppLovin, Unity and Mintegral often tolerate larger initial payloads with caching, but a lower target still produces a faster first frame regardless of the technical ceiling, so treat the technical maximum as a ceiling, not a target.
- TikTok's playable specs have historically been stricter on total payload than several other networks; confirm current limits directly before finalising art direction, since building a stylised, asset-heavy concept first and discovering the size constraint at submission means reworking the art direction under time pressure rather than by choice.
- Reserve at least 15% headroom below whatever limit is confirmed, since analytics SDKs, tracking pixels and end-card assets added late in production reliably add size that was not accounted for in the initial budget.
Measuring what actually matters
File size compliance at submission is a necessary check, not a sufficient one. The metric that predicts conversion is time to first interactive frame on a representative device and network profile, which most playable QA processes don't measure directly even when they measure file size correctly. Test on a mid-tier Android device over a throttled connection profile, not a flagship phone on office wifi. That catches load time problems a file size check alone will miss, because two builds of identical file size can have meaningfully different load times depending on asset loading order and on whether the build loads critical path assets before background ones.
The trade worth making early
When a playable concept and a size budget conflict, the fix almost always belongs in production, not in a post-hoc compression pass. A concept built around a richly rendered 3D environment is fighting the file size budget from its first storyboard, and no amount of texture compression at the end will fully close that gap without visibly degrading the art. A concept that carries the budget in mind from the brief onward, using simpler shading and smaller sprite sheets, with shorter audio cues by design rather than by cut, reaches the same emotional impact with an actual chance of loading before the user has moved on. The QA checklist this desk covered in "The Playable Ad QA Checklist to Run Before Submission" catches a build that is too large before it ships. The better fix is a brief that never asks for one.
