How to Diagnose and Optimize Frontend Performance in 2D Design Tools

1. Background

Before discussing front‑end performance, the article shows typical operation screenshots of the Meijian 2D tool, illustrating the difference between pre‑optimization and post‑optimization states with animated GIFs.

The article notes that users abandon pages that take more than three seconds to load, highlighting the importance of front‑end performance for user satisfaction.

2. Tool Front‑End Performance Troubleshooting Difficulties

Performance issues are harder to diagnose than functional bugs because users often describe symptoms vaguely (e.g., “slow”, “laggy”) and cannot reproduce the exact steps. Additionally, performance depends heavily on user hardware, environment, and specific project data, making remote replication challenging.

Continuous performance optimization is required as new features are released, but without comprehensive impact assessment, regressions can occur.

3. Performance Problem Thinking

3.1 Clarify User Scenarios

Two main scenario types are identified:

Content loading scenarios (project load, page load, image load) evaluated by latency (ms).

Content interaction scenarios (image drag, rotate, zoom) evaluated by frame rate (FPS).

3.2 Define Follow‑Up Directions

Key focus areas include quickly identifying performance‑related feedback, establishing proactive offline interception mechanisms, and implementing online performance monitoring.

3.3 Determine Monitoring Metrics

Data collection uses instrumentation to report latency for loading scenes and FPS for interaction scenes, along with hardware info (CPU, memory, GPU, hardware acceleration) and project details (size, element count, effects). Prioritization is applied to address critical issues first.

4. Data Monitoring Dashboard and Metric Assurance

4.1 Rapid Identification of Operational Performance Issues

By filtering collected data by user ID, time range, or project ID, the team can assess whether reported performance problems are reflected in frame‑rate metrics, which typically stay above 50 FPS, indicating normal operation.

4.2 Offline Performance Baseline Dashboard

Automated UI tests cover core scenarios to establish a performance baseline. Multi‑dimensional comparison of baseline data enables early detection of regressions.

4.3 Online Operational Performance Dashboard

Online user data is segmented into frame‑rate intervals (0‑10, 10‑20, 20‑30, >30 FPS). This distribution reveals the proportion of low‑performance users.

4.4 Definition and Tracking of Low‑Performance Users

Low‑performance users are defined as those with ≤20 FPS for at least 10 % of operations and more than 100 core‑scenario actions per week. Monitoring this cohort helps assess the impact of performance optimizations.

5. Practical Cases

5.1 Simple Front‑End User Behavior Investigation

A user reported occasional stutter. Analysis showed low frame rates were caused by the computer not having hardware acceleration enabled; enabling it restored normal performance.

5.2 Performance Baseline Prevented Regression

An optimization improved a non‑core scenario but, according to the baseline report, degraded core‑scenario performance, leading to a rollback.

5.3 Data Analysis Revealed Rising Low‑Performance Users

An optimization targeting a specific behavior initially seemed effective, but post‑release data showed an increase in low‑frame users, prompting a rollback.

6. Summary

Front‑end performance is a critical component of user experience, directly affecting conversion and retention. Effective performance management requires systematic data collection, analysis, and monitoring using scientific methods. The presented practices aim to help teams proactively identify, diagnose, and resolve performance issues.