Babylon.js profiling and delivery
Explains slow startup, uneven frames and growing memory using a repeatable game scene. It targets the measured bottleneck and records which browsers and devices were actually checked.
babylonjs-profiling-delivery
See how it helpsWhen is it useful?
Use when a scene loads slowly, stutters or grows in memory after repeated navigation.
What does it help you do?
- Separates script, GPU, shader compilation and asset decoding costs.
- Changes a specific bottleneck and compares the same warmed-up route.
- Records tested browsers and handles unavailable rendering backends explicitly.
Try asking this
Our browser racer stutters on the first lap and slows after five restarts. Measure asset decoding, shader compilation and retained scene resources separately. Compare the same track after one focused change and document unsupported graphics options without claiming untested phone performance.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Babylon.js — profiling delivery
Use when investigating Babylon startup, frame time, draw calls, memory growth or browser compatibility.
Version and project gate
Inspect package.json and lockfile, Babylon package family and exact version, engine creation, WebGL/WebGPU choice, canvas hosting, loaders, physics plugin version and asset ownership. Keep Babylon Lite and the full engine APIs distinct. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.
Work
Capture a representative scene and actual device. Distinguish JS, GPU, shader compilation and asset decode stalls. Inspect scene/engine instrumentation available in the installed version. Change one bottleneck and compare the same route after warm-up; include context loss and teardown in delivery.
Deliver
A bottleneck record, scoped optimization and browser/build matrix with explicit unmeasured targets. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
Do not replace a measured bottleneck with generic draw-call targets or assume WebGPU is supported everywhere.
Acceptance scenario
Repeat a level transition and a busy gameplay route, then simulate an unavailable rendering backend and verify a visible outcome. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.
Scope and sources
This skill belongs to Ziva. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.
Included files 1
SKILL.md