Page loading method, device, system and storage medium based on micro-frontend framework

Abstract

This application discloses a page loading method, apparatus, system, and storage medium based on a micro-frontend framework, belonging to the field of page loading technology. The method obtains page routing rules and container scheduling rules by pre-setting a micro-frontend base loading and parsing configuration file; it pre-builds and warms up page-bearing container instances to obtain ready-state container instances; the base uniformly intercepts and parses page access requests to obtain page routing information; and it determines the target ready-state container instance based on the matching of routing rules and container scheduling rules, then calls that instance to complete the loading of the business page to be loaded. This application simplifies the loading process and shortens page loading time through unified scheduling, container pre-warming and reuse, and precise rule matching, solving the problems of chaotic, inefficient, and unstable loading in traditional micro-frontends, and is suitable for efficient and stable loading of frontend pages.

Description

Technical Field

[0001] This application belongs to the field of page loading technology, and in particular relates to a page loading method, apparatus, system and storage medium based on a micro front-end framework. Background Technology

[0002] With the rapid iteration of front-end technologies and the large-scale iteration of business systems, micro-frontend frameworks, with their advantages of independent development, independent deployment, and on-demand access, are widely used in large-scale web client (Web) and mobile hybrid business scenarios. Micro-frontend architecture can effectively solve the problems of bloated code, high coupling, and difficult iterative maintenance in monolithic projects, enabling the aggregated management and independent operation of multiple business sub-applications.

[0003] Current mainstream micro-frontend page loading technologies typically involve temporarily retrieving the micro-frontend base, resolving page routes in real time, dynamically creating a page container, and sequentially loading the business page after detecting a page access request. This approach lacks pre-configured parsing and rule-based processes, and fails to define unified page route matching standards and container scheduling criteria. The loading process is cumbersome and redundant, and the sequential execution is time-consuming, directly resulting in slow initial page load speeds and low loading efficiency for micro-frontend pages. Summary of the Invention

[0004] The purpose of this application is to provide a page loading method, device, system, and storage medium based on a micro-frontend framework. By constructing a micro-frontend base, it achieves centralized management of configuration and requests, pre-builds and warms up container instances to reduce the overhead of repeated creation, performs unified parsing and rule matching of page access requests, and schedules ready-state containers to complete page loading based on the matching results, thereby standardizing the micro-frontend page loading process and improving page loading efficiency and operational stability.

[0005] To achieve the above objectives, the solution proposed in this application is: In a first aspect, embodiments of this application provide a page loading method based on a micro-frontend framework, including: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain page routing rules and container scheduling rules; By preheating the base page of the micro-frontend base using at least one page-bearing container instance pre-built on the micro-frontend base, at least one ready container instance is obtained. The micro-frontend base intercepts page access requests and parses them to obtain page routing information. Based on page routing rules and container scheduling rules, determine the target ready container instance that matches the page routing information from at least one ready container instance; Retrieve the target ready container instance and load the business page corresponding to the page access request based on the target ready container instance.

[0006] The method described in the embodiments of this application may also have the following additional technical features: Furthermore, before determining the target ready container instance matching the page routing information from at least one ready container instance based on page routing rules and container scheduling rules, the page loading method also includes: Based on page routing information, determine whether the page access request matches the loading conditions of at least one ready container instance; Based on page routing rules and container scheduling rules, determine the target ready container instance that matches the page routing information from at least one ready container instance, including: If a page access request matches the loading conditions of at least one ready container instance, a target ready container instance matching the page routing information is determined from at least one ready container instance according to the page routing rules and container scheduling rules.

[0007] Furthermore, page loading methods also include: If a page access request does not match the loading conditions of at least one ready container instance, a new page hosting container instance is created through the micro-frontend base, and the business page to be loaded is loaded based on the newly created page hosting container instance.

[0008] Furthermore, before determining the target ready container instance matching the page routing information from at least one ready container instance based on page routing rules and container scheduling rules, the page loading method also includes: A preheating instance reuse pool is built using a micro-frontend base, and at least one ready container instance is placed into the preheating instance reuse pool. Based on page routing rules and container scheduling rules, determine the target ready container instance that matches the page routing information from at least one ready container instance, including: Based on page routing rules and container scheduling rules, a target ready container instance matching the page routing information is determined from the preheated instance reuse pool. Retrieve the target ready container instance, including: Retrieve the target ready container instance from the preheated instance reuse pool.

[0009] Furthermore, page loading methods also include: After the target ready container instance loads the business page to be loaded, the ready container instance is recycled to the preheating instance reuse pool.

[0010] Furthermore, the target ready container instance is in an idle state; the page loading method also includes: The idle target ready container instance performs page pre-rendering for the business page to be loaded.

[0011] Furthermore, page loading methods also include: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain the pre-rendered skeleton; Pre-rendering of the business page to be loaded is performed using an idle target ready container instance, including: When the business page to be loaded is opened, the pre-rendered skeleton is rendered to the target ready container instance in the idle state through the micro frontend base.

[0012] Furthermore, page loading methods also include: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain the page pre-rendering configuration information; Pre-rendering of the business page to be loaded is performed using an idle target ready container instance, including: When the business page to be loaded is opened, the document object structure of the business page to be loaded is dynamically captured and cached based on the page pre-rendering configuration information; When the business page to be loaded is opened again, the cached document object structure is retrieved to pre-render the business page to be loaded; Once the business page to be loaded has finished loading, remove the pre-rendered document object structure, re-capture the document object structure of the current business page to be loaded, and update the cache.

[0013] Furthermore, page loading methods also include: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain the backup domain name configuration information, which includes at least one backup domain name. Page loading methods also include: Detect the loading process of the business page to be loaded based on the target ready container instance; When an error occurs during the loading process, the system switches to an alternate domain name via the micro-frontend base. The pending business page is reloaded on the ready container instance using an alternate domain name.

[0014] Furthermore, page loading methods also include: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain performance optimization configuration information, which includes business data. Page loading methods also include: During the loading phase of the business page to be loaded, the page pre-rendering and business data pre-request are performed in parallel through idle ready container instances.

[0015] Secondly, embodiments of this application provide a page loading device based on a micro-frontend framework, comprising: The configuration acquisition module is used to load and parse the preset configuration file based on the preset micro-frontend base to obtain the page routing rules and container scheduling rules; The container preheating module is used to preheat the base page of the micro-frontend base by carrying the container instance through at least one page pre-built based on the micro-frontend base, so as to obtain at least one ready container instance. The page parsing module is used to intercept page access requests through the micro-frontend base, parse the page access requests, and obtain page routing information; The container matching module is used to determine the target ready container instance that matches the page routing information from at least one ready container instance, based on page routing rules and container scheduling rules. The page loading module is used to retrieve the target ready container instance and load the business page corresponding to the page access request based on the target ready container instance.

[0016] Thirdly, embodiments of this application provide a page loading system based on a micro-frontend framework. The system includes a processor and a memory. The memory stores a computer program, which is loaded and executed by the processor to implement the page loading method based on a micro-frontend framework provided in the first aspect of embodiments of this application.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it is used to implement a page loading method based on a micro-frontend framework provided in the first aspect of embodiments of this application.

[0018] The page loading method based on a micro-frontend framework provided in this application has the following advantages compared with the prior art: This application embodiment preloads and parses configuration files through a micro-frontend base to uniformly generate page routing rules and container scheduling rules, constructing a globally unified standardized scheduling basis. Compared to the traditional ruleless and random page loading mode, this application embodiment achieves standardized and normalized control over page routing matching and container resource scheduling, completely solving the technical problems of chaotic page loading strategies, fragmented scheduling logic, and lack of unified execution standards in traditional micro-frontends, thus improving the regularity and controllability of micro-frontend page loading.

[0019] This application embodiment pre-constructs at least one page-hosting container instance and completes the base page preheating, thereby obtaining a ready-to-load container instance in advance and completing the pre-preparation of container resources and the runtime environment. Unlike the passive mode of traditional technologies that create and initialize containers only after a request is triggered, this effectively eliminates the lengthy time required for container creation and environment initialization during page access, shortening the pre-loading time at the carrier level and avoiding the loading delay problem caused by real-time container creation.

[0020] This application embodiment intercepts and parses page access requests through a unified base to obtain page routing information. Combined with preset page routing rules and container scheduling rules, it accurately matches and obtains the target ready container instance that best suits the current access requirements. By relying on page routing rules and container scheduling rules to achieve a precise correspondence between routing information and container resources, it solves the shortcomings of traditional technologies, such as the lack of unified rules, disordered scheduling, and chaotic matching, significantly improving the accuracy and standardization of page loading scheduling.

[0021] This application embodiment achieves rapid loading and rendering of the business page by invoking the matched target ready container instance to load the business page. The overall process eliminates the drawbacks of traditional serial loading, significantly shortens the first screen loading time of the micro-frontend page, optimizes the user page access experience, and effectively improves the overall efficiency of micro-frontend page loading and system operation stability, making it better suited for high-concurrency and high-frequency micro-frontend business access scenarios. Attached Figure Description

[0022] Figure 1 A flowchart illustrating the page loading method based on a micro-frontend framework according to an embodiment of this application is shown. Figure 2 This illustration shows a schematic diagram of the micro-frontend webpage view warm-up and reuse process according to an embodiment of this application; Figure 3 This paper illustrates a schematic diagram of a dual-path loading process for a web client page according to an embodiment of this application. Figure 4 A schematic diagram of a typical loading timing according to an embodiment of this application is shown; Figure 5 A schematic diagram of the pre-rendering loading timing of an embodiment of this application is shown; Figure 6 This illustration shows a schematic diagram of the interface pre-request loading timing according to an embodiment of this application; Figure 7 A structural block diagram of a page loading device based on a micro-frontend framework according to an embodiment of this application is shown; Figure 8 A structural block diagram of a computer device according to an embodiment of this application is shown. Detailed Implementation

[0023] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, it should be noted that, for ease of description, only the parts relevant to this application are shown in the accompanying drawings, not the entire structure. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application.

[0024] The terms “comprising” and “having”, and any variations thereof, used in this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0025] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0026] Please refer to Figure 1 The present application provides a page loading method based on a micro-frontend framework, comprising the following steps: Step 101: Load and parse the preset configuration file based on the preset micro-frontend base to obtain page routing rules and container scheduling rules.

[0027] The micro-frontend base in this application embodiment is a globally centralized core scheduling carrier for the overall page loading architecture. It builds a globally unified management and control layer independently of the running logic of ordinary business pages. It undertakes the core central role of centralized configuration management, unified request access, page loading scheduling, container instance full lifecycle management, pre-rendering scheduling, loading anomaly disaster recovery and performance optimization coordination, and provides underlying operation support for the subsequent standardized, process-oriented, fault-tolerant and optimizable micro-frontend page loading system.

[0028] Specifically, the underlying runtime framework of the micro-frontend base is first built. Based on industry micro-frontend solutions, it adopts a lightweight data format configuration file (JSON configuration file) to dynamically drive page loading logic. It initializes a global basic runtime instance based on the frontend runtime environment, defines the base's independent runtime scope, and logically isolates it from the runtime environment of ordinary business pages. The base reserves configuration parsing interfaces, page access request listening interfaces, instance scheduling interfaces, rendering scheduling interfaces, exception handling interfaces, and performance optimization scheduling interfaces as a unified access point for subsequent business processes.

[0029] Furthermore, common basic capabilities are built into the micro-frontend base, specifically including: Shared base libraries: The base preloads and globally injects commonly used third-party libraries such as the progressive JavaScript development framework (Vue) and the declarative UI development framework (React). These libraries can be used directly when the page loads without repeated packaging and loading, reducing resource size and avoiding version conflicts. Routing Management: The base station centrally manages global routes, and is responsible for route resolution, historical record updates, and page switching scheduling; State Management: Provides a global state communication mechanism to enable data sharing and message passing between pages; Lifecycle Management: Provides standard lifecycle hooks for page loading, mounting, and unloading, and supports preloading strategies.

[0030] Furthermore, configuration loading and parsing logic is integrated within the micro-frontend base, enabling it to independently load and parse preset configuration files. After the micro-frontend base is initialized and started, it automatically reads the preset configuration files, performs structured parsing of the various configurations fixed in the preset configuration files, and generates page routing rules and container scheduling rules that can be called globally. In this embodiment, page routing rules and container scheduling rules provide a scheduling basis for page loading. After parsing, the rules are globally cached within the micro-frontend base for unified invocation in subsequent request matching, pre-rendering execution, fault tolerance, and performance optimization.

[0031] Furthermore, a page access request listening mechanism is globally mounted on the micro-frontend base, serving as the sole entry point for receiving and parsing all page access requests. All page access requests are uniformly fed into the micro-frontend base, which then performs standardized parsing of request routes, Uniform Resource Locators (URLs), and access characteristics according to preset parsing rules, generating page routing information in a fixed format. This avoids the problems of scattered request processing and inconsistent parsing standards in the original technology, achieving centralized control over all requests.

[0032] Furthermore, the matching rule logic is solidified within the micro-frontend base, matching the aforementioned page routing information with the globally cached page routing rules and container scheduling rules; comparing the page routing information with the page routing rules and container scheduling rules, and using the matching logic to determine the loading strategy based on the route and address, filtering out the container usage method and loading rules that are suitable for the current page access request, providing a decision basis for the scheduling and loading of subsequent business pages to be loaded.

[0033] Furthermore, multiple types of scheduling logic are integrated within the micro-frontend base, including: Pre-rendering scheduling: Supports static and dynamic pre-rendering, completing content rendering before resource loading, basically eliminating white screen; Anomaly recovery scheduling: Real-time monitoring of page loading errors and network failures. When an anomaly occurs, the backup domain configuration information is called, and after switching to the backup domain, the loading is completed again on the container instance, realizing automatic retry and fault self-healing. Performance optimization scheduling: Based on performance optimization configuration information, pre-rendering and business data pre-request are executed in parallel during the page loading phase, so that content and data are ready in advance, significantly shortening the first screen display time.

[0034] Based on the above architecture, the micro-frontend foundation forms a centralized operating architecture that integrates unified configuration parsing, unified request listening and parsing, matching of page routing information with page routing rules, full lifecycle management of container instances, dual-mode pre-rendering scheduling, backup domain disaster recovery for loading anomalies, parallel pre-rendering of idle containers, and pre-requesting of critical data. It standardizes the entire page loading process from the bottom layer, solving the technical pain points of traditional micro-frontend scenarios such as the lack of a unified scheduling core, scattered configurations, non-standard request processing, and lack of standardized control over page loading. It provides underlying architectural support for subsequent standardized page loading, pre-rendering optimization, fault self-healing, and performance improvement.

[0035] After the micro-frontend base is built and the global runtime environment is initialized, the embodiments of this application execute the unified loading and parsing steps of the preset configuration file. The micro-frontend base acts as the sole configuration processing entity, completing the reading, verification, structured parsing and global caching of the configuration file, and finally obtaining the page routing rules and container scheduling rules, providing a unified rule basis for subsequent page routing information matching, container instance scheduling and page loading.

[0036] Specifically, the default configuration file is a structured configuration file based on JSON format, independently configured in the local runtime directory of the micro-frontend base. It is dynamically loaded by the base to drive the page scheduling logic, without relying on separate configurations for external business pages, thus decoupling the configuration and business loading logic at the architectural level. During the startup initialization phase, the micro-frontend base actively triggers the configuration loading logic, automatically reads the local default configuration file, and performs integrity and format checks on the configuration file, filtering out incomplete, abnormally formatted, and invalid configuration data to ensure the validity and accuracy of subsequent page routing rules and container scheduling rules.

[0037] Step 102: By preheating the base page of the micro-frontend base using at least one page-bearing container instance pre-built based on the micro-frontend base, at least one ready-to-use container instance is obtained.

[0038] This application embodiment incorporates management logic for page-hosting container instances within the micro-frontend base, corresponding to the preheating and reuse mechanism of page-hosting container instances. It possesses full lifecycle management capabilities for container instance creation, preheating, inclusion in the reuse pool, idle state detection, scheduling and use, loading and mounting, and recycling and reuse. The base can construct at least one page-hosting container instance before receiving the first page access request. A preheating instance reuse pool can be constructed through the micro-frontend base, placing at least one ready-to-use container instance into the preheating instance reuse pool. Simultaneously, it can detect in real time whether the container instance is in an idle state, providing a usable carrier for subsequent static pre-rendering, dynamic pre-rendering, abnormal switching loading, parallel pre-rendering, and pre-requesting.

[0039] Furthermore, based on the page routing rules and container scheduling rules obtained in step 101, the micro-frontend base can schedule and allocate at least one ready container instance, so that the use of the container instance is accurately matched with the page routing information of the page access request, avoiding waste of container resources and scheduling conflicts.

[0040] Meanwhile, the extended rules such as the backup domain name configuration information and performance optimization configuration information obtained from step 101 can be combined with the loading logic of the ready container instance. Among them, the backup domain name configuration information includes at least one preset backup domain name, which serves as the disaster recovery switching resource address when the page loading is abnormal. It is used to automatically switch links and reload in scenarios such as network failure, domain name resolution failure, and request timeout. The performance optimization configuration information includes business data parameters, which are used to limit the range of core business data that need to be pre-requested during the page loading stage, supporting the performance optimization logic of parallel pre-rendering and pre-requesting in idle containers.

[0041] Step 103: Intercept page access requests through the micro-frontend base and parse the page access requests to obtain page routing information.

[0042] After the micro-frontend base completes initialization, loading and parsing of preset configuration files, and caching of global page routing rules and container scheduling rules, it enters a normalized page access listening and processing state. The micro-frontend base uniformly completes the capture, reception, and standardized parsing of page access requests, constructs a globally unique request processing entry point, and completely replaces the scattered logic of scattered request listening and processing in the traditional micro-frontend architecture, realizing centralized control of all page access behaviors.

[0043] Specifically, during the operation of the front-end page, when a user triggers any page access behavior such as page navigation, page refresh, or opening a new page, a corresponding page access request is automatically generated. In this embodiment, the base intercepts page access requests uniformly, instead of directly creating new page hosting container instances. All page access requests are uniformly aggregated upwards to the micro-frontend base, which uniformly captures and obtains all page access requests, avoiding logical confusion caused by request omissions, duplicate listening, and multi-port processing, and ensuring that all page access behaviors can be globally perceived and uniformly processed.

[0044] After receiving a page access request, the micro-frontend base retrieves the globally cached page routing rules and container scheduling rules to perform structured and standardized parsing of the page access request, abandoning the traditional mode of directly allowing loading of native requests. The micro-frontend base performs multi-dimensional feature decomposition and information extraction on the received page access request. The core parsing content includes, but is not limited to, the current page's access URL, routing path, page resource identifier, whether it is a micro-frontend page, and key feature information such as the business parameters carried in the request.

[0045] The micro-frontend base uses built-in standardized parsing logic to organize, filter, and extract features from raw page access requests. It removes invalid and redundant parameters, illegal characters, and invalid access identifiers from the requests, extracting core, valid information that characterizes the current page loading needs. Finally, it parses page routing information from the page access requests. This page routing information is the core basis for subsequent matching with the page routing rules and container scheduling rules obtained in step 101. It accurately corresponds to the resource requirements and access scenarios of the business page to be loaded, providing precise data support for subsequent rule matching, container instance scheduling, and page loading strategy determination.

[0046] Furthermore, the steps of intercepting page access requests and parsing to obtain page routing information specifically include: intercepting page access requests through the micro-frontend base and extracting page routing information from the page access requests; based on the page routing information, determining whether the page access request meets the loading conditions of at least one ready container instance; if it meets the conditions, retaining the page routing information to enter the subsequent matching process; if it does not meet the conditions, creating a new page hosting container instance through the micro-frontend base and loading the business page to be loaded based on the newly created page hosting container instance.

[0047] Step 104: Based on the page routing rules and container scheduling rules, determine the target ready container instance that matches the page routing information from at least one ready container instance.

[0048] After the micro-frontend base intercepts and parses page access requests and obtains page routing information, and has already obtained page routing rules and container scheduling rules through a preset configuration file, the micro-frontend base performs matching of page routing information with page routing rules and container scheduling rules, and selects the target ready container instance from at least one ready container instance based on the container scheduling rules. This embodiment of the application focuses on the core rule determination and container selection stage of page loading, used to accurately associate the user's actual page access needs with the system's preset standardized routing rules and container scheduling rules, achieving differentiated scheduling based on routing, rules, and container status, avoiding blind loading, container resource waste, and loading conflicts.

[0049] Specifically, the micro-frontend base retrieves page routing rules and container scheduling rules from the global cache in memory. Page routing rules characterize the access paths and loading permissions of each business page, while container scheduling rules characterize the scheduling conditions, usage priorities, and carrying scope of at least one ready container instance. Simultaneously, the micro-frontend base reads the page routing information obtained in step 103, using it as matching input. With page routing as the sole core matching dimension, it compares and correlates each rule with the page routing rules and container scheduling rules.

[0050] The micro-frontend base has a built-in unified rule matching logic. Based on the consistency comparison between page routing information and page routing rules, and combined with the usage conditions of ready container instances defined by container scheduling rules, it selects a target ready container instance from at least one ready container instance that is available, has matching permissions, and suitable carrying capacity. During the matching process, the base determines whether the currently loading business page is allowed to use a ready container instance, and which ready container instance is allowed, based on the page routing information. Finally, it uniquely determines the target ready container instance that matches the page routing information, providing a clear container carrier for subsequent page loading.

[0051] In scenarios where a match is found, the target ready container instance is directly determined without creating a new container. In scenarios where there is no matching container or the scheduling conditions are not met, the base can initiate fallback logic to create a new page-hosting container instance to ensure that page access requests can be responded to and processed normally.

[0052] Furthermore, the micro-frontend base achieves precise alignment of page routing information, page routing rules, and container scheduling rules through multi-dimensional rule validation and container status determination, ultimately obtaining a matching result that includes the target ready container instance, loading method, and scheduling strategy. This matching result clearly defines the target ready container instance used by the currently loading business page, and clarifies the corresponding container invocation method and loading execution strategy, providing a direct execution basis for container scheduling and page loading in step 105.

[0053] Step 105: Retrieve the target ready container instance and load the business page to be loaded corresponding to the page access request based on the target ready container instance.

[0054] After the micro-frontend base determines the target ready container instance that matches the page routing information from at least one ready container instance based on page routing rules and container scheduling rules, the micro-frontend base executes the formal loading process of the business page to be loaded based on the matching result. This embodiment of the application is the core execution link for the final rendering of the page. Relying on the aforementioned unified base architecture, configuration matching rules, and page carrier container instance preheating and reuse mechanism, it abandons the traditional extensive loading mode of direct request loading of front-end pages, no rule control, and no carrier reuse, and realizes a standardized, closed-loop page loading process based on preset rules, relying on the target ready container instance, which is pre-renderable, fault-tolerant, and performance-optimizable.

[0055] Specifically, the micro-frontend base first reads the page loading scheduling rules corresponding to the current matching results to clarify the loading permissions, rendering strategies, disaster recovery strategies, and performance optimization strategies for the business page to be loaded. Based on the scheduling instructions of the matching results, the micro-frontend base triggers the retrieval logic of the preheating instance reuse pool, directly retrieving the determined target ready container instance from the preheating instance reuse pool. This target ready container instance is used as the dedicated carrier for the business page to be loaded, and subsequent page resource mounting, rendering, and display are completed based on this container instance. There is no need to recreate and initialize the page carrier container instance, significantly reducing page startup loading time.

[0056] During page loading, the micro-frontend base monitors the running status of the current target ready container instance in real time. If the target ready container instance is idle, the micro-frontend base synchronously executes pre-optimization logic based on the pre-rendering rules and performance optimization rules in the matching results. Static pre-rendering: When the business page to be loaded is opened, the pre-rendered skeleton is rendered into the idle ready container instance through the micro frontend base; Dynamic pre-rendering: When a business page to be loaded is opened, the document object structure of the business page to be loaded is dynamically captured and cached based on the page pre-rendering configuration information; when the business page to be loaded is opened again, the cached document object structure is called for pre-rendering; the cache is updated after loading is completed. Parallel pre-rendering and pre-requesting: During the loading phase of the business page to be loaded, page pre-rendering and business data pre-requesting are performed in parallel through the target ready container instance in the idle state.

[0057] Furthermore, if the micro-frontend base detects that there are no idle target ready container instances, meaning that all successfully matched target ready container instances are in a occupied running state and cannot perform pre-rendering and data pre-requesting and other pre-optimization operations, the micro-frontend base will maintain the normal loading process of the current page. Based on the target ready container instances in an occupied state, it will orderly complete the entire process of resource retrieval, script execution, page mounting and rendering of the business page to be loaded, ensuring that page access requests can be responded to normally and avoiding page loading blocking and request timeout issues due to the lack of idle containers.

[0058] Meanwhile, the micro-frontend base continuously monitors the running status of each target ready container instance in real time and listens to the execution progress of container tasks. Once it detects that any target ready container instance has completed the current business loading task and switched to the idle ready state, it immediately updates the container status cache and re-includes it in the scope of schedulable resources, providing a usable carrier for subsequent new page access requests, page pre-rendering and performance optimization operations.

[0059] This application's embodiments improve the full-scenario scheduling logic for page loading by providing fallback adaptation for scenarios with no idle containers. This ensures that performance-optimized loading is possible when there are idle containers, while also guaranteeing the stability and continuity of page loading in high-concurrency, multi-page continuous access scenarios when there are no idle containers. It avoids page loading anomalies during peak periods of container resource consumption, thereby improving the overall system's fault tolerance and operational stability.

[0060] Through the above optimizations, the embodiments of this application significantly shorten the user-perceived loading wait time, achieving faster page rendering.

[0061] Meanwhile, the micro-frontend base monitors the loading status of the business page to be loaded on the target ready container instance in real time. When an anomaly occurs during the loading process, the micro-frontend base switches to the backup domain and reloads the business page to be loaded on the target ready container instance through the backup domain, achieving seamless disaster recovery and greatly improving the stability of page loading.

[0062] After the pending business page has completed all resource loading, page rendering, data mounting, and normal display, the micro-frontend base completes the final processing of this page loading process. The micro-frontend base removes the binding relationship between the current business page and the target ready container instance, resets the container's running state, and recycles the target ready container instance to the preheated instance reuse pool. This achieves cyclic reuse of container instances, avoids resource waste and performance loss caused by frequent creation and destruction of containers, and improves the overall system operating efficiency.

[0063] Please refer to Figure 2 This application provides a method for warming up and reusing a WebView in a micro-frontend. This method, through collaboration between the micro-frontend base and the client, enables the pre-creation, background warm-up, and on-demand reuse of the WebView. The overall process is divided into three core stages: App startup initialization, request interception and distribution, and micro-frontend page loading. Specifically, it includes the following steps: Step 201: Execute the application loading process to create a backend webpage view instance and load the micro-frontend basic project; register and listen for relevant application redirection protocols of the webpage client.

[0064] During the app startup initialization phase, the client actively executes the application loading (appLoad) initialization process, completes the creation of the background WebView container, loads the basic resources of the micro-frontend project, and generates a background WebView instance invisible to the user. Through this pre-initialization operation, the micro-frontend runtime environment and basic framework are set up and initialized in advance. At the same time, the client completes the registration and listening configuration of the web-related application redirection protocol (URLScheme), continuously listening for all subsequent web page access requests triggered by the user, providing the pre-conditions for subsequent request interception and fast page loading.

[0065] Step 202: The user triggers a page access request, and the client intercepts and filters the request through the application redirection protocol.

[0066] During the request interception and distribution phase, when a user triggers any page access behavior such as page redirection, page refresh, or opening a new page, the client accurately captures and filters all web-related access requests through a preset URLScheme interception mechanism. This achieves global and unified interception of micro-frontend page access requests, avoiding logical confusion caused by request omissions and scattered request processing, and providing an effective request data source for subsequent page type determination.

[0067] Step 203: Determine if it is a micro-frontend project page.

[0068] The client parses the intercepted web page access requests, extracts the corresponding URL path information, verifies the project attributes of the page to be loaded based on preset project identification rules, distinguishes between ordinary web project pages and micro-frontend project pages, and executes differentiated page loading strategies based on the judgment results.

[0069] Step 204: Obtain the preloaded backend webpage view instance, pass the routing information, and verify the warm-up status.

[0070] If the URL path determines that the currently accessed page is a micro-frontend project page, the client retrieves a pre-loaded WebView instance that has been initialized in advance on the backend, synchronously passes the routing information corresponding to the current page access request to the backend WebView instance, and verifies the preheating status of the instance to provide a basis for subsequent container reuse or fallback creation.

[0071] Step 205: Determine whether preheating is complete.

[0072] The client detects and judges the initialization and warm-up status of the currently obtained backend WebView instance, distinguishes between two states: warm-up complete and incomplete, and executes the corresponding page loading logic according to different warm-up states to ensure the stability and efficiency of micro-frontend page access.

[0073] Step 206: Create a new webpage view instance as a fallback.

[0074] If the verification result shows that the backend WebView instance has not finished warming up and is temporarily unavailable, in order to avoid problems such as page loading failure and page lag, the client immediately creates a new WebView container instance as a backup carrier. The new container completes the loading of subsequent micro-frontend pages, ensuring that page access requests can be responded to normally.

[0075] Step 207: Switch the webpage view instance to the foreground and display it.

[0076] If the verification result shows that the background WebView instance has completed warm-up and is ready for use, the client can directly switch the hidden background WebView instance to the foreground display without having to repeatedly create the container and initialize the runtime environment, thus achieving instant loading of the micro-frontend page.

[0077] Step 208: Reuse the webpage view instance to open the base entry HTML and load the basic framework and configuration information.

[0078] During the micro-frontend page loading phase, the client, relying on the ready WebView instance switched to the foreground, opens the micro-frontend base entry HTML file to complete the loading and initialization of the micro-frontend basic framework. Simultaneously, it loads the system's preset configuration information. The system automatically synchronizes the latest configuration data every preset interval (e.g., 3 minutes) to ensure that page routing rules, container scheduling rules, and other configuration information are updated in real time, guaranteeing the accuracy and timeliness of the page loading strategy.

[0079] Step 209: Listen for route changes and notify the client that the page is ready; fetch page information and obtain preloaded data and page content in parallel.

[0080] After the micro-frontend framework is loaded, it continuously listens for global route change events. When a route switch or page access trigger event is detected, it proactively reports the page readiness status to the client. At the same time, based on the latest configuration information, it proactively retrieves the target page information and completes the pre-loading of data and the acquisition of the core page content in parallel, ensuring that page resources and business data are ready in advance.

[0081] Step 210: Perform page rendering and lifecycle management to display the loaded micro-frontend page to the user.

[0082] Step 211: Create a new webpage view instance and open the page.

[0083] If the URL path indicates that the currently accessed page is not a micro-frontend project page, the client directly creates a new independent WebView container instance, opens the target page address through the newly created WebView instance, and completes the page loading and display using the conventional web page loading method, adapting to the conventional access scenarios of ordinary web pages.

[0084] After the page resources and business data are preloaded, the micro-frontend framework executes standardized page rendering logic and manages the entire lifecycle of the page, completing lifecycle operations such as page mounting, state updates, and anomaly monitoring, and finally displays the loaded micro-frontend business page to the user.

[0085] This application's embodiment completely avoids the performance loss of repeatedly creating and initializing container instances every time a micro-frontend page is opened by using the core mechanism of WebView's backend pre-creation, preheating, and on-demand reuse. Combined with optimization strategies such as timed configuration synchronization and preloading of business data, it significantly shortens the loading time of micro-frontend pages and effectively optimizes the user's page access experience.

[0086] Please refer to Figure 3 This application provides a method for loading web client pages using dual paths. The method includes the following steps: Step 301: Obtain the web client page access request triggered by the user.

[0087] During client-side operation, the system monitors user page actions. When a user triggers page navigation, page refresh, or new page opening, the client captures and generates the corresponding web page access request, which serves as the trigger for subsequent page type identification and page loading scheduling.

[0088] Step 302: Determine if it is a micro-frontend project page.

[0089] After receiving a web page access request, the client extracts the URL path information corresponding to the request, verifies the project type of the currently accessed page through preset project identification rules, determines whether the page to be loaded is a regular web project page or a micro-frontend project page, and enters the corresponding loading branch process based on the judgment result.

[0090] Step 303: Proceed to the normal loading process.

[0091] When the client determines that the page to be loaded is a regular web page, it executes the normal page loading logic and uses the native web page loading method to complete the page display. The specific execution process is as follows: Step 313: Create a webpage view instance and open the target URL.

[0092] The client directly creates a brand new WebView container instance, and redirects to and opens the corresponding target URL based on the address information carried in the page access request, providing an independent page execution carrier for ordinary web pages.

[0093] Step 323: Load the homepage resources.

[0094] After the WebView instance starts, it loads the homepage static resources and business resources of a regular web page. During the domain name resolution stage, it uses the HTTPDNS service to replace the traditional DNS resolution, which effectively reduces the probability of network anomalies such as domain name resolution failure and request timeout, and improves the stability of resource loading.

[0095] Step 333: Determine whether the resource loading was successful.

[0096] The client monitors the WebView's resource loading status in real time, verifies and judges the loading results of the core page resources, and executes different fallback logic for page rendering based on whether the resource loading is successful or not.

[0097] Step 343: After the resources are successfully loaded, inject the JSBridge interface and common scripts into the web page view to facilitate bidirectional communication between JS and the native APP.

[0098] After the homepage resources are fully loaded, the client injects a standardized JSBridge communication interface and a general runtime script into the current WebView environment to establish a two-way data communication channel between the App client and the H5 page, supporting subsequent business interactions, status callbacks, permission calls, and other functions of the page.

[0099] Step 353: Execute the page's JavaScript code and monitor the page rendering status through a white screen detection mechanism.

[0100] After the script injection is completed, WebView parses and executes the page's business JS code normally. At the same time, the H5 side white screen detection mechanism is started to monitor the rendering progress of the Document Object Model (DOM), style loading status and page drawing status in real time, and promptly identify page rendering abnormalities.

[0101] Step 363: Render and display the complete page to the user.

[0102] Once page resources are loaded, scripts are executed, and DOM drawing is complete without any rendering errors, WebView completes the final page rendering and displays a normal, ordinary web business page to the user.

[0103] Step 373: If resource loading fails, display a fallback page for the webpage view.

[0104] If the homepage resource loading times out, links are broken, or resources are missing, the client will directly display a preset WebView fallback page to avoid users seeing a blank page, thus optimizing the user experience during abnormal access.

[0105] Step 304: If the current page is a micro-frontend project page, proceed with the micro-frontend optimization loading process.

[0106] When the client determines that the page to be loaded is a micro-frontend project page, it abandons the traditional coarse loading method of creating a new container and starts a standardized optimized loading process based on preheated container reuse, cache optimization, and fault tolerance, thereby improving the loading speed and stability of micro-frontend pages.

[0107] Step 314: Determine if the client has an available preheating container.

[0108] The client retrieves the container status of the local preheating instance reuse pool, checks whether there is a micro-frontend preheating container that has completed base initialization and is in an idle and ready state, and selects the execution strategy of reuse loading or new container loading based on the container availability status.

[0109] Step 324: If a preheating container is available, reuse the preheating container to load the target business sub-application.

[0110] If an available backend preheating container is detected, the client directly switches the preheating container, which has already completed the micro-frontend base initialization, to the foreground for display, and sends a page loading instruction to the micro-frontend base, notifying the base to load the target business sub-application corresponding to the current request. This eliminates the need to repeatedly create WebView containers and repeatedly initialize the base runtime environment, greatly reducing page startup time.

[0111] Step 334: If no preheating container is available, create a new web view instance and open the base URL.

[0112] If there is no available preheating container, the client creates a new independent WebView container instance and accesses the unified entry URL of the micro-frontend base through the new container to start the micro-frontend base loading process.

[0113] Step 344: Load the micro-frontend basic framework resources and accelerate loading by combining caching and network optimization.

[0114] After WebView starts, it loads the basic framework resources of the micro-frontend base. During the loading process, it integrates HTTPDNS domain name optimization and offline base caching mechanism, prioritizes reading local cached base static resources, and only incrementally pulls and updates resources, which greatly improves the startup and loading speed of the micro-frontend base.

[0115] Step 354: Determine whether the micro-frontend base resources have been loaded successfully.

[0116] The client monitors the loading progress and results of the base framework resources, verifies the integrity and validity of the core base resources, and executes corresponding fallback and initialization logic based on the success or failure of the base resource loading.

[0117] Step 364: After the base resources are successfully loaded, complete the script injection and micro-frontend framework initialization.

[0118] After the base resources are loaded, the client injects a dedicated Bridge interface and a running script into the current WebView, executes the core JS code of the base, and completes the initialization operations such as environment initialization, global variable mounting, and basic capability registration of the overall micro-frontend framework.

[0119] Step 374: Load the target business sub-application on the base and support disaster recovery by retrying with backup domain names.

[0120] After the micro-frontend framework is initialized, the base loads the target business sub-application corresponding to the current access based on the page routing information. During the loading of sub-application resources, the network status and domain name access status are monitored in real time. When the main domain name access fails, it automatically switches to the preset backup domain name for reloading, realizing self-healing of loading failures.

[0121] Step 384: Determine whether the business sub-application has been successfully loaded.

[0122] The base verifies the resource loading, script execution, and page rendering results of the target business sub-application in real time, determines whether the sub-application has been loaded normally, and executes page display or fallback prompt logic based on the loading results.

[0123] Step 3841: When the sub-application loads successfully, render and display the micro-frontend business page.

[0124] If the target business sub-application resources are fully loaded and rendered normally, the base completes page mounting and state rendering, and displays the final micro-frontend business page to the user.

[0125] Step 3842: If the sub-application fails to load, display the base fallback page.

[0126] If a business sub-application encounters issues such as resource shortages, rendering errors, or interface anomalies, the system displays a dedicated fallback page for the micro-frontend base, replacing the blank error page and improving the fault tolerance of the micro-frontend page.

[0127] Step 394: If the base resource fails to load, display the fallback page of the webpage view.

[0128] If the core framework of the micro-frontend fails to load resources, times out, or encounters resource errors, the WebView fallback page will be displayed directly to avoid the problem of displaying a blank page and ensure the basic user experience of the page.

[0129] This application's embodiments solve the problems of repeated initialization, long loading time, and lack of fallback for traditional micro-frontend pages by preheating container reuse, HTTPDNS network optimization, offline caching acceleration, and a multi-level page fallback disaster recovery mechanism, effectively improving the loading efficiency and operational stability of micro-frontend pages.

[0130] Please refer to Figures 4 to 6 The diagram illustrates three loading timing sequences provided in this application embodiment, visually demonstrating the improvement effects of different optimization strategies on the first-screen loading performance of the page. The horizontal axis represents the direction of time progression, executing each loading stage sequentially from left to right, with each rectangle representing the execution period of a critical task.

[0131] For details, please refer to Figure 4 This is a schematic diagram of the normal loading timing provided in the embodiments of this application. The normal loading process is the native page loading logic without pre-optimization. All loading tasks are executed serially in a strict fixed order. The subsequent task can only start after the preceding task has been completely executed. There are no parallel execution steps in the whole process.

[0132] In the normal loading process, the base loading and project configuration loading tasks are executed first. After the project configuration is loaded, the project resource loading task is started. After the project resources are loaded, the project initialization and interface call tasks are executed in sequence. After the interface call task is completed, the project rendering begins. Only after the project rendering is completed does the Largest Contentful Paint (LCP) element rendering task start, and finally the first screen of the page is loaded.

[0133] The process has a strong time-series dependency. Interface calls and rendering of key content on the first screen are all executed after the project rendering steps. All time-consuming steps are stacked and blocked at each level, resulting in a long overall loading cycle, a delay in the completion of the first screen rendering, and a long waiting time for the user page.

[0134] Please refer to Figure 5 This is a schematic diagram of the pre-rendering loading sequence provided in the embodiments of this application. The pre-rendering loading process optimizes the rendering sequence of the first screen based on the ordinary serial loading process, breaking the timing restriction that LCP element rendering can only be performed after the project rendering is completed in the original process.

[0135] The execution sequence of the initial base loading, project configuration loading, project resource loading, and project initialization is consistent with the normal loading process. The difference is that during the project resource loading execution period, the first screen's largest content rendering task is started in advance, so that the LCP element rendering step and the project initialization step overlap in time and are executed in parallel. However, the interface call and the regular project rendering task are still executed sequentially according to the original serial sequence.

[0136] This optimization method allows for the rendering of key content on the first screen to begin before subsequent initialization and rendering steps are completed. Compared to the normal loading process, LCP element rendering is completed significantly earlier, effectively reducing the overall rendering time of the first screen and shortening the waiting time for users to see the content.

[0137] Please refer to Figure 6 This is a schematic diagram of the interface pre-request loading timing provided in the embodiments of this application. The interface pre-request loading process is a full-link optimization scheme that is further iterated on the basis of pre-rendering. It also realizes multiple parallel optimizations of interface request pre-loading, key resource pre-loading and first screen pre-rendering, and eliminates serial blocking time consumption to the greatest extent.

[0138] During the synchronous loading period of project resources, the interface pre-request task and the LCP critical resource loading task are launched in parallel. The originally postponed interface call steps and the first screen resource loading steps are brought forward and proceed synchronously with the project resource loading steps. Before the subsequent project initialization and regular project rendering start, the preparation work for acquiring business data and loading the core resources of the first screen has been completed in advance.

[0139] Once the project rendering phase begins, there's no need to wait for API data returns or critical resource loading. Business data and initial screen resources are already ready, allowing project rendering and LCP element rendering to seamlessly connect and complete almost synchronously. This process eliminates redundant waiting time in the overall loading chain, resulting in the fastest initial screen loading speed. It represents the best performance and user experience among the three loading processes.

[0140] Please refer to Figure 7 This application provides a page loading device based on a micro-frontend framework, including a configuration acquisition module 501, a container preheating module 502, a page parsing module 503, a container matching module 504, and a page loading module 505, wherein: The configuration acquisition module 501 is used to load and parse the preset configuration file based on the preset micro-frontend base to obtain the page routing rules and container scheduling rules; The container preheating module 502 is used to preheat the base page of the micro-frontend base by carrying the container instance through at least one page pre-built based on the micro-frontend base, so as to obtain at least one ready container instance. The page parsing module 503 is used to intercept page access requests through the micro-frontend base, parse the page access requests, and obtain page routing information; The container matching module 504 is used to determine a target ready container instance that matches the page routing information from at least one ready container instance according to the page routing rules and the container scheduling rules. Page loading module 505 is used to retrieve the target ready container instance and load the business page to be loaded corresponding to the page access request based on the target ready container instance.

[0141] The page loading device based on the micro-frontend framework in this application embodiment can be a computer device or a component within the computer device, such as an integrated circuit or a chip. The computer device can be a terminal or other devices besides a terminal. For example, the computer device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle computer device, mobile internet device (MID), ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc., and can also be a server, network attached storage (NAS), personal computer (PC), etc. This application embodiment does not specifically limit the specific implementation.

[0142] The page loading device based on the micro-frontend framework provided in this application embodiment can achieve... Figure 1 The various processes implemented in the micro-frontend framework-based page loading method embodiment will not be described again here to avoid repetition.

[0143] This application also provides a computer device, please refer to... Figure 8 The computer device includes a processor 601 and a memory 602. The memory 602 stores a program or instruction that can run on the processor 601. When the program or instruction is executed by the processor 601, it implements the various steps of the page loading method based on the micro front-end framework described above and achieves the same technical effect. To avoid repetition, it will not be described in detail here.

[0144] It should be noted that the computer device in this application embodiment includes the mobile computer device and the non-mobile computer device described above.

[0145] The memory 602 can be used to store software programs and various data. The memory 602 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 602 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 602 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0146] Processor 601 may include one or more processing units; optionally, processor 601 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 601.

[0147] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described page loading method embodiment based on the micro-frontend framework and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0148] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described page loading method embodiment based on the micro-frontend framework, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0149] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0150] This application also provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the page loading method embodiment based on the micro front-end framework described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0151] 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 apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0152] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A page loading method based on a micro-frontend framework, characterized in that, include: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain page routing rules and container scheduling rules; By preheating the base page of the micro-frontend base using at least one page-bearing container instance pre-built based on the micro-frontend base, at least one ready container instance is obtained. The micro-frontend base intercepts page access requests and parses the page access requests to obtain page routing information; Based on the page routing rules and the container scheduling rules, a target ready container instance that matches the page routing information is determined from the at least one ready container instance; The target ready container instance is retrieved, and the business page to be loaded corresponding to the page access request is loaded based on the target ready container instance.

2. The page loading method according to claim 1, characterized in that, Before determining the target ready container instance matching the page routing information from the at least one ready container instance according to the page routing rules and the container scheduling rules, the page loading method further includes: Based on the page routing information, determine whether the page access request matches the loading conditions of the at least one ready container instance; The step of determining a target ready container instance matching the page routing information from the at least one ready container instance according to the page routing rules and the container scheduling rules includes: If the page access request matches the loading conditions of the at least one ready container instance, the target ready container instance that matches the page routing information is determined from the at least one ready container instance according to the page routing rules and the container scheduling rules.

3. The page loading method according to claim 2, characterized in that, The page loading method also includes: If the page access request does not match the loading conditions of the at least one ready container instance, a new page hosting container instance is created through the micro-frontend base, and the business page to be loaded is loaded based on the newly created page hosting container instance.

4. The page loading method according to claim 1, characterized in that, Before determining the target ready container instance matching the page routing information from the at least one ready container instance according to the page routing rules and the container scheduling rules, the page loading method further includes: A preheating instance reuse pool is constructed using the micro-frontend base, and at least one ready-state container instance is placed into the preheating instance reuse pool. The step of determining a target ready container instance matching the page routing information from the at least one ready container instance according to the page routing rules and the container scheduling rules includes: Based on the page routing rules and the container scheduling rules, a target ready container instance that matches the page routing information is determined from the preheating instance reuse pool; The process of retrieving the target ready container instance includes: Retrieve the target ready container instance from the preheating instance reuse pool.

5. The page loading method according to claim 4, characterized in that, The page loading method also includes: After loading the business page to be loaded based on the target ready container instance, the ready container instance is recycled to the preheating instance reuse pool.

6. The page loading method according to any one of claims 1-5, characterized in that, The target ready container instance is in an idle state; the page loading method further includes: The target ready container instance in the idle state is used to pre-render the business page to be loaded.

7. The page loading method according to claim 6, characterized in that, The page loading method also includes: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain a pre-rendered skeleton; The step of pre-rendering the business page to be loaded using the target ready container instance in an idle state includes: When the business page to be loaded is opened, the pre-rendered skeleton is rendered to the ready container instance in the idle state through the micro front-end base.

8. The page loading method according to claim 6, characterized in that, The page loading method also includes: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain the page pre-rendering configuration information; The step of pre-rendering the business page to be loaded using the target ready container instance in an idle state includes: When the business page to be loaded is opened, the document object structure of the business page to be loaded is dynamically captured and cached based on the page pre-rendering configuration information; When the business page to be loaded is opened again, the cached document object structure is retrieved to pre-render the business page to be loaded; Once the business page to be loaded is loaded, the pre-rendered document object structure is removed, the document object structure of the current business page to be loaded is re-captured, and the cache is updated.

9. The page loading method according to claim 6, characterized in that, The page loading method also includes: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain backup domain name configuration information, which includes at least one backup domain name; The page loading method also includes: Detect the loading process of the service page to be loaded based on the target ready container instance; When an error occurs during the loading process, the system switches to the backup domain name via the micro-frontend base. The pending business page is reloaded on the ready container instance using the alternative domain name.

10. The page loading method according to claim 6, characterized in that, The page loading method also includes: Based on the preset micro-frontend base, the preset configuration file is loaded and parsed to obtain performance optimization configuration information, which includes business data; The page loading method also includes: During the loading phase of the business page to be loaded, the page pre-rendering and the business data pre-request are executed in parallel by the ready container instance in the idle state.

11. A page loading device based on a micro-frontend framework, characterized in that, include: The configuration acquisition module is used to load and parse the preset configuration file based on the preset micro-frontend base to obtain the page routing rules and container scheduling rules; The container preheating module is used to preheat the base page of the micro-frontend base by preheating the base page of the micro-frontend base based on at least one page carrying container instance pre-built on the micro-frontend base, so as to obtain at least one ready container instance. The page parsing module is used to intercept page access requests through the micro-frontend base, and parse the page access requests to obtain page routing information; The container matching module is used to determine a target ready container instance that matches the page routing information from the at least one ready container instance according to the page routing rules and the container scheduling rules. The page loading module is used to retrieve the target ready container instance and load the business page to be loaded corresponding to the page access request based on the target ready container instance.

12. A page loading system based on a micro-frontend framework, the system comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, The computer program is loaded and executed by the processor to implement a page loading method based on a micro-frontend framework as described in any one of claims 1 to 10.

13. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it is used to implement a page loading method based on a micro-frontend framework as described in any one of claims 1 to 10.

Images