Pretext vs DOM Layout: Real-World Performance Benchmarks

Performance claims in JavaScript are easy to make and hard to trust. "300x faster" sounds like marketing copy — so let's look at what's actually happening, why DOM text measurement is slow, and what the real numbers look like when you compare Pretext to the traditional approach.

How DOM Text Measurement Actually Works

When you use browser APIs to measure text — element.offsetWidth, getBoundingClientRect(), getComputedStyle() — you're triggering the browser's layout engine. This isn't a lightweight operation. The browser has to:

1. Apply all CSS cascading rules to the element and its ancestors
2. Calculate the box model (margins, padding, borders)
3. Run the text shaping pipeline (font selection, kerning, ligatures)
4. Compute the final pixel dimensions of every affected element
5. Return your measurement

Step 4 is the killer: this is a layout reflow, and it invalidates the browser's cached layout tree. Do it 100 times in a loop, and you've triggered 100 full reflows — even if you're only measuring simple <span> elements.

The Batching Trap

Experienced developers know to batch DOM reads and writes to minimize reflows. But for dynamic text layout — where container sizes change on resize, font sizes respond to content, or text wraps around moving objects — batching is often impossible. You need the measurement before you can compute the next position.

This is the wall that text-heavy UIs hit. No amount of batching helps when the layout problem itself is inherently sequential.

How Pretext Measures Text

Pretext bypasses the DOM layout engine entirely. Here's the actual pipeline:

prepare() phase (run once per text string):

1. Unicode segmentation — splits text into grapheme clusters, words, and soft-wrap opportunities using the Unicode Line Breaking Algorithm
2. Canvas measurement — renders each segment to an off-screen <canvas> with ctx.measureText(), which uses the real font engine without triggering layout
3. Width caching — stores segment widths in a flat typed array for O(1) lookup

layout() phase (run every frame):

1. Reads cached widths from the typed array
2. Runs a greedy line-breaking algorithm using only addition and comparison operations
3. Returns an array of line objects with pre-computed positions

No DOM queries. No layout engine. No reflows. Just arithmetic over a flat array.

Benchmark: 500 Text Blocks

This is the scenario measured in the DOM vs Pretext benchmark demo built by community contributor clawsuo-web. It renders 500 independent text blocks and measures layout time on each resize event.

At 500 blocks with the DOM approach, you're already over budget for a 60fps animation before you've drawn anything. Pretext leaves 99.7% of your frame budget for actual rendering.

Benchmark: Real-Time Resize

The resize scenario is where the gap becomes most visible. When a user drags a resize handle, layout must recalculate on every mouse move event — potentially 60+ times per second.

With DOM measurement, resize handlers typically include debouncing (50–200ms delay) specifically to avoid layout thrash. With Pretext, you can layout on every mousemove event without any debouncing, because a layout() call for a 500-text batch costs ~0.09ms.

This is why demos like Drag Sprite Reflow — where a sprite drags through text and paragraphs reflow in real time — are possible with Pretext and practically impossible with DOM measurement.

Benchmark: Animation Frames

For typographic animation (text as physics objects, particle systems, game tiles), layout must run every frame — at 60fps, that's once every 16.67ms.

DOM text measurement at 60fps is simply not viable for non-trivial amounts of text. Pretext's layout() runs in ~0.09ms per 500-text batch, meaning you can layout 300+ text blocks per frame and still have 15ms remaining for rendering.

This unlocks the entire category of text-based games and physics simulations in the pretext.cool showcase.

When DOM Measurement Is Still Fine

Pretext isn't the right tool for everything. DOM measurement is perfectly adequate when:

• Text layout is static (rendered once, not animated)
• You have fewer than ~20 text blocks updating simultaneously
• Layout only changes on user interaction (button clicks, page navigation)
• You're already using CSS Grid or Flexbox and don't need custom line breaking

Pretext is the right tool when you need text layout to be fast enough to run on every frame — real-time reflow, animation, games, or data-dense UIs with live updates.

Try the Benchmark Yourself

The DOM vs Pretext demo lets you see the performance difference in your own browser, on your own hardware. Run both approaches side-by-side and watch the frame rate counter.

Want to build something with Pretext? Browse the full community showcase for inspiration, or jump straight to the getting started guide.

Community benchmark demo by clawsuo-web. Pretext library by chenglou.