Page monitoring method and device, equipment and medium

Abstract

The invention relates to a page monitoring method and device, equipment and a medium in the technical field of computers, and the method comprises the steps that a page loading event is responded, and whether a document object model constructed by a loaded page corresponding to the event is normal or not is monitored; when the document object model is normal, continuously monitoring the visible proportion of a target page element in the loaded page in the viewport, and judging whether the visible proportion reaches a preset visible threshold value or not; when the visible proportion reaches a preset visible threshold value, determining page loading duration between a loading start timestamp of the loaded page and a current timestamp; and when the document object model is abnormal or the page loading duration exceeds a preset time consumption threshold, determining that the page loading state is a white screen abnormal state, and constructing a corresponding error loading report to be reported to a preset visual monitoring panel. According to the method and the device, efficient and accurate page monitoring is realized, and the robustness of the web application is convenient to maintain.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a page monitoring method and corresponding apparatus, computer equipment, and computer-readable storage medium. Background Technology

[0002] With the rapid development of internet applications, page monitoring has become a crucial aspect of ensuring user experience. Therefore, effective page monitoring has become an important part of web development and operations. Traditionally, page monitoring relies on browser-provided completion events or network request status. For example, it might determine whether all page resources have been loaded by listening to Document Object Model (DOM) events such as ContentLoaded or load, or by setting a fixed time threshold; if the corresponding completion event is not triggered within that time, a loading timeout is considered to have occurred. Another common approach is to monitor page loading based on the success or failure of HTTP requests, inferring successful page loading by capturing the response status of network requests.

[0003] While these methods can reflect the basic state of page loading to some extent, they primarily focus on the timing of page resource requests or network connectivity, without delving into the underlying mechanisms of page rendering. Traditional monitoring methods, relying solely on surface-level event triggers or network state changes, often fail to identify anomalies that may occur during the Document Object Model (DOM) construction process. Even if a network request returns successfully, if problems arise during the DOM construction phase, such as script execution errors or style conflicts leading to content rendering failures, the user may still see a blank screen—the so-called white screen anomaly.

[0004] Therefore, traditional page monitoring technology, limited by its basic principles and technical means, has exposed significant problems in practical applications, resulting in low accuracy of existing technologies in detecting abnormal white screen states, making it difficult to meet the needs of modern web applications for efficient and accurate monitoring. Summary of the Invention

[0005] The primary objective of this application is to solve at least one of the aforementioned problems by providing a page monitoring method and corresponding apparatus, computer equipment, and computer-readable storage medium.

[0006] To achieve the various objectives of this application, the following technical solution is adopted: A page monitoring method provided for one of the purposes of this application includes the following steps: Respond to page load events and monitor whether the document object model built for the corresponding loading page is normal; When the document object model is normal, continuously monitor the visibility ratio of the target page element in the viewport within the loading page, and determine whether the visibility ratio reaches the preset visibility threshold. When the visibility ratio reaches a preset visibility threshold, the page loading time between the start loading timestamp and the current timestamp of the loading page is determined. When the document object model is abnormal, or the page loading time exceeds the preset time threshold, the page loading status is confirmed as a white screen abnormal state, and a corresponding error loading report is constructed and reported to the preset visual monitoring panel.

[0007] On the other hand, a page monitoring device provided to meet one of the purposes of this application includes an event response module, a visibility analysis module, a time consumption calculation module, and a white screen reporting module. The event response module is used to respond to page loading events and monitor whether the document object model constructed by the loading page corresponding to the event is normal. The visibility analysis module is used to continuously monitor the visibility ratio of target page elements within the loading page in the viewport when the document object model is normal, and determine whether the visibility ratio reaches a preset visibility threshold. The time consumption calculation module is used to determine the page loading time between the start loading timestamp and the current timestamp of the loading page when the visibility ratio reaches the preset visibility threshold. The white screen reporting module is used to confirm that the page loading state is a white screen abnormal state when the document object model is abnormal or the page loading time exceeds the preset time consumption threshold, and construct a corresponding error loading report to be reported to a preset visual monitoring panel.

[0008] In another aspect, a computer device provided for one of the purposes of this application includes a central processing unit and a memory, the central processing unit being used to invoke and run a computer program stored in the memory to perform the steps of the page monitoring method described in this application.

[0009] In another aspect, a computer-readable storage medium is provided to suit another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the page monitoring method, which, when invoked by a computer, performs the steps included in the method.

[0010] The technical solution of this application has many advantages, including but not limited to the following aspects: Firstly, this application effectively overcomes the limitations of traditional technologies that rely solely on surface-level events or network request status for monitoring. By detecting whether the Document Object Model (DOM) of a loading page is normal, it can capture potential problems in the early stages of the DOM processing phase during rendering, accurately pinpointing the root cause of white screen anomalies. This significantly improves the comprehensiveness and accuracy of anomaly detection, ensuring that anomaly alarms are triggered promptly once a DOM construction failure is detected, avoiding missed detections or misjudgments caused by blind spots in traditional technologies.

[0011] Secondly, after confirming that the document object model is normal, we further introduce real-time continuous monitoring of the visible proportion of target page elements in the viewport, and make judgments based on preset visibility thresholds. This allows page monitoring to not only focus on the completion of resource loading, but also on the rendering status of the content actually visible to the user. This effectively distinguishes the difference between apparent loading completion and actual content visibility, further enhancing the accuracy of white screen detection. At the same time, by calculating the page loading time and comparing it with preset time thresholds, we achieve a quantitative evaluation of loading efficiency, avoiding the situation of misjudging normal loading as abnormal due to long waiting times.

[0012] Furthermore, by combining two conditions—document object model anomalies and loading time exceeding limits—the system confirms the white screen anomaly and automatically generates a report with detailed error information, which is then uploaded to the visual monitoring panel in real time. This significantly improves the automation of anomaly handling and the convenience and efficiency of maintenance. Compared to general systems that only provide coarse-grained alerts based on simple event triggers or state changes, this application provides operations and maintenance personnel with intuitive diagnostic criteria. This not only shortens the problem-solving cycle but also supports the operations and maintenance team in quickly responding to and fixing problems, thereby significantly improving the robustness of web applications, ensuring user experience, and reducing the risk of user churn due to insufficient page monitoring. Attached Figure Description

[0013] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a typical embodiment of the page monitoring method of this application; Figure 2 This is a schematic block diagram of the page monitoring device of this application; Figure 3 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0014] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0015] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0016] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0017] Those skilled in the art will understand that the terms "client," "terminal," and "terminal device" as used herein include both devices that receive wireless signals, devices that only possess wireless signal receiver capabilities without transmission capabilities, and devices with receiving and transmitting hardware, devices that have receiving and transmitting hardware capable of bidirectional communication over a bidirectional communication link. Such devices may include: cellular or other communication devices such as personal computers or tablets, having single-line displays, multi-line displays, or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service) that can combine voice, data processing, fax, and / or data communication capabilities; PDAs (Personal Digital Assistants) that may include radio frequency receivers, pagers, internet / intranet access, web browsers, notebooks, calendars, and / or GPS (Global Positioning System) receivers; and conventional laptops and / or handheld computers or other devices that have and / or include radio frequency receivers. As used herein, "client," "terminal," and "terminal device" can be portable, transportable, installed in a means of transportation (air, sea, and / or land), or suitable and / or configured to operate locally and / or in a distributed manner, operating in any other location on Earth and / or in space. "Client," "terminal," and "terminal device" as used herein can also be a communication terminal, an internet access terminal, or a music / video playback terminal, such as a PDA, a MID (Mobile Internet Device), and / or a mobile phone with music / video playback capabilities, or a smart TV, set-top box, etc.

[0018] The hardware referred to by the names "server," "client," and "service node" in this application is essentially an electronic device with the equivalent capabilities of a personal computer. It is a hardware device with the necessary components revealed by the von Neumann architecture, such as a central processing unit (including an arithmetic logic unit and a control unit), memory, input devices, and output devices. The computer program is stored in its memory, and the central processing unit loads the program stored in the secondary storage into the main memory to run it, execute the instructions in the program, and interact with the input and output devices to complete specific functions.

[0019] It should be noted that the concept of "server" used in this application can also be extended to apply to server clusters. Based on network deployment principles as understood by those skilled in the art, the servers should be logically divided; physically, these servers can be independent yet accessible through interfaces, or they can be integrated into a single physical computer or a computer cluster. Those skilled in the art should understand this flexibility and should not use it to constrain the implementation of the network deployment method described in this application.

[0020] One or more of the technical features of this application, unless explicitly specified herein, can be deployed on a server and accessed by a client remotely calling the online service interface provided by the server, or can be directly deployed and run on a client for access.

[0021] Unless otherwise specified, all data involved in this application may be stored remotely on a server or on a local terminal device, as long as it is suitable for use by the technical solution of this application.

[0022] Those skilled in the art will understand that although the various methods in this application are described based on the same concept and thus present commonality among them, they can be performed independently unless otherwise specified. Similarly, the various embodiments disclosed in this application are all based on the same inventive concept; therefore, concepts expressed in the same way, as well as concepts that are appropriately changed for convenience but are expressed differently, should be understood equivalently.

[0023] Unless otherwise expressly stated, the various embodiments disclosed in this application can be combined in a cross-cutting manner to flexibly construct new embodiments, as long as such combination does not depart from the inventive spirit of this application and can meet the needs of the prior art or solve a certain deficiency in the prior art. Those skilled in the art should be aware of such modifications.

[0024] The page monitoring method of this application can be programmed into a computer program product and deployed on a client or server. For example, in an exemplary application scenario of this application, it can be deployed on the server of an e-commerce platform. In this way, the method can be executed by human-computer interaction with the process of the computer program product through a graphical user interface by accessing the interface opened after the computer program product is running.

[0025] Please see Figure 1 The page monitoring method of this application, in its typical embodiment, includes the following steps: Step S1100: Respond to the page load event and monitor whether the document object model constructed by the page loading corresponding to the event is normal; In client-side rendering mode, the client, i.e., the web application, loads the page and first responds to a page load event. Then, the client requests a basic framework page from the server, typically a document containing a small amount of HTML skeleton and JavaScript (script) application code. After this, the core rendering logic of the page enters a phase driven by the client-side JavaScript code, which is the crucial sub-stage of the page loading process—the page rendering stage.

[0026] To overcome the limitations of traditional technologies that rely on surface-level loading events and to accurately pinpoint the root causes of potential white screen errors, this step focuses on in-depth monitoring of the structure and state of the Document Object Model (DOM) built during the rendering phase. "Monitoring whether it's normal" here doesn't just refer to the success or failure of network requests, but rather delves into the browser's process of parsing and constructing the DOM. This technical solution can be implemented through one or more of the following embodiments: In one embodiment, a front-end performance monitoring library or interface, such as the NavigationTiming API, Resource Timing API, or Performance Timing API, can be used for objective timing analysis. Specifically, key performance timestamps, such as domInteractive (marking the time when the HTML document parsing is complete and the DOM tree is ready), can be monitored. By calculating the difference between domInteractive and the navigation start time (fetchStart), the time taken to build the DOM can be quantified. If this time exceeds a reasonable threshold set based on historical data or business scenarios, or if the relevant key timestamp (such as domComplete) does not appear within the expected time, it can be determined that there is an abnormal delay or interruption in the DOM construction process, which is considered an "abnormal" state.

[0027] In another embodiment, the DOMContentLoaded event can be listened to for state verification. This event is a native event triggered synchronously by the browser after the initial HTML document has been fully loaded and parsed, and the DOM tree has been built. In the monitoring logic, a timer linked to this event can be set. If the DOMContentLoaded event is not triggered within a preset time window, it strongly indicates that the document parsing or DOM tree building process encountered a blocking error (e.g., missing critical structured HTML tags, or failure of referenced synchronous scripts), preventing the DOM from entering a ready state, and should be judged as "abnormal".

[0028] In another embodiment, to achieve real-time, fine-grained monitoring of the DOM construction process, the MutationObserver API can be introduced. This API allows developers to register a callback to asynchronously observe changes in a specific DOM node or its subtree (such as the addition or deletion of child nodes, or the modification of attributes). In the early stages of page rendering, by applying a MutationObserver instance to the document object or document.documentElement (i.e., the element), the dynamic insertion process of DOM nodes can be continuously monitored, providing direct evidence that the DOM is being successfully constructed by JavaScript. Conversely, if the MutationObserver fails to capture any expected, substantial DOM structure changes within the expected script execution cycle, it may mean that the core scripts that build the DOM failed to execute or malfunctioned, also indicating an "abnormal" state.

[0029] Step S1200: When the document object model is normal, continuously monitor the visibility ratio of the target page element in the viewport within the loading page, and determine whether the visibility ratio reaches the preset visibility threshold. Successful page loading not only means the DOM tree is correctly constructed, but more importantly, the core visual content of the page must be successfully rendered and presented within the user's browser viewport. Even if the DOM structure is correct, if stylesheets fail to load, critical rendering elements are hidden (e.g., display: none), layout calculation errors cause content to be pushed out of the viewport, or asynchronously populated content fails to be injected as scheduled, the user may still see a blank or severely missing interface—essentially a white screen. Therefore, this step introduces continuous monitoring of the "visibility ratio of target page elements in the viewport" as an objective quantitative standard for determining whether the page has completed effective rendering.

[0030] Specifically, target page elements refer to key visual elements that represent the successful rendering of the main content of the page; these can be containers that carry the main information (such as...). <main>), core content blocks (such as those with specific identifiers) These elements are selected based on their central role in visual presentation; their visibility directly determines the user's perception of whether the page has loaded successfully. Those skilled in the art can use this information to configure elements as needed. Monitoring their "visibility within the viewport" involves the interaction between the browser rendering engine and the visual model. The browser viewport represents the area of ​​the webpage currently visible to the user, and the visibility of an element is determined by calculating the element's "intersection" with the viewport—that is, how much of the element actually lies within the viewport and is not obscured by other elements (CSS properties such as visibility and opacity also affect visibility determination).

[0031] To achieve efficient and low-performance continuous monitoring, one embodiment employs the Intersection Observer API provided by modern browsers. This API allows developers to asynchronously observe changes in the intersection state between a target element and its ancestor elements or the top-level document viewport. A callback function is triggered when the element's visibility ratio (represented by `intersectionRatio`) changes and reaches a set threshold. By configuring a preset visibility threshold (e.g., 50% or 80%) as the API's threshold, it is possible to determine whether the target element is sufficiently displayed to the user. It is easy to understand that the preset visibility threshold is used to measure whether the visible size of the target page element in the viewport is large enough; those skilled in the art can further configure it as needed based on this disclosure.

[0032] Continuous monitoring of this dynamic process begins when the DOM is confirmed to be normal and continues until the element's visibility ratio reaches a preset visibility threshold, or until the process enters the subsequent loading time determination stage. This ensures that monitoring covers the entire timeframe from DOM readiness to actual content rendering completion, including possible style calculations, layout, drawing, and subsequent rendering sub-stages such as asynchronous data population. By determining whether the visibility ratio reaches the preset visibility threshold, a quantifiable and programmable objective technical indicator is essentially established for the subjective state that "page content has been successfully rendered."

[0033] Step S1300: When the visibility ratio reaches a preset visibility threshold, determine the page loading time between the start loading timestamp and the current timestamp of the loading page; The Document Object Model (DOM) has been verified to be built normally, and the visibility of the target page element representing the main content of the page in the user's viewport has reached the preset visibility threshold. This means that the page has not only completed the underlying structure and logic construction, but also achieved a "effectively loaded" state at the visual rendering level, which allows the user to perceive the presentation of the core content.

[0034] The start loading timestamp refers to the initial moment when page navigation or the loading process begins. In a browser environment, in one implementation, this start moment can be precisely obtained using the `fetchStart` or `navigationStart` timestamps defined in the Navigation Timing API or the Performance Timing API. `fetchStart` indicates the moment the browser begins checking the cache or preparing to make a network request to retrieve the document, while `navigationStart` marks the moment when the previous document has been unloaded and navigation of the new page has officially begun. Using timestamps provided by such standard performance interfaces ensures the objectivity, consistency, and cross-browser comparability of the timing start point, laying a reliable benchmark for subsequent duration calculations.

[0035] The current timestamp refers to the moment when the visibility ratio of the target page element reaches a preset visibility threshold. This capture is tightly coupled with the continuous monitoring mechanism described in step S1200. When the Intersection Observer API detects that the target element's intersectionRatio reaches or exceeds the preset visibility threshold, the monitoring callback function is triggered. Within the execution context of this callback function, a high-precision timestamp can be recorded by calling the `performance.now()` method or obtaining the `Date.now()` value. The monotonically increasing high-resolution timestamp provided by `performance.now()` is particularly suitable for accurate performance measurement and effectively avoids errors caused by system time adjustments.

[0036] Based on the obtained start loading timestamp and current timestamp, the page loading time can be determined by subtracting the start loading timestamp from the current timestamp. This time essentially quantifies the complete waiting time from when a user initiates a page visit (or when the page begins loading) to when the user actually sees enough core content. It includes not only the time consumed by all underlying technical aspects such as network requests, HTML parsing, DOM construction, style calculation, layout, drawing, and compositing, but also the time taken up by dynamic interactive processes such as asynchronous data acquisition and rendering, and lazy loading of content. Therefore, it comprehensively and accurately reflects the loading performance or loading time experience perceived by the end user.

[0037] Step S1400: When the document object model is abnormal, or the page loading time exceeds the preset time threshold, confirm that the page loading status is a white screen abnormal status, and construct a corresponding error loading report to report to the preset visual monitoring panel.

[0038] It is understandable that an abnormal construction of the Document Object Model (DOM) directly means that the basic structure for page rendering has failed. Regardless of subsequent processes, the user terminal will inevitably be unable to obtain visible page content, constituting a fundamental rendering failure. Conversely, if the page loading time exceeds a preset time threshold, it indicates that even if the DOM is constructed normally and the content is eventually visible, the loading process has exceeded the time range tolerable by user experience or business logic. From a user experience perspective, this is equivalent to loading failure and can be broadly categorized as a "white screen" or "unavailable" state. Therefore, by comprehensively considering the technical feasibility of the underlying rendering process and the timeliness of the upper-layer loading process, if either of these conditions is not met, the page loading state is confirmed as a white screen abnormal state. The preset time threshold can be configured as needed by those skilled in the art based on the information disclosed herein.

[0039] After confirming that the page loading status is a blank screen abnormal state, the automated error reporting process is further executed, and the corresponding error loading report is constructed and reported to the preset visual monitoring panel. In one embodiment, when constructing an error loading report, if the document object model is abnormal, it is identified as a specific white screen abnormality type corresponding to the page loading state. This information may include details of missing key timestamps captured by the performance API in step S1100 (such as domInteractive not being triggered), DOM structure changes in a stagnant state detected by MutationObserver, or error stack information captured by JavaScript execution. These details, along with the current timestamp, page loading state, and its identification type, constitute the substantive content of the error loading report. If the page loading time exceeds a preset time threshold, it is identified as a specific white screen abnormality type corresponding to the page loading state. This is achieved by parsing the UserAgent and page resource path from the page retrieval request initiated by the client, obtaining the physical width and height of the user terminal screen using window.screen.width and window.screen.height, and obtaining the width and height of the visible area inside the browser window using window.innerWidth and window.innerHeight. These details, along with the current timestamp, page loading state, and its identification type, constitute the substantive content of the error loading report.

[0040] Error loading reports are submitted to the monitoring panel. This submission typically involves a client (such as a browser) initiating an HTTP request to the designated monitoring server interface, sending the prepared error loading report as part of the request. The monitoring server receives and persistently stores the report, then parses and processes the information, presenting it in a variety of formats such as charts, lists, and detail pages on the "visual monitoring panel." This allows operations and maintenance personnel to gain real-time and intuitive insights into the detailed circumstances surrounding online page white screen anomalies.

[0041] It is easy to understand from the above embodiments that, compared with the prior art, this application has many advantages, including at least: Firstly, this application effectively overcomes the limitations of traditional technologies that rely solely on surface-level events or network request status for monitoring. By detecting whether the Document Object Model (DOM) of a loading page is normal, it can capture potential problems in the early stages of the DOM processing phase during rendering, accurately pinpointing the root cause of white screen anomalies. This significantly improves the comprehensiveness and accuracy of anomaly detection, ensuring that anomaly alarms are triggered promptly once a DOM construction failure is detected, avoiding missed detections or misjudgments caused by blind spots in traditional technologies.

[0042] Secondly, after confirming that the document object model is normal, we further introduce real-time continuous monitoring of the visible proportion of target page elements in the viewport, and make judgments based on preset visibility thresholds. This allows page monitoring to not only focus on the completion of resource loading, but also on the rendering status of the content actually visible to the user. This effectively distinguishes the difference between apparent loading completion and actual content visibility, further enhancing the accuracy of white screen detection. At the same time, by calculating the page loading time and comparing it with preset time thresholds, we achieve a quantitative evaluation of loading efficiency, avoiding the situation of misjudging normal loading as abnormal due to long waiting times.

[0043] Furthermore, by combining two conditions—document object model anomalies and loading time exceeding limits—the system confirms the white screen anomaly and automatically generates a report with detailed error information, which is then uploaded to the visual monitoring panel in real time. This significantly improves the automation of anomaly handling and the convenience and efficiency of maintenance. Compared to general systems that only provide coarse-grained alerts based on simple event triggers or state changes, this application provides operations and maintenance personnel with intuitive diagnostic criteria. This not only shortens the problem-solving cycle but also supports the operations and maintenance team in quickly responding to and fixing problems, thereby significantly improving the robustness of web applications, ensuring user experience, and reducing the risk of user churn due to insufficient page monitoring.

[0044] In a further embodiment, step S1400, when the page loading time exceeds a preset time threshold, confirms that the page loading state is a white screen abnormal state and constructs a corresponding error loading report, including the following steps: Step S1410: Collect the basic loading information and context diagnostic information of the target page. The context diagnostic information includes any one or more of the following: network status information, key resource loading status information, and page error information. To provide a basis for subsequent anomaly attribution analysis, comprehensive multidimensional data related to the page loading process will be collected, and the collected data will be stored in a structured format (such as JSON format) as the input source for subsequent attribution analysis. Basic loading information refers to fundamental attribute data describing page loading, including but not limited to: the page URL (i.e., the page resource path), user agent information (User-Agent), start loading timestamp, current timestamp, the physical width and height of the user's terminal screen, the width and height of the visible area within the browser window, the page loading status, and its corresponding specific white screen anomaly type.

[0045] Contextual information refers to environmental factors and / or specific details that may affect the white screen error during loading, including but not limited to: Network status information: Key metrics such as network type (e.g., Wi-Fi, 4G, 5G), average signal strength, average latency (RTT), and average download speed are captured through the browser's navigator.connection API or NetworkInformation API during the loading process. This data reflects the impact of the network layer on loading performance; for example, resource request timeouts in weak network environments may lead to a white screen.

[0046] Critical resource loading status information: Utilize the Resource Timing API or a front-end performance monitoring library (such as WebVitals) to record the loading status of critical resources during page loading, including but not limited to: request time, response time, transmission time, status code (such as 200, 404, 500, etc.), and resource size of HTML documents, CSS stylesheets, JavaScript scripts, and core image resources. If critical CSS or JS resources fail to load (such as a 404 error) or are incomplete (such as a timeout), it will directly affect page rendering, resulting in a blank screen.

[0047] Page error messages: By listening to the `window.onerror` event, the `unhandledrejection` event (which catches unhandled Promise errors), and the `PerformanceError` interface, various errors occurring during page loading are collected, including script execution errors (such as syntax errors and type errors), resource loading errors (such as image loading failures), console error messages, and corresponding stack traces. These error logs are directly related to code-level issues that may cause a blank screen, such as JavaScript errors causing DOM manipulation to be interrupted.

[0048] Step S1420: Construct attribution credential information based on the basic loading information and context diagnostic information; The basic loading information and context diagnostic information are formatted in JSON format, and the formatted two are concatenated to obtain the attribution credential information.

[0049] Step S1430: Use a large language model to infer reference attribution information for the white screen abnormal loading based on the attribution credential information; The large language model is pre-trained to convergence using an extremely large corpus, acquiring the ability to generate text describing human language, and possessing accurate basic text semantic understanding and basic logical reasoning capabilities. The large language model can be selected from Bert, OPT, Chinchilla, PaLM, LLaMA, Alpaca, Vicuna, GPT3, GPT3.5, GPT4, ChatGPT, etc., and any one of them can be selected as needed.

[0050] The attribution credential information is embedded into a preset prompt template to obtain prompt text, which is then input into the large language model. The prompt template contains the attribution credential information to be embedded and an attribution task description text. An illustrative example is: {"Please analyze the following data and provide the reason for the blank screen: {Attribution credential information}"}.

[0051] It is understandable that the large language model, based on the semantic features of the input data, performs deep reasoning through a multi-layer Transformer structure to identify the causal logical relationship between the attribution basis data and the white screen anomaly (such as the causal relationship between broken resource dependency chains, script execution anomalies and rendering blockage), and finally generates reference attribution information in natural language form.

[0052] Step S1440: Construct an error loading report based on the attribution credential information and reference attribution text.

[0053] In one embodiment, attribution credential information can be concatenated with reference attribution text to form the substantive content of the error loading report.

[0054] In the recommended embodiment, based on the previous step, after obtaining the attribution credential information, a large language model can be used to infer a portion of the content in the attribution credential information upon which the reference attribution text is based. This portion of content is then specifically annotated in the attribution credential information. Those skilled in the art can flexibly implement this annotation, for example, by annotating this portion with a boolean field that is referenced in the inference, or by inserting a new JSON object into the attribution credential information where the value is the line number of the referenced portion of content in the attribution credential information. Subsequently, the annotated attribution credential information, along with the aforementioned reference attribution text, serves as the substantive content of the error loading report.

[0055] In this embodiment, by constructing multi-dimensional anomaly diagnostic criteria and ultimately generating a report, the efficiency of locating white screen anomaly issues is significantly improved. Upon confirming a loading timeout, the system systematically collects contextual diagnostic information such as network status, critical resource loading status, and page errors, forming a complete attribution credential dataset. More importantly, by introducing a large language model to intelligently analyze the attribution credentials, interpretable reference attribution information is automatically generated, effectively compensating for the technical deficiency of traditional monitoring systems that can only report anomalies but cannot provide in-depth causes. Thus, the attribution process, which originally relied on human experience, can be transformed into an automated diagnostic process, significantly lowering the operational threshold and greatly reducing anomaly handling time. Simultaneously, the structured error report integrates raw diagnostic data with machine-generated attribution conclusions, preserving the integrity of technical details while providing intuitive problem interpretation, promoting efficient collaboration across functional teams.

[0056] In a further embodiment, after determining the page loading duration between the start loading timestamp and the current timestamp of the loading page in step S1300, the following steps are included: Step S2400: When the document object model is normal and the page loading time does not exceed the preset time threshold, the loading page is successfully loaded as the target page. It's easy to understand that when everything is normal, the client will eventually successfully load the loading page into the target page, at which point the user will be able to see the complete and accurately displayed page content on the terminal where the client is running.

[0057] Step S2410: Obtain the monitoring dataset corresponding to the target page and report it to the visual monitoring panel, which includes the following steps: Step S2411: Obtain the duration of multiple loading stages of the target page using a preset performance monitoring component; The performance monitoring component can be implemented using the Performance Timing API. After the page loads, the component actively queries the high-precision timestamps exposed by this API, which are automatically recorded by the browser kernel in the rendering pipeline. These timestamps mark a series of standardized, technically defined key milestones, such as navigation start, DOM interactivity, DOM content loading completion (DOMContentLoadedEventEnd), page loading completion (loadEventEnd), first-paint, and first-contentful-paint. By calculating the differences between these adjacent key timestamps, the performance monitoring component can automatically deduce and structuredly output a series of loading phase durations with clear performance significance, such as: "DNS resolution time," "TCP connection time," "DOM construction time," "total resource loading time," "First Content Rendering Time (FCP)," and "Estimated Time to Interact (TTI)." These duration data are not a single overall loading time, but rather a breakdown of the overall user experience into multiple independently measurable stages such as the network layer, parsing layer, and rendering layer, thus providing a data foundation for accurately locating performance bottlenecks.

[0058] Step S2412: Obtain user behavior information generated by user operations on the target page using a preset user monitoring component, including the following steps: Step S24120: Listen for route change events and collect the first behavior information generated by the user's route hopping behavior; The user monitoring component rewrites (or proxies) the browser's native History API (including the pushState and replaceState methods) and simultaneously listens for native events such as hashchange and popstate. This allows for the creation of a monitoring layer that covers all front-end route change paths. When a user switches views, whether triggered by clicking a link or by a programmatic API call, this monitoring layer intercepts the route change event and records key data such as the target URL, timestamp, and redirection type, thus generating initial information.

[0059] Step S24121: Listen for user click events and collect the second behavior information generated by the user's valid click behavior; The user monitoring component captures all click interactions on the page by globally attaching listeners for the `click` and `touchstart` events to the document root node, leveraging event bubbling. To improve the value density of the collected data and avoid reporting invalid data, the component integrates filtering in its listening logic: a click is only considered a "valid click" to be recorded if the target element of the event has a predefined marker attribute (such as `data-log-id`). Subsequently, the component extracts and records the element identifier, coordinates, and trigger time of this click, forming a second set of behavioral information. This approach demonstrates a balanced design between comprehensive monitoring and precise data collection.

[0060] Step S24122: Listen for the target request initiation event and collect the third behavior information generated by the user's asynchronous script request behavior; The user monitoring component hijacks (Monkey-patch) the global XMLHttpRequest constructor and fetch API during initialization, embedding hook functions at key points such as request initiation and response return. When any user action (such as clicking a button to trigger form submission) causes the page to send an asynchronous HTTP request (i.e., an Ajax request) to the server, this request is processed by the hijacked interface of the component. The component synchronously records information such as the request URL, method, parameters, execution time, and response status, generating third-party information.

[0061] Step S24123: Construct user behavior information based on the first behavior information, the second behavior information, and the third behavior information; After collecting the first, second, and third behavioral information through the three monitoring channels mentioned above, the user monitoring component executes a data integration and construction process. The component sorts and merges the behavioral data from different channels according to time sequence, associates it with context, and adds unified session identifiers, page identifiers, and other metadata, ultimately constructing a complete, orderly, and traceable set of user behavior information.

[0062] Step S2413: Obtain error and exception data of the target page from a preset exception monitoring component, including the following steps: Step S24130: Listen for page error listener events and collect the first error information generated by page script execution exception; JavaScript, or scripting language, is the core language that drives dynamic content on a webpage. Syntax errors or runtime errors during its execution can directly cause the script to break down, which may lead to page malfunctions or rendering errors.

[0063] To capture the aforementioned errors, the exception monitoring component registers an error event listener globally during page initialization by calling `window.addEventListener('error')`. When an exception occurs during the execution of JavaScript code by the browser engine, this listener callback is automatically triggered. The event object passed to the callback function encapsulates a detailed description of the error (`error.message`), the address of the script file where the error occurred (`error.filename`), and key metadata such as the line number (`error.lineno`) and column number (`error.colno`) of the error location. To further obtain the context of the function call chain, the monitoring component parses the stack trace property (`error.stack`) in the `error` object. For example, using a parsing function like `parseStackFrames`, the stack information is converted into structured frame sequence data, thereby accurately tracing the root cause of the error. To avoid redundant reporting caused by repeated triggering of the same error within a short period, the monitoring component generates a unique error identifier based on the error type, error message, and filename, and uses this identifier for deduplication, reporting only the first occurrence of the specific error, thus forming the first error message.

[0064] Step S24131: Listen for asynchronous task exception events on the page and collect the second error information generated by the asynchronous task execution exception; Web applications widely adopt Promise-based asynchronous programming patterns. If exceptions thrown in such asynchronous tasks (such as fetch requests, setTimeout callbacks, and async / await functions) are not explicitly caught, they will become "unhandled Promise rejections," which will also corrupt the application state.

[0065] To capture the aforementioned errors, the exception monitoring component can use `window.addEventListener('unhandledrejection')` to globally listen for the `unhandledrejection` event. This event is triggered when any Promise is rejected and not handled by its own `.catch()` method or an upstream `try-catch` block in the call chain. The event object contains the rejected Promise object and its reason, which is typically an error object. However, considering the possibility that developers might use `try-catch` or `Promise.catch` but fail to re-throw the error, a better approach to more comprehensively capture all asynchronous error scenarios is to combine a plugin from a code compilation tool (such as Babel) to transform the source code during the build phase, automatically embedding error reporting logic into `try-catch` blocks and `Promise.catch` callbacks, or repackaging and re-throwing captured errors to the `unhandledrejection` event channel. This ensures that all exceptions on asynchronous execution paths are collected by a unified monitoring system, thereby generating the second error message.

[0066] Step S24132: Listen for page resource acquisition exception events and collect the third error information generated by resource loading exceptions; If static resources (such as images, scripts, and stylesheets) on which page rendering depends fail to load, it will directly result in missing visual content or the inability of functional scripts to execute. Resource loading errors will also trigger the browser's error event, but its event target (event.target) is a specific DOM element (such as...). , <script>, <link>）。

[0067] 为实现对上述错误的捕获，异常监控组件在实施步骤S24130的全局error事件监听基础上，可以在回调函数中增加判断逻辑：检查event.target的tagName属性，若其值为"IMG"、"SCRIPT"、"LINK"等标识资源标签的类型，则判定此次错误为资源加载失败。随后，采集事件目标元素的资源地址（src或href属性）、标签类型以及该元素的外层HTML片段等上下文信息，生成一份描述资源加载失败的专用报告，此即所述第三错误信息。

[0068] 步骤S24133、监听页面接口请求异常事件，采集接口交互异常产生的第四错误信息；页面与服务器之间的数据交互（API调用）是动态内容的核心，接口请求失败或返回错误状态将导致数据无法呈现。

[0069] 异常监控组件通过劫持（Monkey-patch）浏览器提供的原生网络请求接口来实现对此类异常的监控。具体地，组件使用代理函数（如proxyXmlHttp和proxyFetch）覆盖全局的XMLHttpRequest构造函数和fetch方法。在代理逻辑中，于请求发起（open, send）和响应返回（onloadend, then / catch）的关键节点植入钩子函数。通过监控HTTP响应状态码（例如，大于等于400的状态码通常表示客户端或服务器错误）、分析响应体中可能包含的服务端错误信息、以及捕获因网络问题导致的请求异常（如超时、断连），来判定接口交互是否失败。对于每一次被拦截的请求，监控组件会记录其请求URL、HTTP方法、请求耗时、响应状态码及响应体（或错误对象）等关键指标，形成所述第四错误信息。

[0070] 步骤S24134、基于所述第一错误信息、第二错误信息、第三错误信息及第四错误信息，构造所述错误异常数据。

[0071] 异常监控组件作为一个统一的错误数据汇聚与治理中心，将上述四个独立监控通道采集到的异构错误信息进行标准化、结构化与上下文关联。组件会为每一条错误信息附加统一的时间戳、页面会话标识（Session ID）、页面URL等元数据。所有处理后的错误信息被封装为预设的统一数据格式（例如一个名为ExceptionMetrics的JSON Schema），形成错误异常数据。进一步的实施例中，异常监控组件还可以通过集成用户行为追踪模块（例如引用一个如BehaviorStore的缓存），可以将错误发生时刻临近的用户操作序列（如点击、跳转）作为上下文关联到错误异常数据中，极大地丰富了错误诊断的维度。

[0072] 步骤S2414、由预设的录制监控组件获取所述目标页面的用户操作相对应的录屏数据，其中，包括如下步骤：步骤S24140、监听所述目标页面的用户操作事件，采用与监听所述用户操作事件的类型相匹配的预设的录制采样策略，获得录屏图像帧序列；录制监控组件在所述目标页面渲染完成并展示后，即启动如rrweb（record andreplay the web）等专业的Web录制库，开始持续监听页面上的用户操作事件。为了不对全部操作进行无差别、高频率的全量录制，而是采用了与事件类型相匹配的预设录制采样策略。组件针对不同类型的用户操作事件（如滚动事件、媒体事件、输入事件、鼠标移动事件）设定了差异化的采样规则。示范性举例，对于连续性的滚动或鼠标移动事件，采用定时采样策略（如每200毫秒采集一帧图像）；对于持续时间较长、状态变化相对缓慢的媒体播放事件，则采用较低的采样频率（如每1000毫秒采集一帧图像）；而对于离散的、能引起页面内容关键性变化的输入事件（如表单输入），则在输入开始前和输入完成（如触发blur事件）后这两个关键节点分别采集图像帧。由此，便可在每种事件完成后得到对应的至少一个图像帧，将这些图像帧按照时序先后排列形成对应事件的录屏图像帧序列。

[0073] 可见，基于事件类型和操作特性的差异化采样策略，精准地识别了不同交互对页面状态的影响粒度与速度。通过为高频、连续性但信息密度相对较低的操作（如鼠标移动）设置较低的采样率，而为低频、离散但能导致界面状态跃迁的操作（如表单提交）在关键节点进行捕获，在确保不遗漏重要操作序列的前提下，有效地过滤了大量中间过渡状态的冗余图像数据，从而生成一个由关键帧构成的、数据量大幅优化的录屏图像帧序列。当然本领域技术人员可根据此处揭示再按需另设采集频率。

[0074] 步骤S24141、当所述录屏图像帧序列的数据量不超过预设上报数据量时，本地存储该录屏图像帧序列，并判断本地存储的所有录屏图像帧序列的数据总量是否超过预设上报数据量；当新生成的某个录屏图像帧序列的数据量未超过一个预设上报数据量阈值（例如2MB，本领域技术人员可按需配置）时，该序列将被暂存于运行客户端终端的本地存储（如IndexedDB或内存缓存）中。随后，会判断当前在本地存储中累积的所有录屏图像帧序列的数据总量是否超过了所述预设上报数据量阈值。

[0075] 可以理解，上述实现能够优化网络请求的频次与效率。立即上报每一个微小的操作序列会产生大量细碎的HTTP请求，增加网络开销并可能对监控服务端造成压力。通过设置一个合理的数据量阈值进行本地聚合，可以将短时间内发生的多次用户操作所对应的多个录屏序列打包，为后续步骤进行一次性的、数据块更完整的传输做好准备，这符合网络传输中"减少请求次数、增大单次有效载荷”的通用优化原则。

[0076] 步骤S24142、当所述数据总量超过预设上报数据量时，取出所述本地存储的所有录屏图像帧序列作为录屏数据；当本地存储的录屏图像帧序列数据总量超过了预设上报数据量阈值时，触发实际上报动作。将取出本地存储的所有累积序列，合并作为本次上报的"录屏数据”。

[0077] 步骤S2415、基于所述多个加载阶段时长、用户行为信息、错误异常数据和录屏数据构造监控数据集。

[0078] 将以上的多个加载阶段时长、用户行为信息、错误异常数据和录屏数据整合一起，便是监控数据集。在推荐的实施例中，还可以在整合后进行压缩再得到压缩版的监控数据集。

[0079] 不难理解，对于上报监控数据集的具体时机，可以是在监控数据集中四种监控数据中的任一种监控数据或任意多种达到一定数据量时，即可构造出该监控数据集上报给可视化监控面板，例如步骤S24142揭示的上报时机。此处数据量可由本领域技术人员按需配置。在上报前，这些监控数据可以暂存在运行客户端的终端本地存储中。

[0080] 本实施例中，通过构建一套覆盖页面成功加载后全生命周期的、立体化的综合监控方案，实现了从"异常监测”到"全景感知”的能力延伸。该方案通过集成性能、用户行为、异常及操作录制四大监控组件，对已成功加载的目标页面进行持续性的全景数据采集。性能监控量化了各加载阶段的耗时，为用户体验评估提供了关键指标；用户行为监控通过路由跳转、点击、异步请求等多事件监听，精准刻画了用户的真实交互路径；异常监控则构建了覆盖脚本、资源、接口等的全链路错误捕获网络，确保运行时问题被全面记录。尤为关键的是，录制监控组件通过智能匹配操作事件的录制采样策略及数据量管控机制，在可控开销下实现了用户操作过程的视觉化留存，为复现复杂交互场景下的问题提供了直观证据。最终，通过融合上述多源异构数据构造监控数据集，本方案为运维和开发人员提供了一个集性能指标、用户行为、错误日志及操作录像于一体的全景监控视图。这不仅极大增强了复杂问题的回溯与诊断能力，使问题排查从依赖日志推测升级为"有数可查、有迹可循”的精准分析，而且为持续优化产品性能与交互体验提供了坚实的数据驱动基础，从而在保障应用稳定性的同时，显著提升了其可维护性与可进化性。

[0081] 请参阅图2，适应本申请的目的之一而提供的一种页面监测装置，是对本申请的页面监测方法的功能化体现，该装置包括事件响应模块1100、可见分析模块1200、耗时计算模块1300以及白屏上报模块1400，其中，事件响应模块1100，用于响应页面加载事件，监测该事件相对应的加载中页面所构建的文档对象模型是否正常；可见分析模块1200，用于当所述文档对象模型正常时，持续监控所述加载中页面内的目标页面元素在视口中的可见比例，并判断所述可见比例是否达到预设可见阈值；耗时计算模块1300，用于当所述可见比例达到预设可见阈值时，确定所述加载中页面的开始加载时间戳与当前时间戳之间的页面加载时长；白屏上报模块1400，用于当所述文档对象模型异常，或所述页面加载时长超过预设耗时阈值时，确认页面加载状态为白屏异常状态，并构造相对应的错误加载报告上报给预设的可视化监控面板。

[0082] 进一步的实施例中，所述白屏上报模块1400，包括：信息采集子模块，用于采集所述目标页面的基础加载信息和上下文诊断信息，所述上下文诊断信息包括网络状况信息、关键资源加载状态信息及页面错误信息中的任意一种或任意多种信息；信息构造子模块，用于基于所述基础加载信息和上下文诊断信息构造归因凭据信息；参考归因子模块，用于采用大语言模型基于所述归因凭据信息推理出白屏异常加载的参考归因信息；报告构造子模块，用于基于所述归因凭据信息和参考归因文本构造错误加载报告。

[0083] 进一步的实施例中，所述耗时计算模块1300之后，包括：加载成功子模块，用于当所述文档对象模型正常，且所述页面加载时长不超过预设耗时阈值时，将所述加载中页面成功加载为目标页面；报告上报子模块，用于获取所述目标页面相对应的监控数据集上报给可视化监控面板。

[0084] 进一步的实施例中，所述报告上报子模块，包括：性能监控单元，用于由预设的性能监控组件获取所述目标页面的多个加载阶段时长；用户监控单元，用于由预设的用户监控组件获取所述目标页面的用户操作所产生的用户行为信息；异常监控单元，用于由预设的异常监控组件获取所述目标页面的错误异常数据；录制监控单元，用于由预设的录制监控组件获取所述目标页面的用户操作相对应的录屏数据;构造集合上报单元，用于基于所述多个加载阶段时长、用户行为信息、错误异常数据和录屏数据构造监控数据集。

[0085] 进一步的实施例中，所述用户监控单元，包括：第一事件监听子单元，用于监听路由变化事件，采集用户的路由跳转行为产生的第一行为信息；第二事件监听子单元，用于监听用户点击事件，采集用户的有效点击行为产生的第二行为信息；第三事件监听子单元，用于监听目标请求发起事件，采集用户的异步脚本请求行为产生的第三行为信息；信息构造子单元，用于基于所述第一行为信息、第二行为信息、第三行为信息构造用户行为信息。

[0086] 进一步的实施例中，所述异常监控单元，包括：第四事件监听子单元，用于监听页面错误监听事件，采集页面脚本执行异常产生的第一错误信息；第五事件监听子单元，用于监听页面异步任务异常事件，采集异步任务执行异常产生的第二错误信息；第六事件监听子单元，用于监听页面资源获取异常事件，采集资源加载异常产生的第三错误信息；第七事件监听子单元，用于监听页面接口请求异常事件，采集接口交互异常产生的第四错误信息；数据构造子单元，用于基于所述第一错误信息、第二错误信息、第三错误信息及第四错误信息，构造所述错误异常数据。

[0087] 进一步的实施例中，所述录制监控单元，包括：第八事件监听子单元，用于监听所述目标页面的用户操作事件，采用与监听所述用户操作事件的类型相匹配的预设的录制采样策略，获得录屏图像帧序列；本地存储子单元，用于当所述录屏图像帧序列的数据量不超过预设上报数据量时，本地存储该录屏图像帧序列，并判断本地存储的所有录屏图像帧序列的数据总量是否超过预设上报数据量；存储取用子单元，用于当所述数据总量超过预设上报数据量时，取出所述本地存储的所有录屏图像帧序列作为录屏数据。

[0088] 为解决上述技术问题，本申请实施例还提供计算机设备。如图3所示，计算机设备的内部结构示意图。该计算机设备包括通过系统总线连接的处理器、计算机可读存储介质、存储器和网络接口。其中，该计算机设备的计算机可读存储介质存储有操作系统、数据和计算机可读指令，数据中可存储有控件信息序列，该计算机可读指令被处理器执行时，可使得处理器实现一种页面监测方法。该计算机设备的处理器用于提供计算和控制能力，支撑整个计算机设备的运行。该计算机设备的存储器中可存储有计算机可读指令，该计算机可读指令被处理器执行时，可使得处理器执行本申请的页面监测方法。该计算机设备的网络接口用于与终端连接通信。本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

[0089] 本实施方式中处理器用于执行图2中的各个模块及其子模块的具体功能，存储器存储有执行上述模块或子模块所需的程序代码和各类数据。网络接口用于向用户终端或服务器之间的数据传输。本实施方式中的存储器存储有本申请的页面监测装置中执行所有模块 / 子模块所需的程序代码及数据，服务器能够调用服务器的程序代码及数据执行所有子模块的功能。

[0090] 本申请还提供一种存储有计算机可读指令的存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行本申请任一实施例的页面监测方法的步骤。

[0091] 本领域普通技术人员可以理解实现本申请上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体（Read-Only Memory，ROM）等计算机可读存储介质，或随机存储记忆体（Ran文档对象模型 Access Memory，RAM）等。

[0092] 综上所述，本申请实现高效精准的页面监控，便于维护web应用的稳健性。

[0093] 本技术领域技术人员可以理解，本申请中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本申请中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本申请中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

[0094] 以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。< / script> < / main>

Claims

1. A method of page monitoring, characterized by, The method comprises the following steps: monitoring whether a document object model constructed by a loading-in-progress page corresponding to a page loading event is normal in response to the page loading event; when the document object model is normal, continuously monitoring a visible proportion of a target page element in the loading-in-progress page in a viewport and determining whether the visible proportion reaches a preset visible threshold; when the visible proportion reaches the preset visible threshold, determining a page loading duration between a start loading timestamp of the loading-in-progress page and a current timestamp; when the document object model is abnormal or the page loading duration exceeds a preset time consumption threshold, confirming that a page loading state is a white screen abnormal state and constructing a corresponding error loading report to be reported to a preset visual monitoring panel.

2. The page monitoring method of claim 1, wherein, when the page loading duration exceeds the preset time consumption threshold, confirming that the page loading state is the white screen abnormal state and constructing the corresponding error loading report, comprising the following steps: collecting basic loading information and context diagnosis information of the target page, wherein the context diagnosis information comprises any one or any multiple of network status information, key resource loading state information and page error information; constructing attribution credential information based on the basic loading information and the context diagnosis information; using a large language model to infer reference attribution information of the white screen abnormal loading based on the attribution credential information; constructing an error loading report based on the attribution credential information and the reference attribution text.

3. The page monitoring method of claim 1, wherein, after determining the page loading duration between the start loading timestamp of the loading-in-progress page and the current timestamp, comprising the following steps: when the document object model is normal and the page loading duration does not exceed the preset time consumption threshold, successfully loading the loading-in-progress page as the target page; obtaining a monitoring data set corresponding to the target page to be reported to the visual monitoring panel.

4. The page monitoring method according to claim 3, characterized by, obtaining the monitoring data set corresponding to the target page, comprising the following steps: obtaining, by a preset performance monitoring component, a plurality of loading stage durations of the target page; obtaining, by a preset user monitoring component, user behavior information generated by user operations of the target page; obtaining, by a preset exception monitoring component, error exception data of the target page; obtaining, by a preset recording monitoring component, screen recording data corresponding to user operations of the target page; constructing the monitoring data set based on the plurality of loading stage durations, the user behavior information, the error exception data and the screen recording data.

5. The page monitoring method according to claim 4, wherein obtaining, by the preset user monitoring component, the user behavior information generated by the user operations of the target page, comprising the following steps: listening to a route change event to collect first behavior information generated by a user route jump behavior; listening to a user click event to collect second behavior information generated by an effective click behavior of the user; listening to a target request initiation event to collect third behavior information generated by an asynchronous script request behavior of the user; constructing the user behavior information based on the first behavior information, the second behavior information and the third behavior information.

6. The page monitoring method of claim 4, wherein, obtaining, by the preset exception monitoring component, the error exception data of the target page, comprising the following steps: listening to a page error listening event to collect first error information generated by a page script execution exception; An asynchronous task exception event is listened to, and second error information generated by an asynchronous task execution exception is collected; An abnormal resource acquisition event is listened to, and third error information generated by a resource loading exception is collected; An interface request exception event is listened to, and fourth error information generated by an interface interaction exception is collected; Based on the first error information, the second error information, the third error information, and the fourth error information, the error exception data is constructed.

7. The page monitoring method of claim 4, wherein, The target page is obtained by a preset recording monitoring component. The user operation corresponding to the target page is recorded, and the following steps are included: A user operation event of the target page is listened to, and a preset recording sampling strategy matched with the type of the listened user operation event is used to obtain a recording image frame sequence; When a data amount of the recording image frame sequence does not exceed a preset reporting data amount, the recording image frame sequence is locally stored, and whether a total data amount of all locally stored recording image frame sequences exceeds the preset reporting data amount is determined; When the total data amount exceeds the preset reporting data amount, all locally stored recording image frame sequences are taken as recording data.

8. A page monitoring device, characterized by It includes: An event response module is configured to respond to a page loading event, monitor whether a document object model constructed by a loading-in-progress page corresponding to the event is normal, and monitor a visible proportion of a target page element in a viewport of the loading-in-progress page when the document object model is normal. A time consumption calculation module is configured to determine a page loading time length between a start loading timestamp and a current timestamp of the loading-in-progress page when the visible proportion reaches a preset visible threshold. A white screen reporting module is configured to confirm a page loading state as a white screen abnormal state when the document object model is abnormal or the page loading time length exceeds a preset time consumption threshold, and construct a corresponding error loading report to report to a preset visual monitoring panel. The central processing unit is configured to call and run a computer program stored in the memory to perform steps of the method of any one of claims 1 to 7.

9. A computer device comprising a central processing unit and a memory, characterized in that The computer program is stored in the form of computer readable instructions and is implemented according to the method of any one of claims 1 to 7. When the computer program is called and run by a computer, steps included in the corresponding method are performed.

10. A computer-readable storage medium, characterized in that, ​

Images