Performance optimization method, system, device and storage medium for front-end application

Abstract

The application relates to a front-end application performance optimization method, system, device and storage medium. The method comprises the following steps: identifying a hot path of a runtime performance causal graph of a front-end application when the front-end application is running; identifying an anti-pattern of the front-end application according to a predefined anti-pattern graph of the front-end application and the runtime performance causal graph; and generating a visual diagnosis report of the front-end application according to the hot path and the anti-pattern, wherein the visual diagnosis report comprises the highlighted hot path, optimization suggestions, quantitative prediction indexes of the optimization suggestions and verification operation entrances of the optimization suggestions. The scheme provided by the application can improve the efficiency and accuracy of performance optimization of the front-end application.

Description

Technical Field

[0001] This application relates to the fields of software development tools and data visualization technology, and in particular to a method, system, device and storage medium for optimizing the performance of front-end applications. Background Technology

[0002] Performance optimization of front-end applications of related technologies can provide component-level flame graphs, function call stack statistics, or network request sequence graphs, clearly showing "which component renders slowly" or "which function call takes a long time". Based on qualitative inferences from static code analysis or pattern statistics, it can provide optimization tips based on code patterns (e.g., "It is recommended to use React.memo" or "It is recommended to use useMemo").

[0003] However, performance optimization of front-end applications using related technologies lacks definitive causal relationships at the diagnostic level, lacks quantitative data support at the decision-making level, and faces high time and operational costs at the verification level. Data that only presents performance phenomena cannot show the causes of these phenomena or quantify the performance indicators after optimization. It can only rely on personal experience and a deep understanding of the code to manually reason and check logs to diagnose the performance of the front-end application. The performance indicators after optimization are evaluated based on vague experience or guesswork, resulting in inefficient and error-prone performance optimization of front-end applications using related technologies, leading to either insufficient or excessive optimization of the front-end application. Summary of the Invention

[0004] To address or partially address the problems existing in related technologies, this application provides a method, system, device, and storage medium for optimizing the performance of front-end applications, which can improve the efficiency and accuracy of front-end application performance optimization.

[0005] The first aspect of this application provides a performance optimization method for a front-end application, the method comprising: During the runtime of the front-end application, identify the hotspot paths in the runtime performance causal graph of the front-end application; Based on the predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph, identify the anti-pattern of the front-end application; Based on the hotspot path and the anti-pattern, a visual diagnostic report of the front-end application is generated. The visual diagnostic report includes the highlighted hotspot path, optimization suggestions, quantitative prediction indicators of the optimization suggestions, and a verification operation entry point for the optimization suggestions.

[0006] In one embodiment, the method further includes: The optimization suggestions are verified through a sandbox replay via the verification operation entry point.

[0007] In one implementation, the step of generating the quantitative prediction index of the optimization suggestion includes: By extracting data, the actual running data of the front-end application components during a set time period is extracted from the historical records of the runtime performance causal graph. The simulation data of the component during the set time period after adopting the optimization suggestions is used. Based on the actual operating data and the simulated operating data, calculate the quantitative prediction index of the optimization suggestion and the confidence level of the quantitative prediction index.

[0008] In one implementation, the step of generating the runtime performance cause-effect graph includes: Compile-time instrumentation and runtime lightweight proxy are used to collect the state change flow, component rendering flow, and user interaction flow of the front-end application; Based on the state change flow, the component rendering flow, the user interaction flow, and the causal association algorithm, the runtime performance causal graph is generated. The nodes of the runtime performance causal graph include component instances, reactive state nodes, and user interaction events. The directed edges of the runtime performance causal graph include trigger edges, driving edges, and rendering call edges.

[0009] In one implementation, identifying hotspot paths in the runtime performance causal graph of the front-end application during runtime includes: Based on the runtime performance cause-effect graph, identify the causal transmission path during the runtime of the front-end application; An improved graph analysis algorithm is used to calculate the total performance overhead percentage of the causal propagation path based on the nodes, directed edges, and quantization attributes of the directed edges in the runtime performance causal graph. The causal transmission path that accounts for a percentage of total performance overhead greater than a preset percentage threshold is identified as the hotspot path in the runtime performance causal graph of the front-end application.

[0010] In one implementation, identifying the anti-pattern of the front-end application based on a predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph includes: Based on the predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph, the runtime performance cause-effect graph is matched with the predefined anti-pattern graph to identify the anti-pattern of the front-end application. The anti-pattern includes the unrelated state lifting anti-pattern and / or the inline function waterfall anti-pattern.

[0011] A second aspect of this application provides a performance optimization system for a front-end application, the system comprising: The first identification unit is used to identify hotspot paths in the runtime performance causal graph of the front-end application during runtime. The second identification unit is used to identify the anti-pattern of the front-end application based on the predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph. The report generation unit is used to generate a visual diagnostic report of the front-end application based on the hotspot path identified by the first identification unit and the anti-pattern identified by the second identification unit. The visual diagnostic report includes the highlighted hotspot path, optimization suggestions, quantitative prediction indicators of the optimization suggestions, and a verification operation entry for the optimization suggestions.

[0012] In one embodiment, the system further includes: The verification unit is used as the verification operation entry point for the visual diagnostic report generated by the report generation unit, and performs sandbox playback verification of the optimization suggestions.

[0013] A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0014] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method described above.

[0015] The fifth aspect of this application provides a computer program product comprising computer instructions that, when executed by a processor, implement the method described above.

[0016] The technical solution provided in this application may include the following beneficial results: The technical solution of this application identifies hotspot paths and anti-patterns in the runtime performance causal graph of a front-end application. Based on these hotspot paths and anti-patterns, it diagnoses the performance of the front-end application, elevating the root cause localization of performance issues from experience-based, hourly or even day-long inference and investigation to data-driven, minute-level, intuitively traceable, and visual performance diagnosis. Based on the hotspot paths and anti-patterns in the runtime performance causal graph, it generates optimization suggestions and predictive quantitative indicators for these suggestions, transforming optimization decisions from those based on fuzzy experience and qualitative guesswork to rational decisions based on quantitative predictive data. It also provides a one-click verification operation entry point for these optimization decisions. The front-end application performance optimization method of this application, based on data-driven decision-making, achieves a closed loop of causal tracing, quantitative decision-making, and verification assistance for front-end application performance optimization, thereby improving the efficiency and accuracy of front-end application performance optimization.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0019] Figure 1 This is a flowchart illustrating a performance optimization method for a front-end application as shown in an embodiment of this application; Figure 2 This is another schematic diagram of the performance optimization method for front-end applications shown in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of a front-end application performance optimization system shown in an embodiment of this application; Figure 4 This is another structural schematic diagram of the performance optimization system for front-end applications shown in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0020] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0021] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0023] This application provides a method for optimizing the performance of a front-end application, which can improve the efficiency and accuracy of front-end application performance optimization.

[0024] The front-end application of this application embodiment may include a Web single-page application developed based on a modern responsive framework (including but not limited to React, Vue 3, SolidJS); its core feature is declarative rendering and state-driven view, that is, the user interface (UI) is a function of the application state, and any change in the state will automatically trigger the recalculation and update of the relevant view.

[0025] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0026] Figure 1 This is a flowchart illustrating a performance optimization method for a front-end application as shown in an embodiment of this application.

[0027] See Figure 1 A performance optimization method for front-end applications, comprising: Step 101: During the runtime of the front-end application, identify the hotspot paths in the runtime performance causal graph of the front-end application.

[0028] In one embodiment, during the runtime of the front-end application, each causal transmission path of the runtime performance causal graph can be identified based on the runtime performance causal graph of the front-end application; and hotspot paths of the runtime performance causal graph can be determined based on the total performance overhead of each causal transmission path and the total performance overhead of the front-end application.

[0029] Step 102: Identify anti-patterns in the front-end application based on the predefined anti-pattern graph and runtime performance cause-effect graph of the front-end application.

[0030] In one embodiment, anti-patterns of the front-end application can be identified during runtime based on a predefined anti-pattern graph of the front-end application and a runtime performance causal graph of the front-end application.

[0031] Step 103: Based on the hotspot paths in the runtime performance causal graph of the front-end application and the anti-patterns of the front-end application, generate a visual diagnostic report for the front-end application. The visual diagnostic report includes highlighted hotspot paths, optimization suggestions, quantitative prediction indicators of the optimization suggestions, and entry points for verifying the optimization suggestions.

[0032] In one embodiment, a visual diagnostic report for the front-end application can be generated based on the hotspot paths of the runtime performance causal graph and the anti-patterns of the front-end application. The visual diagnostic report may include hotspot paths highlighted using an interactive causal graph visualization view, actionable optimization suggestions including code modification examples, quantitative prediction metrics and confidence levels of the optimization suggestions displayed through quantitative prediction cards, and a verification operation entry point for the optimization suggestions that can be launched in a sandbox with one click.

[0033] The front-end application performance optimization method of this application identifies hotspot paths and anti-patterns in the runtime performance causal graph of the front-end application. Based on these hotspot paths and anti-patterns, it diagnoses the performance of the front-end application, elevating the root cause localization of performance issues from experience-based, hourly or even day-long inference and investigation to data-driven, minute-level, intuitively traceable, and visual performance diagnosis. Based on the hotspot paths and anti-patterns in the runtime performance causal graph, it generates optimization suggestions and predictive quantitative indicators for these suggestions, transforming optimization decisions from those based on fuzzy experience and qualitative guesswork to rational decisions based on quantitative predictive data. It also provides a one-click verification operation entry point for these optimization decisions. This front-end application performance optimization method, based on data-driven decision-making, achieves a closed loop of causal tracing, quantitative decision-making, and verification assistance for front-end application performance optimization, thereby improving the efficiency and accuracy of front-end application performance optimization.

[0034] Figure 2 This is another schematic diagram of the performance optimization method for front-end applications shown in the embodiments of this application.

[0035] See Figure 2 A performance optimization method for front-end applications, comprising: Step 201: Generate a runtime performance causal graph of the front-end application based on the state change flow, component rendering flow, user interaction flow, and causal association algorithm of the front-end application.

[0036] In one embodiment, during the runtime of the front-end application, the event stream of the front-end application can be collected. The event stream of the front-end application may include the state change stream, component rendering stream, and user interaction stream of the front-end application. Based on the event stream of the front-end application, a causal association algorithm is used to generate a runtime performance causal graph of the front-end application. The generated runtime performance causal graph of the front-end application may be a runtime performance causal graph constructed in real time based on the event stream of the front-end application, or it may be a runtime performance causal graph updated in real time based on the event stream of the front-end application.

[0037] In one embodiment, the runtime performance causal graph is a directed, time-stamped graph data model dynamically constructed during the actual execution of the application. Nodes in the runtime performance causal graph represent runtime entities, including component instances, reactive state nodes, and user interaction events. Directed edges represent defined causal relationships between entities, including triggering edges, driving edges, and rendering call edges. Triggering edges represent the causal relationship where a state change (e.g., state change A) triggers a component (e.g., component B) to re-render. Driving edges represent the causal relationship where a user interaction event (e.g., user interaction event C) leads to a state change (e.g., state D). Rendering call edges represent the call relationship where parent component rendering leads to child component rendering. Each directed edge carries precise time stamps, historical trigger counts, and cumulative performance overhead (e.g., total time), making the runtime performance causal graph not only a relationship graph but also a data model containing performance semantics.

[0038] In one embodiment, compile-time instrumentation and a lightweight runtime proxy can be used to collect the state change flow, component rendering flow, and user interaction flow of the front-end application. Based on the state change flow, component rendering flow, user interaction flow, and causal association algorithm, a runtime performance causal graph is generated. The nodes of the runtime performance causal graph include component instances, reactive state nodes, and user interaction events. The directed edges of the runtime performance causal graph include trigger edges, driving edges, and rendering call edges. Each directed edge of the runtime performance causal graph has quantization attributes, which may include timing markers, cumulative historical trigger counts, and cumulative performance overhead. By collecting the event flow of the front-end application through compile-time instrumentation and a lightweight runtime proxy, it is possible to ensure that the performance overhead on the front-end application is less than 1%.

[0039] In one embodiment, the front-end application may include a web single-page application developed based on a modern responsive framework (including but not limited to React, Vue3, SolidJS); its core feature is declarative rendering and state-driven view, that is, the user interface (UI) is a function of the application state, and any change in the state will automatically trigger the recalculation and update of the relevant view.

[0040] In one embodiment, a non-intrusive approach combining compile-time instrumentation (implemented through JavaScript compilers Babel and SWC (Speedy Web Compiler, a compiler written in Rust)) and runtime lightweight proxies (implemented using JavaScript's Proxy object or decorator) can be used to collect the state change flow, component rendering flow, and user interaction flow of the front-end application.

[0041] In one embodiment, the collected state change stream may include all reactive state update operations of the front-end application that are precisely intercepted and recorded. The recorded content includes snapshots of values ​​before and after the update, high-precision timestamps (microsecond level), and a complete JavaScript call stack, such as React's useStatesetter, Redux's dispatch, and Vue 3's reactive / ref update.

[0042] In one embodiment, the debugging APIs provided by various frameworks (e.g., React's) can be used. <profiler>The component (Vue 3's onRenderTracked hook) or higher-order component wrapper collects the component rendering flow of the front-end application. The collected component rendering flow can include the start and end times of each component instance's rendering cycle, the number of virtual DOM nodes generated in this rendering, and the direct cause identifier that triggered this rendering.

[0043] In one embodiment, the user interaction stream collected from the front-end application may include user interaction events such as clicks, inputs, and scrolling that are listened to and recorded, as well as their processing functions.

[0044] In one embodiment, a first-in-first-out (FIFO) event buffer queue and a very short short-lived active event window can be maintained. A proximity time window backtracking algorithm can be used. When a component rendering event is detected as complete, the state change events that have occurred within the short-lived active event window (e.g., 5 milliseconds) are backtracked, and the call stack information at the time of each state change is extracted. Based on the top function of the call stack of the state change (i.e., the source function that most directly triggers the state change), it is determined whether the top function of the call stack is defined within the scope of "the currently rendering component" or "any ancestor component of the currently rendering component". If the top function of the call stack is defined within the scope of "the currently rendering component" or "any ancestor component of the currently rendering component", then a causal relationship between the state change and the current component rendering is confirmed. A triggering causal edge (trigger edge) with the current timing mark can be established in the runtime performance causal graph, pointing from the state change node to the current component node. For state changes triggered by user interaction events, a driving causal edge (driving edge) can be established in the runtime performance causal graph, pointing from the user interaction event node to the corresponding state change node. For scenarios where parent component rendering leads to child component rendering, rendering call edges can be established in the runtime performance causal graph. As the front-end application continues to run, the event stream of the front-end application can be continuously collected, and the nodes and weighted directed edges of the runtime performance causal graph can be dynamically accumulated, updated, and expanded. Each weighted directed edge has quantitative attributes such as the cumulative number of historical triggers and the cumulative performance overhead, forming a complete runtime performance causal graph of the front-end application, including component instances, reactive state nodes, user interaction event nodes, and directed edges including trigger edges, driving edges, and rendering call edges.

[0045] In one embodiment, it can be determined whether the source function of the state change originates from the code scope of the current rendering component and its ancestor components. This allows for the determination of whether there is a causal relationship between the state change and the current component's rendering. This filtering based on call stack scope attribution can accurately identify the state change that truly drives the current component's re-rendering among multiple concurrent state changes. The proximity time window backtracking algorithm, based on the front-end runtime characteristic that "cause must precede effect, and causal time is adjacent in a single event loop," achieves a deterministic and automated causal relationship from state to component rendering, without requiring any manual instrumentation from the developer.

[0046] In one embodiment, a runtime performance causal graph can be automatically constructed based on the deterministic nature of the temporal correlations during the front-end application runtime, using a causal association algorithm. By non-intrusive and high-precision collection of the temporal event stream of the front-end application through compile-time instrumentation and runtime proxy, and employing a proximity time window backtracking algorithm combined with call stack analysis, a deterministic and traceable causal relationship model from "responsive state changes" to "component re-rendering triggered by them" can be automatically and dynamically established during the front-end application runtime without any code annotations or developer configuration. This overcomes the limitation of related technologies that can only provide post-event statistical correlations and cannot determine causality in real time.

[0047] Step 202: During the runtime of the front-end application, identify the hotspot paths of the runtime performance causal graph based on the runtime performance causal graph of the front-end application.

[0048] In one embodiment, during the runtime of the front-end application, causal transmission paths can be identified based on the runtime performance causal graph of the front-end application; an improved graph analysis algorithm is used to calculate the total performance overhead ratio of the causal transmission paths based on the nodes, directed edges, and quantization attributes of the directed edges in the runtime performance causal graph; and causal transmission paths with a total performance overhead ratio greater than a preset threshold are identified as hotspot paths in the runtime performance causal graph of the front-end application.

[0049] In one embodiment, during the runtime of the front-end application, an improved graph analysis algorithm can be used to calculate the total performance cost of each causal transmission path in the runtime performance causal graph based on the nodes, directed edges, and quantization attributes of the directed edges. Based on the total performance cost of each causal transmission path and the total performance cost of the front-end application, the proportion of total performance cost of each causal transmission path can be calculated. Based on the proportion of total performance cost of each causal transmission path, causal transmission paths (hot spots) whose proportion of total performance cost of the front-end application runtime is greater than a preset proportion threshold can be identified, and the causal transmission path with the largest proportion of total performance cost of the front-end application runtime (the key causal chain that causes the largest global performance cost of the front-end application runtime) can be identified. The total performance cost of a causal transmission path characterizes the importance of the causal transmission path. The importance of the causal transmission path includes not only the importance of the nodes in the causal transmission path (the number of directed edges pointing to the nodes, i.e., the frequency at which the nodes are triggered), but also the quantization attribute of the directed edges pointing to the nodes in the causal transmission path (cumulative rendering overhead, including the cumulative number of historical triggers and cumulative performance overhead). In other words, the total performance cost of a causal transmission path includes the frequency at which the nodes in the causal transmission path are triggered and the quantization attribute of the directed edges pointing to the nodes in the causal transmission path.

[0050] In one embodiment, a weighted PageRank algorithm can be used during the runtime of the front-end application to calculate the total performance cost of each causal path in the runtime performance causal graph based on the nodes, directed edges, and quantification attributes of the directed edges. The total performance cost of the causal path includes the frequency of node triggering in the causal path, the cumulative historical trigger count of the directed edges pointing to the nodes, and the cumulative performance cost. For example, the chain from the intervalTimer event to the lastUpdated state change and then to the rendering of the three chart components ChartA, ChartB, and ChartC (causal path) accounts for 72% of the total page rendering cost, which is the largest. This chain is considered the highest priority critical causal chain and is also a hot path where the total performance cost exceeds a preset threshold.

[0051] In one embodiment, a weighted PageRank algorithm is used to comprehensively evaluate the triggering frequency of each node and the cumulative performance overhead weights carried by the directed edges pointing to each node (e.g., cumulative historical trigger counts and cumulative performance overhead) based on the runtime performance causal graph, in order to locate the causal transmission paths that have the most significant impact on global performance, thereby guiding attention to the bottleneck sources with the most optimization value.

[0052] Step 203: Based on the predefined anti-pattern graph of the front-end application, perform subgraph matching between the runtime performance cause-effect graph and the predefined anti-pattern graph to identify the anti-pattern of the front-end application.

[0053] In one embodiment, typical bad design patterns (anti-patterns) that repeatedly occur in front-end application development and lead to performance degradation or resource waste can be abstracted into identifiable specific subgraph topologies, which are predefined as anti-pattern graphs of the front-end application. Through a built-in extensible graph pattern recognition rule library, a subgraph matching algorithm is used to match the runtime performance causal graph with the predefined anti-pattern graph based on the front-end application's predefined anti-pattern graph and the front-end application's runtime performance causal graph, thereby identifying the anti-patterns of the front-end application. Anti-patterns include unrelated state lifting anti-patterns and / or inline function waterfall anti-patterns.

[0054] In one embodiment, the irrelevant state promotion anti-pattern is characterized by a graph structure where a state node has numerous trigger edges pointing to multiple component nodes, but these component nodes do not actually consume the state's value, leading to unnecessary changes to the state causing a large amount of invalid rendering. For example, a state node is identified with numerous trigger edges pointing to multiple component nodes, but the rendering output of these components (based on virtual DOM or props analysis) does not actually depend on (consume) the state's value.

[0055] In one embodiment, the inline function waterfall anti-pattern is characterized by a graph structure where the parent component's rendering node generates a new callback function object and passes it as a prop to the child component, triggering a cascading chain where the child component frequently re-renders due to unequal prop references. For example, it identifies a chain where the parent component creates a new callback function (e.g., an event handler) within its rendering function and passes it as a prop to the child component, causing frequent re-renders in the child component even if the parent component's other states remain unchanged due to unequal prop references.

[0056] Step 204: Based on the hotspot paths in the runtime performance cause-effect graph and the anti-patterns of the front-end application, generate a visual diagnostic report for the front-end application. The visual diagnostic report includes highlighted hotspot paths, optimization suggestions, quantitative prediction metrics for the optimization suggestions, and entry points for verifying the optimization suggestions.

[0057] In one embodiment, optimization suggestions corresponding to anti-patterns can be generated based on the anti-patterns observed during the runtime of the front-end application. Through data extraction, real runtime data of the front-end application components over a set time period is extracted from the historical records of the runtime performance causal graph of the front-end application; simulated runtime data of the component over the set time period after adopting the optimization suggestions is simulated; and based on the real runtime data and the simulated runtime data, a quantitative prediction index for the optimization suggestions and the confidence level of the quantitative prediction index are calculated.

[0058] For example, for the optimization suggestion corresponding to an anti-pattern in a front-end application ("It is recommended to use React.memo for the ExpensiveChart component"), a lightweight simulation can be used to extract the collection of all props objects and their specific values ​​received during the N most recent renderings of the ExpensiveChart component from the historical record of the front-end application's runtime performance causal graph. The behavior of React.memo is simulated in memory, performing a deep comparison of the props sequence from the N renderings of the ExpensiveChart component; determining which adjacent renderings would be skipped if the ExpensiveChart component used React.memo due to equality in either shallow or deep prop comparisons. The proportion of renders that can be blocked out of the total number of renders is statistically analyzed. The average time and historical total time of blocked renders are obtained from the runtime performance causal graph. A quantitative prediction metric for the optimization suggestion and the confidence level of the quantitative prediction metric are generated. For example, a quantitative prediction metric is generated that "if the component ExpensiveChart uses React.memo, it can reduce repeated renders by about 85%, and the total rendering time of the component's subtree is expected to be reduced by 70%", and the confidence level of the quantitative prediction metric is calculated based on the variance of historical data.

[0059] In one embodiment, through lightweight simulation calculation, based on historical behavior data recorded by the runtime performance causal graph of the front-end application, a data-driven quantitative prediction is made on the rendering path that can be blocked and the performance overhead reduced after implementing the optimization suggestion corresponding to a certain anti-pattern, so as to obtain the quantitative prediction index of the optimization suggestion and the confidence level of the quantitative prediction index. Once an anti-pattern in a front-end application is identified and optimization suggestions are provided, the process goes beyond mere qualitative description. Instead, it extracts real runtime data from the application's runtime performance causal graph history, including the props set received by the component during recent rendering and rendering time. It then simulates the behavior after the optimization suggestion takes effect in memory (e.g., simulating React.memo's deep comparison of the prop sequence to determine which renderings can be skipped). This allows for precise calculation of quantitative predictive metrics such as the percentage of renderings that can be prevented, the expected saving in rendering time, and the confidence level of these metrics. A predictive report, including the quantitative predictive metrics and their confidence levels, is generated, providing quantifiable expected benefits. This replaces vague judgments based on experience with objective data, directly answering the question, "How much performance can be improved by implementing the optimization suggestion?" This reduces the decision-making risk and trial-and-error costs of front-end application performance optimization, transforming it from relying on personal experience to data-driven engineering decisions.

[0060] In one embodiment, a visual diagnostic report for the front-end application can be generated based on the hotspot paths of the runtime performance causal graph and the anti-patterns of the front-end application. The visual diagnostic report may include hotspot paths highlighted using an interactive causal graph visualization view, actionable optimization suggestions including code modification examples, quantitative prediction metrics and confidence levels of the optimization suggestions displayed through quantitative prediction cards, and a verification operation entry point for the optimization suggestions that can be launched in a sandbox with one click.

[0061] In one embodiment, a quantitative prediction card can be used to display quantitative prediction metrics that can directly measure the expected effect of optimization suggestions, as well as the confidence level of the quantitative prediction metrics calculated based on the variance of historical data. The quantitative prediction card can intuitively display the specific expected benefits of the front-end application after implementing the optimization suggestions. Quantitative prediction metrics may include the proportion of renders that can be blocked out of the total number of renders (i.e., the rate of reduction in invalid renders or the rate of reduction in duplicate renders), the expected reduction in rendering time (or the percentage reduction in the total rendering time of component subtrees), and the expected increase in frame rate (FPS).

[0062] In one embodiment, the visual diagnostic report can be a structured, data-driven, quantitative decision support report. It not only includes the location and natural language description of performance bottlenecks, but also provides predictive quantitative indicators based on runtime performance causal graph calculations, as well as the confidence level of these predictive quantitative indicators. The visual diagnostic report can clearly provide the quantitative expectation of adopting optimization suggestions (e.g., using React.memo on component X is expected to reduce meaningless rendering by 85% ± 5%, and is expected to reduce the rendering time of this subtree by 70%). The visual diagnostic report can be compared side-by-side with empirical data generated from subsequent sandbox replay verification, forming a complete "prediction-empirical" decision-making loop, providing a high-confidence decision basis for front-end application performance optimization.

[0063] In one embodiment, based on the runtime performance causal graph of the front-end application, the predictive quantification index of the optimization suggestions and the confidence level of the predictive quantification index are quantified. Utilizing the rich structural information and historical behavioral statistics contained in the constructed runtime performance causal graph of the front-end application, lightweight, historical data-based simulation calculations and quantitative predictions are performed on the rendering paths that can be blocked and the performance overhead reduced after implementing the optimization suggestions. This achieves a fundamental leap from providing general qualitative suggestions to providing precise quantitative decision-making basis.

[0064] Step 205: Verify the optimization suggestions through the verification operation entry point in the optimization suggestions by performing sandbox replay.

[0065] In one embodiment, sandbox replay verification is a secure verification method that provides empirical support for optimization recommendations. Sandbox replay verification automatically deploys the front-end application code in a fully isolated containerized environment, replays representative, anonymized user interaction sequences pre-recorded in a production or pre-production environment, and uses the same probes to precisely collect performance metrics such as render count, component latency, memory usage, and frame rate (FPS) during the replay process. Sandbox replay verification can objectively and repeatably verify the actual performance differences resulting from optimization recommendations based on visual diagnostic reports.

[0066] In one embodiment, the sandbox verification of optimization suggestions can be initiated with a single click through the verification operation entry point of the visual diagnostic report. Based on Docker container technology, the current code repository is cloned, dependencies are installed, and the sandbox environment is built with a single click through the verification operation entry point, creating an application runtime sandbox completely isolated from the host environment. The host environment is the runtime and deployment environment of the front-end application, i.e., the actual runtime environment (e.g., local machine, test server, or pre-release server) where the front-end application is developed, tested, or pre-released daily. The sandbox environment is a fully isolated copy of the application created within a container after the code repository is cloned, dependencies are installed, and the build is completed with a single click using Docker container technology. The sandbox environment is isolated from the host environment and does not interfere with it, thus ensuring that replaying and verifying optimization suggestions in the sandbox will not pollute or affect the runtime and deployment environments of the front-end application.

[0067] In one embodiment, a headless browser (e.g., Puppeteer) can be launched in the production or pre-release environment of the front-end application using a sandbox verification replay engine. This browser loads both the front-end application before and after optimization suggestions, and utilizes automated, lightweight scripts to accurately and reliably reproduce the recorded, anonymized user interaction event sequences with minimal overhead, ensuring operational consistency for each verification. The anonymized user interaction event sequences are recorded in structured data format, showing user clicks, inputs, scrolling, and their corresponding page element selectors and values. This ensures accurate reproduction of real user behavior during subsequent sandbox replays, and data security and privacy compliance are guaranteed through anonymization.

[0068] In one embodiment, during the replay of the sandbox verification, the same data acquisition probe is injected to synchronously collect key performance indicators, automatically align the timing, and generate comparison charts of the front-end application before and after the optimization suggestions are adopted. For example, a comparison chart of the "rendering times over time", an "FPS curve overlay", and a "memory usage comparison chart" of the front-end application before and after the optimization suggestions are adopted.

[0069] In one embodiment, the source code of the front-end application is modified based on optimization suggestions through a visual diagnostic report. The modified front-end application does not require deployment and can be directly triggered for sandbox verification through the verification operation entry in the visual diagnostic report. By automatically running at least two replays (using the front-end application before optimization with the suggestions as the baseline and the front-end application after optimization with the suggestions as the experimental group), empirical data of the front-end application before optimization with the suggestions and quantitative prediction indicators of the front-end application after optimization with the suggestions are quantitatively generated. Based on the high-confidence empirical data and quantitative prediction indicators, a performance optimization decision for the front-end application is made, realizing a complete engineering closed loop of "analysis-prediction-modification-verification-decision" for the performance optimization of the front-end application.

[0070] In one embodiment, a closed-loop empirical verification process, serving human decision-making through sandbox replay without any automated code modification, is employed. This process records real user interaction sequences and performs precise, automated replay within a completely isolated, containerized sandbox environment. Performance metrics are collected using a consistent measurement system, providing low-cost, fast, and reliable performance comparison empirical data for front-end application performance optimization. The comparison empirical data, combined with quantitative prediction cards, constitutes a complete and highly reliable "prediction-empirical" decision support closed loop.

[0071] The following is a comparative experiment based on a large React data visualization dashboard application containing 47 components and 12 global state nodes. The experiment compares the performance optimization method of the front-end application in this application embodiment with a first performance optimization method using a first optimization tool with related technologies (e.g., React DevTools Profiler) and a second performance optimization method using a second optimization tool with related technologies (e.g., Chrome Performance panel). The experimental task is to locate the root cause of "periodic stuttering of the page during timer execution".

[0072] The front-end application for the comparative experiment: a React data visualization and monitoring dashboard built with React 18 + Redux Toolkit, including ECharts chart components, table components, and timed refresh logic.

[0073] Hardware environment: Intel i7-12700H / 32GB RAM / Chrome 120.

[0074] Experimental Methods: The front-end application performance optimization method of this application embodiment, the first performance optimization method using a first optimization tool of related technology (e.g., React DevTools Profiler), and the second performance optimization method using a second optimization tool of related technology (e.g., Chrome Performance panel) were used to independently complete the same experimental task to locate the root cause of "periodic page stuttering during timer operation". The time consumed by the front-end application performance optimization method, the first performance optimization method, and the second performance optimization method of this application embodiment, which determined the root cause to be "lastUpdated global state updates every second, causing unrelated chart components to be cascaded and re-rendered", was recorded respectively.

[0075] The experimental results of the comparative experiment are shown in Table 1 below.

[0076] Table 1:

[0077] Based on experimental data from comparative experiments, the front-end application performance optimization method of this application embodiment improves root cause localization efficiency by approximately 12 times compared to React DevTools Profiler and approximately 16 times compared to the Chrome Performance panel. This front-end application performance optimization method automates the manual process of reasoning about causes and effects from flame diagrams into root cause localization based on the runtime performance causal graph of the front-end application, reducing root cause localization time from hours to minutes; quantitative prediction metrics eliminate decision blind spots due to uncertain optimization effects; sandbox replay verification compresses the verification cycle from days to minutes; the synergy of these three elements reduces the overall optimization decision cycle for front-end application performance optimization from days to approximately 15 minutes, achieving an order-of-magnitude efficiency improvement.

[0078] The following uses a specific scenario to illustrate the workflow and effect of the front-end application performance optimization method of this application embodiment.

[0079] Scenario: A large data visualization dashboard (front-end application) with multiple independent chart components (ChartA, ChartB, and ChartC) and a status indicator at the bottom of the page that displays the last updated time (LastUpdatedIndicator).

[0080] Key variable and component definitions: DashboardApp: The top-level root component, responsible for composing and laying out all child components. Internally, it subscribes to the global state lastUpdated through Redux's useSelectorHook. When the global state changes, DashboardApp will re-render, which in turn triggers all child components to re-render.

[0081] `lastUpdated`: A global reactive state node (the `state.ui.lastUpdated` field in the Redux Store), a string of type ISO 8601 (e.g., "2026-06-08T14:30:00Z"). This state node is updated every 1000ms (milliseconds) by the `setInterval` timer and is used solely to drive the display of the `LastUpdatedIndicator` component.

[0082] LastUpdatedIndicator: A lightweight display component that only consumes the value of the lastUpdated state and renders a line of text at the bottom of the page (e.g., Last Updated: 14:30:00), with a single render taking approximately 0.3ms.

[0083] ChartA, ChartB, and ChartC are three independent ECharts chart components, each rendering different dimensions of business data. ChartA, ChartB, and ChartC do not read or depend on the values ​​of the lastUpdated state. However, as child components of DashboardApp, they are triggered by React's default rendering mechanism when the parent component re-renders due to a change in lastUpdated. Each chart component (ChartA, ChartB, and ChartC) takes approximately 35ms-50ms to render (including ECharts instance updates).

[0084] intervalTimer: A setInterval timer reference that performs a state update every 1000ms and is the source of the performance bottleneck in this scenario.

[0085] The "trigger edge" property is defined as follows: Each trigger edge in the runtime performance causal graph that points from lastUpdated to ChartX carries the following quantization property: {triggerCount: N, avgRenderCost: Mms, totalCost: N×Mms}, where N is the number of historical triggers and Mms is the average rendering time of the corresponding component.

[0086] S1 collects event streams and builds a runtime performance causal graph.

[0087] S1.1, inject compile-time instrumentation.

[0088] The Babel plugin automatically injects profilerStart('DashboardApp') and profilerEnd('DashboardApp') calls before and after the rendering function of the DashboardApp component, injects state reading tracking code at the useSelector read point, and injects timer event tracking code at the setInterval callback point.

[0089] S1.2, When the large data visualization dashboard is running, the event stream of the large data visualization dashboard is collected.

[0090] Collect the state change stream and detect that the lastUpdated state is updated every 1000ms. Each update record is: {stateId: "state.ui.lastUpdated", oldValue: "2026-06-08T14:30:00Z", newValue:"2026-06-08T14:30:01Z", timestamp: 1717848601000us, callStack: ["setIntervalcallback", "dispatch", "updateTimestamp"]}.

[0091] Collect the component rendering stream and detect that DashboardApp and all its child components are triggered to render in the same event loop. Record: {componentId: "ChartA", renderStart: 1717848601002, renderEnd:1717848601040, vdomNodes: 1, triggerReason: "parent re-render"}.

[0092] Collect user interaction streams and record user actions such as clicking chart filter buttons.

[0093] S1.3 executes the causal association algorithm to construct the runtime performance causal graph of the large data visualization dashboard.

[0094] When the ChartA rendering completion event arrives, a 5ms time window is traced back, revealing the lastUpdated state change event. Further analysis of the call stack confirms that the DashboardApp component function is included in the ChartA rendering initiation stack, and the change in lastUpdated is precisely the reason for triggering the re-rendering of DashboardApp. Therefore, a trigger edge is established in the runtime performance cause-effect graph, pointing from the lastUpdated state node to the ChartA component node, with accompanying time sequence markers and quantitative attributes such as rendering overhead. The same process is executed for ChartB and ChartC, forming a complete runtime performance cause-effect graph for the large data visualization dashboard.

[0095] S1.4, Visualize the runtime performance cause-effect graph.

[0096] The runtime performance cause-effect graph can be presented in an interactive view, where the lastUpdated node is highlighted in red as a hotspot state, and the three triggering edges emanating from it are highlighted with thick lines. The edge labels indicate "Trigger Frequency: 1Hz" and the cumulative rendering overhead is "120ms / s". Through the intuitive display of the interactive view, it can be seen that "an unrelated timer state is driving all graph components to perform invalid rendering at a frequency of 1 time per second".

[0097] S2 analyzes and generates visual diagnostic reports for large data visualization dashboards.

[0098] S2.1 identifies anti-patterns in large data visualization dashboards.

[0099] Performing subgraph matching on the runtime performance cause-effect graph revealed that the lastUpdated state node has three trigger edges pointing to ChartA, ChartB, and ChartC respectively. However, analysis of the useSelector subscription list and props dependencies of these three components confirmed that none of them consumed the value of lastUpdated. This structure precisely matches irrelevant states, thus improving the anti-pattern.

[0100] S2.2, Identify hotspot paths.

[0101] An improved weighted PageRank algorithm is used to identify the causal transmission path from the intervalTimer event -> lastUpdated state change -> ChartA / B / C rendering as the critical causal chain (hot spot path). The total performance cost of this causal transmission path accounts for 72% of the total rendering cost of the current page, and it is the highest priority optimization path.

[0102] S2.3, simulate and calculate the quantitative returns.

[0103] Perform lightweight simulation calculations to extract the rendering events of ChartA, ChartB, and ChartC within the last 60 seconds from the historical records of the runtime performance causal graph, for a total of 180 times (60 times each / 60 seconds, i.e., once per second for each).

[0104] Simulate the effect of "moving the lastUpdated state inside the LastUpdatedIndicator component": DashboardApp no ​​longer subscribes to lastUpdated, so it will no longer re-render due to timer updates, and the rendering of ChartA, ChartB, and ChartC triggered by timers will be completely eliminated.

[0105] Calculate the quantitative prediction metrics. Invalid rendering reduction rate = 180 / 180 = 100% (relative to timer-triggered scenarios); Expected reduction in rendering time = 180 times × average 40ms / time = 7200ms, which means a reduction of approximately 120ms of rendering CPU time per second.

[0106] S2.4 generates and outputs visual diagnostic reports for large data visualization dashboards.

[0107] Automatically generate and output a visualization diagnostic report for a large data visualization dashboard. The visualization diagnostic report includes the hotspot path from lastUpdated to ChartA / B / C highlighted through an interactive cause-effect graph view, optimization suggestions to "move the lastUpdated state and update logic down to the LastUpdatedIndicator component", a quantitative prediction card with the optimization suggestion that "the invalid rendering frequency of ChartA / B / C triggered by timers is expected to be reduced from 1Hz to 0Hz, reducing the rendering CPU time occupied by about 120ms per second, and the FPS is expected to increase from 45 to 60 (an improvement of 33%), with a confidence level of 95%", and a "one-click start sandbox verification" button.

[0108] S3, Verification and Decision.

[0109] S3.1 Optimize the large data visualization dashboard based on optimization suggestions.

[0110] Based on the optimization suggestions in the visualization diagnostic report, the code of a large data visualization dashboard can be optimized by removing `useSelector(state => state.ui.lastUpdated)` and `dispatch(updateTimestamp())` from the `DashboardApp` component and moving them down to the `LastUpdatedIndicator` component. This optimization process does not require an understanding of the underlying rendering mechanism; simply follow the code modification examples provided in the optimization suggestions.

[0111] S3.2, triggers sandbox verification.

[0112] Clicking the "One-click Start Sandbox Verification" button will automatically execute the following process: Cloning and building: The Docker container automatically pulls the code before optimization (baseline version) and the code after optimization (experimental version), and executes npm install and npm run build respectively to create two completely isolated application running sandboxes.

[0113] Playback of the recorded sequence: The headless browser powered by Puppeteer loads the application in two sandboxes and precisely replays a pre-recorded anonymized user action sequence (15 events, approximately 30 seconds long) that includes complex interactions such as "clicking the chart filter button -> entering search keywords -> drilling down to view details".

[0114] Synchronous collection metrics: During playback, the same probe automatically collects performance metrics such as the number of renderings, component time consumption, memory changes, and FPS.

[0115] S3.3 Output an empirical comparison report.

[0116] Automatically align timings and generate comparison data before and after optimization. The comparison data can include comparisons of rendering times, FPS, and memory usage.

[0117] Rendering count comparison: Before optimization, ChartA / B / C were each rendered once per second (3 times / s in total); after optimization, at the lastUpdated update time, the chart area rendering count monitoring curve became a flat zero line, and the rendering count was reduced by 100%.

[0118] FPS Comparison: Before optimization, the FPS fluctuated between 35-50 (average 45 FPS) when users scrolled through the charts; after optimization, the FPS stabilized at 58-60 (average 59.5 FPS), an improvement of approximately 33%.

[0119] Memory comparison: After optimization, due to the elimination of temporary objects generated by high-frequency invalid rendering, the GC (Garbage Collection, automatic memory management mechanism) pause frequency is reduced by about 40%.

[0120] S3.4, Prediction-Empirical Closed Loop.

[0121] The empirical comparison report is presented alongside the predicted quantitative indicators: the prediction is "100% reduction in rendering," and the empirical result is "100% reduction in rendering"; the prediction is "33% increase in FPS," and the empirical result is "33% increase in FPS." The predictions and empirical results are highly consistent, validating the effectiveness of the optimization recommendations. Based on this solid, minute-level evidence chain of both predictions and empirical data, the front-end application was optimized according to the recommendations. The entire process, from problem identification to optimization completion, took only about 15 minutes.

[0122] The performance optimization method for front-end applications in this application constructs a runtime performance causal graph of the front-end application based on the runtime temporal correlation. It does not depend on the implementation details of any specific front-end framework. As long as the target framework follows the "state-driven view" reactive paradigm, it can be applied by adapting the corresponding data collection probe. This performance optimization method has excellent technical versatility and framework independence, and can be widely adapted to mainstream and emerging frameworks such as React, Vue, and SolidJS. It has a long lifespan and broad applicability. This performance optimization method fundamentally changes the paradigm of front-end application performance optimization. Developers no longer need to perform time-consuming reasoning through vast logs and jumping flame graphs like detectives. Instead, they directly face a clear, visual diagnostic report and make decisions based on data-driven predictions and minute-level empirical comparison reports. It shortens the root cause localization and optimization decision verification cycle of front-end application performance bottlenecks from hours or even days to minutes, order-of-magnitude improving the efficiency of front-end application performance diagnosis and optimization decision-making. The combination of quantitative prediction and empirical verification provides strong objective evidence to support each optimization suggestion, greatly enhancing its credibility. Developers no longer need to blindly trust tools or argue about the necessity of optimization; instead, they can reach a consensus based on solid, visual diagnostic reports. This significantly reduces the cognitive resistance and coordination costs of promoting high-performance code practices within R&D teams.

[0123] The front-end application performance optimization method of this application systematically solves the three major problems of front-end application performance optimization in related technologies through a complete, data-driven toolchain: "lack of deterministic causal relationships at the diagnostic level, lack of quantitative data basis at the decision-making level, and high time and operation costs at the verification level." It transforms front-end application performance optimization from a craft that relies on personal experience into an engineering decision based on data and evidence.

[0124] The performance optimization method for front-end applications in this application constructs a runtime performance causal graph of the front-end application. It presents the complex influence relationship between dynamic "state changes" and "component rendering" hidden under the front-end application code in real time in an intuitive and deterministic graph structure, thus overcoming the core pain point of "difficulty in finding the root cause of performance bottlenecks" and realizing the deterministic root cause visualization and tracing of the performance bottleneck of the front-end application.

[0125] The performance optimization method for front-end applications in this application includes a visual diagnostic report comprising optimization suggestions and predictive quantitative indicators of those suggestions, qualitative suggestions that surpass related technologies, and a runtime performance causal graph of the front-end application and the historical behavioral data contained therein. Through lightweight simulation calculations, a quantitative predictive indicator (e.g., the expected reduction in rendering percentage and time) is attached to each specific optimization suggestion. Objective data replaces vague subjective experience judgments, reducing decision-making risks and providing data-driven quantitative decision support for front-end application performance optimization.

[0126] The performance optimization method for front-end applications in this application establishes a low-cost, high-reliability empirical verification loop through sandbox playback verification, providing a one-click, low-cost tool for verifying optimization effects. It achieves objective evaluation of the actual effects of optimization suggestions within minutes, shortening the "hypothesis-verification" cycle from days to minutes, significantly reducing trial-and-error costs, and providing reliable empirical feedback for quantitative prediction, thus forming a decision-making closed loop.

[0127] The front-end application performance optimization method of this application embodiment is inherently framework-independent and low-intrusive, enabling it to be deployed at scale to front-end application development across various industries in the form of a standardized toolchain, thus promoting cross-industry large-scale application deployment. By integrating the front-end application performance optimization method of this application embodiment into the enterprise R&D process in the form of CI / CD plugins, development environment middleware, or cloud SaaS services, it is possible to achieve large-scale promotion from personal tools to team standard practices, making front-end application performance optimization no longer the exclusive skill of a few senior developers, but a replicable and quantifiable engineering capability.

[0128] Online trading platforms of financial institutions such as banks and securities firms in the financial industry have extremely high requirements for page response speed and smooth interaction (e.g., in scenarios where market data is refreshed in real time). The front-end application performance optimization method in this application embodiment can accurately locate unnecessary cascading rendering caused by high-frequency data push, ensuring the real-time performance and stability of trading operations.

[0129] During large-scale promotional events in the e-commerce industry, the front-end performance of core pages such as product detail pages and shopping carts directly impacts user conversion rates. The front-end application performance optimization method described in this application can help e-commerce teams quickly identify rendering bottlenecks caused by complex promotional state management and complete targeted front-end application performance optimization before peak event times.

[0130] SaaS (Software as a Service) and enterprise-level web applications such as CRM (Customer Relationship Management), ERP (Enterprise Resource Planning), and project management typically involve complex form interactions and large-scale table rendering. The front-end application performance optimization method in this application can systematically identify invalid rendering modes caused by excessive global state enhancement, reducing the perceived lag for enterprise users when operating complex interfaces.

[0131] Data visualization and BI platform operation and maintenance monitoring dashboards and data analysis dashboards often suffer from performance bottlenecks due to the interconnected refresh of multiple charts. The performance optimization method for the front-end application in this application embodiment can intuitively reveal the root cause of "a timer state driving the re-rendering of all charts" through runtime performance cause-effect graphs, assisting in precise state scope isolation optimization.

[0132] Online education and live streaming platforms feature real-time interactive whiteboards and bullet screens, with frequent UI updates and concurrent user interactions. The performance optimization method for front-end applications in this application can help pinpoint the waterfall-style re-rendering problem of sub-components caused by inline creation of event handling functions.

[0133] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a front-end application performance optimization system, electronic device, and corresponding embodiments.

[0134] Figure 3 This is a schematic diagram of the structure of a front-end application performance optimization system shown in an embodiment of this application.

[0135] See Figure 3 A performance optimization system 300 for a front-end application includes a first identification unit 301, a second identification unit 302, and a report generation unit 303.

[0136] The first identification unit 301 is used to identify hotspot paths in the runtime performance causal graph of the front-end application during runtime.

[0137] In one embodiment, when the front-end application is running, the first identification unit 301 can identify each causal transmission path of the runtime performance causal graph based on the runtime performance causal graph of the front-end application; and determine the hotspot path of the runtime performance causal graph based on the total performance overhead of each causal transmission path and the total performance overhead of the front-end application.

[0138] The second identification unit 302 is used to identify the anti-pattern of the front-end application based on the predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph of the front-end application.

[0139] In one embodiment, the second identification unit 302 can identify the anti-pattern of the front-end application based on the predefined anti-pattern graph of the front-end application and the runtime performance causal graph of the front-end application during the front-end application runtime.

[0140] The report generation unit 303 is used to generate a visual diagnostic report for the front-end application based on the hotspot path identified by the first identification unit 301 and the anti-pattern identified by the second identification unit 302. The visual diagnostic report includes the highlighted hotspot path, optimization suggestions, quantitative prediction indicators of the optimization suggestions, and verification operation entry for the optimization suggestions.

[0141] In one embodiment, the report generation unit 303 can generate a visual diagnostic report for the front-end application based on the hotspot paths of the runtime performance causal graph and the anti-patterns of the front-end application. The visual diagnostic report may include hotspot paths highlighted using an interactive causal graph visualization view, actionable optimization suggestions including code modification examples, quantitative prediction indicators and confidence levels of the optimization suggestions displayed through quantitative prediction cards, and a verification operation entry for the optimization suggestions that can be launched with one click in the sandbox.

[0142] The technical solution of this application embodiment identifies hotspot paths and anti-patterns in the runtime performance causal graph of the front-end application. Based on these hotspot paths and anti-patterns, it diagnoses the performance of the front-end application, elevating the root cause localization of front-end application performance from experience-based, hourly or even day-level inference and investigation to data-driven, minute-level, intuitively traceable, and visual performance diagnosis. Based on the hotspot paths and anti-patterns in the runtime performance causal graph, it generates optimization suggestions and predictive quantitative indicators for these suggestions, elevating optimization decisions from those based on fuzzy experience and qualitative guesswork to rational decisions based on quantitative predictive data. It also provides a one-click verification operation entry point for these optimization decisions. This front-end application performance optimization method, based on data-driven decision-making, achieves a closed loop of causal tracing, quantitative decision-making, and verification assistance for front-end application performance optimization, thereby improving the efficiency and accuracy of front-end application performance optimization.

[0143] Figure 4 This is another structural schematic diagram of the performance optimization system for front-end applications shown in the embodiments of this application.

[0144] See Figure 4 A performance optimization system 300 for a front-end application includes a map generation unit 401, a first identification unit 301, a second identification unit 302, a report generation unit 303, and a verification unit 404.

[0145] The graph generation unit 401 is used to generate a runtime performance causal graph of the front-end application based on the state change flow, component rendering flow, user interaction flow, and causal association algorithm of the front-end application.

[0146] The first identification unit 301 is used to identify the causal transmission path of the front-end application during runtime based on the runtime performance causal graph of the front-end application; using an improved graph analysis algorithm, it calculates the total performance overhead ratio of the causal transmission path based on the nodes, directed edges, and quantization attributes of the directed edges in the runtime performance causal graph; and determines the causal transmission path with a total performance overhead ratio greater than a preset threshold as the hotspot path of the runtime performance causal graph of the front-end application.

[0147] The second identification unit 302 is used to identify the anti-patterns of the front-end application by using a built-in extensible graph pattern recognition rule library and a subgraph matching algorithm, based on the predefined anti-pattern graph of the front-end application and the runtime performance causal graph of the front-end application, by performing subgraph matching between the runtime performance causal graph and the predefined anti-pattern graph, and the anti-patterns include unrelated state lifting anti-patterns and / or inline function waterfall anti-patterns.

[0148] The report generation unit 303 is used to generate a visual diagnostic report for the front-end application based on the hotspot paths of the runtime performance causal graph and the anti-patterns of the front-end application. The visual diagnostic report may include hotspot paths highlighted using an interactive causal graph visualization view, actionable optimization suggestions including code modification examples, quantitative prediction indicators and confidence levels of the optimization suggestions displayed through quantitative prediction cards, and a verification operation entry for the optimization suggestions that can be launched in a sandbox with one click.

[0149] The verification unit 404 is used as the verification operation entry point for the visual diagnostic report generated by the report generation unit 303, and performs sandbox playback verification of the optimization suggestions in the visual diagnostic report.

[0150] Regarding the system in the above embodiments, the specific manner in which each unit performs operations has been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0151] Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0152] See Figure 5 The electronic device 1000 includes a memory 1010 and a processor 1020.

[0153] The processor 1020 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. Memory 1010 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 1020 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 1010 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 1010 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0154] The memory 1010 stores executable code, which, when processed by the processor 1020, can cause the processor 1020 to execute part or all of the methods described above.

[0155] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0156] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) that, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0157] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, implement the method described above.

[0158] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.< / profiler>

Claims

1. A performance optimization method for a front-end application, characterized in that, include: During the runtime of the front-end application, identify the hotspot paths in the runtime performance causal graph of the front-end application; Based on the predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph, identify the anti-pattern of the front-end application; Based on the hotspot path and the anti-pattern, a visual diagnostic report of the front-end application is generated. The visual diagnostic report includes the highlighted hotspot path, optimization suggestions, quantitative prediction indicators of the optimization suggestions, and a verification operation entry point for the optimization suggestions.

2. The method according to claim 1, characterized in that, The method further includes: The optimization suggestions are verified through a sandbox replay via the verification operation entry point.

3. The method according to claim 1, characterized in that, The steps for generating the quantitative prediction indicators for the optimization suggestions include: By extracting data, the actual running data of the front-end application components during a set time period is extracted from the historical records of the runtime performance causal graph. The simulation data of the component during the set time period after adopting the optimization suggestions is used. Based on the actual operating data and the simulated operating data, calculate the quantitative prediction index of the optimization suggestion and the confidence level of the quantitative prediction index.

4. The method according to claim 1, characterized in that, The steps for generating the runtime performance cause-effect graph include: Compile-time instrumentation and runtime lightweight proxy are used to collect the state change flow, component rendering flow, and user interaction flow of the front-end application; Based on the state change flow, the component rendering flow, the user interaction flow, and the causal association algorithm, the runtime performance causal graph is generated. The nodes of the runtime performance causal graph include component instances, reactive state nodes, and user interaction events. The directed edges of the runtime performance causal graph include trigger edges, driving edges, and rendering call edges.

5. The method according to claim 4, characterized in that, The step of identifying hotspot paths in the runtime performance causal graph of the front-end application during runtime includes: Based on the runtime performance cause-effect graph, identify the causal transmission path during the runtime of the front-end application; An improved graph analysis algorithm is used to calculate the total performance overhead percentage of the causal propagation path based on the nodes, directed edges, and quantization attributes of the directed edges in the runtime performance causal graph. The causal transmission path that accounts for a percentage of total performance overhead greater than a preset percentage threshold is identified as the hotspot path in the runtime performance causal graph of the front-end application.

6. The method according to claim 1, characterized in that, The step of identifying anti-patterns in the front-end application based on the predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph includes: Based on the predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph, the runtime performance cause-effect graph is matched with the predefined anti-pattern graph to identify the anti-pattern of the front-end application. The anti-pattern includes the unrelated state lifting anti-pattern and / or the inline function waterfall anti-pattern.

7. A performance optimization system for front-end applications, characterized in that, include: The first identification unit is used to identify hotspot paths in the runtime performance causal graph of the front-end application during runtime. The second identification unit is used to identify the anti-pattern of the front-end application based on the predefined anti-pattern graph of the front-end application and the runtime performance cause-effect graph. The report generation unit is used to generate a visual diagnostic report of the front-end application based on the hotspot path identified by the first identification unit and the anti-pattern identified by the second identification unit. The visual diagnostic report includes the highlighted hotspot path, optimization suggestions, quantitative prediction indicators of the optimization suggestions, and a verification operation entry for the optimization suggestions.

8. The system according to claim 7, characterized in that, The system also includes: The verification unit is used as the verification operation entry point for the visual diagnostic report generated by the report generation unit, and performs sandbox playback verification of the optimization suggestions.

9. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, It stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-6.

Images