Front-end resource preprocessing control method, device and storage medium

Abstract

The application discloses a front-end resource preprocessing control method and device and a storage medium, relates to the technical field of front-end resource processing, and comprises the following steps: in response to a network resource request, data blocks are obtained by dividing a response data stream according to a data block reading threshold; resource dependency relationships are obtained by incrementally analyzing the data blocks block by block; the comprehensive priorities of the data blocks are calculated in combination with resource types and loading time sequence requirements; the data blocks are pushed to corresponding scheduling queues; the system running state is judged and the scheduling queues are updated according to adjustment judgment rules, and a target queue is obtained; and the data blocks are subjected to resource conversion processing based on the target queue, target data is generated in combination with the resource dependency relationships, and the target data is pushed to a consumer end. Through the steps of dividing a response stream according to a data block reading threshold, incrementally analyzing data blocks block by block, dynamically scheduling priorities and converting resources in a streaming mode, the application solves the problem of poor resource processing efficiency, improves loading speed and resource utilization, and optimizes user experience.

Description

Technical Field

[0001] This application relates to the field of front-end resource processing technology, and in particular to a control method, device and storage medium for front-end resource preprocessing. Background Technology

[0002] In web page front-end resource processing and application loading scenarios, the ability to efficiently schedule and parallel process front-end resources is directly related to the user experience and core competitiveness of web applications.

[0003] In related technologies, the architecture of full download followed by serial processing is used to complete the entire front-end resource processing work by waiting for all kinds of front-end network resources to be fully downloaded to the local machine before starting subsequent operations such as parsing, conversion, injection and rendering. This approach is difficult to adapt to the high-load and complex application scenarios of large single-page applications and resource-intensive web systems, resulting in poor resource processing efficiency.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a control method, device, and storage medium for front-end resource preprocessing, aiming to solve the technical problem of poor resource processing efficiency.

[0006] To achieve the above objectives, this application proposes a control method for front-end resource preprocessing, the method comprising: In response to a network resource request, the response data stream corresponding to the network resource request is divided according to the data block reading threshold to obtain different types of data blocks; The data blocks of different types are parsed incrementally, and the resource dependencies corresponding to the data blocks are obtained. Based on the resource dependencies, resource types, and loading timing requirements of the data block, the overall priority of the data block is calculated, and the data block is pushed to the corresponding scheduling queue based on the differentiated scheduling strategy and the overall priority of the data block. The system operating status is determined according to the adjustment judgment rules, and the scheduling queue is updated according to the judgment result to obtain the target queue; Based on the target queue, the data block is processed for resource transformation. Combined with the resource dependencies of the data block, target data is generated and pushed to the consumer.

[0007] In one embodiment, based on the network resource request, the response data stream issued by the website corresponding to the network resource request is retrieved; The response data stream is segmented according to the data block reading threshold, and each segment of data is bound with identity tagging information to obtain the original data block. Based on the header feature code of the original data block, and combined with the content type field of the network resource request corresponding to the original data block, the resource category is determined to obtain a marked data block with resource type identifier; According to the type classification rules, the marked data blocks with resource type identifiers are grouped and processed to obtain data blocks of different types.

[0008] In one embodiment, a corresponding state machine-based incremental parser instance is matched based on the resource type identifier corresponding to the data block; The incremental parser instance performs block-by-block streaming lexical and syntactic analysis on the data block, caches the unclosed syntactic unit stack, and generates segmented document structure fragments corresponding to the data block. Traverse the segmented document structure fragments corresponding to the data block, organize the resource import statements and external resource reference information in the segmented document structure fragments, and obtain the preliminary resource dependency set corresponding to the data block; Based on the global resource dependency set matching and verification of the preliminary resource dependency set, the indirect dependency entries of the nested levels in the preliminary resource dependency set are supplemented to obtain the resource dependency relationship corresponding to the data block.

[0009] In one embodiment, the resource type and loading timing requirements corresponding to the data block are determined based on the resource type identifier of the data block; Based on the resource dependency relationship, resource type and loading timing requirements of the data block, the corresponding parameters are matched in the weight parameter library to obtain the resource dependency level coefficient, resource rendering contribution coefficient and loading timing urgency coefficient. The resource dependency level coefficient, the resource rendering contribution coefficient, and the loading sequence urgency coefficient are weighted according to the weighted calculation rules to obtain the comprehensive priority corresponding to the data block. Based on the overall priority corresponding to the data block, the data block is pushed to the scheduling queue of the corresponding level.

[0010] In one embodiment, the comprehensive score of the data block is obtained by multiplying the resource dependency level coefficient, the resource rendering contribution coefficient, and the loading timing urgency coefficient by the corresponding adjustment ratio and then summing them up. The overall score of the data block is compared and matched with a preset score range to determine the overall priority of the data block. The scheduling strategy for the data block is determined by matching a dedicated scheduling execution mode based on the comprehensive priority corresponding to the data block. The data block is pushed to the corresponding scheduling queue according to the scheduling strategy.

[0011] In one embodiment, the network downlink rate, processor utilization, and user interaction behavior data corresponding to the scheduling queue are collected, and a set of status parameters is obtained by associating timestamps. The set of state parameters is matched and verified one by one with the multi-level trigger thresholds, and the verification results are conditionally determined according to the adjustment judgment rules to obtain the judgment result and the corresponding adjustment range parameter. If the determination result is that no adjustment is triggered, then the current scheduling queue will be used as the target queue.

[0012] In one embodiment, the determination result is branched and divided into two execution paths: one that does not trigger adjustment and one that triggers adjustment. When the determination result is the trigger adjustment, the priority increase or decrease value corresponding to the data block is calculated block by block according to the adjustment range parameter; Update the overall priority of the data block according to the priority increase or decrease value corresponding to the data block; The data blocks are migrated across queues according to the updated comprehensive priority, and the corresponding level of scheduling execution rules are rebound for the data blocks migrated into the new queue to obtain the target queue.

[0013] In one embodiment, the corresponding incremental conversion rule set is matched based on the resource type identifier attached to the data block in the target queue; According to the incremental transformation rule set, the segmented document structure fragments within the data block are subjected to block-by-block syntax translation and code simplification to generate locally syntactically consistent segmented transformation fragments; The resource dependency relationship between the global resource dependency set and the data block is retrieved for matching and verification. The ready status of the dependent resources is confirmed, and the ready dependency content is injected into the corresponding syntax node position of the segmented transformation fragment to obtain the segmented target data block. The segmented target data blocks are checked for format compliance and semantic consistency. After the checks are passed, the data is pushed to the consumer in an orderly manner according to the timing requirements of the rendering execution on the consumer side.

[0014] In addition, to achieve the above objectives, this application also proposes a front-end resource preprocessing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method for front-end resource preprocessing as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the control method for front-end resource preprocessing as described above.

[0016] This application provides a control method for front-end resource preprocessing, including responding to network resource requests and dividing the response data stream corresponding to the network resource requests into different types of data blocks according to data block reading thresholds; performing incremental parsing on different types of data blocks to obtain the resource dependencies corresponding to each data block; calculating the comprehensive priority of data blocks based on the resource dependencies, resource types, and loading timing requirements of the data blocks; pushing the data blocks to the corresponding scheduling queues based on differentiated scheduling strategies; judging the system running status according to adjustment judgment rules and updating the scheduling queues to obtain the target queue based on the judgment results; and finally performing resource conversion processing on the data blocks based on the target queues and generating target data based on the resource dependencies of the data blocks to push to the consumer end. This streaming parallel pipeline processing architecture solves the technical problems caused by the traditional serial mode of full download and post-processing of front-end resources, such as high first-screen loading latency, low resource utilization caused by serial operation of network transmission and computing resources, and inability to support dynamic incremental processing and on-demand loading under streaming transmission. It improves the loading response speed of front-end resources, the overall resource utilization efficiency of the system, and the page interaction experience of end users.

[0017] In summary, this application solves the technical problem of poor resource processing efficiency by segmenting the response stream according to the data block reading threshold, incremental parsing block by block, dynamic priority scheduling, and streaming resource conversion, thereby improving loading speed and resource utilization and optimizing the end-user experience. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the control method for front-end resource preprocessing in this application; Figure 2 This is a flowchart of the data processing for this application; Figure 3This is a system architecture diagram for this application; Figure 4 This is a flowchart of the front-end resource preprocessing process for this application; Figure 5 This is a sequence diagram of the system processing in this application; Figure 6 This is a flowchart illustrating the fifth embodiment of the control method for front-end resource preprocessing in this application; Figure 7 This is a flowchart illustrating the seventh embodiment of the control method for front-end resource preprocessing in this application; Figure 8 This is a schematic diagram of the front-end resource preprocessing equipment in this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] In related technologies, the architecture of full download followed by serial processing is used to complete the entire front-end resource processing work by waiting for all kinds of front-end network resources to be fully downloaded to the local machine before starting subsequent operations such as parsing, conversion, injection and rendering. This approach is difficult to adapt to the high-load and complex application scenarios of large single-page applications and resource-intensive web systems, resulting in poor resource processing efficiency.

[0024] This application provides a solution as follows: First, in response to a network resource request, the response data stream corresponding to the network resource request is segmented according to a data block reading threshold to obtain different types of data blocks. Then, the different types of data blocks are parsed incrementally to obtain the resource dependencies corresponding to the data blocks. Next, based on the resource dependencies, resource types, and loading timing requirements of the data blocks, the comprehensive priority of the data blocks is calculated. Based on a differentiated scheduling strategy and the comprehensive priority of the data blocks, the data blocks are pushed to the corresponding scheduling queue. Then, the system operating status is determined according to the adjustment judgment rules, and the scheduling queue is updated according to the judgment result to obtain the target queue. Finally, the data blocks are processed for resource conversion based on the target queue. Combined with the resource dependencies of the data blocks, target data is generated and pushed to the consumer end.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or front-end resource preprocessing device capable of performing the above functions. The following description uses a front-end resource preprocessing device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] This application provides a control method for front-end resource preprocessing, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the control method for front-end resource preprocessing in this application.

[0028] In this embodiment, the control method for front-end resource preprocessing includes steps S10 to S50: Step S10: In response to the network resource request, the response data stream corresponding to the network resource request is divided according to the data block reading threshold to obtain different types of data blocks.

[0029] Network resource requests are the core request instructions that trigger the front-end resource preprocessing process, initiated by the terminal browser based on page rendering requirements. The response data stream is a continuous binary data sequence carrying the resource content, returned by the origin server in response to the resource request. The data block read threshold is a segmented capacity benchmark parameter used to divide the continuous data stream. Different types of data blocks are segmented data units that are categorized and labeled according to resource type, carrying unique identifiers. For example, resource types include script resources, style resources, document resources, and image resources.

[0030] In this embodiment, upon receiving a network resource request initiated by the terminal browser, a data transmission link is first established with the origin server to obtain read permission for the response data stream, and then the data stream segmentation and type identification process is initiated.

[0031] For example, there are two methods for segmenting and classifying response data streams. The first is a fixed threshold pre-segmentation and response header pre-classification mode. Before the data stream transmission starts, the content type field of the response message header is read to pre-determine the resource type. A fixed data block reading threshold is then retrieved for the corresponding resource type. During the data stream transmission, continuous binary data is segmented according to this threshold, and a unique identifier containing a resource identifier and block sequence number is bound to each segment of data. The data block is then classified directly based on the pre-determined type. This method has a simple and stable segmentation logic, extremely low classification time, and can complete processing synchronously with the data stream transmission, making it suitable for regular page loading scenarios with stable network conditions and standardized resource types.

[0032] The second approach is a dynamic adaptive threshold segmentation and feature code secondary verification classification mode. During data stream transmission, the first segment of data is extracted using a basic threshold. The header feature code of the first segment is extracted and compared with the response header information for preliminary type matching. Then, the reading threshold of the next segment of data is dynamically adjusted based on the initially matched resource type. For each segment of data, the header feature code is extracted and compared with a preset resource feature library for secondary verification. If the verification passes, the corresponding type identifier and unique identity tag are bound. If the verification fails, the type is re-identified and the segmentation threshold is corrected. This method can dynamically adapt the segmentation granularity according to the characteristics of the resource content, and ensure the accuracy of type identification through dual verification. It is suitable for heterogeneous resource loading scenarios with complex resource types and incomplete response header information.

[0033] In an exemplary scheme for performing data stream segmentation and classification, a streaming transmission link with the source station is first established, the response body is verified to support segmented reading, and data block sequence number counters and identity tag generation rules are initialized. Then, the first segment of data is read, and the first segment of binary data is truncated using a preset basic reading threshold. The content type field of the response message is extracted to complete the initial type determination. Next, feature code verification is performed, extracting the header feature bytes of the first segment of data and matching them with the standard feature library of the corresponding type. If the matching degree reaches a preset threshold, the resource type is confirmed; otherwise, the feature libraries of all resource types are traversed for re-identification. Then, threshold dynamic adjustment is performed, retrieving the corresponding optimal segmentation threshold based on the confirmed resource type as the reading benchmark for subsequent data segments. Next, segmented segmentation and tagging are performed, truncating the remaining data stream segment by segment according to the adjusted threshold. After each segment is truncated, a unique identity tag containing a unique resource identifier, block sequence number, and type identifier is generated and bound to the corresponding data segment. Finally, classification and aggregation are performed, classifying all data blocks into the corresponding type's parsing set according to the type identifier carried by the data blocks, resulting in different types of data blocks for subsequent incremental parsing processing.

[0034] Step S20: Incrementally parse the data blocks of different types one by one to obtain the resource dependencies corresponding to the data blocks.

[0035] Block-by-block incremental parsing is a processing mode that performs syntax and semantic parsing on segmented data blocks, relying on a context continuation mechanism. Parsing can begin without waiting for all resources to load completely. Resource dependencies describe the set of relationships between external resources and internal modules that the current data block depends on. Examples include script import dependencies, style reference dependencies, resource path dependencies, and module call dependencies.

[0036] In this embodiment, after the data blocks are classified and collected, the corresponding parsing logic is matched for different types of data blocks, and the incremental parsing process is started to extract resource dependencies in a synchronous manner.

[0037] For example, there are two implementation methods for block-by-block incremental parsing and dependency extraction. The first is state machine stack-resident incremental parsing. For each type of resource, a corresponding syntax state machine is initialized. When parsing the first data block, an initial syntax state stack is generated and resided in memory. When parsing subsequent data blocks, the resident state stack is directly read as the context starting point, and the syntax parsing of the current data block is completed, generating the corresponding segmented syntax structure fragments. Simultaneously, resource reference nodes in the fragments are traversed to extract dependency information. The state stack is updated and cached after each data block is parsed. This method features context-resident reuse, strong parsing continuity, extremely low single-block parsing time, and can be processed synchronously with the arrival rhythm of data blocks, making it suitable for low-latency parsing scenarios under streaming transmission.

[0038] The second method is segmented context snapshot-based incremental parsing. After parsing each data block, a complete context snapshot file is generated, recording all currently unclosed syntax nodes, parsed structures, and extracted dependency information, and persistently cached. Before parsing the next data block, the context snapshot corresponding to the previous data block is loaded, the parsing state is restored, and then parsing of the current data block is started, generating the syntax structure fragment and dependency set for the current segment. After completion, a new context snapshot is generated, overwriting the old snapshot. This method allows for context state backtracking and migration, is not limited by memory residency, supports interrupted parsing task recovery and cross-node distributed parsing, and is suitable for complex parsing scenarios involving large resources and multi-node collaborative processing.

[0039] In an exemplary scheme for incremental parsing and dependency extraction, the parsing rule base corresponding to each resource type is first loaded, and an independent parsing process is initialized for each type of resource. Then, context initialization is performed, reading the first data block of the same resource type, starting the corresponding parser, and generating an initial grammar state and context baseline. Next, block-by-block parsing is performed, sequentially reading subsequent data blocks of the same type according to their data block numbers. Starting from the parsing context retained from the previous data block, lexical and syntactic analysis of the current data block is completed, generating segmented grammar structure fragments, and the parsing context state is updated synchronously. Next, dependency node identification is performed, traversing all external reference nodes and import declaration nodes generated in the segmented grammar structure fragments, extracting the corresponding resource identifiers, reference paths, and dependency levels to form a preliminary dependency set for the current data block. Then, dependency deduplication and validation are performed, comparing the preliminary dependency set with the extracted global dependency list, removing duplicate dependencies, and supplementing the dependency hierarchy and loading priority markers. Finally, the validated resource dependencies are associated and bound with the identity markers and segmented grammar structure fragments of the corresponding data blocks, outputting the resource dependencies corresponding to each data block for subsequent priority calculation and scheduling processing.

[0040] Step S30: Calculate the overall priority of the data block based on the resource dependency, resource type, and loading timing requirements corresponding to the data block, and push the data block to the corresponding scheduling queue based on the differentiated scheduling strategy and the overall priority of the data block.

[0041] Overall priority is a quantitative score that measures the order in which data blocks are processed and pushed, calculated by weighting multiple influencing factors. Differentiated scheduling strategies are specific scheduling execution rules set for different priority levels. Scheduling queues are ordered queues divided by priority level, used to temporarily store data blocks awaiting processing. For example, priority levels include highest priority, high priority, medium priority, and low priority.

[0042] In this embodiment, after obtaining the resource dependencies of each data block, the comprehensive priority calculation and queuing scheduling process is initiated based on the resource type and loading timing requirements of the data block itself.

[0043] For example, the implementation of comprehensive priority calculation and queuing scheduling includes two methods. The first is a static weighted calculation and fixed hierarchical queuing mode. Fixed weight parameters are pre-configured for three dimensions: resource dependency level, resource type, and loading sequence. For each data block, quantified scores for each of the three dimensions are extracted, multiplied by the corresponding weights, and then summed to obtain a comprehensive priority score. This score is compared with a preset four-level fixed score range to determine the priority level, and then pushed to the corresponding level's scheduling queue, simultaneously binding the queue to the preset scheduling strategy. This method features simple and stable calculation logic, unified hierarchical rules, and extremely short scheduling time, making it suitable for conventional page resource scheduling scenarios with fixed resource structures and clear timing requirements.

[0044] The second approach is a multi-dimensional dynamic weighting and adaptive hierarchical queuing mode. First, based on the current page rendering stage and resource loading progress, the weight ratios of three dimensions—resource dependency level, resource type, and loading sequence—are dynamically adjusted. Then, quantified parameters for each data block are extracted for the corresponding dimension, and a comprehensive priority score is calculated based on the dynamic weights. Simultaneously, the threshold boundaries of the hierarchical intervals are adaptively adjusted according to the current queue backlog. After priority level determination, the data block is pushed to the corresponding scheduling queue, and the queue's scheduling parameters are updated synchronously. This method can dynamically adjust the priority strategy according to the page loading stage, adapting to different needs throughout the entire page rendering lifecycle. It can flexibly handle abnormal situations such as queue congestion and is suitable for rich page scheduling scenarios with complex interactions and numerous dynamic resources.

[0045] In an exemplary scheme for priority calculation and queuing scheduling, the priority dimension configuration library and scheduling queue configuration set are first loaded, and four levels of scheduling queues and corresponding scheduling strategies are initialized. Then, dimension parameter extraction is performed. For each data block, dependency level parameters are extracted from resource dependencies, rendering contribution parameters are extracted from data block type identifiers, and urgency parameters are extracted from resource loading sequence requirements. Next, weight configuration determination is performed. Based on the current page rendering stage, the corresponding dimension weight configuration is retrieved, and corresponding weight coefficients are assigned to dependency level, rendering contribution, and urgency. Then, comprehensive score calculation is performed. The quantified parameters of the three dimensions are multiplied by their corresponding weight coefficients and summed to obtain the comprehensive priority score for each data block. Next, priority level determination is performed. The comprehensive priority score is compared with the preset four-level score range one by one to determine the priority level corresponding to the data block. Finally, queue push and strategy binding are performed. Data blocks are pushed to the corresponding level of scheduling queue in sequence, and the dedicated scheduling execution strategy corresponding to the queue is bound to the data block. Simultaneously, the queue length statistics and pending processing markers are updated. Finally, all data blocks are enqueued, forming a hierarchical scheduling queue system for subsequent dynamic adjustment and transformation processing.

[0046] Step S40: Determine the system operating status according to the adjustment judgment rules, update the scheduling queue based on the judgment result, and obtain the target queue.

[0047] The adjustment judgment rules are a set of triggering conditions and judgment logic used to determine whether the scheduling queue needs to be adjusted. System operating status is a set of real-time operating indicators describing the network, computing power, and interaction status of terminal devices. The target queue is the final scheduling queue that has been dynamically adjusted and optimized and can be directly used for subsequent conversion processing. For example, system operating status includes network downlink speed, processor utilization, and user interaction behavior.

[0048] In this embodiment, after the data block is enqueued, the system operation status is continuously monitored, and adjustment judgments are performed according to preset rules to dynamically optimize the scheduling queue.

[0049] For example, there are two ways to implement dynamic queue adjustment. The first is threshold-triggered periodic adjustment. System operating status parameters are collected at fixed time intervals, and each parameter is compared with a preset multi-level trigger threshold. When any parameter reaches the corresponding trigger threshold, the queue adjustment process is initiated. A priority adjustment coefficient is calculated based on the parameter offset, and the priority of data blocks within each queue is uniformly corrected. After cross-queue migration, the target queue is generated. If the trigger threshold is not reached, the original queue state remains unchanged. This method offers a stable adjustment rhythm, controllable system overhead, and the ability to periodically adapt to changes in system status and to suit typical operating scenarios with stable system load fluctuations.

[0050] The second approach is event-driven real-time adjustment. It continuously monitors for changes in system operating status. When critical events such as sudden changes in network speed, sudden increases in processor load, or user interaction are detected, a queue adjustment decision is triggered. Based on the impact level and scope of the event, the affected data blocks are precisely located, and the priority levels of the corresponding data blocks are adjusted accordingly. The queue is then migrated, and the target queue is generated immediately after the adjustment. This method offers fast response times, precisely adjusting only the affected data blocks without requiring a full queue traversal, making it suitable for highly dynamic operating scenarios with drastic system state fluctuations and frequent user interactions.

[0051] In an exemplary scheme for dynamic queue adjustment, a system status monitoring process is first initiated to continuously collect three types of status data: network downlink rate, processor utilization, and user interaction behavior. Simultaneously, an adjustment judgment rule base and multi-level trigger threshold configurations are loaded. Next, periodic status sampling is performed, extracting the current system status parameter set at preset time intervals. After standardization, these parameters are input into the adjustment judgment module. Then, threshold matching is performed, comparing the standardized status parameters with each level of trigger threshold to determine if queue adjustment is triggered. If not, the original scheduling queue state is maintained, and the original queue is directly used as the target queue. If adjustment is triggered, the adjustment magnitude parameter is calculated, and the priority increase / decrease coefficient is determined based on the proportion of the parameter exceeding the threshold. Subsequently, data block priority updates are performed, traversing the data blocks in each scheduling queue, recalculating the comprehensive priority score based on the adjustment magnitude coefficient, and updating the corresponding priority level. Finally, cross-queue migration is performed, migrating data blocks with changed priority levels to the corresponding new-level scheduling queues, synchronously rebinding the corresponding scheduling policies, and verifying the sequential consistency of data blocks in each queue. Finally, the adjustment results are verified to confirm that all data block queues belong to the correct entities and that the scheduling policies match correctly. The final target scheduling queue is then generated for subsequent resource conversion processing.

[0052] Step S50: Based on the target queue, perform resource conversion processing on the data block, and combine the resource dependencies of the data block to generate target data and push it to the consumer end.

[0053] Resource transformation processing involves converting and optimizing the syntax and format of data blocks to adapt them to the requirements of the end consumer. Target data is a standardized data unit that, after transformation and dependency injection, can be directly loaded and executed by the consumer. The consumer is the terminal rendering and execution environment that receives, loads, and executes resource data. Examples include script engines, rendering engines, and style parsers.

[0054] In this embodiment, after the target scheduling queue is generated, data blocks are retrieved sequentially according to the queue scheduling rules, the resource conversion and dependency injection process is started, and then pushed to the consumer.

[0055] For example, resource conversion and push can be implemented in two ways. The first is a block-by-block in-situ conversion and dependency injection mode. Data blocks are retrieved one by one according to the scheduling order of the target queue. In-situ syntax conversion and code optimization are performed based on the segmented syntax structure fragments of the data blocks to generate segmented conversion results. At the same time, according to the resource dependencies bound to the data blocks, the ready-to-use dependency content is precisely injected into the corresponding syntax node positions of the segmented conversion results. After generating segmented target data, it is immediately pushed to the consumer. This method has a short single-block processing link, low output latency, and can complete processing synchronously with the scheduling rhythm, making it suitable for streaming incremental consumption scenarios with low latency requirements.

[0056] The second approach involves segmented context-linked transformation and dependency preloading injection. Each time, multiple consecutive data blocks are retrieved. First, the syntax contexts of these blocks are concatenated to form a complete local syntax tree. Then, based on this local syntax tree, a globally optimized transformation process is performed, generating a coherent segmented transformation result. Simultaneously, the next batch of dependent resources is preloaded according to dependencies. During the transformation process, dependency content is integrated and injected, forming consecutive target data segments that are then pushed sequentially to the consumer. This method enables cross-block global optimization, resulting in higher transformation quality and more advanced dependency loading. It reduces waiting time on the consumer side and is suitable for complex resource processing scenarios with higher requirements for resource execution efficiency.

[0057] In an exemplary scheme for performing resource conversion and push, the conversion rule library corresponding to each resource type is first loaded, and the scheduling execution entry point of the target queue is initialized. Then, data blocks are dequeued in order, and according to the scheduling strategy corresponding to the target queue, data blocks to be processed are retrieved sequentially, and the conversion rule set corresponding to the resource type is called. Next, block-by-block conversion processing is performed. Based on the segmented syntax structure fragments carried by the data blocks, syntax transpilation, code simplification, and format standardization are performed to generate locally syntactically self-consistent segmented conversion fragments, and the validity of syntax connection between adjacent data blocks is simultaneously verified. Then, dependency matching and injection are performed. The global dependency ready ledger is called, the resource dependency relationship of the current data block is matched, and after confirming that all dependent resources are ready, the dependency content is accurately injected into the corresponding syntax node position of the segmented conversion fragment, generating segmented target data. Finally, compliance verification is performed. Format verification, semantic consistency verification, and integrity verification are performed on the segmented target data. If the verification fails, a single-block reprocessing process is triggered. Finally, the verified segmented target data is pushed to the browser consumer in an orderly manner according to the rendering execution sequence requirements of the consumer, and the processing status and push results of the data blocks are recorded synchronously for subsequent fault tolerance backtracking and performance statistics.

[0058] Further, please refer to Figure 2 , Figure 2This is a flowchart of the data processing in this application. The front-end resource streaming preprocessing solution based on the web streaming application programming interface (API) addresses the core shortcomings of existing front-end resource processing technologies by breaking the serial timing model of full download and post-processing. It constructs a streaming processing architecture that enables real-time block-by-block parsing, transformation, and dependency injection of incompletely downloaded resources. Leveraging the streaming data processing capabilities of the web streaming API, the front-end resource processing flow is reconstructed into a multi-stage parallel pipeline. Through the collaborative work of four core modules—stream acquisition and distribution, real-time parsing, dynamic transformation, and dependency management and injection—incremental processing of network resources can be completed during transmission. Processed valid data blocks can be directly pushed to the consumer for immediate consumption, thus completely eliminating the latency bottleneck caused by full download. Simultaneously, flexible configurable design adapts to the processing needs of different types of resources, improving the system's scalability and compatibility, ultimately achieving a synergistic improvement in front-end loading performance, user experience, and development efficiency. During the specific scheduling process, when a data block carrying resource content arrives, a resource feature extraction operation is first performed. Then, the data block's overall priority is calculated by multiplying the loading timing requirements, resource dependencies, and system running status by their corresponding weight coefficients and summing the results. The priority level is then determined: data blocks with a score of 9 or higher are placed in the highest priority queue and scheduled using a preemptive strategy; data blocks with a score between 7 and 8 are placed in the high priority queue and scheduled using a 100-millisecond time-slice round-robin strategy; data blocks with a score between 4 and 6 are placed in the medium priority queue and scheduled using a 50-millisecond time-slice round-robin strategy; and data blocks with a score below 4 are placed in the low priority queue and scheduled using an idle-triggered strategy. During scheduling, the system status monitoring module collects three types of operational data in real time: network speed, CPU utilization, and user interaction behavior, and performs adjustment trigger judgments. If adjustment is required, the data blocks in the low priority queue are downgraded or upgraded in priority. If no adjustment is required, the scheduling status is directly recorded. Finally, the data blocks that have completed scheduling are pushed to the consumer end corresponding to the browser rendering engine or script virtual machine.

[0059] Second Embodiment This embodiment provides an exemplary scheme for response data stream segmentation and resource type determination. In this example, the response data stream issued by the corresponding origin station is first retrieved based on the network resource request. The original data blocks are obtained by segmenting them according to the data block reading threshold and binding them with identity tags. Then, the resource category is determined by combining the header feature code and the content type field. Finally, different types of data blocks are obtained by grouping them by type. Step S10 includes steps A11 to A14: Step A11: Based on the network resource request, retrieve the response data stream issued by the website corresponding to the network resource request.

[0060] Step A12: Segment the response data stream according to the data block reading threshold, and bind identity tag information to each segment of data to obtain the original data block.

[0061] Step A13: Based on the header feature code of the original data block, and combined with the content type field of the network resource request corresponding to the original data block, the resource category is determined to obtain a marked data block with a resource type identifier.

[0062] Step A14: According to the type classification rules, group the marked data blocks with resource type identifiers to obtain data blocks of different types.

[0063] The raw data block is an independent data unit truncated according to a threshold and bound with a unique identifier; it is the basic processing object for type determination. The header signature is a fixed sequence of characteristic bytes contained at the beginning of the data block, identifying the resource format and type; it is the core basis for resource category identification. The content type field is a standard identifier field carried in the response header, used to declare the category to which the resource belongs. The tagged data block with resource type identifier is a data unit that has completed category determination and has been marked with a type attribute tag. For example, resource categories include script resources, style resources, document resources, and image resources.

[0064] In this example, when retrieving the response data stream based on network resource requests, a persistent connection and streaming approach can be used. First, a sustainable network link is established with the origin server. After verifying that the response body supports segmented streaming access, the binary data sent by the origin server is continuously received, thus completing the retrieval of the response data stream. Alternatively, a segmented retrieval approach with breakpoint resumption can be used. Data segments with specified offsets are requested from the origin server in batches, and then accumulated and pieced together to form a complete response data stream, thus adapting to data stream acquisition in weak network environments.

[0065] After retrieving the response data stream, the data block truncation and marking process is initiated. The continuous response data stream is truncated segment by segment according to a preset data block reading threshold. For each segment, an identity marker containing a unique resource identifier, block sequence number, and reception timestamp is generated and bound, resulting in the original data block. Then, for each original data block, a fixed-length feature code is extracted from its header. This feature code is then compared and determined against the content type field in the corresponding network resource request response header. Once the resource category of the data block is confirmed, a corresponding resource type identifier is appended, resulting in a marked data block with the resource type identifier. Finally, according to preset type classification rules, all marked data blocks are grouped and aggregated by resource category, maintaining the original transmission sequence of data blocks within each group. This results in different types of data blocks. Through double-checked type determination and ordered grouping, the type compatibility and processing order accuracy of subsequent incremental parsing are ensured.

[0066] For example, there are two ways to complete the resource category determination and grouping to obtain different types of data blocks. The first is the response header pre-classification and feature code serial verification mode. First, the content type field of the response message is read to complete the preliminary determination of the resource type. According to the preliminary determination of the type, the corresponding data block reading threshold is retrieved to perform segmented truncation and identity marking. After generating the original data blocks, the header feature code of each original data block is extracted sequentially and compared serially with the standard feature library of the pre-determined type. If the verification matches, the type is confirmed and an identifier is added. If the verification does not match, the entire type feature library is re-traversed to complete the re-identification. Finally, the data blocks of different types are grouped and collected according to the confirmed type. This method adopts the serial processing logic of pre-classification followed by block-by-block verification. By narrowing the feature matching range through the pre-judgment of the response header, the computational overhead of full feature traversal is reduced. The processing rhythm is highly adapted to the data stream transmission speed and is suitable for regular page loading scenarios with stable network conditions and standardized resource types.

[0067] The second method employs a parallel feature code matching and dynamic threshold adaptive mode. First, a basic threshold is used to extract the initial raw data block. Simultaneously, the standard feature library for all resource categories is invoked to perform parallel matching with the header feature code of the initial data block, quickly identifying the resource category with the highest matching degree. The reading threshold for subsequent data blocks is dynamically adjusted based on the processing characteristics of this category. During the extraction of subsequent data blocks, parallel feature code verification and type confirmation are performed concurrently. After all data blocks have had their type identifiers appended, they are grouped and aggregated in parallel according to category, resulting in data blocks of different types. This method uses parallel feature matching and dynamic threshold adaptive processing logic. It improves the speed of data type identification through parallel comparison across the entire library, without relying on pre-classification information in the response header. Furthermore, it can dynamically optimize the segmentation granularity based on resource type, adapting to complex resource loading scenarios with missing response header information and heterogeneous resource types.

[0068] Further, please refer to Figure 3 , Figure 3This is a system architecture diagram for this application. A layered architecture front-end resource streaming preprocessing system is proposed. The system as a whole consists of a front-end client, a data layer, an infrastructure layer, and a cluster of peripheral support services. The front-end client incorporates five business processing units: browser, stream acquisition and distribution, real-time parsing, dynamic conversion, and consumer. It also includes four management units: fault tolerance mechanism, priority scheduling, configuration adaptation, and dependency management and injection. After the browser initiates a network resource request, the stream acquisition and distribution unit acquires and distributes the response data stream in chunks. The real-time parsing unit performs incremental parsing block by block, the dynamic conversion unit optimizes resource format conversion, and the dependency management and injection unit matches and injects dependent resources. The fault tolerance mechanism provides exception handling and retry guarantees throughout the process. After processing, the data blocks undergo hierarchical scheduling by the priority scheduling unit and matching of corresponding processing rules by the configuration adaptation unit before finally being pushed to the consumer for incremental loading and execution. The system connects to external authentication and authorization services, monitoring and logging services, and configuration management services via Remote Procedure Call (RPC) to achieve identity authentication, operation log reporting, and processing rule distribution. The configuration management service connects to a caching service via a message queue to achieve high-speed reading, writing, and synchronous updates of configuration data. Cross-node data interaction is achieved between services through Hypertext Transfer Protocol (HTTP) and Secure Hypertext Transfer Protocol (STP). The data layer deploys a master database, slave databases, a NoSQL database, file storage, and data backup units. The master and slave databases handle the separation of reading and writing of structured configuration and business data. The NoSQL database supports high-speed access to unstructured state data. File storage is used for persistent storage of raw resources and processing products. The data backup unit enables disaster recovery archiving of all data, providing data storage and reliability support for the entire system process. The underlying infrastructure layer consists of server clusters, network devices, security protection, monitoring and alarm systems, and operation and maintenance management units. It undertakes the deployment and operation and maintenance of the entire system, providing computing power, network, security, monitoring, and operation and maintenance guarantees for upper-layer services, jointly supporting the stable and efficient operation of the "transmit, process, and consume simultaneously" streaming architecture.

[0069] Third Embodiment This embodiment provides an exemplary scheme for incremental parsing and resource dependency extraction. In this example, the corresponding state machine-based incremental parser instance is first matched according to the resource type identifier of the data block. Then, the parser performs block-by-block streaming lexical and syntactic analysis on the data block and caches the unclosed syntactic unit stack to generate segmented document structure fragments. Subsequently, the fragments are traversed to extract resource import statements and external references to obtain a preliminary resource dependency set. Finally, nested indirect dependency entries are checked and supplemented based on the global resource dependency set to obtain the complete resource dependency relationship corresponding to the data block. Step S20 includes steps B11 to B14: Step B11: Match the corresponding state machine-based incremental parser instance based on the resource type identifier corresponding to the data block.

[0070] Step B12: Perform block-by-block streaming lexical and syntactic analysis on the data block using the incremental parser instance, cache the unclosed syntactic unit stack, and generate segmented document structure fragments corresponding to the data block.

[0071] Step B13: Traverse the segmented document structure fragments corresponding to the data block, organize the resource import statements and external resource reference information in the segmented document structure fragments, and obtain the preliminary resource dependency set corresponding to the data block.

[0072] Step B14: Based on the global resource dependency set, verify the preliminary resource dependency set, supplement the indirect dependency entries of the nested levels in the preliminary resource dependency set, and obtain the resource dependency relationship corresponding to the data block.

[0073] An incremental parser instance is a state machine parsing unit built for a specific resource type, supporting breakpoint-based resuming of parsing. It is the core executor for performing block-by-block streaming syntax parsing. An unclosed syntax unit stack is a stack-based storage structure used to cache syntax nodes that have not been fully parsed across data blocks, and is the core carrier ensuring the syntactic continuity of multi-block parsing. A segmented document structure fragment is a local syntax structure unit generated after parsing a single data block, carrying the complete syntactic and semantic information of the current data block. A resource import statement is a standard syntax statement in the resource content declaring external resource import relationships. The preliminary resource dependency set is a collection of all explicit dependencies directly extracted from a single-block segmented document structure fragment. The global resource dependency set is a complete dependency ledger covering all resources and containing all explicit and nested implicit dependencies.

[0074] In this example, when matching an incremental parser instance based on the resource type identifier corresponding to a data block, a static type mapping matching method can be used. This involves pre-establishing a mapping relationship between resource types and parser instances, and directly indexing and retrieving the corresponding parser instance after reading the resource type identifier carried by the data block, thus achieving fast parser matching. Alternatively, a dynamic rule-based adaptation matching method can be used. This involves reading the header syntax features and type identifier of the data block, combining them with a pre-defined parser adaptation rule base to perform dynamic matching, and automatically selecting the incremental parser instance that best matches the syntax rules, thereby adapting to the parsing requirements of custom type resources.

[0075] After matching the incremental parser instance, a block-by-block streaming parsing process is initiated. The incremental parser instance sequentially performs lexical and syntactic analysis on the data block, simultaneously storing unclosed syntactic nodes into an unclosed syntactic unit stack to ensure cross-block parsing continuity, generating corresponding data block segmented document structure fragments. These fragmented document structures are then traversed, identifying and organizing all resource import statements and external resource references, forming a preliminary resource dependency set for the data block. Finally, the global resource dependency set is retrieved to match and verify the preliminary resource dependency set, supplementing nested indirect dependency entries layer by layer. After deduplication and merging, the complete resource dependency relationship for the data block is obtained. Through continuous incremental parsing and hierarchical dependency completion, accurate dependency extraction is achieved without loading all resources, ensuring the accuracy of dependencies in subsequent scheduling and transformation stages.

[0076] For example, there are two ways to implement block-by-block incremental parsing and resource dependency extraction. The first is a state machine stack-resident serial continuation parsing mode. A singleton incremental parser instance is initialized for the same resource type. When parsing the first data block, an initial unclosed syntax unit stack is generated and resides in memory. Subsequent data blocks enter the parser sequentially according to the transmission order. Lexical and syntactic analysis is completed from the syntax stack of the previous data block as the context starting point. The syntax stack is updated, and segmented document structure fragments of the current segment are generated. After extracting explicit references segment by segment to obtain a preliminary resource dependency set, it is compared with the global resource dependency set to supplement nested indirect dependencies, ultimately obtaining the resource dependency relationship corresponding to the data block. This method uses a single-instance stack-resident serial continuation parsing logic, which has strong syntactic context continuity, extremely low parsing state loss, and a processing rhythm that is highly matched with the arrival time of data blocks. It is suitable for low-latency conventional parsing scenarios under streaming transmission.

[0077] The second approach is a multi-instance snapshot-based parallel parsing mode. This mode initializes independent incremental parser instances for multiple data blocks of the same type. Each parser preloads a context snapshot of the corresponding data block to restore the parsing context. Simultaneously, multiple instances are launched in parallel to perform lexical and syntactic analysis. Each instance independently caches its own unclosed syntactic unit stack and generates segmented document structure fragments. After extracting the preliminary resource dependency sets of each fragment in parallel, a global dependency ledger is used to uniformly complete and verify nested indirect dependencies, merging them to obtain the resource dependencies corresponding to all data blocks. This method employs multi-instance parallel processing and context snapshot restoration, which can fully utilize computing resources to improve parsing throughput. The context snapshot can be persistently stored to support recovery from parsing task interruptions, making it suitable for batch parsing scenarios with large resource volumes and high concurrency.

[0078] Further, please refer to Figure 4 , Figure 4This is a flowchart of the front-end resource preprocessing process for this application. The front-end resource streaming preprocessing process, based on the webpage streaming interface, covers three execution paths: normal flow, exception handling, and priority scheduling. It adapts to both development and production environments. In development environments, it can be integrated via a build tool plugin, while in production environments, it can be deployed at the edge nodes or gateways of the content delivery network. The process is initiated by a network request from the browser. Upon receiving a Hypertext Transfer Protocol (HTTP) response carrying a content type identifier header, streaming processing can begin without waiting for the complete response. First, a readable stream object is created, and binary text data blocks of several kilobytes each are read and passed to the processing pipeline in a non-blocking asynchronous manner, avoiding the waste of CPU computing power and network input / output bandwidth. Then, the data blocks enter the type recognition logic to determine the resource type. This logic first performs a preliminary determination based on the content type field in the response header, and then performs a secondary verification based on the content characteristics of the data blocks to ensure accurate resource type judgment. After the determination is completed, it enters one of three parallel parsing branches according to the resource type. The first branch, for Hypertext Markup Language (HTML) resources, performs incremental Document Object Model (DOM) parsing, quickly constructing DOM fragments block by block and extracting external resource references. The second category targets script resources, sequentially performing streaming lexical analysis and streaming syntax analysis to gradually construct abstract syntax tree fragments and identify import statements and function definitions. The third category targets cascading style sheet resources, performing block-by-block parsing to extract import rules and font references. The dependency information obtained from these three branches is synchronized to the dependency management module in real time, jointly maintaining a global real-time dependency graph. Simultaneously, the parsed data blocks are passed downstream, loaded with configurable preset transformation rules, and then processed comprehensively through a multi-path transformation stream. Processing capabilities include backward compatibility translation of high-level syntax, style preprocessor compilation, code compression and obfuscation, remote module replacement, and on-demand injection of compatibility patches. Custom transformation logic is also supported, enabling pre-processing based on partial content. During processing, the real-time dependency graph is used to determine whether dependency resources need to be pre-loaded, triggering concurrent requests to obtain the corresponding dependency resources in advance. A context-aware dynamic injection mechanism is used to convert script import declarations to direct references and external cascading style sheets to Hypertext Markup Language inline styles, ensuring the semantic correctness after injection. The process synchronously sets up exception handling paths. When an error or corruption is detected in a data block, the abnormal data block is flown back to the discard module and the corresponding data segment is re-requested. Format verification and defect checking are performed on all data blocks simultaneously. Furthermore, a priority scheduling mechanism is implemented to ensure that critical resources pass through the processing pipeline first. Finally, the processed data block is output through a writable stream and pushed to the corresponding consumer based on resource type. Hypertext Markup Language (HTML) and Cascading Style Sheets (CSS) resources are pushed to the browser rendering engine, and script resources are pushed to the script virtual machine, enabling processing and consumption simultaneously without waiting for complete resource loading.

[0079] Fourth embodiment This embodiment provides an exemplary scheme for comprehensive priority calculation and hierarchical scheduling queuing. In this example, the corresponding resource type and loading timing requirements are first determined based on the resource type identifier of the data block. Then, three types of coefficients are obtained from the weight parameter library according to the resource dependency, resource type, and loading timing requirements. Subsequently, the comprehensive priority corresponding to the data block is calculated according to the weighted operation rules. Finally, the data block is pushed to the corresponding level of the scheduling queue according to the comprehensive priority. Step S30 includes steps C11 to C14: Step C11: Determine the resource type and loading timing requirements corresponding to the data block based on the resource type identifier of the data block.

[0080] Step C12: Match the corresponding parameters in the weight parameter library according to the resource dependency relationship, resource type and loading timing requirements of the data block to obtain the resource dependency level coefficient, resource rendering contribution coefficient and loading timing urgency coefficient.

[0081] Step C13: Perform weighted calculations on the resource dependency level coefficient, the resource rendering contribution coefficient, and the loading sequence urgency coefficient according to the weighted calculation rules to obtain the comprehensive priority corresponding to the data block.

[0082] Step C14: Based on the comprehensive priority corresponding to the data block, push the data block to the scheduling queue of the corresponding level.

[0083] The weight parameter library is a set of parameters pre-stored for weight configurations corresponding to different scenarios and resource types, serving as the rule basis for priority weighted calculation. The resource dependency level coefficient is a quantitative indicator that quantifies the nesting depth and number of pre-dependencies of the resources on which a data block depends, used to characterize the degree of pre-dependency for data block execution. The resource rendering contribution coefficient is a quantitative indicator that quantifies the role of resource type in supporting the initial page rendering and core interactions, used to characterize the rendering value level of the resource. The loading sequence urgency coefficient is a quantitative indicator that quantifies the urgency of the data block's demand in the page rendering sequence, used to characterize the time sensitivity of resource loading. The weighted calculation rule is a calculation rule that multiplies multi-dimensional coefficients by their corresponding weights and then sums them up, used to generate a unified priority quantification score.

[0084] In this example, when determining resource type and loading timing requirements based on the resource type identifier of a data block, the resource type identifier carried by the data block can be directly read according to the resource type determination result. This identifier is then combined with the current rendering stage of the page to match the corresponding loading timing level, thus completing the determination of resource type and loading timing requirements. Alternatively, a real-time rendering node awareness method can be used to collect the current rendering node and the list of content to be rendered from the browser's rendering engine in real time, dynamically determining the loading timing urgency level of each data block to adapt to changes in timing requirements during the dynamic rendering process of the page.

[0085] After determining the resource types and loading timing requirements, the weight parameter matching process is initiated. Combining the existing resource dependencies, resource types, and loading timing requirements of the data blocks, the weight parameter library is searched to retrieve the corresponding weight parameters for the scenario, yielding the resource dependency level coefficient, resource rendering contribution coefficient, and loading timing urgency coefficient. Then, according to preset weighting rules, the three coefficients are multiplied by their corresponding weights and summed to calculate the comprehensive priority score for each data block. Finally, based on the comprehensive priority score, the corresponding priority level is matched, and the data blocks are pushed to the corresponding level's scheduling queue in the original transmission order. This multi-dimensional weighted precise quantification and hierarchical queue scheduling achieves orderly and efficient resource scheduling in streaming processing scenarios, avoiding rendering delays caused by critical resource blockage.

[0086] For example, there are two ways to implement comprehensive priority calculation and hierarchical scheduling queuing. The first is a static weight fixed hierarchical scheduling mode. A fixed weight parameter library that is universally applicable to all scenarios is pre-configured. The same weight ratio is used for all data blocks. The resource dependency level coefficient, resource rendering contribution coefficient, and loading sequence urgency coefficient are multiplied by the corresponding fixed weights and then accumulated to obtain a comprehensive priority score. The score is then compared with a preset four-level fixed score range one by one to determine the priority level of the data block. After that, the data blocks are pushed to the corresponding level of the scheduling queue in sequence, and the queue is bound to a preset exclusive scheduling strategy. This method uses a serial calculation logic of fixed weights and fixed hierarchical ranges. The weight rules are uniform and stable, the calculation time is extremely low, and the scheduling judgment logic is simple and controllable. It can be highly adapted to the arrival rhythm of streaming data and is suitable for conventional static page loading scenarios with fixed page structure and standardized resource types.

[0087] The second method is a dynamic weighted adaptive hierarchical scheduling mode. First, based on the current page rendering stage, system running status, and queue backlog, the weight ratio of the three types of coefficients in the weight parameter library is dynamically adjusted to generate a dynamic weight configuration adapted to the current scenario. Then, a comprehensive priority score is calculated by combining the resource dependency level, rendering contribution, and timing urgency of each data block. Simultaneously, based on the current length and processing rate of each scheduling queue, the boundaries of the hierarchical threshold are adaptively adjusted. After determining the priority level, the data block is pushed to the corresponding scheduling queue, and the queue's scheduling parameters are updated synchronously. This method employs scenario-based dynamic weighting and adaptive hierarchical threshold processing logic, which can dynamically adjust the scheduling strategy according to different stages of the entire page loading lifecycle, flexibly responding to system load fluctuations and queue congestion. It offers higher scheduling adaptation accuracy and is suitable for rich interactive page loading scenarios with complex interactions and abundant dynamic resources.

[0088] Further, please refer to Figure 5 , Figure 5This is a sequence diagram of the system processing in this application. A time-series preprocessing scheme for front-end resources, progressing along a timeline, is supported by four underlying capabilities: error recovery mechanism, resource monitoring, performance optimization, and cache management. The process begins with the browser initiating a front-end resource request. After the stream acquisition and distribution module intercepts the Hypertext Transfer Protocol response, it starts acquiring and distributing resource data blocks. At time T2, the fault tolerance mechanism checks the integrity of the data blocks. If the data block verification fails, a retry is triggered, and the data block is returned to the stream acquisition and distribution module for re-acquisition. The error recovery mechanism ensures the reliability of data transmission. Subsequently, the data stream is transferred to the real-time parsing module for incremental parsing, incrementally generating abstract syntax trees or document object model fragments. Dependencies in the fragments are extracted and passed to the dependency management module. The resource monitoring mechanism monitors the running status and data processing progress of each module throughout the process. At time T3, the priority scheduling module starts, allocating CPU computing power and stream pipeline resources. Priority adjustments can be performed based on the real-time running status, and the performance optimization mechanism ensures scheduling efficiency and resource utilization. At time T4, the configuration adaptation module starts, dynamically adjusting the conversion strategy and supporting dynamic adaptation to different conversion rules and processing requirements through a configuration update mechanism. At time T5, the parsed data blocks enter the dynamic conversion module for incremental conversion processing. After the incremental conversion is completed, the processing results are synchronized to the dependency management module. At time T6, the dependency management module builds a complete dependency graph and preloads the corresponding dependency resources. After the dependency preloading is completed, dependency injection and content integration are completed. Finally, the processed valid resources are pushed to the consumer by the dependency management module in a real-time rendering execution manner. The caching management mechanism provides data caching and reuse capabilities for each stage throughout the process. The entire link achieves parallel and overlapping advancement of transmission, parsing, conversion, dependency loading, and consumption along the timeline, completely breaking the timing bottleneck of serial processing.

[0089] Fifth Embodiment This embodiment provides an exemplary scheme for comprehensive priority weighted calculation and hierarchical queue matching. In this example, the resource dependency level coefficient, resource rendering contribution coefficient, and loading sequence urgency coefficient are first multiplied by the corresponding adjustment ratio and then summed to obtain the comprehensive score of the data block. The comprehensive score is then compared with a preset score range to determine the comprehensive priority of the data block. Subsequently, a dedicated scheduling execution mode is matched according to the comprehensive priority to determine the scheduling strategy of the data block. Finally, the data block is pushed to the corresponding scheduling queue according to the scheduling strategy. Please refer to... Figure 6 , Figure 6 This is a flowchart illustrating the fifth embodiment of the control method for front-end resource preprocessing in this application. Step C13 includes steps D11-D14: Step D11: Multiply the resource dependency level coefficient, the resource rendering contribution coefficient, and the loading timing urgency coefficient by the corresponding adjustment ratio, and then sum them up to obtain the comprehensive score of the data block.

[0090] Step D12: Compare and match the comprehensive score of the data block with the preset score range to determine the comprehensive priority of the data block.

[0091] Step D13: Match the dedicated scheduling execution mode according to the comprehensive priority corresponding to the data block, and determine the scheduling strategy of the data block.

[0092] Step D14: Push the data block to the corresponding scheduling queue according to the scheduling strategy.

[0093] The adjustment ratio is a proportional parameter used to quantify the weighting of the three priority influencing factors. It corresponds one-to-one with the three coefficients and determines the contribution of each dimension to the final priority. The comprehensive score is a single quantified value obtained after weighted calculation of the three coefficients, and it is the core basis for determining the priority level. The preset score range is a pre-defined set of score ranges used to divide different priority levels; different ranges correspond to different priority levels. The dedicated scheduling execution mode is a scheduling execution rule customized for different priority levels, used to control the processing order and resource allocation method of data blocks. The scheduling strategy is a complete scheduling execution scheme integrating scheduling execution rules, resource allocation standards, and timing constraints. The scheduling queue is an ordered storage unit used to temporarily store data blocks to be scheduled, divided according to priority level. Different queues correspond to different scheduling execution priorities. For example, the preset score range is divided into four levels, corresponding to the highest priority, high priority, medium priority, and low priority levels. The dedicated scheduling execution modes correspond to four types: preemptive scheduling, long-cycle time-slice round-robin, short-cycle time-slice round-robin, and idle-triggered scheduling, respectively.

[0094] In this example, when obtaining the three types of coefficients and their corresponding adjustment ratios, the preset fixed adjustment ratio parameters can be directly retrieved by referring to the weight parameter library matching method, thereby completing the parameter preparation for the weighted calculation. Alternatively, the adjustment ratio adapted to the current scenario can be dynamically calculated and generated based on the current page rendering stage, system load, and queue backlog, thus adapting to the scheduling needs of different running stages.

[0095] After matching the coefficients and adjustment ratios, a weighted calculation process is initiated. The resource dependency level coefficient, resource rendering contribution coefficient, and loading timing urgency coefficient are multiplied by their respective adjustment ratios and then summed to calculate the comprehensive score for each data block. The comprehensive score is then compared with preset multi-level score intervals to determine the score interval to which the data block belongs, thus determining its comprehensive priority level. Next, based on the determined comprehensive priority level, a dedicated scheduling execution mode for that level is matched, integrating resource allocation, timing control, and processing rules to generate a complete scheduling strategy for that data block. Finally, according to the scheduling strategy, the data blocks are pushed to the corresponding level's scheduling queue in their original transmission order. Through refined weighted calculations and differentiated scheduling strategy matching, precise hierarchical resource scheduling in streaming processing scenarios is achieved, ensuring priority processing of critical resources and improving overall processing efficiency and rendering response speed.

[0096] For example, there are two ways to implement comprehensive priority calculation and queue pushing. The first is a fixed interval serial matching and static strategy binding mode. Four fixed preset score intervals and corresponding static dedicated scheduling execution modes are pre-configured. For each data block, a weighted calculation is performed sequentially to obtain a comprehensive score. Then, the score intervals are compared serially in descending order of priority. Once a matching interval is found, the comprehensive priority level is locked, and the pre-configured static scheduling strategy for that level is directly bound. Subsequently, the data blocks are pushed sequentially to the tail of the corresponding level's scheduling queue, maintaining the original arrival order of the data blocks in the queue. This method uses fixed hierarchical rules and serial successive matching calculation logic. The interval determination logic is simple and stable, the scheduling strategy is unified and controllable, and the calculation time is extremely low. It can be highly adapted to the arrival rhythm of streaming data and is suitable for conventional page loading scenarios with stable network conditions and fixed resource structures.

[0097] The second approach is a dynamic interval adaptive matching and scenario-based strategy generation mode. First, based on operational parameters such as the backlog length of each scheduling queue, system computing load, and page rendering stage, the boundary thresholds of preset score intervals at each level are dynamically adjusted. Simultaneously, a dedicated scheduling execution mode with corresponding priorities is dynamically generated based on the current scenario requirements. Then, weighted calculations are performed in parallel on batches of data blocks to obtain a comprehensive score. Parallel interval matching is used to quickly determine the comprehensive priority level of each data block, generating a customized scheduling strategy for each data block adapted to the current scenario. Subsequently, data blocks are pushed to their corresponding positions in the corresponding scheduling queues according to priority, with high-priority data blocks inserted at the front of the queue for priority processing. This method employs dynamic threshold adjustment and parallel batch matching processing logic, which can adaptively adjust the grading standards and scheduling rules according to the real-time system status, avoiding congestion in high-priority queues or starvation in low-priority queues. It offers greater scheduling flexibility and scenario adaptability, making it suitable for dynamic page loading scenarios with large system load fluctuations and complex interactions.

[0098] Further, the acquisition and distribution module serves as the entry point for stream processing. Its core function is to capture the HTTP response stream of browser network requests and convert it into a readable stream object that can be incrementally processed. The specific implementation logic is as follows: It intercepts the HTTP response of frontend resource requests through the browser's Fetch API. When the response header is returned and the response body data is received, it immediately intervenes in processing without waiting for the response body to be fully received. Based on the characteristics of the response body data, it creates a readable stream object, sets a data block reading threshold (default 4KB, adjustable via configuration), and divides the continuous response data stream into fixed-size binary / text data blocks to achieve incremental data reading. It employs a stream distribution route, initially classifying resource types such as HTML / JS / CSS / multimedia based on the Content-Type field of the HTTP response header, and distributing different types of data blocks to the corresponding processing branches. Simultaneously, it adds a unique identifier (including resource ID, block sequence number, and timestamp) to each data block for subsequent verification and backtracking. Process validity checks are performed by managing pending data blocks through a queue to avoid delays in processing individual data blocks affecting overall stream transmission efficiency, fully utilizing network bandwidth and CPU resources.

[0099] The real-time parsing module receives data blocks distributed by the streaming module. Its core function is to perform incremental parsing and dependency extraction of resources. Different parsing strategies are employed for different resource types to ensure accuracy and efficiency. Initial classification is performed first using the HTTP response header's Content-Type field (e.g., text / html corresponds to HTML resources, application / javascript corresponds to JS resources, and text / css corresponds to CSS resources). For scenarios with missing, ambiguous, or mislabeled Content-Type values, a feature code matching algorithm is introduced for secondary verification. This involves extracting N bytes (N≥16) of feature code from the data block header and comparing it with a preset feature library. The feature matching degree is calculated as shown in the formula: ; Where S is the feature matching degree, a_i is the i-th feature code of the data block to be identified, b_i is the i-th feature code of the target resource type in the feature library, n is the feature code length (default n=16), and ⊕ is the XOR matching operation. A successful match is determined when S≥95%, ensuring a type recognition accuracy ≥99%. A type verification fault tolerance mechanism is added; if a single feature matching fails, subsequent data blocks are read to supplement the feature code for a second matching, avoiding misjudgments due to missing features caused by data block fragmentation. Simultaneously, an incremental Document Object Model (DOM) parser based on a state machine is adopted, defining a four-state transition model of "tag start, attribute parsing, tag end, text content," parsing HTML fragments block by block. Construction is performed in real-time during the parsing process. The analysis phase utilizes an incremental abstract syntax tree (AST) construction algorithm to progressively build incomplete AST fragments from the lexical token stream. This phase primarily involves converting only the syntactic units contained in the current data block from the AST or DOM fragments output by the parsing module, without waiting for the complete resource. For example, the function signature of a JS resource is translated first, and incremental processing continues as subsequent function body data blocks arrive. Differentiated conversion strategies are employed for different fragments of the same resource (such as the core logic and comments of JS, and the structural tags and text content of HTML) to improve conversion efficiency.

[0100] Sixth Embodiment This embodiment provides an exemplary scheme for system operation status acquisition and steady-state determination of scheduling queues. In this example, the system first acquires operational data such as network downlink rate, processor utilization, and user interaction behavior corresponding to the scheduling queue and associates them with corresponding timestamps to obtain a set of status parameters. Then, the set of status parameters is matched and verified one by one with multi-level trigger thresholds, and the verification results are judged according to the adjustment judgment rules to obtain the corresponding judgment result and the corresponding adjustment magnitude parameter. Finally, when the judgment result is that no adjustment is triggered, the current scheduling queue is directly used as the target queue. Step S40 includes steps E11 to E13: Step E11: Collect the network downlink rate, processor utilization, and user interaction data corresponding to the scheduling queue, and obtain the set of status parameters by associating the timestamps.

[0101] Step E12: Match and verify the set of state parameters with the multi-level trigger thresholds one by one, and make conditional judgments on the verification results according to the adjustment judgment rules to obtain the judgment results and the corresponding adjustment range parameters.

[0102] Step E13: When the determination result is that no adjustment is triggered, the current scheduling queue is taken as the target queue.

[0103] The network downlink rate is an operational indicator representing the real-time level of network download bandwidth of terminal devices, directly affecting the efficiency of data block reception and distribution. Processor utilization is an operational indicator representing the real-time load of the terminal's core computing resources, directly affecting the efficiency of data block parsing and conversion. User interaction behavior is a behavioral indicator representing the activity level and interaction needs of users on the current page, directly affecting the timing priority and scheduling strategy of resource loading. The state parameter set is a standardized set of state data that integrates multi-dimensional operational data and binds it to corresponding collection timestamps; it is the core input basis for executing queue adjustment judgments. Multi-level trigger thresholds are a pre-set set of state parameter critical values ​​corresponding to different adjustment levels; different threshold ranges correspond to different adjustment trigger levels and adjustment magnitudes. The adjustment judgment rule is a set of logical rules used to comprehensively analyze multi-dimensional threshold matching results and determine whether to trigger queue adjustment. The judgment result is a conclusion on whether queue adjustment is triggered after conditional judgment, divided into two categories: triggered adjustment and non-triggered adjustment. The adjustment magnitude parameter is a quantitative parameter representing the magnitude of queue priority adjustment, and it only takes effect when adjustment is triggered.

[0104] In this example, when collecting operational data to obtain a set of state parameters, a periodic sampling method can be used. This involves synchronously collecting network, computing power, and interaction data at fixed time intervals, binding the sampling timestamps, and then summarizing the data to obtain the state parameter set. Alternatively, an event-triggered asynchronous collection method can be used. This method continuously monitors change events in the three types of operational data. When any dimension of data experiences a significant fluctuation, full-dimensional data collection is immediately triggered, and a state parameter set is generated after binding the event trigger timestamps. This allows for precise capture of abrupt changes in the system state.

[0105] After collecting the state parameter set, the threshold matching and adjustment judgment process is initiated. Each dimension parameter in the state parameter set is matched and verified against its corresponding multi-level trigger threshold, and the threshold level of each dimension parameter is recorded. Then, according to preset adjustment judgment rules, the matching results of all dimensions are combined to perform conditional judgment, yielding the final result of this judgment and the corresponding adjustment magnitude parameter. When the judgment result is no adjustment triggered, it is confirmed that the member order and scheduling strategy of the current scheduling queue remain in their original state. The current scheduling queue is directly used as the target queue. Through multi-dimensional state monitoring and rigorous conditional judgment, the stability of the scheduling queue is ensured when the system state is stable, avoiding the scheduling overhead caused by frequent adjustments.

[0106] For example, there are two ways to complete the state determination and queue steady-state confirmation. The first is a fixed-period single-dimensional serial determination steady-state mode. Three types of operational data are synchronously collected according to a preset fixed sampling period to generate a set of state parameters. These parameters are then compared serially with corresponding multi-level trigger thresholds in the order of network speed, processor utilization, and user interaction behavior. When none of the dimension parameters reach the minimum trigger threshold, it is directly determined that no adjustment will be triggered, and all members and scheduling configurations of the current scheduling queue are locked and used as the target queue. This method uses periodic sampling and serial dimension-by-dimensional determination processing logic. The determination logic is simple and stable, the system monitoring overhead is low, and it can smoothly complete state verification at a fixed rhythm. It is suitable for regular page loading scenarios with stable system load and no frequent interactions.

[0107] The second approach is a multi-dimensional, parallel, steady-state judgment mode. This mode continuously collects three types of operational data in parallel: network downlink rate, processor utilization, and user interaction behavior. It generates a real-time, timestamped state parameter stream and simultaneously verifies the matching relationship between all dimension parameters and multi-level trigger thresholds through a multi-dimensional, parallel judgment model. It comprehensively evaluates the overall system state fluctuation. When the overall fluctuation is within the steady-state range, it determines that no adjustment will be triggered. Simultaneously, it verifies the consistency of the current scheduling queue's running state and sequence; once confirmed, it is designated as the target queue. This method employs parallel real-time data acquisition and multi-dimensional, parallel judgment processing logic, resulting in high state awareness sensitivity. It comprehensively evaluates the overall system state rather than a single indicator, avoiding false triggers caused by accidental fluctuations in a single parameter. It is suitable for dynamic page loading scenarios where the system state experiences small fluctuations and user interaction is frequent.

[0108] Furthermore, key auxiliary mechanisms, to ensure the reliability of streaming processing, include multiple fault-tolerance mechanisms: data block verification: after each data block is processed, data integrity is verified through hash verification (such as MD5). If data corruption or processing errors are detected, a rollback mechanism is triggered, discarding the problematic data block; precise re-request: based on the unique identifier of the data block, only the specific corrupted data block is re-requested from the server, rather than retransmitting the entire resource, reducing network overhead for error recovery; anomaly degradation: when the Web Streams API is not supported by the current browser, it automatically degrades to the traditional full-processing mode to ensure system compatibility. Simultaneously, for security considerations, a priority scheduling mechanism is designed based on the importance of different resources, employing a three-dimensional quantitative scoring system of "resource type + rendering contribution + loading sequence requirements," with priority weights calculated as shown in the formula: ; Wherein, P is the overall priority score (ranging from 0 to 10, with higher scores indicating higher priority), T is the resource type weight (core JS / CSS: 10, first-screen images: 8, non-first-screen scripts: 4, redundant resources: 2), R is the rendering contribution (resources necessary for first-screen rendering: 10, non-first-screen but interactive: 6, non-essential: 2), and S is the loading timing requirement (immediate loading: 10, lazy loading: 3); α, β, and γ are weight coefficients (α+β+γ=1, default α=0.4, β=0.4, γ=0.2, adjustable by configuration). Resources are divided into four priority levels based on the P value: P≥9 is the highest priority (P0), 7≤P<9 is high priority (P1), 4≤P<7 is medium priority (P2), and P<4 is low priority (P3). The system employs a four-level feedback queue design with four priority levels, each using a differentiated scheduling strategy: P0 queue: Preemptive scheduling is used. Once a P0-level data block arrives, processing of the current low-priority queue is immediately paused, and CPU and streaming resources are prioritized for the P0 data block. The low-priority queue is then restored after processing is complete. P1 / P2 queues: Round-robin scheduling is used. A longer time slice (default 100ms) is allocated to the P1 queue, and a shorter time slice (default 50ms) to the P2 queue, ensuring that high-priority queues receive more processing resources. P3 queue: Idle-triggered scheduling is used. Processing is initiated only when system resources are idle, based on monitoring CPU utilization (threshold ≤30%) and network bandwidth usage (threshold ≤20%), avoiding the consumption of core resources. A dynamic adjustment mechanism based on real-time status is implemented: Priority strategies are adjusted in real-time based on network status, CPU load, and user interaction behavior, ensuring scheduling flexibility and system stability. Firstly, regarding network status adaptation: The network type (2G / 3G / 4G / 5G / Wi-Fi) and downlink speed are obtained via the Navigator.connection API. When the network speed is ≤1Mbps, P3-level resource processing is paused, prioritizing P0 / P1-level resources. When the network speed is ≥10Mbps, the processing priority of P2-level resources is increased to fully utilize bandwidth. Secondly, CPU utilization is monitored in real-time via the performance API. When CPU utilization is ≥80%, the time slice allocation for P1 and lower priority resources is reduced to avoid system lag. When CPU utilization is ≤30%, the processing weight of low-priority queues is increased. For scheduling status monitoring and visualization: A built-in scheduling status monitoring module collects data such as processing progress, resource utilization, and priority adjustment records for each queue in real time. Data block processing status is marked using status codes (0 = waiting for processing, 1 = processing, 2 = completed, 3 = paused). Simultaneously, it supports outputting scheduling data to front-end debugging tools, allowing developers to intuitively view the priority scheduling effect and optimize scheduling parameter configurations.

[0109] The dependency management and injection module is responsible for maintaining a real-time dependency graph of resources and dynamically injecting necessary dependency code or resource links into the data stream. This module works closely with the parsing module; once the parsing module extracts new dependencies from HTML or JS, such as detecting import statements or resource links, the dependency management module immediately records these relationships and determines whether the referenced resources need to be preloaded. For critical dependencies, the system can trigger new concurrent requests to retrieve these resources, thereby achieving early loading and parallel processing of dependent resources. Regarding injection, this module dynamically modifies the content of the data blocks flowing through it. For example, when processing JavaScript modules, the system may convert import statements into direct references to already loaded modules; or in the HTML stream, it may replace external stylesheet links with inline style blocks (if the strategy allows) to accelerate rendering. The injection operation is real-time and context-aware, ensuring that the modified code is semantically correct and dependencies are available during subsequent consumption.

[0110] At the end of the entire stream processing pipeline is the consumer, typically the browser's rendering engine (for HTML / CSS) or a JavaScript virtual machine (for JS). Processed data blocks are directly passed to the consumer via a writable stream (WritableStream), allowing it to immediately begin parsing, compilation, or rendering without waiting for the entire file transfer to complete. For example, a browser can download and render an HTML page simultaneously, progressively presenting the page structure; for JavaScript, the engine can begin compiling and executing received code blocks, even before the function body has fully arrived. To ensure the reliability and data consistency of the stream processing, the system incorporates multiple fault-tolerance mechanisms. Each data block undergoes format validation and hash verification after processing. If a processing error or data corruption is detected, the system can trigger a rollback operation, discarding the problematic block and re-requesting the specific data segment, rather than reloading the entire resource, thus minimizing the overhead of error recovery. The system also supports processing priority scheduling, allowing higher processing priority to be assigned to critical resources (such as CSS or JS required for initial page rendering), prioritizing their passage through the processing pipeline and further optimizing the user experience.

[0111] This solution is designed for seamless integration with the existing front-end development ecosystem. It can run as a plugin for build tools (such as Webpack, Rollup, or Vite) on the development server or during the build process, enabling streaming preprocessing and hot updates during development; it can also be deployed in the edge nodes or gateways of a content delivery network (CDN) as a runtime acceleration layer, performing real-time streaming optimization of resources delivered to end users, thereby providing an end-to-end performance improvement solution.

[0112] Seventh Embodiment This embodiment provides an exemplary scheme for dynamic adjustment and cross-queue migration of scheduling queues. In this example, the determination result is first branched, divided into two execution paths: one that does not trigger adjustment and one that triggers adjustment. When the determination result is that adjustment is triggered, the priority increase or decrease value corresponding to each data block is calculated according to the adjustment magnitude parameter. Then, the comprehensive priority of each data block is updated according to the increase or decrease value. Finally, the cross-queue migration of data blocks is executed according to the updated comprehensive priority, and the corresponding level of scheduling execution rules is rebound to obtain the target queue adapted to the current system state. Please refer to... Figure 7 , Figure 7 This is a flowchart illustrating the seventh embodiment of the control method for front-end resource preprocessing in this application. Step E12 includes steps F11 to F14: Step F11: Perform branch identification on the determination result and divide it into two types of execution paths: one that does not trigger adjustment and one that triggers adjustment.

[0113] Step F12: When the determination result is the trigger adjustment, calculate the priority increase or decrease value corresponding to the data block block by block according to the adjustment range parameter.

[0114] Step F13: Update the overall priority of the data block according to the priority increase / decrease value corresponding to the data block.

[0115] Step F14: Perform cross-queue migration of the data blocks according to the updated comprehensive priority, rebind the corresponding level of scheduling execution rules for the data blocks migrated into the new queue, and obtain the target queue.

[0116] Branch identification is a processing action that classifies the execution direction of the judgment result to match the corresponding subsequent processing flow. Execution path refers to the branches of the subsequent processing flow corresponding to different judgment results, divided into two categories: non-triggering adjustment paths that maintain queue stability and triggering adjustment paths that perform queue optimization. Priority increase / decrease values ​​are numerical parameters that quantify the magnitude and direction of data block priority adjustments; positive indicates priority increase, and negative indicates priority decrease. Cross-queue migration is the scheduling adjustment action of transferring a data block from its original scheduling queue to the scheduling queue corresponding to a new priority.

[0117] In this example, when identifying branches based on the judgment results, the result identifier field can be directly read from the conditional judgment results to complete the division of the two types of execution paths, thereby achieving fast branch matching. Alternatively, a multi-round result aggregation and identification method can be used, combining the judgment results from multiple consecutive sampling periods for comprehensive aggregation and judgment to confirm whether the trigger adjustment path has truly been entered, thereby avoiding erroneous adjustments caused by a single state fluctuation.

[0118] After branch identification and confirmation of entering the trigger adjustment path, the priority update and queue adjustment process is initiated. Based on the adjustment magnitude parameter and the original priority level and resource attributes of each data block, the priority increase or decrease value of each data block is calculated block by block. Then, the comprehensive priority score is adjusted based on the priority increase or decrease value of each data block to complete the update of the comprehensive priority. Next, the corresponding level of scheduling queue is rematched according to the updated comprehensive priority. Data blocks with changed priorities are moved out of the original queue and into the corresponding new queue. At the same time, the original scheduling execution rule binding is removed for all data blocks moved into the new queue, and the scheduling execution rules of the corresponding level of the new queue are rematched and bound. After verifying the member order and rule matching of all queues, the final target queue is obtained. In this way, through fine-grained block-by-block priority adjustment and cross-queue dynamic migration, the scheduling queue adapts to the changes in system operation status in real time, ensuring the processing priority of critical resources and overall scheduling efficiency.

[0119] For example, there are two ways to implement priority updates and cross-queue migration to obtain the target queue. The first is a full-queue serial block-by-block adjustment and migration mode. This mode traverses all scheduling queues sequentially from low to high priority, calculates the priority increase or decrease value for each data block in each queue, updates the corresponding comprehensive priority, and then determines whether cross-queue migration is needed. If migration is required, the data block is removed from the original queue and inserted into the corresponding position in the target queue. Simultaneously, the unbinding and rebinding of scheduling execution rules are completed. After all data blocks are processed, the order consistency of each queue is verified to generate the final target queue. This method uses a single-threaded serial traversal and block-by-block processing logic, ensuring controllable adjustment order, low data migration conflict rate, and high queue order stability. It is suitable for conventional scheduling adjustment scenarios with small data block sizes and small adjustment ranges.

[0120] The second method is a segmented parallel batch adjustment and migration mode. First, based on the adjustment magnitude parameter and the original priority level of the data blocks, all data blocks to be adjusted are divided into three independent segments: a promotion group, a demotion group, and a maintenance group. Parallel processing tasks are then initiated for the promotion and demotion groups to batch calculate the priority increase / decrease values ​​of all data blocks within each group and update the overall priority. Then, batch cross-queue migration is completed according to the new priority level, and the corresponding scheduling execution rules are rebound in batches. Data blocks in the maintenance group remain in their original queues without modification. After all group processing is completed, the order and rule matching of the entire queue are uniformly verified to generate the final target queue. This method uses segmented grouping and parallel batch processing computation logic. By splitting the data blocks into pre-groups, dependent adjustment tasks are executed in parallel, reducing the time consumed by serial traversal and resulting in higher adjustment processing efficiency. It is suitable for large-scale scheduling and adjustment scenarios with large data block sizes and significant system state fluctuations.

[0121] Eighth embodiment This embodiment provides an exemplary scheme for incremental resource conversion and dependency injection push. In this example, the corresponding incremental conversion rule set is first matched according to the resource type identifier attached to the data block in the target queue. Then, the segmented document structure fragments within the data block are subjected to block-by-block syntax translation and code simplification according to the incremental conversion rule set to generate locally syntactically consistent segmented conversion fragments. Subsequently, the global resource dependency set is retrieved to verify the readiness status of the dependency resources and the ready dependency content is injected into the corresponding syntax node position to obtain the segmented target data block. Finally, after completing the format compliance and semantic consistency verification, it is pushed to the consumer in an orderly manner according to the consumer rendering execution sequence requirements. After step S50, steps G11~G14 are also included: Step G11: Match the corresponding incremental conversion rule set according to the resource type identifier attached to the data block in the target queue.

[0122] Step G12: Perform block-by-block syntax translation and code simplification on the segmented document structure fragments within the data block according to the incremental transformation rule set, and generate locally syntactically self-consistent segmented transformation fragments.

[0123] Step G13: Retrieve the resource dependency relationship between the global resource dependency set and the data block for matching and verification, confirm the ready status of the dependent resources, and inject the ready dependency content into the corresponding syntax node position of the segmented transformation fragment to obtain the segmented target data block.

[0124] Step G14: Perform format compliance and semantic consistency verification on the segmented target data block. After the verification is passed, push the data to the consumer in an orderly manner according to the timing requirements of the consumer rendering execution.

[0125] The incremental conversion rule set is a set of pre-defined processing rules for specific resource types, including syntax translation rules, code optimization rules, and format specification rules. It serves as the rule basis for performing incremental resource conversion. Segmented document structure fragments are local syntactic structure units generated after incremental parsing of data blocks, and are the core input objects for incremental conversion processing. Syntax translation is the process of converting the original syntax format of the resource into a consumer-compatible syntax format to ensure cross-environment compatibility. Code simplification is an optimization process that removes redundant characters and simplifies logic in the resource content to reduce resource size and improve loading efficiency. Segmented conversion fragments are locally syntactically self-consistent conversion result units generated after single-block data conversion processing. The global resource dependency set is a unified dependency ledger covering all loaded resources and recording the loading status of each resource. Dependency ready status is a status indicator indicating whether a dependent resource has completed loading and conversion and can be directly injected and used. Segmented target data blocks are standardized resource units that have completed conversion processing and dependency injection and can be directly pushed to the consumer. Format compliance verification is a verification action to confirm whether the format of the target data block conforms to the consumer's receiving standards. Semantic consistency verification is a validation action that verifies whether the semantic logic of data blocks is complete and correct after dependency injection. For example, syntax transpilation includes backward compatibility transpilation of high-level script syntax and style preprocessor syntax transpilation; code simplification includes whitespace comment removal and variable name compression; and resource types include script resources, style resources, and document resources.

[0126] In this example, when matching the incremental conversion rule set based on the resource type identifier, the resource type determination result can be referenced, and the corresponding conversion rule set can be directly matched through the static mapping relationship between type and rule, thereby completing the rapid retrieval of conversion rules. Alternatively, a scenario-based dynamic adaptation approach can be adopted, combining the current operating environment, consumer version, and performance configuration to dynamically filter and combine suitable conversion rules to generate a unique incremental conversion rule set for this application, thus adapting to the conversion needs of different terminal environments.

[0127] After matching the incremental transformation rule set, the block-by-block transformation and dependency injection process is initiated. According to the incremental transformation rule set, the segmented document structure fragments within the data block are sequentially subjected to syntax transpilation and code simplification, generating locally syntactically consistent segmented transformation fragments. Subsequently, the global resource dependency set is retrieved, and its resource dependencies bound to the current data block are matched and verified one by one to confirm the readiness status of all dependent resources. Ready dependencies are then precisely injected into the corresponding syntax node positions of the segmented transformation fragments, ensuring semantic logical coherence after injection, resulting in the segmented target data block. Finally, format compliance and semantic consistency checks are performed on the segmented target data block. If the checks fail, a single-block re-transformation process is triggered. If the checks pass, the segmented target data blocks are pushed to the consumer in sequence according to the rendering execution timing requirements of the consumer. Thus, through block-by-block incremental transformation and precise dependency injection, resources can be transformed and consumed simultaneously in streaming processing scenarios without waiting for the full resource processing to complete, improving the loading response speed and execution stability of front-end resources.

[0128] For example, there are two ways to implement incremental conversion and dependency injection push. The first is a serial processing mode of single-block in-situ conversion and fixed-point dependency injection. Data blocks are retrieved one by one according to the scheduling order of the target queue. Based on the segmented document structure fragments of the single block, in-situ syntax translation and code simplification are performed to generate segmented conversion fragments. The dependencies of the current data block are matched synchronously, and the ready dependency content is injected into the corresponding syntax nodes in the fragment to generate segmented target data blocks. After verification, the blocks are immediately pushed to the consumer. The conversion processing of the next block is started only after the processing of a single block is completed. This method adopts the execution logic of single-block serial in-situ processing. The single-block processing link is short, the output latency is low, and the processing rhythm is highly matched with the scheduling dequeue rhythm. It can realize the push of data blocks as they are processed, and is suitable for streaming incremental consumption scenarios with low latency requirements.

[0129] The second approach employs a multi-segment context-linked transformation and dependency preloading parallel processing mode. Each time, multiple consecutive data blocks are retrieved from the target queue. These segments are first concatenated to form a locally complete syntactic context. Based on this complete context, globally optimized syntax transpilation and code simplification are performed to generate semantically coherent segmented transformation fragments. Simultaneously, dependency resources for subsequent batches are preloaded according to dependencies. During the transformation process, dependency content is integrated and injected, forming consecutive segmented target data blocks. After batch verification, these blocks are pushed sequentially to the consumer. This method utilizes multi-segment context-linked processing and dependency preloading, enabling cross-block global optimization, higher transformation quality, and more proactive dependency loading. It reduces consumer waiting time and the risk of syntax errors, making it suitable for complex resource processing scenarios with higher requirements for resource execution efficiency and stability.

[0130] This application provides a front-end resource preprocessing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the control method for front-end resource preprocessing in the first embodiment described above.

[0131] The following is for reference. Figure 8 The diagram illustrates a structural schematic of a front-end resource preprocessing device suitable for implementing embodiments of this application. The front-end resource preprocessing device in these embodiments may include, but is not limited to, mobile terminals such as laptops, application delivery controllers, personal digital assistants (PDAs), tablets (PADs), edge node servers, etc., as well as fixed terminals such as cache server hardware devices, desktop computers, etc. Figure 8 The front-end resource preprocessing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0132] like Figure 8 As shown, the front-end resource preprocessing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the front-end resource preprocessing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the front-end resource preprocessing device to communicate wirelessly or wiredly with other devices to exchange data. Although a front-end resource preprocessing device with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0133] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0134] The front-end resource preprocessing device provided in this application, employing the front-end resource preprocessing control method in the above embodiments, can solve the technical problem of poor resource processing efficiency. Compared with the prior art, the beneficial effects of the front-end resource preprocessing device provided in this application are the same as the beneficial effects of the front-end resource preprocessing control method provided in the above embodiments, and other technical features in this front-end resource preprocessing device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0135] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0136] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0137] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the front-end resource preprocessing control method in the above embodiments.

[0138] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0139] The aforementioned computer-readable storage medium may be included in the front-end resource preprocessing device; or it may exist independently and not be assembled into the front-end resource preprocessing device.

[0140] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a front-end resource preprocessing device, the front-end resource preprocessing device: responds to a network resource request and segments the response data stream corresponding to the network resource request according to a data block reading threshold to obtain different types of data blocks; incrementally parses the different types of data blocks block by block to obtain the resource dependencies corresponding to the data blocks; calculates the comprehensive priority of the data blocks based on the resource dependencies, resource types, and loading timing requirements, and pushes the data blocks to the corresponding scheduling queue based on a differentiated scheduling strategy and the comprehensive priority of the data blocks; determines the system operating status according to adjustment judgment rules, updates the scheduling queue based on the judgment result, and obtains a target queue; performs resource conversion processing on the data blocks based on the target queue, and generates target data and pushes it to the consumer end in conjunction with the resource dependencies of the data blocks.

[0141] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0142] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0143] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0144] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned front-end resource preprocessing control method, thereby solving the technical problem of poor resource processing efficiency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the front-end resource preprocessing control method provided in the above embodiments, and will not be repeated here.

[0145] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A control method for front-end resource preprocessing, characterized in that, The method includes: In response to a network resource request, the response data stream corresponding to the network resource request is divided according to the data block reading threshold to obtain different types of data blocks; The data blocks of different types are parsed incrementally, and the resource dependencies corresponding to the data blocks are obtained. Based on the resource dependencies, resource types, and loading timing requirements of the data block, the overall priority of the data block is calculated, and the data block is pushed to the corresponding scheduling queue based on the differentiated scheduling strategy and the overall priority of the data block. The system operating status is determined according to the adjustment judgment rules, and the scheduling queue is updated according to the judgment result to obtain the target queue; Based on the target queue, the data block is processed for resource transformation. Combined with the resource dependencies of the data block, target data is generated and pushed to the consumer. The steps of determining the system operating status according to the adjustment judgment rules, updating the scheduling queue based on the judgment result, and obtaining the target queue include: Collect operational data such as network downlink rate, processor utilization, and user interaction behavior corresponding to the scheduling queue, and obtain a set of status parameters by associating timestamps; The set of state parameters is matched and verified one by one with the multi-level trigger thresholds, and the verification results are conditionally determined according to the adjustment judgment rules to obtain the judgment result and the corresponding adjustment range parameter. When the determination result is that no adjustment is triggered, the current scheduling queue is taken as the target queue; After the steps of matching and verifying the set of state parameters one by one with the multi-level trigger thresholds, and performing conditional judgment on the verification results according to the adjustment judgment rules to obtain the judgment result and the corresponding adjustment magnitude parameter, the front-end resource preprocessing control method further includes: The determination results are branched and divided into two execution paths: one that does not trigger adjustment and one that triggers adjustment. When the determination result is the trigger adjustment, the priority increase or decrease value corresponding to the data block is calculated block by block according to the adjustment range parameter; Update the overall priority of the data block according to the priority increase or decrease value corresponding to the data block; The data blocks are migrated across queues according to the updated comprehensive priority, and the corresponding level of scheduling execution rules are rebound for the data blocks migrated into the new queue to obtain the target queue.

2. The control method for front-end resource preprocessing as described in claim 1, characterized in that, The step of responding to a network resource request and dividing the response data stream corresponding to the network resource request into different types of data blocks according to a data block reading threshold includes: Based on the network resource request, retrieve the response data stream sent by the website corresponding to the network resource request; The response data stream is segmented according to the data block reading threshold, and each segment of data is bound with identity tagging information to obtain the original data block. Based on the header feature code of the original data block, and combined with the content type field of the network resource request corresponding to the original data block, the resource category is determined to obtain a marked data block with resource type identifier; According to the type classification rules, the marked data blocks with resource type identifiers are grouped and processed to obtain data blocks of different types.

3. The control method for front-end resource preprocessing as described in claim 1, characterized in that, The step of incrementally parsing different types of data blocks to obtain the resource dependencies corresponding to the data blocks includes: Match the corresponding state machine-based incremental parser instance based on the resource type identifier corresponding to the data block; The incremental parser instance performs block-by-block streaming lexical and syntactic analysis on the data block, caches the unclosed syntactic unit stack, and generates segmented document structure fragments corresponding to the data block. Traverse the segmented document structure fragments corresponding to the data block, organize the resource import statements and external resource reference information in the segmented document structure fragments, and obtain the preliminary resource dependency set corresponding to the data block; Based on the global resource dependency set matching and verification of the preliminary resource dependency set, the indirect dependency entries of the nested levels in the preliminary resource dependency set are supplemented to obtain the resource dependency relationship corresponding to the data block.

4. The control method for front-end resource preprocessing as described in claim 1, characterized in that, The step of calculating the comprehensive priority of the data block based on its resource dependencies, resource type, and loading timing requirements, and then pushing the data block to the corresponding scheduling queue based on the differentiated scheduling strategy and the comprehensive priority of the data block, includes: The resource type and loading timing requirements corresponding to the data block are determined based on the resource type identifier of the data block. Based on the resource dependency relationship, resource type and loading timing requirements of the data block, the corresponding parameters are matched in the weight parameter library to obtain the resource dependency level coefficient, resource rendering contribution coefficient and loading timing urgency coefficient. The resource dependency level coefficient, the resource rendering contribution coefficient, and the loading sequence urgency coefficient are weighted according to the weighted calculation rules to obtain the comprehensive priority corresponding to the data block. Based on the overall priority corresponding to the data block, the data block is pushed to the scheduling queue of the corresponding level.

5. The control method for front-end resource preprocessing as described in claim 4, characterized in that, The step of calculating the comprehensive priority of the data block by weighting the resource dependency level coefficient, the resource rendering contribution coefficient, and the loading sequence urgency coefficient according to the weighted calculation rules includes: The comprehensive score of the data block is obtained by multiplying the resource dependency level coefficient, the resource rendering contribution coefficient, and the loading timing urgency coefficient by the corresponding adjustment ratio and then summing them up. The overall score of the data block is compared and matched with a preset score range to determine the overall priority of the data block. The scheduling strategy for the data block is determined by matching a dedicated scheduling execution mode based on the comprehensive priority corresponding to the data block. The data block is pushed to the corresponding scheduling queue according to the scheduling strategy.

6. The control method for front-end resource preprocessing as described in claim 1, characterized in that, The step of performing resource transformation processing on the data block based on the target queue, and generating target data and pushing it to the consumer based on the resource dependencies of the data block includes: Match the corresponding incremental conversion rule set based on the resource type identifier attached to the data block in the target queue; According to the incremental transformation rule set, the segmented document structure fragments within the data block are subjected to block-by-block syntax translation and code simplification to generate locally syntactically consistent segmented transformation fragments; The resource dependency relationship between the global resource dependency set and the data block is retrieved for matching and verification. The ready status of the dependent resources is confirmed, and the ready dependency content is injected into the corresponding syntax node position of the segmented transformation fragment to obtain the segmented target data block. The segmented target data blocks are checked for format compliance and semantic consistency. After the checks are passed, the data is pushed to the consumer in an orderly manner according to the timing requirements of the rendering execution on the consumer side.

7. A front-end resource preprocessing device, characterized in that, The front-end resource preprocessing device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method for front-end resource preprocessing as described in any one of claims 1 to 6.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the control method for front-end resource preprocessing as described in any one of claims 1 to 6.

Images