Optimizing a Web Frontend Workflow Engine: Reducing Load Time, Input Lag, and Memory Usage

The team was tasked with improving a web‑based workflow engine that displayed over 300 components, suffered from slow page loads, noticeable input lag, and frequent browser crashes due to high memory usage.

Basic Flow Diagram

graph TD 调用接口拿到配置 --> 前端组装数据option --> 调用渲染器 --> for循环展示组件 --> 页面展示

Key Problems Identified

Slow initial page rendering.

Element UI el‑input caused input lag.

Excessive memory usage leading to browser crashes.

Investigation Steps

The API response time was acceptable (~100 ms), so the focus shifted to the front‑end rendering pipeline. The page assembles a large option object from the backend configuration, which is then passed to a renderer.

Optimization Directions

Trim the option data size.

Freeze the option object with Object.freeze to bypass Vue’s reactive getters/setters.

Reduce unnecessary component re‑renders.

Ensure event listeners are removed promptly.

Apply vue.lazy (or change events) to mitigate input lag.

Analyze memory leaks using Chrome’s Memory/Performance tools.

Lazy‑load tables.

Findings & Solutions

Option Size : The assembled option grew to 440 k lines. By using provide/inject (Vue) or React context, the size was reduced to ~40 k lines.

Option Freezing : After freezing the final option, rendering performance improved because Vue no longer intercepts get/set on a massive reactive object.

Excessive Render Loops : Some components were rendered multiple times due to hidden fields for different approval nodes. The fix was to pre‑assemble data and control visibility via event listeners instead of rendering then hiding.

Input Lag : The lag stemmed from Vue’s reactive data updates on every keystroke. Switching the input event to change (or wrapping the input with a lazy‑update variable) resolved the issue.

Memory Leaks : EventBus instances remained attached after page closure, causing memory bloat. Adding proper off calls before re‑binding eliminated the leaks.

Table Rendering : Table rendering was deferred using setTimeout to move heavy work to the next event loop, allowing the main page to appear faster.

Summary

When data volume is large, prune or freeze it to speed up rendering.

Frequent browser crashes usually indicate memory leaks from oversized objects, circular references, or lingering event listeners.

Complex front‑end features should be preceded by design reviews and documentation to avoid low‑level performance pitfalls.

References

Hand‑on guide to diagnosing JavaScript memory leaks: https://zhuanlan.zhihu.com/p/322356761