Front-end processing method and apparatus, terminal device, and storage medium

By intercepting concurrent network requests through service worker threads and retrieving target data based on adaptive strategies, the white screen problem caused by high concurrency requests on the front-end page was solved, achieving fast response and efficient data display, thus improving the user experience.

CN117421499BActive Publication Date: 2025-11-04CHINA MOBILE INFORMATION TECHNOLOGY CO LTD +1
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202311353656.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-10-18
Publication Date
2025-11-04
Estimated Expiration
2043-10-18

AI Technical Summary

Technical Problem

During the initial loading process of the front-end page, some network requests may be suspended or timed out due to network or back-end service response issues, resulting in a blank screen. Existing caching queue methods are inefficient and unreliable, making it difficult to solve the response timeout problem caused by high-concurrency requests.

Method used

By intercepting network requests through service worker threads, if the target data does not exist in the cache, the target domain name is determined based on an adaptive adjustment strategy, a query request is initiated, and the target data is obtained through backend nodes for rendering and display. Service Worker is used to achieve parallel sending of asynchronous network requests, optimizing the handling of concurrent network requests.

Benefits of technology

It enables fast response to concurrent network requests, improves data response speed, enhances user experience, reduces browser processing burden, and minimizes white screen issues.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117421499B_ABST
    Figure CN117421499B_ABST
Patent Text Reader

Abstract

The application discloses a front-end processing method and device, a terminal equipment and a storage medium, wherein, in response to a loading instruction of a front-end page, a network request corresponding to the loading instruction is intercepted through a service worker; if target data corresponding to the network request does not exist in pre-stored cache data, an access destination domain name corresponding to the network request is determined based on an adaptive adjustment strategy, a query request is initiated to at least one backend node to obtain the target data corresponding to the network request, and the target data is rendered and displayed; the network request is intercepted through the service worker, and the network request for which the target data does not exist in the pre-stored cache data is optimized based on the adaptive adjustment strategy, and then the target data corresponding to the network request is obtained through the backend node and rendered and displayed, so that the network request is processed in time, the data response speed is improved, and the user experience is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a front-end processing method, apparatus, terminal device, and storage medium. Background Technology

[0002] During the front-end page display process, multiple HTTP requests need to be sent to the back-end simultaneously during the initial page loading. Due to network or back-end service response issues, some network requests may become pending or timeout, which can easily cause a blank screen on the front end and result in a poor user experience.

[0003] Existing technologies use a cache queue approach, building a sequential request queue for Promise through reduce, which can effectively reduce the concurrency of network requests.

[0004] In the process of conceiving and implementing this application, the inventors discovered at least the following problems: the above method requires all requests to return successfully. If a request fails, no subsequent requests will be sent, which is inefficient. Furthermore, the existing technology has low reliability and fault tolerance, and it is difficult to overcome the problem of page white screen caused by response timeout due to high concurrency requests on the front-end page.

[0005] Therefore, it is necessary to propose a solution to achieve a fast response to concurrent network requests in order to avoid the problem of a blank screen on the front end.

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

[0007] The main objective of this invention is to provide a front-end processing method, apparatus, terminal device, and storage medium, which aims to achieve rapid response to concurrent network requests and avoid front-end white screen problems.

[0008] To achieve the above objectives, the present invention provides a front-end processing method, the front-end processing method comprising:

[0009] In response to the loading command of the front-end page, the network request corresponding to the loading command is intercepted through the service worker thread;

[0010] If the target data corresponding to the network request does not exist in the pre-stored cached data, the access destination domain name corresponding to the network request is determined based on the adaptive adjustment strategy, and used to initiate a query request to at least one backend node to obtain the target data corresponding to the network request, and to render and display the target data.

[0011] Optionally, after the step of intercepting the network request corresponding to the loading instruction through a service worker thread in response to the loading instruction of the front-end page, the method further includes:

[0012] If the target data corresponding to the network request exists in the pre-stored cache data, then the target data is retrieved from the cache data and rendered and displayed.

[0013] Optionally, the step of intercepting the network request corresponding to the loading instruction through the service worker thread further includes:

[0014] Determine whether the browser version of the front-end page supports the service worker thread;

[0015] If the browser version of the front-end page supports the service worker thread, then the service worker thread is enabled.

[0016] Optionally, before the step of retrieving the target data from the cached data and rendering it if the target data corresponding to the network request exists in pre-stored cached data, the method further includes:

[0017] Obtain the historical behavior data corresponding to the front-end page;

[0018] The historical behavior data is analyzed to obtain user preference information;

[0019] The data related to the user preference information is stored to obtain the cached data.

[0020] Optionally, the step of storing data related to the user preference information to obtain the cached data includes:

[0021] The cached data is obtained by storing data related to the user preference information at the individual page level; and / or,

[0022] The cached data is obtained by storing data related to the user preference information at the granularity of the data on the page.

[0023] Optionally, the step of storing data related to the user preference information at the granularity of the data on the page to obtain the cached data includes:

[0024] Based on a pre-trained data change prediction model, a caching configuration is set for at least one data type in the full dataset, and at least one of data storage, data modification, and data deletion is performed based on the caching configuration; and / or,

[0025] The system queries data related to the user preference information at preset intervals to determine if there are any data identifiers indicating changes. If there are data identifiers indicating changes, the system performs at least one of the following actions: data storage, data modification, and data deletion.

[0026] Optionally, before the step of setting the caching configuration for at least one data type in the full dataset based on the pre-trained data change prediction model, the method further includes:

[0027] Acquire pre-collected sample data, wherein the sample data includes at least one of the following: data type, amount of changed data, change time, and business type;

[0028] The sample data is processed to obtain various multidimensional datasets;

[0029] The data change prediction model is obtained by training the model based on the aforementioned multidimensional datasets.

[0030] Optionally, after the step of storing the data related to the user preference information to obtain the cached data, the method further includes:

[0031] In response to the launch command of the initial page corresponding to the full data, the full data is preloaded;

[0032] In response to receiving a data request instruction for the initial page, the corresponding requested data is selected from the loaded full data according to the data request instruction;

[0033] The requested data is sent to the browser's main thread for data rendering and display.

[0034] Optionally, the target data includes preferred data and / or non-preferred data. The step of retrieving the target data from the cached data and rendering it if the target data corresponding to the network request exists in pre-stored cached data includes:

[0035] If the preference data in the target data exists in pre-stored cached data, then the preference data is retrieved from the cached data and rendered; and / or,

[0036] If there is corresponding initialization data for the non-preferred data in the target data, then the initialization data is called and rendered for display.

[0037] Optionally, the step of determining the destination domain name corresponding to the network request based on the adaptive adjustment strategy includes:

[0038] Based on the original destination domain name of the network request, initiate the network request to at least one backend node; and if the network request fails, change the original destination domain name and initiate the network request again based on the changed domain name; and / or,

[0039] Initiate speed test network requests to each backend node to obtain the speed test results of each backend node, determine the priority of each backend node based on the speed test results, and determine the access destination domain name corresponding to the network request based on the priority of each backend node.

[0040] Optionally, the step of initiating a query request to at least one backend node includes:

[0041] The network requests are processed in batches and / or encapsulated to obtain processed network requests;

[0042] The processed network request is sent to at least one corresponding backend node.

[0043] Furthermore, to achieve the above objectives, the present invention also provides a front-end processing device, the front-end processing device comprising:

[0044] The interception module is used to intercept network requests corresponding to the loading instructions of the front-end page through the service worker thread.

[0045] The initiating module, if the target data corresponding to the network request does not exist in the pre-stored cached data, is used to determine the access destination domain name corresponding to the network request based on the adaptive adjustment strategy, and to initiate a query request to at least one backend node to obtain the target data corresponding to the network request, and to render and display the target data.

[0046] In addition, to achieve the above objectives, the present invention also provides a terminal device, the terminal device including a memory, a processor, and a front-end processing program stored in the memory and executable on the processor, wherein the front-end processing program, when executed by the processor, implements the steps of the front-end processing method as described above.

[0047] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a front-end processing program, which, when executed by a processor, implements the steps of the front-end processing method as described above.

[0048] This invention proposes a front-end processing method, apparatus, terminal device, and storage medium. Responding to a front-end page loading instruction, a service worker thread intercepts the network request corresponding to the loading instruction. If the target data corresponding to the network request does not exist in pre-stored cached data, an adaptive adjustment strategy is used to determine the access destination domain name corresponding to the network request. This domain name is then used to initiate a query request to at least one backend node to obtain the target data corresponding to the network request. The target data is then rendered and displayed. By intercepting network requests through the service worker thread and optimizing network requests where the target data does not exist in pre-stored cached data based on the adaptive adjustment strategy, the target data corresponding to the network request is obtained and rendered and displayed through the backend node. This achieves timely processing of network requests, improves data response speed, and thus enhances the user experience. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the functional modules of the terminal device to which the front-end processing device of the present invention belongs;

[0050] Figure 2 This is a flowchart illustrating an exemplary embodiment of the front-end processing method of the present invention;

[0051] Figure 3 This is a flowchart illustrating another exemplary embodiment of the front-end processing method of the present invention;

[0052] Figure 4 This is a schematic diagram illustrating the principle of cached data comparison in an embodiment of the present invention;

[0053] Figure 5 for Figure 3 A schematic diagram of the specific process of step S03 in the embodiment;

[0054] Figure 6 This is a schematic diagram illustrating code initialization in an embodiment of the present invention;

[0055] Figure 7 This is a schematic diagram of the regression prediction process in an embodiment of the present invention;

[0056] Figure 8 for Figure 2 A schematic diagram of the specific process of step S30 in the embodiment;

[0057] Figure 9 This is a schematic diagram illustrating a network request example in an embodiment of the present invention.

[0058] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0059] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0060] The main solution of this invention is as follows: in response to the loading instruction of the front-end page, the network request corresponding to the loading instruction is intercepted by the service worker thread; if the target data corresponding to the network request does not exist in the pre-stored cached data, the access destination domain name corresponding to the network request is determined based on the adaptive adjustment strategy, and a query request is initiated to at least one back-end node to obtain the target data corresponding to the network request, and the target data is rendered and displayed. This achieves timely processing of network requests, improves the data response speed, and thus improves the user experience.

[0061] Technical terms involved in the embodiments of this invention:

[0062] Service Worker: Service worker thread.

[0063] During the initial page loading process, the front-end page typically needs to send multiple HTTP requests to the back-end simultaneously. Due to network or back-end service response issues (ClickHouse has a large latency for some types of requests, such as user profiles), some network requests may become pending or timeout, which can easily cause a blank screen on the front-end and a poor user experience.

[0064] Current technologies employ a caching queue approach, using `reduce` to build a sequential request queue from Promises. This effectively reduces the concurrency of network requests. However, this method requires all requests to return successfully; if one request fails, no subsequent requests are sent, resulting in low efficiency. Furthermore, current technologies have low reliability and fault tolerance. For example, if 100 network requests need to be processed concurrently using a caching queue, these 100 requests are cached and sent sequentially. The page needs to wait for all 100 requests to respond before rendering. Assuming each request takes 0.1 seconds, this would take nearly 10 seconds, causing a blank screen during this period. While existing solutions improve service request response efficiency to some extent regardless of whether the result is successful or failed, they still don't adequately address the issue of large latency in some requests leading to a blank screen.

[0065] To address the technical issue of response timeouts and resulting blank screens caused by high concurrency requests on front-end pages, this invention provides a concurrent request processing method based on service workers. This method intercepts and optimizes concurrent network requests, achieving rapid responses to concurrent network requests and improving the user experience.

[0066] Specifically, refer to Figure 1 , Figure 1 This is a schematic diagram of the functional modules of the terminal device to which the front-end processing device of the present invention belongs. The front-end processing device can be an independent device capable of front-end processing, and it can be carried on the terminal device in hardware or software form. The terminal device can be a smart mobile terminal with data processing capabilities, such as a mobile phone or tablet computer, or it can be a fixed terminal device or server with data processing capabilities.

[0067] In this embodiment, the terminal device to which the front-end processing device belongs includes at least an output module 110, a processor 120, a memory 130, and a communication module 140.

[0068] The memory 130 stores the operating system and front-end processing program. The front-end processing device can store information such as the loading instruction of the front-end page, the network request corresponding to the loading instruction, the pre-stored cached data, the target data, and the access destination domain name corresponding to the network request in the memory 130. The output module 110 can be a display screen, etc. The communication module 140 can include a WIFI module, a mobile communication module, and a Bluetooth module, etc., and communicates with external devices or servers through the communication module 140.

[0069] When the front-end processing program in memory 130 is executed by the processor, it performs the following steps:

[0070] In response to the loading command of the front-end page, the network request corresponding to the loading command is intercepted through the service worker thread;

[0071] If the target data corresponding to the network request does not exist in the pre-stored cached data, the access destination domain name corresponding to the network request is determined based on the adaptive adjustment strategy, and used to initiate a query request to at least one backend node to obtain the target data corresponding to the network request, and to render and display the target data.

[0072] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0073] If the target data corresponding to the network request exists in the pre-stored cache data, then the target data is retrieved from the cache data and rendered and displayed.

[0074] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0075] Determine whether the browser version of the front-end page supports the service worker thread;

[0076] If the browser version of the front-end page supports the service worker thread, then the service worker thread is enabled.

[0077] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0078] Obtain the historical behavior data corresponding to the front-end page;

[0079] The historical behavior data is analyzed to obtain user preference information;

[0080] The data related to the user preference information is stored to obtain the cached data.

[0081] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0082] The cached data is obtained by storing data related to the user preference information at the individual page level; and / or,

[0083] The cached data is obtained by storing data related to the user preference information at the granularity of the data on the page.

[0084] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0085] Based on a pre-trained data change prediction model, a caching configuration is set for at least one data type in the full dataset, and at least one of data storage, data modification, and data deletion is performed based on the caching configuration; and / or,

[0086] The system queries data related to the user preference information at preset intervals to determine if there are any data identifiers indicating changes. If there are data identifiers indicating changes, the system performs at least one of the following actions: data storage, data modification, and data deletion.

[0087] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0088] Acquire pre-collected sample data, wherein the sample data includes at least one of the following: data type, amount of changed data, change time, and business type;

[0089] The sample data is processed to obtain various multidimensional datasets;

[0090] The data change prediction model is obtained by training the model based on the aforementioned multidimensional datasets.

[0091] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0092] In response to the launch command of the initial page corresponding to the full data, the full data is preloaded;

[0093] In response to receiving a data request instruction for the initial page, the corresponding requested data is selected from the loaded full data according to the data request instruction;

[0094] The requested data is sent to the browser's main thread for data rendering and display.

[0095] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0096] If the preference data in the target data exists in pre-stored cached data, then the preference data is retrieved from the cached data and rendered; and / or,

[0097] If there is corresponding initialization data for the non-preferred data in the target data, then the initialization data is called and rendered for display.

[0098] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0099] Based on the original destination domain name of the network request, initiate the network request to at least one backend node; and if the network request fails, change the original destination domain name and initiate the network request again based on the changed domain name; and / or,

[0100] Initiate speed test network requests to each backend node to obtain the speed test results of each backend node, determine the priority of each backend node based on the speed test results, and determine the access destination domain name corresponding to the network request based on the priority of each backend node.

[0101] Furthermore, when the front-end processing program in memory 130 is executed by the processor, it also performs the following steps:

[0102] The network requests are processed in batches and / or encapsulated to obtain processed network requests;

[0103] The processed network request is sent to at least one corresponding backend node.

[0104] This embodiment, through the above-described scheme, specifically responds to the loading instruction of the front-end page by intercepting the network request corresponding to the loading instruction through a service worker thread. If the target data corresponding to the network request does not exist in the pre-stored cached data, an adaptive adjustment strategy is used to determine the access destination domain name corresponding to the network request. This domain name is then used to initiate a query request to at least one back-end node to obtain the target data corresponding to the network request. The target data is then rendered and displayed, achieving timely processing of network requests, improving data response speed, and thus enhancing the user experience.

[0105] Based on, but not limited to, the terminal device architecture described above, embodiments of the method of the present invention are proposed.

[0106] The execution subject of the method in this embodiment can be a front-end processing device or a terminal device, etc. This embodiment takes a front-end processing device as an example.

[0107] Reference Figure 2 , Figure 2 This is a flowchart illustrating an exemplary embodiment of the front-end processing method of the present invention. The front-end processing method includes:

[0108] Step S10: In response to the loading instruction from the front-end page, the network request corresponding to the loading instruction is intercepted by the service worker thread;

[0109] The front-end processing method in this embodiment of the invention is applicable to high-concurrency access scenarios of operator big data to external industry products. It is suitable for industries such as finance, public services, culture and tourism, and transportation. This embodiment of the invention will illustrate its application in a smart finance platform.

[0110] In the front-end display of a smart finance platform, multiple HTTP requests are usually sent to the back-end simultaneously during the initial page loading process, resulting in a heavy processing burden on the browser. In this embodiment of the invention, Service Worker is used to implement the parallel sending of asynchronous network requests to reduce the processing burden on the browser's main thread.

[0111] Optionally, the step of intercepting the network request corresponding to the loading instruction through the service worker thread further includes:

[0112] Determine whether the browser version of the front-end page supports the service worker thread;

[0113] If the browser version of the front-end page supports the service worker thread, then the service worker thread is enabled.

[0114] Specifically, Service Workers are currently supported on mobile devices (Chrome and Safari 11.3 and above on iOS) and PCs (Firefox, Chrome, Opera, etc.). Overall, it can be used on both mobile and PC. When a page loads, the front-end loads static files (e.g., JS, CSS, images, fonts, etc.). These static resource files contain JavaScript. After the JavaScript loads, it checks if the browser's information includes support for Service Workers ('service worker' in the navigator). If not, Service Workers are not enabled; otherwise, they are enabled.

[0115] Alternatively, a Service Worker can be understood as a proxy server between the client and the server. A Service Worker is an existing browser thread, an independent thread separate from the JavaScript main thread. Multiple Service Workers can exist, and they are responsible for triggering computations through network events from registered domains, residing in an independent process. Performing resource-intensive operations within it will not block the main thread. It adds offline caching capabilities to the web worker and implements response interception functionality as a proxy server between the web application (server) and the browser. It can also access the browser's cache and index database. In this embodiment of the invention, based on the inherent functions of Service Workers, high-concurrency network requests in existing technologies have been optimized.

[0116] Optionally, when it is determined that the browser supports Service Workers, the Service Worker thread can be used to intercept HTTP requests. In this embodiment of the invention, the function of using Service Workers to intercept HTTP / HTTPS requests provides support for subsequent processing steps. Service Workers are services that provide detailed proxying between the browser and the network or cache. Service Workers are registered in the main script file and referenced in a dedicated service worker file, navigator.serviceWorker.register(' / service-worker.js').

[0117] Optionally, starting a Service Worker also incurs some costs, such as slow startup speed. High Service Worker startup costs can reduce the efficiency of some browser pages. In this embodiment of the invention, resource requests in the browser are processed concurrently with Service Worker startup. Because the Service Worker is an independent thread separate from the browser's main thread, this allows for parallel processing with the browser's main thread (resource requests). The requests are then processed through the Service Worker, thereby reducing the impact of Service Worker startup to some extent.

[0118] Step S20: If the target data corresponding to the network request does not exist in the pre-stored cached data, then the access destination domain name corresponding to the network request is determined based on the adaptive adjustment strategy, which is used to initiate a query request to at least one backend node to obtain the target data corresponding to the network request, and to render and display the target data.

[0119] Optionally, after intercepting HTTP requests through the Service Worker thread and comparing the cache with the front-end query parameters, if it is determined that the target data corresponding to the network request does not exist in the pre-stored cache data, the network request can be initiated normally. During the network request process, if there are multiple external web service proxies on the server backend, speed test network requests can be initiated to multiple external web service proxies, and then the server with the fastest response speed can be selected to initiate the network request based on the speed test results; alternatively, if the network request fails, the access destination domain name can be changed, and then the network request can be initiated based on the changed access destination domain name to obtain the target data responded by the server and render and display it.

[0120] In this embodiment, in response to the loading instruction of the front-end page, the network request corresponding to the loading instruction is intercepted by a service worker thread. If the target data corresponding to the network request does not exist in the pre-stored cached data, the access destination domain name corresponding to the network request is determined based on an adaptive adjustment strategy. This domain name is then used to initiate a query request to at least one backend node to obtain the target data corresponding to the network request. The target data is then rendered and displayed. By intercepting the network request through the service worker thread and optimizing the network request for which the target data does not exist in the pre-stored cached data based on the adaptive adjustment strategy, the target data corresponding to the network request is obtained and rendered and displayed by the backend node. This achieves timely processing of network requests, improves the data response speed, and thus improves the user experience.

[0121] Reference Figure 3 , Figure 3This is a flowchart illustrating another exemplary embodiment of the front-end processing method of the present invention. Based on the above... Figure 2 In the embodiment shown, the front-end processing method further includes:

[0122] Step S30: If the target data corresponding to the network request exists in the pre-stored cache data, then the target data is retrieved from the cache data and rendered and displayed.

[0123] Furthermore, after intercepting HTTP requests through the Service Worker thread, the cache can be compared and queried based on the front-end query parameters, and a response can be generated.

[0124] Optionally, to reduce the pressure on the server from concurrent requests, the data query service is cached in this embodiment of the invention. User preference information is primarily obtained by analyzing historical behavior data. The acquisition of user preferences is similar to the data mining model of existing recommendation systems, and relevant algorithms from recommendation systems can also be applied to this embodiment, such as collaborative filtering algorithms. A Service Worker can be used to send network requests to obtain all data related to user preferences.

[0125] Optionally, during the use of the front-end page of the smart finance platform, the query conditions are usually changed, and the response data is visualized in the form of heatmaps, bar charts, pie charts, etc. Each time the query conditions are changed, a new query request needs to be sent to the ClickHouse database, which puts a lot of pressure on backend resources. Moreover, there is redundancy between multiple requests, and the data is not effectively reused.

[0126] For example, if a user selects active user data from Chengdu Wuhou District, the Service Worker intercepts the query request and performs a filter query on the local IndexedDB based on the filter criteria for active users from Chengdu Wuhou District. The browser's JavaScript checks if the data is included in the browser's cache. If it is, the cached data (e.g., IndexedDB data) is directly returned to the browser's main thread via PostMessage and rendered on the front-end page. If it is not, a normal network request is initiated, and after a normal response, the response data is stored in IndexedDB.

[0127] Optionally, before the step of retrieving the target data from the cached data and rendering it if the target data corresponding to the network request exists in pre-stored cached data, the method further includes:

[0128] Obtain the historical behavior data corresponding to the front-end page;

[0129] The historical behavior data is analyzed to obtain user preference information;

[0130] The data related to the user preference information is stored to obtain the cached data.

[0131] It should be noted that step designations such as S20 and S30 are used in the embodiments of the present invention for the purpose of more clearly and concisely describing the corresponding content, and do not constitute a substantial limitation on the order. In specific implementation, those skilled in the art may execute S30 first and then S20, etc., but these should all be within the protection scope of this application.

[0132] Reference Figure 4 , Figure 4 This is a schematic diagram illustrating the principle of cached data comparison in an embodiment of the present invention, such as... Figure 4 As shown, a typical front-end page may include multiple network requests. Each network request consists of an API interface URL and request parameters. In IndexedDB, cached data is stored using the hash value corresponding to the interface URL as the storage key (e.g., 5279d70779d9de9b2c4efd7e8a32ba19). Different request parameters are hashed and used as storage keys, stored as a JSON array in the value corresponding to the key 5279d70779d9de9b2c4efd7e8a32ba19. When the browser checks whether it contains cached data for a certain request, it queries whether id1 contains the corresponding key based on the current URL. If the key is found, it queries the hash value id2 of the network request parameters to check if the corresponding key exists in the JSON array. If the corresponding key exists, the value corresponding to that key is returned to the front-end page for rendering.

[0133] Optionally, cached data can usually be selected or determined based on user preference information. Therefore, historical behavior data corresponding to the front-end page can be obtained first, and then the historical behavior data can be analyzed to obtain user preference information.

[0134] Optionally, user preference information is provided by the server, based on the analysis of historical behavioral data during the user's page browsing process. User preference information can be requested from the server periodically, for example, once every half month. User preference information is generated as a feature profile of the user after big data analyzes the user's click events and historical orders during the user's use of the App. This user profile also reflects the user's preferences. Network preferences can be associated with data type, data request interface, and data display method. By obtaining this association, the browser can combine the current user's ID and user feature profile to know the page, data type, and data style that the user prefers to query, and then silently request and cache the corresponding data in advance.

[0135] Optionally, in this embodiment of the invention, the acquisition of user preferences is similar to the data mining model of existing recommendation systems, and relevant algorithms of recommendation systems can also be applied to this embodiment, such as through collaborative filtering algorithms. A Service Worker can be used to send network requests to obtain full data related to user preferences.

[0136] Optionally, in this embodiment of the invention, the full amount of data related to user preferences can be represented by two granularities: 1) at the granularity of a single page, that is, the response data of multiple network requests for the entire page whose user preferences are being judged are cached, such as the user information table, user payment records and other data (which may correspond to multiple network request interfaces) in the user details page are all cached; 2) at the granularity of data in the page, that is, the response data of the API interface corresponding to the data item whose user preferences are being judged are cached, such as the user payment records (corresponding to the payment record query interface) in the user details page are cached.

[0137] This embodiment, through the above-described scheme, specifically obtains historical behavior data corresponding to the front-end page; analyzes the historical behavior data to obtain user preference information; and stores data related to the user preference information to obtain cached data. This achieves pre-storage of user preference data, enabling timely response to user network requests, thereby improving data response speed and enhancing the user experience.

[0138] Reference Figure 5 , Figure 5 for Figure 3 A schematic diagram of the specific process of step S03 in this embodiment. This embodiment is based on any of the above embodiments. In this embodiment, step S03 includes:

[0139] Step S031: Store the data related to the user preference information at the granularity of a single page to obtain the cached data;

[0140] Specifically, using a single page as the granularity means caching the response data of multiple network requests for the entire page whose user preferences are being judged. For example, multiple data items (which may correspond to multiple network request interfaces) in the user details page, such as the user information table and user payment records, are all cached.

[0141] Optionally, when using pages as the data caching granularity, the Service Worker pre-caches the response data of all network requests involved in the page and sets the cache validity period. Within the validity period, network requests can be responded to using locally cached data. Only when the user manually deletes the cache or manually refreshes the page will a network request be sent to the server to request the latest data and cache it.

[0142] Step S032: Using the data in the page as the granularity, store the data related to the user preference information to obtain the cached data.

[0143] Optionally, using data on the page as the granularity refers to caching the response data of the API interface corresponding to the user preference data item being judged, such as caching the user's payment records (corresponding to the payment record query interface) on the user details page.

[0144] Optionally, the target data includes preferred data and / or non-preferred data. The step of retrieving the target data from the cached data and rendering it if the target data corresponding to the network request exists in pre-stored cached data includes:

[0145] If the preference data in the target data exists in pre-stored cached data, then the preference data is retrieved from the cached data and rendered; and / or,

[0146] If there is corresponding initialization data for the non-preferred data in the target data, then the initialization data is called and rendered for display.

[0147] Specifically, when using API interfaces as the caching granularity, the full set of user preference-related data pre-cached via Service Worker might be only a portion of a page's data. For example, a page might have eight data segments, with seven of them related to user preferences. Therefore, the Service Worker can cache this data. After a ServiceWorker intercepts a user request, it renders and displays most of the page data by looking up the local cache. This allows the ServiceWorker to quickly display the most relevant data to the user, while other data network requests are processed and responded to normally. Furthermore, in some cases, users expect the page to display all data immediately upon opening, avoiding a blank screen. It's important to note that page rendering requires all data requests to be processed and responded to. During this period, the page may display a blank screen or a loading state. Therefore, the optimal approach is to cache and respond to all data within the same page. For API-level caching, preferred data is intercepted and responded to normally, while non-preferred data can be handled using fallback data. This fallback data is equivalent to the page's initialization data, i.e., the initialization data for specific variables in JS scripts, Vue components, and React component files—a pre-processing at the code development level. (See reference...) Figure 6 , Figure 6 This is a schematic diagram illustrating code initialization in an embodiment of the present invention, such as... Figure 6 As shown, initializing the display data variables in the code can solve the white screen problem caused by non-preferred data.

[0148] Optionally, the step of storing data related to the user preference information at the granularity of the data on the page to obtain the cached data includes:

[0149] Based on a pre-trained data change prediction model, a caching configuration is set for at least one data type in the full dataset, and at least one of data storage, data modification, and data deletion is performed based on the caching configuration; and / or,

[0150] The system queries data related to the user preference information at preset intervals to determine if there are any data identifiers indicating changes. If there are data identifiers indicating changes, the system performs at least one of the following actions: data storage, data modification, and data deletion.

[0151] Specifically, in order to ensure that the data displayed on the page is as consistent as possible with the actual data on the server side and to guarantee the real-time performance of the application data, two methods are used to process the effective cache time of the data, including: 1. Based on the data change situation, predict the change time of data from different interfaces, and set different effective cache times for data from different interfaces using preset values; 2. Request user preference data every certain period of time, for example, every half hour. In addition to the data that the user prefers to view, the user preference data also includes an indicator of whether each piece of data has changed. When the server performs update or insert operations on the corresponding data table, it will set the data accordingly to indicate that the data has changed.

[0152] Optionally, different cache times are set for different types of data. In existing technologies, cache settings are mostly based on the developer's experience or set fixed cache times. Sometimes, these settings are not accurate enough. For example, setting the cache time too long can lead to technical problems such as untimely data updates, causing the front end to be unable to obtain the latest data in a timely manner. On the other hand, setting the cache time too short can lead to frequent cache updates, which will increase network requests and traffic, defeating the purpose of caching and resulting in low cache utilization. The system does not implement cache time settings based on the data change characteristics (e.g., location data and call data are frequently updated data, while user attribute information is low-frequency changing data). After the server predicts the frequency of data changes, it can set corresponding cache time thresholds for different types of data. After the browser obtains this time threshold and stores it in local storage, each time the browser opens the browser, it will compare whether the cache time threshold of different data is exceeded. If it is exceeded, the cache of the specific data will be deleted and retrieved again through Service Worker.

[0153] Optionally, before the step of setting the caching configuration for at least one data type in the full dataset based on the pre-trained data change prediction model, the method further includes:

[0154] Acquire pre-collected sample data, wherein the sample data includes at least one of the following: data type, amount of changed data, change time, and business type;

[0155] The sample data is processed to obtain various multidimensional datasets;

[0156] The data change prediction model is obtained by training the model based on the aforementioned multidimensional datasets.

[0157] Reference Figure 7 , Figure 7 This is a schematic diagram of the regression prediction process in an embodiment of the present invention, such as... Figure 7As shown, when data changes, a script collects data such as data type, amount of changed data, change time, and business type corresponding to each data point, and stores this data in the database. After processing the collected data, the Xgboost algorithm is applied to predict the next change interval for each dataset. Based on whether the data is newly added in the current period, whether the data has changed in the current period, and the next change interval predicted by the Xgboost algorithm, a cache configuration is set for each data point. Here, the dataset corresponds to the interface. Different front-end modules request URLs + request parameters corresponding to different datasets. For example, ` / api / v2 / user_data? id=1034`, where ` / api / v2 / user_data` is the request path, and `id=1034` is the request parameter id equal to 1034. This request corresponds to a dataset described in this solution. Of course, due to different query conditions, there may be inclusion, being included, or partial overlap between datasets.

[0158] Optionally, data collection can be periodic (e.g., every 5 or 10 days). Scripts collect data types, change data volume (number of data entries), change time, and business type (application type). The SHA1 hash algorithm is used to calculate the hash value of each dataset based on its content, and the data is stored in the database. The collected data is then processed, primarily involving updating the "new" and "changed" flags for each data point in each version. For each data point: if the data did not exist at the previous time point, it is considered a new data point, with a "new" value of 1 and a "changed" value of 1; if the same data existed at the previous time point (same relative path and name), the "new" value is 0. Additionally, the hash value of the current version of the data is compared with the hash value of the previous version. If the values ​​are the same, the data is considered unchanged, with a "changed" value of 0; otherwise, it is 1.

[0159] Optionally, for the data at each historical point in time, filter out the newly added or modified data; calculate which version of the data it is in this version, how many days since the data was first launched before it was modified, and the time interval between the data and the next modification (if a certain data has not been modified since a certain historical version, it is assumed that its latest version has been modified).

[0160] Optionally, based on the collected data, the Xgboost algorithm can be applied to predict the time interval for the next data change.

[0161] Optionally, after the above process, a multidimensional dataset can be obtained for each dataset, including: data type, amount of changed data (number of data entries), change time, business type (application type), and data change time. The first four metrics are the model's X variables, and the fifth metric is the Y variable, used to train the Xgboost model and tune parameters to optimize model performance.

[0162] Optionally, by applying the trained model, the predicted time interval for the next change of each dataset in the current period can be given, and the data caching configuration (e.g., caching time) can be set based on the predicted change cycle of each data.

[0163] Optionally, after the step of storing the data related to the user preference information to obtain the cached data, the method further includes:

[0164] In response to the launch command of the initial page corresponding to the full data, the full data is preloaded;

[0165] In response to receiving a data request instruction for the initial page, the corresponding requested data is selected from the loaded full data according to the data request instruction;

[0166] The requested data is sent to the browser's main thread for data rendering and display.

[0167] Specifically, user preference information can be cached for a period of time after being obtained. When a user opens the page, a network request is sent via a Service Worker thread to retrieve all data related to the user preferences for caching. This data is then communicated with the UI layer via the PostMessage method. Upon receiving the response data, the UI layer renders DOM elements in real time to display the data. This step fully utilizes the independent operation of Service Workers to achieve data preloading. When a user subsequently opens the page, as long as the previously cached preference data is still valid, the cached data can be directly sent to the browser's main thread for rendering. For example, in the financial panorama platform of this invention, data sources that users frequently view can be obtained first. When a user opens a page, the Service Worker is activated and sends a data request to the website server. This process is completely imperceptible to the user. When the user needs to view a page of interest, the backend data has already been obtained and cached by the Service Worker. The user can simply click on the data to view the page and the cached data of interest will be returned. Unlike existing technologies, the browser's main thread does not need to wait for a data request response and can immediately render and display the data, shortening the rendering latency, reducing the probability of a blank screen on the client, and greatly improving the user experience of using the web application. At the same time, it also reduces the concurrent pressure on the backend server. Furthermore, the data obtained from the pre-cached data of the Service Worker for page rendering is data of interest related to the user's preferences. Thus, the page data of interest to the user can be quickly rendered and displayed to the user, further improving the user experience.

[0168] This embodiment, through the above-described scheme, specifically stores the user preference information-related data at the granularity of a single page to obtain the cached data; and / or, stores the user preference information-related data at the granularity of data within a page to obtain the cached data. By performing a full request covering most scenarios when the page is opened, the response data of this request is cached and stored in IndexedDB for reuse under various subsequent query conditions. Furthermore, data caching is configured using a pre-trained data change prediction model, allowing for fine-grained processing of data caching time settings. This enables effective management of caching time while saving network resources. Preloading the cached data further improves data response speed and enhances the user experience.

[0169] Reference Figure 8 , Figure 8 for Figure 2A schematic flowchart of step S30 in this embodiment. This embodiment is based on any of the above embodiments, and in this embodiment, step S30 includes at least one of the following:

[0170] Step S301: Based on the original destination domain name of the network request, initiate the network request to at least one backend node; if the network request fails, change the original destination domain name and initiate the network request again based on the changed domain name.

[0171] Specifically, the Service Worker intercepts HTTP requests and compares the cache with the front-end query parameters. If it is determined that the target data corresponding to the network request does not exist in the pre-stored cache data, the network request can be initiated normally. During the network request process, a network request can be initiated to at least one backend node based on the original destination domain name of the network request. If the network request fails, the destination domain name can be changed, and then a network request can be initiated based on the changed destination domain name to obtain the target data responded by the server and render and display it.

[0172] Step S302: Initiate a speed test network request to each backend node to obtain the speed test results of each backend node, determine the priority of each backend node based on the speed test results, and determine the access destination domain name corresponding to the network request based on the priority of each backend node.

[0173] Optionally, when there are multiple external web service proxies in the server backend, one of the web service proxies can be selected to initiate the network request. This selection can be achieved by using a Service Worker to initiate speed test network requests to multiple external web service proxies when the page starts, recording the time interval between each server's 200 OK response as the speed test result, and selecting the server with the fastest response time to initiate subsequent data network requests. In other words, by intercepting changes to the access domain name, load balancing can be achieved at the front-end (client-side) level through a Service Worker. Specifically, in the first request upon page startup, the Service Worker thread can modify the destination domain name of the intercepted request, thus initiating query requests to multiple backend nodes (each node corresponding to a node in the ClickHouse distributed cluster).

[0174] Reference Figure 9 , Figure 9 This is a schematic diagram illustrating a network request example in an embodiment of the present invention, such as... Figure 9As shown, there are 5 requests in total. Requests 1-2 can be sent to the first server, request 3 can be sent to the second server, and requests 4-5 can be sent to the third server. This is equivalent to implementing load balancing, eliminating the need for backend servers to perform load balancing and distribution. The requests are directly distributed through the frontend JS script, which effectively reduces the data query pressure on the backend servers. Furthermore, the Service Worker selects and distributes requests to servers with faster response times based on speed testing, ensuring that the requested data can be obtained quickly and improving request efficiency.

[0175] Optionally, the step of initiating a query request to at least one backend node includes:

[0176] The network requests are processed in batches and / or encapsulated to obtain processed network requests;

[0177] The processed network request is sent to at least one corresponding backend node.

[0178] Specifically, in this embodiment of the invention, concurrent requests can also be sent in batches, for example, 100 requests can be sent in 10 batches to reduce concurrency; or, multiple network requests can be encapsulated into one network request to reduce the number of network requests, thereby optimizing the network request method.

[0179] Furthermore, embodiments of the present invention also propose a front-end processing device, the front-end processing device comprising:

[0180] The interception module is used to intercept network requests corresponding to the loading instructions of the front-end page through the service worker thread.

[0181] If the target data corresponding to the network request exists in the pre-stored cached data, the calling module is used to call the target data and render and display it.

[0182] The initiating module, if the target data corresponding to the network request does not exist in the pre-stored cached data, is used to determine the access destination domain name corresponding to the network request based on the adaptive adjustment strategy, and to initiate a query request to at least one backend node to obtain the target data corresponding to the network request, and to render and display the target data.

[0183] To address the technical issue of response timeouts and resulting blank screens caused by high-concurrency requests on front-end pages, this invention provides a front-end processing method based on multi-threaded concurrent request handling. This method intercepts and optimizes concurrent network requests, achieving rapid responses and effectively improving the access performance of existing platform front-ends, thus enhancing user experience. For data application front-end pages, this is a relatively basic patented technology. Existing technologies often use a uniform setting without distinguishing data types. The method in this invention sets a longer cache time (e.g., 6 months) for data with low change frequency (e.g., user age, gender, activity region, etc.) and a shorter cache time for data with even lower change frequency. This effectively reduces unnecessary network data transmission, significantly saving related costs and demonstrating high practical application value.

[0184] The principle and implementation process of front-end processing in this embodiment are explained in the above embodiments and will not be repeated here.

[0185] Furthermore, this embodiment of the invention also proposes a terminal device, which includes a memory, a processor, and a front-end processing program stored in the memory and executable on the processor. When the front-end processing program is executed by the processor, it implements the steps of the front-end processing method described above.

[0186] Since this front-end processing program adopts all the technical solutions of all the foregoing embodiments when it is executed by the processor, it has at least all the beneficial effects brought about by all the technical solutions of all the foregoing embodiments, which will not be described in detail here.

[0187] Furthermore, embodiments of the present invention also propose a computer-readable storage medium storing a front-end processing program, which, when executed by a processor, implements the steps of the front-end processing method described above.

[0188] Since this front-end processing program adopts all the technical solutions of all the foregoing embodiments when it is executed by the processor, it has at least all the beneficial effects brought about by all the technical solutions of all the foregoing embodiments, which will not be described in detail here.

[0189] Compared to existing technologies, the front-end processing method, apparatus, terminal device, and storage medium proposed in this invention, in response to a front-end page loading instruction, intercept the network request corresponding to the loading instruction through a service worker thread. If the target data corresponding to the network request does not exist in pre-stored cached data, an adaptive adjustment strategy is used to determine the access destination domain name corresponding to the network request, which is then used to initiate a query request to at least one backend node to obtain the target data corresponding to the network request. The target data is then rendered and displayed. By intercepting network requests through a service worker thread and optimizing network requests where the target data does not exist in pre-stored cached data based on an adaptive adjustment strategy, the target data corresponding to the network request is obtained and rendered and displayed through the backend node. This achieves timely processing of network requests, improves data response speed, and thus enhances the user experience.

[0190] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0191] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0192] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, controlled terminal, or network device, etc.) to execute the methods of each embodiment of this application.

[0193] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A front-end processing method, characterized in that, The front-end processing method includes the following steps: In response to the loading command of the front-end page, the network request corresponding to the loading command is intercepted through the service worker thread; If the target data corresponding to the network request does not exist in the pre-stored cached data, the access destination domain name corresponding to the network request is determined based on the adaptive adjustment strategy, which is used to initiate a query request to at least one backend node to obtain the target data corresponding to the network request, and to render and display the target data. The startup process of the service worker thread is parallel to the resource request process of the browser's main thread. The cached data is selected or determined based on user preference information; The full set of data related to user preferences is represented at the granularity of a single page and / or at the granularity of the data within a page; the granularity of a single page means that the response data of multiple network requests for the entire page whose user preferences are being judged are cached; the granularity of the data within a page means that the response data of the API interface corresponding to the data item whose user preferences are being judged are cached. Different types of data are set with different caching times; the caching time is set based on the predicted value of the data change time and the identifier of whether each data in the periodically collected user preference data has changed.

2. The front-end processing method as described in claim 1, characterized in that, Following the step of intercepting the network request corresponding to the loading instruction via a service worker thread in response to the loading instruction from the front-end page, the method further includes: If the target data corresponding to the network request exists in the pre-stored cache data, then the target data is retrieved from the cache data and rendered and displayed.

3. The front-end processing method as described in claim 1, characterized in that, Before the step of intercepting the network request corresponding to the loading instruction through the service worker thread, the following is also included: Determine whether the browser version of the front-end page supports the service worker thread; If the browser version of the front-end page supports the service worker thread, then the service worker thread is enabled.

4. The front-end processing method as described in claim 2, characterized in that, The step of retrieving the target data corresponding to the network request and rendering it before retrieving the target data from the cached data if the target data exists in the pre-stored cached data includes: Obtain the historical behavior data corresponding to the front-end page; The historical behavior data is analyzed to obtain user preference information; The data related to the user preference information is stored to obtain the cached data.

5. The front-end processing method as described in claim 4, characterized in that, The step of storing the data related to the user preference information to obtain the cached data includes: The cached data is obtained by storing data related to the user preference information at the individual page level; and / or, The cached data is obtained by storing data related to the user preference information at the granularity of the data on the page.

6. The front-end processing method as described in claim 5, characterized in that, The step of storing data related to user preference information at the granularity of data on the page to obtain the cached data includes: Based on a pre-trained data change prediction model, a caching configuration is set for at least one data type in the full dataset, and at least one of data storage, data modification, and data deletion is performed based on the caching configuration; and / or, The system queries data related to the user preference information at preset intervals to determine if there are any data identifiers indicating changes. If there are data identifiers indicating changes, the system performs at least one of the following actions: data storage, data modification, and data deletion.

7. The front-end processing method as described in claim 6, characterized in that, Before the step of setting a cache configuration for at least one data type in the full dataset based on the pre-trained data change prediction model, the method further includes: Acquire pre-collected sample data, wherein the sample data includes at least one of the following: data type, amount of changed data, change time, and business type; The sample data is processed to obtain various multidimensional datasets; The data change prediction model is obtained by training the model based on the aforementioned multidimensional datasets.

8. The front-end processing method as described in claim 6, characterized in that, After the step of storing the data related to the user preference information to obtain the cached data, the method further includes: In response to the launch command of the initial page corresponding to the full data, the full data is preloaded; In response to receiving a data request instruction for the initial page, the corresponding requested data is selected from the loaded full data according to the data request instruction; The requested data is sent to the browser's main thread for data rendering and display.

9. The front-end processing method as described in claim 2, characterized in that, The target data includes preferred data and / or non-preferred data. If the target data corresponding to the network request exists in pre-stored cached data, the step of retrieving the target data from the cached data and rendering it includes: If the preference data in the target data exists in pre-stored cached data, then the preference data is retrieved from the cached data and rendered; and / or, If there is corresponding initialization data for the non-preferred data in the target data, then the initialization data is called and rendered for display.

10. The front-end processing method as described in claim 1, characterized in that, The step of determining the destination domain name corresponding to the network request based on the adaptive adjustment strategy includes: Based on the original destination domain name of the network request, initiate the network request to at least one backend node; and if the network request fails, change the original destination domain name and initiate the network request again based on the changed domain name; and / or, Initiate speed test network requests to each backend node to obtain the speed test results of each backend node, determine the priority of each backend node based on the speed test results, and determine the access destination domain name corresponding to the network request based on the priority of each backend node.

11. The front-end processing method as described in claim 1, characterized in that, The step of initiating a query request to at least one backend node includes: The network requests are processed in batches and / or encapsulated to obtain processed network requests; The processed network request is sent to at least one corresponding backend node.

12. A front-end processing device, characterized in that, The front-end processing device includes: The interception module is used to intercept network requests corresponding to the loading instructions of the front-end page through the service worker thread. The initiating module, if the target data corresponding to the network request does not exist in the pre-stored cached data, is used to determine the access destination domain name corresponding to the network request based on the adaptive adjustment strategy, and to initiate a query request to at least one backend node to obtain the target data corresponding to the network request, and to render and display the target data. The startup process of the service worker thread is parallel to the resource request process of the browser's main thread. The cached data is selected or determined based on user preference information; The full set of data related to user preferences is represented at the granularity of a single page and / or at the granularity of the data within a page; the granularity of a single page means that the response data of multiple network requests for the entire page whose user preferences are being judged are cached; the granularity of the data within a page means that the response data of the API interface corresponding to the data item whose user preferences are being judged are cached. Different types of data are set with different caching times; the caching time is set based on the predicted value of the data change time and the identifier of whether each data in the periodically collected user preference data has changed.

13. A terminal device, characterized in that, The terminal device includes a memory, a processor, and a front-end processing program stored in the memory and executable on the processor. When the front-end processing program is executed by the processor, it implements the steps of the front-end processing method as described in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a front-end processing program, which, when executed by a processor, implements the steps of the front-end processing method as described in any one of claims 1-11.

Citation Information

Patent Citations

  • Domain name configuration management method and device, computer equipment and storage medium

    CN109474459A

  • Concurrent network request processing method and device, equipment and storage medium

    CN116302175A

  • Resource acceleration method and system

    CN116700994A