How a property tour reaches the browser: static, edge-cached 3D and what a CDN does
Key Takeaways
- A pre-rendered property tour is delivered as finished files, the way a photo or PDF is, so the phone plays a video instead of running a 3D engine.
- When a tour loads slowly for a buyer overseas, the files are simply too far away, and a CDN fixes that by caching copies near each viewer.
- Because a cached file serves the thousandth viewer as cheaply as the first, edge delivery holds steady through a launch-day traffic spike.
- A CDN accelerates repeat visits, so the very first viewer in a new region still waits for a nearby cache to fill.
The interactive tour opens the instant you tap it. On the office monitor, on your own phone, it is there before you finish reaching for coffee. Then a broker in Dubai emails to say it took the better part of a minute, and a prospect on a three-year-old Android says it never really loaded. Same tour, same link, wildly different experience. The reflex is to blame the 3D: too heavy for a weak phone, too much for a distant connection. Usually that reflex is wrong, and the reason is worth twenty minutes of your attention before you sign with any vendor.
Google's own figure for mobile page-load abandonment in general (The need for mobile speed). It is the bar any buyer-facing page has to clear, which is why how a tour is delivered is worth understanding at all.
How a tour actually reaches the browser
There are roughly three ways an interactive 3D scene can get in front of a viewer. It can run as a live program on the visitor's own phone, where the device's chip renders every frame. It can be computed on a server per visit and streamed down as pixels, one live session for each viewer. Or the heavy render can be done once, ahead of time, and the finished result copied out as ordinary files: pre-rendered video clips, images, and a page of HTML. Vinode uses the third one.
That last model is the whole point of this article. Pre-rendering moves the expensive graphics work off the viewing device and before the visit, primarily in Unreal Engine, then bakes it into files. A visit becomes a file fetch, the same shape as loading a photo or a PDF. The phone plays a video; it never runs an engine. That is why an older handset on patchy mobile data can still open the scene.
The tour is not fully static end to end. The presentation layer, the 3D, the images, and the page, is finished files an edge can cache. The thin dynamic parts, a live availability read and a lead-form submission, still travel to an origin server. And because the experience is finished files rather than a live feed, a sales-office kiosk can hold them locally and keep running when the venue wifi drops.
Three ways 3D reaches a viewer
Runs on the device
A real-time engine renders every frame on the visitor's phone, so the result tracks whatever hardware they happen to be holding.
Streamed per visit
A server renders the scene live and sends pixels down, which means one active session, and its cost, for every concurrent viewer.
Finished files (this one)
The render is done once, ahead of time, and served as cacheable video, images, and HTML. A visit is a plain file fetch.
Why it is slow overseas, and what a CDN is for
Go back to the broker in Dubai. If the files that make up the tour physically sit on a server in Frankfurt, every byte has to cross the distance to Dubai and back. That is a distance problem, not a 3D problem. The files just sit too far from the phone in Dubai to arrive quickly.
A content delivery network is the fix for distance. An edge server is simply a copy of your files kept as close to the viewer as possible. In Google's own description, a request arrives at a machine "at the edge of Google's network as close as possible to the user" (Google Cloud, Cloud CDN overview). A CDN is the network of those nearby copies, so the bytes travel a short hop instead of an ocean.
You do not have to take this on faith. Open Kozielska Park, a live ROHE development in Katowice, from wherever you happen to be sitting: the full photorealistic 3D world loads in about a second in the browser, on a phone, with no app. That is static-plus-edge delivery doing its job on a real project you can test yourself.
More viewers barely change the math
Here is the property that makes launch day boring in the best way. When a file is already cached at an edge, serving it to the thousandth viewer is close to the same work as serving it to the first. The edge answers from its copy without going back to the origin, so a spike spreads across the network of caches instead of piling onto one machine. As AWS puts it plainly, a CDN "can handle more web traffic and reduce the load on web servers" (AWS, What is a CDN?).
This is where the per-visit-render model behaves differently. If every viewer needs a live server session, each concurrent visitor is fresh work and fresh cost, which is the argument the pixel-streaming cost study and the launch-day traffic-spike post get into. For static, edge-cached assets there is no such per-viewer bill. The same logic settles a quieter worry, whether adding a tour will drag down your existing marketing site: edge-served assets do not lean on your site's own server, so they do not tax it.
Flat-under-load here is an architectural property of edge-cached files. It is not a measured Vinode number. There is no published concurrency ceiling or cache-hit ratio to quote, and inventing one would be worse than admitting it does not exist.
Why a CDN can still feel slow the first time
A CDN is not one warm copy sitting everywhere at once. Caching is reactive and happens per edge. The first time a file is requested through a given edge, that edge has nothing to hand over, so it fetches from the origin and passes it along. Google calls this a cache miss, as against a cache hit, where the edge already holds the file and "responds directly to the user, shortening the round-trip time" (Google Cloud, Cloud CDN overview). Filling one region's cache does not warm the others; each region heats up on its own first request (Google Cloud, caching overview).
A CDN speeds up the repeat path. The very first visit in a fresh region does not get that lift. The first overseas viewer after a cache expires can still wait, and everyone behind them is fast.
For the evaluator checking whether this can "just be static hosting," the answer is yes, with the boring detail everyone hits. An Amazon S3 static-website endpoint serves over HTTP only, and AWS's own guidance is to put a CDN in front of it for HTTPS and global reach (AWS, hosting a static website on Amazon S3). "Static bucket plus CDN" is the standard, unglamorous pairing, and it is the same family Vinode's "served from a global edge" description sits in.
Push a vendor on the word global. An honest one tells you which parts of the page are fast everywhere and which take a moment to warm up. The rest just repeat the word and hope you never test it.
Test it from where your buyers sit
If you carry one thing into a vendor conversation, carry a method. Open their live demo from the country your buyers actually live in, on the kind of mid-range phone most of them are holding, and judge the repeat visit, because the repeat visit is what your buyers get. And stop filing "will the 3D crash on launch day" under hardware or rendering. For static, edge-cached assets that question is settled, which is exactly what you want the heaviest thing on the page to be.
See it load from where you are
Open a live Vinode project on your own phone, then let's talk about the launch you're planning.
The asset budget is what breaks 3D at 500 units, not your polygon count
Grinding on the model has a hard ceiling at masterplan scale. LOD tiers, a texture memory budget, draw-call limits, and streaming order decide whether a 528-unit scene loads on a buyer's phone. Here is what that budget looks like at 25 buildings, and why no amount of tuning upgrades the device in their hand.
Why pre-rendered 3D beats real-time for real estate sales
Real-time engines look impressive in a demo, but they buckle on the devices your buyers actually use. Here's why Vinode streams pre-rendered 3D instead, and what it means for your conversion rate.
The real cost of streaming 3D per viewer: a worked GPU-and-CDN cost study
Two ways to serve an interactive 3D tour, two cost curves that point in opposite directions. This is the arithmetic worked out at dated public rates: what 100, 1,000 and 10,000 concurrent viewers actually cost on a GPU fleet versus a CDN, and the two numbers that decide where the lines cross.