Performance

Lumora runs in three places during a show, and each has a different performance profile:

• The operator control panel, where you cue, preview, and take graphics.
• The Controller App, an optional desktop version of that same control panel.
• Your output renderers, the browser sources your broadcast software captures.

Your preview and your program output are separate. If a graphic stutters or looks wrong in the control panel, that does not mean it will stutter or look wrong on air. The reverse is also true, and the causes are usually different.

Browser extensions

This is the biggest cause of a preview that doesn't match what goes to air.

When you run the control panel in a normal browser tab, every extension you have installed also runs inside Lumora, including inside each graphic preview frame. Extensions can read and change the contents of those frames. That means a preview can show you something different from what actually goes to air, and no amount of care on your side will reveal it.

Extensions also cost time. In our own measurements, taking a graphic on and then off air with extensions disabled produced no long tasks at all. With an ordinary extension set installed, the same interaction produced three, and the browser's main thread was busy for roughly 350 ms at each take instead of roughly 40 ms.

The cost is not spread evenly, and it is not where most people expect:

Extension	Main-thread time
Password manager	~730 ms
Writing assistant	~35 ms
Ad blocker	~5 ms

Ad blockers are not the problem. The expensive extensions are the ones that inject into every frame looking for form fields, password managers above all. Lumora creates a fresh frame for each graphic you take, so that extension's code is compiled and evaluated again on every take, not once when you open the page.

Lumora does not detect which extensions you have installed, and won't. Enumerating them is a fingerprinting technique, and as the table shows, knowing an extension is installed tells you very little about whether it costs you anything.

Limiting extensions to the sites that need them

You rarely need to disable an extension everywhere. You just need to stop it running on Lumora. Every major browser can do this per site:

• Chrome and Edge: right-click the extension's toolbar icon, and under This can read and change site data, choose When you click the extension.
• Firefox: open Add-ons and themes, select the extension, open Permissions, and turn off its access for this site.
• Safari: open Settings → Extensions, select the extension, and set this website's permission to Ask or Deny.

The extension keeps working normally everywhere else. Start with password managers and anything that injects its own UI into pages; ad blockers are almost never worth touching.

The Controller App

The Controller App is a desktop version of the operator control panel. It loads the same interface, so the layout, hotkeys, and behaviour are identical to a browser tab, but it has no extension system, so nothing can inject into your preview frames. It is the one environment where the preview is guaranteed to be showing you Lumora and nothing else.

It is not faster in any other respect. It is the same application, and it applies no special graphics tuning of its own. Once you've limited your extensions on the Lumora site as described above, a browser tab and the Controller App perform the same.

The Controller App is included on some subscription tiers. See Subscription plans for which.

Output renderers

Your outputs are what your broadcast software captures, and they are what actually goes to air.

Output renderers do not run browser extensions. OBS, vMix, and similar tools load the output page in an embedded browser with no extension system at all. Nothing in the sections above affects your program output. Extensions can affect the preview but not what goes to air.

Each time you take a graphic on air, Lumora creates a new frame for it, loads the template, and runs it. There is no pre-loading and no reuse between takes, which means a template's start-up cost is paid on every take rather than once per show. If takes feel slow on air, the template's own loading and start-up work is the first place to look, not the renderer.

Two things are worth checking on the renderer itself:

• Renderer version. Some templates require a newer embedded browser than the one your broadcast software ships with. When that happens, Lumora shows a compatibility warning in the Status Panel and in the Identify Outputs overlay. The warning does not block the graphic from going on air. It tells you the template may not render as its author intended. Updating your broadcast software usually resolves it.
• What each output is doing. Every output is a live page rendering in real time. If you're running several, they each cost their renderer machine something. See Outputs for how outputs work and how many your plan allows.

When the graphic itself is the cost

If one particular template is slow and others are fine, the cost is usually inside that template rather than in Lumora. The common causes are large media that must be downloaded and decoded before anything can appear, and start-up work the template does before it signals that it's ready.

If you built the template yourself, or you can reach whoever did, that's the place to look first. If a template is slow in preview but fine on air (or the other way round), re-read the sections above before touching the template; that pattern usually points at the environment, not the graphic.