Applet page rendering acceleration and resource intelligent caching method and system

Abstract

The application discloses a kind of applet page rendering acceleration and resource intelligent caching method and system, to solve applet synchronous rendering block, cache control rigidification, weak network lag, resource duplication request and so on.Proceeding of rendering is split into skeleton screen, core area, non-core lazy rendering three-layer asynchronous procedure and reuse rendering node;Establish three-level resource grading and pre-cache system, supporting unified cache engine with TTL expiration cleaning, multidimensional LRU elimination, MD5 / URL deduplication, version isolation capability;Real-time monitoring network state and hierarchical adaptation rendering loading strategy, while interface, resource request is merged and anti-shake and incremental transmission processing are handled.The application can shorten the page white screen duration, improve cache space utilization, adapt to all network environment, reduce bandwidth and server load, and is suitable for e-commerce, finance, information, social interaction and other multi-resource high-frequency applet.

Description

Technical Field

[0001] This invention relates to the field of mini-program development technology, specifically to a method and system for accelerating page rendering and intelligent resource caching in mini-programs. Background Technology

[0002] Mini-programs have rapidly gained popularity due to their features of being installation-free, ready to use, and cross-platform compatible, and are widely used in e-commerce, social media, news, finance, and other scenarios. The page rendering and resource loading effects directly determine the user experience. Currently, most mainstream mini-programs rely on the framework's built-in rendering engine, combined with a basic local caching mechanism to load page styles, scripts, components, images, and business interface data. However, existing technical solutions have many inherent flaws.

[0003] Current mini-programs use a full synchronous rendering mode, where styles, core scripts, and business components are processed sequentially. This results in a long initial rendering cycle and makes the app prone to white screens and page lag in weak network environments. The caching strategy is rigid, providing only unified local storage capabilities without differentiated management based on resource type, access frequency, or business importance. This often leads to the contradiction of frequently used, critical resources being cleared while infrequent, idle resources occupy cache space for extended periods. Furthermore, the existing solution lacks resource pre-caching and deduplication logic. The same static resources and API data are repeatedly requested every time the page is opened, consuming additional bandwidth and increasing loading latency.

[0004] The cache management lacks a complete intelligent scheduling system, and there are no resource TTL expiration rules, cache space thresholds, or tiered eviction policies. This makes it prone to cache overflows and residual old version resources, leading to page rendering errors. Furthermore, existing technologies have insufficient weak network adaptability, lacking tiered degradation rendering and incremental data return mechanisms. Even with poor network quality, all resources are still forcibly loaded, significantly reducing page availability. In addition, existing mini-programs lack interface merging and request debouncing mechanisms; batch requests in a short period can exacerbate server load. Moreover, the lack of end-to-end operational monitoring and visual custom configuration capabilities prevents dynamic adjustment of cache and rendering parameters based on business scenarios.

[0005] In summary, existing mini-program rendering and caching solutions suffer from pain points such as rendering blockage, inefficient cache management, waste of network resources, and poor adaptability to weak network conditions, and cannot meet the high-performance operation requirements of multi-page, high-frequency interactive mini-programs. Summary of the Invention

[0006] To address these issues, this invention provides a method and system for accelerating page rendering and intelligent resource caching in mini-programs, solving problems such as rendering blockage, caching rigidity, repeated resource requests, and poor experience in weak network conditions in existing technologies.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a method for accelerating page rendering and intelligent resource caching in mini-programs, comprising:

[0008] S1. The page rendering process is divided into layers and asynchronously, and the skeleton screen rendering, core area parallel rendering, and non-core area lazy rendering are executed in sequence, and the repeated rendering nodes are reused.

[0009] S2. Classify resources in multiple dimensions according to resource type, access frequency, and business weight, and perform tiered pre-caching operations in combination with user page dwell behavior;

[0010] S3. Build a unified cache management engine to perform operations such as expiration cleanup, space eviction, deduplication verification, and version isolation on cache resources;

[0011] S4. Monitor the terminal network status in real time and dynamically adjust the page rendering range and resource loading strategy according to the network quality level;

[0012] S5. Merge and debouncing page interface requests and resource requests, and use an incremental mechanism to transmit interface data.

[0013] As a preferred solution for accelerating page rendering and intelligent resource caching in mini-programs, the layered asynchronous splitting in S1 specifically includes:

[0014] When page initialization is triggered, the page structure skeleton is rendered first to generate the skeleton screen;

[0015] The style files, core scripts, and key components are loaded and parsed in parallel to complete the first-screen rendering of the core area of ​​the page, and the loading and parsing process does not block the main rendering thread.

[0016] Real-time monitoring of page scrolling and element visibility, based on a formula for determining visible area:

[0017]

[0018] In the formula, For visibility assessment results, To render the vertical coordinate of the element, , These are the coordinates of the upper and lower boundaries of the viewport, respectively; when the determination result... When non-core areas, secondary business components, and non-first-screen images enter the visible area, lazy rendering loading is triggered.

[0019] Rendering nodes with the same structure can be reused. The node similarity matching formula is as follows:

[0020]

[0021] when When nodes are identified as having the same structure, they are reused; where, For node similarity, , These are the two rendering nodes to be compared. For the number of identical child nodes, This represents the total number of child nodes. This is the similarity threshold.

[0022] As a preferred solution for accelerating page rendering and intelligent resource caching in mini-programs, S2 divides resources into a three-level resource grading system:

[0023] Level 1 resources are resident cache resources, including core interface data, basic style files, common components, and frequently used images;

[0024] Secondary resources are cached resources based on access frequency, including business page resources and regular interface data;

[0025] Level 3 resources are cached on demand, including low-frequency images and non-critical scripts;

[0026] The formula for calculating resource access frequency is:

[0027]

[0028] In the formula, For resource access frequency, To accumulate the number of visits, For statistical periods; combined with access frequency With business weight Delineate resource boundaries at three levels;

[0029] The tiered pre-caching specifically includes: pre-caching first-level resources when a user enters the mini-program; monitoring the user's page dwell time and triggering pre-caching based on the formula:

[0030]

[0031] In the formula, Pre-caching trigger results The duration of time spent on the page. This is the threshold for dwell time; when the judgment result... At that time, pre-cache the next-level related resources corresponding to the current page.

[0032] As a preferred solution for accelerating page rendering and intelligent resource caching in mini-programs, the unified cache management engine construction process in S3 includes:

[0033] Set the TTL expiration time according to the resource type, and the expiration determination formula is as follows:

[0034]

[0035] In the formula, The result of the resource expiration determination. For the current time, For resource storage time, This corresponds to the expiration time of the resource; when Clean up cached resources after they expire;

[0036] The formula for cache space utilization is:

[0037]

[0038] when The elimination mechanism is activated at the appropriate time; where, For cache space usage, Used space Maximum cache space, Spatial threshold;

[0039] When cache space usage reaches a preset threshold, an LRU eviction policy is adopted, prioritizing the cleanup of cache resources with the highest priority value, lowest access frequency, lowest cache level, and expired status. The eviction priority formula is:

[0040]

[0041] In the formula, For resources Elimination priority The start time of access. Last access time For resource level, Mark resources as expired. These are weighting coefficients;

[0042] Deduplication is performed using MD5 / URL signature for cache deduplication. The formula for determining duplicates is:

[0043]

[0044] In the formula, For the result of duplicate resource determination, URL hash signature algorithm, This refers to the MD5 hash algorithm for resource files. , These are the access addresses of the two resources to be compared. , For two resource files to be compared; when If a resource is identified as a duplicate, a single copy of the same resource will be stored.

[0045] After updating the mini-program version, clear all cached resources corresponding to the old version.

[0046] As a preferred solution for accelerating page rendering and intelligent resource caching in mini-programs, the dynamic adjustment in S4 specifically includes:

[0047] Network levels are determined based on a network rate classification formula, which is as follows:

[0048]

[0049] In the formula, For network level, For real-time downlink speed, , For rate grading thresholds;

[0050] When the network is in WiFi / 5G mode, perform full page rendering and full resource pre-caching;

[0051] When the network is in 4G mode, perform parallel rendering of the core area and pre-caching of key resources, and disable the loading of unnecessary resources;

[0052] When the network is weak / 2G, render the skeleton screen and core text content, and downgrade the images to thumbnails according to the compression formula. The interface returns incremental data.

[0053] The compression formula is:

[0054]

[0055] In the formula, For thumbnail size, Original image size The compression factor is 1.

[0056] When the terminal is offline, load the locally available cached resources.

[0057] As a preferred solution for accelerating page rendering and intelligent resource caching in mini-programs, S5 specifically includes merging and debouncing optimizations for the resource requests and interface requests on the page, including:

[0058] Short-interval requests are determined based on a time window formula, which is:

[0059]

[0060] In the formula, The result is determined by the time window. For the current request time, The time of the last request. This is the threshold for the time window;

[0061] Multiple API requests triggered at short intervals within the same page are merged into a single batch request;

[0062] Debouncing is implemented for repeated requests for the same resource within a short period of time, merging them into a single request for execution;

[0063] When the interface data is updated, it returns the fields that have changed, but not the full data.

[0064] When an interface / resource fails to load, a fast retry operation is performed on the core interface, and a delayed retry operation is performed on the non-core interface.

[0065] The formula for fast retry of the core interface is as follows:

[0066]

[0067] The formula for delaying and retrying non-core interfaces is as follows:

[0068]

[0069] In the formula, , This is the interval between retry attempts. ; , This represents the maximum number of retries. These are preset configuration constants.

[0070] As a preferred solution for accelerating page rendering and intelligent resource caching in mini-programs, before initiating a resource loading request, the local cache is queried first according to the cache hit formula; if the cache is hit, the local cached resource is called; if the cache is not hit, a network request is sent to the server and the requested resource is written to the local cache.

[0071] The cache hit formula is:

[0072]

[0073] In the formula, To cache the hit results, To request a resource identifier, This is a collection of cached resource IDs.

[0074] As a preferred solution for accelerating page rendering and intelligent resource caching in mini-programs, it also includes marking the page level, the resource type, and the business priority during the mini-program packaging stage, and generating a resource list in resource.json format;

[0075] Integrate the SDK and configure the maximum cache size, expiration time of resources at all levels, rendering thresholds, and weak network judgment criteria;

[0076] When a mini-program starts, it initializes the rendering engine, cache manager, and network listener.

[0077] As a preferred solution for accelerating page rendering and intelligent resource caching in mini-programs, it also includes real-time collection of page rendering time, cache hit rate, interface request time, and page white screen duration, and reports the collected data to the outside world.

[0078] The cache hit rate formula is:

[0079]

[0080] In the formula, For cache hit rate; To count the number of cache hits within a given period, This represents the total number of resource requests within the statistical period.

[0081] The formula for page rendering time is:

[0082]

[0083] In the formula, Total page rendering time; , For the start and end times of rendering;

[0084] The formula for the duration of blank screen on the page is:

[0085]

[0086] In the formula, This refers to the duration of the blank screen on the page. This refers to the page load trigger time; This is the time when the page was first drawn.

[0087] This invention also provides a mini-program page rendering acceleration and intelligent resource caching system, which employs the above-mentioned mini-program page rendering acceleration and intelligent resource caching method, including:

[0088] Parallel acceleration and asynchronous splitting unit for page rendering: used to split the page rendering process into layers and asynchronously, sequentially executing skeleton screen rendering, core area parallel rendering, and non-core area lazy rendering, and reusing repeated rendering nodes;

[0089] Resource multidimensional classification and pre-caching mechanism unit: used to classify resources in multiple dimensions according to resource type, access frequency, and business weight, and to perform classified pre-caching operations in combination with user page dwell behavior;

[0090] Intelligent cache management and eviction strategy unit: used to build a unified cache management engine to perform expired cleanup, space eviction, deduplication verification, and version isolation operations on cache resources;

[0091] Weak network environment adaptive and incremental rendering unit: used to monitor the terminal network status in real time and dynamically adjust the page rendering range and resource loading strategy according to the network quality level;

[0092] Resource Request Merging and Debouncing Optimization Unit: Used to merge and debouncing page interface requests and resource requests, and to transmit interface data using an incremental mechanism.

[0093] The present invention has the following advantages:

[0094] First, the present invention adopts a layered asynchronous split rendering scheme, which eliminates the problem of synchronous rendering blocking by prioritizing skeleton screen rendering, parallel loading of main resources, lazy rendering of non-core areas and reuse of rendering nodes, greatly shortens the white screen time of the first screen and improves the smoothness of page rendering.

[0095] Secondly, this invention constructs a three-level resource classification and pre-caching mechanism, which manages the cache differently according to resource priority and preloads the main resources in advance; it is equipped with a unified cache management engine that includes TTL expiration, LRU eviction, MD5 / URL deduplication, and version isolation to avoid cache overflow and conflicts with old version resources, improve cache space utilization and cache hit rate, reduce duplicate resource requests, and save terminal network bandwidth.

[0096] Third, this invention can identify network levels in real time and adaptively adjust rendering and loading strategies. It enables thumbnails and incremental interfaces in weak network conditions and can read local cache in offline states, significantly improving the usability and stability of mini-programs in complex network environments.

[0097] Fourth, this invention implements interface merging, request debouncing, incremental data transmission, and differentiated retry logic, effectively reducing invalid network requests, reducing data transmission volume, and lowering the access pressure on server interfaces.

[0098] Fifth, the entire system of this invention adopts a modular collaborative architecture, supports visually customizable parameters such as caching, rendering, and weak network judgment, and can collect and report full-link indicators of rendering, caching, and requests, which facilitates continuous iteration and optimization and is suitable for various high-frequency interactive mini-program scenarios with multiple resources such as e-commerce, finance, and information. Attached Figure Description

[0099] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0100] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0101] Figure 1 This is a schematic diagram of a method for accelerating page rendering and intelligent resource caching in a mini-program, as provided in Embodiment 1 of the present invention.

[0102] Figure 2 This is a technical roadmap for a method to accelerate page rendering and intelligently cache resources in a mini-program, as provided in Embodiment 1 of the present invention.

[0103] Figure 3 This is a schematic diagram of a mini-program page rendering acceleration and intelligent resource caching system architecture provided in Embodiment 1 of the present invention. Detailed Implementation

[0104] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the 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.

[0105] Example 1

[0106] See Figure 1 and Figure 2 This invention provides a method for accelerating page rendering and intelligent resource caching in mini-programs, comprising:

[0107] S1. The page rendering process is divided into layers and asynchronously, and the skeleton screen rendering, core area parallel rendering, and non-core area lazy rendering are executed in sequence, and the repeated rendering nodes are reused.

[0108] S2. Classify resources in multiple dimensions according to resource type, access frequency, and business weight, and perform tiered pre-caching operations in combination with user page dwell behavior;

[0109] S3. Build a unified cache management engine to perform operations such as expiration cleanup, space eviction, deduplication verification, and version isolation on cache resources;

[0110] S4. Monitor the terminal network status in real time and dynamically adjust the page rendering range and resource loading strategy according to the network quality level;

[0111] S5. Merge and debouncing page interface requests and resource requests, and use an incremental mechanism to transmit interface data.

[0112] Specifically, a comprehensive optimization system is built from four dimensions: rendering pipeline, resource caching, network adaptation, and request optimization. This breaks through the traditional architecture bottleneck of "synchronous rendering and single caching" in mini-programs. It reduces first-screen loading time by asynchronously decomposing rendering bottlenecks; enhances cache space value and improves cache hit rate through tiered cache management; ensures availability across all scenarios by adapting to different network environments through adaptive network strategies; and reduces server-side pressure by aggregating request processing to reduce unnecessary network overhead. The entire solution requires no modification to the underlying rendering engine of the mini-program; it achieves rendering acceleration and resource saving solely through upper-level logic scheduling, adapting to various mini-program business scenarios.

[0113] In one possible embodiment, in S1, the hierarchical asynchronous splitting specifically includes:

[0114] When page initialization is triggered, the page structure skeleton is rendered first to generate the skeleton screen;

[0115] Specifically, in the native rendering process of a mini-program, page structure parsing, resource loading, and interface data rendering have a sequential dependency relationship. The duration of the initial blank screen is determined by the total time spent loading the initial resource package and rendering the initial screen. The skeleton screen is a "perception optimization and rendering front-end" approach. It uses a minimalist placeholder structure (gray blocks, line outlines) to replace the complete page content. It can quickly draw the overall outline of the page on the rendering thread without waiting for style files, business scripts, and interface data to finish loading. It reduces waiting anxiety by utilizing the user's perceptual tolerance range, shortens the initial screen waiting time from a subjective perspective, and avoids the experience gap caused by a blank screen.

[0116] The style files, core scripts, and key components are loaded and parsed in parallel to complete the first-screen rendering of the core area of ​​the page, and the loading and parsing process does not block the main rendering thread.

[0117] Specifically, traditional mini-programs use a serial execution mode of "loading, parsing, and rendering." The loading and parsing of styles, scripts, and components consumes resources of the main rendering thread, causing thread blocking and lengthening the first-screen rendering time. Parallel loading relies on the dual-thread architecture of the mini-program, which separates the "logic layer" and "rendering layer." It distributes the loading and parsing tasks of styles, scripts, and key components to asynchronous threads for parallel processing. The main rendering thread is only responsible for drawing the skeleton screen and page structure, avoiding blocking caused by single-threaded task queuing, maximizing the use of the terminal's multi-core computing power and network bandwidth, and compressing the first-screen rendering time of core areas.

[0118] Real-time monitoring of page scrolling and element visibility, based on a formula for determining visible area:

[0119]

[0120] In the formula, For visibility assessment results, To render the vertical coordinate of the element, , These are the coordinates of the upper and lower boundaries of the viewport, respectively; when the determination result... When non-core areas, secondary business components, and non-first-screen images enter the visible area, lazy rendering loading is triggered.

[0121] Specifically, if non-core areas of the page (bottom modules, secondary components, and non-first-screen images) are rendered synchronously during the initialization phase, they will preempt the computing power and bandwidth resources of the core areas, slowing down the rendering speed of the first screen. Lazy rendering is "loaded on demand and overhead is deferred." Through visual listening capabilities such as IntersectionObserver, it calculates the positional relationship between elements and the viewport in real time. Rendering and corresponding resource loading are only triggered when an element enters the user's visible area. The visible area determination formula accurately quantifies the visible state of elements by comparing coordinate ranges, transforming the subjective judgment of "whether it has entered the viewport" into a calculable mathematical logic. This avoids false or missed triggers of lazy rendering, ensuring that non-primary resources are only loaded when needed by the user, prioritizing the rendering efficiency of the main content on the first screen.

[0122] Rendering nodes with the same structure can be reused. The node similarity matching formula is as follows:

[0123]

[0124] when When nodes are identified as having the same structure, they are reused; where, For node similarity, , These are the two rendering nodes to be compared. For the number of identical child nodes, This represents the total number of child nodes. This is the similarity threshold.

[0125] Specifically, the creation and destruction of DOM nodes or custom component nodes by the mini-program rendering engine incurs significant memory overhead and reflow / repaint calculations. Repeated creation of nodes with the same structure during page transitions and list scrolling significantly reduces page smoothness and can even cause lag. Node reuse is a "space-for-time" trade-off. A cache pool of rendered nodes is established, and nodes of the same type are matched using a node structure similarity algorithm. When a new page or new list item needs to render nodes with the same structure, existing node instances in the cache pool are reused, updating only the internal data of the nodes. This avoids repeated node creation, style calculations, and layout reflows, greatly reducing the computational overhead of the rendering engine and improving the smoothness of page scrolling and transitions. The similarity matching formula quantifies the degree of structural similarity using "number of identical child nodes / total number of child nodes," and combines this with a similarity threshold to achieve precise and controllable reuse determination, balancing reuse rate and structural compatibility.

[0126] In one possible embodiment, in S2, the multidimensional grading divides the resources into a three-level resource grading system:

[0127] Level 1 resources are resident cache resources, including core interface data, basic style files, common components, and frequently used images;

[0128] Secondary resources are cached resources based on access frequency, including business page resources and regular interface data;

[0129] Level 3 resources are cached on demand, including low-frequency images and non-critical scripts;

[0130] Specifically, different resources have significantly different impacts on page rendering, user access frequency, and business value. Adopting a uniform caching strategy can lead to a contradiction: "primary resources are easily cleaned up, while low-frequency resources occupy space for extended periods," resulting in low cache space value. Multi-dimensional tiering, based on "value matching and differentiated management," comprehensively assesses the value of resources from three dimensions: resource attributes (type), user behavior (access frequency), and business value (business weight). Resources are divided into three priority levels, each matched with a differentiated caching strategy. High-value level 1 resources are permanently cached to ensure the primary user experience is not degraded; medium-value level 2 resources are dynamically cached based on access frequency, balancing experience and space usage; low-value level 3 resources are cached only on demand during access, avoiding wasted storage space. This tiered approach maximizes the value of cached resources.

[0131] The formula for calculating resource access frequency is:

[0132]

[0133] In the formula, For resource access frequency, To accumulate the number of visits, For statistical periods; combined with access frequency With business weight Delineate resource boundaries at three levels;

[0134] Specifically, access frequency is a key objective indicator for measuring resource popularity. Simply manually classifying resources by level cannot adapt to the differentiated access habits of different users, nor can it cope with the dynamic changes in resource popularity. Access frequency statistics are a "quantified popularity, dynamic classification" approach. It accumulates the number of times a resource is requested within a fixed statistical period, and calculates the access frequency per unit time by "number of accesses / statistical period duration," using a quantitative value to accurately represent the resource's popularity level. Combined with manually configured business weights, it integrates objective user behavior data with subjective business priorities to form a quantifiable and dynamically adjustable three-level resource classification standard. This avoids the rigidity of manual classification and compensates for the bias of single data, making resource classification more closely aligned with actual business scenarios.

[0135] The tiered pre-caching specifically includes: pre-caching first-level resources when a user enters the mini-program; monitoring the user's page dwell time and triggering pre-caching based on the formula:

[0136]

[0137] In the formula, Pre-caching trigger results The duration of time spent on the page. This is the threshold for dwell time; when the judgment result... At that time, pre-cache the next-level related resources corresponding to the current page.

[0138] Specifically, traditional caching mechanisms only store resources locally when actively requested, resulting in an inherent flaw of "must be loaded on first access, inevitably taking time," and failing to eliminate network latency on the first access. Tiered pre-caching, on the other hand, is based on "behavior prediction and pre-loading," leveraging the regularity and predictability of user behavior to pre-load high-probability accessed resources into the local cache. When a mini-program starts, the primary resources are common dependencies of all pages and will inevitably be accessed; therefore, they are pre-loaded to eliminate network latency on the first access of these primary resources. When a user stays on the current page for more than a certain duration, it indicates a high probability that the user will continue browsing the next level of related pages. At this point, related resources are pre-loaded, and when the user navigates to the corresponding page, they can be directly read from the local cache, achieving instant page loading.

[0139] In one possible embodiment, the unified cache management engine construction process in S3 includes:

[0140] Set the TTL expiration time according to the resource type, and the expiration determination formula is as follows:

[0141]

[0142] In the formula, The result of the resource expiration determination. For the current time, For resource storage time, This corresponds to the expiration time of the resource; when Clean up cached resources after they expire;

[0143] Specifically, if cached resources are stored permanently, on the one hand, issues such as outdated content and inconsistencies with the online version can arise, leading to incorrect page display; on the other hand, they will continuously occupy local storage space, resulting in wasted cache space. The TTL expiration mechanism is a "time-sensitive, automatic expiration" system that sets differentiated effective lifespans for different types of resources. By comparing the difference between the current time and the resource's storage time with the TTL value, it determines whether a resource has exceeded its validity period; expired resources are automatically cleaned up. This mechanism ensures consistency between cached content and the online version, avoiding page rendering anomalies caused by old resources, and adapts to the update frequency of different resources through differentiated durations. For example, basic common styles are updated slowly, so a long TTL can be set; promotional images are updated quickly, so a short TTL can be set, achieving a balance between timeliness and user experience.

[0144] The formula for cache space utilization is:

[0145]

[0146] when The elimination mechanism is activated at the appropriate time; where, For cache space usage, Used space Maximum cache space, Spatial threshold;

[0147] Specifically, the storage space of the terminal's local cache has a physical limit. If the cache is continuously written to without control, it will eventually exceed the storage limit, leading to new cache write failures or even system storage anomalies. Space threshold control is a "water level monitoring and trigger eviction" mechanism. It calculates the ratio of used cache space to maximum cache space in real time, i.e., the cache occupancy rate, and uses this as the "water level" of the cache space. When the occupancy rate reaches a preset safety threshold, the cache eviction mechanism is automatically triggered to actively clean up low-value cache resources, keeping the cache space occupancy within a safe range. This fundamentally avoids cache overflow problems and ensures the long-term stable operation of the caching system.

[0148] When cache space usage reaches a preset threshold, an LRU eviction policy is adopted, prioritizing the cleanup of cache resources with the highest priority value, lowest access frequency, lowest cache level, and expired status. The eviction priority formula is:

[0149]

[0150] In the formula, For resources Elimination priority The start time of access. Last access time For resource level, Mark resources as expired. These are weighting coefficients;

[0151] Specifically, traditional LRU eviction policies rely solely on "recent access time" as a single criterion, neglecting the business importance and expiration status of resources. This can easily lead to the accidental deletion of high-value, but recently inaccessible, resources, resulting in a decrease in cache hit rate. This multi-dimensional LRU eviction solution employs a "comprehensive scoring and survival of the fittest" approach. It integrates three dimensions—"recent unused time," "resource level," and "expiration status"—using weighted coefficients to determine a comprehensive eviction priority. Resources with longer unused times, lower resource levels, and expired status have higher priority values ​​and are more likely to be evicted. The weighted coefficients allow for flexible adjustment of the weights for each dimension, adapting to the caching needs of different business scenarios. Within limited cache space, this maximizes the retention of high-value resources and improves the overall cache hit rate.

[0152] Deduplication is performed using MD5 / URL signature for cache deduplication. The formula for determining duplicates is:

[0153]

[0154] In the formula, For the result of duplicate resource determination, URL hash signature algorithm, This refers to the MD5 hash algorithm for resource files. , These are the access addresses of the two resources to be compared. , For two resource files to be compared; when If a resource is identified as a duplicate, a single copy of the same resource will be stored.

[0155] Specifically, the same resource may have multiple access points carrying different URL parameters, such as the same image with different tracking parameters. If cached directly without validation, the same resource will be stored multiple times, severely wasting cache space. MD5 / URL signature deduplication is a "unique identifier, deduplicated storage" method. For URL resources, a unique signature is generated from the main URL after removing redundant parameters using a hash algorithm; for file resources, a unique digest is generated from the file content using an MD5 algorithm. By comparing the signatures / digests of two resources, if they match, they are determined to be the same resource, and only one cache copy is stored. All subsequent requests for the same resource are directed to this copy. This mechanism avoids the duplicate storage of resources from the same origin, significantly improving cache space utilization.

[0156] After updating the mini-program version, clear all cached resources corresponding to the old version.

[0157] Specifically, during mini-program version iterations, page structure, style files, business scripts, and static resources all change. Incompatibility issues exist between old version cached resources and new version code; continued use can lead to page rendering errors, style anomalies, and functional errors. Version isolation involves "version binding and batch cleanup," binding each version's cached resources to a corresponding mini-program version number. When a mini-program version update is detected, all cached resources from the previous version are batch-cleaned, ensuring that the new version only loads resources from the corresponding version, avoiding page anomalies caused by version incompatibility and guaranteeing the stability of version iterations.

[0158] In one possible embodiment, S4 specifically includes:

[0159] Network levels are determined based on a network rate classification formula, which is as follows:

[0160]

[0161] In the formula, For network level, For real-time downlink speed, , For rate grading thresholds;

[0162] Specifically, the bandwidth, latency, and stability vary greatly across different network environments. A uniform rendering and loading strategy cannot adapt to all scenarios, leading to a polarized experience: suboptimal performance under strong network conditions and unusable pages under weak network conditions. Network grading, which involves "quantifying quality and tiered adaptation," collects the terminal's downlink network speed in real time. Using preset two-level speed thresholds, the network is divided into four quality levels: WiFi / 5G, 4G, weak network / 2G, and offline. This serves as the basis for dynamically adjusting rendering and loading strategies. The speed thresholds can be flexibly configured according to business scenarios, ensuring that the grading standards match the actual user experience and providing an accurate basis for subsequent differentiated strategies.

[0163] When the network is in WiFi / 5G mode, perform full page rendering and full resource pre-caching;

[0164] Specifically, WiFi / 5G networks offer high bandwidth, low latency, and low data costs, eliminating concerns about bandwidth usage and data consumption. This strategy, based on "high-quality network, optimal experience," maximizes network bandwidth utilization in a high-quality network environment. It preloads all page resources and multi-level related resources, while simultaneously performing full page rendering to achieve optimal page smoothness and instant page loading, maximizing the user experience.

[0165] When the network is in 4G mode, perform parallel rendering of the core area and pre-caching of key resources, and disable the loading of unnecessary resources;

[0166] Specifically, 4G network bandwidth and data costs are at a moderate level, requiring a balance between user experience and data consumption. The strategy is "moderate network, balanced trade-offs." In a 4G environment, priority is given to ensuring the rendering speed of page areas and the loading of essential business resources, while cutting back on the loading of unnecessary secondary and decorative resources. This ensures that the user's main browsing experience is not significantly affected, while avoiding unnecessary data consumption and loading time, thus achieving a balance between experience and cost.

[0167] When the network is weak / 2G, render the skeleton screen and core text content, and downgrade the images to thumbnails according to the compression formula. The interface returns incremental data.

[0168] The compression formula is:

[0169]

[0170] In the formula, For thumbnail size, Original image size The compression factor is 1.

[0171] Specifically, in weak network / 2G environments, bandwidth is extremely low, latency is high and unstable, and full resource loading can lead to prolonged blank screens or loading failures, resulting in extremely poor page usability. This strategy is "low-quality network, degradation and survival." In low-quality network environments, multiple degradation methods are used to significantly reduce the size of rendered content and resources, minimizing network dependence and retaining only the skeleton screen and core text content to ensure users can access the most basic information. Images are compressed proportionally to reduce their size and resolution, significantly reducing image file size. APIs only return incrementally changing fields, reducing the amount of data transmitted. This degradation approach ensures that pages can still load and be used normally in weak network conditions, improving page usability in extreme network environments.

[0172] When the terminal is offline, load the locally available cached resources.

[0173] Specifically, when the terminal network is disconnected, it cannot initiate any network requests, and traditional mini-programs will directly display a loading failure message, making the page unusable. Offline caching, on the other hand, is a "cache fallback in offline environments." Relying on locally stored effective cache resources, it directly reads the locally cached page to render it even without a network connection, allowing users to still browse previously visited page content. This achieves basic offline usability and significantly improves user experience and product availability in extreme network environments.

[0174] In one possible embodiment, S5, the merging and debouncing optimization of the resource request and the interface request of the page specifically includes:

[0175] Short-interval requests are determined based on a time window formula, which is:

[0176]

[0177] In the formula, The result is determined by the time window. For the current request time, The time of the last request. This is the threshold for the time window;

[0178] Specifically, API merging and request debouncing identify batch / repeated requests within a short period, while the time window is a quantitative standard for determining "short intervals." Time window determination involves "window aggregation and unified processing." A fixed duration threshold is set as the time window, and by comparing the time difference between the current request and the previous request, it's determined whether requests belong to the same window. Requests falling within the same time window can be merged or debounced. The window duration balances request aggregation effectiveness with response latency: a window that is too large increases request response latency, while a window that is too small results in poor request aggregation. It can be flexibly configured according to business scenarios to achieve the optimal balance between experience and performance.

[0179] Multiple API requests triggered at short intervals within the same page are merged into a single batch request;

[0180] Specifically, during page initialization, multiple business interface requests are typically initiated in parallel. Each independent request needs to go through the complete process of establishing a connection, handshake, transmission, and disconnection. Multiple requests generate a large amount of redundant network overhead, and high concurrency increases server load. Interface merging is a method of "batch requests and reduced overhead." It aggregates multiple independent interface requests from the same page within the same time window into a single batch request and sends it to the server. The server then processes the requests uniformly and returns the results in batches. By reducing the number of requests, the overhead of redundant connection establishment is reduced, network congestion is decreased, and the server's request processing pressure is reduced, thereby improving the overall response efficiency of the interfaces.

[0181] Debouncing is implemented for repeated requests for the same resource within a short period of time, merging them into a single request for execution;

[0182] Specifically, when users perform rapid operations, such as frequently switching tabs, quickly scrolling through lists, or repeatedly triggering the same pop-up, requests for the same resource will be repeatedly triggered within a short period. Most of these duplicate requests are invalid, wasting bandwidth and server resources and potentially causing frequent page rendering fluctuations. Request debouncing works by "filtering duplicates and merging executions." Within a time window, multiple requests for the same resource are only retained as one valid request, merged into a single real request, and filtered out the duplicate and invalid requests in between. This mechanism avoids the bandwidth waste from loading duplicate resources and reduces page fluctuations caused by frequent rendering, improving the stability of the interaction process.

[0183] When the interface data is updated, it returns the fields that have changed, but not the full data.

[0184] Specifically, traditional APIs return complete data with each request, with most fields identical to those in the previous request—this redundant data increases transmission volume and loading time, especially noticeable in weak network environments. Incremental transmission, on the other hand, "differential transmission, reducing redundancy." The client sends a version identifier of the previous data with each request. The server compares the version differences and returns only the changed fields. The client then merges these changes locally to obtain the complete data. By transmitting only the differing data, the volume of data transmitted by the API is significantly reduced, shortening network transmission time, with particularly noticeable performance improvements in weak network environments.

[0185] When an interface / resource fails to load, a fast retry operation is performed on the core interface, and a delayed retry operation is performed on the non-core interface.

[0186] The formula for fast retry of the core interface is as follows:

[0187]

[0188] The formula for delaying and retrying non-core interfaces is as follows:

[0189]

[0190] In the formula, , This is the interval between retry attempts. ; , This represents the maximum number of retries. These are preset configuration constants.

[0191] Specifically, network fluctuations can cause occasional API request failures. If a uniform retry strategy is adopted, the problem arises where "delayed retries for core APIs impact user experience, while frequent retries for non-core APIs waste bandwidth resources." Differentiated retries prioritize user experience by implementing tiered retries based on the API's business importance, setting different retry intervals and maximum retries. Core APIs (such as main page data APIs) use short-interval, reasonable-number retries to quickly restore the page to its normal state and ensure a good user experience. Non-core APIs (such as event tracking and decoration data APIs) use longer-interval, fewer-number delayed retries to avoid consuming significant bandwidth resources while maintaining a high request success rate. This differentiated strategy balances retry success rate and resource consumption while ensuring a good user experience.

[0192] In one possible embodiment, before initiating a resource loading request, the local cache is queried first according to the cache hit formula; if the cache is hit, the local cache resource is called; if the cache is not hit, a network request is sent to the server and the requested resource is written to the local cache.

[0193] The cache hit formula is:

[0194]

[0195] In the formula, To cache the hit results, To request a resource identifier, This is a collection of cached resource IDs.

[0196] Specifically, the main value of a caching system lies in replacing network requests with local reads, reducing network dependence and improving loading speed. The cache lookup mechanism follows a "cache-first, origin-only" approach, establishing a resource loading process of "check cache first, request later." All resource requests first access the local cache, matching the cached resource set using the resource's unique identifier. If a match is found, the local cache is read directly without initiating a network request, achieving millisecond-level loading. If a match fails, a network request is initiated to retrieve the resource, and the returned resource is simultaneously stored in the local cache for subsequent requests. This process ensures maximum utilization of cached resources and minimizes network requests, forming the fundamental operational logic of the entire caching system.

[0197] In one possible embodiment, the method further includes marking the page level, the resource type, and the business priority during the mini-program packaging stage, and generating a resource list in resource.json format;

[0198] Integrate the SDK and configure the maximum cache size, expiration time of resources at all levels, rendering thresholds, and weak network judgment criteria;

[0199] When a mini-program starts, it initializes the rendering engine, cache manager, and network listener.

[0200] Specifically, the resource manifest generated during the packaging phase is "marked during compilation and read at runtime." Resource classification and page-level marking are completed in advance during the compilation and packaging phase, and manually configured business priorities are solidified into a resource manifest file. At runtime, the resource attributes can be obtained simply by reading the manifest, eliminating the need for dynamic runtime identification. This improves operational efficiency and ensures the accuracy of resource classification. SDK integration and parameter configuration are "unified management and flexible adaptation." All configurable parameters are managed uniformly, allowing business users to customize and adjust thresholds according to their own scenarios, improving the solution's versatility and scenario adaptability. The startup initialization module is "pre-ready and effective across the entire chain." The initialization of major modules such as rendering scheduling, cache management, and network monitoring is completed early in the mini-program's lifecycle, ensuring that the entire optimization mechanism is ready when the page loads and is effective across the entire chain from the first page.

[0201] In one possible embodiment, the data collection also includes real-time collection of page rendering time, cache hit rate, interface request time, and page white screen duration, and the collection data is reported externally.

[0202] The cache hit rate formula is:

[0203]

[0204] In the formula, For cache hit rate; To count the number of cache hits within a given period, This represents the total number of resource requests within the statistical period.

[0205] The formula for page rendering time is:

[0206]

[0207] In the formula, Total page rendering time; , For the start and end times of rendering;

[0208] The formula for the duration of blank screen on the page is:

[0209]

[0210] In the formula, This refers to the duration of the blank screen on the page. This refers to the page load trigger time; This is the time when the page was first drawn.

[0211] Specifically, the actual effectiveness of optimization strategies needs to be quantitatively evaluated and continuously iterated and adjusted based on actual operational data to ensure optimal long-term results. Data collection and reporting is a process of "quantitative evaluation and data-driven," collecting performance metrics across the entire rendering, caching, and request chain through front-end event tracking, quantifying metric values ​​using standardized formulas, and uniformly reporting them to the data analysis platform. These metrics allow for the evaluation of the actual effects of rendering acceleration and caching optimization, precise identification of performance bottlenecks, and targeted adjustments to caching thresholds, resource tiering strategies, network adaptation parameters, etc., enabling continuous iteration of optimization strategies and ensuring that performance remains at an optimal level in the long term.

[0212] The application scenarios of this invention are as follows:

[0213] Online business scenarios for e-commerce mini-programs: Suitable for online retailers and e-commerce platform operators in high-frequency access stages such as product browsing, shopping cart, order checkout, and marketing activities. Adaptable to the concurrent loading requirements of massive product images, pop-up components, and marketing interfaces. Traditional mini-program synchronous rendering is prone to problems such as blank product lists, repeated image loading, and order lag in weak network conditions. The lack of tiered caching leads to frequent product resource invalidation. This solution uses layered asynchronous rendering with three-level resource pre-caching, and adaptively loads thumbnails in weak network conditions, significantly shortening product page loading speed, reducing repeated interface requests, and improving user order conversion rates.

[0214] Content distribution scenarios for news feed mini-programs: Suitable for news, text, and short video news platforms, this solution addresses high-frequency interaction points such as news feed scrolling, column switching, and content detail page browsing. It adapts to the needs of massive text and image materials, pagination interfaces, and simultaneous loading of multiple column components. Traditional solutions re-request image and content interfaces with each scroll, resulting in scrolling lag and cache space being occupied by low-frequency old information. This solution implements lazy rendering of non-essential content, LRU intelligent eviction of expired information resources, and merges pagination interface requests, improving the smoothness of news feed scrolling and reducing data consumption.

[0215] Financial service mini-program business processing scenarios: Applicable to online business processing of banks, insurance companies, and wealth management institutions, it adapts to multiple business page switching for account inquiry, wealth management products, and insurance policy processing, and contains a large number of core interfaces and compliant static component resources. Traditional mini-program caching lacks version isolation, and version updates are prone to page function errors. Under weak network conditions, business interfaces may fail to load and basic information cannot be viewed offline. This solution permanently caches the main financial resources, automatically clears the old cache with version updates, and uses incremental interfaces and offline caching as a backup in weak network conditions to ensure the stability of financial business access.

[0216] Local life tool mini-program service traffic acquisition scenarios: Applicable to local life merchants in catering, housekeeping, and travel, with multiple usage scenarios including store display, group purchase verification, and location navigation, covering various network environments such as outdoor 2G / weak network and public WiFi; Traditional mini-programs fully load large store images and group purchase interfaces, resulting in long loading failures of outdoor weak network pages, and repeated location and group purchase requests exacerbating server pressure. This solution dynamically degrades rendering according to network level, anti-jitter merges repeated location resource requests, and only displays text and thumbnail store images in weak network environments, improving the usability of mini-programs in offline weak network environments.

[0217] This enterprise internal office mini-program is designed for employee work scenarios, suitable for corporate administration and human resources departments. It addresses high-frequency page switching scenarios involving attendance tracking, approval processes, document viewing, and notifications. It includes numerous common form components, approval interfaces, and attachment image resources. Traditional mini-programs lack a node reuse mechanism, leading to significant rendering lag due to frequent page switching and long-term cache occupation of low-frequency historical approval files. This solution reuses form rendering nodes, implements hierarchical management of office resource caching, automatically cleans up low-frequency historical files, improves the smoothness of multi-page switching, and optimizes terminal storage space usage.

[0218] It should be noted that the method of this embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this embodiment, and these multiple devices will interact with each other to complete the described method for accelerating mini-program page rendering and intelligently caching resources.

[0219] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0220] Example 2

[0221] See Figure 3 Embodiment 2 of the present invention also provides a mini-program page rendering acceleration and intelligent resource caching system, which adopts the above-mentioned mini-program page rendering acceleration and intelligent resource caching method, including:

[0222] Page rendering parallel acceleration and asynchronous splitting unit 100: used to perform layered asynchronous splitting of the page rendering process, sequentially executing skeleton screen rendering, core area parallel rendering, non-core area lazy rendering, and reusing repeated rendering nodes.

[0223] Resource multidimensional classification and pre-caching mechanism unit 200: used to classify resources in multiple dimensions according to resource type, access frequency and business weight, and perform classified pre-caching operations in combination with user page dwell behavior;

[0224] Intelligent Cache Management and Eviction Strategy Unit 300: Used to build a unified cache management engine to perform expired cleanup, space eviction, deduplication verification, and version isolation operations on cache resources;

[0225] Weak network environment adaptive and incremental rendering unit 400: used to monitor the terminal network status in real time and dynamically adjust the page rendering range and resource loading strategy according to the network quality level;

[0226] Resource Request Merging and Debouncing Optimization Unit 500: Used to merge and debouncing page interface requests and resource requests, and to transmit interface data using an incremental mechanism.

[0227] It should be noted that the information interaction and execution process between the modules of the above-mentioned device are based on the same concept as the method embodiment in Embodiment 1 of this application, and the resulting technical effects are the same as those in the method embodiment of this application. For details, please refer to the description in the method embodiment shown above in this application, and it will not be repeated here.

[0228] Example 3

[0229] Embodiment 3 of the present invention provides a non-transitory computer-readable storage medium storing program code for a method of accelerating page rendering and intelligent resource caching in mini-programs. The program code includes instructions for executing the method of accelerating page rendering and intelligent resource caching in mini-programs as described in Embodiment 1 or any possible implementation thereof.

[0230] Computer-readable storage media can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0231] Example 4

[0232] Embodiment 4 of the present invention provides an electronic device, including: a memory and a processor;

[0233] The processor and the memory communicate with each other via a bus; the memory stores program instructions that can be executed by the processor, and the processor can execute the mini-program page rendering acceleration and resource intelligent caching method of Embodiment 1 or any possible implementation thereof by calling the program instructions.

[0234] Specifically, a processor can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. This memory can be integrated into the processor or located outside the processor and exist independently.

[0235] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0236] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0237] Although the present invention has been described in detail above with general descriptions and specific embodiments, modifications or improvements can be made to it, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present invention fall within the scope of protection claimed by the present invention.

Claims

1. A method for accelerating page rendering and intelligently caching resources in mini-programs, characterized in that, include: S1. The page rendering process is divided into layers and asynchronously, and skeleton screen rendering, core area parallel rendering, and non-core area lazy rendering are executed. Repeated rendering nodes are reused. S2. Classify resources in multiple dimensions according to resource type, access frequency, and business weight, and perform tiered pre-caching operations in combination with user page dwell behavior; S3. Build a unified cache management engine to perform operations such as expiration cleanup, space eviction, deduplication verification, and version isolation on cache resources; S4. Monitor the terminal network status in real time and dynamically adjust the page rendering range and resource loading strategy according to the network quality level; S5. Merge and debouncing page interface requests and resource requests, and use an incremental mechanism to transmit interface data.

2. The method for accelerating page rendering and intelligent resource caching in mini-programs according to claim 1, characterized in that, In S1, the hierarchical asynchronous splitting specifically includes: When page initialization is triggered, the page structure skeleton is rendered first to generate the skeleton screen; The style files, core scripts, and key components are loaded and parsed in parallel to complete the first-screen rendering of the core area of ​​the page, and the loading and parsing process does not block the main rendering thread. Real-time monitoring of page scrolling and element visibility, based on a formula for determining visible area: In the formula, For visibility assessment results, To render the vertical coordinate of the element, , These are the coordinates of the upper and lower boundaries of the viewport, respectively; when the determination result... When non-core areas, secondary business components, and non-first-screen images enter the visible area, lazy rendering loading is triggered. Rendering nodes with the same structure can be reused. The node similarity matching formula is as follows: when When nodes are identified as having the same structure, they are reused; where, For node similarity, , These are the two rendering nodes to be compared. For the number of identical child nodes, This represents the total number of child nodes. This is the similarity threshold.

3. The method for accelerating page rendering and intelligent resource caching in mini-programs according to claim 1, characterized in that, In S2, the multidimensional grading divides resources into a three-level resource grading system: Level 1 resources are resident cache resources, including core interface data, basic style files, common components, and frequently used images; Secondary resources are cached resources based on access frequency, including business page resources and regular interface data; Level 3 resources are cached on demand, including low-frequency images and non-critical scripts; The formula for calculating resource access frequency is: In the formula, For resource access frequency, To accumulate the number of visits, For statistical periods; combined with access frequency With business weight Delineate resource boundaries at three levels; The tiered pre-caching specifically includes: pre-caching first-level resources when a user enters the mini-program; monitoring the user's page dwell time and triggering pre-caching based on the formula: In the formula, Pre-caching trigger results The duration of time spent on the page. This is the threshold for dwell time; when the judgment result... At that time, pre-cache the next-level related resources corresponding to the current page.

4. The method for accelerating page rendering and intelligent resource caching in mini-programs according to claim 1, characterized in that, In S3, the construction process of the unified cache management engine includes: Set the TTL expiration time according to the resource type, and the expiration determination formula is as follows: In the formula, The result of the resource expiration determination. For the current time, For resource storage time, This corresponds to the expiration time of the resource; when Clean up cached resources after they expire; The formula for cache space utilization is: when The elimination mechanism is activated at the appropriate time; where, For cache space usage, Used space Maximum cache space, Spatial threshold; When cache space usage reaches a preset threshold, an LRU eviction policy is adopted, prioritizing the cleanup of cache resources with the highest priority value, lowest access frequency, lowest cache level, and expired status. The eviction priority formula is: In the formula, For resources Elimination priority The start time of access. Last access time For resource level, Mark resources as expired. These are weighting coefficients; Deduplication is performed using MD5 / URL signature for cache deduplication. The formula for determining duplicates is: In the formula, For the result of duplicate resource determination, URL hash signature algorithm, This refers to the MD5 hash algorithm for resource files. , These are the access addresses of the two resources to be compared. , For two resource files to be compared; when If a resource is identified as a duplicate, a single copy of the same resource will be stored. After updating the mini-program version, clear all cached resources corresponding to the old version.

5. The method for accelerating page rendering and intelligent resource caching in mini-programs according to claim 1, characterized in that, In S4, the dynamic adjustment specifically includes: Network levels are determined based on a network rate classification formula, which is as follows: In the formula, For network level, For real-time downlink speed, , For rate grading thresholds; When the network is in WiFi / 5G mode, perform full page rendering and full resource pre-caching; When the network is in 4G mode, perform parallel rendering of the core area and pre-caching of key resources, and disable the loading of unnecessary resources; When the network is weak / 2G, render the skeleton screen and core text content, and downgrade the images to thumbnails according to the compression formula. The interface returns incremental data. The compression formula is: In the formula, For thumbnail size, Original image size The compression factor is 1. When the terminal is offline, load the locally available cached resources.

6. The method for accelerating page rendering and intelligent resource caching in mini-programs according to claim 1, characterized in that, In S5, the merging and debouncing optimization of the resource requests and interface requests on the page specifically includes: Short-interval requests are determined based on a time window formula, which is: In the formula, The result is determined by the time window. For the current request time, The time of the last request. This is the threshold for the time window; Multiple API requests triggered at short intervals within the same page are merged into a single batch request; Debouncing is implemented for repeated requests for the same resource within a short period of time, merging them into a single request for execution; When the interface data is updated, it returns the fields that have changed, but not the full data. When an interface / resource fails to load, a fast retry operation is performed on the core interface, and a delayed retry operation is performed on the non-core interface. The formula for fast retry of the core interface is as follows: The formula for delaying and retrying non-core interfaces is as follows: In the formula, , This is the interval between retry attempts. ; , This represents the maximum number of retries. These are preset configuration constants.

7. The method for accelerating page rendering and intelligent resource caching in mini-programs according to claim 1, characterized in that, Before initiating a resource loading request, the local cache is queried first according to the cache hit formula; if the cache is hit, the local cached resource is called; if the cache is not hit, a network request is sent to the server and the requested resource is written to the local cache. The cache hit formula is: In the formula, To cache the hit results, To request a resource identifier, This is a collection of cached resource IDs.

8. The method for accelerating page rendering and intelligent resource caching in mini-programs according to claim 1, characterized in that, It also includes marking the page level, the resource type, and the business priority during the mini-program packaging stage, and generating a resource list in resource.json format; Integrate the SDK and configure the maximum cache size, expiration time of resources at all levels, rendering thresholds, and weak network judgment criteria; When a mini-program starts, it initializes the rendering engine, cache manager, and network listener.

9. The method for accelerating page rendering and intelligent resource caching in mini-programs according to claim 1, characterized in that, It also includes real-time collection of page rendering time, cache hit rate, interface request time, and page white screen duration, and reports the collected data to the outside world; The cache hit rate formula is: In the formula, For cache hit rate; To count the number of cache hits within a given period, This represents the total number of resource requests within the statistical period. The formula for page rendering time is: In the formula, Total page rendering time; , For the start and end times of rendering; The formula for the duration of blank screen on the page is: In the formula, This refers to the duration of the blank screen on the page. This refers to the page load trigger time; This is the time when the page was first drawn.

10. A system for accelerating page rendering and intelligently caching resources in a mini-program, employing the method for accelerating page rendering and intelligently caching resources in a mini-program as described in any one of claims 1-9, characterized in that, include: Parallel acceleration and asynchronous splitting unit for page rendering: used to perform layered asynchronous splitting of the page rendering process, execute skeleton screen rendering, core area parallel rendering, non-core area lazy rendering, and reuse repeated rendering nodes; Resource multidimensional classification and pre-caching mechanism unit: used to classify resources in multiple dimensions according to resource type, access frequency, and business weight, and to perform classified pre-caching operations in combination with user page dwell behavior; Intelligent cache management and eviction strategy unit: used to build a unified cache management engine to perform expired cleanup, space eviction, deduplication verification, and version isolation operations on cache resources; Weak network environment adaptive and incremental rendering unit: used to monitor the terminal network status in real time and dynamically adjust the page rendering range and resource loading strategy according to the network quality level; Resource Request Merging and Debouncing Optimization Unit: Used to merge and debouncing page interface requests and resource requests, and to transmit interface data using an incremental mechanism.

Images