The tension, and where it actually resolves
Every byte you strip out is a byte a network's webview doesn't have to download and decode before the ad can respond to a tap — which is why every major network caps size at all. But quality is also the entire point of a playable; a build that loads fast and looks compressed to mush converts worse than one that's slightly heavier and actually sells the game.
The two goals usually aren't in real conflict, though. The biggest size reductions tend to come from assets that were never buying any visible quality — a UI texture exported at 2048px that renders at 200px, a WAV file where an MP3 would be indistinguishable, three near-identical background variants when one would do. Fixing those costs nothing visible. The tradeoffs that do cost visible quality — dropping a texture a compression tier, shortening a video — are worth making deliberately, only after the free wins are gone.
For the mechanics of why playables blow their size budget in the first place, see our breakdown of playable ad compression and size limits — base64 embedding alone adds roughly a third to every asset's size, unavoidable for networks like Google and Meta. This article assumes that context and focuses only on what you can change in the Unity project before any of that encoding happens.
The checklist: what to do before you export
1. Fix texture compression and resolution first
Check the import settings on every texture: the compression format, and whether the max size is actually justified by where it renders on screen. A background or UI element filling a phone-sized canvas rarely needs a 2048px or 4096px source texture — most playables are viewed at a few hundred pixels across. Dropping an oversized texture to a sane max size and a proper compressed format is usually the single largest, least visible size win available.
2. Set a sane audio bitrate, and trim what you don't need
Lower the bitrate on music and sound effects to something a phone speaker can't distinguish from the original — mono is often enough for effects and voiceover that don't need stereo separation. Then trim leading/trailing silence from every clip, and delete any clip left over from an earlier iteration of the creative that nothing in the current build actually plays.
3. Remove unused assets from the build, not just the scene
An asset unreferenced by the active scene can still get pulled into a build if it sits in a folder Unity treats as part of the bundle, or an old prefab still points at it. Do a pass specifically for textures, audio clips, and prefabs left behind from previous variants of the ad — they contribute zero gameplay or visual value and still cost real bytes once base64-encoded for delivery.
4. Reuse and share assets instead of duplicating variants
Playables often end up with two or three near-identical versions of the same button, background, or character pose — each saved separately because a variant was tried and never cleaned up. Consolidate to one shared asset wherever the visual difference isn't load-bearing, and reuse the same texture/sprite across multiple UI elements instead of exporting near-duplicates. Every duplicate removed is pure savings, no quality tradeoff involved.
5. Weigh video against sprite-sheet animation for short loops
For a few seconds of looping motion — a spinning coin, a celebratory burst — an embedded video file is often far heavier than the same motion built as a sprite-sheet animation, especially once base64-encoded for a network that requires it. Video wins when content is genuinely video-like (real footage, complex simultaneous motion); a short, simple loop is usually cheaper and just as effective as a sprite sheet. If you do need embedded video, keep it as short as the creative allows and re-encode at the lowest bitrate and resolution that still looks acceptable on a phone screen.
6. Test the real post-conversion size after every change — don't guess
Raw asset size in your Unity project isn't the number a network measures against its cap. Base64/base122 encoding, Luna's cache format, and per-network packaging rules all change the final byte count, sometimes substantially. After each round of changes above, run the export through PlayableKit's free Size Checker instead of estimating — it converts your actual Playworks/Luna export through the same engine used for paid builds and reports the real size per network, so you know whether a change actually moved the needle before doing more work.
What this checklist is, and isn't
Every item above is manual, source-level work inside the Unity project, before anything gets uploaded to PlayableKit — that's deliberate, not a limitation we're glossing over. PlayableKit's converter measures your build accurately and packages it correctly for each network's actual rules, but it does not run a lossy re-compression pass over your images or audio, and it doesn't decide on your behalf that a texture can drop a compression tier. It re-encodes Unity's already-compressed asset cache for browser-safe delivery and applies the most space-efficient embedding a given network's spec allows — but neither step makes an oversized JPEG or an uncompressed WAV smaller. If the checklist above hasn't been done, the converted output will faithfully reflect that.