A VR experience that opens from a URL sounds like a shortcut around the app stores. It is, but the frame budget is brutal and most of the work is spent earning back milliseconds. Here is the real arithmetic.
Every few months a client asks whether their showroom, factory or unbuilt apartment could be walked through in VR, and whether it has to be an app. It does not. The WebXR Device API has been shipping in browsers since 2019 and is supported today in the Meta Quest browser, on Apple Vision Pro through Safari, in Chrome on Android, and on desktop Chrome and Edge with a tethered headset. One URL, no store review, no install, no 400MB download before anyone sees anything.
That is the entire pitch, and it is a good one. What nobody mentions is the frame budget, which is where the actual engineering lives.
Start with the arithmetic. A flat website that renders in 200ms feels instant. A VR headset running at 90Hz gives you 11.1 milliseconds to produce a frame, and you produce it twice, once per eye. Quest 3 will happily run at 120Hz, which is 8.3ms. Miss the deadline and the compositor reprojects the last frame; miss it repeatedly and the user feels it in their inner ear rather than seeing it on screen. There is no equivalent on the 2D web. A janky website is annoying. A janky VR experience makes people take the headset off and not put it back on.
The second thing to internalise is that a standalone headset is a mobile device. Quest 3 runs a Snapdragon XR2 Gen 2, which is a phone chip with a phone thermal envelope. Every instinct from desktop WebGL is wrong here. The practical ceiling on a standalone headset is in the low hundreds of draw calls per frame, not thousands, and the fastest way to blow through it is a scene exported straight from a design tool where every screw is its own mesh with its own material.
So most of the work on a WebXR project is not the VR part. It is asset discipline. Merge meshes that share a material. Instance anything that repeats, which in an architectural walkthrough means the windows, chairs, railings and light fittings. Bake lighting into lightmaps rather than computing it in real time, because a single real-time shadow-casting light can cost more than the rest of the scene. Keep the texture budget in mind: a headset has a couple of gigabytes of usable memory, and 4K textures on objects the user will never stand closer than three metres to are pure waste.
Compress properly. glTF with Draco for geometry and KTX2 with Basis Universal for textures is the current sensible default. KTX2 matters more than people expect, because it stays compressed on the GPU rather than being decoded to raw RGBA in memory the way a PNG or JPEG is. On a large scene that difference is the whole memory budget.
Then there is comfort, which is a design constraint disguised as a technical one. Two rules cover most of it. Never move the camera without the user asking, because the mismatch between what their eyes report and what their inner ear reports is exactly what makes people ill. And offer teleport locomotion as the default rather than smooth stick movement, with a vignette that narrows the field of view during motion for anyone who chooses smooth. Both are cheap to implement and both are the difference between a demo people finish and one they abandon.
The bit that surprises clients most is that the same codebase should also run well in an ordinary browser tab on an ordinary laptop, because that is where almost all the traffic will actually come from. Very few of your customers own a headset. The headset is the impressive version; the desktop and phone version is the one that gets used. Build for the tab first and treat the immersive session as an upgrade the same page offers when the hardware is present, which is precisely what the navigator.xr.isSessionSupported check is for.
None of this is exotic. It is Three.js or Babylon, glTF, a build pipeline that compresses assets properly, and a lot of measuring. But it is genuinely different work from building a website, and it is why almost nobody in the Indian market offers it on open web standards rather than as a Unity build behind an app store.
If you want to see the argument rather than read it, our own showcase runs in a browser tab and opens in a headset from the same link. We built it to demonstrate the two services it describes, on the grounds that a practice claiming it can do this should be able to point at something rather than at a slide.