A-Frame tick component count and per-frame CPU budget

A-Frame executes every component's tick method once per frame through its centralized ECS loop. The documented behavior does not specify a hard upper bound on concurrent tick handlers, but frame budget depends on handler complexity and target refresh rate.

Goal: determine whether the number of active tick components alone is a reliable signal for capping entity behavior before measuring per-frame cost.

Constraints: Three.js matrix recalculations may occur when tick handlers modify transforms, and VR applications typically require sustained 60–90 fps to avoid discomfort. The relationship between handler count and frame time is not defined in the A-Frame documentation.

• Is there a documented maximum number of tick components per scene before A-Frame's central loop becomes the dominant CPU cost?
• Does A-Frame provide built-in instrumentation to isolate tick execution time from Three.js rendering time?
• Should teams cap active tick handlers by count, or measure per-frame milliseconds first?