Front-end resource preloading method and computer program product
By capturing user interaction data on the client side and dynamically preloading resources using a lightweight prediction model, the problem of existing technologies being unable to respond to real-time changes in user behavior is solved. This enables personalized and real-time preloading of resources, improving page response speed and resource utilization efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHENGDU BOSS INNOVATION TECH CO LTD
- Filing Date
- 2026-03-05
- Publication Date
- 2026-06-05
Smart Images
Figure CN122153196A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and more specifically, to a front-end resource preloading method and a computer program product. Background Technology
[0002] In web applications, front-end resource preloading has become a widely adopted optimization technique to improve page loading performance and user interaction smoothness. Currently, the mainstream preloading solutions primarily rely on static configuration methods manually specified by developers, such as pre-declaring critical scripts or image resources in HTML using tags.
[0003] While such solutions alleviate loading latency to some extent, they have inherent limitations. Their preloading decision-making logic is static, offline, and group-oriented, and cannot respond to real-time behavioral changes of individual users in the current session. Summary of the Invention
[0004] In view of this, the purpose of this invention is to provide a front-end resource preloading method and a computer program product to at least partially improve the above-mentioned problems.
[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows: In a first aspect, embodiments of the present invention provide a front-end resource preloading method, including: Capture continuous user interaction data on the current page on the client side; Feature extraction is performed on the continuous interaction behavior data to generate a feature vector; The feature vector is input into a lightweight prediction model deployed on the client to obtain the expected interaction intensity of each interactive element on the current page. When the expected interaction intensity of at least one of the interactive elements meets the preloading condition, the target resource associated with the interactive element that meets the preloading condition is determined according to the predefined resource mapping table. By using a preload scheduler, the background download of each target resource is initiated to dynamically preload the front-end resources.
[0006] Optionally, the step of extracting features from the continuous interaction behavior data to generate a feature vector includes: Extract trajectory features, hover features, scroll features, and context features within a preset time period; wherein, the trajectory features include instantaneous velocity, instantaneous acceleration, trajectory curvature, and movement direction angle; the hover features include target element identifier, cumulative hover time, and hover stability; the scroll features include scroll percentage, average scroll speed, and prominent elements within the viewport; and the context features include currently interactive elements and page semantic keywords; The trajectory features, hovering features, scrolling features, and context features are combined into a feature vector of fixed length.
[0007] Optionally, the trajectory curvature is determined based on continuous operating position points by calculating the ratio of the chord height to the chord length of the formed chord; The movement direction angle is the angle between the operation position point and the center position of a candidate interactive element. The hovering stability is determined by calculating the variance or standard deviation of the position coordinates of the operation position point within the target element region; The protruding elements within the viewport are determined by calculating the visible area ratio of each element within the current viewport using the Intersection Observer API provided by the browser. The semantic keywords of the page are obtained by parsing the text content of the currently visible area and extracting them using the TF-IDF algorithm.
[0008] Optionally, the lightweight prediction model is a gradient boosting decision tree model or a lightweight neural network model; The lightweight neural network model includes an input layer, at least one hidden layer, and an output layer; wherein the dimension of the input layer matches the length of the feature vector; the at least one hidden layer is a fully connected layer, with 2 to 3 layers, each containing 32 to 64 neurons, and using the ReLU activation function; the output layer is a Softmax layer, used to output the expected interaction intensity of each interactive element in the current page.
[0009] Optionally, the step of inputting the feature vector into a lightweight prediction model deployed on the client to obtain the expected interaction intensity of each interactive element on the current page includes: The feature vector is input into the lightweight prediction model to obtain the original output values of each interactive element; The original output value is normalized to obtain the probability value of each interactive element being interacted with, which is used as the expected interaction intensity.
[0010] Optionally, when the expected interaction intensity of at least one of the interactive elements meets the preloading condition, determining the target resource associated with the interactive element that meets the preloading condition according to a predefined resource mapping table includes: Select the top K interactive elements with the highest expected interaction intensity that meet the preloading conditions as high-probability intent elements; From the resource mapping table, the resources associated with each of the high-probability intent elements are queried respectively, and the target resource list is obtained after merging. The resource mapping table is a JSON data structure that records the mapping relationship between the selector of interactive elements and at least one resource to be preloaded.
[0011] Optionally, the step of initiating background downloads of each of the target resources through a preloading scheduler to dynamically preload frontend resources includes: A preloading request is generated for each target resource, and a dynamic priority is assigned to it; wherein the dynamic priority is determined by the expected interaction intensity of the corresponding interactive element and the inherent priority of the target resource marked in the resource mapping table; Preload requests are sent to the browser in descending order of dynamic priority.
[0012] Optionally, the method further includes: If the target resource already exists in the browser cache, the creation of a duplicate request will be cancelled before a new preload request is created. Once a new round of predictions is generated, if any interactive element corresponding to a preloading request no longer meets the preloading conditions, the preloading request is immediately terminated.
[0013] Optionally, the method further includes: When a user is detected to have a real interaction with any interactive element on the current page, the feature vector generated in the time period before the real interaction and the corresponding real interactive element are used as training samples. The lightweight prediction model is incrementally learned and updated by mixing newly generated training samples with randomly retained historical training samples.
[0014] Secondly, embodiments of the present invention provide a computer program product, the computer program product including instructions, which, when executed on an electronic device, cause the electronic device to perform the method described in any of the above-mentioned embodiments.
[0015] This invention provides a front-end resource preloading method and computer program product. By continuously capturing user interaction behavior data in the current session in the client browser, extracting multi-dimensional features from the behavior data to generate a structured feature vector, and then inputting the feature vector into a lightweight prediction model deployed on the client, the model outputs the expected interaction intensity probability distribution of each interactive UI element in real time. Combined with a pre-set confidence threshold, network status awareness, and resource size constraints, the model makes dynamic decisions to determine the required preloaded resources. Finally, the client preload scheduler initiates background downloads, thereby accurately obtaining user intent, preloading the required resources in real time, and reducing the user's perceived waiting time.
[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 A schematic structural block diagram of an electronic device provided in an embodiment of the present invention; Figure 2 This is one of the flowcharts illustrating a front-end resource preloading method provided in an embodiment of the present invention; Figure 3 This is a second flowchart illustrating a front-end resource preloading method provided in an embodiment of the present invention. Figure 4 The third flowchart illustrates a front-end resource preloading method provided in this embodiment of the invention. Figure 5 The fourth flowchart illustrates a front-end resource preloading method provided in this embodiment of the invention. Figure 6 This is the fifth flowchart illustrating a front-end resource preloading method provided in an embodiment of the present invention.
[0019] Icons: 100 - Electronic device; 101 - Memory; 102 - Communication interface; 103 - Processor; 104 - Communication bus. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0021] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.
[0022] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0023] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0024] To implement the process steps and functions of the various examples of this invention, please refer to [link / reference]. Figure 1 , Figure 1 This is a schematic structural block diagram of an electronic device provided in an embodiment of the present invention. The electronic device 100 includes a memory 101 and a processor 103, which are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses 104 or signal lines. The memory 101 can be used to store software programs and modules, and the processor 103 executes the software programs and modules stored in the memory 101, thereby performing various functional applications and data processing.
[0025] Electronic device 100 can be, but is not limited to, a personal computer (PC), a server, a distributed computer, etc. It is understood that electronic device 100 is not limited to a physical server, but can also be a virtual machine on a physical server, a virtual machine built on a cloud platform, or any other computer that can provide the same functionality as the server or virtual machine. The operating system of electronic device 100 can be, but is not limited to, Windows, Linux, etc.
[0026] The memory 101 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.
[0027] The communication connection between the electronic device 100 and external devices is achieved through at least one communication interface 102 (which can be wired or wireless).
[0028] Processor 103 may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of this embodiment can be completed by integrated logic circuits in the hardware of processor 103 or by instructions in software form. Processor 103 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0029] Understandable. Figure 1 The structure shown is for illustrative purposes only; the electronic device 100 may also include components that are more advanced than those shown. Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.
[0030] The following is an exemplary description of the front-end resource preloading method provided by this invention. See [link to documentation]. Figure 2 The method includes, for example Figure 2 The following steps are described: S210: Capture continuous user interaction data on the current page on the client side.
[0031] Continuous interactive behavior data is a time-series raw event stream, triggered and collected in real time by the browser's native event system, including but not limited to: mouse movement events, pointer hover events, scrolling events, focus switching events, touch start events, and the coordinates, timestamps, event types, and target DOM element references of click events; data collection is continuously carried out in the context of the single HTML document currently being viewed by the user, with a sampling frequency of no less than 10Hz, to ensure the continuity and detail fidelity of the behavior trajectory.
[0032] S220: Extract features from continuous interaction behavior data to generate feature vectors.
[0033] The behavior sequence acquired by S210 is segmented into sliding windows with a fixed time window (e.g., 100–200 milliseconds); multi-dimensional feature calculation is performed on the event set within each window, and four types of information, namely trajectory dynamics, hovering tendency, scrolling context and page semantics, are fused to output a real number vector with a fixed dimension for machine learning model inference.
[0034] S230: Input the feature vector into a lightweight prediction model deployed on the client to obtain the expected interaction intensity of each interactive element on the current page.
[0035] The feature vector generated by S220 is input into a lightweight prediction model that has been pre-loaded into the browser's memory. This lightweight prediction model is embedded in the browser's runtime environment in a WebAssembly (WASM) or native JavaScript manner, with a model size controlled within 1MB and a single inference time of less than 10ms. The model receives the feature vector as input and outputs a set of scalar values, each corresponding to all DOM elements registered as interactive targets on the current page (marked by CSS selectors or the `data-predictable="true"` attribute). After being normalized by the Softmax function, the scalar values represent the probability that the user will have an explicit interaction (such as clicking, focusing, or submitting) with the corresponding element in the next moment. This probability is defined as the "expected interaction intensity".
[0036] S240: When the expected interaction intensity of at least one interactive element meets the preloading condition, determine the target resource associated with the interactive element that meets the preloading condition according to the predefined resource mapping table.
[0037] The system monitors the expected interaction intensity distribution output by the S230 in real time. When the intensity value of any interactive element exceeds a preset threshold (e.g., 0.65), it is determined that the preloading condition is met. Then, based on the element's CSS selector or unique data attribute (e.g., `data-intent-id`), the system queries the local JSON format resource mapping table. This mapping table is sent by the server along with the HTML when the page is initially loaded, or actively pushed via HTTP / 3 Server Push. Its content is a static key-value pair structure, clearly recording the URL of the resource to be preloaded associated with each interactive element and its type (e.g., `script`, `data`, `image`). The query results constitute the set of target resources to be loaded.
[0038] S250: By using a preload scheduler, the background download of each target resource is started to dynamically preload the front-end resources.
[0039] The preloading scheduler runs as an independent module in the browser's task queue, receiving the target resource list determined by S240. The scheduler calls the browser's native APIs (including `fetch()` in conjunction with `cache.put()`, or `importScripts()`) to initiate background resource retrieval requests. All requests are set to `priority="low"` or have their priority dynamically adjusted based on network conditions, without blocking the main page rendering process. After the resources are downloaded, they are automatically stored in the HTTP cache or Service Worker Cache, and can be immediately retrieved from the cache when the user actually triggers the corresponding interaction.
[0040] This method constructs a preloading system on the client side that integrates behavior perception, intent inference, resource decision-making, and background execution. It does not rely on server-side computation or group user data, but directly uses the current user's real-time interactive behavior (such as mouse movement trajectory, hovering, scrolling rhythm, etc.) as the sole input source. The prediction target is accurate to a specific DOM element on the page (such as a button or search box), rather than the entire page or route. All processing is completed within the browser, and the inference response is controlled at the millisecond level, ensuring that the preloading instruction is issued before the user actually clicks. Thus, without increasing the network transmission burden, it significantly improves the response speed of various interactive operations after the first screen (such as expanding menus, pop-up modal boxes, loading details).
[0041] In step S220, to enable the prediction model to effectively distinguish different user intent patterns and support subsequent high-precision interaction intensity calculations, the original event stream must be transformed into a structured, measurable, and physically meaningful numerical representation. Relying solely on event type or coarse-grained statistics (such as "total hover duration" or "total scroll count") cannot capture the dynamic evolution of behavior, nor can it reflect the user's current attention focus and operational tendencies. Therefore, this embodiment of the invention further specifies that feature extraction must simultaneously extract four orthogonal and complementary behavioral dimension features within a preset time window, including trajectory features, hover features, scrolling features, and contextual features. See also Figure 3 Step S220 may include the following steps: S221: Extract trajectory features, hovering features, scrolling features, and context features within a preset time period.
[0042] The trajectory features include instantaneous velocity, instantaneous acceleration, trajectory curvature, and movement direction angle; hovering features include target element identification, cumulative hovering time, and hovering stability; scrolling features include scrolling percentage, average scrolling speed, and prominent elements within the viewport; and contextual features include currently interactive elements and page semantic keywords.
[0043] Trajectory features, based on a continuous sequence of mouse / touch point coordinates within the window (`x1,y1,t1`…`x n ,y n ,t n Calculate: Instantaneous velocity is the ratio of the displacement to the time difference between two adjacent points, i.e. .
[0044] Instantaneous acceleration is the rate of change of adjacent velocity vectors, i.e., a = |v| i+1 v i | / (t i+1 t i ).
[0045] The trajectory curvature, based on continuous operation positions, is determined by calculating the ratio of the chord height to the chord length of the formed chord. Within the current time window, the first point `P1(x1,y1)`, the middle point `P2(x2,y2)`, and the last point `P3(x3,y3)` in the mouse / touchpoint trajectory sequence are taken; a chord segment is constructed with `P1` and `P3` as endpoints; the vertical distance from `P2` to this chord segment (i.e., the chord height `h`) is calculated, and the Euclidean length of `P1P3` (i.e., the chord length `l`) is also calculated; the final trajectory curvature is defined as the ratio `k = h / l`. This ratio ranges from `[0, 0.5]`, with a larger value indicating a higher degree of trajectory curvature, reflecting tentative turning or target correction behavior during user operation.
[0046] The movement direction angle is the angle between the operation position point and the center position of a candidate interactive element. For any candidate interactive element `E (whose DOM node is uniquely identified by a CSS selector), get its bounding rectangle within the current viewport using getBoundingClientRect(), and calculate its center coordinates (c...). x , c y ); Take the current operation position point P(x,y) (i.e., the coordinates of the latest `mousemove` event); then the movement direction angle θ is defined as a vector (c x x, c y The angle between y) and the positive horizontal direction (X-axis), calculated in radians according to standard mathematical convention: θ = atan2(c y y, c x x)`. This angle is used to quantify whether the user's cursor is moving towards the element, and is a key geometric basis for determining the directionality of the interaction intent.
[0047] Hover features are extracted from target elements within the window that trigger `pointerover` or `mouseenter` events. The target element identifier is determined by a unique CSS selector (such as `#search-input`) or the `data-intent-id` attribute value.
[0048] Cumulative hover time: Counts the total number of milliseconds that the element has been continuously hovered within the current window.
[0049] Hover stability is determined by calculating the variance or standard deviation of the position coordinates of the operation point within the target element's region: when the user hovers over the target element E, the relative coordinate sequence within the element's client area (the rectangle defined by `element.getBoundingClientRect()`) is collected {(u i ,v i )}, where u i = x i left_E, v i = y i top_E; Calculate the variances of the u-coordinate sequence and the v-coordinate sequence respectively: σ u ² = (1 / n)·Σ(u i ū)²,σ v ² = (1 / n)·Σ(vi )²; The final hover stability is defined as the average of the two: S = (σ u ² + σ v ²) / 2. The smaller this value is, the weaker the cursor jitter within the element area, indicating that the user's attention is highly concentrated; otherwise, it reflects a state of hesitation, scanning, or mis-hovering.
[0050] Scrolling characteristics are calculated by combining `window.scrollY` and `document.body.scrollHeight`: Scrolling percentage: scrollY / (scrollHeight innerHeight).
[0051] Average scrolling speed: The difference in scrolling offsets at the start and end times of the window divided by the time difference.
[0052] Elements protruding within the viewport: The visible area ratio of each interactive element in the current viewport is detected in real time through the browser's native `IntersectionObserver` API, and the element with the highest ratio is selected as the representative.
[0053] Contextual characteristics are obtained by comprehensively considering the page runtime state: Current interactive element: Records the currently focused element (`document.activeElement`) or the element recently triggered by the `focusin` event.
[0054] Page semantic keywords are obtained by parsing the text content of the current visible area and applying the TF-IDF algorithm: Call `document.querySelectorAll(" ")` to traverse all visible text nodes (filtering nodes with `display:none`, `visibility:hidden`, and `aria-hidden="true"`), and extract their `textContent`; perform lightweight preprocessing on the concatenated full text: convert to lowercase uniformly, remove punctuation and numbers, and tokenize into word tokens; after constructing the term frequency vector, filter it in combination with a preset general web page stop word list (including words such as "的", "和", "在", "to", "the", "and", etc.); finally, calculate the weight of each word token using the TF-IDF formula: TF-IDF(t) = TF(t) × log(N / DF(t)), where TF(t) is the frequency of occurrence of word token t in the visible text of the current page, and N is the total number of indexed pages across the site (provided by a configuration file sent by the server, e.g., 104 -10 5 ), DF(t) is the number of pages containing t (also from offline statistics on the server); the top 3 terms with the highest TF-IDF values are taken as "page semantic keywords".
[0055] S222: Combine trajectory features, hovering features, scrolling features, and context features into a fixed-length feature vector.
[0056] All numerical features extracted in S221 are concatenated in a predetermined order to form a fixed-dimensional real-number vector. The length of this vector is determined by the total number of feature terms (e.g., 6-dimensional trajectory features + 3-dimensional hovering features + 3-dimensional scrolling features + 4-dimensional context features = 16-dimensional). All components are linearly normalized to the [0,1] interval to ensure the consistency of data scale before inputting into the model.
[0057] In step S230, in order to balance inference speed, memory usage and prediction accuracy, in one possible implementation, the lightweight prediction model of this embodiment of the invention can be a gradient boosting decision tree model or a lightweight neural network model.
[0058] When using a gradient boosting decision tree model: Offline training is performed on the server using the LightGBM or XGBoost framework, generating a tree-structured serialized model file (e.g., .txt or .bin format). This file is compiled into a WASM module using a dedicated toolchain and loaded into the browser's memory via `WebAssembly.instantiateStreaming()`. The model input is a fixed-length feature vector generated by S222, and the output is the raw score (logit value) corresponding to each interactive element, without the need for additional activation functions.
[0059] When a lightweight neural network model is used, the lightweight neural network model includes an input layer, at least one hidden layer, and an output layer; wherein, the dimension of the input layer matches the length of the feature vector; at least one hidden layer is a fully connected layer, the number of which is 2 to 3, each containing 32 to 64 neurons, and using the ReLU activation function; the output layer is a Softmax layer, used to output the expected interaction intensity of each interactive element in the current page.
[0060] To ensure consistent comparability, interpretability, and downstream decision-making compatibility among different model outputs, the expected interaction strength must be obtained from the original output values after deterministic normalization. See [link to relevant documentation]. Figure 4 Step S230 may include: S231: Input the feature vector into the lightweight prediction model to obtain the original output values of each interactive element.
[0061] S232: Normalize the original output values to obtain the probability values of each interactive element being interacted with, which are used as the expected interaction intensity.
[0062] The fixed-length feature vector generated by S222 is input into the lightweight prediction model. After the model performs inference, it outputs a sequence of real numbers of dimension N [s1, s2, ..., s]. n ], where N is the total number of registered interactive elements on the current page (dynamically obtained and cached through DOM traversal), and each s i For the corresponding element a i The original score (logit value). This score has not undergone any nonlinear transformation, retains the original discriminative ability of the model, and is the sole input source for normalization.
[0063] For the original score vector [s1, s2, ..., s...] n Perform standard Softmax normalization, the calculation formula is as follows:
[0064] Where, p i That is, element a i The probability estimate of the user's next interaction is strictly within the interval (0, 1), and all p... i The sum of these values is always equal to 1. This probability value is defined as the "expected interaction strength" and is directly used to determine the threshold of the preloading conditions in S240.
[0065] To improve resource loading efficiency and avoid redundant requests while ensuring prediction accuracy, this embodiment of the invention further stipulates that the process of determining the target resource must include two inseparable steps: intent pruning based on intensity ranking and cross-intent resource sharing and merging. See also Figure 5 Step S240 may include: S241: Select the top K interactive elements with the highest expected interaction intensity that meet the preloading conditions as high-probability intent elements.
[0066] S242: From the resource mapping table, query the resources associated with each high-probability intent element, and merge them to obtain the target resource list; the resource mapping table is a JSON data structure that records the mapping relationship between the selector of interactive elements and at least one resource to be preloaded.
[0067] Maintain a real-time interaction strength p according to the expected value. i A list of candidate elements sorted in descending order; when any element's p i When the value reaches a preset threshold, it is determined that the preloading condition is met; subsequently, p is selected from the set of conditions met. iThe top K elements with the highest values (K is an integer constant, e.g., K = 3) constitute the set of high-probability intention elements {a1, a2, ..., a...} k The size of this set is strictly constrained by K, which prevents resource loading from becoming excessive due to intent divergence while preserving the robustness of multi-path prediction (e.g., a user may click "view details" or "add to cart," both of which are high-probability intents).
[0068] Retrieve all resources corresponding to each high-probability intent element, merge them, and since each element may require the same resources, deduplication can be performed during the merging process to obtain the target resource list. This target resource list contains the resources that need to be preloaded.
[0069] In one alternative implementation, see [link to implementation details]. Figure 6 Step S250 may include the following steps: S251: Generate a preload request for each target resource and assign it a dynamic priority; wherein the dynamic priority is determined by the expected interaction intensity of the corresponding interactive element and the inherent priority of the target resource marked in the resource mapping table.
[0070] S252: Send preload requests to the browser in descending order of dynamic priority.
[0071] Iterate through each resource in the target resource list output in step S242 and assign it a scalar value, i.e., dynamic priority. This value can be calculated using the following formula:
[0072] in, Indicates target resource Dynamic priority, For target resources The expected interaction intensity value of the corresponding element, if the target resource If only a single intent element is associated, the value is directly taken as the expected interaction intensity value of that element. If the target resource... If shared by multiple intent elements, this value is the maximum of the expected interaction intensity values of all associated intent elements. Indicates target resource Type identifiers declared in the resource mapping table, such as "script", "data", "image", "font", or "style". It is a preset resource type weight function.
[0073] Calculate each resource in the target resource list After determining the dynamic priority, the preloaded scheduler executes the following ordered scheduling process: Request sorting: The preloading scheduler sorts all resources in the target resource list in strict descending order according to their respective dynamic priority values, generating an ordered request queue Q. This queue ensures that the highest priority resource is at the front.
[0074] Sequential request initiation: The scheduler initiates preload requests for each resource in the order of the queue.
[0075] Network Awareness and Control: Before initiating each request, the scheduler checks the client's current network status. If the network is determined to be unavailable or of extremely poor quality, the current request can be skipped and the status recorded to adapt to harsh network environments. Under high-speed Wi-Fi, multiple resources can be preloaded simultaneously; under slow cellular networks, the concurrency can be limited to 1, or even the preloading of non-critical resources can be paused.
[0076] To address the two long-standing, interdependent structural flaws in existing front-end preloading technologies—"spatial redundancy" and "temporal mismatch"—and ensure that preloading behavior strictly matches the user's true intent in any user interaction scenario, truly achieving an intelligent balance between "improving loading speed" and "avoiding resource waste," this method may also include: S253: If the target resource already exists in the browser cache, cancel the creation of duplicate requests before creating new preload requests.
[0077] Before step S252 is executed, the currently pending resources are... (From ordered queue Q) Perform a forced cache probe. This probe is completed via the following doubly deterministic path: HTTP cache probing: Use browser-provided caching interfaces (such as Service Worker's CacheAPI) or performance timeline interfaces (such as performance.getEntriesByName) to query whether the resource has been cached or is being loaded.
[0078] Memory / Disk Cache Probing: A lightweight cache index table (e.g., a Map object) is maintained in the client's memory to proactively record resource identifiers (such as URLs) that have been successfully requested and cached by this preloading system. When any preloading request completes successfully (e.g., the corresponding load event is triggered or a fetch request returns a successful response), the system automatically updates this index table, marking the resource as "cached".
[0079] If any of the above probing paths returns a positive result, indicating that the resource already exists in the client cache or is being loaded, the preload scheduler will immediately terminate the creation process for this request for that resource. This means that no new DOM element will be created for the resource, and no new network API calls will be initiated, thus completely avoiding redundant operations.
[0080] This request deduplication mechanism brings the following beneficial effects: Saves network resources: Directly avoids the network overhead caused by establishing unnecessary TCP connections, performing TLS handshakes, and transmitting duplicate HTTP messages.
[0081] Improve the performance of critical requests: Prevent the limited browser concurrent connections from being occupied by redundant requests, ensure that high-priority critical resource requests can obtain network connections in a timely manner, and reduce queuing delays.
[0082] Reduced user costs: Especially in cellular network environments, it effectively reduces users' unnecessary data traffic consumption. In real-world applications (such as e-commerce pages), this mechanism can prevent an average of trillions of redundant data transmissions per user session.
[0083] S254: After a new round of predictions is generated, if any interactive element corresponding to a preloading request no longer meets the preloading conditions, the preloading request will be immediately terminated.
[0084] Step S254 addresses the shortcomings of existing preloading technologies. Traditional solutions, once preloading is initiated, continue until completion or timeout regardless of changes in user behavior, resulting in a large number of "completed but useless" resource downloads. This invention introduces a dynamic termination mechanism that strongly binds the request lifecycle to the timing output of the prediction model. This mechanism can terminate unnecessary preloading requests with millisecond-level response speeds when user intent shifts.
[0085] The preload scheduler associates a unique, browser-provided abort controller (such as an AbortController instance) with each successfully initiated preload request. This abort controller provides a programmable abort signal interface for the corresponding network request.
[0086] A new round of user intent prediction is performed at fixed time intervals. Each time a new round of prediction is completed and a new expected interaction intensity distribution is generated, the intent drift detection process is immediately initiated. Iterate through all ongoing preload requests and obtain the original intent element served by each request and its associated abortable controller.
[0087] For each ongoing request, query the latest expected interaction strength value corresponding to its original intent element in the new round of prediction.
[0088] The request is evaluated based on preset termination criteria to determine whether it has become invalid. For example, if the latest intensity value of the intent element is lower than the preloading confidence threshold, the basic conditions for triggering preloading are no longer met; if the intensity value of the intent element decreases by more than a dynamic threshold (e.g., a decrease of more than 0.2) compared to the previous prediction result, this indicates that the user's attention or operational intent has significantly shifted.
[0089] If any of the conditions are met, it is determined that the "intent has drifted" for the requested service, and the operation is immediately terminated.
[0090] Once the abort decision is made, an instruction is immediately sent to the browser by calling the abort method (e.g., abort()) of the abortable controller associated with the request. The browser will then terminate the corresponding network request, release the TCP connection, and mark the downloaded but incomplete data as disposable.
[0091] Current solutions all employ a static model deployment model, where the model is trained and then permanently deployed on the server, and the client only performs inference. To optimize the prediction model, feedback and online learning can be implemented. This method also includes: S260: When a user is detected to have a real interaction with any interactive element on the current page, the feature vector generated in the time period before the real interaction and its corresponding real interactive element are used as training samples.
[0092] To enable personalized incremental learning of the model, the training sample generation process is automatically triggered when explicit, genuine user interactions are detected. Step S260 ensures that the training data strictly originates from the user's genuine intent feedback, providing high-quality supervision signals for the online updating of the model.
[0093] Training samples are generated based on specific explicit real-world user interaction events, including but not limited to mouse clicks, form submissions, focus shifts, and specific key presses. Interaction data is collected only from page elements that have been marked as interactive targets (e.g., elements matched by a custom attribute `data-predictable="true"` or a specific CSS selector).
[0094] When the above triggering conditions are met, a training sample is constructed according to the following rules: Time window backtracking: Extracts all temporal feature vectors generated by the feature extraction module within a preset time period (denoted as T) prior to the occurrence of the actual interaction event. In one optional implementation, this time T is set to 2 seconds.
[0095] Tag binding: The DOM element that triggered the interaction (i.e., the target element actually manipulated by the user) is used as the unified real tag for all feature vectors within the aforementioned time period. This tag is usually represented by a unique identifier for the element (such as a CSS selector string).
[0096] Sample format: The final generated single training sample is a structured data tuple in the form (Ft1, Ft2, ..., Ft). n e true ). Among them, Ft i This represents the feature vector generated at the i-th time point within the time window, where n is the total number of vectors within the window, and e true This refers to the actual label mentioned above.
[0097] S270: Incremental learning updates of a lightweight prediction model are performed by mixing newly generated training samples with randomly retained historical training samples.
[0098] To enable online learning of the prediction model on the client side, a refined workflow involving sample mixing and parameter updates is implemented. This workflow aims to efficiently utilize newly collected feedback data while maintaining the model's general performance and preventing "catastrophic forgetting" caused by continuously learning new samples.
[0099] The client maintains a fixed-capacity historical training sample pool to store past training samples. When newly generated training samples are produced, a random retention and replacement strategy is used to add them to the sample pool. The new samples are retained with a high probability (e.g., 95%).
[0100] At the same time, an old sample in the sample pool is randomly discarded with a low probability (e.g., 5%) to ensure that the capacity of the sample pool is stable and the content is continuously updated.
[0101] This strategy ensures that the model training data includes both the latest user behavior patterns and a sufficient amount of historical common patterns (such as the common "hover-click" rule), which is a key mechanism to prevent the model from "catastrophic forgetting".
[0102] When the model update trigger condition is met, instead of directly using all new samples for training, a mixed training batch is constructed: A certain number of historical samples are randomly selected from the historical sample pool.
[0103] At the same time, some new samples are selected from the latest batch of samples.
[0104] These two sample groups are merged to form a mixed training batch for this model update.
[0105] In one optional implementation, the ratio of historical samples to new samples in the mixed batch is approximately 4:1. This ratio strikes a good balance between enabling the model to quickly adapt to new user behaviors and maintaining the stability of model predictions.
[0106] Model updates are not performed in real time, but are triggered when any of the following conditions are met: Data volume condition: The cumulative number of newly generated samples reaches a preset threshold.
[0107] Time condition: The time interval since the last model update exceeds a preset duration (e.g., 24 hours).
[0108] This dual-trigger mechanism ensures timely updates while avoiding the computational overhead of overly frequent updates. The update process is executed asynchronously in a background thread on the client (such as a Web Worker) to avoid blocking the main thread of the user interface. The update method depends on the model type: For gradient boosting decision tree models, call their online learning interface (such as the partial_fit method) and perform an incremental training round using the hybrid training batch.
[0109] For lightweight neural network models, a stochastic gradient descent algorithm is used to perform a single parameter update. The parameter update formula can be expressed as:
[0110] in, For model parameters, For learning rate, For loss function, The gradient represents the loss information.
[0111] In summary, the front-end resource preloading method and computer program product provided by this invention achieve millisecond-level, element-level, adaptive, and evolvable front-end resource preloading by constructing a five-in-one technical system on the browser side, which integrates multi-dimensional behavioral feature extraction, lightweight model end-side inference, intent-driven resource scheduling, intelligent management of request lifecycle, and feedback closed-loop online learning. This fundamentally solves the dual structural defects of spatial redundancy and temporal mismatch in traditional static preloading.
[0112] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0113] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0114] If the functionality is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0115] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
[0116] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.
Claims
1. A method for preloading front-end resources, characterized in that, include: Capture continuous user interaction data on the current page on the client side; Feature extraction is performed on the continuous interaction behavior data to generate a feature vector; The feature vector is input into a lightweight prediction model deployed on the client to obtain the expected interaction intensity of each interactive element on the current page. When the expected interaction intensity of at least one of the interactive elements meets the preloading condition, the target resource associated with the interactive element that meets the preloading condition is determined according to the predefined resource mapping table. By using a preload scheduler, the background download of each target resource is initiated to dynamically preload the front-end resources.
2. The method according to claim 1, characterized in that, The step of extracting features from the continuous interaction behavior data to generate a feature vector includes: Extract trajectory features, hover features, scroll features, and context features within a preset time period; wherein, the trajectory features include instantaneous velocity, instantaneous acceleration, trajectory curvature, and movement direction angle; the hover features include target element identifier, cumulative hover time, and hover stability; the scroll features include scroll percentage, average scroll speed, and prominent elements within the viewport; and the context features include currently interactive elements and page semantic keywords; The trajectory features, hovering features, scrolling features, and context features are combined into a feature vector of fixed length.
3. The method according to claim 2, characterized in that, The trajectory curvature is determined based on continuous operating position points by calculating the ratio of the chord height to the chord length of the formed chord. The movement direction angle is the angle between the operation position point and the center position of a candidate interactive element. The hovering stability is determined by calculating the variance or standard deviation of the position coordinates of the operation position point within the target element region; The protruding elements within the viewport are determined by calculating the visible area ratio of each element within the current viewport using the Intersection Observer API provided by the browser. The semantic keywords of the page are obtained by parsing the text content of the currently visible area and extracting them using the TF-IDF algorithm.
4. The method according to claim 1, characterized in that, The lightweight prediction model is a gradient boosting decision tree model or a lightweight neural network model. The lightweight neural network model includes an input layer, at least one hidden layer, and an output layer; wherein the dimension of the input layer matches the length of the feature vector; the at least one hidden layer is a fully connected layer, with 2 to 3 layers, each containing 32 to 64 neurons, and using the ReLU activation function; the output layer is a Softmax layer, used to output the expected interaction intensity of each interactive element in the current page.
5. The method according to claim 4, characterized in that, The step of inputting the feature vector into a lightweight prediction model deployed on the client to obtain the expected interaction intensity of each interactive element on the current page includes: The feature vector is input into the lightweight prediction model to obtain the original output values of each interactive element; The original output value is normalized to obtain the probability value of each interactive element being interacted with, which is used as the expected interaction intensity.
6. The method according to claim 1, characterized in that, When the expected interaction intensity of at least one of the interactive elements meets the preloading condition, the target resource associated with the interactive element that meets the preloading condition is determined according to a predefined resource mapping table, including: Select the top K interactive elements with the highest expected interaction intensity that meet the preloading conditions as high-probability intent elements; From the resource mapping table, the resources associated with each of the high-probability intent elements are queried respectively, and the target resource list is obtained after merging. The resource mapping table is a JSON data structure that records the mapping relationship between the selector of interactive elements and at least one resource to be preloaded.
7. The method according to claim 1, characterized in that, The step of initiating background downloads of each target resource through a preloading scheduler to dynamically preload frontend resources includes: A preloading request is generated for each target resource, and a dynamic priority is assigned to it; wherein the dynamic priority is determined by the expected interaction intensity of the corresponding interactive element and the inherent priority of the target resource marked in the resource mapping table; Preload requests are sent to the browser in descending order of dynamic priority.
8. The method according to claim 7, characterized in that, The method further includes: If the target resource already exists in the browser cache, the creation of a duplicate request will be cancelled before a new preload request is created. Once a new round of predictions is generated, if any interactive element corresponding to a preloading request no longer meets the preloading conditions, the preloading request is immediately terminated.
9. The method according to claim 1, characterized in that, The method further includes: When a user is detected to have a real interaction with any interactive element on the current page, the feature vector generated in the time period before the real interaction and the corresponding real interactive element are used as training samples. The lightweight prediction model is incrementally learned and updated by mixing newly generated training samples with randomly retained historical training samples.
10. A computer program product, characterized in that, The computer program product includes instructions that, when executed on an electronic device, cause the electronic device to perform the method of any one of claims 1 to 9.