Home/Start/Performance
Start / Zidom JS

Performance

Measured bundle sizes, fine-grained updates and reproducible benchmarks.

Performance and measurements#

Zidom's goal is to do only the DOM work required by a change. That is an architectural choice, not proof that every application will be faster than every competing framework.

This page separates measured bundle sizes from expected runtime behavior and benchmark work that is still in progress.

Beta.2 release measurements — October 31, 2026#

The published Beta.2 release records reviewed measurements at the exact source commit f1cb8d4326c2e8acb94b59a72133489648c26e7d:

  • Core + DOM: 4,360 bytes gzip, within the 4.5 KiB (4,608-byte) public-API bundle guard.
  • Combined app stack: 9,062 bytes gzip, within the 10 KiB (10,240-byte) public-API bundle guard.
  • The maintainer's release matrix passed 10/10 local checks; these are not independent performance audits.

The figures represent bundled, minified ES2022 public APIs, not complete app downloads, page startup, or direct React/Preact/Vue comparisons. The October 29 figures below remain as a historical baseline and should not be confused with current Beta.2 release measurements. See bundle methodology.

Measured bundle size — October 29, 2026#

The maintainer's Zidom bundle-size baseline records the following gzip sizes from a CI run on October 29, 2026:

  • Core: 1.00 KiB gzip — the reactive core public API.
  • Core + DOM: 2.67 KiB gzip — the combined reactive core and DOM renderer public APIs.
  • Router: 3.26 KiB gzip — the router public API.
  • Query: 1.91 KiB gzip — the query public API.
  • DI: 0.84 KiB gzip — the dependency-injection public API.
  • Forms: 1.54 KiB gzip — the forms public API.
  • Combined app stack: 6.45 KiB gzip — one bundled API surface for the core, DOM, router, query, DI, forms and store packages.

Measurement scope matters. These are minified ES2022 ESM bundles built with esbuild, then compressed with gzip level 9. Public exports are preserved. They are not the bytes downloaded by a typical application, and the numbers are neither additive nor a current cross-framework ranking. Application code, assets, compiler tooling, deployment-specific code splitting, and startup costs are not included.

Evidence access: The underlying framework repository is currently private. Visitors without repository access cannot inspect the CI run or reproduce this baseline from source. These are maintainer-reported historical measurements, not independently verified public benchmarks. We will only claim public reproducibility when source and fixtures are accessible.

The dated numbers above are a documented historical baseline, not a claim that today's latest commit has the same measured size. To reproduce a current measurement, use the size script and publish its output.

What fine-grained updates mean#

When a signal is used as a reactive DOM binding, changes notify that binding instead of invoking the component's setup again to rebuild a virtual tree.

tsx
●  Zidom
import { signal } from '@zidomjs/core';const count = signal(0);const view = <button onClick={() => count.value++}>  Count: {count}</button>;

In this example, the text node depends on count. Changing the signal updates the subscribed binding. Other unrelated bindings do not need to update.

This is a work-avoidance model, not a promise that every update has zero overhead. Effects, component ownership, list reconciliation, style/layout work and application logic still take time. See reactive rendering and effects and lifecycle.

Keyed lists and DOM identity#

Zidom has a keyed-list renderer designed to reuse matching DOM nodes during reorder and update operations. Reuse can preserve input focus and local DOM state. Creating, removing, moving or updating rows still costs work.

The experimental comparative browser harness exercises a 1,000-row keyed list in Zidom, React, Preact and Vue. It verifies every row and each keyed element's identity after repeated revisions and records diagnostic timings. Those timings are not a general speed ranking. The frameworks schedule and flush updates differently, and the harness does not cover full application startup, memory, layout, paint or hydration.

How to reproduce the measurements#

With repository access, clone the framework repository, install its pinned development dependencies and run the following locally:

bash
●  Zidom
npm installnpm run size:prodnpm run size:checknpm run benchmarknpm run benchmark:compare

The browser comparison requires Playwright Chromium and the repository's benchmark prerequisites. Running these commands locally does not trigger GitHub Actions. See benchmark instructions and production size methodology. The internal signal/effect benchmark is not comparable to React/Vue component-render benchmarks.

What is not yet established#

  • A trustworthy, apples-to-apples cold start and time-to-interactive comparison.
  • Production-app DOM update, memory and input latency results across desktop and mobile.
  • Independent confirmation of performance against React, Preact, Vue, Solid, Svelte or Angular.
  • Complete hydration, accessibility and browser/device performance coverage.

Until those measurements are available, Zidom's position is a small measured library surface and a fine-grained update architecture, not an unqualified claim to be the fastest framework.

Explore the interactive examples or try the playground to see the reactive behavior firsthand.