The Next Fest demo problem
Every Steam Next Fest, hundreds of developers ship demos. Most see a wishlist bump of a few hundred. A handful see their wishlists triple or quadruple in a week. The difference is rarely about game quality. The games that underperform are often genuinely good. The difference is almost always in the demo itself.
We've built more than a dozen Next Fest demos, including browser-based WebGL versions that run inside the Steam page itself. Across those projects, three factors separate the demos that move the needle from the ones that don't.
"Sub-8-second load time. A natural exit point at 12 minutes. A save state on close. That's the pattern behind every demo that tripled wishlists."
Factor 1: Load time under 8 seconds
A player clicks "Play Demo" in their browser. They're on the Steam page, probably in a tab they opened while browsing the Next Fest catalogue. They have other tabs. They have things to do. If your demo takes 25 seconds to load, a significant portion of them won't wait. They'll switch tabs, forget, and you've lost them.
The demos we build target sub-8-second load on a median connection, which is roughly a 20 Mbps broadband connection with some latency. That means your initial payload needs to be under about 60MB uncompressed. For a Unity or Unreal game ported to WebGL, this typically requires:
- Streaming asset loading, so the game starts before all assets are downloaded
- Texture compression specific to WebGL (ETC2, ASTC, or BC7 depending on browser support)
- Audio transcoded to OGG for web rather than WAV
- Code stripping to remove unused engine features from the WASM binary
- Brotli compression on all static assets at the CDN layer
None of this is trivial to get right, but the baseline 25–45 second load time of a naively exported WebGL build is a significant conversion killer. The 8-second target is achievable with focused optimisation work.
Factor 2: The 12-minute stopping point
The best demos are designed to end. Not abruptly, not frustratingly, but with intention. They guide the player through enough of the game to understand what it is, feel its core loop, and then deliver a satisfying "to be continued" moment that converts curiosity into a wishlist.
Twelve minutes is a guideline, not a rule. The important thing is that there's a designed stopping point. Demos that just run until the player gets bored or closes the tab leave them without a clear action to take. Demos that end on a hook (a cliffhanger, a world-building reveal, the moment just before a major unlock) give players a reason to press the wishlist button.
What we look for in demo scope planning:
- Teach the core loop. Players should understand what the game is within the first 3 minutes
- Show variety. If the game has combat, exploration, and building, the demo should touch all three
- Build to a moment. The demo's final beat should be something that makes the player want what comes next
- Don't include content you want held back. Mid-game reveals, final bosses, and story twists should not appear in Next Fest demos even if they're technically accessible
Factor 3: Save state on close
This one is easy to implement and almost nobody does it. When a player closes your browser demo tab, their progress is saved. When they come back, maybe three hours later, maybe the next day, they resume where they left off.
The data on this is consistent: demos with saved progress have return rates roughly 2.3× higher than demos without. Return visits correlate strongly with wishlists. A player who plays your demo twice is far more likely to wishlist than one who played it once and left.
Browser demos can use localStorage for lightweight save data (session position, tutorial state, inventory) without any server infrastructure. If the game uses a cloud save system natively, that can sometimes be shimmed for the web build. In either case, the save state implementation is a relatively small investment for a measurable conversion impact.
What most web demo builds get wrong
The most common mistake is treating a web demo as an afterthought, something to generate the week before Next Fest from the existing build. A browser demo built this way tends to have all the problems you'd expect: slow loads, no scope design, no save state, and browser compatibility issues that show up as cryptic error screens for players on certain GPUs.
The demos that perform best are planned 6–10 weeks before the event. That's enough time to properly scope the demo content, do the WebGL optimisation work, build the save state system, test across browser/OS/GPU combinations, and do a soft launch to catch edge cases before the festival traffic hits.
If you're planning for the next Steam Next Fest and want to talk through what a web demo build would look like for your specific title, we're happy to run a free assessment. No commitment, no call required.