Page pre-rendering method and device, equipment and storage medium

Abstract

The invention provides a page pre-rendering method and device, equipment and a storage medium, and relates to the technical field of internet technology and page rendering. According to the specific implementation scheme, page rendering logic is executed in a script execution environment of a client background to obtain rendering result data; generating a static page file locally at the client based on the rendering result data; and in response to an access request for the target page, loading the locally generated static page file to display the target page. By means of the technical scheme, page core rendering and splicing can be completed in advance, the time-consuming rendering process is preposed, and the waiting time of first screen rendering is shortened.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of internet technology and page rendering technology. Background Technology

[0002] With the development of mobile internet technology, embedding WebView components within mobile applications (Client or App) to load and display web pages (such as H5 pages) has become a mainstream technical solution. This solution allows for flexible updates to business content and possesses excellent cross-platform compatibility. When users access these embedded web pages using mobile applications, the initial page load speed is a key factor affecting user experience. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, and storage medium for pre-rendering pages.

[0004] According to one aspect of this disclosure, a method for pre-rendering a page is provided, comprising: The page rendering logic is executed in the script execution environment in the client background to obtain the rendering result data; Based on the rendered result data, static page files are generated locally on the client side; In response to a request for access to the target page, load the locally generated static page file to display the target page.

[0005] According to another aspect of this disclosure, an apparatus for pre-rendering a page is provided, comprising: The pre-rendering module is used to execute page rendering logic in the script execution environment in the client background to obtain rendering result data; The generation module is used to generate static page files locally on the client based on the rendered result data; The loading module is used to load locally generated static page files in response to access requests for the target page, so as to display the target page.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and The memory is communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0009] The technical solution of this disclosure can create a lightweight rendering environment inside the client, and complete the core rendering and splicing of the page in advance during the idle period of the device that the user is unaware of, thereby bringing forward the most time-consuming rendering process and reducing the waiting time for the first screen rendering.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a method for pre-rendering a page according to an embodiment of this disclosure; Figure 2 This is an architecture diagram of a pre-rendered page system provided in one embodiment of the present disclosure; Figure 3 This is a schematic flowchart of a page rendering method provided in another embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of a pre-rendered page apparatus provided according to an embodiment of the present disclosure; Figure 5 This is a block diagram of an electronic device used to implement embodiments of the present disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] In order to improve the loading performance of H5 pages and reduce the "white screen" time for users, various page rendering solutions have been proposed in the industry.

[0014] A common approach is Client-Side Rendering (CSR). In CSR, the server returns only a basic HTML skeleton and related script (JavaScript, JS) resources to the client's WebView. After receiving the resources, the WebView relies on its built-in JS runtime to parse and execute the script. During script execution, data requests, DOM (Document Object Model) construction, and page rendering are performed, finally presenting the complete page to the user.

[0015] Another solution for optimizing the first-screen experience is Server-Side Rendering (SSR). In SSR, the page rendering logic (usually based on JavaScript) is executed on a remote server (such as a Node.js environment). The server concatenates the data and template into a complete HTML string, and then sends this HTML file containing the first-screen content to the client. The client's WebView receives this and can directly parse and display it.

[0016] In addition, offline package technology exists to accelerate resource acquisition. This solution typically involves pre-packaging the static resources required for a webpage (such as HTML, JS, and CSS files) and having the client download them to local storage. When a user visits the site, WebView can directly load these pre-built static resources from the client's local storage, thus eliminating the need for network requests.

[0017] The initial rendering of the CSR solution relies entirely on network requests and JavaScript execution, which can easily lead to a blank screen in weak network environments. Furthermore, when the JavaScript file is large, the parsing and execution time significantly impacts the user experience.

[0018] SSR solutions require a Node.js environment to be deployed on the server, increasing operational costs and service complexity. In high-concurrency scenarios, the server-side rendering pressure is high, easily becoming a performance bottleneck. On mobile devices with weak network conditions, users still need to wait for the server to return HTML, resulting in noticeable initial screen latency.

[0019] Offline package solutions require pre-packaging and releasing page resources, resulting in insufficient dynamism and limited data updates. Each business iteration necessitates a new release, increasing deployment and canary release costs. Furthermore, they cannot effectively support real-time data and personalized rendering.

[0020] To at least partially solve one or more of the above-mentioned problems and other potential problems, the embodiments of this disclosure provide a Native Side Rendering (NSR) method, i.e., a localized rendering method for pages. By using the technical solution of the embodiments of this disclosure, a lightweight rendering environment can be created inside the client, and the core rendering and splicing of the page can be completed in advance during the idle period of the device without the user's awareness, thus bringing forward the most time-consuming rendering process and reducing the waiting time for the first screen rendering.

[0021] This embodiment provides a method for pre-rendering pages, applied to a client. The client can be a native application (App) installed on a mobile terminal (such as a smartphone or tablet), such as a personal cloud or cloud storage application. Figure 1 This is a flowchart illustrating a method for pre-rendering a page according to an embodiment of this disclosure. Figure 1 As shown, the method includes at least the following steps: S110: Executes page rendering logic in the script execution environment in the client background to obtain rendering result data.

[0022] In this embodiment of the disclosure, the client backend can be understood as an environment that runs without the user's awareness, such as in a background thread of the application or in an invisible view.

[0023] A script execution environment can be a component or engine that can parse and execute JavaScript (JS) code.

[0024] Page rendering logic can be a set of code files developed by the front end to define the page structure and content, such as an nsr.bundle.js file, which may contain rendering logic written using frameworks such as Vue2 or React.

[0025] To execute the page rendering logic, the above code can be loaded and run in the script execution environment, allowing it to complete the calculation of data and templates in the background.

[0026] The rendering result data can be the data output after the page rendering logic is executed, used to describe the final page content, and is usually one or more strings.

[0027] One specific implementation could be that the client starts a JS Runtime in the background, loads the nsr.bundle.js file, and calls the renderApp method within it. This method executes Vue2's rendering logic (such as creating a virtual DOM and converting it into a string), and finally outputs outHtml (an HTML string describing the DOM structure) and Store string (a data string describing the initial state of the page). These two together constitute the rendering result data.

[0028] S120: Generate static page files locally on the client based on the rendered result data.

[0029] In this step, "client local" can refer to the local storage space of the client device (such as a mobile phone). A static page file can be a complete HTML file that can be directly loaded and displayed by a browser or web view component, such as an index.html file.

[0030] Generating a static page file based on the rendered result data can be a file compositing process. For example, the client's native code reads a preset HTML template (e.g., template.html), then inserts the outHtml string and Store string obtained from S110 into the specified placeholders of the template through string replacement, and finally saves this concatenated complete HTML content as the local index.html file, which is the static page file.

[0031] S130: In response to an access request for the target page, load the locally generated static page file to display the target page.

[0032] In this step, the target page is the specific business page that the user wants to access, such as an activity page or a function page. Responding to the access request can refer to the user clicking on the client interface. Loading the locally generated static page file can mean that after receiving the user's click, the client does not initiate a network request to retrieve HTML, but instead directly loads the index.html file generated locally by the S120 into its front-end web view component (WebView).

[0033] For example, when a user clicks on an activity entry point within the app, the app locates the locally generated index.html file based on a manifest file (resource mapping manifest) and immediately loads it into the foreground WebView used for display.

[0034] According to the solution of this disclosure embodiment, by executing the page rendering logic in advance in the script execution environment in the client background and generating a static page file locally, when the user requests access, the client can directly load this complete page that has been prepared locally, thereby avoiding the time-consuming process of JS download, parsing, execution and data request required by traditional client real-time rendering (CSR), greatly shortening the first screen loading time, eliminating the white screen, and realizing the instant loading experience of "click to display".

[0035] In one possible implementation, S110 executes the page rendering logic in a script execution environment in the client background, further including: S111: Instantiate an off-screen network view component in the client background as a script execution environment.

[0036] In this step, the off-screen web view (WebView) component can be a standard component provided by a mobile operating system for loading and displaying web pages, such as WebView on the Android platform or WKWebView on the iOS platform.

[0037] Off-screen means that the network view component instance is created and run in memory, but is not attached to any visible user interface, and the user cannot see it.

[0038] Using the off-screen network view component as a script execution environment means that the core purpose of this solution is not to use it to display web pages, but to use its built-in JavaScript execution capabilities (such as V8 and JSCore engines) to act as the JSRuntime in S110.

[0039] For example, the client creates a WebView object instance in a background thread but does not call methods such as addView to display it to the user. This approach reuses the app's built-in WebView capabilities, eliminating the need to integrate third-party JS engines such as V8 or QuickJS, thus reducing client-side complexity and maintenance costs.

[0040] S112: Execute page rendering logic in the off-screen network view component to obtain rendering result data.

[0041] In this step, the client's native code communicates with the off-screen WebView instantiated in S111, passing it the page rendering logic (such as the content of the nsr.bundle.js file) and instructing it to execute. After execution, the off-screen WebView then sends the rendered result data back to the client's native code.

[0042] According to the embodiments of this disclosure, a lightweight and low-cost in-client rendering implementation is provided by reusing the client-built-in off-screen network view component as the script execution environment. It avoids the high deployment and maintenance costs of Node.js servers required by traditional server-side rendering (SSR), and also avoids the problems of increased package size and architectural complexity caused by the need to embed an additional JS engine in other in-client rendering solutions.

[0043] In one possible implementation, S112 executes page rendering logic in the off-screen network view component, further including: S1121: Inject page rendering logic into the off-screen network view component in the client backend.

[0044] In this step, injection can refer to the client-side native code loading the page rendering logic (e.g., reading the entire text content of nsr.bundle.js from a local file) into the JS context of the off-screen WebView created by S111 through a specific interface (e.g., WebView.evaluateJavascript), making it ready to be invoked.

[0045] S1122: Call the preset rendering method within the page rendering logic to generate rendering result data.

[0046] In this step, the predefined rendering method can be a global function predefined in the page rendering logic (nsr.bundle.js) and exposed to the native environment, such as the renderApp(context) method. The call can refer to the client-side native code, after injecting its logic, triggering the execution of this renderApp function again via evaluateJavascript or JSBridge (a bridge for bidirectional communication between native and JS code). When executed in the off-screen WebView, this function completes a series of front-end rendering tasks, such as creating the Virtual Document Object Model (DOM), executing the mounting and rendering logic of Vue2 components, and finally exporting the rendered result data (such as outHtml strings and Store strings). This data is returned to the client-side native code via JSBridge or asynchronous callbacks.

[0047] According to the solution of this disclosure, a standardized interaction interface between client-side native code and front-end rendering logic is implemented by injecting page rendering logic and calling preset rendering methods. This allows the front-end rendering logic to iterate independently, while the client only needs to focus on calling renderApp, a unified entry point, thus decoupling the native code from the front-end logic and improving maintainability.

[0048] In one possible implementation, S1122 calls a preset rendering method within the page rendering logic, further including: S1123: When calling the preset rendering method within the page rendering logic, skip the request and rendering of the preset post-processing data.

[0049] In this step, post-processing data refers to data that is not suitable for acquisition during the pre-rendering stage (S1122). Post-processing data includes data with real-time characteristics. This data can be volatile, delayed, or personalized, such as a user's "money," "points," or "expired data" that needs to be updated in real time. Skipping requests and rendering means that when the `renderApp` method is executed in S1122, its internal logic will determine whether to skip network requests for this post-processing data if it recognizes that the current environment is NSR (NativeSide Rendering). Furthermore, when generating the `outHTML`, only placeholders will be reserved for these data, without filling in any actual content. Post-processing data can be pre-defined. For example, it can be pre-defined which interfaces' data is considered sensitive, and when `renderApp` is executed in NSR, requests to these interfaces will be automatically skipped in the code logic.

[0050] For example, a page needs to display "Username" and "Account Balance". When executing S1122, renderApp may render the "Username" (because it is relatively fixed), but will skip rendering the "Account Balance".

[0051] According to the solution of this disclosure, by skipping the rendering of post-processing data (such as sensitive or real-time data) in the pre-rendering stage, the problem of data staleness or inconsistency that may be caused by pre-rendering is cleverly solved. This ensures that the skeleton of the page can be quickly pre-rendered to achieve instant loading, while avoiding user complaints caused by seeing expired data (such as incorrect balances), thus achieving a balance between rendering speed and data consistency.

[0052] In one possible implementation, the pre-rendering method provided in this disclosure, based on S110~S13, and especially based on S1123, further includes the following steps: S140: Execute the script logic contained in the static page file to asynchronously request and populate the skipped post-processing data.

[0053] In this step, the static page file (i.e., index.html generated by S120) contains not only the HTML skeleton generated by S110, but also script logic for activating the page (this logic can come from the local page template of S121, or it can be part of the page rendering logic package). When the user's foreground WebView loads this index.html (i.e., the "target page in the initial state"), this script logic will begin to execute. This process is often referred to as "hydration" in the front-end field. The script logic (e.g., the Vue2 runtime) takes over the static DOM on the page and asynchronously initiates network requests to retrieve the post-processing data (such as "account balance") that was skipped in S1123. After successful retrieval, the script logic updates the DOM, fills the skipped data into the corresponding placeholders, and binds interactive events (such as clicks) to the page elements. At this point, the page reaches its final target page state, which is a dynamic page with complete data content and fully interactive functionality.

[0054] It should be understood that if there is no post-processing data in the target page, the final target page can be obtained after S130 loads index.html.

[0055] According to the solution of this disclosure, post-processing data is asynchronously loaded by executing script logic after the page is displayed, forming a complete closed loop of "pre-rendering + hydration". This enables the solution to not only achieve instant first screen display, but also support real-time data refresh and complete user interaction, solving the shortcomings of traditional offline package solutions in terms of insufficient dynamism and inability to support real-time personalized rendering.

[0056] In one possible implementation, this embodiment, based on the previous embodiments, further includes preparation steps prior to pre-rendering: S101: Triggers the download of an offline resource package containing page rendering logic and local page templates during client cold start.

[0057] In this step, a client cold start refers to a user launching the app from scratch (e.g., clicking the desktop icon before the app process is running in the background). This is an ideal time when the user expects loading time and device resources are relatively idle. The offline resource package can be a compressed file (e.g., .zip), generated by the front-end pipeline (product building module) and uploaded to the offline package platform for version management. This offline resource package contains the raw materials needed to perform pre-rendering, mainly including: Page rendering logic (e.g., nsr.bundle.js file).

[0058] Local page templates (e.g., template.html files).

[0059] Triggered download means that when the client starts cold, it checks the version of the local offline resource package and downloads the latest resource package from the offline package platform to the local machine.

[0060] According to the solution of this disclosure embodiment, by downloading the offline resource package during the client cold start, it is ensured that the logic and template used for pre-rendering are the latest versions. At the same time, the download action is scheduled at a time with minimal impact on user experience, which prepares for the subsequent pre-rendering to be performed in the background.

[0061] In one possible implementation, S120 generates a static page file based on the rendered result data, further including: S121: Retrieve a pre-saved local page template.

[0062] In this step, the local page template can be part of the offline resource package downloaded from S101, which is pre-stored on the client's local machine. This template is an HTML skeleton file that does not contain specific business DOM elements, but defines the basic framework of the page (such as CSS links and JS script references) and key placeholders.

[0063] S122: Replace the preset placeholders in the local page template with the rendered data to generate a static page file.

[0064] This step involves a string concatenation process performed at the client-side native layer. The client-side native code reads the template.html content obtained by S121, then retrieves the rendering result data generated by S110 (such as the outHtml string and Store string), and uses this data to replace the corresponding placeholders in the template. After concatenation, the resulting complete HTML string is written to the client's local storage and saved as a static page file (such as index.html).

[0065] According to the solution of this disclosure, static page files are generated by using a "template + placeholder replacement" method, thus decoupling the static page framework from the dynamically rendered content. This approach ensures the flexibility of the front-end rendering logic while also making the client-side file generation process efficient and controllable.

[0066] In one possible implementation, S130, in response to an access request for the target page, loads a locally generated static page file to display the target page, further including: S131: Determine if the static page file exists on the client's local machine.

[0067] In this step, when a user initiates an access request in S130, the client (e.g., through the manifest mapping relationship of the offline package) will first check whether the static page file (e.g., index.html) that should have been generated in step S120 actually exists on the local disk.

[0068] S132: If the static page file does not exist, execute the client-side real-time rendering mode to display the target page.

[0069] In this step, the absence of static page files may mean that the background pre-rendering process of S110-S120 has not yet been executed, is in progress, or has failed. In this case, a fallback mechanism will be initiated to ensure normal user access. Client-side real-time rendering (CSR) mode means that the client no longer attempts to load index.html, but instead loads the local page template in S121. This template (like a traditional H5 page) loads the page rendering logic (nsr.bundle.js) in its foreground WebView. Then, nsr.bundle.js (in CSR mode) will initiate network requests, retrieve data, and perform rendering in real time, ultimately displaying the target page.

[0070] According to the solution of this disclosure, by determining whether the static page file exists before loading and providing a fault-tolerant mechanism of "downgrading CSR execution when it does not exist", the robustness of the solution is greatly improved. This ensures that even if the user accesses the page before pre-rendering is complete, or if pre-rendering fails unexpectedly, the page can still be opened normally, avoiding functional unavailability.

[0071] In one possible implementation, the offline resource package does not contain static page files in its initial state.

[0072] In this embodiment of the disclosure, the initial state refers to the original resource package that has been packaged by the front-end pipeline (product building module), uploaded to the offline package platform, and downloaded by the client in S101. This resource package does not contain the final static page file. It only contains the raw materials used to create the file, namely the page rendering logic (nsr.bundle.js) and the local page template (template.html).

[0073] According to the solution of this disclosure embodiment, by limiting the offline resource package to not containing static page files in the initial state, it is clear that the final static page files are generated locally, rather than the traditional offline package that pre-packages index.html on the server.

[0074] Figure 2This embodiment provides an architecture diagram of a pre-rendered page system, as shown in the figure, which is divided into an output construction module, an offline rendering module, and a page loading and hydration module.

[0075] The artifact build module can be a front-end build pipeline. This module is responsible for packaging and generating artifacts for native side rendering (NSR).

[0076] Specifically, this module packages the front-end rendering logic (such as Vue2 component code) and a unified rendering entry method (such as the `renderApp` method) into a single page rendering logic package (e.g., `nsr.bundle.js`). Simultaneously, this module generates a local page template (e.g., `template.html`), which contains the page's basic HTML skeleton, placeholders, and script logic for subsequent steps (e.g., hydration logic). Finally, the module uploads the generated `nsr.bundle.js` and `template.html` artifacts to an offline package platform for version management.

[0077] The offline rendering module executes on the client-side (e.g., a mobile app). The client downloads offline resources from an offline package platform at specific times (e.g., when the app launches). The client creates an off-screen web view component in the background and injects nsr.bundle.js into it. The client executes the page rendering logic within the off-screen WebView by calling the renderApp method, generating DOM and store data. Finally, the client retrieves this rendered data and replaces the corresponding placeholders in the template.html template with it, thus concatenating and generating a complete static page file locally.

[0078] Page loading and the hydration module are triggered when a user actually accesses the page. When a user clicks the access entry, the client directly loads the locally generated index.html file into the front-end network view component based on the mapping relationship of a manifest file. Since index.html is a static file that already contains the complete DOM, the page is displayed instantly. After the page is displayed, the script logic contained in index.html (i.e., the hydration logic) begins to execute. This logic can perform tasks such as asynchronous data refresh and interactive event binding, making the page fully interactive.

[0079] According to the scheme of this disclosure embodiment, by dividing the system into three modules—product construction, offline rendering, and page loading and hydration—the most time-consuming rendering process is completely moved to the front end before the user accesses the page, and complete static page files are pre-generated locally on the client. This allows for "instant" rendering by directly loading local files when the user accesses the page, avoiding the problems of long white screen time and slow loading caused by relying on real-time JS execution in traditional CSR solutions, and also avoiding the server-side deployment costs required by SSR solutions.

[0080] Figure 3 This is a flowchart illustrating a page rendering method provided in this embodiment. Specific implementation steps may include: S301: Triggers App launch.

[0081] After the app starts, two processes are triggered in parallel: one is to initialize the JS Runtime, and the other is to start downloading offline resources.

[0082] S302: Initialize the JS Runtime.

[0083] Prepare a JS Runtime (JavaScript execution environment) in the client-side background for the subsequent NSR (Native Side Rendering) process.

[0084] S303: Offline resource download.

[0085] The client downloads the resources required for subsequent processes, including the Bundle.js file.

[0086] S304: Loading Bundle.js.

[0087] Load the Bundle.js file into the prepared JS Runtime.

[0088] S305: Execute Render.

[0089] In the JS Runtime environment, the pre-rendering logic is executed by combining Runtime capabilities with the loaded Bundle.js.

[0090] S306: Generate the complete DOM.

[0091] After the rendering logic is executed, the complete DOM structure of the page is generated in the background.

[0092] S307: Assembly of templates and DOM.

[0093] Assemble the complete DOM with a preset page template.

[0094] S308: Generate a complete index file.

[0095] Once assembled, a complete index file containing the full page content is generated locally on the client.

[0096] The steps S301 to S308 above (NSR process) can be completed in advance before a user triggers access to a specific page. When a user initiates an access request, the following steps are performed: S309: Activity clicks.

[0097] Respond to a user action triggered within the app, such as clicking an activity entry point.

[0098] S310: Initialize WebView.

[0099] The client responds to the S309 click by instantiating a WebView to display the page.

[0100] S311: Causes WebView to hit and load the complete index file.

[0101] During the initialization of WebView, if the Index is hit, the complete index file that has already been generated locally will be loaded directly.

[0102] S312: Perform rendering (hydration).

[0103] After WebView loads the complete index file, it executes the embedded script logic within the page to hydrate the page, such as binding interactive events and loading dynamic data.

[0104] S313: Display the page to the user.

[0105] After rendering and hydration are complete, the final interactive page is presented to the user.

[0106] According to the solution of this disclosure embodiment, by starting the NSR process immediately after the App starts, time-consuming operations such as page rendering and DOM generation are brought forward, and a complete index file is pre-generated locally. When the user actually initiates an activity by clicking, the WebView does not need to wait for JS execution and DOM rendering, but can directly load this pre-generated file, thereby greatly shortening the waiting time from clicking to page display, achieving fast page loading and a "second-open" experience.

[0107] Figure 4 This is a structural schematic diagram of a pre-rendered page apparatus 400 provided according to an embodiment of this disclosure. For example... Figure 4 As shown, the device includes: The pre-rendering module 401 is used to execute page rendering logic in the script execution environment in the client background to obtain rendering result data; The generation module 402 is used to generate static page files locally on the client based on the rendering result data; Load module 403 is used to load locally generated static page files to display the target page in response to an access request for the target page.

[0108] In one possible implementation, the pre-rendering module 401 is used for: Instantiate an off-screen network view component in the client-side background as a script execution environment; Execute page rendering logic in the off-screen network view component to obtain the rendering result data.

[0109] In one possible implementation, the pre-rendering module 401 is used for: Inject page rendering logic into the off-screen network view component in the client-side backend; Call the preset rendering method within the page rendering logic to generate the rendering result data.

[0110] In one possible implementation, when calling the preset rendering method within the page rendering logic, the request and rendering of the preset post-processing data are skipped. Post-processed data includes data with real-time characteristics.

[0111] In one possible implementation, the device further includes a hydration module for: Execute the script logic contained in the static page file to asynchronously request and populate the skipped post-processing data.

[0112] In one possible implementation, the device further includes a hydration module download module for: When the client starts cold, it triggers the download of an offline resource package containing page rendering logic and local page templates.

[0113] In one possible implementation, the generation module 402 is used for: Retrieve a pre-saved local page template; Replace the preset placeholders in the local page template with the rendered data to generate a static page file.

[0114] In one possible implementation, loading module 403 is used for: Determine if the static page file exists on the client's local machine; If the static page file does not exist, execute the client-side real-time rendering mode to display the target page.

[0115] In one possible implementation, the offline resource package does not contain static page files in its initial state.

[0116] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0117] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0118] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0119] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0120] like Figure 5 As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 502 or a computer program loaded from storage unit 508 into random access memory (RAM) 503. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0121] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0122] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the method of pre-rendering a page. For example, in some embodiments, the method of pre-rendering a page may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the method of pre-rendering a page described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the method of pre-rendering a page by any other suitable means (e.g., by means of firmware).

[0123] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0124] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0125] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0126] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0127] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0128] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0129] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0130] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for pre-rendering a page, comprising: The page rendering logic is executed in the script execution environment in the client background to obtain the rendering result data; Based on the rendered result data, a static page file is generated locally on the client. In response to an access request for the target page, the locally generated static page file is loaded to display the target page.

2. The method according to claim 1, wherein, The execution of page rendering logic in the client-side background script execution environment to obtain rendering result data includes: Instantiate an off-screen network view component in the client-side background as a script execution environment; The page rendering logic is executed in the off-screen network view component to obtain the rendering result data.

3. The method according to claim 2, wherein, The step of executing page rendering logic in the off-screen network view component to obtain rendering result data includes: Inject page rendering logic into the off-screen network view component in the client-side backend; The preset rendering method within the page rendering logic is invoked to generate the rendering result data.

4. The method according to claim 3, wherein, When the preset rendering method within the page rendering logic is called, the request and rendering of the preset post-processing data are skipped. The post-processed data includes data with real-time characteristics.

5. The method according to claim 1 or 4, further comprising: The script logic contained in the static page file is executed to asynchronously request and populate the skipped post-processing data.

6. The method according to claim 1, further comprising: When the client starts cold, it triggers the download of an offline resource package containing page rendering logic and local page templates.

7. The method according to claim 1 or 6, wherein, The step of generating a static page file locally on the client based on the rendered result data includes: Retrieve a pre-saved local page template; The rendered result data replaces the preset placeholders in the local page template to generate the static page file.

8. The method according to claim 1, wherein, The step of loading the locally generated static page file to display the target page in response to an access request for the target page includes: Determine whether the static page file exists locally on the client. If the static page file does not exist, the client-side real-time rendering mode is executed to display the target page.

9. The method according to claim 6, wherein, The offline resource package does not contain the static page file in its initial state.

10. An apparatus for pre-rendering a page, comprising: The pre-rendering module is used to execute page rendering logic in the script execution environment in the client background to obtain rendering result data; The generation module is used to generate static page files locally on the client based on the rendering result data; The loading module is used to load the locally generated static page file to display the target page in response to an access request for the target page.

11. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

13. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-9.

Images