DEV Community: Oskar Szulc

Game dev techniques that made our Vue web app 20x faster

Oskar Szulc — Thu, 15 Oct 2026 19:41:50 +0000

In short: Five game engine techniques fixed our Vue org chart once customers reached 240k employees: frustum culling (render only what's on screen), spatial partitioning, moving heavy work into Web Workers, level of detail, and hash map lookups. Rendering got 20x faster (a 10k org went from 1 min 45 s to under 5 seconds), and filters went from 9 seconds to 1.5.

Before web dev I made video games for about 5 years. Unity, C#, real-time multiplayer, frame budgets. When I started building org chart visualization software I didn’t think that background would be so relevant in performance optimisation front. Then our customers hit 10k, 30k, 240k employees and I was solving the same problems – just with DOM nodes instead of sprites and entities.

Here are specific techniques from game dev that made the biggest difference.

Don’t process what’s off-screen

Most fundamental optimization in games. If something isn’t visible to the player, skip it entirely. No rendering, no physics, minimal AI. Games call this frustum culling.

Our org chart is an infinite canvas. At any moment maybe 50-100 cards are visible, but the full tree might have 10,000+ nodes.

What we had before: render all 10k nodes, let the browser figure out visibility. 10,000 sets of DOM elements, Vue instances, reactive watchers – all for off-screen nodes.

What I did instead: bare-bones HTML placeholders for nodes outside the viewport. No Vue component mounted, no reactive tracking. When a node enters the viewport during panning, it gets instantiated on the fly. Vue’s async components made this clean.

For 10k nodes: ~100 fully rendered + 9,900 lightweight placeholders.

Before: 10k org → 1 min 45 sec, 5.5 GB

After: same org → under 5 seconds, 1.1 GB

Grid-based spatial partitioning

The viewport culling above has a problem. To decide which nodes are visible you check each one against viewport boundaries. 10k nodes × 60fps = 600k checks per second. Panning felt choppy.

Games solved this with spatial partitioning. Divide the world into a grid, each cell ~500px. To find visible objects, check which grid cells overlap the viewport — much fewer operations — then tell nodes in those cells they might be on screen.

Scales regardless of total node count. Whether 10k or 100k nodes, the number of grid cells overlapping the viewport stays roughly constant. Same thing every RTS does — StarCraft, Age of Empires, all of them.

Frame budgets and the render thread

In games you have 16.67ms per frame at 60fps. Blow that and the game stutters. Web browsers have the same constraint — block the main thread for 200ms and the UI freezes.

Our API sends compressed JSON. For 30k employees, decompression takes ~1.5 seconds on M1 Pro. That’s 1.5 seconds of frozen UI — no spinner, no animations, nothing.

In games the answer is obvious: move heavy work off the main thread. I moved JSON decompression to a Web Worker. Still takes 1.5 seconds, but loading animations play smoothly and the browser never shows “not responding.”

This also unblocked TanStack Query for background refresh — previously even background refetches caused micro-freezes during decompression.

The dictionary lookup pattern

Less “game dev technique” and more “thing anyone doing real-time systems learns the hard way.”

In games, looking up an entity by ID happens millions of times per frame. You never iterate an array to find something.

What we had:

// O(n*m) — 10k updates against 20k array = 200M comparisons
updates.forEach(person => {
  const index = people.findIndex(p => p.personId === person.personId)
  people[index] = person
})

What works:

// O(n+m) — build lookup once
const indexById = {}
people.forEach((person, i) => { indexById[person.personId] = i })

updates.forEach(person => {
  const index = indexById[person.personId]
  if (index !== undefined) people[index] = person
})

I found a production bug where .includes() on an array was called inside a filter loop for 20k employees. Browser ran out of memory. Dictionary lookup fixed it instantly.

The pattern

None of these techniques are new. Any Unity or Unreal developer would recognize them. But they’re rarely discussed in web dev because most apps don’t push the browser hard enough.

The moment your app becomes an infinite canvas — org charts, maps, design tools, data visualizations — you’re building something closer to a game engine than a web app. The constraints are the same: limited frame budget, finite memory, large worlds with smooth interaction.

I’d recommend looking at game dev resources before web performance blogs if you’re in that space. The game dev community has had 30+ years to figure these problems out.

Technique	Web application	Impact
Frustum culling	Viewport-based instantiation	20x render speed
Spatial partitioning	Grid-based intersection	Smooth panning at any scale
Thread offloading	Web Workers	UI never freezes
Level of detail	Simplified zoomed-out components	10x fewer reactive bindings
Hash map lookups	Dictionary-based data access	Filters from 9s to 1.5s

Originally published on oskarszulc.com.

Making a 240k-record org chart load in a browser

Oskar Szulc — Thu, 15 Oct 2026 19:41:22 +0000

In short: Our org chart froze the browser at 10k employees (1 min 45 s to expand, 5.5 GB of memory) and crashed outright at 240k. Over two years I replaced per-node Vue instances with a ~200-line renderer, rendered only what's in the viewport, and moved hierarchy building to the backend. A 10k org now renders in under 5 seconds with 1.1 GB, and a 240k org loads in 0.8 GB.

At Agentnoon we build org chart software for large enterprises. Our customers range from 5,000 to 240,000 employees. This is what I learned scaling the frontend over ~2 years.

Where we started

Mid-2022, I integrated d3-org-chart as the foundation. It handled layout, expand/collapse, zooming. We mounted small Vue instances as custom elements inside each node. It was a necessary workaround step since d3 only supported string templates as the individual elements, so tiny custom html elements were our approach necessary for this implementation.

This worked fine for a few thousand employees. At 20k it got sluggish. At 240k the browser just died.

The problem

For every org chart node we were:

– creating a custom element via document.createElement

– mounting a fresh Vue instance inside it

– setting up reactive dependency tracking

– rendering the component in its own scope, disconnected from the parent app

With 10k visible nodes:

– 1 min 45 sec to expand the full chart

– 5.5 GB memory

– browser frozen

The d3-org-chart library was 2,000+ lines of code we’d heavily patched. Drag & drop libraries couldn’t understand the shadow DOM scope. Every new feature was duct tape on top of duct tape.

Rewrite: 2,000 lines to 200

I was implementing drag & drop for position planning and hit a wall — libraries couldn’t work within d3-org-chart’s shadow DOM. I had three options: ignore it, write a custom implementation, or rewrite the chart as a native Vue component.

I went with option 3. Had a hunch it would be quick for this case — no expand/collapse needed, I knew how to extract d3’s tree layout calculations, and we only needed root + one level of children.

It took 4-5 hours. The result was ~200 lines. A template iterating over data, setting transform attributes on SVG nodes and lines. No custom elements, no shadow DOM, no separate Vue instances.

The key: let d3 calculate the layout, let Vue render the DOM. The old approach used d3 for both, then hacked Vue on top.

// d3 calculates positions
const layout = d3.tree().size([width, height])
const root = layout(d3.hierarchy(data))

// Vue renders
// <g v-for="node in root.descendants()" :transform="`translate(${node.x},${node.y})`">
//   <OrgChartCard :person="node.data" />
// </g>

Metric	d3-org-chart	Native Vue
Time	1 min 45 sec	< 5 seconds
Memory	5.5 GB	1.1 GB
Code	2,000+ lines	~200 lines

Lazy loading custom fields

Next bottleneck: custom fields. User-defined attributes stored in PostgreSQL. For a 30k org with 20 types, that’s 600k rows. We loaded all of them on startup.

What I found:

– most features didn’t need ALL values

– filters only needed unique values per type — one SQL query, sub-second even for 600k rows

– org chart cards only needed values for visible nodes

So I built two backend endpoints (unique values + filtered employees) and used TanStack Query to fetch values per person as they enter the viewport. Cache policy handles the rest.

Metric	Before	After
Directory memory (30k org)	400-500 MB	200-300 MB
Full app path	1,400 MB	900 MB

Don’t load all people

The big one. We were fetching the entire people collection on app load. For 240k employees that meant decompressing and parsing everything before anything could render.

I moved JSON decompression to a Web Worker first (kept the UI responsive but didn’t reduce memory). Then rethought the whole approach:

The frontend doesn’t need all people data. It needs the tree structure and data for visible nodes.

I used d3 hierarchy functions on the backend to build the full tree from {id, parentId} pairs. For 240k employees this takes ~1 second server-side. The backend returns:

– lightweight hierarchy pairs for the entire org

– full records only for requested nodes (batched by what’s on screen)

Frontend renders the tree immediately from hierarchy, shows placeholder cards. As nodes enter the viewport, it batches requests for their data. TanStack Query handles caching and background refresh.

This meant rewriting basically every feature that previously iterated over people. The changelog for this release was the longest I’d ever written.

Metric	Before	After
Memory on load (240k)	1.8 GB	0.8 GB
Filter apply	9 sec	1.5 sec
Filter reset	15 sec	2.5 sec
30k org total memory	1+ GB	< 400 MB

Scenarios migration

The main org chart was fast. But scenario planning still loaded all people upfront.

Migrating scenarios was the hardest part. Every operation had assumptions about in-memory data. Move employee — previously instant (mutate local state), now needs API call + cache invalidation. Remove employee — 4-5 different code paths depending on whether they’re a backfill, have subordinates, etc.

Trickiest bug: cache race condition where moving an employee invalidates people cache, hierarchy endpoint fires immediately, cache is half-rebuilt, returns single employee.

I used TanStack Query cache manipulation for optimistic updates on simple operations, loading states for complex ones.

What I took away

Each phase was the minimum change for the next order of magnitude. Dictionary lookups for 10k. New rendering for 30k. Backend hierarchy for 240k. If I’d built the final architecture in 2022 I would have over-engineered for problems that didn’t exist yet.
The bottleneck was never what I expected. I assumed DOM rendering. It was actually: unnecessary Vue instance creation, array iteration patterns (.includes() inside loops), synchronous JSON decompression, loading data we didn’t need.
Backend compute is cheap, memory is not. Hierarchy building + filtering in Node.js: 1-2 seconds for 240k records. Saved gigabytes of browser memory.
Data-driven scope cutting. I skipped reimplementing directory search — usage data showed 3 uses in a month. Same for column sorting.
Performance improvements compound. Vue rewrite enabled viewport rendering. Viewport rendering enabled on-demand fetching. On-demand fetching enabled TanStack Query caching. By the end, 30k orgs felt like cheating.

Summary

What changed	Before	After
Org chart library	2,000+ lines	~200 lines
10k org render	1:45 / 5.5 GB	5 sec / 1.1 GB
240k org load	browser crash	0.8 GB, usable
Filter operations (240k)	9 sec	1.5 sec
Directory memory (30k)	500 MB	200 MB

At the end of 2023, opening a 30k org in dev would crash the browser in 5 seconds. Six months later I could keep it open all day.

Originally published on oskarszulc.com.