Method and terminal for automatically monitoring, analyzing and processing performance of front-end system

By automating monitoring and data integration and cleaning, combined with visualization analysis, the problem of low efficiency in manual testing in front-end performance monitoring has been solved, and the effect of quickly locating and optimizing performance bottlenecks has been achieved.

CN120872759APending Publication Date: 2025-10-31SHENZHEN COOCAA NETWORK TECH CO LTD
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202510957851.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-07-11
Publication Date
2025-10-31

AI Technical Summary

Technical Problem

Existing front-end performance monitoring methods rely on manual testing and log analysis, which are difficult to fully cover all scenarios and lack systematic data integration and analysis methods, resulting in low efficiency in locating and optimizing performance problems.

Method used

An automated monitoring method is adopted. By acquiring preset performance indicator parameters, open source tools such as Google Lighthouse, WebPageTest, and Sentry are used to monitor the front-end system in real time, integrate and clean the data, generate visual dashboards for analysis, and optimize indicators that do not meet the preset values.

Benefits of technology

It has achieved automation and intelligence in front-end performance monitoring, improved data analysis efficiency, quickly located performance bottlenecks, and enhanced the timeliness and accuracy of performance optimization.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120872759A_ABST
    Figure CN120872759A_ABST
Patent Text Reader

Abstract

The invention discloses a front-end system performance automatic monitoring analysis processing method and a terminal, and belongs to the technical field of Internet, and the method comprises the steps: monitoring a front-end system in real time according to preset performance index parameters, and capturing corresponding index data; performing integration, data format unified processing and data cleaning processing on the captured index data; according to a preset analysis demand, generating a corresponding visualized billboard diagram from each piece of processed index data; carrying out statistics and analysis on response time, resource loading time and user behavior conditions of each index data of the generated visual billboard graph, and generating an analysis result; and performing performance optimization on the index data which does not conform to a preset value in the generated analysis result, and outputting an optimization result. According to the method, the front-end system can be automatically monitored, counted and analyzed, and is displayed through a visual interface, so that problem positioning and targeted optimization are conveniently and quickly carried out, the improvement of system performance is facilitated, and convenience is provided for the use of a user.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of front-end performance monitoring technology, and in particular to a method, apparatus, server, and storage medium for automated monitoring, analysis, and processing of front-end system performance. Background Technology

[0002] In modern internet applications, front-end systems, as the direct carriers of user interaction, directly impact user experience and corporate image. With the rapid development of web technologies, enterprise websites and large-scale front-end systems have become crucial platforms for corporate presentation, product marketing, and service delivery. However, in actual operation, these front-end systems frequently face performance issues such as slow response times, long blank screen periods, and resource loading delays. These problems not only degrade user experience but can also lead to user churn and lost business opportunities.

[0003] Traditional front-end performance monitoring methods primarily rely on manual testing and log analysis, which have significant limitations. First, performance issues are often sporadic and difficult to reproduce, making it challenging for manual testing to comprehensively cover all scenarios. Second, existing monitoring tools acquire data that is scattered and inconsistently formatted, lacking effective integration and analysis methods. Third, the process of locating and optimizing performance issues lacks a systematic approach, making it difficult for developers to quickly and accurately pinpoint the root cause of problems.

[0004] Existing performance monitoring solutions typically only provide raw data and lack intelligent analysis capabilities. Developers need to spend a significant amount of time on data cleaning, format conversion, and visualization to obtain valuable performance analysis results. This inefficient workflow severely impacts the timeliness and effectiveness of performance optimization.

[0005] Therefore, existing technologies still need improvement and development. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a method, apparatus, server, and storage medium for automated monitoring, analysis, and processing of front-end system performance. This invention can automatically monitor, statistically analyze, and display the data through a visual interface, facilitating rapid problem localization and targeted optimization, thereby improving system performance and providing convenience for users. It has the advantages of improving performance monitoring efficiency, enabling intelligent data analysis, and quickly locating performance bottlenecks.

[0007] This application provides a method for automated monitoring, analysis, and processing of front-end system performance, the technical solution of which is as follows:

[0008] A method for automated monitoring, analysis, and processing of front-end system performance, comprising:

[0009] Obtain the preset performance metrics parameters that need to be monitored for the front-end system;

[0010] Based on preset performance index parameters, the front-end system is monitored and the corresponding index data is captured in real time.

[0011] The captured indicator data is integrated, the data format is standardized, and the data is cleaned.

[0012] The processed indicator data will be used to generate corresponding visualization dashboards based on the preset analysis requirements.

[0013] The system statistically analyzes and compiles data on various metrics, including response time, resource loading time, and user behavior, to generate analytical results.

[0014] The system optimizes the performance of indicators that do not meet the preset values ​​in the generated analysis results and outputs the optimization results.

[0015] The aforementioned automated monitoring and analysis method for front-end system performance includes, prior to the step of obtaining preset performance indicator parameters for front-end system performance monitoring:

[0016] Pre-configure the performance metrics parameters that need to be monitored for the front-end system.

[0017] The performance metrics include: initial load time, white screen time, document content load time, page resource load time, and resource load time.

[0018] The aforementioned method for automated monitoring, analysis, and processing of front-end system performance includes the following step: capturing corresponding indicator data of the front-end system in real time based on preset performance indicator parameters.

[0019] Select the specified open-source automated performance monitoring tools, including: Google Lighthouse open-source automation tool for improving webpage quality, WebPageTest website performance testing tool for testing webpage performance, and Sentry error tracing and performance monitoring platform for real-time monitoring of front-end application performance and errors;

[0020] By using the selected open-source automated performance monitoring tools, the corresponding indicator data of the front-end system can be captured in real time according to the preset performance indicator parameters.

[0021] The aforementioned method for automated monitoring, analysis, and processing of front-end system performance includes the following step: capturing corresponding indicator data of the front-end system in real time based on preset performance indicator parameters.

[0022] Use the browser's Performance API to obtain performance metrics, including:

[0023] White screen performance metric: The point in time when the page's visual appearance first changes;

[0024] Gray screen performance metrics: The time point at which any text, image, non-blank canvas, or vector graphic is first drawn.

[0025] Maximum content rendering performance metric: the relative time required to render the largest image or text block within the visible area;

[0026] First-input latency performance metrics: the time elapsed from the user's first interaction with the page until the browser responds to the interaction and is actually able to begin processing event handlers;

[0027] Cumulative layout offset performance metric: This measures the total score of all unexpected layout offsets that occur throughout the entire lifecycle of a webpage;

[0028] Static resource loading performance metrics: These metrics are used to obtain the static resources accessed during each load and to create analytical graphs of the collected static resources to identify the causes of excessively long static resource loading times.

[0029] The aforementioned method for automated monitoring, analysis, and processing of front-end system performance includes the following steps: integrating the captured indicator data, unifying the data format, and cleaning the data.

[0030] The captured data from various sources are integrated and combined.

[0031] The integrated indicator data will be formatted by converting the date and numerical data types to form indicator data in a unified format.

[0032] Handle missing values ​​for indicator data in a uniform format, check for missing values ​​in the data, and delete or fill them as needed;

[0033] Perform outlier handling on standardized indicator data, identifying and processing outliers in the data;

[0034] Perform duplicate value processing on indicator data in a uniform format, and find and delete duplicate records.

[0035] The aforementioned method for automated monitoring and analysis of front-end system performance includes the following step: generating corresponding visual dashboards from the processed indicator data according to preset analysis requirements.

[0036] When trend analysis is required, line charts are drawn using visualization methods based on the processed indicator data to show the trend of performance indicators over time.

[0037] When distribution analysis is required, histograms are plotted based on the processed index data to show the distribution of specific performance indicators.

[0038] When correlation analysis is required, a heat map is drawn based on the processed index data to show the correlation between different performance indicators.

[0039] When comparative analysis is required, use bar charts to compare performance metrics across different pages or time periods based on the processed metric data.

[0040] The aforementioned method for automated monitoring, analysis, and processing of front-end system performance includes the following steps: optimizing the performance of indicator data that does not meet preset values ​​in the generated analysis results and outputting the optimization results.

[0041] Each indicator data in the generated analysis results is compared with the corresponding preset value to determine whether each indicator data meets the range of its corresponding preset value.

[0042] The system optimizes the performance of indicator data in the generated analysis results to determine whether the indicator data meets the preset value range of the corresponding indicator, and outputs the optimization results.

[0043] An automated monitoring and analysis processing device for front-end system performance, wherein the device comprises:

[0044] The pre-setting module is used to pre-set the performance indicator parameters that need to be monitored for the front-end system. The performance indicator parameters include: first load time, white screen time, document content load time, page resource load time, and resource load time.

[0045] The metrics acquisition module is used to acquire preset performance metrics parameters that are needed for performance monitoring of the front-end system.

[0046] The real-time data capture module is used to monitor and capture corresponding indicator data of the front-end system in real time according to preset performance indicator parameters.

[0047] The data integration and cleaning module is used to integrate the captured indicator data, unify the data format, and perform data cleaning.

[0048] The visualization generation module is used to generate corresponding visualization dashboards from the processed indicator data according to preset analysis requirements.

[0049] The statistical analysis module is used to statistically analyze the response time, resource loading time, and user behavior of various indicators in the generated visual dashboard, and generate analysis results.

[0050] The optimization module is used to optimize the performance of indicator data that does not meet the preset values ​​in the generated analysis results and output the optimization results.

[0051] A server includes a memory and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by one or more processors, the one or more programs comprising the method for performing any one of the methods.

[0052] A computer-readable storage medium, wherein, when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform any of the methods described above.

[0053] As can be seen from the above, this application provides a front-end system performance automated monitoring and analysis method, device, server and storage medium. This paper will introduce a front-end automated performance monitoring and analysis method, which can automatically monitor all response times, resource loading times and user behavior of the front-end system, and report to the server at the same time. The algorithm performs statistics and analysis, and then displays the results through a visual interface, which is convenient for developers to locate and optimize.

[0054] This application solves the problems of low efficiency and scattered data in traditional methods by automating monitoring, data integration and cleaning, visual analysis and intelligent optimization processes. It has the advantages of improving performance monitoring efficiency, realizing intelligent data analysis and quickly locating performance bottlenecks. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 This is a flowchart illustrating the automated monitoring and analysis method for front-end system performance provided in Embodiment 1 of the present invention.

[0057] Figure 2 This is a flowchart illustrating the automated monitoring and analysis method for front-end system performance provided in Embodiment 2 of the present invention.

[0058] Figure 3The principle block diagram of an embodiment of the front-end system performance automated monitoring and analysis processing device provided by the present invention.

[0059] Figure 4 This is a block diagram illustrating the internal structure of the server provided in an embodiment of the present invention. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0061] It should be noted that if the embodiments of the present invention involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0062] In current technologies, modern enterprises generally rely on websites and front-end systems for product display and user interaction. However, in actual operation, problems such as response delays, excessively long blank screen times, and slow resource loading often occur. Traditional monitoring methods rely on manual sampling and inspection, which has drawbacks such as discontinuous data collection, difficulty in reproducing problems, and limited analytical dimensions. For example, an e-commerce platform frequently experienced page lag during promotional periods. Maintenance personnel could only passively discover the problem through user complaints, unable to locate performance bottlenecks in real time, resulting in optimization measures lagging behind the loss of user experience.

[0063] To address the aforementioned issues, the inventors of this application discovered that the root cause of the performance problems lies in the lack of a systematic monitoring mechanism. An evaluation of existing tools revealed that fragmented log collection methods resulted in poor data correlation, making manual analysis insufficient to cover multi-dimensional indicators. Based on this, the research and development direction shifted to building an automated data collection system, eliminating information silos through unified data processing, and improving analysis efficiency by combining visualization technology. Further research revealed that static threshold alarm modes are unsuitable for dynamic business scenarios, necessitating the establishment of an anomaly detection mechanism based on statistical models.

[0064] Therefore, this application proposes an automated monitoring and analysis method for front-end system performance, as described in the following embodiments:

[0065] Example 1

[0066] like Figure 1 As shown, an automated monitoring and analysis method for front-end system performance according to Embodiment 1 of the present invention includes the following steps:

[0067] Step S100: Obtain the preset performance indicator parameters that need to be monitored for the front-end system;

[0068] In this embodiment, obtaining preset performance indicator parameters for monitoring the front-end system may include:

[0069] Loading performance metrics, such as First Screen Load Time (FCP), Maximum Content Render (LCP), First Byte Time (TTFB), and resource loading time (such as JS / CSS / image loading time), reflect the efficiency of a page from request to rendering.

[0070] Interaction performance metrics, such as First Input Delay (FID), input response time (e.g., button click, form submission feedback time), and Long Task duration, measure the smoothness of user operations.

[0071] Stability metrics, such as page error rate (JS errors, resource loading failure rate), white screen time, and number of page crashes, reflect the reliability of system operation.

[0072] User experience-related metrics, such as cumulative layout offset (CLS) (which measures the degree of unexpected displacement of page elements) and changes in page visibility (such as whether the user switches tabs), are directly related to the user's subjective experience.

[0073] These metrics need to be pre-defined based on specific scenarios (for example, e-commerce websites focus more on product page loading speed and payment button response time, while backend management systems focus more on table rendering efficiency and API request success rate), and the thresholds of the metrics need to be clearly defined (such as LCP need to be controlled within 2.5 seconds and the error rate need to be less than 0.1%), so as to provide quantitative standards for subsequent monitoring.

[0074] Because front-end performance involves numerous metrics, blindly collecting all data would lead to wasted monitoring system resources and low analysis efficiency. In this embodiment of the invention, pre-setting key metrics can accurately pinpoint the performance bottlenecks most important to the business (such as the response speed of e-commerce payment processes), ensuring that monitoring data is "useful and efficient."

[0075] After setting preset indicators and thresholds, this invention can automatically compare actual operating data with standard values ​​to quickly identify anomalies (such as "LCP exceeds 3 seconds" or "error rate suddenly increases by 5%)." Compared to the vague "user feels it's slow," quantitative indicators can help developers directly pinpoint the problem area (such as resource loading timeout or code execution blocking), reducing troubleshooting time.

[0076] Step S200: Based on the preset performance index parameters, the front-end system is monitored and the corresponding index data is captured in real time.

[0077] This application pre-defines a set of performance metrics (also known as monitoring metrics or key performance indicators, such as page load time, white screen time, resource loading rate, response time, etc.) during the operation of the front-end system. The system will monitor these metrics in real time and continuously capture relevant data.

[0078] Specifically, real-time monitoring is performed based on the previously preset performance metrics parameters, continuously tracking changes in these metrics. This can be done using browser performance APIs (such as the Performance API) or dedicated monitoring tools to capture data while the user is browsing web pages.

[0079] In this embodiment, the values ​​of each metric are collected in real time during data collection, such as the time of the first page rendering, the delay of resource requests, and the DOM loading time.

[0080] The advantage of this step-by-step implementation is that, through real-time data capture, performance bottlenecks can be quickly located, such as whether a critical resource is loading slowly or if a network fluctuation is causing the problem. Furthermore, it allows for regular analysis of metric data to identify potential optimization opportunities and drive continuous performance improvements.

[0081] Step S300: Integrate the captured indicator data, unify the data format, and perform data cleaning.

[0082] In this step of the embodiment, various indicator data collected from different sources and scenarios will be aggregated into a unified storage or management system. For example, data such as page load time, resource request time, and user interaction time will be centrally saved for subsequent analysis.

[0083] After data integration, data format standardization is required. Specifically, data for different indicators may come from different sensors, tools, or acquisition methods, resulting in varying formats (such as different timestamp formats, different units, inconsistent field naming, etc.). This necessitates converting them into a unified standard format, such as unified units (seconds, milliseconds), unified field naming, and unified timestamp formats.

[0084] Next, data cleaning is performed. Specifically, because outliers may occur during the data collection process (such as abnormal requests, missing data, duplicate data, or erroneous data), the data needs to be cleaned to delete invalid or abnormal records, ensuring the accuracy and reliability of the data. This may include handling missing values, outlier detection and correction, and data deduplication.

[0085] In this way, by standardizing the format of the captured indicator data, this invention ensures that data from different indicators can be compared and correlated, avoiding misunderstandings or analytical biases caused by inconsistent formats. Furthermore, after cleaning the indicator data, isolated outliers or junk data are prevented from affecting the overall analytical conclusions, thus ensuring the accuracy of the analysis results. Moreover, through data integration and standardization, subsequent automated analysis, visualization, and intelligent algorithms can directly utilize the data, reducing preliminary preparation work and improving data analysis efficiency.

[0086] Step S400: Generate corresponding visualization dashboards from the processed indicator data according to the preset analysis requirements;

[0087] In this embodiment, the processed and analyzed performance metrics data can be automatically or manually generated into intuitive and easy-to-understand visual dashboards, enabling relevant personnel to quickly understand the system's performance status. Specifically, this includes the following:

[0088] Choose the appropriate visualization type. Based on different performance metrics, select the most suitable chart type for display. For example: line chart: shows the trend of page load time; bar or column chart: compares the loading latency of different resources within a certain time period; pie chart: shows the proportion of different performance bottlenecks; heat map: shows hot areas of performance changes.

[0089] Then, charts are generated based on the preset analysis requirements;

[0090] For example: monitoring real-time changes in key metrics (such as the time of first content rendering);

[0091] Displays performance trends over a period of time;

[0092] Display the frequency and location of performance anomalies;

[0093] Track performance differences among different user groups or different devices.

[0094] In this embodiment, regarding dynamic updates and interactions, the generated visual dashboard can support real-time dynamic refresh, and users can view detailed information by filtering, zooming, and hovering, enabling interactive exploration.

[0095] This embodiment can also integrate multiple indicators and multiple dimensions of multiple views. For example, multiple key indicator charts can be displayed in one dashboard to help the development team and decision-makers grasp the overall performance status from multiple perspectives.

[0096] Thus, in this embodiment, by generating a visual dashboard, developers, operations and maintenance personnel, and product managers can understand the system's performance health status at a glance without delving into the code or raw data, achieving rapid insight; and by using visual charts to identify performance bottlenecks, abnormal fluctuations, and trend changes, problems can be located.

[0097] Step S500: Statistically analyze the response time, resource loading time, and user behavior of various indicators in the generated visual dashboard, and generate analysis results;

[0098] In this step of the embodiment, the performance metrics data already displayed on the visualization dashboard are used for in-depth statistical analysis to draw valuable conclusions or discoveries. This process can help understand the performance of the front-end system and user behavior, identify potential problems, and support optimization decisions.

[0099] Specifically, statistics and analysis of response time can be performed on different request types (such as page load, API call, resource request) to calculate the average response time, maximum and minimum response time, fluctuation range, and trend of response time. This helps identify bottlenecks or points of abnormal fluctuation in request response and determine whether preset performance goals are met. For example, if the response time of a certain API becomes significantly longer, it may affect the user experience.

[0100] Statistics and analysis of resource loading times can specifically track the loading time of various resources on a page (images, scripts, stylesheets, etc.), analyze which resources load slowly or fail to load, whether the resource loading order is reasonable, and identify duplicate loading or redundant requests. This helps identify key resources affecting page loading speed and guides resource optimization solutions, such as merging and compression, and caching strategy optimization.

[0101] Statistical analysis of user behavior involves analyzing user behavior data on a webpage, such as page dwell time, frequently clicked areas, browsing paths, scrolling behavior, and form submissions. The goal is to understand users' actual usage habits and concerns, identify pain points or frequently used areas in the user experience, and provide a basis for performance optimization and interface improvement.

[0102] The analysis results are generated by combining the above data to conduct a comprehensive analysis and identify performance bottlenecks, user pain points, and abnormal fluctuations. Examples include abnormally high response time metrics, frequently failing to load resources, and changing trends in user behavior (such as a sudden decrease in page dwell time). The goal is to provide specific optimization suggestions, alerts, or trend reports to support the team in improving performance and enhancing user experience.

[0103] Step S600: Optimize the performance of the index data that does not meet the preset values ​​in the generated analysis results, and output the optimization results.

[0104] Thus, the analysis results generated by this invention enable: 1) Scientific decision-making: Data-driven analysis makes optimization measures more evidence-based; 2) Problem identification: Quickly pinpoint the specific links affecting performance; 3) Continuous improvement: Monitor changing trends and evaluate the effectiveness of optimization measures.

[0105] As can be seen from the above, the embodiments of this application propose an automated monitoring and analysis method for front-end system performance, including: acquiring preset performance monitoring parameters, capturing corresponding indicator data in real time, integrating and cleaning the data to generate a visual dashboard, statistically analyzing response time and resource loading status, and optimizing abnormal indicators. This method achieves a complete link from data collection to problem solving by constructing a closed-loop monitoring system.

[0106] Among these, performance metrics parameters refer to predefined key performance observation points, specifically implemented using core indicators such as initial load time and white screen time. These parameters accurately reflect performance at the user's perceived level. Data format standardization refers to converting heterogeneous data into a standard structure, achieved through methods such as date and time standardization and numerical unit normalization, ensuring cross-platform data comparability. Visual dashboards are dynamic interfaces that display analysis results, using line charts to show trend changes and heatmaps to present indicator relationships, helping to quickly identify performance fluctuation patterns. Performance optimization refers to improvement measures for abnormal indicators, specifically employing techniques such as code compression and caching strategy adjustments to achieve precise performance tuning.

[0107] Specifically, preset performance metrics are configured in the monitoring system, and automated tools continuously collect operational data. During the collection process, raw data from different sources is converted and cleaned before being stored in a unified database. The data analysis module generates multi-dimensional visualization charts based on preset rules, allowing operations personnel to observe performance trends on each page in real time through interactive dashboards. When the statistical model detects that a specific metric deviates from the preset range, the system automatically triggers an optimization suggestion generation process, such as recommending a CDN acceleration solution for abnormal resource loading times. The entire process forms a closed-loop management system of monitoring, analysis, and optimization, effectively shortening the problem response cycle.

[0108] Compared to existing technologies, traditional methods rely on manual inspection and offline analysis. This application achieves 24 / 7 monitoring through automated data collection, eliminates data discrepancies between tools using unified data processing, and improves problem localization efficiency by combining visualization technology. Compared to single-threshold alarm mechanisms, this method introduces a multi-dimensional statistical model, which can identify hidden performance problems in complex scenarios, such as resource loading anomalies caused by changes in user behavior patterns.

[0109] Through the above technical solutions, this application establishes an end-to-end performance monitoring system, enabling real-time problem detection and targeted optimization measures. Automated data collection reduces manual intervention costs, unified data processing ensures the accuracy of analysis results, and visual dashboards improve problem diagnosis efficiency, ultimately forming an actionable performance optimization plan. This solution is particularly suitable for dynamic business scenarios, effectively preventing performance degradation caused by traffic fluctuations and ensuring the stability of user experience.

[0110] This application further proposes to pre-set performance metrics parameters for front-end system performance monitoring before obtaining preset performance metrics parameters. These performance metrics parameters include initial load time, white screen time, document content load time, page resource load time, and resource load time.

[0111] The initial load time refers to the time interval from when a user initiates a page request to when the page is fully loaded. It can be measured using the browser's navigation timing API or automated tools to reflect the overall waiting experience when a user visits the site for the first time.

[0112] The white screen time refers to the time interval between when the browser starts parsing HTML and when it first renders page elements. It can be captured through browser rendering timeline data and is used to measure the performance bottleneck in the initial rendering stage of the page.

[0113] The document content loading time refers to the time when the DOM tree is completed. It can be marked through the DOMContentLoaded event and is used to evaluate the loading efficiency of the page's basic framework.

[0114] Page resource loading time refers to the time when all external resource files are loaded. This can be monitored through the window.onload event to detect the loading efficiency of resource files such as images and scripts.

[0115] Resource loading time refers to the time interval from the initiation of a request to the completion of receiving a single static resource. This time interval can be recorded using a resource time sequence waterfall chart to locate loading anomalies in specific resource files.

[0116] Specifically, five core performance metrics are predefined through the configuration management interface before the system runs. For example, a parameter set including initial load time, white screen time, document content load time, page resource load time, and resource load time is established in the monitoring platform configuration module. When the system starts, this preset parameter set is automatically loaded as the monitoring benchmark, and data at the corresponding time points is collected in real time through the browser performance interface and automated tools. This method of predefining key time-dimensional metrics can systematically cover performance monitoring points throughout the entire page loading process.

[0117] Compared to existing technologies, traditional front-end performance monitoring typically focuses only on overall loading time or the loading of some resources, lacking targeted monitoring of key time points such as the white screen phase and the DOM construction phase. This application, however, establishes a monitoring system covering the entire process of page initialization, content rendering, and resource loading by pre-setting multiple performance indicators with clear technical definitions, allowing performance issues to be pinpointed to specific loading stages.

[0118] Through the above technical solutions, this application can effectively identify the specific factors causing page response delays. For example, when a blank screen time exceeds a threshold, HTML parsing or first-screen resource loading strategies can be optimized accordingly; when document content loading time is abnormal, issues with DOM structure complexity or script execution efficiency can be investigated. This phased approach to setting performance metrics provides developers with multi-dimensional guidance for optimization.

[0119] This application further proposes selecting specific open-source automated performance monitoring tools, including the Google Lighthouse open-source automation tool for improving webpage quality, the WebPageTest website performance testing tool for testing webpage performance, and the Sentry error tracing and performance monitoring platform for real-time monitoring of front-end application performance and errors; using the selected open-source automated performance monitoring tools, the corresponding indicator data of the front-end system are captured in real-time based on preset performance indicator parameters.

[0120] Among them, Google Lighthouse, an open-source automation tool, is a tool for multi-dimensional quality assessment of web pages through automated scripts. Specifically, it can be integrated into the monitoring process using its provided API to generate assessment reports that include performance metrics, accessibility, and best practices. WebPageTest, a website performance testing tool, is a testing platform that simulates different network conditions based on a real browser environment. Specifically, it can obtain resource waterfall charts and time-point data during page loading by configuring test geographical location, network bandwidth, and device type parameters. Sentry, a bug tracking and performance monitoring platform, is a cloud service that can capture front-end runtime errors and performance metrics. Specifically, it can record user behavior and collect performance data by injecting SDK code.

[0121] Specifically, after setting performance metrics parameters, a complementary monitoring system is formed by simultaneously invoking three tools. For example, Google Lighthouse can periodically execute automated tests and output key metrics such as first content rendering time; WebPageTest can simulate access scenarios for users in different regions and obtain resource loading time-series data; Sentry continuously monitors performance fluctuations in actual user operations in the production environment. The data from the three tools are collected synchronously through standardized interfaces. Google Lighthouse focuses on benchmark testing in laboratory environments, WebPageTest provides network layer performance analysis, and Sentry supplements performance under real user scenarios, jointly constructing a multi-dimensional monitoring data source.

[0122] Compared to existing technologies, traditional solutions often employ single tools or manual testing methods, resulting in limitations such as limited monitoring dimensions and an inability to cover real-world user scenarios. This application, through the organic combination of toolchains, retains the controllable testing conditions of a laboratory environment while incorporating real-world user behavior data. It also supports simulated testing in multi-regional network environments, enabling performance data collection to cover the entire development, testing, and production phases.

[0123] Through the above technical solution, this application achieves multi-dimensional capture of front-end performance issues, simultaneously identifying performance defects in laboratory benchmark environments, loading anomalies under specific network conditions, and performance bottlenecks in real user operations. This combined monitoring mechanism effectively solves the pain point of the difficulty in reproducing sporadic problems, providing complete data support for subsequent analysis and optimization.

[0124] This application further proposes to obtain performance metrics by calling the Performance API provided by the browser, including white screen performance metrics, gray screen performance metrics, maximum content rendering performance metrics, first input delay performance metrics, cumulative layout offset performance metrics, and static resource loading performance metrics.

[0125] Among them, the white screen performance metric refers to the time point when the page's visual appearance first changes. This is specifically achieved by monitoring the first render event in the browser's rendering process, reflecting the rendering efficiency during the initial page loading phase. The gray screen performance metric refers to the time point when any text, image, non-blank canvas, or vector graphic is first rendered. This is obtained by capturing the browser's first valid content rendering event, measuring the user's perceived page usability. The maximum content rendering performance metric refers to the relative time it takes for the largest image or text block within the visible area to complete rendering. This is achieved by analyzing the rendering time of the largest element after the layout has stabilized, evaluating the presentation efficiency of the page's core content. The first input latency performance metric refers to the time from the user's first interaction with the page to the browser's actual response and the start of event handling. This is measured by listening to the difference between user input events and the browser's response time, reflecting the page's interactive response performance. The cumulative layout offset performance metric is the sum of scores for all unexpected layout offsets throughout the page's lifecycle. This is achieved by calculating the element position offset and its visible impact range, quantifying the page's visual stability. The static resource loading performance metric refers to the static resource information accessed each time the page loads. This is achieved by recording resource loading time and status data, analyzing resource loading efficiency and identifying bottlenecks.

[0126] Specifically, by calling the Performance API, the six types of performance metrics mentioned above can be captured in real time. For example, white screen time and gray screen time are recorded by listening to the timestamps of browser rendering events; maximum content rendering time is determined by continuously monitoring the rendering status of page elements and calculating the stabilization time of the largest element; initial input latency is statistically analyzed by comparing the difference between user operation time and browser response time; cumulative layout offset is derived by calculating the comprehensive impact of changes in page element positions on the visible area; and static resource loading data is summarized by extracting key node information from the resource loading timeline. After unified processing, this data forms a multi-dimensional foundation for performance analysis, helping developers accurately pinpoint performance bottlenecks in page loading, rendering, and interaction processes.

[0127] Compared to existing technologies, current solutions typically rely on third-party tools or manual data collection, resulting in issues such as coarse data granularity, poor real-time performance, and limited coverage of metrics. This application, however, directly calls the browser's native API, enabling the capture of key performance metrics with higher precision and less intrusion. It also covers performance parameters throughout the entire process, from page loading and content rendering to user interaction, significantly improving the comprehensiveness and accuracy of monitoring data.

[0128] Through the above technical solutions, this application enables refined monitoring and analysis of front-end performance issues. For example, white screen and gray screen time data can quickly identify rendering delays during page initialization; initial input delay metrics allow for targeted optimization of interactive response logic; and cumulative layout offset scores can effectively reduce page visual jitter. Ultimately, these metrics provide clear data support for performance optimization, shortening the problem-solving cycle and improving optimization efficiency.

[0129] This application further proposes steps for integrating the captured indicator data, unifying the data format, and cleaning the data, including: integrating the captured indicator data from different sources; converting the date and numerical type of the integrated indicator data to form indicator data in a unified format; handling missing values ​​in the unified format indicator data by checking for missing values ​​and deleting or filling them as appropriate; handling outliers in the unified format indicator data by identifying and processing outliers; and handling duplicate records in the unified format indicator data by finding and deleting duplicate records.

[0130] Data integration refers to merging heterogeneous data from multiple monitoring tools or interfaces. Specifically, data pipeline technology can be used to import JSON and CSV data from different sources into a unified repository, thus solving the difficulty of correlation analysis caused by the scattered storage of multi-source data. Data format unification involves converting timestamp fields to the standard ISO8601 format and unifying numeric fields to floating-point precision. This can be achieved through regular expression matching and type conversion functions, eliminating data parsing errors caused by format differences. Missing value handling involves detecting null values ​​or invalid placeholders. This can be achieved by using interpolation to linearly fill time-series data or directly deleting records with missing values ​​exceeding a threshold, thus avoiding the bias of statistical results caused by null values. Outlier handling involves identifying values ​​outside the reasonable range. This can be achieved by defining outlier boundaries using box plots or the 3σ principle, and correcting the data using truncation or smoothing methods, thus eliminating noise interference from sensor false alarms or network jitter. Duplicate value handling involves detecting multiple identical records. This can be achieved by generating data fingerprints using hash algorithms and comparing them, thus preventing data redundancy caused by the retry mechanism of the acquisition system.

[0131] Specifically, during the data integration phase, a data access layer is established to merge monitoring results from tools such as Lighthouse and Sentry with metrics collected from the Performance API, forming a comprehensive dataset that includes time and page dimensions. In the format standardization phase, date fields are converted to the "YYYY-MM-DD HH:mm:ss" format, and numerical metrics are retained to two decimal places. During missing value handling, for null values ​​in the static resource load time field, if other metrics on the same page are complete, the historical average value for that page is used to fill in the null value; if more than 30% of the field is missing, the entire record is marked as invalid. For outlier handling, records with an initial load time exceeding 10 seconds undergo secondary verification; if confirmed as genuine data, they are retained; otherwise, they are discarded. Duplicate value handling uses a composite key based on timestamp, page URL, and metric type to remove duplicates, ensuring the uniqueness of each record.

[0132] Compared to existing technologies, traditional methods typically only perform simple cleaning on single-source data, lacking a systematic processing flow for multi-source heterogeneous data. For example, existing technologies do not adapt to the format differences between browser interface data and automation tool data, leading to timeline misalignment issues during visualization analysis; furthermore, the lack of phased cleaning rules may result in the accidental deletion of genuine high-latency data during outlier handling. This application establishes a multi-level data processing mechanism, improving cross-platform data consistency while ensuring data integrity.

[0133] Through the above technical solution, this application solves the problem of scattered indicators caused by complex data sources in front-end performance monitoring, eliminates analysis errors caused by chaotic formats, and effectively filters out invalid data and noise interference generated during the collection process. The resulting standardized dataset provides high-quality input for subsequent visualization and statistical analysis, improving the accuracy of performance bottleneck location while reducing the workload of manual data verification.

[0134] This application further proposes a step to generate corresponding visualization dashboards from the processed indicator data according to preset analysis requirements, including: when trend analysis is required, drawing line charts based on the processed indicator data to show the changing trend of performance indicators over time using a visualization scheme; when distribution analysis is required, drawing histograms based on the processed indicator data to show the distribution of specific performance indicators; when correlation analysis is required, drawing heatmaps based on the processed indicator data to show the correlation between different performance indicators; and when comparative analysis is required, using bar charts to compare performance indicators on different pages or over different time periods based on the processed indicator data.

[0135] Trend analysis involves observing the changing patterns of performance indicators through time-series data, typically using line charts to visually reflect fluctuations over time. Distribution analysis involves statistically analyzing the frequency of performance indicators across different numerical ranges, typically using histograms to clearly demonstrate the central tendency and dispersion of the dataset. Correlation analysis studies the relationships between multiple performance indicators, typically using heatmaps to visually represent correlation coefficients through color variations. Comparative analysis compares the performance differences between different objects or time periods, typically using bar charts to visually display the comparison results through height differences.

[0136] Specifically, after data cleaning and format standardization, the system automatically matches a visualization solution based on preset analysis scenarios. When operations and maintenance personnel need to observe long-term fluctuations in page load time, the system calls the line chart generation module to map timestamps and corresponding indicator values ​​to continuous points in a coordinate system. When troubleshooting resource loading anomalies, the system triggers the histogram generation module to group and statistically analyze static resource load times by millisecond intervals. When studying the correlation between white screen time and resource load time, the system activates the heatmap generation module to calculate the Pearson correlation coefficient matrix for the two sets of data. When comparing the performance of different page versions, the system calls the bar chart generation module to display the version number alongside the mean of key indicators.

[0137] Compared to existing technologies, traditional monitoring systems typically provide only single-dimensional data reports and cannot dynamically switch visualization formats according to specific analysis scenarios. While some existing solutions include chart display functions, they lack dedicated view configurations for performance analysis scenarios; for example, they do not apply heatmaps to indicator correlation analysis or bar charts to version iteration comparisons. Furthermore, existing technologies often require manual selection of chart types, while this application achieves automatic matching of visualization solutions by pre-setting analysis requirements.

[0138] Through the above technical solutions, this application can automatically generate adapted visualization views for different performance analysis scenarios, enabling developers to quickly identify the spatiotemporal distribution characteristics of performance bottlenecks. Line charts effectively capture the periodic fluctuations of performance indicators, histograms accurately locate the distribution range of outliers, heatmaps intuitively reveal the potential correlations between indicators, and bar charts clearly present the differences between multiple objects, thus forming a multi-dimensional performance problem diagnosis support system.

[0139] This application further proposes to optimize the performance of indicator data that does not meet the preset values ​​in the generated analysis results and output the optimization results. This includes comparing each indicator data in the generated analysis results with the corresponding preset value to determine whether each indicator data meets the preset value range of its corresponding indicator; optimizing the performance of indicator data that does not meet the preset value range of its corresponding indicator in the generated analysis results and outputting the optimization results.

[0140] The comparison of indicator data with corresponding preset values ​​refers to matching and verifying the actual collected performance parameters with pre-set acceptable thresholds. This can be achieved using automated scripts to implement the threshold comparison logic, such as defining the allowable fluctuation range for each indicator through a configured JSON file. Performance optimization refers to taking targeted improvement measures for indicators that exceed preset ranges. This can be achieved through code compression, caching strategy adjustments, or resource loading order optimization. For example, CDN acceleration can be implemented for indicators with excessively long static resource loading times. Outputting optimization results involves generating a structured report from the verification data after the optimization measures are implemented. This can be achieved using a PDF document generation module or API interface push methods. For example, performance comparison data before and after optimization can be embedded in an email notification in tabular form.

[0141] Specifically, after the performance monitoring system completes data collection and analysis, it automatically filters out abnormal metrics based on preset threshold judgment rules. When the initial input delay exceeds 500 milliseconds, the system automatically triggers JavaScript main thread optimization schemes, such as decomposing long tasks into a micro-task queue. For pages with cumulative layout offsets exceeding 0.25, it automatically generates a suggested scheme for fixing DOM element sizes. After the optimization measures are implemented, the system re-collects performance data and generates a comparison report, including changes in metric values ​​before and after optimization, as well as an evaluation of the effectiveness of the optimization.

[0142] Compared to existing technologies, traditional methods rely on manual analysis of performance reports and manual formulation of optimization schemes, which suffers from problems such as response lag and subjective judgment bias. This application, by establishing an automated threshold determination mechanism and optimization strategy library, can identify performance bottlenecks in real time and quickly match the best optimization scheme, while generating traceable optimization process documents, effectively solving the defects of low efficiency in manual processing and lack of systematic optimization measures.

[0143] Through the above technical solution, this application achieves a rapid location and closed-loop handling mechanism for performance issues, ensuring that each abnormal indicator can be optimized in a targeted manner, avoiding the disconnect between optimization measures and actual problems in traditional methods. The standardized output of optimization results provides the development team with clear directions for improvement, shortening the cycle from problem discovery to fix. At the same time, the accumulated optimization case data establishes a knowledge base that can be referenced for subsequent performance tuning.

[0144] The present invention will be further described in detail below through another specific application embodiment.

[0145] Example 2

[0146] like Figure 2 As shown in the figure, the second embodiment of this invention provides an automated monitoring and analysis method for front-end system performance, including:

[0147] S10, Begin, and proceed to S11;

[0148] S11. Define the monitoring indicators and proceed to S12;

[0149] In this embodiment of the invention, the monitoring metrics are first defined. That is, before starting to build the monitoring system, the performance metrics to be monitored need to be defined. In this embodiment of the invention, preferably, the front-end performance metrics include:

[0150] 1) Initial load time: This is the time from when the user requests the page to when the page is rendered for the first time.

[0151] 2) White screen time: The time from when the user requests the page to when the page begins to render content.

[0152] 3) DOMContentLoaded time: The time it takes for the DOM structure to finish loading.

[0153] 4) Load time: The time it takes for all resources on the page (including images, scripts, etc.) to be loaded.

[0154] 5) Resource loading time: The loading time of each resource (such as CSS, JS, and images).

[0155] S12, The front-end system captures various metrics and proceeds to S13;

[0156] In a specific embodiment of the present invention, the monitoring indicators are clearly defined, automated monitoring technology is selected, and corresponding monitoring tools are chosen for automated indicator monitoring, specifically including:

[0157] 1) This application may choose open-source, automated performance monitoring tools, such as the following automated performance monitoring tools:

[0158] ①Google Lighthouse: An open-source automation tool used to improve the quality of web pages. It can audit aspects such as performance, accessibility, and best practices.

[0159] ②WebPageTest: A free website performance testing tool used to test the performance of web pages in multiple locations and provide detailed reports.

[0160] ③Sentry: An open-source bug tracking and performance monitoring platform used to help monitor the performance and bugs of front-end applications in real time.

[0161] 2) In specific embodiments of the present invention, monitoring code can be implemented independently using pre-defined monitoring metrics: for example, using the Performance API provided by the browser to obtain performance metrics, including:

[0162] ① White screen (FP): The point in time when the page's visual appearance first changes. For example, setting the background color of the body (the main body of the page); White screen (FP) does not include the default background rendering, but it does include the rendering of non-default backgrounds;

[0163] ②Fallout Gray Screen (FCP): The point in time when any text, image, non-blank canvas, or SVG (vector graphics) is first drawn;

[0164] ③ Maximum Content Render (LCP): The relative time it takes for the largest image or text block in the visible area to be rendered. It is a user-centric performance metric that can test the page loading speed as perceived by the user.

[0165] ④ First Input Delay (FID): This is the time elapsed from the first time a user interacts with the page (e.g., when they click a link, press a button, or use a custom control driven by JavaScript) until the browser responds to the interaction and is actually able to begin processing the event handler.

[0166] ⑤ Cumulative Layout Offset (CLS): This measures the total score of all unexpected layout offsets that occur throughout the entire lifecycle of a webpage;

[0167] ⑥ Static resource loading: This application can obtain the static resources accessed each time it loads, and create analysis graphs such as waterfall charts from the collected static resources to find the cause of the problem that causes the static resource loading time to be too long.

[0168] S13, Indicator reporting and storage, and then proceed to S14;

[0169] In a specific embodiment of the present invention, a backend storage and analysis system will be built to report and store the various indicator data captured by the frontend system, as follows:

[0170] 1) Reporting Interface Design: Design a reporting interface that can be called by the front end via fetch or XMLHttpRequest.

[0171] 2) Then select a database: Depending on the applicable scenario, you can use a relational database (such as MySQL) or a non-relational database (such as MongoDB) for data storage.

[0172] In this embodiment, data storage optimization is performed, specifically including the following steps:

[0173] ① Data compression: For large amounts of performance monitoring data, data compression algorithms (such as Gzip) can be used to compress the data and reduce storage space.

[0174] ② Partitioned storage: In relational databases, partitioned tables can be used to store data, improving data query performance. For example, performance monitoring data tables can be partitioned by time.

[0175] ③ Caching mechanism: Use caching (such as Redis) to cache frequently queried data and reduce the access pressure on the database.

[0176] S14. Organize the data and proceed to S15;

[0177] S15. Perform data cleaning and proceed to S16;

[0178] In specific embodiments of the present invention, the method further includes data processing and cleaning steps, specifically including:

[0179] 1) First, perform data integration: combine data from different sources. For example, front-end performance data may come from different pages or different versions of code, and there may also be other data such as user information and server logs.

[0180] 2) Next, standardize the data format: Ensure consistent data format for easier subsequent analysis. Using Python's pandas library as an example, perform format conversion for date and numeric types.

[0181] 3) Handle missing values: Check for missing values ​​in the data and handle them as appropriate, such as deleting or filling them in.

[0182] 4) Outlier handling: Identify and handle outliers in the data. Statistical methods, such as the Z-score method, can be used.

[0183] (5) Duplicate value handling: Find and delete duplicate records.

[0184] S16. Generate a visual dashboard based on the cleaned data, and proceed to S17;

[0185] In this step of the embodiment, a visual dashboard is generated from the cleaned data.

[0186] S17. Perform performance index analysis and proceed to S18;

[0187] In this specific embodiment, the generated visualization dashboard will undergo visualization analysis, specifically including:

[0188] 1) Trend analysis: Based on the collected data, a line chart is drawn using a visualization method to show the trend of performance indicators over time.

[0189] 2) Distribution analysis: This involves drawing histograms based on the data to show the distribution of specific performance indicators.

[0190] 3) Correlation analysis: This involves drawing heat maps to show the correlation between different performance indicators.

[0191] 4) Comparative analysis: Use bar charts to compare performance metrics across different pages or time periods.

[0192] S18, Optimize performance and proceed to S19;

[0193] In this embodiment of the invention, performance optimization will also be performed based on the index data that do not meet the preset values ​​in the above analysis results, and the optimization results will be output.

[0194] S19, End.

[0195] As can be seen from the above, this specific application embodiment provides a front-end automated performance monitoring and analysis method. This method can automatically monitor all system response times, resource loading times, and user behavior, and simultaneously report to the server. The algorithm performs statistical analysis, and the results are then displayed through a visual interface, making it convenient for developers to locate and optimize specific issues.

[0196] Exemplary device

[0197] like Figure 3 As shown in the figure, an embodiment of the present invention provides an automated monitoring and analysis processing device for front-end system performance, the device comprising:

[0198] The pre-setting module 310 is used to pre-set the performance indicator parameters that need to be monitored for the front-end system. The performance indicator parameters include: first load time, white screen time, document content load time, page resource load time, and resource load time.

[0199] The indicator acquisition module 320 is used to acquire preset performance indicator parameters that need to be used for performance monitoring of the front-end system;

[0200] The real-time data capture module 330 is used to monitor and capture corresponding indicator data of the front-end system in real time according to preset performance indicator parameters.

[0201] The data integration and cleaning module 340 is used to integrate the captured indicator data, perform data format unification processing, and perform data cleaning processing.

[0202] The visualization generation module 350 is used to generate corresponding visualization dashboards from the processed indicator data according to preset analysis requirements.

[0203] The 360 ​​Statistical Analysis Module is used to statistically analyze the response time, resource loading time, and user behavior of various indicators in the generated visual dashboard, and generate analysis results.

[0204] The optimization module 370 is used to optimize the performance of indicator data that do not meet the preset values ​​in the generated analysis results and output the optimization results.

[0205] The system comprises several modules: **Pre-configuration module:** This module defines the scope of performance monitoring and can be implemented through a configuration management interface, allowing for the definition of monitoring targets by pre-setting indicator parameters. **Real-time data capture module:** This module is the execution unit that collects front-end runtime data. For example, it integrates Google Lighthouse or WebPageTest tools to automate data scraping and obtain key indicators such as page load time and resource loading status in real time. **Data integration and cleaning module:** This module is the logical unit that processes heterogeneous data. For example, it uses ETL processes to standardize date formats and employs missing value imputation algorithms to ensure data integrity. **Visualization module:** This module is the component that graphically displays data. For example, it uses the Echarts library to generate line charts to show trend changes and uses bar charts to compare performance differences between different pages. **Optimization module:** This module is the exception handling decision-making unit. For example, it triggers alarms based on preset thresholds and generates suggested reports by associating them with optimization schemes such as code compression and caching strategies.

[0206] Specifically, the pre-setting module receives user-defined monitoring metrics such as first-screen loading time and resource loading time through the configuration interface, forming a standardized parameter set. After reading the preset parameters, the metric acquisition module initiates an automated monitoring process, such as calling the Sentry platform to collect page rendering time-series data and obtaining the first input delay metric through the Performance API. The data integration and cleaning module performs structured transformation on JSON and CSV format data collected from different tools, such as unifying timestamps to ISO8601 format and using interpolation algorithms to fill in missing values ​​caused by monitoring interruptions. The visualization generation module calls different chart engines based on the analysis scenario, such as generating line charts when tracking performance trends and comparative bar charts when comparing multi-page performance. The statistical analysis module performs regression analysis on the raw data associated with the visualization charts to identify the correlation between resource loading time and user bounce rate. The optimization module marks metrics exceeding preset thresholds as abnormal, such as associating first-screen loading times exceeding 3 seconds with image lazy loading schemes and generating specific optimization operation guidelines.

[0207] Compared to existing technologies, traditional methods rely on manual configuration of monitoring tools and lack data integration capabilities. For example, developers need to use Lighthouse and WebPageTest separately to generate independent reports, making cross-tool data analysis difficult. This application automates tool integration and data processing through modular design. For instance, the data integration and cleaning module can automatically align timestamp data from different tools, enabling multi-dimensional correlation analysis. The problem of separation between visualization charts and optimization suggestions in existing technologies is also improved. For example, the optimization module can directly correlate abnormal data points in visualization charts to generate targeted solutions.

[0208] Through the above technical solutions, this application achieves automated discovery and closed-loop processing of front-end performance issues. The modular architecture solves the problem of data silos across multiple tools; for example, the data integration and cleaning module can uniformly process data streams from browser interfaces and third-party monitoring platforms. The linkage mechanism between visual dashboards and statistical analysis helps quickly locate performance bottlenecks; for example, heatmaps can identify the positive correlation between resource loading time and code package size. The automated output of optimization suggestions shortens the problem-solving cycle; for example, when a static resource loading timeout is detected, the system can immediately recommend CDN acceleration or resource merging solutions, avoiding response delays caused by manual analysis.

[0209] Based on the above embodiments, the present invention also provides a server, the principle block diagram of which can be as follows: Figure 4 As shown. The server includes a processor, memory, network interface, display screen, and database connected via a system bus.

[0210] A server according to this application further includes one or more programs, wherein one or more programs are stored in a memory and configured to be executed by one or more processors, the one or more programs including a method for performing automated monitoring and analysis of front-end system performance.

[0211] In this context, "memory" refers to the hardware device used to store program code and monitoring data, specifically implemented using solid-state drives (SSDs) or disk arrays. Its function is to persistently store performance metric collection rules, analysis algorithms, and historical monitoring data. "Processor" refers to the arithmetic unit that executes program instructions, specifically implemented using multi-core CPUs or distributed computing clusters. Its function is to process front-end performance data in real time and execute automated analysis processes. "Program" refers to a set of computer instructions containing performance monitoring logic, specifically written in Python or Java. Its function is to implement the complete processing chain of data acquisition, cleaning, visualization, and optimization decision-making.

[0212] Specifically, the server loads preset performance metrics and analysis rules into memory, and the processor driver executes an automated monitoring process. For example, when the program calls the browser's Performance API to obtain the white screen time metric, the processor parses the raw data returned by the API in real time and correlates the timestamp with the resource loading event. During the data cleaning phase, the program uses regular expressions to match abnormal characters and employs a sliding window algorithm to identify outliers in the time series. After data standardization, the processor calls the visualization engine to generate a dynamic line chart and caches the rendering results in memory for front-end use. When the page resource loading time is detected to exceed a threshold, the optimization module automatically triggers a CDN acceleration strategy and generates an optimization report containing problem location and repair suggestions.

[0213] In some implementations, the program can be configured to trigger a full-site performance scan task at regular intervals, such as automatically executing Lighthouse tests and generating a daily report at 2:00 AM every day. For high-concurrency scenarios, the server can adopt a microservice architecture to deploy multiple analysis nodes, using message queues to distribute tasks and aggregate results. At the data storage level, time-series databases can be used to efficiently store the time dimension data of performance metrics, while relational databases store device configuration information and optimization history.

[0214] Compared to existing technologies, traditional servers typically only possess basic data storage and computing capabilities, requiring manual script configuration and integration of data from multiple tools for performance monitoring. This application, however, achieves integrated monitoring tools and a streamlined data processing pipeline through pre-built programs, eliminating the parsing costs associated with cross-system data format differences. While existing anomaly detection often employs fixed threshold alarm mechanisms, this application dynamically adjusts detection sensitivity using machine learning models, effectively reducing false alarm rates. Furthermore, traditional solutions store analysis results in raw log format; this application generates visualization templates automatically, enabling performance data to be instantly transformed into decision support information.

[0215] Through the above technical solution, this application achieves end-to-end automated processing of front-end performance data, overcoming the technical bottlenecks of low efficiency and difficulty in problem localization during manual monitoring. The server, through a pre-defined standardized processing flow, ensures that performance indicators from different sources can be uniformly analyzed and compared, effectively shortening the average time to detect performance anomalies. Based on the collaborative working mechanism of the processor and memory, the system can process massive amounts of monitoring data in real time and generate visual reports, providing developers with precise optimization directions. Through automated threshold detection and optimization strategy matching, the frequency of manual intervention is significantly reduced, improving the efficiency of closed-loop processing of performance issues.

[0216] This application further proposes a computer-readable storage medium that, when executed by the processor of an electronic device, enables the electronic device to perform an automated monitoring and analysis method for front-end system performance, including: acquiring preset performance index parameters; capturing index data in real time by monitoring the front-end system; integrating and unifying the data format and performing data cleaning; generating a visual dashboard based on analysis requirements; performing statistical analysis on the index data; optimizing the performance of index data that does not meet preset values ​​and outputting the results.

[0217] Computer-readable storage media refers to the physical carrier used to persistently store program instructions. Specifically, it can be implemented using solid-state drives, hard disk drives, or flash memory chips. Its function is to ensure that the execution logic of the performance monitoring method can be stored for a long time and called stably.

[0218] The processor is a computing unit that executes instructions stored in the storage medium. Specifically, it can be implemented using a central processing unit or a graphics processing unit. Its function is to parse instructions and drive electronic devices to complete data acquisition, analysis, and optimization operations.

[0219] Instructions refer to a set of codes that control electronic devices to perform specific functions. They can be implemented using machine language or compiled binary code, and their role is to transform the performance monitoring process into standardized operations that can be executed repeatedly.

[0220] Specifically, when instructions from the storage medium are loaded into the processor, the electronic device will automatically execute performance data acquisition, cleaning, and analysis processes according to preset logic. For example, it can capture metrics such as white screen time and resource loading time by calling browser interfaces or open-source tools, then perform format conversion and outlier handling on the data to generate visual charts such as line graphs and heatmaps. When the initial input delay exceeds a threshold, an optimization algorithm is automatically triggered to generate resource compression or caching strategies, and the optimization results are written to a log file.

[0221] Compared to existing technologies, current solutions typically rely on independently deployed monitoring tools whose data processing logic is separated from the storage medium, resulting in unusable analysis results and high response latency. This application embeds the complete method into the storage medium, allowing any compatible electronic device to directly invoke the standardized process, avoiding data deviations caused by differences in environmental configurations, and reducing manual intervention.

[0222] Through the above technical solution, this application achieves automated discovery and closed-loop processing of front-end performance issues, overcoming the technical shortcomings of low efficiency and difficulty in reproducing problems through manual troubleshooting. The synergistic effect of storage media and processor enables performance data to be collected in real time and persistently stored, facilitating developers to quickly locate resource loading anomalies or rendering stuttering issues. At the same time, it automatically generates solutions through preset optimization logic, shortening the fault repair cycle.

[0223] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for automated monitoring, analysis, and processing of front-end system performance, characterized in that, include: Obtain the preset performance metrics parameters that need to be monitored for the front-end system; Based on preset performance index parameters, the front-end system is monitored and the corresponding index data is captured in real time. The captured indicator data is integrated, the data format is standardized, and the data is cleaned. The processed indicator data will be used to generate corresponding visualization dashboards based on the preset analysis requirements. The system statistically analyzes and compiles data on various metrics, including response time, resource loading time, and user behavior, to generate analytical results. The system optimizes the performance of indicators that do not meet the preset values ​​in the generated analysis results and outputs the optimization results.

2. The front-end system performance automated monitoring and analysis method according to claim 1, characterized in that, Before the step of obtaining the preset performance indicator parameters that need to be monitored for the front-end system, the following steps are included: Pre-configure the performance metrics parameters that need to be monitored for the front-end system. The performance metrics include: initial load time, white screen time, document content load time, page resource load time, and resource load time.

3. The front-end system performance automated monitoring and analysis method according to claim 1, characterized in that, The step of real-time monitoring and capturing corresponding indicator data of the front-end system according to preset performance indicator parameters includes: Select the specified open-source automated performance monitoring tools, including: Google Lighthouse open-source automation tool for improving webpage quality, WebPageTest website performance testing tool for testing webpage performance, and Sentry error tracing and performance monitoring platform for real-time monitoring of front-end application performance and errors; By using the selected open-source automated performance monitoring tools, the corresponding indicator data of the front-end system can be captured in real time according to the preset performance indicator parameters.

4. The front-end system performance automated monitoring and analysis method according to claim 1, characterized in that, The step of real-time monitoring and capturing corresponding indicator data of the front-end system according to preset performance indicator parameters includes: Use the browser's Performance API to obtain performance metrics, including: White screen performance metric: The point in time when the page's visual appearance first changes; Gray screen performance metrics: The time point at which any text, image, non-blank canvas, or vector graphic is first drawn. Maximum content rendering performance metric: the relative time required to render the largest image or text block within the visible area; First-input latency performance metrics: the time elapsed from the user's first interaction with the page until the browser responds to the interaction and is actually able to begin processing event handlers; Cumulative layout offset performance metric: This measures the total score of all unexpected layout offsets that occur throughout the entire lifecycle of a webpage; Static resource loading performance metrics: These metrics are used to obtain the static resources accessed during each load and to create analytical graphs of the collected static resources to identify the causes of excessively long static resource loading times.

5. The front-end system performance automated monitoring and analysis method according to claim 1, characterized in that, The steps of integrating the captured indicator data, unifying the data format, and cleaning the data include: The captured data from various sources are integrated and combined. The integrated indicator data will be formatted by converting the date and numerical data types to form indicator data in a unified format. Handle missing values ​​for indicator data in a uniform format, check for missing values ​​in the data, and delete or fill them as needed; Perform outlier handling on standardized indicator data, identifying and processing outliers in the data; Perform duplicate value processing on indicator data in a uniform format, and find and delete duplicate records.

6. The front-end system performance automated monitoring and analysis method according to claim 1, characterized in that, The step of generating corresponding visualization dashboards from the processed indicator data according to preset analysis requirements includes: When trend analysis is required, line charts are drawn using visualization methods based on the processed indicator data to show the trend of performance indicators over time. When distribution analysis is required, histograms are plotted based on the processed index data to show the distribution of specific performance indicators. When correlation analysis is required, a heat map is drawn based on the processed index data to show the correlation between different performance indicators. When comparative analysis is required, use bar charts to compare performance metrics across different pages or time periods based on the processed metric data.

7. The method for automated monitoring, analysis and processing of front-end system performance according to claim 1, characterized in that, The step of optimizing the performance of indicator data that do not meet the preset values ​​in the generated analysis results and outputting the optimization results includes: Each indicator data in the generated analysis results is compared with the corresponding preset value to determine whether each indicator data meets the range of its corresponding preset value. The system optimizes the performance of indicator data in the generated analysis results to determine whether the indicator data meets the preset value range of the corresponding indicator, and outputs the optimization results.

8. A front-end system performance automated monitoring, analysis and processing device, characterized in that, The device includes: The pre-setting module is used to pre-set the performance indicator parameters that need to be monitored for the front-end system. The performance indicator parameters include: first load time, white screen time, document content load time, page resource load time, and resource load time. The metrics acquisition module is used to acquire preset performance metrics parameters that are needed for performance monitoring of the front-end system. The real-time data capture module is used to monitor and capture corresponding indicator data of the front-end system in real time according to preset performance indicator parameters. The data integration and cleaning module is used to integrate the captured indicator data, unify the data format, and perform data cleaning. The visualization generation module is used to generate corresponding visualization dashboards from the processed indicator data according to preset analysis requirements. The statistical analysis module is used to statistically analyze the response time, resource loading time, and user behavior of various indicators in the generated visual dashboard, and generate analysis results. The optimization module is used to optimize the performance of indicator data that does not meet the preset values ​​in the generated analysis results and output the optimization results.

9. A server, characterized in that, It includes a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors, wherein the one or more programs include methods for performing any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1-7.

Citation Information

Cited By

  • Method and device for observing and issuing requests of large model inference engine

    CN121581249A