Browser performance: rehearse the worst phrase

Make a musical stress case

An idle CPU meter tells you little about a dense performance. Create a short phrase that combines the instrument’s intended maximum overlap, expressive movement and effect tails. Include the transitions the interface will actually perform: a preset change, recording start, visual update or sample selection where supported. This is the passage the instrument must handle reliably.

Keep the phrase repeatable. Save its MIDI or event sequence when possible and note the manual actions. A test that changes every time is useful for improvisation but less useful for locating a regression. Preserve a simpler reference phrase too, so you can distinguish a general failure from one caused by the demanding passage.

Run the test in the intended browser and device class. A powerful development machine does not establish performance on a phone or older laptop. Record the configuration with the result and avoid converting a single successful run into a universal support claim.

Observe before optimising

Chrome’s Web Audio profiling guidance distinguishes missed rendering deadlines, garbage-collection disruption and device callback timing. The broader lesson is to gather evidence about where time is spent before replacing code at random. Use the current profiling tools available in your browser; older tutorials may describe an interface that has moved.

If the sound glitches, compare the same phrase with expensive graphics disabled. Then compare it with a reduced voice count or simpler effect. Change one condition at a time. A smoother screen does not necessarily mean the audio problem is fixed, and a lower average CPU figure does not prove that short processing peaks have disappeared.

Check whether work is repeated unnecessarily. A waveform display may not need a full redraw for every control message. A meter may not need to send every audio block to the main thread. A sample should not be decoded again merely because a panel was reopened. These are hypotheses to inspect in the implementation, not assumptions about every application.

For custom DSP, reuse working buffers and keep the processing path predictable. Chrome’s AudioWorklet guidance explains why avoiding unnecessary allocation matters under short rendering deadlines. Moving work into a worklet does not make unlimited work affordable; the audio still has to arrive in time.

Design graceful reduction and recovery

Choose what the instrument can reduce while preserving its musical identity. Lowering visual detail may be preferable to cutting voices; in another instrument, a shorter ambience may be less noticeable than a missing note. Make these choices deliberately and expose any automatic quality change clearly enough that it does not masquerade as a different preset.

Test interruptions separately from heavy load. The Page Visibility API reports visibility changes, but hidden-page timer and rendering behaviour depends on browser policy. Do not assume that a background tab will behave exactly like the foreground session. Define what the interface reports when audio is suspended and how the player resumes.

Rehearse stopping recording, downloading a take and starting another session. Confirm that completed work is not lost while the interface prepares the next state. Resource cleanup matters here: old voices, listeners or capture objects should not accumulate invisibly across repeated sessions.

After a change, rerun the same demanding phrase and the simple reference. Keep a brief result with the source revision. Stop optimising when the relevant behaviour is dependable and no unresolved failure remains. The aim is a playable instrument with known limits, not an endlessly polished benchmark that never reaches a musician.