---
title: "Performance Considerations"
slug: "performance"
updated: 2025-12-19T10:18:46Z
published: 2025-12-19T10:18:46Z
canonical: "support.dise.com/performance"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.dise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.**