A Year-End Playable File Size Load Time Audit to Run
A playable file size load time audit to run before 2026 briefs go out, covering network limits, asset bloat and device drift.
A playable file size load time audit is not the same exercise as a pre-launch QA pass, and treating it as one is why so many portfolios drift back into bloat within a few months of a clean launch. Pre-launch QA checks a single build against a spec. A year-end audit checks every live playable in the portfolio against the specs those networks enforce today, which have usually moved since each build first got approved.
As covered in this desk's earlier piece "Build Size, Load Time and the Slow Death of a Playable," file size creep is gradual, arriving one asset swap or one added interaction at a time, until a playable that launched under a network's limit sits quietly over it. Then it either gets rejected on resubmission or, worse, keeps running while loading slowly enough to lose players before the interactive moment ever appears. December is the natural point in the calendar to run this check across the whole live set rather than one title at a time, with most Q4 campaigns closing out and January briefs not yet locked.
Why specs drift under a live playable
Network file size and load time requirements are not static. Meta and Google have both adjusted creative specs at various points this year, and so have TikTok and the major rewarded networks, which means a playable approved against last spring's limits is not guaranteed to meet this winter's. Live playables also accumulate small production debts. A placeholder texture that someone meant to optimise before launch and never did. A localisation pass that added string assets without a matching audit of total payload. Or an SDK or analytics update that added weight nobody flagged as a creative concern, because it never touched the visual build.
The audit, portfolio-wide
Run the audit in one pass across every currently live playable. The value of the exercise is comparative, which is why waiting for each build's own review cycle throws it away: seeing which builds have drifted furthest makes it obvious where to prioritise rework first. For each live playable, capture four things in one sheet: current build weight against each network's published limit, actual load time on a mid-tier Android device on a throttled connection rather than a flagship device on office wifi, the date the build was last re-tested against a network spec rather than just last live, and a note on any recent non-creative update, SDK, analytics, localisation, that touched the build without a corresponding size check.
What the numbers usually show
Portfolios that have not run this audit in six months or more typically find the same pattern. A handful of top-performing playables are also the oldest builds in the portfolio, because a strong performer gets left alone rather than rebuilt, and those same builds are usually the ones sitting furthest over the network's current spec. Best performance, worst compliance: that combination is precisely the set most likely to get flagged or throttled by a network at the least convenient moment, typically right before a seasonal push when the team least wants a compliance surprise.
Playable file size load time audit: a worked example
Take a hypothetical portfolio of eighteen live playables at a mid-size publisher, none audited against current network specs since its original launch. Running the four-point audit across all eighteen finds eleven inside current limits, four marginally over on file size but still loading acceptably, and three both significantly over spec and among the portfolio's top five performers by spend. One of those three is a strategy-genre playable that launched in March. It has grown from an original 4.8MB build to 7.1MB today through five separate small updates, none individually large enough to trigger a size review, and the cumulative effect now sits well above a network's 5MB limit introduced in a spec update over the summer. On a throttled mid-tier Android connection, that build's load time has grown from roughly 2.1 seconds at launch to 4.6 seconds today, comfortably past the point where a meaningful share of viewers abandon before the interactive moment loads. It also carries close to 18% of the portfolio's total playable spend. So it becomes the first item on the January action list, ahead of any new creative concept work, purely on the combination of size drift and spend concentration the audit surfaced.
Turning the audit into a January action list
The audit is only useful if it produces a ranked list rather than a report that sits unread. Rank flagged builds on two factors: how far over the current spec a build sits, and how much live spend runs through it today. A build that is only slightly over spec but carries a small fraction of portfolio spend can wait. A build that is significantly over spec and carries meaningful live budget should be the first thing a production team touches once January briefs open. A rejected or throttled top performer costs more in lost delivery than a new concept delayed by a week.
Run this audit as a standing December fixture rather than a one-off exercise, and the January backlog it produces gets shorter each year rather than repeating the same drift the audit exists to catch.
What to watch next
Watch whether networks keep adjusting file size and load time specs mid-year rather than only at defined checkpoints, since a spec that can change without a clear announcement window is the reason a single annual audit is not sufficient on its own. A mid-year check, even a lighter one, catches drift before it compounds for six months. And watch whether any network starts enforcing load time thresholds directly rather than file size alone, since a shift toward measuring actual load performance would make the throttled-device test in this audit the primary compliance metric rather than a supplementary check.
