How do you architect a high-performance WebAR/WebVR app?

Long Answer

A production-grade WebAR/WebVR application must protect frame time above all else. Smoothness is not a by-product; it is an explicit budget every system respects. The architecture organizes around four loops: render, simulation, I/O, and streaming. Each is isolated, paced, and observable so devices from mid-tier phones to desktop headsets sustain comfort.

1) Capability profiles
Probe WebXR, WebGL 2 vs WebGPU, texture formats (ASTC, ETC2, Basis), max texture size, and hardware concurrency. Map to profiles (low/med/high) that gate effects, resolution scale, and physics step rate. Store a runtime config that components read.

2) Asset pipeline and budgets
Set per-profile budgets: triangles, draw calls, materials, texture MB, shader cost. Enforce in CI with meshopt/Draco and KTX2 (UASTC/ETC1S). Use LODs and impostors; stream prioritized content (visible > likely > decorative). Prefer single-pass PBR, atlas decals, and merge meshes sharing materials to cut state changes.

3) Engine, rendering, pacing
Use WebXR for pose and lifecycle. Prefer WebGPU when available; otherwise optimize WebGL 2 with instancing and UBOs. Apply dynamic resolution. Order frames: input → sim → cull → draw. Target 16.6 ms at 60 FPS; if over budget, drop effect tiers before framerate. Use GPU timers to trigger quality scaling.

4) Physics and interactions
Run physics in a Web Worker with a fixed timestep and render-time interpolation. Keep colliders simple and separate from visuals. Model interactions with state machines; debounce high-rate events. For AR anchors/occlusion, cache surfaces and update at a capped rate.

5) Networking and sync
For multiuser, use an authoritative server and late-join snapshots. Send compressed deltas at 10–20 Hz; clients interpolate and reconcile. Use WebRTC DataChannel or WebSocket; keep network I/O in a worker and pass immutable frames to the main thread.

6) Memory and streaming
Pre-allocate pools for transient math objects. Reuse buffers/textures; keep an LRU streaming cache. Decode images off-thread. When memory pressure rises, downshift texture resolution and drop distant LODs first. Instrument lifecycles and surface counters in an in-app HUD.

7) Tooling and observability
Add perf-budget tests in CI. Ship an overlay that graphs CPU, GPU, draw calls, and texture MB; auto attach traces on dropped frames. Aggregate P50/P95 frame time and device stats to dashboards so regressions are visible per release.

8) Accessibility and UX
Provide comfort settings (locomotion, vignette, snap-turn, handedness). Respect reduced-motion. Offer 3D fallback when XR is off. Use world-locked UI with large targets.

9) Progressive enhancement
Design scenes to scale: fewer dynamic lights and simpler shaders on low-end; reflections and higher shadow cascades on high-end. Maintain one codepath with data-driven toggles.

Together these choices balance 3D assets, physics, and real-time interactions within strict budgets, keeping WebAR/WebVR experiences smooth on mobiles and impressive on powerful devices without code forks.

‍

Table

‍

Common Mistakes

Treating WebAR/WebVR like a desktop game and blowing the frame budget with high-poly meshes, many materials, and unbatched draw calls. Running physics on the main thread, then blaming input lag and stutter on devices. Shipping PNG/JPEG textures without GPU compression (KTX2), causing memory spikes and slow uploads. Hard-coding effects instead of profiling and scaling by capability. Trusting raw network positions at 60 Hz with no interpolation or reconciliation, creating rubber-banding. Allocating new vectors/arrays each frame and letting GC hitch the render loop. Streaming every asset at once instead of prioritized queues. Skipping GPU timers and real telemetry, so regressions ship unnoticed. Ignoring comfort settings and reduced-motion flags, increasing sickness for users. No 3D fallback when WebXR is unavailable, yielding a blank page. No LOD on crowds or particles. Using verbose JSON for state instead of compact binary. CI accepts oversized assets because budgets are not enforced.

‍

Sample Answers (Junior / Mid / Senior)

Junior:
“I would use WebXR with a Three.js renderer, aim for 60 FPS, and keep assets small. I would compress textures with KTX2, use LODs, and merge meshes to reduce draw calls. Physics would run in a Web Worker with a fixed timestep, and I would add interpolation to keep motion smooth. I would also provide comfort options like snap-turn and a vignette.”

Mid:
“I start with capability profiles to choose quality tiers and resolution scale. I enforce budgets in CI for triangles, materials, and texture MB. Rendering uses instancing and UBOs; physics and networking run in workers. For multiuser, I send deltas at 15 Hz, interpolate locally, and reconcile on corrections. I ship an in-app HUD to watch CPU, GPU, draw calls, and P95 frame time.”

Senior:
“Architecture separates hot loops and isolates the main thread. WebGPU is preferred when available; otherwise WebGL 2 is tuned with culling and batching. Streaming is prioritized; memory pools avoid GC churn. Auto quality scalers react to GPU timers. Telemetry flows to dashboards so regressions are caught within hours, not releases.”

‍

Evaluation Criteria

Look for an answer that treats frame time as a budget and structures systems around it. Strong candidates define capability profiles, budgets, and CI gates for assets and shaders. Run physics/networking off the main thread, use fixed timesteps with interpolation, and compress textures. Include dynamic resolution and quality tiers, plus authoritative networking with deltas and reconciliation. Observability: in-app HUD, GPU timers, and dashboards for P50/P95 by device. Accessibility is present: comfort settings, reduced-motion, and fallbacks when XR is unavailable. Progressive enhancement with one codepath, explicit targets like CPU ≤6 ms and GPU ≤8 ms. Mention LRU streaming caches, object pools, asset preflight tests, and late-join snapshots to show operational maturity. Answers must link choices to user comfort and business goals such as mid-tier coverage and predictable releases.

‍

Preparation Tips

Spin up a minimal WebXR scene with a cube and controller input. Add an in-app HUD showing CPU, GPU, draw calls, and frame time. Implement capability detection (WebGPU/WebGL 2, texture formats, cores) and derive three profiles. Create CI checks that reject meshes over triangle limits and textures without KTX2. Integrate a physics library in a Worker with a fixed timestep and render-time interpolation. Add a streaming loader: prioritized queues, LRU cache, and off-thread decode. Prototype multiuser: authoritative server, 15 Hz deltas, client interpolation, and late-join snapshots. Wire GPU timers and quality scalers to drop effects when over budget. Build comfort settings (vignette, snap-turn, handedness) and a 3D fallback for non-XR. Finally, load-test on three devices (low, mid, high), record P50/P95, and document thresholds for go/no-go. Snapshot perf each commit to a dashboard. Automate asset preflight locally and in CI for early artist feedback. Practice a one-minute narrative on budgets, profiles, and scalers. Run a weekly perf triage to review regressions and update budgets.

‍

Real-world Context

A retail AR try-on cut P95 frame time from 28 ms to 17 ms by moving physics to a Worker, enforcing KTX2 textures, and enabling dynamic resolution on low-end Android. A WebVR tour halved draw calls by merging meshes and atlas-ing decals; adding LODs dropped GPU time enough to reintroduce soft shadows on desktop. A multiplayer AR sandbox stabilized interactions after adopting an authoritative server: 15 Hz deltas, client interpolation, and late-join snapshots; rubber-banding vanished. A training sim fixed stutter by pooling math objects, decoding images off-thread, and downshifting LODs under memory pressure. In each case, a frame-time budget, CI asset gates, and in-app telemetry turned ‘optimize later’ into a routine discipline that scaled across devices. A team added capability probes and quality tiers; low-tier phones ran at 30 FPS with reduced effects, while headsets hit 72 FPS from one codepath. A live events app used streaming and an LRU cache to prioritize visible props; scene loads fell under 2 s on mid-tier devices without pops, boosting retention.

‍

Key Takeaways

• Treat frame time as a hard budget; scale fidelity, not framerate.
  
• Encode capability profiles and enforce per-profile asset budgets in CI.
  
• Offload physics/networking to workers; interpolate and reconcile.
  
• Compress textures (KTX2), use LODs, merge meshes, and limit materials.
  
• Ship observability (HUD, GPU timers, P50/P95 dashboards) and comfort options.
  
  

Practice Exercise

Scenario:
You are building a cross-device WebAR/WebVR demo that must hold 60 FPS on modern phones and 72 FPS on headsets. Scenes include interactive physics props and a small multiuser area. You have two weeks to reach a stable beta.

Tasks:

1. Define capability detection and three profiles (low/med/high). For each, set budgets: triangles, draw calls, texture MB, shader cost, and physics step.
   
2. Build an asset pipeline: meshopt/Draco, KTX2 textures (UASTC/ETC1S), LOD ladders, material atlas. Add CI checks that fail on budget violations.
   
3. Implement a render loop with dynamic resolution and a quality scaler triggered by GPU timers. Show an in-app HUD (CPU, GPU, draw calls, frame time).
   
4. Move physics to a Worker with a fixed timestep and render-time interpolation. Use primitive colliders; cap AR surface/anchor updates.
   
5. Prototype multiuser: authoritative server, 15 Hz deltas, client interpolation, reconciliation, and late-join snapshots.
   
6. Add memory controls: object pools, an LRU streaming cache, off-thread decode, and a downshift policy under pressure.
   
7. Ship comfort options (vignette, snap-turn, handedness) and a 3D fallback when XR is unavailable.
   
   

Deliverable:
A one-page runbook with budgets, profiles, and rollback rules; screenshots of the HUD under load on three devices; and telemetry charts showing P50/P95 before and after optimization. Include a short postmortem listing the top three regressions discovered, the fixes applied, and any budget updates. Document how the quality scaler chooses which effects to disable first and how to override it for demos.