PaperlayerView exact revision on arXiv

Source-linked AI summary

Decomposing Browser Pipeline Architectures for DOM-Sourced Particle Effects: Worker Offload, WebGL, and WebAssembly

Hossein Asadi

arXiv:2608.23609v1cs.SE

TL;DR

The paper asks when browser-layer optimizations fail to become product-level performance gains. It decomposes DOM-sourced particle pipelines across thread, renderer, and simulation choices, measuring interactive, stress, and simulation-only regimes. Worker offload improves interactive pacing, while WASM kernel gains do not necessarily improve end-to-end FPS and renderer rankings vary by configuration.

  • Problem

    Layered browser architectures lack controlled evidence showing whether Worker, renderer, and simulation optimizations propagate from local measurements to end-to-end user-visible performance.

  • Method

    The paper varies thread placement, renderer, and simulation backend across five DOM-sourced particle pipelines, using interactive, stress, and simulation-only measurements with replication.

  • Results

    Worker offload improves interactive pacing; WASM speeds Chrome-class simulation kernels by about 1.5–1.85×, yet those gains need not produce clear end-to-end FPS improvements, while renderer rankings vary across configurations.

  • Takeaways & Limitations

    Bottleneck-aware evaluation should identify the dominant layer and test whether its local improvement propagates to user-visible performance.

  • Takeaways & Limitations

    Absolute FPS and capture latencies are not claimed to transfer to arbitrary live DOMs, and heavier real pages may change ranking magnitudes.

Abstract

from arXiv · show

Local optimization does not necessarily yield end-to-end optimization in layered browser architectures. Teams often treat Web Workers, WebGL, and WebAssembly as interchangeable ways to "make it faster," yet each lever targets a different layer. We present a controlled architectural decomposition--using DOM-sourced particle pipelines as a concrete workload--of five particle pipelines (P1-P5), with an additional non-particle CSS-layer baseline (P0), that isolates thread placement, renderer choice, and simulation backend. Using a reproducible harness we measure interactive pacing, high-load end-to-end stress, and a simulation-only microbenchmark, plus same-host cross-browser / dual-GPU-class replication (Firefox 153+Intel UHD; Chrome 138+NVIDIA NVK) and an independent second-host slice on Google Colab (Chrome 150, Tesla T4, n=5). Four results stand out. (1) Worker offload improves interactive pacing on paper-primary Chrome (approx. 144 vs approx. 52 FPS; Cliff's delta=1, n=10). (2) AssemblyScript speeds the Chrome update kernel by about 1.5-1.6x on the primary host and approx. 1.85x on Colab T4 (sim-only). (3) Under approx. 250k WebGL particles the Chrome sim-only WASM win need not raise product FPS (P5<=P4 on primary/Firefox; P5 approx. P4 on Colab T4); in-worker CPU phase timers show simulate still dominates the accounted budget, so the non-translation is not a simple "draw dominates CPU" story. (4) Renderer ranking and absolute margins vary across browser/GPU/host configurations. The contribution is bottleneck-aware architectural measurement: identify the dominant layer and test whether a layer win propagates to user-visible FPS.

1. Introduction

The paper frames Workers, WebGL, and WASM as layer-specific optimizations whose local gains may not improve user-visible performance. It studies this translation problem through controlled DOM-sourced particle pipelines and bottleneck-aware measurements.

  • Layer-local optimization need not improve end-to-end, user-visible performance in layered browser architectures.
  • DOM-sourced particle dissolve pipelines combine DOM capture, CPU simulation, and Canvas2D/WebGL drawing into one measurable product path.
  • Five particle pipelines vary thread placement, renderer choice, and simulation backend, while P0 remains a non-particle CSS-layer baseline.
  • The measurement method separates interactive pacing, end-to-end stress, and simulation-only evidence, with replication across browsers, GPU classes, and a second host.
  • Worker offload dominates interactive gains on paper-primary Chrome, AssemblyScript speeds update kernels, and kernel gains need not produce clear end-to-end FPS gains under WebGL-heavy load.

2. Related Work

Related work establishes Workers, WebAssembly, GPU rendering, DOM capture, and jank metrics as studied technologies. The paper positions its gap as controlled, joint architectural measurement that pairs kernel results with end-to-end performance.

  • Related performance research motivates measuring browser computation, dependency-aware pipelines, page complexity, and main-thread congestion.
  • Prior work commonly reports WebAssembly kernel or microbenchmark speedups, but this paper pairs them with Worker+WebGL end-to-end FPS.
  • Table 1 provides a structured comparison of related empirical and systems studies rather than a systematic literature review.
  • Web Workers, WebGL, and WebAssembly are mature technologies studied largely in isolation rather than as jointly varied browser-stack levers.
  • The paper uses DOM-sourced particle pipelines as an instrumented workload for studying layered browser architectures, treating particle aesthetics as incidental.

3. Method: Pipeline Architectures

The method decomposes a shared DOM-capture workload into orthogonal thread, simulation, and renderer choices across P1–P5, with P0 outside the particle comparison. Measurements distinguish product-facing FPS and pacing from simulation-only performance.

  • Shared capture: All particle pipelines share DOM capture into an ImageBitmap or pixel buffer under common geometry and styling constraints.
  • Shared capture: P0 splits the captured image across CSS layers instead of sampling particles, so it is not a per-particle peer.
  • Design axes: The architecture varies three orthogonal choices: thread, simulation backend, and renderer.
  • Pipeline configurations: P1 is the main-thread Canvas2D particle negative control, while P2 changes only the renderer to WebGL2.
  • Pipeline configurations: P3–P5 move work into a worker; P4 and P5 both use WebGL2 but differ in JavaScript versus WASM simulation.
  • Measurement: Primary metrics are effect FPS and frame-time p95, while sim-only reports mean update-frame time and derived particles/s without drawing.

4. Experimental Setup

The study uses controlled synthetic DOM fixtures and three measurement regimes to isolate browser-pipeline layers across replicated browser, GPU, and host configurations.

  • Fixtures: Synthetic fixtures A, B, and C use a controlled complexity ladder rather than scraped pages or a live-web corpus.The ladder is designed to isolate capture cost while keeping architectural comparisons comparable.
  • Measurement regimes: The harness measures interactive pacing, end-to-end stress, and simulation-only performance as distinct experimental regimes.Interactive runs peak near 96k particles, stress runs reach 250k, and sim-only excludes drawing.
  • Reproducibility: Interactive, stress, and simulation-only campaigns use ten repetitions, with means for interactive aggregates and medians for stress and sim-only aggregates.The harness defaults to BENCH_REPS=10 and records reproducible result trees.

5. Results

Worker offload produces the clearest interactive benefit, while stress, kernel, and replication results show that renderer and WASM gains do not translate uniformly across configurations.

  • Interactive regime: Worker pipelines reach approximately 144 FPS, whereas main-thread particle pipelines remain near 52–60 FPS on Fixture A.The worker-versus-P1 comparison has Cliff’s δ=1.0 and exact p=1.08 × 10^-5.
  • Interactive regime: At density 2, worker frame-time p95 is 7.0 ms versus 21.2 ms for P1, but the interactive ceiling prevents separating WebGL and WASM effects.The same worker/main-thread split appears on Fixture B.
  • Capture versus DOM complexity: Capture latency increases with fixture complexity for P1, from 6.6 ms on A to 28.4 ms on C, while P5 remains heaviest on C at 15.4 ms.Capture is measured separately from the animation/render loop.
  • Stress end-to-end: At 250k particles on primary Chrome/NVK, P4 reaches 112.9 FPS, ahead of P5 at 96.9 and P3 at 63.2.Across densities, P5 remains below P4, while WebGL workers outperform the Canvas2D worker on this path.
  • Stress end-to-end: P5−P4 ranges from roughly −12% to −16% in median FPS, so the simulation-only WASM advantage does not produce an end-to-end FPS win across configurations.On Colab T4, P5 is approximately tied with P4, with a gap of about 2 FPS.
  • In-worker frame phases: In-worker timers assign about 89–93% of accounted CPU time to simulation, while draw-call wall time is about 1%; GPU elapsed remains below simulation CPU time.At density 2, P4 reports 2.19 ms GPU versus 5.45 ms simulation CPU, and P5 reports 2.18 versus 3.85 ms.
  • Simulation-only: WASM is 1.47×–1.64× faster than the equivalent JS update loop in sim-only tests, with WASM throughput around 137–165M particles/s versus 93–103M for JS.The Chrome-class kernel advantage is not portable: Firefox sim-only WASM is approximately 0.56× JS, while Colab T4 reaches approximately 1.85× at 250k.
  • Replication: Renderer ranking and absolute FPS margins vary across browser, GPU, driver, and host configurations.An archival headed Chrome stress matrix preferred P3 over WebGL, while Colab T4 produced P5≈P4≫P3.

6. Discussion

The discussion shows that browser performance levers optimize different layers, so local wins may not propagate to end-to-end performance. Worker offload improves interactive pacing, WASM improves Chrome-class simulation kernels, but renderer and host configuration shape product-level outcomes.

  • Findings: P4 leads P5 in Chrome/NVK stress FPS, while P5 remains below P4 under the shared WebGL-heavy regime.The phase breakdown reports simulate as dominant, with draw-call CPU wall time small and GPU elapsed still below simulate.
  • Findings: 144 FPS versus 52 FPS: Worker pipelines P3–P5 outperform main-thread P1 on paper-primary Chrome interactive pacing.The reported effect size is Cliff’s δ=1 with n=10.
  • Findings: 1.5–1.6×: AssemblyScript accelerates the matched Chrome sim-only JavaScript loop, but Firefox reverses the ordering and Colab reaches approximately 1.85×.These results concern the isolated typed numeric update kernel, not product FPS.
  • Findings: Renderer ranking reverses across configurations: Chrome/NVK and Firefox prefer P4 over P5, Colab T4 makes WebGL workers competitive, and archival Chrome preferred P3.The comparison indicates that render-path cost depends on browser, GPU, driver, engine, and host.
  • Findings: captureMs grows from fixture A to B to C for both P1 and P5, establishing DOM capture as an independent startup cost.The paper treats capture separately from the animation/render loop rather than as evidence about live-web performance.
  • Implications: The practical rule is to identify the bottleneck layer and report product-FPS evidence alongside any layer-local kernel measurement.The broader contribution is bottleneck-aware decomposition rather than a universal ranking of particle libraries.

7. Threats to Validity

Validity is limited by host, fixture, metric, and instrumentation choices. The results support regime-dependent layer-translation patterns, not universally transferable absolute FPS or rankings.

  • External validity: Absolute FPS remains host-specific because the primary and Firefox/NVK matrices use one laptop, while Colab adds only one second host.Further physical hosts and GPU configurations remain useful for external validation.
  • External validity: Synthetic harness-authored fixtures are not representative production websites, so capture latencies and ranking magnitudes may shift on real pages.The supported scope is the reported regime-dependent pattern under controlled fixtures.
  • Construct validity: Headed UI-average-FPS and long-task signals were unreliable, so primary evaluation uses effect FPS and frame-time p95.Cross-engine absolute FPS is not directly comparable when display and timer ceilings differ; primary tables use n=10 and Colab uses n=5.
  • Internal validity: GPU timer evidence is Chrome-only and supportive, while compositor and display costs outside the WebGL command stream remain unmeasured.Sim-only measures the kernel without draw, and worker interactive pipelines can hit a display/timer ceiling.

8. Conclusion

The paper decomposes DOM-sourced particle pipelines by thread, renderer, and simulation backend to test whether layer-level optimizations reach user-visible performance. It finds worker pacing gains and Chrome-class WASM kernel gains, but no guaranteed end-to-end translation and configuration-dependent renderer rankings.

  • Conclusion: Worker offload improves interactive pacing on paper-primary Chrome, while AssemblyScript improves Chrome-class simulation kernels by approximately 1.5–1.85× but not on the Firefox slice.The Colab T4 slice supports the Chrome-class kernel result and the absence of a clear end-to-end WASM stress win.
  • Conclusion: Under WebGL-heavy stress, simulation remains dominant in accounted in-worker CPU phases, yet the WASM kernel advantage does not produce a clear product-FPS win.Renderer rankings and absolute margins also vary across browser, GPU, and host configurations.
  • Conclusion: The supported practical lesson is to identify the dominant bottleneck layer and test whether its optimization propagates to end-to-end user-visible performance.This layer-translation pattern, rather than a universally faster technology, is the paper’s generalizable contribution.
  • Future work: Future work includes additional physical hosts, compositor and display instrumentation, and product scenarios that remain clearly simulation-bound.Such scenarios may clarify when end-to-end WASM gains reappear.

Availability

The study provides reproducible code, harnesses, fixtures, analysis materials, statistics scripts, raw results, and an archived result tree for independent reproduction.

  • Artifacts: The reference library and companion experiments package contain the particle effect, harness, fixtures, analysis notes, statistics scripts, and raw JSON results.The materials cover primary, replication, phase-instrumented stress, and second-host regimes.
  • Reproduction: The benchmark commands support official, stress, simulation-only, and replication runs, including Firefox or Chrome selection.CPU and GPU phase stress can target the P4 and P5 worker pipelines.
  • Transparency: The study uses synthetic UI fixtures only, reports no human subjects or personal data, and declares no competing interests or specific grant funding.A DOI-backed Zenodo archive stores the result trees, harness, and analysis scripts.
Loading 2608.23609v1…