Home/Recipes/Dashboard Rendering

Dashboard Rendering & Layout Thrashing

Architectural strategies for rendering complex dashboards containing multiple charts, widgets, and data grids without causing layout thrashing or stuttering animations.

Advanced
1-3 days
Impact: High
Related
Browser APIs:request-animation-frame
Recipes:large-data-table
Experiments:rendering

The Problem

Dashboards pack high-density information (charts, grids, stats) into a single view. When multiple widgets render, fetch data, and resize simultaneously, they frequently read from and write to the DOM concurrently. This triggers severe layout thrashing and jank.

Common Symptoms

  • Resizing the browser window causes extreme stuttering and freezing.
  • Initial load sequence looks "glitchy" as widgets jump around during rendering.
  • Animations (like sidebar toggles) drop frames heavily when charts are present.

Root Causes

  • Widgets individually measuring their own DOM containers (e.g. `offsetWidth`) immediately followed by another widget updating its `style.width`.
  • Canvas/SVG charting libraries forcing synchronous recalculations.
  • Uncontrolled render cascades where one widget loading triggers layout shifts in others.

Typical Expected Improvements

DOM Nodes
↓ 95%
Memory
↓ 80%
FPS
↑ 3–5×
Initial Render
↓ 70%

Decision Matrix

Architectural decision guidance for different scenarios.

Scenario: Widgets need to redraw/recalculate when the browser resizes.

✅ Recommended:ResizeObserver + requestAnimationFrame Debouncing
🔄 Alternatives:window.addEventListener("resize")

⚖️ Trade-offs: Requires careful cleanup of observers when widgets unmount.

💡 Why: Listening to `window.resize` fires synchronously. `ResizeObserver` specifically tracks the element and groups measurements, and `requestAnimationFrame` ensures the redraw is synchronized with the display.

Scenario: A dashboard contains 20+ heavy charts, but only 4 are visible on screen.

✅ Recommended:IntersectionObserver Lazy Loading
🔄 Alternatives:Load all concurrently

⚖️ Trade-offs: Scrolling fast might show a blank space briefly before the chart initializes.

💡 Why: Initializing 20 canvas charts blocks the main thread completely. Only rendering what is in the viewport keeps the initial load instant.

When NOT To Use
  • If the dashboard consists of strictly static content or text-only cards.
  • If the layout uses fixed CSS grid sizes where widgets never resize dynamically.

Approaches

Do This

  • Batch DOM reads and writes centrally (e.g., using `fastdom`).
  • Use `ResizeObserver` for widget resizing, not `window.resize`.
  • Lazy-load offscreen widgets using `IntersectionObserver`.
  • Reserve layout space using CSS `aspect-ratio` or fixed height placeholders to prevent Cumulative Layout Shift (CLS).

Anti-patterns

  • Interleaving DOM reads (`clientHeight`) and writes (`style.height`) in a `forEach` loop across widgets.
  • Relying purely on JavaScript for grid layout calculations (use CSS Grid instead).
  • Animating layout properties like `width` or `margin` (animate `transform` instead).

Implementation

import { useVirtualList } from '@vueuse/core'

const { list, containerProps, wrapperProps } = useVirtualList(
  hugeDataArray,
  {
    itemHeight: 48
  }
)

Use AI

Instantly analyze your codebase using this recipe via MCP. Open your AI agent and run this prompt.

Review my Vue table for virtualization opportunitiesCopy Prompt

Related Knowledge