Virtual reality (VR) has been around for quite some time, and today it's developed enough to create websites specifically for it. This is made possible by the WebXR technology, which allows for VR applications to run directly in a browser.
Virtual, Yet Real
Before we dive into the testing details in the following articles, let’s first explore the fundamental differences between WebXR sites and traditional 2D websites. A 2D website is a flat object, aptly called a "page." It occupies a small part of our visual field on the screen, so the website creator doesn’t need to think about what lies beyond that page—it’s out of their control. However, a WebXR site is literally a reality that the user immerses themselves in completely. This opens up a world of possibilities, but it also brings new challenges. For instance, if an application takes too long to load or crashes, it’s crucial to consider how to handle this scenario. Staring at a blank screen on a computer is one thing; being lost in a black void is another.
Consider another example: the keyboard. When users immerse themselves in an application, they can’t even use the system keyboard on the headset. Therefore, if your application requires text input, you’ll need to develop your own input methods. We implemented a standard QWERTY keyboard and also added voice recognition to our site—a small neural network running directly in the browser that can recognize English.
VR Sessions
For static or moderately dynamic 2D sites, session management isn’t much of an issue. With web applications, you may be more familiar with background tabs and restoring states after unloading tabs, but very few 2D websites face these challenges. When navigating to a WebXR site, you initially land on a 2D gateway but only enter the application once you start a VR session. Managing this VR session is a whole different ball game. Users can be in a session or out of it, and the session can be active or in the background. Standalone headsets like the Quest series also have various sleep modes, each with its own implications for the application. You need to manage these transitions and ensure that everything works smoothly in different modes, which isn’t always a given.
We faced this problem multiple times. For example, if you access a WebXR site on a standalone headset like the Oculus Quest 1/2/3 and then take off the headset, it will immediately enter a light sleep mode, then transition to deep sleep after a few minutes. After exiting deep sleep, our socket connections would stop working because the backend had closed them, but the frontend wouldn’t open new ones and would wait for messages on the old connections.
Spatial Design
On a 2D site, layout determines where elements are placed on the page. On a VR site, you’re working in a 3D space. When designing your application, you must consider previously unthought-of web questions:
- How far should an element be from the user?
- Should it move with the user or remain static in the "room"?
- If it moves, how do we handle intersections with other elements?
- How will elements appear from different angles? What about from behind?
- What boundaries do we expect users to navigate?
- How do we restrict movement beyond those boundaries?
- What happens if a user does step outside?
In our application, we solved the problem of moving elements intersecting by dividing all panels and windows into several layers. Each layer has its own sphere centered around the user's starting position, with varying radii. Some elements, like panels or keyboards, are movable but can only move within their layer's sphere—changing their distance from the center isn’t allowed. This approach doesn’t resolve intersections within the same layer, but in our case, it’s a corner case we’ve decided to accept for now.
Interaction
In VR, controllers are primarily used for navigation. Unlike a mouse, which has 2-3 buttons, controllers have 8-10 buttons and offer up to 6 degrees of freedom instead of just 3. This creates a wide range of new opportunities and challenges. Additionally, there’s hand tracking, which doesn’t involve any buttons but allows for gestures. Complicating matters further is the lack of a universal solution for handling clicks in 3D space. Each library comes with its own peculiarities, meaning you'll need to develop a button-pressing mechanism as a significant technical feature. Have you ever faced the challenge of implementing mouse click handling on a 2D site, including library selection and configuration?
In earlier Quest headsets, if one controller was active, hand tracking was disabled. However, after an update for the Quest 3, this logic changed, allowing users to hold a controller in one hand and use hand tracking with the other. This led to situations where some settings were hidden in the menu when using hand tracking, prompting us to revise our visibility logic.
Performance
Naturally, there’s a threshold for performance on 2D sites that you need to be mindful of. However, with VR, you’ll hit that threshold much sooner. Several factors contribute to this: your website is essentially a 3D video game. Even if you create a simple landing page, you're already dealing with performance levels that most 2D sites will never reach. But it’s not just a 3D game; it also has to render in stereoscopic images. Add to that a wider field of view than typical games, and consider that modern VR headsets have resolutions comparable to 2K—twice the workload since there are two displays.
In summary, instead of rendering a flat page, you’re rendering a 3D game in 4K resolution with an increased field of view and a constantly moving camera. And you need to do this on standalone headset hardware, which is much closer in performance to smartphones than even budget gaming PCs. The situation is further complicated by the fact that frameworks for WebXR are relatively new and still require optimization in terms of performance.
It’s hard to provide specific insights on this topic, as we monitor performance with every feature and release. For every feature discussion, we ask, “How will this impact performance?”
Last But Not Least. The Issue of Motion Sickness
This problem is closely linked to performance. If the frame rate drops below 90 FPS, it can negatively affect user comfort, and falling below 60 FPS can be disastrous. Modern headsets help mitigate this. Their operating systems run separately from web applications, so even if an app’s FPS drops, the system can maintain 90 FPS, lowering performance demands on the app. However, this only helps with temporary dips. If your app consistently runs at low FPS, users won’t stick around long and are unlikely to return.
Besides performance, the design of the application can also impact motion sickness. For example, if a large part of the user’s visual space starts moving—such as dragging a panel—this can easily lead to discomfort. Navigating in VR using buttons is also tied to this issue.
Our site features an option to capture the entire scene and rotate it using the controller relative to the center. Even after two years of daily VR experience, I start to feel queasy after 30 seconds of using this feature. Thankfully, we designed this function to be used sparingly, usually for much less than 30 seconds, so it doesn’t pose problems for most users.
Conclusion
If you take a closer look at the issues described, you’ll notice that many are typical for 3D video games. This is accurate. As I mentioned, a VR site is essentially a 3D video game running in a browser. However, the challenges associated with traditional websites are still very much present, making it more accurate to say that a VR site is a hybrid of a website and a 3D video game. Therefore, when developing and testing one, you’ll encounter problems characteristic of both.
In future articles, I’ll delve deeper into the specifics of testing WebXR sites in the categories discussed today—those that overlap with 2D sites but have their unique traits—as well as automation for testing VR sites.
Thanks for reading!
