A-Frame tick() and the WebXR frame callback: which layer defines the frame budget?

On an A-Frame 1.x scene, the goal before optimizing is to locate the actual frame bottleneck rather than guess. Two timing sources sit at the integration boundary: the stats component, which times the ECS tick() loop on the CPU, and the WebXR session's frame callback, which delivers an XRFrame timestamp tied to the compositor's schedule.

The two loops are not guaranteed to stay in lockstep. A-Frame drives rendering through the browser's animation loop, while an immersive session schedules frames via XRSession.requestAnimationFrame; implementations differ in how the callbacks interleave, so timing taken around tick() may drift from compositor timing by up to a frame. The stats readout also covers JavaScript execution only; GPU work and compositor overhead stay invisible, which matters for shader-heavy or draw-call-heavy scenes. Behavior varies across desktop Chrome and standalone headset browsers, so version and hardware assumptions should be pinned before comparing numbers.

That leaves an unresolved instrumentation decision:

• Should the frame budget be measured at the tick() level, at the XRFrame callback level, or correlated across both?
• Can drift between the two loops be bounded reliably on the target browsers, or does it need per-session calibration?
• Do GPU-bound stalls surface at either measurement point, or does isolating them require a separate GPU profile?