DEV Community: loggerhead turtle

Keeping Large JSON Smooth: Update Only What Changed

loggerhead turtle — Mon, 21 Sep 2026 23:00:00 +0000

Almost any implementation feels smooth when the JSON is small. The real challenge starts with large data: a real API response may contain deeply nested objects, long arrays, and many repeated structures. At that point, simply panning the canvas, editing one field, or switching between two documents can freeze the page.

While building Treease to work with 50 MB documents, I made a series of optimizations. This article collects the lessons behind them. It focuses on what to compute, read, and update, not on virtualization, or what to draw. For the rendering side, see How I Made a Canvas JSON Viewer Fast with Viewport Virtualization.

Process Only What You Need

A straightforward implementation often looks like this:

Full data → full layout tree → full graph → full Canvas scene

The problem is that once any step works on the full data set, a local interaction can turn into global work. A better model keeps the data, layout, and current view separate:

Full data   →   full layout tree   →   subgraph   →  local Canvas objects
    ↑                    ↑                 ↑
search, edit    incremental updates    pan, zoom, click

The benefit is that offscreen nodes still exist in the data and layout, so search, path navigation, and editing keep their context. More importantly, editing one field does not require recomputing unrelated data.

Two Layout Approaches

Consider this order JSON:

{
  "customer": {
    "name": "Maya",
    "email": "maya@example.com"
  },
  "orders": [
    { "id": "A-100", "total": 42 },
    { "id": "A-101", "total": 18 }
  ]
}

Balanced Layout

Many visualization tools treat nodes as positions that affect one another. They try to avoid overlap, spread nodes apart, and make the whole graph look balanced. The order JSON above might look like this:

                              ┌──▶ name
                ┌▶ [customer]-┤
                │             └──▶ email
[root] ─────────┤
                │             ┌──▶ [A-100]
                └▶ [orders] ─-┤
                              └──▶ [A-101]

This graph is easy to read, but every position is decided in relation to all the others. customer, orders, and the rest all take part in the same calculation of what a more balanced graph should look like. If A-100 gets taller or gains a nested object, the layout has to reconsider every node to produce the next result. That makes this style of layout a poor fit for incremental or streaming updates.

Layered Layout

A layered layout does not decide positions by asking whether the whole graph looks balanced. It derives geometry directly from the JSON structure and reading order:

depth 0          depth 1           depth 2

[root] ────────▶ [customer]
  │                 ├─ name
  │                 └─ email
  │
  └────────────▶ [orders]
                     ├───────────▶ [A-100]
                     └───────────▶ [A-101]

The layout follows these rules:

The root starts in the upper-left corner, and the graph grows to the right and downward.
Nodes at the same depth share the same X coordinate: X equals the rightmost boundary of the parent subtree plus a fixed horizontal gap.
The first node at each depth has a Y coordinate equal to the lowest boundary of the preceding sibling subtree plus a fixed vertical gap.
An edge starts from the matching row in the parent node and ends at the first row of the child node, rather than connecting the geometric centers of two nodes.

With these rules in place, the layout can support incremental and streaming updates, and it becomes easy to calculate the affected subgraph after an edit.

Local Changes Stay Local

Suppose order A-100 gets a new coupon field:

{
  "id": "A-100",
  "coupon": "SUMMER10",
  "total": 42
}

In a layered layout, the result is easy to see. After inserting coupon:

[orders]
  ├─ [0] ─────────▶ [A-100]
  │                    ├─ id
  │                    ├─ coupon  ← new row
  │                    └─ total   ← moves down with its row
  │
  └─ [1] ─────────▶ [A-101]       ← later sibling in the same column moves down

The affected area is clear and local:

coupon added
  → height of A-100
  → Y position of total
  → later sibling nodes at the same depth as A-100

The layout propagates only when the change pushes later content out of the way, and only in the direction where that propagation is necessary.

Store Similar Data Together

Local layout is not enough on its own. Even if an algorithm updates only a few nodes, it can still waste time if finding those nodes means jumping through many scattered objects in memory.

The most intuitive in-memory form for JSON is an object tree:

root object
  ├─ pointer ──▶ customer object
  │                 ├─ pointer ──▶ name string
  │                 └─ pointer ──▶ email string
  │
  └─ pointer ──▶ orders array
                    └─ pointer ──▶ A-100 object

It matches the way people think about JSON. But the machine has to keep following pointers: read one object, jump to an array, jump to another object, then jump to a string. Those objects may live in completely different parts of memory.

An alternative is to group records by type and keep records of the same type next to each other:

Node records: [0][1][2][3][4][5][6][7]...
Edge records: [0][1][2][3][4][5][6][7]...

Both forms are O(N) when traversing N nodes, but locality can make their real-world costs very different:

Object tree: read a node, jump elsewhere for a child, then jump again for a string.
- More pointer chasing, more cache-miss risk, and less opportunity for hardware prefetching.
Contiguous records: read adjacent nodes, edges, and rows in sequence.
- A cache load is more likely to include data needed next, and the hardware can prefetch more effectively.

In practice, paths can be stored as compact parent-linked records instead of repeatedly copying full strings. Nodes and edges can be linked by numeric IDs. A table change can be located precisely by table ID and row number. Each update only needs to keep track of the nodes and rows it actually touched.

Query Only What Is in View

Virtualization prevents offscreen content from becoming Canvas objects, but it does not solve another common trap: drawing only a few dozen elements after first scanning hundreds of thousands of them.

The answer is a spatial grid. Split the canvas into cells and build a spatial index for the laid-out nodes and edges. When the user pans or zooms:

Expand the viewport by a small buffer.
Query the grid cells covered by that area.
Collect nearby node and edge candidates.
Run an exact intersection check.
Update the current Canvas scene.

The core idea is simple: narrow the candidate set before doing expensive work.

Keep State in Its Own Scope

Locality is not only about space. It is also about the scope of state.

Imagine scrolling to item 4,000 in a navigation list with 10,000 children. The wrong approach is to read every item, create every UI element, and update the whole column:

scroll
  → read 10,000 items
  → create 10,000 list items
  → update the whole column

A better approach binds the data, rendering, and state to the current window of the current path:

scroll near item 4,000
  → request items 3,980 through 4,020
  → update only that window

The same is true when switching between documents. Each document should own its own editing state, graph state, and background tasks:

Document A: A's editing state, graph state, background tasks
Document B: B's editing state, graph state, background tasks

When switching to B, activate the state B already has. Do not reread the full document from global state, parse it again, and recreate the graph.

Every data read, asynchronous task, and UI update should know which document, path, and window it belongs to. The key is to define the smallest useful scope and keep state inside it.

Performance Comes from Locality

The goal is not to invent an algorithm that can somehow hold an enormous JSON document. It is to give every user action a small, clear working set:

User action	Data to process
Edit one field	That field, its card, and the later layout it affects
Pan the canvas	Nodes, rows, and edges near the viewport
Scroll navigation	The visible window for the current path
Find a field	The target and a small amount of context
Switch documents	The saved state that belongs to the target document

The key is not processing data faster. It is knowing exactly which data needs work right now.

How I Made a Canvas JSON Viewer Fast with Viewport Virtualization

loggerhead turtle — Mon, 24 Aug 2026 21:50:21 +0000

When you build a visual tool for structured data, everything feels instantaneous on toy examples. A 20-line JSON payload renders crisply into an interactive graph with clean nodes, collapsible trees, and smooth connectors.

Then you drop in a real-world file: a 15 MB API response containing nested objects, deep arrays, and hundreds of thousands of key-value pairs.

Suddenly, the browser locks up. The DOM or Canvas scene graph explodes with tens of thousands of objects. Panning drops from 60 fps to single digits, and zooming triggers multi-second layout thrashing.

Here is how I tackled this problem when building the graph visualizer for Treease by separating semantic completeness from visual materialization.

The Core Dilemma: Completeness vs. Canvas Weight

The naive mental model for a canvas or SVG graph is 1:1 mapping: for every node in the data, instantiate a renderable object in the scene.

[Full JSON AST]  ->  [Canvas Scene Graph / DOM Nodes]

This model breaks down quickly because:

Scene Graph Bloat: The cost of hit-testing, layout calculations, and paint passes scales linearly with document size, even when most content is offscreen.
Memory Overhead: Holding thousands of active visual display objects consumes hundreds of megabytes of RAM.

The intuitive workaround is aggressive lazy loading, for example parsing only what is expanded. But that breaks critical user workflows:

How do you search across the entire document?
How do you jump to a deeply nested path?
How do you show global error indicators or relationship highlights?

The Architectural Shift

The solution was to decouple the data model from the render surface:

[ Full Semantic Graph (In-Memory / Fast Lookups) ]
                      |
                      v Viewport Frustum Culling
[ Materialized Scene (Only Visible Nodes + Overscan) ]

Semantic Completeness: Keep the entire document parsed, indexed, and queryable in memory. Global search, tree navigation, and path queries run against the lightweight in-memory structure.
Visual Materialization: Only instantiate canvas render objects for elements currently within, or adjacent to, the camera viewport.

Let's look at the four specific techniques that made this work.

1. Viewport Virtualization with Bounded Overscan

The foundation is simple bounding-box intersection, but with an important detail: directional overscan.

If you only materialize elements strictly within the viewport, fast panning will cause visible flashing as objects pop into existence.

interface ViewportRect {
  minX: number;
  minY: number;
  maxX: number;
  maxY: number;
}

function calculateOverscanBounds(
  viewport: ViewportRect,
  overscanFactor = 0.5
): ViewportRect {
  const width = viewport.maxX - viewport.minX;
  const height = viewport.maxY - viewport.minY;
  const padX = width * overscanFactor;
  const padY = height * overscanFactor;

  return {
    minX: viewport.minX - padX,
    minY: viewport.minY - padY,
    maxX: viewport.maxX + padX,
    maxY: viewport.maxY + padY,
  };
}

The Rendering Pipeline

On each camera transform:

Compute the visible world-coordinate rectangle from the camera matrix.
Expand it by the overscan margin.
Query a lightweight spatial index to find intersecting nodes.
Diff and reconcile: retain already materialized objects, create new ones entering the bounds, and unmount or recycle objects that left the bounds.

function updateVisibleScene(camera: Camera, spatialIndex: SpatialIndex) {
  const visibleBounds = calculateOverscanBounds(camera.getWorldBounds());
  const visibleNodes = spatialIndex.search(visibleBounds);

  reconcileSceneGraph(visibleNodes);
}

2. Sampling Dense Edge Groups

Nodes are only half the battle. In graph layouts, a single parent array or hub object might have hundreds or thousands of outgoing edges.

Drawing thousands of overlapping curves inside a small visible region creates two problems:

Performance: Computing and rasterizing large numbers of vector paths tanks fill rate.
Visual Usability: Individual lines become an undifferentiated blob.

Without Sampling:  [Node A] ==========> [2000 Children]
With Sampling:     [Node A] - - - - -> [Representative Paths]

Dynamic Stride Sampling

When the number of outgoing edges exceeds a density threshold, we switch to stride-based sampling:

function getMaterializedEdges(node: GraphNode, maxEdgeSampleCap = 32): Edge[] {
  const allEdges = node.outgoingEdges;
  const total = allEdges.length;

  if (total <= maxEdgeSampleCap) {
    return allEdges;
  }

  const stride = Math.ceil(total / maxEdgeSampleCap);
  const sampled: Edge[] = [];

  for (let i = 0; i < total; i += stride) {
    sampled.push(allEdges[i]);
  }

  return sampled;
}

3. Row-Level Virtualization Inside Large Objects

A common JSON edge case is a single flat object with thousands of keys:

{
  "metric_0001": 42,
  "metric_0002": 88
}

Even if the object node intersects the viewport, drawing every key-value row would waste hundreds of draw calls.

Instead of treating a node as an indivisible box, we treat large nodes as vertically virtualized sub-containers:

┌──────────────────────────────┐
│ (offscreen rows not drawn)   │
├──────────────────────────────┤
│ "metric_0412": 104           │
│ "metric_0413": 89            │
│ "metric_0414": 92            │
├──────────────────────────────┤
│ (offscreen rows not drawn)   │
└──────────────────────────────┘

Implementation Concept

If each row has a predictable or pre-computable height, we can determine the visible slice in constant time:

function getVisiblePropertyRange(
  nodeTop: number,
  rowHeight: number,
  totalRows: number,
  viewport: ViewportRect
) {
  const relativeTop = Math.max(0, viewport.minY - nodeTop);
  const relativeBottom = Math.max(0, viewport.maxY - nodeTop);

  const startIdx = Math.max(0, Math.floor(relativeTop / rowHeight) - 2);
  const endIdx = Math.min(totalRows - 1, Math.ceil(relativeBottom / rowHeight) + 2);

  return { startIdx, endIdx };
}

The node container keeps its true total height in layout, but only renders the visible slice.

4. Virtualized Scrolling for Table Nodes

When JSON arrays contain uniform objects, a tabular representation is often more readable than a deeply nested tree:

[
  { "id": 1, "name": "Alice", "status": "active" },
  { "id": 2, "name": "Bob", "status": "pending" }
]

Table nodes in a 2D canvas graph combine two coordinate systems:

World canvas coordinates for graph panning.
Local scroll coordinates for scrolling inside the table itself.

By attaching a virtualized row pool to the table node, we reuse a fixed number of cell renderers regardless of whether the array has 10 items or 100,000 items.

Takeaway

Rendering performance is not about how fast you can draw 50,000 elements. It is about finding clean abstractions so you only ever have to draw 50.

If you are dealing with large graphs, trees, or structured documents on the web, keep asking:

Does this offscreen element need a visual representation right now?
Can the data model answer queries without touching the render tree?