Front-end page resource loading method, system and equipment and storage medium

Abstract

The invention relates to the technical field of data processing, and particularly provides a front-end page resource loading method, system and device and a storage medium, and the method comprises the steps: calculating a network quality score based on the round-trip time, effective bandwidth and packet loss rate collected in real time; constructing a DOM (Document Object Model) dependency tree through static analysis during compiling, identifying key resources required by first screen rendering, and dynamically adjusting resource priorities based on the key resources and viewport detection during operation; if the network quality score is less than, only loading the key resource; if the network quality score is between the maximum and the minimum, key resources are loaded, and non-key resources are loaded as required; and if the network quality score is greater than the real-time viewport detection result, loading all resources, predicting pages which the user may access based on the user historical behavior data and the real-time viewport detection result, and pre-loading target resources according to the network state. According to the invention, accurate matching between the loading strategy and the dynamic network condition is realized.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a method, system, device, and storage medium for loading front-end page resources. Background Technology

[0002] As web applications become increasingly complex, their resource volume grows exponentially. However, significant differences exist in users' network environments (such as 4G, 5G, Wi-Fi, and weak networks), leading to a severe imbalance between page loading performance and user experience. Existing front-end resource loading solutions have several limitations: First, most solutions employ static loading strategies, failing to dynamically adjust resource loading priorities and methods based on real-time changes in network quality (such as bandwidth, latency, and packet loss rate). Second, they lack effective predictive capabilities for user behavior, resulting in blind resource preloading and potential waste of valuable bandwidth. Furthermore, in complex architectures such as micro-frontends, full loading of sub-application resources can easily cause delays in main application initialization. Therefore, there is an urgent need in this field for a comprehensive optimization solution that can intelligently sense network status, accurately identify key resources, and perform predictive loading based on user intent to ensure a smooth and fast user experience under various network conditions. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a front-end page resource loading method, system, device and storage medium to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a method for loading front-end page resources, including: The network quality score is calculated based on real-time collected round-trip time, effective bandwidth, and packet loss rate. A DOM dependency tree is constructed through compile-time static analysis to identify key resources required for the first screen rendering, and resource priorities are dynamically adjusted based on these key resources and runtime viewport detection. If the network quality score is less than If the network quality score is within a certain range, only critical resources will be loaded; if the network quality score is within a certain range, only critical resources will be loaded. and In between, critical resources are loaded and non-critical resources are loaded as needed; If the network quality score is greater than Then, all resources are loaded and, based on user history behavior data and real-time viewport detection results, the pages that the user may visit are predicted, and target resources are preloaded according to network status. in, and The set network quality score threshold.

[0005] In one optional implementation, a network quality score is calculated based on real-time collected round-trip time, effective bandwidth, and packet loss rate, including: Real-time collection of network round-trip time, downlink bandwidth estimate, and packet loss rate obtained through custom speed testing; The effective bandwidth is calculated by subtracting the estimated downlink bandwidth from the packet loss rate. The network quality score is calculated using a linear weighted model based on the round-trip time, effective bandwidth, and packet loss rate.

[0006] In an optional implementation, the linear weighted model includes:

[0007] in, Round trip time, For effective bandwidth, For packet loss rate, , , These are the weights of the corresponding parameter items.

[0008] In one alternative implementation, a DOM dependency tree is constructed through compile-time static analysis to identify key resources required for the initial screen rendering, including: During the application building phase, a custom plugin for the packaging tool is used to perform static analysis from the specified entry file, parse the dependencies between JavaScript and CSS resources to build a resource dependency graph, and simulate the browser rendering process to identify the set of DOM nodes necessary for the first screen rendering. Mark the JavaScript and CSS files that the DOM node set directly depends on as critical resources; Based on the DOM structure and CSS styles, the initial positions of static resources such as images and fonts in the viewport are simulated and calculated, and static resources located in the first screen viewport are added as key resources. Output a structured manifest file containing the critical and non-critical resources. The manifest file contains at least a critical resource array and a non-critical resource array. The resource information in each array includes the resource path and size. The manifest file is deployed to the production environment along with the application code.

[0009] In an optional implementation, dynamically adjusting resource priorities based on the critical resources and runtime viewport detection includes: During application runtime, the manifest file is loaded, and the key resources in the manifest file are read; Use the IntersectionObserver API to monitor the visibility status of non-critical resources in the viewport; Based on the combination of the network quality score and the visibility status, the loading priority queue of non-critical resources is dynamically calculated and adjusted. Specifically, when non-critical resources enter or are about to enter the viewport, their loading priority will be increased; when the network quality score is less than... When non-critical resources that are not in the viewport are not loaded, lazy loading or placeholder replacement is implemented.

[0010] In an optional implementation, loading critical resources and loading non-critical resources on demand includes: Prioritize loading all critical resources in parallel; Initiate loading requests for non-critical resources in the order of the loading priority queue; For image resources among the non-critical resources, a progressive loading method is adopted, which includes first loading and displaying a low-resolution thumbnail, and then asynchronously loading the complete high-resolution image in the background.

[0011] In one optional implementation, based on user historical behavior data and real-time viewport detection results, the system predicts the pages the user may visit and preloads target resources according to network conditions, including: Maintain a preload priority queue, where each queue item contains a target page identifier and its corresponding priority score; Calculate the initial priority score based on historical behavioral data: For each potential target page, calculate its conditional probability of being redirected from the current page based on historical redirection data, and store this conditional probability as its initial priority score in the queue. Dynamically adjust priority scores based on real-time viewport detection: Monitor links pointing to target pages within the current page; when a link enters the viewport, start timing and accumulate its visible duration; when the link leaves the viewport, pause timing; based on the visible duration, dynamically adjust the priority score of the target page corresponding to the link in the queue according to a preset mapping relationship, where the longer the visible duration, the higher the priority score. Calculate the overall priority and trigger preloading: For each target page in the queue, the initial priority score calculated from historical behavior and the priority score adjusted by real-time viewport detection are weighted and summed to obtain the overall priority score; a preloading threshold is set according to the current network quality score: a lower threshold is used in a strong network environment to preload more pages, and a higher threshold is used in a weak network environment to preload fewer pages; for target pages in the queue whose overall priority score exceeds the preloading threshold, the preloading process of their resources is initiated.

[0012] Secondly, the present invention provides a front-end page resource loading system, comprising: The data acquisition module is used to calculate the network quality score based on real-time collected round-trip time, effective bandwidth, and packet loss rate; The resource classification module is used to construct a DOM dependency tree through compile-time static analysis, identify key resources required for the first screen rendering, and dynamically adjust resource priorities based on the key resources and runtime viewport detection. The first control module is used to handle situations where the network quality score is less than... If the network quality score is within a certain range, only critical resources will be loaded; if the network quality score is within a certain range, only critical resources will be loaded. and In between, critical resources are loaded and non-critical resources are loaded as needed; The second control module is used to determine if the network quality score is greater than... Then, all resources are loaded and, based on user history behavior data and real-time viewport detection results, the pages that the user may visit are predicted, and target resources are preloaded according to network status. in, and The set network quality score threshold.

[0013] Thirdly, a device is provided, comprising: The memory is used to store the front-end page resource loader; A processor is configured to implement the steps of the front-end page resource loading method as provided in the first aspect when executing the front-end page resource loading program.

[0014] Fourthly, a computer-readable storage medium is provided, on which a front-end page resource loader is stored, and when the front-end page resource loader is executed by a processor, it implements the steps of the front-end page resource loading method provided in the first aspect.

[0015] The beneficial effects of this invention are as follows: the front-end page resource loading method, system, device, and storage medium provided by this invention, through the construction of a quantitative network quality scoring model, achieve precise matching between loading strategies and dynamic network conditions, significantly improving the user experience under weak and unstable network conditions. By integrating compile-time static analysis and runtime viewport detection, it accurately identifies and prioritizes the loading of critical resources, ensuring first-screen speed, while intelligently loading non-critical resources on demand to avoid bandwidth waste. Based on user history and real-time intent, it predicts the next operation and preloads target resources according to network status, greatly improving the smoothness of page switching and achieving a "click-to-display" effect. The solution is universally applicable to single-page applications, multi-page applications, and micro-frontend architectures, possessing good versatility and implementability. Attached Figure Description

[0016] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0018] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0019] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0022] The front-end page resource loading method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the front-end page resource loading system runs on the computer device.

[0023] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a front-end page resource loading system. Depending on different requirements, the order of the steps in this flowchart can be changed, and some steps can be omitted.

[0024] like Figure 1 As shown, the method includes: S1. Calculate the network quality score based on the real-time collected round-trip time, effective bandwidth, and packet loss rate; S2. Construct a DOM dependency tree through compile-time static analysis, identify key resources required for the first screen rendering, and dynamically adjust resource priorities based on the key resources and runtime viewport detection; S3. If the network quality score is less than If the network quality score is within a certain range, only critical resources will be loaded; if the network quality score is within a certain range, only critical resources will be loaded. and In between, critical resources are loaded and non-critical resources are loaded as needed; S4. If the network quality score is greater than Then, all resources are loaded and, based on user history behavior data and real-time viewport detection results, the pages that the user may visit are predicted, and target resources are preloaded according to network status.

[0025] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0026] S101. Real-time collection of network round-trip time, downlink bandwidth estimate, and packet loss rate obtained through custom speed testing.

[0027] Collect round-trip time (RTT) and downlink bandwidth estimates: Directly read the RTT and downlink property values ​​through the browser's navigator.connection interface (i.e., Network Information API). Simultaneously, listen for the onchange event of this interface to update the data promptly when the network type changes (e.g., switching from WiFi to 4G).

[0028] Obtaining Packet Loss Rate Through Custom Speed ​​Testing: To address the issue of standard APIs not providing packet loss rate data, a lightweight proactive speed testing method is designed. Ten 1KB ping requests (e.g., HTTP requests using the HEAD method or WebSocket heartbeats) are repeatedly sent to a low-latency edge node. The number of requests that fail to receive a response is counted, and the packet loss rate (PacketLoss) is calculated using the following formula: PacketLoss = (Number of lost requests / 10) * 100%. Simultaneously, based on successful requests, the actual average round-trip time (actualRTT) is calculated as a supplement and verification to the RTT value provided by the API.

[0029] S102. The estimated downlink bandwidth is reduced based on the packet loss rate to calculate the effective bandwidth.

[0030] Considering that network packet loss can lead to a decrease in actual effective throughput, this step reduces the ideal bandwidth estimate to more accurately reflect the available bandwidth.

[0031] Specifically, the effective bandwidth is calculated using the following formula: EffectiveBandwidth = downlink * (1 - PacketLoss) / N Wherein, downlink is the estimated downlink bandwidth (in Mbps) obtained from the navigator.connection interface in S101, and PacketLoss is the packet loss rate (ranging from 0 to 1) obtained through custom speed testing in S101. N is a conservative estimation coefficient greater than or equal to 1, used to offset errors caused by network fluctuations. In a preferred embodiment, N = 2 is chosen, which means a more conservative reduction of the ideal bandwidth, thus making the strategy formulation more robust.

[0032] S103. Based on the round-trip time, effective bandwidth, and packet loss rate, the network quality score is calculated using a linear weighted model.

[0033] Linear weighted models include:

[0034] in, Round trip time, For effective bandwidth, For packet loss rate, , , These are the weights of the corresponding parameter items.

[0035] Based on the score, the network status is divided into three categories, corresponding to different loading strategies: Strong network (score less than 80): low network latency, sufficient bandwidth, and adopts a full resource loading + preloading strategy; Medium network (50≤score≤80): The network status is stable, loading critical resources + loading non-critical resources on demand; Weak network (score<50): High network latency and high packet loss rate. Only critical resources are loaded, and non-critical resources are replaced with placeholders (such as low-resolution images and text placeholders).

[0036] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0037] S201. During the application build phase, static analysis is performed from the specified entry file using a custom plugin of the packaging tool.

[0038] This step is achieved by developing a custom plugin for mainstream bundling tools such as Webpack or Vite. This plugin performs the following operations during the build process: Dependency analysis: Starting from the specified application entry file (such as src / main.js), it parses its import or require statements, recursively traverses all JavaScript modules and CSS files (such as via @import), and builds a complete resource dependency graph.

[0039] DOM Tree Simulation and First-Screen Identification: The plugin parses the project's initial HTML template (e.g., index.html) and the application's root component template / JSX structure. By simulating the browser's initial rendering process (ignoring dynamic JavaScript operations) and combining CSS styles (such as media queries, display: none, etc.), it identifies the set of DOM nodes that can be fully rendered within the viewport without scrolling and marks them as "required DOM nodes for the first screen." For example, for single-page applications, this is usually the root component. Inside, the content rendered directly under the initial route.

[0040] S202. Mark the JavaScript and CSS files that the DOM node set directly depends on as critical resources.

[0041] Following S201, the plugin analyzes which JavaScript modules (e.g., application initialization framework code, first-screen component logic code) and CSS files (e.g., first-screen styles) the rendering of these "essential DOM nodes for the first screen" directly depend on. It then adds the paths and sizes of these directly dependent resource files (obtained via the file system) to the critical resource list.

[0042] S203. Based on the DOM structure and CSS styles, simulate and calculate the initial position of static resources such as images and fonts in the viewport.

[0043] The plugin further analyzes the static resources referenced within the DOM nodes on the first screen, such as... The `src` attribute of the `` tag, the `background-image` property in CSS, and the `@font-face` rule are used. By calculating the CSS box model of the corresponding DOM elements for these resources (considering layout, margins, viewport width, etc.), it is determined whether their initial position is within the preset viewport range (usually the window size, such as 1920x1080). Static resources determined to be within the first screen (such as logo images, first screen background images, and the font used for the first screen text) are added to the critical resource list.

[0044] S204. Output the structured list file of the critical resources and non-critical resources.

[0045] After the analysis is complete, the plugin generates a structured manifest file named critical-resources.json. This file is in JSON format and contains two core arrays: "critical": Stores all critical resource objects. Each object contains path (the output path of the resource, such as static / js / main.abc123.js) and size (the size of the resource, in KB).

[0046] "nonCritical": Stores all objects that are not marked as non-critical resources, with the same information format as critical resources.

[0047] This manifest file, as part of the build artifacts, is output to the build directory (e.g., dist) and deployed to the production environment along with the application code.

[0048] Runtime dynamic loading phase (S205-S207) S205. During application runtime, load the manifest file and read the critical resources in the manifest file.

[0049] When the user's browser loads the application, before the main application logic (such as main.js) is executed, a lightweight resource loader asynchronously requests and parses the critical-resources.json manifest file using the fetchAPI. Upon successful parsing, all critical resources are loaded concurrently based on the records in the critical array of the manifest.

[0050] S206. Use the IntersectionObserver API to monitor the visibility status of non-critical resources in the viewport.

[0051] Simultaneously, the resource loading manager initializes an IntersectionObserver instance, configuring its root margin to '200px 0px' to detect elements 200 pixels in advance. This observer then begins listening for all DOM elements on the page that are related to non-critical resources, such as: The corresponding images in the nonCritical list element.

[0052] A container of modular components located outside the main view and requiring lazy loading. When these elements enter or leave the predefined observation area, the observer triggers a callback function.

[0053] S207. Based on the combination of the network quality score and the visibility status, dynamically calculate and adjust the loading priority queue of non-critical resources... The resource loading manager maintains a priority queue for non-critical resources. For each non-critical resource, its initial priority is determined by network score (e.g., sorted in ascending order of file size on a medium network).

[0054] Visibility Priority Boosting: When IntersectionObserver detects that a non-critical resource is about to enter the viewport (i.e., enter the rootMargin extended region), the resource loading manager will immediately boost the priority of that resource in the queue and may interrupt the loading of low-priority resources in progress, and load it first instead.

[0055] Weak network strategy: When the real-time network quality score is lower than the preset weak network threshold (e.g., 50 points), the manager performs strong optimization on all non-critical resources that are not in the viewport: image resources are replaced with extremely small Base64 placeholders or low-resolution versions, and JavaScript / CSS files are marked as "deeply lazy-loaded" and are only loaded when the user interaction clearly requires it (e.g., clicking a button), so as to maximize the smoothness of critical operations.

[0056] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0057] The resource loading manager continuously monitors changes in the network quality score (S). When the score is updated or a page is initialized, the manager compares the S score with a preset threshold and executes the corresponding loading strategy: S301. If S < 50 (weak network strategy): The resource loading manager immediately pauses loading requests for all non-critical resources.

[0058] Initiate loading requests for all critical resources (defined by the critical array in critical-resources.json) in parallel. Simultaneously, for critical image resources, request versions with compression parameters (e.g., quality=30) or in WebP format to further reduce file size.

[0059] For non-critical resources, implement replacement and delay: Image resources: Replace its src attribute with a lightweight SVG or Base64 placeholder.

[0060] JavaScript / CSS resources: Mark them as "deep lazy loading" so that loading is only triggered when a user action (such as clicking a button or scrolling to a specific area) explicitly requires it.

[0061] S302. If 50 ≤ S ≤ 80 (Medium network strategy: Load critical resources and load non-critical resources on demand): The core of this strategy is to prioritize the protection of critical resources and intelligently and systematically load non-critical resources. The specific implementation is as follows: Prioritize parallel loading of all critical resources: The resource loading manager first initiates requests for all critical resources concurrently (in parallel) to ensure that the content on the first screen is displayed as quickly as possible. This process does not wait for any non-critical resources.

[0062] Non-critical resources are loaded in order of priority queue: Non-critical resources are processed immediately after critical resources begin loading.

[0063] Queue Construction: The manager reads the nonCritical array and constructs an initial loading queue based on the resource type and size. In a preferred embodiment, the queue is ordered in ascending order of file size, prioritizing the loading of smaller resources (such as small icon SVGs and utility function JS) to avoid large resources blocking the loading of subsequent smaller resources.

[0064] Dynamic Adjustment: This initial queue is dynamically adjusted based on the real-time monitoring results of the IntersectionObserver in S206. When a non-critical resource element enters the pre-detection area (e.g., 200px outside the viewport), its priority is immediately raised to the front of the queue.

[0065] Sequential Requests: The resource loading manager initiates loading requests sequentially, starting from the head of this priority queue. By default, only one resource is loaded at a time to avoid network connection contention, but in cases of strong network conditions (such as S>70), the number of parallel requests can be increased appropriately.

[0066] Progressive loading of image resources: For images in non-critical resources, a progressive loading technique is used. Specifically, this is implemented as follows: Initial stage: The image's src attribute points to a low-resolution (e.g., 10% quality of the original) thumbnail version, or a very small (e.g., 1-2KB) blurry preview image. This thumbnail will load and display quickly.

[0067] Asynchronous replacement phase: After the thumbnail is loaded and displayed, the script asynchronously creates a new Image object in the background, whose src points to the full high-resolution image.

[0068] Replacement complete: After the high-resolution image has loaded, JavaScript replaces the `src` attribute of the original thumbnail element on the page with the cached high-resolution image URL, achieving a seamless transition. This process provides users with a perceptible loading experience from blurry to clear, effectively improving performance under medium and weak network conditions.

[0069] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0070] When the resource loading manager determines that the current network quality score (S) is greater than the preset strong network threshold (80 points), the strong network loading strategy is triggered. The core of this strategy is to "fully load the current page resources and intelligently preload page resources that may be accessed in the future".

[0071] S401. Full load of current page resources The resource loading manager immediately initiates loading requests for all critical and non-critical resources on the current page in parallel, without any delay or priority distinction, making full use of the high bandwidth advantage.

[0072] S402. Intelligent preloading of future page resources Simultaneously, the intelligent preloading module is activated, performing the following steps to predict and preload the target resources: (1) Maintain the preload priority queue The module initializes an empty array in memory as a preload priority queue. Each item in the queue is an object containing two properties: pageId (target page identifier, usually a URL path) and priorityScore (priority score, initially 0).

[0073] (2) Calculate the initial priority score based on historical behavior data Data source: The module reads the page navigation history stored in the user's browser's localStorage. The record format is {page: ' / current', next: ' / target', timestamp: 1620000000}.

[0074] Calculate the conditional probability: For each target page (such as product, about) that a user might jump from the current page (e.g., home), calculate the conditional probability of that jump. The formula is: P(product|home) = number of times the user jumps from home to product / total number of times the user jumps out of home.

[0075] Assign an initial score: Use the calculated conditional probability (e.g., 0.6) as the initial priority score for the target page and insert or update it in the preload priority queue.

[0076] (3) Dynamically adjust priority scores based on real-time viewport detection Listen for links: After the page loads, use the IntersectionObserver API to listen for all links pointing to pages within the site. Tag. Configure rootMargin to '200px 0px' to detect 200 pixels ahead.

[0077] Timing and Adjustment: When a link enters the observation area, the visible time of the target page corresponding to that link begins to accumulate (the start time is recorded using Date.now()).

[0078] The timer pauses when the link leaves the observation area.

[0079] Based on the cumulative viewing time (t, in seconds), the priority score is dynamically increased using a preset linear mapping function. For example, the function could be: Δscore = min(0.3, t / 10), meaning that 0.1 points are added for every 10 seconds of visibility, with a maximum of 0.3 points. This means that the longer a user watches a link, the higher the preloading priority of its corresponding page.

[0080] (4) Calculate the overall priority and trigger preloading Weighted summation: For each target page in the queue, calculate its overall priority score. The formula is: Overall score = (Historical behavior score * W) history )+(Real-time viewport adjustment* W viewport In a preferred embodiment, the weight is set to W. history = 0.7,W viewport = 0.3, based primarily on historical behavior, supplemented by real-time intent.

[0081] Set a dynamic threshold: The preload threshold (T) is dynamically set based on the network score. For example: T = 0.8 - (S - 80) * 0.01. This means that the better the network (the higher the S), the lower the threshold T can be set, thus allowing more pages to be preloaded (even if its overall score is not high).

[0082] Trigger preloading: For all target pages in the queue with a total score greater than the threshold T, initiate preloading. The preloading process is achieved by dynamically creating... <link rel="prefetch"> This can be achieved by using the `fetch()` API in conjunction with the `cache: 'force-cache'` option, which pre-caches the core JS / CSS resources of the target page (obtained through a predefined route-resource mapping table) in the browser.

[0083] In some embodiments, the front-end page resource loading system may include multiple functional modules composed of computer program segments. The computer programs of each program segment in the front-end page resource loading system may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) The function of loading front-end page resources.

[0084] In this embodiment, the front-end page resource loading system can be divided into multiple functional modules based on its functions, such as... Figure 2 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0085] The data acquisition module is used to calculate the network quality score based on real-time collected round-trip time, effective bandwidth, and packet loss rate; The resource classification module is used to construct a DOM dependency tree through compile-time static analysis, identify key resources required for the first screen rendering, and dynamically adjust resource priorities based on the key resources and runtime viewport detection. The first control module is used to handle situations where the network quality score is less than... If the network quality score is within a certain range, only critical resources will be loaded; if the network quality score is within a certain range, only critical resources will be loaded. and In between, critical resources are loaded and non-critical resources are loaded as needed; The second control module is used to determine if the network quality score is greater than... Then, all resources are loaded and, based on user history behavior data and real-time viewport detection results, the pages that the user may visit are predicted, and target resources are preloaded according to network status. in, and The set network quality score threshold.

[0086] Figure 3 The front-end page resource loading method provided in the embodiments of this application can be applied to devices. Those skilled in the art will understand that the device structure involved in the embodiments of this invention does not constitute a limitation on the device. A device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0087] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0088] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.

[0089] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0090] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0091] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0092] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0093] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0094] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or modules may be electrical, mechanical, or other forms.

[0095] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0096] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0097] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A method for loading front-end page resources, characterized in that, include: The network quality score is calculated based on real-time collected round-trip time, effective bandwidth, and packet loss rate. A DOM dependency tree is constructed through compile-time static analysis to identify key resources required for the first screen rendering, and resource priorities are dynamically adjusted based on these key resources and runtime viewport detection. If the network quality score is less than If the network quality score is within a certain range, only critical resources will be loaded; if the network quality score is within a certain range, only critical resources will be loaded. and In between, critical resources are loaded and non-critical resources are loaded as needed; If the network quality score is greater than Then, all resources are loaded and, based on user history behavior data and real-time viewport detection results, the pages that the user may visit are predicted, and target resources are preloaded according to network status. in, and The set network quality score threshold.

2. The method according to claim 1, characterized in that, A network quality score is calculated based on real-time collected round-trip time, effective bandwidth, and packet loss rate, including: Real-time collection of network round-trip time, downlink bandwidth estimate, and packet loss rate obtained through custom speed testing; The effective bandwidth is calculated by subtracting the estimated downlink bandwidth from the packet loss rate. The network quality score is calculated using a linear weighted model based on the round-trip time, effective bandwidth, and packet loss rate.

3. The method according to claim 2, characterized in that, The linear weighted model includes: in, Round trip time, For effective bandwidth, For packet loss rate, , , These are the weights of the corresponding parameter items.

4. The method according to claim 1, characterized in that, By constructing a DOM dependency tree through compile-time static analysis, the key resources required for the initial screen rendering are identified, including: During the application building phase, a custom plugin for the packaging tool is used to perform static analysis from the specified entry file, parse the dependencies between JavaScript and CSS resources to build a resource dependency graph, and simulate the browser rendering process to identify the set of DOM nodes necessary for the first screen rendering. Mark the JavaScript and CSS files that the DOM node set directly depends on as critical resources; Based on the DOM structure and CSS styles, the initial positions of static resources such as images and fonts in the viewport are simulated and calculated, and static resources located in the first screen viewport are added as key resources. Output a structured manifest file containing the critical and non-critical resources. The manifest file contains at least a critical resource array and a non-critical resource array. The resource information in each array includes the resource path and size. The manifest file is deployed to the production environment along with the application code.

5. The method according to claim 4, characterized in that, Based on the aforementioned key resources and runtime viewport detection, resource priorities are dynamically adjusted, including: During application runtime, the manifest file is loaded, and the key resources in the manifest file are read; Use the IntersectionObserver API to monitor the visibility status of non-critical resources in the viewport; Based on the combination of the network quality score and the visibility status, the loading priority queue of non-critical resources is dynamically calculated and adjusted. Specifically, when non-critical resources enter or are about to enter the viewport, their loading priority will be increased; when the network quality score is less than... When non-critical resources that are not in the viewport are not loaded, lazy loading or placeholder replacement is implemented.

6. The method according to claim 5, characterized in that, Load critical resources and load non-critical resources on demand, including: Prioritize loading all critical resources in parallel; Initiate loading requests for non-critical resources in the order of the loading priority queue; For image resources among the non-critical resources, a progressive loading method is adopted, which includes first loading and displaying a low-resolution thumbnail, and then asynchronously loading the complete high-resolution image in the background.

7. The method according to claim 1, characterized in that, Based on historical user behavior data and real-time viewport detection results, predict the pages a user might visit and preload target resources according to network conditions, including: Maintain a preload priority queue, where each queue item contains a target page identifier and its corresponding priority score; Calculate the initial priority score based on historical behavioral data: For each potential target page, calculate its conditional probability of being redirected from the current page based on historical redirection data, and store this conditional probability as its initial priority score in the queue. Dynamically adjust priority scores based on real-time viewport detection: Monitor links pointing to target pages within the current page; when a link enters the viewport, start timing and accumulate its visible duration; when the link leaves the viewport, pause timing; based on the visible duration, dynamically adjust the priority score of the target page corresponding to the link in the queue according to a preset mapping relationship, where the longer the visible duration, the higher the priority score. Calculate the overall priority and trigger preloading: For each target page in the queue, the initial priority score calculated from historical behavior and the priority score adjusted by real-time viewport detection are weighted and summed to obtain the overall priority score; a preloading threshold is set according to the current network quality score: a lower threshold is used in a strong network environment to preload more pages, and a higher threshold is used in a weak network environment to preload fewer pages; for target pages in the queue whose overall priority score exceeds the preloading threshold, the preloading process of their resources is initiated.

8. A front-end page resource loading system, characterized in that, include: The data acquisition module is used to calculate the network quality score based on real-time collected round-trip time, effective bandwidth, and packet loss rate; The resource classification module is used to construct a DOM dependency tree through compile-time static analysis, identify key resources required for the first screen rendering, and dynamically adjust resource priorities based on the key resources and runtime viewport detection. The first control module is used to handle situations where the network quality score is less than... If the network quality score is within a certain range, only critical resources will be loaded; if the network quality score is within a certain range, only critical resources will be loaded. and In between, critical resources are loaded and non-critical resources are loaded as needed; The second control module is used to determine if the network quality score is greater than... Then, all resources are loaded and, based on user history behavior data and real-time viewport detection results, the pages that the user may visit are predicted, and target resources are preloaded according to network status. in, and The set network quality score threshold.

9. A front-end page resource loading device, characterized in that, include: The memory is used to store the front-end page resource loader; A processor, configured to implement the steps of the front-end page resource loading method as described in any one of claims 1-7 when executing the front-end page resource loading program.

10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a front-end page resource loader, which, when executed by a processor, implements the steps of the front-end page resource loading method as described in any one of claims 1-7.

Images