Performance

Creating a template is similar to making a webpage, but care must be taken to ensure it can perform equally well over time and be predictable in a 24/7 playback situation. This does not necessarily mean that the code has to be hyper-optimized, but there are still some simple "dos and don'ts" to improve performance of templates.

• Keep it minimal. Every script, stylesheet, font, and image adds startup and render cost. Strip out anything not essential for your message.

• Prioritize startup latency. For non-worker type templates, optimize for time-to-first-frame, not long-term throughput.

• Avoid network dependencies. Assume unreliable or slow connectivity - cache assets locally when possible and do not rely on runtime CDN loads.

• Stage vs Play:

  • In onPreload / “off-stage” mode, preload all media and build the DOM quietly.

  • On onShift (play), avoid heavy recalculations or layout shifts. Just start animations or media.

• Provide suggestedNextPreload -return a "suggestedNextPreload" value from onPreload to let the Player know when the best time to preload the next content/message in the Playlist is going to be.

• Defer expensive initialization (like large libraries or analytics) until absolutely necessary.

• Use requestAnimationFrame for timed updates — avoid setInterval or setTimeout loops for visual changes.

• Use native layout features (flexbox, grid) rather than JS positioning.

• Prefer CSS animations/transitions — they’re GPU-accelerated and run outside the main JS thread. Alternately, we suggest using a well proven "tweening" library like GSAP.

• Avoid layout thrashing: batch DOM reads before writes.

• Track your elements - cache references to DOM nodes you reuse - don’t query repeatedly in loops. avoid lookups (e.g. document.getElementById()) all over.

• Limit use of filters, box-shadows, and blurs — they’re expensive on weak GPUs.

• Use muted autoplay + loop for ambient content to avoid user interaction issues.

• Avoid heavy frameworks (React, Angular, Vue) unless required — use vanilla JS or micro-libraries.

• If using a framework, build with tree-shaking and production minification (esbuild, rollup, etc.).

• Avoid polyfills unless strictly necessary — test for real need ('feature' in window) before loading.

• Limit console logging — it can cause noticeable slowdowns on some embedded browsers.

• Use async/await or Promises cleanly — but avoid deep promise chains that hold closures forever.

• Release references to detached DOM nodes to allow GC.

Testing and optimization

• Profile load times with Chrome DevTools “Performance” tab or Lighthouse.

• Simulate slow CPUs / throttled network to expose weak points.

• Watch memory usage — if it grows linearly with time, you have a leak.

• Test on your lowest performing target device first.