First screen acceleration method and device for parallel prefetching and rendering of multiple components of home page and storage medium

Abstract

The invention discloses a home page multi-component parallel prefetching and rendering first screen acceleration method and device and a storage medium, and the method comprises the following steps: constructing a global dependency relationship model based on the metadata and dependency relationship of each component of a home page, and calculating the priority for each component according to a predefined priority evaluation strategy, generating a component scheduling sequence constrained by the priority and the dependency relationship; controlling a concurrency control strategy of the component; preferentially rendering a visual placeholder structure, and smoothly replacing the real content to a user visible area through a progressive rendering replacement strategy; when the variable quantity of the component data exceeds a preset threshold value, triggering an increment updating strategy based on the difference content; generating a cache identifier according to component granularity, reading and writing data in a multi-level cache structure based on the cache identifier, and ensuring data consistency by adopting a background asynchronous verification strategy; and collecting performance indexes in a page rendering process, and adjusting the priority evaluation strategy, the concurrency control strategy and the increment updating strategy according to the performance indexes.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of Web front-end optimization, and in particular to a first page multi-component parallel prefetching and rendering first screen acceleration method. BACKGROUND

[0002] With the increasing richness of Internet application functions, the number and complexity of components carried by the first pages of portal websites, content aggregation platforms and e-commerce platforms have significantly increased. Such first pages usually include top headlines, carousel pictures, matrix grids, information flow lists and various other heterogeneous components, and there are often data or view level dependency relationships between these components. In a weak network and low-end device environment, the traditional first page rendering scheme usually adopts fixed template development or relies on simple lazy loading and general caching strategies, which face many technical bottlenecks when rendering multi-component first pages. On the one hand, there is a lack of global scheduling of the dependencies and priorities between components, which leads to the blocking of key first screen resources by low-priority component requests, prolonging the user interaction time. On the other hand, the coarse-grained refreshing strategy and caching strategy easily cause a large number of invalid network requests and interface backflow redrawing, resulting in layout jitter and traffic waste. SUMMARY

[0003] In order to overcome the above-mentioned shortcomings of the prior art, the purpose of the present application is to provide a first page multi-component parallel prefetching and rendering first screen acceleration method, which can comprehensively schedule, accurately update and perceive experience to realize fast and stable, smooth and efficient first screen rendering experience, so as to solve the problems raised in the background art.

[0004] The technical scheme adopted by the present application to solve its technical problems is: a first page multi-component parallel prefetching and rendering first screen acceleration method, comprising the following steps:

[0005] S1, based on the metadata and dependency relationships of each component of the first page, a global dependency relationship model is constructed, and the priority of each component is calculated according to a pre-defined priority evaluation strategy, and a component scheduling sequence constrained by the priority and the dependency relationship is generated;

[0006] S2, based on the current running environment state, the concurrency control strategy of the components is controlled;

[0007] S3, in the data request process, a visual placeholder structure is preferentially rendered, and after the component data is returned, the real content is smoothly replaced to the user's visual area through a progressive rendering replacement strategy;

[0008] S4, the rendering state changes of each component are continuously monitored, and when the change amount of the component data exceeds a pre-set threshold, an incremental update strategy based on the difference content is triggered;

[0009] S5, generating a cache identifier at an assembly granularity, and reading and writing data in a multi-level cache structure based on the cache identifier, while adopting a background asynchronous verification strategy to guarantee data consistency;

[0010] S6, collecting performance indicators in a page rendering process, and adjusting the priority evaluation strategy, the concurrency control strategy and the incremental update strategy according to the performance indicators.

[0011] As a further improvement of the application, in the step S1, the following steps are included:

[0012] Obtaining a user access request and current network device context information, and obtaining metadata configurations of components of a homepage from a server, the metadata configurations at least including component identification, type, dependency relationship, edition information, default weight and skeleton template identification;

[0013] Taking components as nodes and dependency relationships between the components as directed edges, a priority directed acyclic graph (DAG) is constructed, a comprehensive priority score of each component node is calculated based on a preset priority calculation model, and topological sorting is performed on the DAG to generate a batch execution sequence containing a plurality of components, wherein components in a first-screen visible area are assigned to a high-priority batch.

[0014] As a further improvement of the application, the comprehensive priority score of each component node is calculated based on the preset priority calculation model, and specifically includes the following steps:

[0015] Obtaining five characteristic factors of a component, including business importance B, first-screen visibility A, data freshness F, rendering cost C and historical failure penalty D, and performing normalization processing on each characteristic factor;

[0016] Using configurable weight coefficients wB, wA, wF, wC and wD to perform weighted summation on the normalized characteristic factors to obtain a comprehensive priority score

[0017] P(v) = wB·B + wA·A + wF·F - wC·C - wD·D

[0018] Wherein, v represents a specific component node;

[0019] After calculating the priority score of each node, topological sorting is performed in strict accordance with the dependency relationship constraints between the nodes in the DAG, nodes without dependency conflicts and with similar priority scores are divided into the same batch, and it is ensured that the first-screen key components are concentrated in the earliest executed batch.

[0020] As a further improvement of the application, in the step S2, the following steps are included:

[0021] According to network throughput and round-trip time (RTT) to estimate the current concurrent request upper limit value L, and according to the upper limit value, parallel prefetch requests are initiated for components in the high-priority batch, and delayed loading is performed for components in the low-priority batch during the idle period, and if the request fails, a backoff retry strategy is performed in conjunction with the component priority.

[0022] As a further improvement of the application, in step S3, the following steps are included:

[0023] At the same time of initiating the request, a skeleton screen template is rendered in the corresponding version position of the first screen according to the metadata configuration to perform placeholder, and after the component data is returned, real content rendering is completed in the off-screen buffer, and when the rendering is completed and the animation frame idle condition is met, the off-screen buffer content is replaced to the visible area by a double buffering switching strategy, so as to reduce layout offset and visual jitter.

[0024] As a further improvement of the application, in step S4, the following steps are included:

[0025] A previous rendering digest H_prev and a current rendering digest H_now are maintained for each component, and the difference Δ between the two is calculated regularly or event triggered, and if the difference Δ is greater than the differential threshold δ corresponding to the component or the component cache has reached the time to live (TTL), a minimum incremental update patch is generated and applied to the document object model (DOM) or virtual DOM, otherwise it remains silent.

[0026] As a further improvement of the application, the off-screen buffer content is replaced to the visible area by a double buffering switching strategy, specifically including:

[0027] An off-screen container consistent with the size of the visible area is created in the document object model (DOM), which is in an invisible state and is separated from the regular document flow;

[0028] The obtained component data is combined with the corresponding view template to complete the complete rendering process in the off-screen container, including layout calculation and style application;

[0029] The rendering state of the off-screen container and the load condition of the browser main thread are monitored in real time, and when it is confirmed that the off-screen rendering has been completed, all the data it depends on is ready, and the current browser animation frame is idle, the off-screen container and the current visible container are exchanged and displayed atomically;

[0030] After the exchange is completed, the resources of the original visible container are released and the memory is recycled, and the rendering state digest of the newly replaced and displayed container is recorded as the current rendering digest H_now, and the previous rendering digest H_prev is updated.

[0031] As a further improvement of the present invention: the generation of the minimum incremental update patch and its application to the Document Object Model (DOM) or the Virtual DOM specifically includes:

[0032] The rendering digests H_prev and H_now are structured data that characterize the rendering state of the component, and can be implemented as any one of the following: a field-level hash set, an entry count vector, or a timestamp sequence.

[0033] The function diff(·) for calculating the difference Δ is used to calculate the size of the symmetric difference set between two summaries, the Manhattan L1 distance, or the Euclidean L2 distance.

[0034] The minimum incremental update patch is a set of minimal operation instructions that describe the addition, deletion, attribute modification, or content update of DOM nodes or VDOM nodes.

[0035] When applying a patch, only perform the corresponding DOM operations on the target nodes that have changed.

[0036] In one embodiment of the present invention, step S5 includes:

[0037] Component-level cache keys are generated by combining component type, data version identifier, query parameters, user segmentation and locale information. Component data, rendering summary and timestamp are written in key-value form to at least one layer of cache in memory, indexed database IndexedDB or service worker. A SWR strategy is used to maintain data consistency.

[0038] As a further improvement of the present invention: the method of maintaining data consistency by first deprecating and then correcting the background (SWR) specifically includes:

[0039] Upon receiving a component data request, the system first checks in parallel whether there is valid data in each level of cache that is not marked as expired and matches the component-level cache key.

[0040] If valid cached data exists, it is immediately returned for page rendering, while an asynchronous verification request is sent to the data source to obtain the latest data.

[0041] If the new data obtained from the data source differs from the current cached data, a differential patch is generated and the cache and page DOM are silently updated in the background. This process does not affect the user's current operation.

[0042] If there is no valid data in the cache or the asynchronous verification request fails, the page will be rendered using the most recent stale data or a pre-set fallback template to ensure that the page content is not completely blank.

[0043] As a further improvement of the present invention: step S6 includes:

[0044] Collect core webpage experience metrics, including maximum content rendering (LCP), interactive time (TTI), and cumulative layout offset (CLS), as well as key performance indicators (KPIs). Inject multiple metrics back into the weight factors of the priority calculation model, the upper limit of concurrent requests (L), and the differential threshold (δ) to form an optimization closed loop based on measured experience data.

[0045] As a further improvement of the present invention: the estimation of the current concurrent request limit L based on network throughput and round-trip time (RTT) is specifically achieved through the following formula:

[0046] L = clip( L0 + α·f(downlink throughput) - β·g(RTT) - γ·h(device performance tier) )

[0047] Where L0 is the preset concurrent baseline value, α, β, and γ are the influence coefficients of downlink throughput, RTT, and device performance grading, respectively, and f, g, and h are monotonically increasing functions that map the original parameters to dimensionless scalars;

[0048] The function clip(·) is used to clip the calculation results to a preset safe concurrency range [L_min, L_max] to prevent the estimate from being too high or too low.

[0049] When an increase in network request failure rate or increased response jitter is detected, the concurrent request limit value L is temporarily reduced. After several consecutive successful requests or when network quality recovers, the value of L is gradually increased to restore system throughput.

[0050] As a further improvement of the present invention: step S6 further includes:

[0051] Real-time collection of TTI, LCP, CLS metrics values, as well as counts and durations of business exposure, clicks, and conversion events on the page;

[0052] A metrics aggregation and analysis system that packages and reports metrics values ​​together with session identifiers, timestamps, and network environment information to the server.

[0053] The server periodically aggregates and analyzes massive amounts of indicator data to calculate a set of optimized parameter suggestions for adjusting weight coefficients wB, wA, wF, wC, wD, the upper limit of concurrent requests L, and the differential threshold δ.

[0054] The optimized parameter set is pushed to the page in a grayscale manner by configuring the distribution channel. After the page receives the parameter set, it will take effect immediately in the next DAG construction, concurrency control and differential refresh process.

[0055] Compared with the prior art, the beneficial effects of the present invention are:

[0056] This invention ensures the priority loading and rendering of core components on the first screen through DAG-based global dependency modeling and dynamic priority scheduling, effectively reducing white screen time and interactive time caused by resource contention and improving the first screen loading speed. It adopts a skeleton screen and double-buffered smooth replacement strategy, combined with off-screen rendering and conditional switching, which greatly reduces layout offset and visual jitter during page rendering and enhances visual stability. Through differential water level-triggered minimal incremental update and component-level cache management, precise DOM operations are performed only when data changes effectively, which greatly reduces redundant network requests, computational overhead and main thread blocking, and improves resource utilization efficiency. By injecting performance indicators back to the scheduling strategy parameters in real time, a measurable optimization closed loop is formed. Attached Figure Description

[0057] Figure 1 This is a schematic diagram of the first-screen acceleration method for parallel pre-fetching and rendering of multiple components on the homepage according to the present invention. Detailed Implementation

[0058] In order to clearly and completely understand the technical solution, the present invention will be further described in conjunction with the embodiments and accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0060] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0061] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0062] Embodiments of the present invention provide a method for accelerating the first screen of a homepage by parallel prefetching and rendering of multiple components, comprising the following steps:

[0063] S1. Based on the metadata and dependencies of each component on the homepage, construct a global dependency model, calculate the priority of each component according to the predefined priority evaluation strategy, and generate a component scheduling sequence constrained by priority and dependency.

[0064] S2. Based on the current operating environment state, control the concurrency control strategy of the component;

[0065] S3. During the data request process, the visual placeholder structure is rendered first. After the component data is returned, the real content is smoothly replaced to the user's visible area through a progressive rendering replacement strategy.

[0066] S4. Continuously monitor the rendering status changes of each component. When the change in component data exceeds the preset threshold, trigger an incremental update strategy based on the difference in content.

[0067] S5. Generate cache identifiers at the component level and read and write data in a multi-level cache structure based on the cache identifiers, while using a background asynchronous verification strategy to ensure data consistency.

[0068] S6. Collect performance metrics during the page rendering process, and adjust the priority evaluation strategy, concurrency control strategy, and incremental update strategy based on the performance metrics.

[0069] The first-screen acceleration method for homepage multi-component parallel prefetching and rendering based on priority DAG orchestration and differential water level throttling, according to the present invention, ensures the priority loading of core components by constructing a global dependency model and priority scheduling sequence, effectively reducing resource contention and white screen time. Combined with adaptive concurrency control, the system can dynamically adjust the request strategy according to real-time network conditions, maintaining stable throughput even in weak network environments, greatly shortening interactive time and maximum content rendering time. It adopts a visual placeholder and progressive replacement strategy, first embedding the skeleton structure in the layout, and then rendering the real content through a smooth transition, effectively avoiding sudden shifts and jumps of page elements, reducing the cumulative layout offset index, and improving the user's perceived smoothness. Through differential monitoring and incremental update strategies, DOM updates are triggered only when the actual data changes sufficiently, avoiding unnecessary full rendering and duplicate requests. Combined with component-level caching and consistency management, the cache hit rate is improved, reducing bandwidth consumption and server pressure. By collecting performance indicators in real time and feeding them back to the scheduling and update strategy, a closed-loop control is formed, enabling the system to automatically optimize according to different user devices and network conditions, maintaining high performance in the long term.

[0070] In one embodiment of the present invention, step S1 includes:

[0071] Obtain user access requests and current network device context information, and obtain metadata configurations for each component of the homepage from the server. The metadata configurations include at least component identifiers, types, dependencies, placement information, default weights, and skeleton template identifiers.

[0072] Using components as nodes and dependencies between components as directed edges, a priority directed acyclic graph (DAG) is constructed. A comprehensive priority score is calculated for each component node based on a preset priority calculation model. The DAG is then topologically sorted to generate a batch execution sequence containing several components. Components within the first visible area are assigned to high-priority batches.

[0073] By modeling components as nodes and dependencies as directed edges, it ensures that the loading and rendering of any component strictly follows the components it depends on, avoiding rendering errors, content flickering, or logical anomalies caused by missing dependencies. By constructing a priority-oriented directed acyclic graph (DAG) model, the originally loose multi-component loading process is transformed into a systematic scheduling task with clear dependencies and priority constraints. This overcomes the resource contention problems existing in traditional first-come-first-served or simple parallel strategies, ensuring that key components can obtain network and computing resources first. Batch execution sequences are generated through topology sorting, and components in the first visible area are explicitly assigned to high-priority batches, so that the content that users are most likely to see first is loaded and rendered first. This can directly shorten the first-screen visibility time (LCP) and interactive time of day (TTI), effectively reducing the user's perceived white screen waiting time. Furthermore, priority is calculated based on multiple feature factors and configurable weights, so that the scheduling strategy is no longer static and fixed, but can be flexibly adjusted and optimized according to different business scenarios, user groups, or operational needs.

[0074] In one embodiment of the present invention, the calculation of a comprehensive priority score for each component node based on a preset priority calculation model specifically includes:

[0075] The five feature factors are obtained: business importance of the component (B), first screen visibility (A), data freshness (F), rendering cost (C), and historical failure penalty (D). Each feature factor is normalized to eliminate the influence of units.

[0076] The normalized feature factors are weighted and summed using configurable weight coefficients wB, wA, wF, wC, and wD to obtain the comprehensive priority score.

[0077] P(v) = wB·B + wA·A + wF·F - wC·C - wD·D

[0078] Where v represents a specific component node;

[0079] After calculating the priority score of each node, the topology is sorted strictly according to the dependency constraints between nodes in the DAG. Nodes with no dependency conflicts and similar priority scores are grouped into the same batch to ensure that the key components of the first screen are concentrated in the earliest executed batch.

[0080] By integrating five key characteristic factors—business importance (B), first-screen visibility (A), data freshness (F), acquisition cost (C), and historical failure penalty (D)—this application breaks through the limitations of traditional single-dimensional models. Furthermore, the model transforms priority assessment from subjective experience-based judgment to objective data, ensuring that high-value, high-visibility, and frequently updated components receive priority access to resources. Simultaneously, it prevents high-cost or high-failure-risk components from blocking critical paths, thereby achieving optimal allocation of system resources. Through a combination of weighted summation and penalty terms, the urgency and importance of each component are calculated. This ensures that in the batch execution sequence generated after topological sorting, key components for the first screen are concentrated in high-priority batches, shortening the maximum content rendering time and interactive time, reducing perceived white-screen waiting time, and improving user experience. For components or interfaces with historically high failure rates, their priority is automatically lowered to avoid slowing down the overall progress due to repeated failures and retries, instead freeing up resource channels for more stable components, increasing the success rate of single loads, and enhancing the overall robustness of the system in weak network or unstable environments. After calculating the numerical priority, the algorithm does not simply sort by score, but strictly follows the dependency constraints of DAG for topological sorting. No component will be executed before the components it depends on. Nodes with similar priority scores and no dependency conflicts are grouped into the same batch to achieve a balance between dependency and parallel efficiency, ensuring that resources are fully utilized without logical errors.

[0081] In one embodiment of the present invention, step S2 includes:

[0082] The current concurrent request limit L is estimated based on network throughput and round-trip time (RTT). Parallel prefetch requests are initiated for components in high-priority batches based on this limit, while components in low-priority batches are loaded late during idle periods. If a request fails, a backoff and retry strategy linked to component priority is executed.

[0083] By estimating the upper limit of concurrent requests (L) based on real-time network throughput and round-trip time (RTT), the system automatically increases the number of concurrent requests in high-speed, low-latency networks to fully utilize bandwidth and accelerate overall loading speed. In congested or weak network conditions, it proactively reduces the number of concurrent requests to prevent excessive parallel requests from causing network queue congestion, frequent timeouts, or even connection crashes. Based on this upper limit, the system initiates parallel prefetch requests for components in high-priority batches. The system consistently prioritizes valuable concurrent request slots for critical content on the first screen—content that users most urgently want to see—ensuring that the loading of core content is never crowded out by a large number of low-priority requests. This directly and effectively shortens the first-screen visibility time (LCP) and interactive time time (TTI). When a request fails, for high-priority components, the system may employ more frequent and shorter intervals of aggressive retries to quickly restore the display of critical content. For low-priority components, a longer backoff period or even temporary abandonment strategy is adopted to avoid exacerbating network anomalies and causing more failures and resource consumption.

[0084] Furthermore, the estimation of the current concurrent request limit L based on network throughput and round-trip time (RTT) is specifically achieved through the following formula:

[0085] L = clip( L0 + α·f(downlink throughput) - β·g(RTT) - γ·h(device performance tier) )

[0086] Where L0 is the preset concurrent baseline value, α, β, and γ are the influence coefficients of downlink throughput, RTT, and device performance grading, respectively, and f, g, and h are monotonically increasing functions that map the original parameters to dimensionless scalars;

[0087] The function clip(·) is used to clip the calculation results to a preset safe concurrency range [L_min, L_max] to prevent the estimate from being too high or too low.

[0088] When an increase in network request failure rate or increased response jitter is detected, the concurrent request limit value L is temporarily reduced. After several consecutive successful requests or when network quality recovers, the value of L is gradually increased to restore system throughput.

[0089] The concurrency decision-making system incorporates three key dimensions: network transmission capacity, network transmission quality, and terminal device computing power. Monotonically increasing functions f, g, and h map the original parameters of different dimensions to comparable dimensionless scalars. Configurable influence coefficients α, β, and γ calculate the actual weight of each dimension's impact on concurrency capacity, avoiding the blindness of traditional empirical values. The function clip(·) strictly limits the concurrency limit L within a preset safe range [L_min, L_max]. This prevents excessively high concurrency in excellent network conditions, which could lead to massive requests to the server, potentially overwhelming it or triggering its rate-limiting policy. It also prevents concurrency from dropping to zero in extremely poor network conditions, ensuring at least a minimum request capacity is maintained. This avoids systemic risks such as connection pool exhaustion, widespread request timeouts or failures due to uncontrolled concurrency, thus enhancing system stability. When the system detects an increase in network request failure rate or increased response jitter, it interprets this as a signal of network congestion and temporarily and proactively lowers the L value. This effectively alleviates network pressure and prevents congestion from worsening. Conversely, after several consecutive successful requests, the system interprets this as a signal of network quality recovery and adopts a strategy of gradually increasing the L value. It carefully explores the concurrency limits that the current network environment can handle and ultimately restores the system's throughput capacity.

[0090] In one embodiment of the present invention, step S3 includes:

[0091] While making the request, the skeleton screen template is rendered in the corresponding position of the first screen according to the metadata configuration to place the position. After the component data is returned, the real content is rendered in the off-screen buffer. When the rendering is completed and the animation frame is idle, the content in the off-screen buffer is replaced to the visible area at once through a double buffer switching strategy to reduce layout offset and visual jitter.

[0092] By rendering a skeleton screen template based on metadata configuration and placing it in place simultaneously with the data request, the final content size and layout position are visually locked. This avoids the drastic page element jumps and shifts caused by sudden content insertion in traditional loading modes. A dual-buffering switching strategy enables an atomic, one-time replacement, ensuring a smooth transition from a stable skeleton layout to the final real content. This reduces the cumulative layout offset (CLS) index, providing an extremely stable and smooth loading experience. Performing the complete rendering process of the real content in an off-screen buffer is a key performance optimization. Separating the most performance-intensive rendering calculations from the user's currently visible screen ensures that heavy computational tasks do not block the main thread or affect the current page's interactive responsiveness. Off-screen rendering fully utilizes the browser's compositing thread and GPU acceleration. Once fully ready, switching occurs during the browser's animation frame idle period, eliminating frame rate drops and visual stuttering during rendering. Furthermore, the instant display of the skeleton screen provides immediate feedback to the user, effectively shortening the perceived waiting time and masking the actual latency of background data requests and rendering.

[0093] In one embodiment of the present invention, step S4 includes:

[0094] For each component, maintain the previous rendering summary H_prev and the current rendering summary H_now, and calculate the difference Δ between the two periodically or triggered by an event. If the difference Δ is greater than the difference threshold δ corresponding to the component or the component cache has reached its time-to-live (TTL), generate a minimum incremental update patch and apply it to the Document Object Model (DOM) or the Virtual DOM; otherwise, remain silent.

[0095] By maintaining the previous rendering summary H_prev and the current rendering summary H_now for each component and calculating the difference Δ, the subsequent update process will only be triggered when the amount of data change exceeds the preset threshold δ or the TTL expires. This effectively filters out a large number of update requests with no substantial changes or minor changes, avoiding unnecessary DOM operations, layout reflows and style repaints, thereby saving CPU computing resources and battery consumption, and reducing network bandwidth consumption and server load.

[0096] Furthermore, the method of replacing the off-screen buffer content to the visible area in one go using a double-buffering switching strategy specifically includes:

[0097] Create an off-screen container in the Document Object Model (DOM) with the same size as the visible area. This container is invisible and removed from the normal document flow.

[0098] The acquired component data is combined with the corresponding view template to complete the entire rendering process in the off-screen container, including layout calculation and style application.

[0099] Real-time monitoring of the rendering status of the off-screen container and the load of the browser's main thread; when it is confirmed that the off-screen rendering is complete, all the data it depends on is ready, and the browser is currently in an idle period of animation frames, the off-screen container is atomically swapped with the currently visible container.

[0100] After the swap is completed, immediately release the resources of the original visible container and reclaim the memory. At the same time, record the rendering state summary of the newly replaced display container as the current rendering summary H_now, and update the previous rendering summary H_prev.

[0101] By creating an off-screen container in the DOM that is exactly the same size as the visible area and removing it from the regular document flow, it ensures that any complex rendering calculations performed within this container will not affect the geometry of the currently visible page. This makes the changes perceived by the user instantaneous and holistic switch, rather than the piecemeal pop-ups, page height jitter, or frequent layout reflows caused by gradual rendering. Browser rendering is done in frames, and there are idle windows at specific points in each frame. By monitoring the main thread load in real time and waiting for this opportunity, it ensures that heavy container swapping, style application, and other operations will not compete for resources with ongoing user interactions or other rendering tasks. This completely avoids frame rate drops, page stuttering, or interactive response delays caused by improper rendering timing, ensuring page smoothness. After the swap is completed, the resources of the original visible container are immediately released and memory is reclaimed. This prevents the unlimited growth of memory usage caused by continuously creating off-screen containers and not cleaning them up in a timely manner during the long-term operation of a single-page application, and avoids gradual stuttering or even crashes due to insufficient memory.

[0102] Furthermore, the generation of minimum incremental update patches and their application to the Document Object Model (DOM) or Virtual DOM specifically includes:

[0103] The rendering digests H_prev and H_now are structured data that characterize the rendering state of the component, and can be implemented as any one of the following: a field-level hash set, an entry count vector, or a timestamp sequence.

[0104] The function diff(·) for calculating the difference Δ is used to calculate the size of the symmetric difference set between two summaries, the Manhattan L1 distance, or the Euclidean L2 distance.

[0105] The minimum incremental update patch is a set of minimal operation instructions that describe the addition, deletion, attribute modification, or content update of DOM nodes or VDOM nodes.

[0106] When applying a patch, only perform the corresponding DOM operations on the target nodes that have changed.

[0107] By adjusting the component rendering summary to structured data formats such as field-level hash sets, entry count vectors, or timestamp sequences, and choosing symmetric difference scale, Manhattan distance L1, or Euclidean distance L2 as the calculation method for the difference Δ, the change in rendering states between two rendering states can be calculated with extremely low computational overhead from the perspective of set theory or vector space. This avoids the performance bottlenecks caused by direct deep object comparisons or complex tree difference calculations, achieving extremely high computational efficiency while ensuring the accuracy of difference identification. Furthermore, a minimal set of operation instructions is generated, where each instruction in the patch directly corresponds to an atomic change that must be performed on the DOM tree, without any redundancy. When applying the patch, the browser does not need to process the entire component subtree, nor does it need to re-parse HTML or process unchanged CSS styles. It only needs to perform extremely local operations on the target nodes explicitly specified in the instruction set, reducing the main thread's blocking time and improving the application's interactive response speed.

[0108] In one embodiment of the present invention, step S5 includes:

[0109] A component-level cache key is generated by combining component type, data version identifier, query parameters, user segmentation, and locale information. Component data, rendering summaries, and timestamps are written as key-value pairs to at least one layer of cache in memory, an indexed database (IndexedDB), or a Service Worker. A background correction (SWR) strategy is used to maintain data consistency. SWR is a React Hooks library used to simplify data request logic. It automatically handles caching, duplicate requests, and real-time data updates using unique identifiers (such as API URLs) and asynchronous request functions (such as fetch or Axios). It supports SSR / ISR, TypeScript, and React Native, and is suitable for improving page responsiveness and data consistency.

[0110] By combining multi-dimensional information such as component type, data version identifier, query parameters, user segmentation, and locale to generate cache keys, false hits and cache pollution are avoided. This ensures that the cached data read is completely matched with the context of the current request, improving cache effectiveness and hit rate, and reducing redundant network requests at the source. The system constructs an intelligent layered caching architecture by writing data to at least one layer: memory, indexed database, or service worker. Memory caching provides nanosecond-level read speeds for instantaneous hot data; IndexedDB provides massive persistent storage for large amounts of structured data; and Service Worker caching intercepts network requests, providing powerful offline access capabilities. This allows the system to select the caching layer based on data access frequency and importance, providing users with a fast-response experience. A strategy of prioritizing older, usable data and background correction improves consistency and user experience. When a request is initiated, the system immediately returns potentially outdated cached data for instant rendering, eliminating user wait time. Simultaneously, a verification request is asynchronously initiated in the background to obtain the latest data and update the cache and UI, ensuring users receive a fast response first, while the system guarantees eventual data consistency in the background.

[0111] In one embodiment of the present invention, the method of maintaining data consistency by employing a first-out, available-back-end correction (SWR) strategy specifically includes:

[0112] Upon receiving a component data request, the system first checks in parallel whether there is valid data in each level of cache that is not marked as expired and matches the component-level cache key.

[0113] If valid cached data exists, it is immediately returned for page rendering, while an asynchronous verification request is sent to the data source to obtain the latest data.

[0114] If the new data obtained from the data source differs from the current cached data, a differential patch is generated and the cache and page DOM are silently updated in the background. This process does not affect the user's current operation.

[0115] If there is no valid data in the cache or the asynchronous verification request fails, the page will be rendered using the most recent stale data or a pre-set fallback template to ensure that the page content is not completely blank.

[0116] Upon receiving a request, the system prioritizes returning data from the cache for immediate rendering, ensuring zero-latency response to user actions and completely eliminating the lag caused by waiting for network round trips. Simultaneously, verification requests initiated in the background quietly guarantee the final freshness of the data. Furthermore, when the background verification discovers new data, the system does not abruptly re-render the entire component but generates differential patches and silently updates, applying only the minimum changed dataset to the DOM and cache. The update process is completed in the background without the user's awareness, without causing loss of focus, input interruption, scroll position jumps, or page layout reconstruction, maintaining the continuity of user operations and visual stability. When there is no data in the cache or asynchronous verification fails, the system does not directly throw an error causing a blank screen but instead uses the most recent stale data or a pre-set fallback template, ensuring that the page always has content to view under any extreme circumstances such as network fluctuations, server anomalies, or cache invalidation, thus improving the user experience.

[0117] In one embodiment of the present invention, step S6 includes:

[0118] Collect core webpage experience metrics, including maximum content rendering (LCP), interactive time (TTI), and cumulative layout offset (CLS), as well as key performance indicators (KPIs). Inject multiple metrics back into the weight factors of the priority calculation model, the upper limit of concurrent requests (L), and the differential threshold (δ) to form an optimization closed loop based on measured experience data.

[0119] Traditional optimization strategies rely on pre-configured static settings by developers, making it difficult to adapt to diverse user devices, network environments, and real-time changes in business content. This solution continuously collects real-world metrics such as LCP, TTI, CLS, and business KPIs, and injects these metrics back into core scheduling parameters, including weighting factors w, concurrency limits L, and differential thresholds δ. The injection mechanism doesn't simply boost a single metric; instead, it performs multi-objective collaborative optimization, building a closed-loop control system based on empirical data. For example, if the system detects a deterioration in the CLS metric during a certain period, it can automatically increase the weighting factor wA of the first-screen visibility A, prioritizing visual stability for the rendering engine. If a business KPI shows a high conversion rate for a certain component, its business importance B weight wB can be increased accordingly, receiving more resource allocation. Similarly, the concurrency limit L can dynamically scale based on TTI and network conditions, and the differential threshold δ can be dynamically adjusted based on update frequency and user perception.

[0120] Furthermore, step S6 also includes:

[0121] Real-time collection of TTI, LCP, CLS metrics values, as well as counts and durations of business exposure, clicks, and conversion events on the page;

[0122] A metrics aggregation and analysis system that packages and reports metrics values ​​together with session identifiers, timestamps, and network environment information to the server.

[0123] The server periodically aggregates and analyzes massive amounts of indicator data to calculate a set of optimized parameter suggestions for adjusting weight coefficients wB, wA, wF, wC, wD, the upper limit of concurrent requests L, and the differential threshold δ.

[0124] The optimized parameter set is pushed to the page in a grayscale manner by configuring the distribution channel. After the page receives the parameter set, it will take effect immediately in the next DAG construction, concurrency control and differential refresh process.

[0125] By collecting core experience metrics such as TTI, LCP, and CLS in real time on the client side, and combining them with key event data such as business exposure, clicks, and conversions, all data is packaged and reported along with metadata such as session identifiers, timestamps, and network environment information, ensuring that each piece of data has a complete context. This allows subsequent analysis to accurately pinpoint problems and identify how the loading delay of a certain type of component affects the final conversion rate under specific network types, thus providing extremely precise input for optimization. The server periodically aggregates and analyzes massive amounts of metric data, using statistical analysis (such as calculating quantiles, trend correlation, and regression analysis) to discover the optimal configuration. For example, analysis reveals that when the weight coefficient wA of the first-screen visibility A is increased by 0.1, the median of the overall CLS metric can be improved by 15%, without negatively impacting TTI. Based on this, the system will generate a set of optimization suggestion parameters. A configuration distribution channel is used for canary rollout. After the page receives new parameters, they take effect immediately in the next round of DAG construction and concurrency control processes without needing to refresh. Combined with the canary rollout strategy, the effect of new parameters can be tested on a small scale, and a full release can be made only after verification, greatly reducing the risk of optimization iteration.

[0126] An electronic device is characterized by comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method described in any embodiment.

[0127] For example, in this embodiment, the computer program can be divided into one or more modules, which are stored in the memory and executed by the processor to complete this application. The one or more modules can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the electronic device of the homepage multi-component parallel prefetching and rendering first-screen acceleration method.

[0128] The electronic device used in the first-screen acceleration method for parallel prefetching and rendering of multiple homepage components can be a computing device such as a desktop computer, laptop, PDA, or cloud server. The electronic device used in the first-screen acceleration method for parallel prefetching and rendering of multiple homepage components may include, but is not limited to, processors and memory.

[0129] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the electronic device for the homepage multi-component parallel prefetching and rendering first-screen acceleration method, connecting various parts of the electronic device through various interfaces and lines. The memory can be used to store the computer program and / or modules. The processor implements various functions of the electronic device for the homepage multi-component parallel prefetching and rendering first-screen acceleration method by running or executing the computer program and / or modules stored in the memory, and by calling data stored in the memory. The memory may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, etc.; the data storage area may store data created based on the use of the mobile phone, etc. Furthermore, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital cards (SD cards), flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0130] A computer-readable storage medium, characterized in that the storage medium stores a computer program, which, when executed by a processor, implements the method described in any embodiment.

[0131] In this embodiment, the storage medium is a computer-readable storage medium, and the computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium can include any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0132] In summary, after reading this invention document, those skilled in the art can make various other corresponding modifications to the technical solutions and concepts based on this invention without creative mental effort, and all of these modifications fall within the scope of protection of this invention.

Claims

1. A method for accelerating the first screen of a homepage by parallel prefetching and rendering of multiple components, characterized in that, Includes the following steps: S1. Based on the metadata and dependencies of each component on the homepage, construct a global dependency model, calculate the priority of each component according to the predefined priority evaluation strategy, and generate a component scheduling sequence constrained by priority and dependency. S2. Based on the current operating environment state, control the concurrency control strategy of the component; S3. During the data request process, the visual placeholder structure is rendered first. After the component data is returned, the real content is smoothly replaced to the user's visible area through a progressive rendering replacement strategy. S4. Continuously monitor the rendering status changes of each component. When the change in component data exceeds the preset threshold, trigger an incremental update strategy based on the difference in content. S5. Generate cache identifiers at the component level and read and write data in a multi-level cache structure based on the cache identifiers, while using a background asynchronous verification strategy to ensure data consistency. S6. Collect performance metrics during the page rendering process, and adjust the priority evaluation strategy, concurrency control strategy, and incremental update strategy based on the performance metrics.

2. The method for accelerating the first screen of a homepage with parallel pre-fetching and rendering of multiple components as described in claim 1, characterized in that, Step S1 includes: Obtain user access requests and current network device context information, and obtain metadata configurations for each component of the homepage from the server. The metadata configurations include at least component identifiers, types, dependencies, placement information, default weights, and skeleton template identifiers. Using components as nodes and dependencies between components as directed edges, a priority directed acyclic graph (DAG) is constructed. A comprehensive priority score is calculated for each component node based on a preset priority calculation model. The DAG is then topologically sorted to generate a batch execution sequence containing several components. Components within the first visible area are assigned to high-priority batches.

3. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components as described in claim 2, characterized in that, The preset priority calculation model calculates a comprehensive priority score for each component node, specifically including: The five feature factors are obtained: business importance of the component (B), first screen visibility (A), data freshness (F), rendering cost (C), and historical failure penalty (D), and each feature factor is normalized. The normalized feature factors are weighted and summed using configurable weight coefficients wB, wA, wF, wC, and wD to obtain the comprehensive priority score. P(v) = wB·B + wA·A + wF·F - wC·C - wD·D Where v represents a specific component node; After calculating the priority score of each node, the topology is sorted strictly according to the dependency constraints between nodes in the DAG. Nodes with no dependency conflicts and similar priority scores are grouped into the same batch to ensure that the key components of the first screen are concentrated in the earliest executed batch.

4. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components according to claim 3, characterized in that, Step S2 includes: The current concurrent request limit L is estimated based on network throughput and round-trip time (RTT). Parallel prefetch requests are initiated for components in high-priority batches based on this limit, while components in low-priority batches are loaded late during idle periods. If a request fails, a backoff and retry strategy linked to component priority is executed.

5. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components according to claim 4, characterized in that, Step S3 includes: While making the request, the skeleton screen template is rendered in the corresponding position of the first screen according to the metadata configuration to place the position. After the component data is returned, the real content is rendered in the off-screen buffer. When the rendering is completed and the animation frame is idle, the content in the off-screen buffer is replaced to the visible area at once through a double buffer switching strategy to reduce layout offset and visual jitter.

6. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components according to claim 5, characterized in that, Step S4 includes: For each component, maintain the previous rendering summary H_prev and the current rendering summary H_now, and calculate the difference Δ between the two periodically or triggered by an event. If the difference Δ is greater than the difference threshold δ corresponding to the component or the component cache has reached its time-to-live (TTL), generate a minimum incremental update patch and apply it to the Document Object Model (DOM) or the Virtual DOM; otherwise, remain silent.

7. The first-screen acceleration method for parallel prefetching and rendering of multiple homepage components according to claim 6, characterized in that, The method of replacing the off-screen buffer content to the visible area in one go using a dual-buffering switching strategy specifically includes: Create an off-screen container in the Document Object Model (DOM) with the same size as the visible area. This container is invisible and removed from the normal document flow. The acquired component data is combined with the corresponding view template to complete the entire rendering process in the off-screen container, including layout calculation and style application. Real-time monitoring of the rendering status of the off-screen container and the load of the browser's main thread; when it is confirmed that the off-screen rendering is complete, all the data it depends on is ready, and the browser is currently in an idle period of animation frames, the off-screen container is atomically swapped with the currently visible container. After the swap is completed, immediately release the resources of the original visible container and reclaim the memory. At the same time, record the rendering state summary of the newly replaced display container as the current rendering summary H_now, and update the previous rendering summary H_prev.

8. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components according to claim 7, characterized in that, The process of generating a minimum incremental update patch and applying it to the Document Object Model (DOM) or Virtual DOM specifically includes: The rendering digests H_prev and H_now are structured data that characterize the rendering state of the component, and can be implemented as any one of the following: a field-level hash set, an entry count vector, or a timestamp sequence. The function diff(·) for calculating the difference Δ is used to calculate the size of the symmetric difference set between two summaries, the Manhattan L1 distance, or the Euclidean L2 distance. The minimum incremental update patch is a set of minimal operation instructions that describe the addition, deletion, attribute modification, or content update of DOM nodes or VDOM nodes. When applying a patch, only perform the corresponding DOM operations on the target nodes that have changed.

9. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components as described in claim 8, characterized in that, Step S5 includes: Component-level cache keys are generated by combining component type, data version identifier, query parameters, user segmentation and locale information. Component data, rendering summary and timestamp are written in key-value form to at least one layer of cache in memory, indexed database IndexedDB or service worker. A SWR strategy is used to maintain data consistency.

10. The first-screen acceleration method for parallel prefetching and rendering of multiple homepage components according to claim 9, characterized in that, The strategy of using SWR (Self-Recovery and Back-End Correction) to maintain data consistency specifically includes: Upon receiving a component data request, the system first checks in parallel whether there is valid data in each level of cache that is not marked as expired and matches the component-level cache key. If valid cached data exists, it is immediately returned for page rendering, while an asynchronous verification request is sent to the data source to obtain the latest data. If the new data obtained from the data source differs from the current cached data, a differential patch is generated and the cache and page DOM are silently updated in the background. This process does not affect the user's current operation. If there is no valid data in the cache or the asynchronous verification request fails, the page will be rendered using the most recent stale data or a pre-set fallback template to ensure that the page content is not completely blank.

11. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components according to claim 10, characterized in that, Step S6 includes: Collect core webpage experience metrics, including maximum content rendering (LCP), interactive time (TTI), and cumulative layout offset (CLS), as well as key performance indicators (KPIs). Inject multiple metrics back into the weight factors, concurrent request limit (L), and differential threshold (δ) of the priority calculation model to form an optimization closed loop based on measured experience data.

12. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components according to claim 11, characterized in that, The estimation of the current concurrent request limit L based on network throughput and round-trip time (RTT) is specifically achieved through the following formula: L = clip( L0 + α·f(downlink throughput) - β·g(RTT) - γ·h(device performance tier) ) Where L0 is the preset concurrent baseline value, α, β, and γ are the influence coefficients of downlink throughput, RTT, and device performance grading, respectively, and f, g, and h are monotonically increasing functions that map the original parameters to dimensionless scalars; The function clip(·) is used to clip the calculation results to a preset safe concurrency range [L_min, L_max] to prevent the estimate from being too high or too low. When an increase in network request failure rate or increased response jitter is detected, the concurrent request limit value L is temporarily reduced. After several consecutive successful requests or when network quality recovers, the concurrent request limit value L is gradually increased to restore system throughput.

13. The method for accelerating the first screen of a homepage with parallel prefetching and rendering of multiple components according to claim 12, characterized in that, Step S6 further includes: Real-time collection of TTI, LCP, CLS metrics values, as well as counts and durations of business exposure, clicks, and conversion events on the page; A metrics aggregation and analysis system that packages and reports metrics values ​​together with session identifiers, timestamps, and network environment information to the server. The server periodically aggregates and analyzes massive amounts of indicator data to calculate a set of optimized parameter suggestions for adjusting weight coefficients wB, wA, wF, wC, wD, the upper limit of concurrent requests L, and the differential threshold δ. The optimized parameter set is pushed to the page in a grayscale manner by configuring the distribution channel. After the page receives the parameter set, it will take effect immediately in the next DAG construction, concurrency control and differential refresh process.

14. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1-13.

15. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method as described in any one of claims 1-13.

Images