Serving a photoreal scene to a launch-day crowd: the 3-second threshold and CDN edge economics

A buyer stands in a Riyadh sales office with your development's link open on her own phone. She has a three-year-old Android and one bar of signal. She is one of the first people through the door on launch morning, and by lunchtime a few thousand more will open the same link from the same weak network. Two things have to hold at once: the page has to come up on her handset in the seconds she is willing to give it, and it has to keep coming up just as fast for everyone who opens it after her.

That is a delivery problem before it is anything else. A photoreal scene is heavy, the crowd is large and simultaneous, and the connections are bad. This post is about how you serve that scene fast to thousands of people at once: the threshold you have to clear, and the edge mechanics that let you clear it for the 1,001st viewer as cheaply as the first.

The number every buyer-facing page has to clear

The threshold is not ours and it is not arbitrary. Google found that 53% of mobile site visits are abandoned if a page takes longer than three seconds to load, and that the average mobile page needs 19 seconds to become usable over a 3G connection (The need for mobile speed, blog.google). That figure is about page loads in general, not 3D tours specifically. It sets the bar every buyer-facing page has to clear, and the gap between three seconds and nineteen is where most mobile pages die.

A photorealistic 3D experience is the single hardest kind of page to bring in under that bar, which is precisely why most of them never do. The failure mode is quiet and expensive: the buyer who waits four seconds does not file a complaint, she just closes the tab, and you never learn that the scene was the thing that lost her. Clear three seconds and the abandonment curve works for you instead of against you.

Serving the scene, not computing it

The reason a heavy scene can clear three seconds on a cheap phone is that the phone never computes it. Each Vinode scene is rendered once, ahead of any visit, and baked into video clips plus a lightweight interactive layer, server-rendered into fast static HTML and served from a global edge network. When the buyer opens the link, her handset is playing back video and responding to taps, which even a low-powered phone does flawlessly. Whether it renders ahead of time or live is a separate argument I make in why pre-rendered 3D beats real-time; here the point is narrower and it is about delivery.

Static bytes on an edge network behave the way the fastest websites behave. The file the buyer needs is already cached at a node near her, so the round trip is short even on one bar of signal, and the payload is a video stream a decade of phones have hardware to decode rather than a scene graph and an engine runtime her GPU has to assemble. The tradeoff you accept for this is that the finished bytes are fixed: the set of views, units, and finishes is baked at render time, not generated on demand. That is the right trade when what you are serving is a known development, and the wrong one when it is an open sandbox, which the last section returns to.

The 1,001st viewer costs what the first did

Most developers scope the launch-day traffic problem as a marketing question and discover the engineering one at the worst possible moment. The reality is that load speed and launch-day concurrency are the same property. What makes a page open fast on one cheap phone is what lets an edge network hand the finished bytes to any number of phones at once. A CDN exists to do exactly this: serve the same static file to a crowd from cache. So serving the 1,001st simultaneous viewer costs essentially what serving the first did. There is no per-viewer render to provision, no session to spin up. The marginal viewer is close to free as an engineering property, and a launch-day traffic spike scales the way an ordinary website scales.

A per-viewer cloud-GPU stream has no such property, because each viewer needs their own live render. To absorb a launch-day spike you pre-warm a fleet of GPUs and pay for the idle ones while you wait for the crowd, or you let latecomers queue for a free instance (Microsoft, Unreal Pixel Streaming at scale). That is a capacity-planning problem. The CDN model does not have it. I keep the billing side of that comparison in pixel streaming versus pre-rendered 3D; for delivery, the point is that CDN-served static video holds up when the whole sales team sends the link on the same morning.

Where the render happens is a different question

There is a whole argument about where a scene should be computed: on the buyer's device via WebGL, on a per-viewer cloud GPU via pixel streaming, or ahead of time. That choice decides fidelity and cost, and it is not this post's argument. Vinode renders ahead of time and serves from the edge; the case for that choice lives in why pre-rendered 3D beats real-time.

I make the distinction because evaluators routinely collapse the two questions, and it costs them. A vendor can render on a beautiful cloud GPU and still deliver slowly if the stream has to reach a phone on one bar of signal in Riyadh, since a live stream cannot be cached ahead of the request the way a finished file can. Rendering quality and delivery speed are set by different parts of the stack. Everything below assumes the scene is already finished bytes and asks only how fast, and how widely, you can hand them out.

Three real projects, each testing delivery

The premise Vinode builds to is massive, complex architectural models loading in under three seconds, directly in the browser, with no app and no download. Where a specific project is measured the figure is tighter, and I would rather name the project than average anything into a round number.

Kozielska Park in Katowice, built for the developer ROHE, opens its full photorealistic 3D world in about a second in the browser. Sub-second delivery on a shipped project is the tightest evidence that the edge model does what the headline promises.

Safa Al Fursan in Riyadh is the weak-signal, any-device test made literal. A 67,000 m² masterplan, 25 buildings, 528 units, navigable from the aerial view down into individual duplex interiors, running on a phone with one-thumb navigation, on a laptop, and on an offline kiosk that flies over the whole site without a dropped frame. Massive payload, ordinary hardware, which is the delivery case that usually breaks.

Abu Dhabi Finance Week 2025 is the crowd test. The venue twin, built in Unreal and streamed as pre-rendered video, loads in about two seconds and served an event of more than 35,000 delegates across four days from a single link, no app, with a QR code handing the experience straight to each person's phone.

Where this delivery model is the wrong choice

Serving finished bytes from the edge wins when the set of things a buyer can see is finite and known: a known roster of units, a handful of finishes, a defined set of viewpoints. For that, the payload can be baked once and cached, and every property above holds.

The flip side is just as real. Baking the scene ahead of time means the delivery has nothing to generate on demand. If the whole point of your experience is free-roam exploration, or a configurator whose combinations run into the millions, or user-generated geometry no one can render in advance, then there is no finished file to cache and this model does not apply — a live GPU per session earns its bill. Vinode's own kiosk is pixel-streaming ready for exactly those cases. We serve pre-rendered video by default because most residential launches sell a finite set of homes rather than an infinite sandbox, so the crowd is opening a known development and the edge can hand it to them fast.

Load it on your own phone, on the worst connection in the building

A "loads instantly for everyone" claim has one honest test, and it is a delivery test. Open a real project on the worst phone you can find, on the weakest signal in the building, and watch the development come up. That is the environment your buyers will actually use, and it is the one a demo on a gaming laptop is built to hide. If it clears three seconds there, it will clear it for the crowd, because the same cached bytes are what every one of them receives.