Atomized multi-resource data transmission optimization method
By constructing a resource dependency graph and employing a two-stage optimization strategy, the problems of large HTTP request volume and performance bottlenecks caused by atomic resources were solved, achieving efficient resource aggregation and on-demand loading, thus improving front-end performance and flexibility.
Patent Information
- Application Number
- CN202511681267.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-17
- Publication Date
- 2026-02-06
AI Technical Summary
In existing technologies, the widespread use of atomic CSS and modular JS leads to the loading of a large number of small resource files on the page, which makes it impossible for HTTP/2 and multiplexing technologies to effectively solve the problems of header overhead, head-of-line blocking and browser concurrency limitations. Traditional solutions lack flexibility and efficiency.
By constructing a resource dependency graph, resources are clustered based on dependency relationships and usage frequency, divided into multiple groups, and packaged into resource collection package files to generate manifest files. A two-stage optimization strategy is adopted to preload key sub-packages during construction and intercept requests to match collection packages at runtime.
It significantly reduces the number of HTTP requests, alleviates header overhead and head-of-line blocking, improves cache utilization and resource loading flexibility, and reduces implementation costs for developers.
Smart Images
Figure CN121486480A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of front-end rendering, and in particular to an atomic multi-resource data transmission optimization method. Background Technology
[0002] As web applications become increasingly complex, the number and granularity of front-end resources are constantly refining, especially with the widespread use of atomic CSS and modular JS, resulting in pages needing to load hundreds or even thousands of small resource files. Although HTTP / 2 and multiplexing technologies have alleviated connection bottlenecks to some extent, a large number of small file requests still bring significant header overhead, head-of-line blocking risks, and browser concurrency limitations, severely impacting first-screen loading time and runtime performance.
[0003] Traditional solutions such as resource merging, sprite sheets, and domain sharding, while reducing the number of requests, lack flexibility, are detrimental to caching optimization and on-demand loading, and cannot adapt to dynamically generated atomic resources. The Web Bundle format provides a mechanism for packaging multiple resources into a single file, but currently lacks intelligent aggregation and delivery strategies for atomic resources. Directly packaging the entire resource leads to resource waste, while manual configuration is inefficient and difficult to scale in real-world projects. Therefore, an optimization method for atomic multi-resource data transmission is needed to address the issues of inefficiency and flexibility in front-end resource delivery and request processes. Summary of the Invention
[0004] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the inefficiency and lack of flexibility in the front-end resource delivery and request process in the prior art.
[0005] In a first aspect, this application provides an atomic multi-resource data transmission optimization method, the method comprising:
[0006] Scan the atomic resources in the project source code to obtain resource metadata and resource dependencies;
[0007] The resource metadata includes extracted resource type data, resource volume data, and resource attribute data;
[0008] Based on the resource dependencies, construct a resource dependency graph;
[0009] Based on the resource dependency map and resource usage frequency, each of the atomized resources is divided into multiple resource groups through resource clustering.
[0010] The resources within each resource group are packaged into a resource collection package file, and a list file recording the resource metadata and resource mapping relationships is generated;
[0011] During the application phase of the resource collection package file, client resource requests are intercepted, and the corresponding resource collection package file is matched and loaded and parsed based on the manifest file.
[0012] As an optional implementation, constructing a resource dependency graph based on the resource dependency relationship includes:
[0013] Extract resource type identifiers and mark the hierarchical path location information of resources in the component dependency tree;
[0014] Based on the component information and routing information in the resource dependency relationship, the reference relationship between resources is determined, and a resource dependency graph is constructed.
[0015] As an optional implementation, the method further includes assigning grouping priorities to each of the atomized resources;
[0016] The allocation method for the group priority includes:
[0017] Assign the highest priority to script resources that execute synchronously and style resources that affect the first screen rendering;
[0018] Assign second priority to asynchronously loaded script and font resources;
[0019] Assign the third priority to image resources and style resources required for non-first screen rendering.
[0020] As an optional implementation, packaging the resources within each resource group into a resource collection package file includes:
[0021] Determine the grouping conditions for each resource group and adjust the combination method of each resource group;
[0022] The grouping conditions include any one of the following:
[0023] The group is a high-aggregation resource group, which contains a preset number of the atomic resources. The resource type identifiers of the atomic resources in the group are consistent and the group priority belongs to the same level. The frequency of co-occurrence of the atomic resources in the same functional module exceeds a preset threshold.
[0024] In addition, a global resource index table is established across resource groups, and the entity content of duplicate resources is retained only in the highest priority group, and an integrity check value based on the file content is generated for each resource collection package file.
[0025] As an optional implementation, the application phase includes a loading phase and a running phase. In the application phase of the resource collection package file, intercepting client resource requests, matching the corresponding resource collection package file based on the manifest file, and loading and parsing it includes:
[0026] During the loading phase, a preloading instruction corresponding to the target collection package file is injected into the page document template, and the preloading instruction is associated with the route or entry point indicated by the page document template.
[0027] During the operation phase, browser events are monitored, the Uniform Resource Locator (URL) of the resource request is parsed, the target resource is determined, the manifest file is queried, the corresponding resource collection package file is matched for the target resource, the matching file is loaded and the target resource is extracted, the original independent resource request process is terminated, and if it fails to match the corresponding resource collection package file for the target resource, an independent resource request is initiated according to the original resource request path.
[0028] As an optional implementation, during the loading phase, the method further includes:
[0029] The resource collection package file is split into route-specific sub-packages;
[0030] Declare the mapping relationship between the route path and the route-specific sub-packet in the manifest file;
[0031] Based on the resource attributes corresponding to each atomic resource in the resource collection package file and the user requirement information of the application stage, the loading order of sub-packages is dynamically adjusted.
[0032] Secondly, this application provides an atomized multi-resource data transmission optimization device, comprising:
[0033] The acquisition module is used to scan atomic resources in the project source code to obtain resource metadata and resource dependencies.
[0034] The resource metadata includes extracted resource type data, resource volume data, and resource attribute data;
[0035] The processing module is used to construct a resource dependency graph based on the resource dependency relationships;
[0036] The processing module is further configured to divide each of the atomized resources into multiple resource groups by resource clustering based on the resource dependency graph and resource usage frequency;
[0037] The processing module is further configured to package the resources in each resource group into a resource collection package file, and generate a list file that records the resource metadata and resource mapping relationships;
[0038] The processing module is also used to intercept client resource requests during the application phase of the resource collection package file, match the corresponding resource collection package file based on the manifest file, and load and parse it.
[0039] As an optional implementation, the specific method by which the processing module constructs a resource dependency graph based on the resource dependency relationship includes:
[0040] Extract resource type identifiers and mark the hierarchical path location information of resources in the component dependency tree;
[0041] Based on the component information and routing information in the resource dependency relationship, the reference relationship between resources is determined, and a resource dependency graph is constructed.
[0042] Thirdly, this application provides a computer device including one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method described in the first aspect.
[0043] Fourthly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method described in the first aspect.
[0044] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:
[0045] Based on any of the above embodiments, this application constructs a resource dependency graph to accurately depict the logical relationships and hierarchical structure of atomic resources, laying a data foundation for dynamic grouping. Based on the graph and a clustering algorithm using usage frequency, frequently co-occurring and functionally cohesive resources are intelligently grouped into resource groups, completely replacing traditional manual configuration methods and avoiding problems with redundant merging and improper splitting. By packaging resource groups into a collection package file with integrity verification and generating a manifest file recording metadata and mapping relationships, the aggregation, encapsulation, and reliable delivery of atomic resources are achieved. A two-stage optimization strategy is adopted in the application phase: during construction, key sub-packages are preloaded according to the route; at runtime, requests are intercepted and the manifest file is queried to match and load the collection package, directly reducing the number of actual network requests. Thus, on the one hand, the number of HTTP requests is significantly reduced, alleviating header overhead, head-of-line blocking, and concurrency limitations; on the other hand, intelligent grouping ensures on-demand resource loading, improving cache utilization and update flexibility. Ultimately, a full-link optimization is formed from resource analysis, grouping decision-making, packaging, and request interception, ensuring front-end performance while seamlessly integrating into existing build toolchains, significantly reducing developer implementation costs. Attached Figure Description
[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0047] Figure 1 This is a flowchart illustrating an embodiment of the atomic multi-resource data transmission optimization method provided in this application.
[0048] Figure 2 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation
[0049] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0050] First, let's explain the main terms that may be involved:
[0051] Web Bundle (.wbn): A format that packages multiple web resources (such as HTML, CSS, JS, images, etc.) into a single binary file that can be directly loaded and parsed by a browser.
[0052] Atomic CSS / JS: refers to breaking down styles or scripts into extremely fine-grained units to improve reusability and maintainability.
[0053] Multi-resource atomic delivery: Aggregate and deliver a large number of fine-grained CSS / JS modules through the Web Bundle format, reducing the number of network requests and improving loading performance.
[0054] Request merging strategy: Dynamically identify mergeable resource requests during the build phase or runtime, and aggregate them into fewer network requests to reduce latency and connection overhead.
[0055] As web applications become increasingly complex, the number and granularity of front-end resources are constantly refining, especially with the widespread use of atomic CSS and modular JS, resulting in pages needing to load hundreds or even thousands of small resource files. Although HTTP / 2 and multiplexing technologies have alleviated connection bottlenecks to some extent, a large number of small file requests still bring significant header overhead, head-of-line blocking risks, and browser concurrency limitations, severely impacting first-screen loading time and runtime performance.
[0056] Traditional solutions such as resource merging, sprite sheets, and domain fragmentation can reduce the number of requests, but they lack flexibility, are not conducive to cache optimization and on-demand loading, and cannot adapt to dynamically generated atomic resources.
[0057] Web Bundle formats (such as the Web Packaging standard proposed by Google) provide a mechanism for packaging multiple resources into a single file, but currently lack intelligent aggregation and delivery strategies for atomic resources. Direct full packaging leads to resource waste, while manual configuration is inefficient and difficult to scale in real-world projects.
[0058] Specifically, some feasible implementation methods may include: Traditional resource merging tools (such as Webpack's SplitChunksPlugin): These merge multiple modules into a few chunks through configuration, but they cannot dynamically identify the dependencies of atomic resources, easily leading to redundancy or improper splitting. HTTP / 2 Server Push: The server can actively push relevant resources, but this requires server-side support, and the push strategy is difficult to control precisely, easily resulting in pushing too many or too few resources. Preloading and pre-rendering: Through... <link rel="preload"> Alternatively, pre-rendering pages can load resources in advance, but this doesn't reduce the number of requests and may even increase network contention. The basic Web Bundle solution involves manually bundling resources using the wbn command-line tool or library, but it lacks intelligent request merging strategies and runtime adaptation mechanisms, making it unsuitable for high-frequency update scenarios involving atomic resources.
[0059] Therefore, these feasible implementation methods may have the following problems: First, the resource merging strategy is crude: traditional merging tools are based on configuration rather than actual usage, and cannot adapt to the dynamic dependencies of atomic resources. Second, it cannot reduce the number of requests: while HTTP / 2 Push and preloading can improve loading efficiency, they do not reduce the number of requests, and header overhead still exists. Third, manual bundling is inefficient: basic Web Bundle solutions require developers to manually specify the bundled content, which is not suitable for large projects with tens of thousands of atomic resources. Fourth, it lacks runtime adaptation: most existing solutions rely on build-time decisions and cannot dynamically adjust the delivery strategy according to the runtime context.
[0060] Therefore, this application implements intelligent analysis and dependency graph construction of atomic CSS / JS resources to identify mergeable resource groups. It provides a multi-resource atomic delivery mechanism based on Web Bundle, packaging fine-grained resources into .wbn files, significantly reducing HTTP requests. A dynamic request merging strategy is designed to support both build-time and runtime optimization, improving delivery flexibility. Seamless integration with existing build toolchains (Webpack, Vite, Rollup) is achieved, supporting visual configuration and reporting output.
[0061] In summary, the technical concept of this application lies in constructing a resource dependency graph to accurately depict the logical relationships and hierarchical structure of atomic resources, laying a data foundation for dynamic grouping. Based on the graph and a clustering algorithm using usage frequency, resources with high frequency co-occurrence and functional cohesion are intelligently divided into resource groups, completely replacing the traditional manual configuration method and avoiding problems of redundant merging and improper splitting. By packaging resource groups into collection package files with integrity verification and generating manifest files that record metadata and mapping relationships, the aggregation, encapsulation, and reliable delivery of atomic resources are achieved. A two-stage optimization strategy is adopted in the application phase: key sub-packages are preloaded according to the route during the build process, and requests are intercepted at runtime and the manifest file is queried to match and load collection packages, directly reducing the number of actual network requests. Thus, on the one hand, the number of HTTP requests is significantly reduced, alleviating header overhead, head-of-line blocking, and concurrency limitations; on the other hand, intelligent grouping ensures that resources are loaded on demand, improving cache utilization and update flexibility. Ultimately, a full-link optimization is formed from resource analysis, grouping decision-making, packaging and encapsulation to request interception, which, while ensuring front-end performance, is seamlessly integrated into the existing build toolchain, significantly reducing the implementation cost for developers.
[0062] The methods provided in this application will be described in detail below based on the corresponding implementation methods in some practical application scenarios.
[0063] The core problem this application seeks to solve is that atomic resources (CSS / JS) result in a large number of small file requests, and traditional merging solutions lack dynamism and intelligence.
[0064] The main points of this application are:
[0065] Intelligent grouping: Dynamically clustering resource groups based on dependency graphs and usage frequency (not simple merging);
[0066] Atomic delivery: Package resource groups (.wbn files) in Web Bundle format;
[0067] Dual optimization: build-time preloading + runtime request interception;
[0068] Seamless integration: Build tools are implemented through plug-in architecture.
[0069] In summary, this application provides an optimization method for multi-resource atomic delivery and request merging based on network resource collection packets. The core logic includes:
[0070] During the resource graph construction phase, the project source code is scanned to extract metadata (resource type identifier, volume data, dependencies) of atomic resources, and a resource dependency graph with hierarchical paths is constructed. Static syntax analysis is used to mark the position of resources in the component tree, and route configuration is parsed to determine resource loading boundaries.
[0071] In the dynamic grouping decision-making phase, a resource clustering algorithm is executed based on the map and usage frequency data:
[0072] Group resources according to their co-occurrence frequency in the same route / component, which is greater than or equal to a threshold.
[0073] Verify that the consistency of resource types and the priority difference within the verification group are ≤ the preset range;
[0074] Assign a three-level loading priority (synchronous scripts / critical styles → asynchronous scripts / fonts → images / non-critical styles).
[0075] During the packaging and delivery phase, a network resource collection package file with integrity verification values is generated, a global index table is established to achieve cross-group resource deduplication (only the highest priority group retains entities), and a manifest file is generated to declare the resource path list, verification values, and route-sub-packet mapping relationships.
[0076] The two-phase optimization execution phase includes: Build-time optimization: injecting key resource package preloading instructions into the page document; splitting sub-packages according to route entry points. Runtime optimization includes: a) listening for route switching events; b) parsing request URLs to query manifest files; c) loading matching resource packages and extracting target resources; d) enabling a fallback mechanism (initiating an independent request when a match fails).
[0077] Ultimately, resource request volume compression can be achieved, and the output of grouped distribution data and merged statistical reports can be integrated through toolchain plugins.
[0078] Figure 1 This is a flowchart illustrating an embodiment of the atomic multi-resource data transmission optimization method provided in this application, as shown below. Figure 1 As shown, this application provides an atomic multi-resource data transmission optimization method, the method comprising:
[0079] S101. Scan the atomic resources in the project source code to obtain resource metadata and resource dependencies;
[0080] The resource metadata includes extracted resource type data, resource volume data, and resource attribute data;
[0081] S102. Construct a resource dependency graph based on the resource dependency relationships;
[0082] S103. Based on the resource dependency map and resource usage frequency, each of the atomized resources is divided into multiple resource groups by resource clustering;
[0083] S104. Package the resources in each resource group into a resource collection package file, and generate a list file that records the resource metadata and resource mapping relationships;
[0084] S105. During the application phase of the resource collection package file, intercept client resource requests, match the corresponding resource collection package file based on the manifest file, and load and parse it.
[0085] This implementation method obtains the metadata and dependencies of atomic resources by scanning the project source code, constructs a resource dependency graph, and accurately depicts the logical relationships and hierarchical structure between resources. Based on this graph and the frequency of resource usage, it performs intelligent clustering and grouping, classifying frequently co-occurring and functionally coupled resources into the same resource group, effectively avoiding the subjectivity and redundancy problems of traditional merging schemes. By packaging resource groups into collection package files and generating manifest files, it achieves the aggregation and encapsulation of atomic resources, ensuring the integrity of resource delivery. During the application phase, it intercepts client requests and loads the corresponding collection package based on the manifest file, directly reducing the number of actual network requests and significantly reducing header overhead and head-of-line blocking risks. Thus, it not only solves the performance bottleneck caused by a large number of small file requests, but also ensures on-demand loading and caching efficiency of resources through a dynamic grouping mechanism, fundamentally improving the flexibility and execution efficiency of front-end resource transmission.
[0086] As an optional implementation, constructing a resource dependency graph based on the resource dependency relationship includes:
[0087] Extract resource type identifiers and mark the hierarchical path location information of resources in the component dependency tree;
[0088] Based on the component information and routing information in the resource dependency relationship, the reference relationship between resources is determined, and a resource dependency graph is constructed.
[0089] This implementation method accurately locates the topological relationships of resources within the project structure by extracting resource type identifiers and marking hierarchical path positions in the component dependency tree. It combines component information and routing information to determine the reference relationships between resources, constructing a multi-dimensional dependency graph. This graph not only reflects static dependencies but also divides dynamic loading units through routing boundaries, making subsequent resource grouping more aligned with actual usage scenarios. This improves the accuracy of dependency analysis, provides a data foundation for the intelligent partitioning of highly cohesive resource groups, avoids errors from manual configuration, and enhances the adaptability of optimization strategies.
[0090] As an optional implementation, the method further includes assigning grouping priorities to each of the atomized resources;
[0091] The allocation method for the group priority includes:
[0092] Assign the highest priority to script resources that execute synchronously and style resources that affect the first screen rendering;
[0093] Assign second priority to asynchronously loaded script and font resources;
[0094] Assign the third priority to image resources and style resources required for non-first screen rendering.
[0095] This implementation allocates three levels of priority based on resource type and rendering criticality: the highest priority is given to synchronous scripts and critical styles for the first screen, ensuring fast loading of core page functions; medium priority is given to asynchronous scripts and fonts, balancing functional integrity and loading sequence; and low priority is given to images and non-critical styles, delaying the loading of non-core resources. This strategy, by differentiating resource importance levels, ensures that high-priority resources are packaged and preloaded first, thereby specifically optimizing the first screen rendering time, preventing low-priority resources from blocking critical requests, and improving user experience.
[0096] As an optional implementation, packaging the resources within each resource group into a resource collection package file includes:
[0097] Determine the grouping conditions for each resource group and adjust the combination method of each resource group;
[0098] The grouping conditions include any one of the following:
[0099] The group is a high-aggregation resource group, which contains a preset number of the atomic resources. The resource type identifiers of the atomic resources in the group are consistent and the group priority belongs to the same level. The frequency of co-occurrence of the atomic resources in the same functional module exceeds a preset threshold.
[0100] In addition, a global resource index table is established across resource groups, and the entity content of duplicate resources is retained only in the highest priority group, and an integrity check value based on the file content is generated for each resource collection package file.
[0101] This implementation ensures that resources within a group are highly correlated and frequently co-occur by setting conditions for resource grouping (such as high group cohesion, consistent resource type, same priority level, and co-occurrence frequency exceeding a threshold), thus reducing invalid merging. A cross-group global index table is established to retain entities of duplicate resources only in the highest priority group, eliminating redundant storage. A content-based integrity check value is generated for each collection packet to ensure transmission reliability. Therefore, while maintaining resource group cohesion, packet size is significantly reduced, and cache utilization and loading efficiency are optimized.
[0102] As an optional implementation, the application phase includes a loading phase and a running phase. In the application phase of the resource collection package file, intercepting client resource requests, matching the corresponding resource collection package file based on the manifest file, and loading and parsing it includes:
[0103] During the loading phase, a preloading instruction corresponding to the target collection package file is injected into the page document template, and the preloading instruction is associated with the route or entry point indicated by the page document template.
[0104] During the operation phase, browser events are monitored, the Uniform Resource Locator (URL) of the resource request is parsed, the target resource is determined, the manifest file is queried, the corresponding resource collection package file is matched for the target resource, the matching file is loaded and the target resource is extracted, the original independent resource request process is terminated, and if it fails to match the corresponding resource collection package file for the target resource, an independent resource request is initiated according to the original resource request path.
[0105] This implementation injects a preloading instruction for the target collection package into the page template during the loading phase and preloads critical resources based on routing association instructions. During the runtime phase, it listens for browser events, parses the request URL, queries the manifest file to match the collection package, directly extracts the target resources, and terminates the original independent request, only degrading to an independent request when a match fails. This two-stage mechanism ensures timely delivery of resources for the first screen through preloading and reduces the number of network connections by intercepting and dynamically merging requests at runtime, thereby improving resource loading efficiency and system response speed.
[0106] As an optional implementation, during the loading phase, the method further includes:
[0107] The resource collection package file is split into route-specific sub-packages;
[0108] Declare the mapping relationship between the route path and the route-specific sub-packet in the manifest file;
[0109] Based on the resource attributes corresponding to each atomic resource in the resource collection package file and the user requirement information of the application stage, the loading order of sub-packages is dynamically adjusted.
[0110] This implementation splits the collection package into route-specific sub-packages, declaring the mapping relationship between route paths and sub-packages in the manifest file, thus achieving precise resource allocation by route. The loading order of sub-packages is dynamically adjusted based on resource attributes and user needs, ensuring that resources required for the current route are loaded first. This avoids the waste of full loading, improves the targeting of resource delivery, and further optimizes runtime performance and bandwidth utilization.
[0111] In practical application scenarios, the various implementation methods provided in this application can be combined and operated. The following details the implementation of this application in specific application scenarios.
[0112] Atomized resource analysis and dependency graph construction (construction phase):
[0113] Resource Scanner and Metadata Extractor:
[0114] It iterates through the project's source code and dependencies, identifying all atomic CSS classes, JS modules, icons, fonts, and other fine-grained resources.
[0115] Extract resource metadata, including resource type, size, dependencies, and whether it is dynamically imported.
[0116] Build a resource dependency graph to record the reference relationships and shared contexts (such as commonly used components and routes) between resources.
[0117] Mergeable resource group identifier:
[0118] Based on dependency graphs and usage frequency, the Louvain community discovery algorithm (not the invention point of this patent) identifies resource groups with high cohesion and low coupling.
[0119] Based on factors such as resource type, priority, and whether it is a critical resource (core function or a resource used to render LCP elements or respond to interactions), a merging priority is assigned to each resource group.
[0120] Atomized resource types & priorities:
[0121] High priority: Synchronize JavaScript and critical CSS (directly affecting the first screen rendering).
[0122] Medium priority: Asynchronous JavaScript, Web fonts.
[0123] Low priority: Images, icons, and non-critical CSS.
[0124] Output a resource grouping suggestion report, including a list of resources in each group, the estimated size after merging, and whether it is suitable to package into a .wbn file.
[0125] The criteria for determining whether a resource group is suitable for packaging as a .wbn file are:
[0126] The group contains a large number of fine-grained resources, and each resource is small in size (e.g., less than 2KB).
[0127] Resources within the same group are of the same type (e.g., all CSS or all JS) and have similar loading priorities.
[0128] Resources within a group are collections that are frequently co-occurring and used within the same route, component, or functional module.
[0129] Web Bundle Generation and Signing Mechanism (Build Phase):
[0130] Resource group packer:
[0131] Based on the group report, all CSS, JS, images, and other resources in each resource group are packaged into a single .wbn file.
[0132] It supports resource deduplication and compression, ensuring that the same resource is not packaged repeatedly in different groups.
[0133] Generate an integrity hash for each .wbn file.
[0134] Manifest file generator:
[0135] Generate a manifest.json file, which records information such as the resource list, hash value, dependencies, and version number contained in each .wbn file.
[0136] It provides an API for runtime queries to determine which resources reside in which .wbn file, supporting dynamic loading and cache updates.
[0137] Request merging and delivery strategies (build time and runtime):
[0138] Build-time request merging strategy:
[0139] Inject a preload directive into the HTML template to prioritize loading critical .wbn files.
[0140] Dynamically associate .wbn files based on routes or entry points to achieve on-demand loading.
[0141] Runtime request to merge adapter:
[0142] Intercept resource requests in the client-side routing and query manifest.json to determine if a .wbn file is found.
[0143] If a match is found, the corresponding .wbn file is loaded directly, and the required resources are extracted from it, avoiding the need to initiate multiple small requests.
[0144] Building integrated and visualized reports:
[0145] Provides Webpack / Vite plugins for integration into existing build processes.
[0146] Generate HTML visualization reports that display resource grouping, request merging effects, cache optimization suggestions, etc.
[0147] Developers can force grouping or exclude specific resources by using configuration files or annotation tags.
[0148] This application provides a method for dependency analysis and intelligent grouping of atomic resources, a multi-resource atomic delivery and request merging mechanism based on Web Bundle, an integration interface for build tools, and visual report output, achieving the following main effects:
[0149] Significantly reduce the number of HTTP requests: By aggregating atomic resources through .wbn files, the problem of a large number of small file requests is fundamentally solved.
[0150] Intelligent grouping improves efficiency: Dependency-based dynamic grouping ensures that frequently updated resources can be cached independently.
[0151] No manual configuration required: Fully automated resource analysis and grouping reduces the burden on developers.
[0152] Compatible with existing toolchains: Provides standard plugin interfaces and seamlessly integrates with mainstream build tools such as Webpack and Vite.
[0153] This application also provides an atomized multi-resource data transmission optimization device, comprising:
[0154] The acquisition module is used to scan atomic resources in the project source code to obtain resource metadata and resource dependencies.
[0155] The resource metadata includes extracted resource type data, resource volume data, and resource attribute data;
[0156] The processing module is used to construct a resource dependency graph based on the resource dependency relationships;
[0157] The processing module is further configured to divide each of the atomized resources into multiple resource groups by resource clustering based on the resource dependency graph and resource usage frequency;
[0158] The processing module is further configured to package the resources in each resource group into a resource collection package file, and generate a list file that records the resource metadata and resource mapping relationships;
[0159] The processing module is also used to intercept client resource requests during the application phase of the resource collection package file, match the corresponding resource collection package file based on the manifest file, and load and parse it.
[0160] This implementation method obtains the metadata and dependencies of atomic resources by scanning the project source code, constructs a resource dependency graph, and accurately depicts the logical relationships and hierarchical structure between resources. Based on this graph and the frequency of resource usage, it performs intelligent clustering and grouping, classifying frequently co-occurring and functionally coupled resources into the same resource group, effectively avoiding the subjectivity and redundancy problems of traditional merging schemes. By packaging resource groups into collection package files and generating manifest files, it achieves the aggregation and encapsulation of atomic resources, ensuring the integrity of resource delivery. During the application phase, it intercepts client requests and loads the corresponding collection package based on the manifest file, directly reducing the number of actual network requests and significantly reducing header overhead and head-of-line blocking risks. Thus, it not only solves the performance bottleneck caused by a large number of small file requests, but also ensures on-demand loading and caching efficiency of resources through a dynamic grouping mechanism, fundamentally improving the flexibility and execution efficiency of front-end resource transmission.
[0161] As an optional implementation, the specific method by which the processing module constructs a resource dependency graph based on the resource dependency relationship includes:
[0162] Extract resource type identifiers and mark the hierarchical path location information of resources in the component dependency tree;
[0163] Based on the component information and routing information in the resource dependency relationship, the reference relationship between resources is determined, and a resource dependency graph is constructed.
[0164] This implementation method accurately locates the topological relationships of resources within the project structure by extracting resource type identifiers and marking hierarchical path positions in the component dependency tree. It combines component information and routing information to determine the reference relationships between resources, constructing a multi-dimensional dependency graph. This graph not only reflects static dependencies but also divides dynamic loading units through routing boundaries, making subsequent resource grouping more aligned with actual usage scenarios. This improves the accuracy of dependency analysis, provides a data foundation for the intelligent partitioning of highly cohesive resource groups, avoids errors from manual configuration, and enhances the adaptability of optimization strategies.
[0165] As an optional implementation, the processing module is further configured to assign grouping priorities to each of the atomized resources;
[0166] The allocation method for the group priority includes:
[0167] Assign the highest priority to script resources that execute synchronously and style resources that affect the first screen rendering;
[0168] Assign second priority to asynchronously loaded script and font resources;
[0169] Assign the third priority to image resources and style resources required for non-first screen rendering.
[0170] This implementation allocates three levels of priority based on resource type and rendering criticality: the highest priority is given to synchronous scripts and critical styles for the first screen, ensuring fast loading of core page functions; medium priority is given to asynchronous scripts and fonts, balancing functional integrity and loading sequence; and low priority is given to images and non-critical styles, delaying the loading of non-core resources. This strategy, by differentiating resource importance levels, ensures that high-priority resources are packaged and preloaded first, thereby specifically optimizing the first screen rendering time, preventing low-priority resources from blocking critical requests, and improving user experience.
[0171] As an optional implementation, the specific method by which the processing module packages the resources within each resource group into a resource collection package file includes:
[0172] Determine the grouping conditions for each resource group and adjust the combination method of each resource group;
[0173] The grouping conditions include any one of the following:
[0174] The group is a high-aggregation resource group, which contains a preset number of the atomic resources. The resource type identifiers of the atomic resources in the group are consistent and the group priority belongs to the same level. The frequency of co-occurrence of the atomic resources in the same functional module exceeds a preset threshold.
[0175] In addition, a global resource index table is established across resource groups, and the entity content of duplicate resources is retained only in the highest priority group, and an integrity check value based on the file content is generated for each resource collection package file.
[0176] This implementation ensures that resources within a group are highly correlated and frequently co-occur, reducing invalid merging, by setting grouping conditions for resource groups (such as high aggregation degree, consistent resource type, same priority level, and co-occurrence frequency exceeding a threshold). It also establishes a cross-group global index table to retain entities of duplicate resources only in the highest priority group, eliminating redundant storage. Furthermore, it generates content-based integrity verification values for each collection packet to ensure transmission reliability. Thus, while maintaining the cohesion of resource groups, it significantly reduces packet size and optimizes cache utilization and loading efficiency.
[0177] As an optional implementation, the application phase includes a loading phase and a running phase. During the application phase of the resource collection package file, the processing module intercepts client resource requests and, based on the manifest file, matches and loads the corresponding resource collection package file in the following specific ways:
[0178] During the loading phase, a preloading instruction corresponding to the target collection package file is injected into the page document template, and the preloading instruction is associated with the route or entry point indicated by the page document template.
[0179] During the operation phase, browser events are monitored, the Uniform Resource Locator (URL) of the resource request is parsed, the target resource is determined, the manifest file is queried, the corresponding resource collection package file is matched for the target resource, the matching file is loaded and the target resource is extracted, the original independent resource request process is terminated, and if it fails to match the corresponding resource collection package file for the target resource, an independent resource request is initiated according to the original resource request path.
[0180] This implementation injects a preloading instruction for the target collection package into the page template during the loading phase and preloads critical resources based on routing association instructions. During the runtime phase, it listens for browser events, parses the request URL, queries the manifest file to match the collection package, directly extracts the target resources, and terminates the original independent request, only degrading to an independent request when a match fails. This two-stage mechanism ensures timely delivery of resources for the first screen through preloading and reduces the number of network connections by intercepting and dynamically merging requests at runtime, thereby improving resource loading efficiency and system response speed.
[0181] As an optional implementation, the processing module is further configured to, during the loading phase,
[0182] The resource collection package file is split into route-specific sub-packages;
[0183] Declare the mapping relationship between the route path and the route-specific sub-packet in the manifest file;
[0184] Based on the resource attributes corresponding to each atomic resource in the resource collection package file and the user requirement information of the application stage, the loading order of sub-packages is dynamically adjusted.
[0185] This implementation splits the collection package into route-specific sub-packages, declaring the mapping relationship between route paths and sub-packages in the manifest file, thus achieving precise resource allocation by route. The loading order of sub-packages is dynamically adjusted based on resource attributes and user needs, ensuring that resources required for the current route are loaded first. This avoids the waste of full loading, improves the targeting of resource delivery, and further optimizes runtime performance and bandwidth utilization.
[0186] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as program code in the device's memory, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.
[0187] Indicatively, such as Figure 2 As shown, Figure 2 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 2 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the methods of any of the embodiments described above.
[0188] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.
[0189] Those skilled in the art will understand that Figure 2 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0190] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method provided in any embodiment.
[0191] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0192] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.
[0193] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. An atomized multi-resource data transmission optimization method, characterized in that, include: Scan the atomic resources in the project source code to obtain resource metadata and resource dependencies; The resource metadata includes extracted resource type data, resource volume data, and resource attribute data; Based on the resource dependencies, construct a resource dependency graph; Based on the resource dependency map and resource usage frequency, each of the atomized resources is divided into multiple resource groups through resource clustering. The resources within each resource group are packaged into a resource collection package file, and a list file recording the resource metadata and resource mapping relationships is generated; During the application phase of the resource collection package file, client resource requests are intercepted, and the corresponding resource collection package file is matched and loaded and parsed based on the manifest file.
2. The method according to claim 1, characterized in that, The step of constructing a resource dependency graph based on the resource dependency relationships includes: Extract resource type identifiers and mark the hierarchical path location information of resources in the component dependency tree; Based on the component information and routing information in the resource dependency relationship, the reference relationship between resources is determined, and a resource dependency graph is constructed.
3. The method according to claim 1, characterized in that, The method also includes assigning grouping priorities to each of the atomized resources; The allocation method for the group priority includes: Assign the highest priority to script resources that execute synchronously and style resources that affect the first screen rendering; Assign second priority to asynchronously loaded script and font resources; Assign the third priority to image resources and style resources required for non-first screen rendering.
4. The method according to claim 3, characterized in that, The step of packaging the resources within each resource group into a resource collection package file includes: Determine the grouping conditions for each resource group and adjust the combination method of each resource group; The grouping conditions include any one of the following: The group is a high-aggregation resource group, which contains a preset number of the atomic resources. The resource type identifiers of the atomic resources in the group are consistent and the group priority belongs to the same level. The frequency of co-occurrence of the atomic resources in the same functional module exceeds a preset threshold. In addition, a global resource index table is established across resource groups, and the entity content of duplicate resources is retained only in the highest priority group, and an integrity check value based on the file content is generated for each resource collection package file.
5. The method according to any one of claims 1-4, characterized in that, The application phase includes a loading phase and a running phase. During the application phase of the resource collection package file, client resource requests are intercepted, and the corresponding resource collection package file is matched, loaded, and parsed based on the manifest file. This includes: During the loading phase, a preloading instruction corresponding to the target collection package file is injected into the page document template, and the preloading instruction is associated with the route or entry point indicated by the page document template. During the operation phase, browser events are monitored, the Uniform Resource Locator (URL) of the resource request is parsed, the target resource is determined, the manifest file is queried, the corresponding resource collection package file is matched for the target resource, the matching file is loaded and the target resource is extracted, the original independent resource request process is terminated, and if it fails to match the corresponding resource collection package file for the target resource, an independent resource request is initiated according to the original resource request path.
6. The method according to claim 5, characterized in that, During the loading phase, the method further includes: The resource collection package file is split into route-specific sub-packages; Declare the mapping relationship between the route path and the route-specific sub-packet in the manifest file; Based on the resource attributes corresponding to each atomic resource in the resource collection package file and the user requirement information of the application stage, the loading order of sub-packages is dynamically adjusted.
7. An atomized multi-resource data transmission optimization device, characterized in that, include: The acquisition module is used to scan atomic resources in the project source code to obtain resource metadata and resource dependencies. The resource metadata includes extracted resource type data, resource volume data, and resource attribute data; The processing module is used to construct a resource dependency graph based on the resource dependency relationships; The processing module is further configured to divide each of the atomized resources into multiple resource groups by resource clustering based on the resource dependency graph and resource usage frequency; The processing module is further configured to package the resources in each resource group into a resource collection package file, and generate a list file that records the resource metadata and resource mapping relationships; The processing module is also used to intercept client resource requests during the application phase of the resource collection package file, match the corresponding resource collection package file based on the manifest file, and load and parse it.
8. The method according to claim 7, characterized in that, The specific methods by which the processing module constructs a resource dependency graph based on the resource dependency relationships include: Extract resource type identifiers and mark the hierarchical path location information of resources in the component dependency tree; Based on the component information and routing information in the resource dependency relationship, the reference relationship between resources is determined, and a resource dependency graph is constructed.
9. A computer device, characterized in that, The method includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method as described in any one of claims 1-6.
10. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method as described in any one of claims 1-6.