Fullmoon Core Engine: Design Notes on Build and Rendering Optimization

A web performance design that measures build-time bundle optimization separately from task offloading during browser execution.

1. Separate build time from runtime

These are design notes on web build and rendering optimization. Introducing Rust or WebAssembly does not automatically make an entire application faster. First identify bottlenecks through bundle analysis and browser profiling.

At build time, consider module splitting, dead code elimination, and asset optimization. In the browser, measure network requests, JavaScript parsing and execution, layout, and paint separately. Downloaded JavaScript size and time to first server response are different metrics.

2. WebAssembly and Worker boundaries

CPU-intensive calculations may be candidates for WebAssembly, but initialization and the cost of crossing the JavaScript boundary also need measurement. Workers cannot traverse or modify the DOM directly. Extract the required data on the main thread, send it to the worker, and update the screen when results arrive. See the Web Workers documentation.

• Using a worker is different from having a single WebAssembly instance automatically run across multiple threads.
• Measure message serialization and data copying costs, and consider transferable objects where appropriate.
• Implement cancellation and timeouts, preserving basic page functionality if a worker fails.

3. Reproducible performance comparisons

Use the same device and network conditions, distinguish cold from warm caches, and measure multiple runs. Record build time, transfer size, LCP, INP, and CLS separately; a single number cannot describe overall performance.

Do not present speedup factors, millisecond timings, or unconditional subsecond rendering guarantees as results without supporting benchmark data.