Unity WebGL development is not what most enterprise buyers think it is — and that gap between assumption and delivery is where projects quietly fall apart. We built NBK Virtugate, a gamified onboarding world for the National Bank of Kuwait that runs entirely in-browser with zero installation, and the gap was visible from the first scoping conversation. This post is the honest walkthrough: what the brief asked for, what the constraints actually were, what shipped, and what we would do differently.
If you want the broader context for why WebGL is a distinct discipline with its own ceiling, start with our Unity WebGL service overview. This post goes one level deeper — into a specific project, specific decisions, and specific trade-offs.
The Brief: A Bank That Wanted to Replace PDFs With a World
NBK's onboarding problem was familiar. New employees received dense documentation, sat through instructor-led sessions, and were expected to absorb organisational history, internal tools, and department structure before they'd had a chance to do any actual work. Completion rates were acceptable; retention was not.
The ask was straightforward on the surface: replace the PDF-and-slides stack with something immersive. Employees should be able to explore a virtual bank, discover departments spatially, and encounter onboarding content through interaction rather than passive reading. The experience needed to run in a browser — no headset required, no installation, no IT involvement. Any employee with a link should be able to start immediately.
Two additional requirements shaped everything that followed. First, the experience needed to work across the diversity of corporate hardware — not just on the high-end machines in the executive suite, but on the standard-issue laptops that most employees actually use. Second, it needed to support a dual-mode deployment: browser-first for daily use, with an optional VR mode for deeper immersive sessions in dedicated training spaces.
This is where the "VR but in a browser" assumption becomes dangerous. The client wasn't wrong to want both. But designing for both simultaneously, without understanding the performance constraints that govern each, would have produced a project that underdelivered on both.
The Constraint That Defined Everything: WebGL's Fixed Memory Heap
Before a single piece of geometry was built, we had to establish what the platform could actually hold. Unity WebGL runs inside a browser sandbox with a fixed memory heap — allocated once at load time, not expandable on demand. If the application's runtime memory consumption exceeds the heap, the browser tab crashes. There is no graceful fallback.
For an onboarding world with multiple navigable zones, branded characters, interactive hotspots, and ambient audio, this constraint is not academic. A detailed character model that looks reasonable in a native engine might expand to 50–60 MB of uncompressed memory at runtime. Multiply that across a world with multiple character types and environmental assets, and you're looking at heap exhaustion before the experience even feels complete.
We set the memory budget before any design was locked. The initial heap target was 512 MB — enough to run the engine, load one zone's worth of content, and maintain headroom for runtime allocations. This budget drove every downstream decision: polygon limits per asset, texture resolution ceilings, the number of simultaneously loaded zones, and the architecture of the content delivery system.
The build size constraint compounded this. An empty Unity WebGL build using Universal Render Pipeline starts at approximately 10.7 MB — the bulk of that coming from default assets like the splash screen texture and film grain textures that ship with the template. We stripped those immediately. Custom render settings, disabled unused pipeline features, and a .NET Standard 2.0 compatibility level reduced the code footprint substantially. From that lean baseline, every content asset had to justify its size against the load time target we'd committed to.
The load time target was under 15 seconds on a standard corporate network. Research consistently shows that one-second delays in page load time correlate with measurable drops in satisfaction and engagement — and in a mandatory training context, that friction compounds. An employee who waits 60 seconds for an onboarding experience to load has already formed a negative impression before the first interaction. We treated load time as a user experience metric, not an engineering afterthought.
The Decisions: What We Built and Why
The central architectural decision was AssetBundle streaming. Rather than packaging all zones into a single monolithic .data file that downloads before the experience starts, we split content into zone-specific bundles that load on demand. When an employee enters the Financial Products zone, that zone's assets load; when they leave, those assets unload, freeing heap space for the next zone. The initial download contains only the engine, the core UI, and the entry zone — small enough to meet the load time target.
This decision had a visible consequence: zone transitions required a brief loading moment. We designed that transition deliberately — a contextual animation and audio cue that signals movement between departments, rather than a generic loading spinner. The loading moment became part of the spatial metaphor. It wasn't hidden; it was choreographed.
The visual fidelity decision was equally deliberate. We did not attempt photorealism. Corporate laptop integrated graphics — Intel Iris Xe, AMD Radeon integrated — cannot sustain high frame rates with complex real-time lighting, subsurface scattering, or dynamic shadows across large environments. We used baked lighting throughout: pre-computed lightmaps that capture the visual quality of realistic illumination without the runtime GPU cost. The result is environments that feel warm, branded, and spatially coherent — not photorealistic, but purposeful.
Character assets were built to a 12,000–15,000 polygon budget per avatar, with texture atlasing to reduce draw calls. We targeted under 800 draw calls per frame across the entire visible scene. This is a hard discipline in a world that wants to feel populated — it means every decorative element earns its draw call, and elements that don't serve navigation or learning objectives don't exist.
The interaction system was scoped to match these constraints. Rather than a physics-driven open world where employees can pick up and manipulate any object, NBK Virtugate uses a curated hotspot model: specific, designed interactive moments that trigger content, narrative, or learning checkpoints. Employees walk to a department reception desk and a conversation begins. They approach a historical exhibit and an artifact animates with contextual information. The interactions are clear, responsive, and purposeful — not a simulation of physical reality, but a spatial interface for onboarding content.
Spatial audio carried significant weight in the presence equation. Directional audio cues guide employees toward hotspots. Ambient soundscapes distinguish departments from each other — the quiet focus of a compliance office sounds different from the open energy of a retail banking floor. Audio design is computationally inexpensive relative to visual complexity, and its contribution to subjective presence — the sense of actually being somewhere — is disproportionately large. We leaned into it deliberately.
The dual-mode requirement (browser and VR headset) was resolved by building the core experience once and rendering it through two pipelines. The asset budgets that kept browser performance acceptable also kept VR frame rates manageable. The interaction system, built around hotspots rather than physics, translated cleanly to controller-based VR interaction. This was not an accident — it was a consequence of designing within WebGL's constraints from the start. A design that had pushed to the ceiling of what native VR could achieve would have been impossible to run in a browser.
What Shipped: The Outcome and the Client's Response
NBK Virtugate shipped as a browser-accessible gamified onboarding world where employees navigate a virtual bank, discover departments, and encounter their organisation's history and tools through avatar-driven interaction — all from a browser link, with no installation, no IT ticket, and no device dependency. It also supports optional VR immersion for deeper training sessions.
The client's response: "Excellent work team! A smooth, immersive onboarding experience that brings NBK's history and resources to life."
You can read more about the project at our NBK Virtugate case study.
The platform performs consistently across the target hardware range. Load times meet the 15-second target on standard corporate networks. Frame rates hold at 60 FPS on desktop and 30–45 FPS on lower-end hardware. Memory consumption stays within the allocated heap. Zone transitions are smooth enough that the loading moment reads as intentional rather than as a performance problem.
What didn't ship: the open-world exploration model that appeared in early design discussions. The physics-driven environment where employees could freely manipulate objects. The photorealistic character rendering that appeared in early concept art. These were not failures of ambition — they were the right trade-offs for the platform. An experience that works reliably for every employee on their actual device is more valuable than an experience that looks stunning on a developer's workstation and crashes on a standard-issue laptop.
What We'd Change: The Honest Retrospective on Unity WebGL Development
Three things we'd do differently.
Establish the performance budget in the first client meeting, not the second. We had the constraint conversation early — but not early enough to prevent some design concepts from advancing further than they should have before the fidelity ceiling was clearly communicated. When stakeholders see early concept renders without understanding the WebGL constraint, they anchor on those renders. Walking back visual expectations mid-project is harder than setting them correctly at the outset. The performance budget — heap size, draw call target, load time ceiling, polygon limits — belongs in the proposal document, not the technical specification.
Profile on target hardware from week one. We profiled regularly, but our initial profiling happened on development machines with dedicated GPUs. The first time we profiled on a representative corporate laptop, we found frame rate issues that required design adjustments. Those adjustments were manageable but would have been cheaper to make earlier. Weekly profiling on the lowest-spec device in the target hardware range should be non-negotiable from the first prototype build.
Design the zone transition as a feature earlier. The loading moment between zones was engineered late and choreographed later still. It works well in the shipped product, but it was designed under time pressure. Treating zone transitions as first-class UX moments — with deliberate animation, audio, and contextual framing — should happen in the design phase, not the polish phase.
For a parallel example of how these same constraints played out in an educational context, see our RSA Road Safety case study — a 3D platform adopted into the Irish national school curriculum, where device heterogeneity and bandwidth constraints drove identical design discipline.
3 Lessons You Can Apply to Your Next Unity WebGL Development Project
1. Set the performance budget before design begins. Heap size, draw call ceiling, load time target, polygon limit per asset class — these numbers belong in the brief, not the post-mortem. If your vendor cannot give you these numbers before design starts, they are not ready to scope the project.
2. Design zones, not worlds. Open-world exploration is incompatible with WebGL's memory model at enterprise scale. Bounded, purposeful zones that load on demand are not a compromise — they are the correct architecture. They also produce better learning outcomes because they eliminate navigational ambiguity.
3. Profile on your worst device, weekly. Performance problems discovered late are expensive. Performance problems discovered early are design decisions. Run the build on the lowest-spec device in your target hardware range every week from the first prototype. If frame rate drops, address it before the next sprint adds more assets.
Related Reading
- Unity WebGL Development: Services and Capabilities — the full picture of what we build and how we scope it
- NBK Virtugate Project Case Study — the full project breakdown for the National Bank of Kuwait gamified onboarding platform
- RSA Road Safety Project Case Study — how the same WebGL discipline shipped a 3D platform into the Irish national school curriculum
If you're scoping a browser-based 3D experience and want to understand what's achievable within a real performance budget — before design advances too far — talk to our team at VVS. We'll give you the constraint conversation in the first meeting, not the third.