Dear ClickUp Team,

I am writing to provide detailed technical feedback regarding the loading performance of the Workload and Gantt views. While I greatly appreciate the depth of functionality in ClickUp 4.0, the current load times for complex projects create significant friction in my daily workflow. I would like to propose a specific architectural solution for your consideration.

Currently, navigating to the Workload or Gantt view results in a prolonged "white screen" delay and choppy scrolling behavior. Upon reviewing network activity in DevTools, I observed that the initial JavaScript payload and associated task data can reach upwards of 20MB+.

· Impact: For teams like mine that manage hundreds of active projects, this latency renders quick daily check-ins nearly impossible. The high cost of context switching (waiting for the view to become interactive) forces users to revert to external spreadsheets just for speed.

· Specific Pain Point: The main thread becomes bottlenecked during the heavy JavaScript execution and data hydration phase, degrading the overall user experience.

I strongly recommend integrating WebAssembly (Wasm) as a dedicated compute engine specifically for the rendering and logic of the Workload and Gantt modules.

· Data Processing in Wasm: Offload intensive calculations—such as timeline collision detection, dependency graph resolution, and "Remaining Time" metrics—from JavaScript to Wasm (compiled from Rust or Go).

· Efficient Data Loading: Implement a Wasm-based streaming parser to incrementally deserialize the 20MB payload, rather than waiting for the browser's JS engine to parse the entire monolithic file upfront.

· Canvas Rendering: Utilize Wasm to manage Canvas draw calls. This would enable 60fps scrolling and zooming, bypassing the performance limitations of traditional DOM manipulation for the chart area.

This proposal aligns well with ClickUp 4.0's existing modern Angular and micro-frontend architecture.

· Stack Alignment: WebAssembly modules integrate seamlessly via standard browser APIs and can be lazy-loaded as separate, cacheable chunks to minimize the impact on the initial application bundle.

· Maturity: This approach is already production-proven by industry leaders. Figma uses Wasm for rendering engine performance, and Google Sheets relies on Wasm for calculation speed. The technology is mature and supported across all modern browsers.

· Implementation Path: The team could de-risk this initiative by first migrating the Time Calculations & Sorting logic to Wasm. This would provide an immediate, high-impact performance win before undertaking a full Canvas rendering overhaul.

· Payload Efficiency: Wasm binaries compress more efficiently than equivalent JavaScript. The compute-heavy logic payload could shrink from megabytes to just a few hundred kilobytes.

· Perceived Performance: I estimate this could reduce Time-to-Interactive (TTI) for these views by 60-70% , making the switch between views feel near-instantaneous.

· Scalability: This enhancement would empower teams to visualize 10,000+ tasks with smooth, native-like responsiveness, eliminating the risk of browser tab freezing.

Thank you for your time and for building such a powerful platform. I hope this specific, technical feedback is helpful for the roadmap planning of future performance updates.

Best regards,

Sk W