Page rendering method and device for web page, equipment, medium and product

Abstract

The embodiment of the invention provides a page rendering method and device for a web page, equipment, a medium and a product, and the scheme comprises the steps that an access request of a user is obtained, and the access request is used for requesting to access a target web page displayed in an application client; in response to the access request, reading first page data used for rendering a static page of the target web page from the local of the application client, and reading second page data used for converting the target web page from the static page to a dynamic page from the local of the client, the first page data is data stored after the application client renders a static page for the target web page based on historical access of the user to the target web page, and the second page data is data stored after the static page is converted into a dynamic page; and based on the read first page data and the second page data, rendering to obtain a target web page for a user to execute an interaction operation.

Description

Technical Field

[0001] This specification relates to the field of page rendering technology, and more particularly to a page rendering method for web pages. This specification also relates to a page rendering apparatus for web pages, a computing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] When accessing cloud-based web pages through hybrid applications, the First Contentful Paint (FCP) metric may be poor due to the impact of cloud resource response time, especially under poor network conditions. Users may have to face a blank screen or incomplete page for a long time while waiting, which can easily lead to user churn due to poor user experience.

[0003] Therefore, improving the performance of FCP and increasing the page rendering speed when rendering web pages has become an urgent technical problem to be solved. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide a page rendering method, apparatus, device, medium and product for web pages, which can improve the performance of FCP and the page rendering speed.

[0005] According to a first aspect of one or more embodiments of this specification, a page rendering method for a web page is provided, comprising:

[0006] Obtain the user's access request, which is used to request access to the target web page displayed in the application client;

[0007] In response to the access request, the first page data for rendering the target web page is read from the local storage of the application client. The first page data is data stored by the application client after rendering the static page for the target web page based on the user's historical access to the target web page.

[0008] The application client reads second page data from its local storage to convert the target web page from a static page to a dynamic page. The second page data is data stored by the application client after rendering a dynamic page for the target web page based on the user's historical access to the target web page.

[0009] Based on the first page data and the second page data, the target web page that the user can interact with is rendered.

[0010] According to a second aspect of one or more embodiments of this specification, a page rendering apparatus for a web page is provided, comprising:

[0011] The acquisition module is used to acquire the user's access request, which is used to request access to the target web page displayed in the application client;

[0012] The first reading module is used to read, in response to the access request, the first page data of the static page used to render the target web page from the local storage of the application client. The first page data is the data stored by the application client based on the user's historical access to the target web page after rendering the static page for the target web page.

[0013] The second reading module is used to read second page data from the local machine of the client for converting the target web page from the static page to the dynamic page. The second page data is data stored by the application client based on the user's historical access to the target web page after rendering the dynamic page for the target web page.

[0014] The rendering module is used to render the target web page that the user can interact with based on the first page data and the second page data.

[0015] According to a third aspect of one or more embodiments of this specification, a computing device is provided, including a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor, when executing the computer instructions, implements the steps of the page rendering method for a web page.

[0016] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions, which, when executed by a processor, implement the steps of the page rendering method for a web page.

[0017] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the page rendering method for a web page described above.

[0018] One embodiment of this specification can achieve at least the following beneficial effects: First page data for rendering the static page of the target Web page is pre-stored on the application client. When a user initiates an access request, the application client does not need to request this data from the server; it can directly read the locally pre-stored first page data and quickly render the static page of the target Web page. This eliminates the need for cross-network data requests, shortens the rendering time of the static page, and thus improves the performance of FCP and the page rendering speed.

[0019] Furthermore, the application client can also synchronously read locally stored second-page data. This second-page data is used to convert the target web page from a static page into an interactive dynamic page. This second-page data is stored after the page has completed dynamic rendering, based on the user's historical access requests to the target web page. Because the second-page data is directly associated with the complete dynamic rendering results of historical accesses, it possesses high relative freshness. When performing the static-to-dynamic page conversion operation based on this high-freshness second-page data, the timeliness of the dynamically rendered page data can be effectively ensured, thereby improving the freshness of the target web page available for user interaction. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of a page rendering method for web pages provided in one embodiment of this specification.

[0022] Figure 2 This is a flowchart illustrating a page rendering method for a web page according to an embodiment of this specification;

[0023] Figure 3 This is a schematic diagram of a process provided in an embodiment of the present specification for rendering a target web page into an interactive page that allows users to perform interactive operations using first page data and second page data;

[0024] Figure 4 This is a schematic diagram illustrating a process for snapshot storage of second page data provided in one embodiment of this specification;

[0025] Figure 5 This is a schematic diagram of a page rendering process for a user accessing a product purchase page, provided in one embodiment of this specification.

[0026] Figure 6 This is a schematic diagram of a first static page of a product purchase page provided in one embodiment of this specification;

[0027] Figure 7 This is a schematic diagram of a first dynamic page of a product purchase page provided in one embodiment of this specification;

[0028] Figure 8 This is a schematic diagram of a second dynamic page of a product purchase page provided in one embodiment of this specification;

[0029] Figure 9 This specification provides an embodiment corresponding to... Figure 2 A schematic diagram of the structure of a page rendering device for web pages;

[0030] Figure 10 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0031] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0032] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0033] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0034] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, 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, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0035] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0036] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0037] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0038] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0039] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0040] The following explains the terms and concepts used in one or more embodiments of this specification.

[0041] Native apps need to be downloaded and installed from the corresponding system's app store, such as Apple's App Store or Android's app market. After installation, a separate icon will appear on the phone's home screen. They do not rely on a browser when running and directly access the phone's system resources.

[0042] Web applications, or Web Apps, do not require installation and can be used by accessing a specific website through a browser on a mobile phone or computer. Essentially, they are web pages adapted for mobile devices.

[0043] Hybrid apps are intermediate applications that combine native and web application technologies. Essentially, they utilize web technologies (HTML, CSS, JavaScript) to develop core functionalities and then package them into an application that can be installed in app stores using a native container.

[0044] The Document Object Model (DOM) is a programming interface for representing and manipulating the structure of HTML and XML documents. It organizes elements in a document, such as tags, attributes, and text, into a tree structure, allowing scripting languages ​​such as JavaScript to dynamically modify the content, structure, and style of a page. It is one of the core technologies for implementing interactive functions on web pages.

[0045] React is a JavaScript library developed and maintained primarily for building user interfaces (UI), especially adept at developing complex, frequently interacting single-page applications (SPAs). Its design philosophy and technical features allow developers to handle page state changes more efficiently, reuse UI components, and optimize rendering performance.

[0046] Page rendering refers to the entire process by which the rendering engine of a browser or application client parses, integrates, and calculates various resources (such as HTML, CSS, JavaScript, images, etc.) and data (static pre-stored data, real-time requested data, user interaction data, etc.) required by the page, and finally transforms them into a visual interface that the user can directly see and operate.

[0047] First Contentful Paint (FCP) is one of the core metrics for measuring page load performance. It describes the point in time when the browser first draws any content from the DOM (such as text, images, non-blank Canvas, or SVG) to the screen, marking the moment when the user begins to see the actual content of the page.

[0048] In related technologies, user-independent data in the page data used for static page rendering of web pages is usually stored on the application client. Although this method can quickly render user-independent elements in the static page, user-related data used for rendering user-related elements in the static page still needs to be requested from the server. In other words, rendering a complete static page for a web page in related technologies still takes a relatively long time.

[0049] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0050] Figure 1 This is a schematic diagram illustrating an application scenario of a page rendering method for web pages provided in one embodiment of this specification.

[0051] like Figure 1 As shown in the diagram, the application scenario includes a terminal device 101 and a server 102.

[0052] In the embodiments of this specification, the terminal device 101 may include, but is not limited to, at least one of the following terminals: smartphone, tablet computer, laptop computer, smart interactive device, wearable device, in-vehicle smart terminal, etc. Wearable devices may include, but are not limited to, at least one of the following terminals: smart bracelet, smartwatch, smart glasses, etc.

[0053] Server 102 may include, but is not limited to, at least one of the following: any device, equipment, platform, equipment cluster, or cloud computing service center server with computing and processing capabilities.

[0054] A communication connection is established between terminal device 101 and server 102. This communication connection can be, but is not limited to, a local area network (LAN) connection, a wide area network (WAN) connection, an internet connection, a short-range communication connection, or other types of data network connections. Short-range communication connections include, but are not limited to, Near Field Communication (NFC), LAN, Bluetooth, and infrared connections. Terminal device 101 can request page data from server 102 for rendering a web page. Server 102 responds to the request by sending the page data back to terminal device 101. Terminal device 101 can store the page data locally. When a user sends an access request to terminal device 101 to access a target web page displayed on terminal device 101, terminal device 101 can directly read the locally stored page data for page rendering.

[0055] This application provides a page rendering method for web pages. This application also relates to a page rendering apparatus for web pages, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0056] Figure 2 This is a flowchart illustrating a page rendering method for a web page according to an embodiment of this specification.

[0057] From a programming perspective, the entity executing the process can be a program mounted on a device used for rendering web pages. From a hardware perspective, this method can be executed by any device, platform, or cluster of devices with computing and processing capabilities; for example, it could be a terminal device, a server, or both.

[0058] like Figure 2 As shown, the process may include the following steps:

[0059] Step 202: Obtain the user's access request, which is used to request access to the target web page displayed in the application client.

[0060] In the embodiments described in this specification, the application client can be a hybrid application client installed on a user terminal device. In practical applications, the hybrid application can be an H5 application running within a preset application, and the preset application can include various application carriers capable of running H5 applications. The target web page can be any page displayed in the hybrid application, such as the homepage, order list page, product details page, etc. In practical applications, the target web page can include an H5 page.

[0061] In the embodiments described in this specification, the user can include a user who accesses a web page in the application client. In practical applications, for shopping applications, the user can be either a consumer or a merchant.

[0062] In the embodiments described in this specification, after a user triggers an operation on a web page within the application client, the application client can generate an access request in response to the triggering operation. The triggering operation may include a click operation on the page identifier of the web page.

[0063] Step 204: In response to the access request, read the first page data of the static page used to render the target web page from the local storage of the application client.

[0064] The first page data is data stored by the application client after rendering a static page for the target web page based on the user's historical access to the target web page.

[0065] In the embodiments of this specification, the local storage method of the application client may include memory storage or disk storage, etc. Memory storage may include temporary storage or memory cache during system runtime, etc. Disk storage may include persistent cache storage, local database storage, etc. A static page can refer to a state page where the target web page has fixed content and no dynamic interactive functions. At this time, the page content does not change with user operations or real-time data, and the page presents preset fixed content.

[0066] In the embodiments of this specification, the methods for reading the first page data may include: reading the complete first page data from the local application client at once; or reading each sub-page data from the local application client in batches based on the rendering priority of each sub-page data in the first page data, such as prioritizing reading the sub-page data with higher rendering priority.

[0067] In the embodiments of this specification, historical access to a target web page can refer to one or more accesses to the target web page before the access request is initiated. In practical applications, historical access can refer to the first access within a preset time period, and the preset time period can refer to a time range that traces back a preset duration based on the access time of the access request.

[0068] In practical applications, the first page data can be the data stored after the complete HTML document used to render the static page is rendered for the target web page.

[0069] Step 206: Read the second page data from the client's local storage for converting the target web page from the static page to the dynamic page.

[0070] The second page data is data stored by the application client after rendering a dynamic page for the target web page based on the user's historical access to the target web page.

[0071] In the embodiments described in this specification, the storage location of the second page data on the application client may be the same as or different from the storage location of the first page data on the application client. A dynamic page can refer to a target web page that has interactive functions and whose page content can change with data updates or user operations.

[0072] In the embodiments of this specification, the methods for reading the second page data may include: reading the complete second page data from the local application client at once; or reading each sub-page data in the second page data in batches from the local application client based on the rendering priority of each sub-page data in the second page data, such as prioritizing reading the sub-page data with higher rendering priority.

[0073] In the embodiments of this specification, the historical access timing for storing the second page data may be the same as or different from the historical access timing for storing the first page data. In practical applications, the historical access timing for storing the second page data can be the previous access to the target web page before the current access corresponding to the first access request. The second page data read in this access request can be the data stored by the application client after the previous access to the target web page and the completion of the final dynamic page rendering, wherein the data may include the HTML data corresponding to the dynamic elements of the page required for rendering the dynamic page at that time.

[0074] Step 208: Based on the first page data and the second page data, render the target web page that the user can interact with.

[0075] In the embodiments of this specification, the static page of the target web page can be quickly rendered using the first page data pre-stored locally on the application client; based on this, the target web page can be converted from a static page to a dynamic page using the second page data stored locally, resulting in a target web page that users can interact with by clicking, inputting, etc.

[0076] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only possible execution order. The order of some steps may be adjusted according to actual needs, or some steps may be omitted. When the claims involve method steps, changes in the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.

[0077] Figure 2 The method described above pre-stores the first page data of the static page used to render the target web page on the application client. When a user initiates an access request, the application client does not need to request this data from the server; it can directly read the locally stored first page data to quickly render the static page of the target web page. This eliminates the need for cross-network data requests, shortening the rendering time of the static page and thus improving the performance of FCP and the page rendering speed. Furthermore, the application client can also synchronously read the locally stored second page data. This second page data is used to convert the target web page from a static page to an interactive dynamic page. This second page data is stored after the page has completed dynamic rendering, based on previous user access requests to the target web page. Because the second page data is directly associated with the complete dynamic rendering results of previous accesses, it has high relative freshness. Performing the static-to-dynamic page conversion operation based on this high-freshness second page data effectively ensures the timeliness of the dynamically rendered page data, thereby improving the freshness of the target web page available for user interaction.

[0078] based on Figure 2 In addition to the method described herein, this specification also provides some specific implementation methods of the method, which will be described below.

[0079] This specification provides one specific embodiment of a method for rendering and generating a target web page that allows users to perform interactive operations.

[0080] Optionally, the first page data includes first user-state related data and user-state unrelated data, the second page data includes second user-state related data and a first document object model (DOM) fragment corresponding to the second user-state related data, and the freshness of the second user-state related data is greater than or equal to the freshness of the first user-state related data.

[0081] In the embodiments of this specification, the first user-state related data may include component element data that can interact with the user on the page, such as configuration information of interactive components like buttons, input boxes, and geolocation retrieval components, as well as interaction information between the interactive components and the user. In practical applications, since the interaction logic binding of these interactive components depends on user identity information, the first user-state related data may also include user identity information, such as user ID, avatar, and name. User-state unrelated data may be public page element data that does not depend on user identity and does not involve user interaction, such as page title, general navigation bar, and fixed text. This type of public page element data presents consistent content to all users and does not require dynamic adjustment based on user differences.

[0082] In the embodiments of this specification, the second user-state related data may include user identity dimension information, interaction component configuration information, and interaction information between the interaction component and the user, which are also included in the first user-state related data. Furthermore, the second user-state related data may also include user-state related data requested from the server based on application client feature information, such as personalized content like local service type information and compatible device models requested from the server based on the application client's geographical location information.

[0083] In practical applications, the data related to the second user state and the data related to the first user state can remain consistent in terms of user identity information, such as user ID and avatar, and interactive component configuration information, such as button function configuration and input box rules. The freshness of the interactive information contained in the two can differ. In the data related to the second user state, the freshness of the interaction information between the interactive components and the user is greater than or equal to the freshness of the interaction information in the data related to the first user state. Freshness can be understood as the timeliness of the data. The user interaction information in the data related to the second user state can be real-time interaction information generated during the last access, such as the user's previous button click operation record, while the interaction information in the data related to the first user state can be historical information stored earlier. Higher data freshness in the user interaction information in the data related to the second user state indicates that the data generation or update time of the second user state data is closer to the current access, thus accurately reflecting the user's latest interaction state. It is understandable that the data freshness of the user interaction information in the data related to the second user state can also be the same as that in the data related to the first user state; for example, no new interaction data may have been generated since the first user state data was stored until the current access time.

[0084] In the embodiments of this specification, the second page data may also include a Document Object Model (DOM) fragment corresponding to the data related to the second user state. This DOM fragment may be generated based on the data related to the second user state and may contain page structure information required for dynamic interaction, such as DOM nodes of personalized components, layout relationships of interactive elements, etc., which can be used to quickly construct the interactive structure of dynamic pages.

[0085] Optionally, the step of rendering the target web page that the user can interact with based on the first page data and the second page data may specifically include: parsing the first page data to obtain a Document Object Model (DOM) that can be read by the application client, wherein the DOM includes a second DOM fragment corresponding to data related to the first user state and a third DOM fragment corresponding to data unrelated to the user state; replacing the second DOM fragment with the first DOM fragment to obtain an updated DOM containing the first DOM fragment and the third DOM fragment; rendering a static page of the target web page based on the updated DOM; and dynamically rendering the static page using the user state data to obtain the target web page that the user can interact with.

[0086] Figure 3This is a schematic diagram illustrating a process for rendering a target web page into an interactive page that allows users to perform interactive operations, based on an embodiment of this specification. It includes steps 302 to 312.

[0087] Step 302: The application client reads the first page data from local storage.

[0088] Step 304: The application client parses the data of the first page to obtain the Document Object Model (DOM) that can be read by the application client.

[0089] In the embodiments described in this specification, the application client reads the first page data stored locally and converts the first page data into a complete Document Object Model (DOM) that the application client can read through a parsing engine. The generated DOM can contain two types of sub-fragments: a second DOM fragment corresponding to data related to the first user-mode data, and a third DOM fragment corresponding to data unrelated to the user-mode data. The second and third DOM fragments can constitute the basic structural framework of the static page.

[0090] Step 306: The application client reads the second page data from local storage.

[0091] In the embodiments described in this specification, the first page data can be HTML document data. In practical applications, the HTML document contains pre-script data. This pre-script data can read the user-mode DOM fragments (i.e., the first document object model DOM fragments) from the application client's local storage before React dynamically renders the user-mode DOM fragments from the DOM. It also reads user-mode related data from the second page data, i.e., the second user-mode related data.

[0092] Step 308: Replace the second document object model DOM fragment in the parsed and generated document object model DOM with the first document object model DOM fragment in the second page data to obtain the updated document object model DOM.

[0093] In the embodiments described in this specification, the application client can use a pre-script in the HTML document to replace the second document object model (DOM) fragment with a first DOM fragment to obtain an updated DOM. The updated DOM may include the first DOM fragment (i.e., a high-freshness user-state DOM) and a third DOM fragment (i.e., a fixed common DOM) to ensure that elements corresponding to user-state data in the static page meet timeliness requirements.

[0094] Step 310: Based on the updated Document Object Model (DOM), render and generate the static page of the target web page.

[0095] In the embodiments described in this specification, the application client can generate a static page of the target web page by simultaneously calling the rendering engine to load page styles (CSS) based on the updated Document Object Model (DOM). This allows users to quickly view the complete static page, which may include fixed common elements and high-freshness user-mode elements, meaning there is no missing content.

[0096] Step 312: Using the second user-state related data in the second page data, dynamically render the static page to obtain the target web page that the user can perform interactive operations on.

[0097] In the embodiments described in this specification, after the aforementioned pre-script reads the relevant data in the second user state, it passes the data to React. React can then use the relevant data in the second user state, based on its own client-side activation logic, to perform a watering operation on the DOM fragments in the updated Document Object Model (DOM) that are related to the user state, i.e., the first DOM fragments, to convert the static page into an interactive dynamic page. Because of the correspondence between the relevant data in the second user state and the first DOM fragments, data mismatch issues during the watering process can be reduced, thereby improving the success rate of watering. The watering operation can refer to the process of binding event handling logic, such as click and input logic, to the DOM structure corresponding to the static page, so that the originally static page elements have interactive capabilities. In other words, the watering operation can be understood as a dynamic rendering operation.

[0098] The process of retrieving the first page data stored locally on the application client can be implemented as follows: After the application client sends a request to the server, the server sends the first page data to the application client in batches via streaming. After receiving the data, the application client stores the first page data locally for use when rendering static pages later.

[0099] Optionally, the method may further include: determining whether the application client has stored first page data locally for rendering the target web page, and obtaining a first determination result; if the first determination result indicates that the application client does not store the first page data locally, then requesting the first page data from the server; and using the first page data to render the target web page to obtain the static page of the target web page.

[0100] The step of reading the first page data of the static page used to render the target web page from the local storage of the application client can specifically include: if the first determination result indicates that the first page data is stored locally in the application client, then reading the first page data of the static page used to render the target web page from the local storage of the application client.

[0101] In this embodiment, after receiving the first access request, the application client checks its local storage location to verify the existence of complete first page data matching the current target web page. In practical applications, it is necessary to verify the completeness and validity of the first page data to avoid rendering a complete static page using damaged or incomplete first page data, which would affect the user experience. If the verification result indicates that the application client has stored complete and valid first page data locally, then the static page of the target web page is rendered based on that first page data; if the verification result indicates that the application client has not stored first page data locally, or that the stored data is damaged or expired, then the application client requests the first page data from the server.

[0102] In the embodiments described in this specification, the application client sends a data acquisition request to a preset interface of the server. The data acquisition request may carry page identification information of the target web page. In response to the data acquisition request, the server returns first page data that matches the page identification information to the application client. Based on the first page data, the application client can render and generate a static page of the target web page.

[0103] In practical applications, when the application client does not store the first page data locally and needs to request it from the server, the process of the server rendering and generating a complete HTML document, i.e., the first page data, can include the following: when the application client initiates a page access request, the server can retrieve all rendered data based on the request parameters, including user-independent data, such as the page title and navigation bar structure, as well as user-related data, such as user identification and personalized interactive component configuration. Then, the page content can be split into user-independent public content and user-related personalized content through a partial prerendering (PPR) strategy. User-independent public content can refer to fixed content shared by all users, such as the page skeleton and general copy, while user-related personalized content can refer to personalized content that depends on the user's identity, such as the username and user image.

[0104] During the actual rendering phase, the server can leverage the React Suspense API to prioritize and render the split page content. First, it renders user-independent common content first, merging it with the basic HTML skeleton to generate a transmittable initial HTML portion. This initial HTML is then streamed to the application client. Upon receiving the initial HTML, the application client can quickly parse this content, enabling the rapid display of common content on the first screen, such as the navigation bar and page title. Simultaneously, the server can asynchronously process user-independent personalized content. After processing, the corresponding HTML fragments are streamed to the application client. The application client can then embed these HTML fragments into the initial HTML to form a complete HTML document. The React Suspense API is an asynchronous UI coordination tool provided by React. It's primarily used when a component needs to wait for asynchronous content, such as loading remote data or dynamically imported components. It allows React to pause the rendering of the current component and display pre-set loading placeholder content, such as "loading," until the asynchronous content is ready. Then, the pre-set loading placeholder content is replaced with the actual content to avoid blank page displays.

[0105] In practical applications, for user-independent public content within a page, when the server retrieves user-independent sub-data from the corresponding user-independent data interface, the response time of the data interface varies for different user-independent sub-data. Therefore, the common sub-content within the user-independent public content can be streamed based on the order of response time; shorter response times result in higher rendering priority, and longer response times result in lower rendering priority. In other words, response time and rendering priority are negatively correlated. Similarly, for user-related personalized content within a page, when the server retrieves user-related sub-data from the corresponding user-related data interface, the response time of the data interface varies for different user-related sub-data. Therefore, the personalized sub-content within the user-related personalized content can also be streamed based on the order of response time; shorter response times result in higher rendering priority, and longer response times result in lower rendering priority. In other words, response time and rendering priority are negatively correlated.

[0106] Under the server-side streaming rendering strategy, the complete HTML document generated by the server is not sent all at once, but is transmitted gradually in a streaming manner with public content first and user-specific content following up. This ensures the rapid presentation of user-independent content to optimize FCP performance, while the asynchronous coordination of Suspense prevents user-specific content from blocking the rendering of static pages. Finally, a complete HTML document containing all page content can be assembled on the application client to lay the foundation for subsequent static page display and dynamic hydration operations.

[0107] In scenarios where the server sends the first page data to the application client via streaming, the application client can immediately start the static rendering process based on the first page data fragments received in batches without waiting for the complete data to be received.

[0108] Optionally, the first page data includes multiple batches of subpage data, and the server sends each batch of subpage data to the application client at different times; the step of rendering the target web page using the first page data to obtain the static page of the target web page may specifically include: receiving the first page data returned by the server, wherein the server feeds back the multiple batches of subpage data to the application client in a batch-by-batch manner; and rendering the multiple batches of subpage data sequentially according to the order of the batch-by-batch feedback to obtain the complete static page of the target web page.

[0109] In the embodiments of this specification, the method by which the server divides the first page data into multiple batches of sub-page data can refer to the above-described content on server-side rendering of a complete HTML document, and will not be repeated here.

[0110] In the embodiments described in this specification, when the first page data is split into multiple batches of sub-page data, the server can send these sub-page data to the application client in batches at different times according to preset rules, such as high priority for public content and low priority for personalized content, and low priority for data interface response time and high priority for data interface response time. The application client does not need to wait for all sub-page data to be received before rendering; instead, it can render each batch of sub-page data received in the order sent by the server, and finally stitch together the rendering results of all batches to form the complete static page of the target web page. This rendering method, which combines batch transmission with sequential rendering, can shorten the initial content rendering (FCP) time compared to waiting for all data to load, allowing users to see the page skeleton in advance without waiting for all page data to load, thus improving the user experience.

[0111] Optionally, after rendering the target web page using the first page data to obtain the static page of the target web page, the process may further include: storing the first page data in the application client.

[0112] In the embodiments described in this specification, the target web page is rendered into a complete static page by gradually receiving the subpage data in batches. After the static page is rendered, the application client integrates the subpage data in batches into complete first page data and stores it locally on the application client so that it can be reused directly in subsequent accesses, avoiding duplicate requests and improving the performance of FCP of the page accessed later.

[0113] In the actual rendering process, in addition to the first page data, it may also rely on user-mode data requested from the server based on the application client's characteristic information. Examples include local service category data obtained based on the client's geolocation information and personalized content adapted to the device model. Although this type of data is not part of the first page data, it directly affects the accurate presentation of user-mode elements in static pages, such as displaying local-specific entry points and adapting layout styles for different devices. Therefore, when this type of data exists, the application client needs to store it along with the integrated first page data to ensure that subsequent renderings can quickly reuse the first page data and also call upon this personalized data, thereby improving the consistency and accuracy of page presentation.

[0114] The first page data refers to the static page data stored for the web page. Therefore, it does not include user interaction data generated after the web page is converted from a static to a dynamic page. Thus, to maintain the freshness of the rendered web page, it is necessary to store the user interaction data generated after the dynamic page is rendered.

[0115] In one or more embodiments of this specification, an embodiment is proposed for storing generated user interaction data in a snapshot storage manner.

[0116] Optionally, after rendering the target web page that the user can interact with based on the first page data and the second page data, the process may further include: requesting new user-state related data from the server, the new user-state related data including user interaction data generated after the target web page was rendered into a dynamic page during the previous access; using the new user-state related data to dynamically render the target web page that the user can interact with again to obtain an updated target web page; extracting third user-state related data and the corresponding Document Object Model (DOM) fragments from the updated target web page; and performing snapshot storage processing on the third user-state related data and the corresponding DOM fragments to obtain the second page data stored in the application client.

[0117] Figure 4 This is a schematic diagram illustrating a process for snapshot storage of second page data according to an embodiment of this specification. It includes steps 402 to 410.

[0118] Step 402: Based on the data from the first page and the data from the second page, render the target web page that the user can interact with.

[0119] Step 404: Request new user-mode data from the server.

[0120] Specifically, "new user-state related data" can refer to user interaction data generated by the dynamic page after the application client renders and displays the target web page during the user's last visit. In other words, "new user-state related data" can refer to user interaction data generated between the user and the dynamic page after the target web page is rendered into a dynamic page during the last visit. For example, if the user clicks the "follow" button on the dynamic page, the generated "new user-state related data" can be the user's "follow" data for the merchant.

[0121] In the embodiments described in this specification, when requesting new user-level data from the server, a data query request may be sent to the server first.

[0122] Optionally, requesting new user-state data from the server may specifically include: sending a data query request to the server, the data query request being used to request new user-state data from the server; if the server has new user-state data, then obtaining the new user-state data returned by the server.

[0123] In the embodiments of this specification, for the previous access request, the server is usually aware of the user interaction data generated after rendering and generating the dynamic page. After receiving the data query request sent by the application client, if user interaction data was generated after rendering and generating the dynamic page in the previous access request, such as a user purchasing an item and adding an order record, the server can send feedback information about the existence of new user state data to the application client. In response to the feedback information, the application client can request the new user state data from the server.

[0124] In practical applications, the application client may also send a request to the server to retrieve new user-level data directly, instead of sending a data query request to the server in advance. The server responds to the request by sending the new user-level data back to the application client if the server has such data, or by sending a message to the application client that no new user-level data exists if the server does not have such data.

[0125] Step 406: Using the new user-state data, dynamically render the target web page that the user can interact with again to obtain an updated target web page.

[0126] In the embodiments described in this specification, the dynamic logic corresponding to the new user-state data is rendered onto the generated target web page that the user can interact with, thus reproducing the page state at the end of the previous visit. During the actual rendering process, the application client uses React to accurately match the new user-state data with the corresponding page elements. For example, it automatically fills in leftover content in input boxes, keeps lists selected, and positions the scrollbar to the position it was at when the user left. This ensures that when the user opens the page again, the content and operable state are completely consistent with the previous state, allowing the user to continue using the page without repeating operations, thereby improving the user experience.

[0127] In practical applications, the time interval between switching from the target web page where the user can perform interactive operations to the updated target web page where the user can perform interactive operations can be on the order of milliseconds, which is imperceptible to the user.

[0128] Step 408: For the updated target web page, extract the third-user-state related data and the corresponding Document Object Model (DOM) fragments from the page.

[0129] In the embodiments of this specification, after the target web page is dynamically rendered twice to generate an updated target web page that can be interactively operated by the user, the document object model (DOM) corresponding to the page has completely contained all structural information related to the user state.

[0130] In practical applications, application clients can accurately filter and extract DOM fragments corresponding to third-user-level data from the Document Object Model (DOM) based on preset rules. These preset rules can be based on the class names, custom attributes, or node hierarchy tags specific to the user-level DOM fragments. These extracted DOM fragments typically correspond to personalized interactive areas on the page, such as user information display modules, historical operation record lists, and personalized configuration panels. After extracting the DOM fragments corresponding to the user-level data, the application client can further parse these fragments to obtain the corresponding user-level data. The parsing process can be based on preset binding relationships between fragment structures and data fields; for example, the text content of a DOM node might correspond to a username field, and the checked attribute of a button might correspond to a user's favorites status field.

[0131] Step 410: Perform snapshot storage processing on the data related to the third user state and the document object model (DOM) fragments corresponding to the data related to the third user state to obtain the second page data stored in the application client.

[0132] In the embodiments of this specification, the snapshot is stored after the target web page has been dynamically rendered and updated to allow users to perform interactive operations.

[0133] In the embodiments of this specification, storing snapshots of third-user-state related data and their corresponding DOM fragments means saving the complete data related to the user state and the corresponding DOM fragments in the current page in the form of an instant snapshot.

[0134] In practical applications, during snapshot storage, the DOM fragments corresponding to user-space data are converted into HTML strings and stored in LocalStorage, while user-space data is converted into JSON format and stored in IndexedDB.

[0135] In practical applications, if the server does not have the aforementioned new user-state related data, then after rendering the target web page that the user can interact with based on the first page data and the second page data, a snapshot storage process is performed on the user-state related data and the corresponding DOM fragments in the rendered target web page that the user can interact with.

[0136] In practical applications, the current access is a snapshot of the user interaction data generated during the previous access, while the user interaction data generated during the current access needs to be stored during the snapshot storage process of the next access.

[0137] In the embodiments of this specification, snapshot storage can capture the real-time state between user-state data and the corresponding DOM fragments, ensuring the accurate correspondence between user-state data and DOM fragments. For example, the state data of an interactive button must match the attributes of its DOM node; that is, if the button is selected, the DOM node's attribute should also be selected. This improves the success rate of dynamic page rendering based on second-page data stored in snapshot storage.

[0138] In one or more embodiments of this specification, the user interaction data generated after the dynamic page is rendered can also be updated within the first page data.

[0139] Optionally, the second page data is user-state related data extracted from the first page data;

[0140] After rendering the target web page that the user can interact with based on the first page data and the second page data, the process may further include: acquiring user interaction data generated by the user and the target web page that the user can interact with; updating the user interaction data to the user-related data in the first page data to obtain updated first page data.

[0141] In the embodiments described in this specification, the second page data can be user-state related data extracted from the first page data, that is, there is no need to store the second page data separately.

[0142] In the embodiments of this specification, after converting the target web page from a static page to a dynamic page, it is not necessary to perform snapshot storage processing on the data in the dynamic page. Once the user interacts with the dynamic page, this interaction data can be directly updated to the first page data stored locally on the application client, i.e., dynamically updating the first page data stored locally on the application client. This ensures that the first page data always synchronously reflects the user's latest interaction state. Subsequent calls to the updated first page data can also display a more up-to-date page to the user, thus simplifying the storage process and ensuring the continuity of the user's interactive experience.

[0143] As the target web page is upgraded and updated, the version of the target web page released on the server will also be updated. After the version of the target web page on the server is updated, the first page data stored locally on the application client also needs to be updated synchronously.

[0144] Optionally, the first page data includes the HTML skeleton corresponding to the target web page, and the method may further include: sending an update query request to the server, the update query request being used to request the server to determine whether the HTML skeleton corresponding to the target web page has been updated; if the query result returned by the server reflects that the HTML skeleton has been updated, then requesting new first page data corresponding to the updated HTML skeleton from the server; and caching the new first page data.

[0145] In the embodiments described in this specification, the server can generate an HTML skeleton corresponding to the target web page. The HTML skeleton is the core of the page's basic structure, determining the overall layout framework of the page. When the version of the target web page is updated, the server can generate a matching HTML skeleton.

[0146] In the embodiments described in this specification, the first page data fed back by the server to the application client may include the HTML skeleton of the target web page.

[0147] In practical applications, the application client can send update query requests to the server at preset intervals, so that the server can respond to the update query request to determine whether the HTML skeleton corresponding to the current target web page has been updated. If the server reports that the HTML skeleton has been updated, the application client can request new first page data that matches the updated HTML skeleton from the server. After receiving the new first page data from the server, the application client can use the new first page data to replace the old first page data stored locally, so as to ensure that the new web page can be rendered using the first page data stored locally in the application client.

[0148] In practical applications, during this access process, the process of statically rendering the target web page using the old first-page data stored locally in the application client and the process of updating the old first-page data are asynchronous processes. In other words, during this access, the old first-page data is still used for page rendering, and the new first-page data stored in this update is used for page rendering in the next access.

[0149] After reading the second page data from the application client's local storage, it is also necessary to verify whether the second page data can be used for dynamic rendering of a static page generated based on the first page data.

[0150] Optionally, the first page data includes a first HTML skeleton corresponding to the target web page. After reading the second page data from the client's local storage for converting the target web page from a static page to a dynamic page, the process may further include: determining whether the second HTML skeleton of the second page data is consistent with the first HTML skeleton, and obtaining a second determination result; the process of rendering the target web page that the user can interact with based on the first page data and the second page data may specifically include: if the second determination result indicates that the second HTML skeleton is consistent with the first HTML skeleton, then rendering the target web page that the user can interact with based on the first page data and the second page data.

[0151] In the embodiments of this specification, the second HTML skeleton of the second page data can be understood as the HTML skeleton in the page DOM used when extracting the second page data. The comparison between the first HTML skeleton and the second HTML skeleton can refer to comparing whether the version number of the first HTML skeleton and the version number of the second HTML skeleton are consistent.

[0152] In the embodiments of this specification, dynamic page rendering of a static page generated based on the first page data will only be performed using the second page data if it is determined that the second HTML skeleton of the second page data is consistent with the first HTML skeleton of the first page data. This can improve the success rate of dynamic rendering of the target web page.

[0153] Optionally, the first page data may also include user-state related data and user-state unrelated data;

[0154] After determining whether the second HTML skeleton of the second page data is consistent with the first HTML skeleton and obtaining the second determination result, the method may further include: if the second determination result indicates that the second HTML skeleton is inconsistent with the first HTML skeleton, then extracting the first user-state related data from the first page data; using the first user-state related data, dynamically rendering the static page of the target web page generated based on the first page data to obtain the dynamic page of the target web page.

[0155] In this embodiment, if the second HTML skeleton of the second page data read from the application client's local storage is inconsistent with the first HTML skeleton of the first page data, the read second page data is discarded to avoid problems such as element misalignment or functional failure in subsequent DOM integration or interaction binding due to skeleton structure mismatch. Simultaneously, first user-state related data is extracted from the first page data. Based on this first user-state related data, the static page of the target web page generated based on the first page data is dynamically rendered to obtain the dynamic page of the target web page. This remedial method allows the initial web page content to be displayed to the user, avoiding the display of misaligned or garbled pages due to dynamic rendering errors, thus improving the user experience.

[0156] In one or more embodiments described herein, in order to facilitate understanding of the solution by those skilled in the art, the explanation is provided using the example of a user accessing a product purchase page in a product purchase scenario.

[0157] Figure 5 This is a schematic diagram illustrating a page rendering process for a user accessing a product purchase page, provided by an embodiment of this specification. It includes steps 502 to 530.

[0158] Step 502: Obtain the user's first access request, which is used to request access to the product purchase page displayed in the application client.

[0159] In the embodiments described in this specification, the first access request can be a user's trigger operation on the product purchase page in the shopping software. For example, the trigger operation may include the user's click operation on a preset control on the homepage of the shopping software.

[0160] Step 504: In response to the first access request, request the first page data of the static page used to render the product purchase page from the server.

[0161] In this embodiment of the specification, the first page data can be a complete HTML file corresponding to the product purchase page. The HTML file includes HTML strings corresponding to each page element in the product purchase page. Each page element can include page background, page navigation bar, page title, page buttons, page input box, product attribute elements, user attribute elements, etc.

[0162] Step 506: Based on the data from the first page, render and generate the first static page of the product purchase page.

[0163] In the embodiments of this specification, the first static page can be a page that displays information such as page background color, page theme name, page icon, product purchase button, product review box, product name, product image, user ID number, and user name. None of the page elements on this page can interact with the user.

[0164] In practical applications, if there is user-state data that depends on the application client's feature information to request from the server, then it is also necessary to request the user-state data from the server and perform static page rendering on the product purchase page based on the user-state data.

[0165] Figure 6 This is a schematic diagram of a first static page of a product purchase page provided in one embodiment of this specification. For example... Figure 6 As shown, Figure 6 This includes button 601 that the user cannot click.

[0166] Step 508: Store the data of the first page locally on the application client.

[0167] Step 510: Extract user-state related data from the first page data.

[0168] In the embodiments of this specification, user-state related data may include page configuration data corresponding to page elements such as the product purchase button and product review box in the first static page. In order to establish interaction logic between the user and page elements such as the product purchase button and product review box, user-state related data may also include user ID number, user name, etc. in the first static page.

[0169] Step 512: Using the user-state data, dynamically render the first static page to generate the first dynamic page of the product purchase page.

[0170] The first dynamic page can be a page that, based on the aforementioned first static page, establishes interactive dynamic logic for page elements such as the product purchase button and product review box in the first static page.

[0171] In practical applications, if the server has new user-level data, it is necessary to request the new user-level data from the server and then dynamically render the generated dynamic page again based on the new user-level data.

[0172] Figure 7 This is a schematic diagram of the first dynamic page of a product purchase page provided in one embodiment of this specification. For example... Figure 7 As shown, Figure 7 This includes a button 701 that users can click. When button 701 is triggered, it can display product order 1, product order 2, and product order 3.

[0173] Step 514: Perform snapshot storage processing on the first user-state related data in the first dynamic page and the user-state DOM fragments corresponding to the first user-state related data to obtain the second page data.

[0174] In practical applications, if the server has new user-level data, it is necessary to perform snapshot storage processing on the data in the dynamic page after the second dynamic rendering.

[0175] Step 516: Obtain the user's second access request, which is used to request access to the product purchase page.

[0176] Step 518: Read the first page data stored locally on the application client.

[0177] Step 520: Based on the data from the first page, render and generate the second static page of the product purchase page.

[0178] In practical applications, the content of the first static page and the second static page can be the same.

[0179] Step 522: Read the second page data from the snapshot storage.

[0180] Step 524: Using the data from the second page, dynamically render the second static page to generate the second dynamic page of the product purchase page.

[0181] In practical applications, if a user renders the first dynamic page in the first access request but does not request new user-mode data from the server, then the first dynamic page and the second dynamic page can be identical.

[0182] Step 526: Request new user-mode data from the server.

[0183] In practical applications, assuming a user takes a snapshot of the data in the first rendered dynamic page during the initial access request, and then interacts with that page—for example, by purchasing a product from a product purchase page—a new purchase order is generated. In this case, the server can request the user-defined data related to this new purchase order.

[0184] Step 528: Based on the new user state data, dynamically render the second dynamic page again to generate the third dynamic page of the product purchase page.

[0185] In the embodiments described in this specification, the new user state user data may refer to the user interaction data corresponding to the new purchase order generated after the aforementioned user makes another purchase of goods.

[0186] Figure 8 This is a schematic diagram of a second dynamic page of a product purchase page provided in one embodiment of this specification. For example... Figure 8 As shown, Figure 8 This includes a button 801 that users can click. When button 801 is triggered, in addition to displaying product order 1, product order 2, and product order 3, it can also display product order 4 (802), which corresponds to the new user-state data requested from the server.

[0187] Step 530: Perform snapshot storage processing on the second user-state related data in the third dynamic page and the user-state DOM fragments corresponding to the second user-state related data to obtain new second page data.

[0188] In practical applications, during a user's next access request, the static page of the product purchase page can be dynamically rendered using the new second page data, and the new user-state user data requested in step 526 can be displayed in the rendered dynamic page.

[0189] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0190] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods.

[0191] Figure 9 This specification provides an embodiment corresponding to... Figure 2 A schematic diagram of the structure of a page rendering device for web pages.

[0192] like Figure 9 As shown, the device may include:

[0193] The acquisition module 902 is used to acquire the user's access request, the access request being used to request access to the target web page displayed in the application client;

[0194] The first reading module 904 is used to respond to the access request by reading the first page data of the static page used to render the target web page from the local storage of the application client. The first page data is the data stored by the application client based on the user's historical access to the target web page after rendering the static page for the target web page.

[0195] The second reading module 906 is used to read second page data from the local machine of the client for converting the target web page from the static page to the dynamic page. The second page data is data stored by the application client after rendering the dynamic page for the target web page based on the user's historical access to the target web page.

[0196] The rendering module 908 is used to render the target web page that the user can interact with based on the first page data and the second page data.

[0197] based on Figure 9 The embodiments of this specification also provide some specific implementation schemes of the method, which are described below.

[0198] Optionally, the first page data includes first user-state related data and user-state unrelated data, the second page data includes second user-state related data and a first document object model (DOM) fragment corresponding to the second user-state related data, and the freshness of the second user-state related data is greater than or equal to the freshness of the first user-state related data.

[0199] The rendering module 908 may specifically include:

[0200] The parsing unit is used to parse the first page data to obtain a document object model (DOM) that can be read by the application client. The DOM includes a second DOM fragment corresponding to the data related to the first user state and a third DOM fragment corresponding to the data unrelated to the user state.

[0201] The replacement unit is used to replace the second document object model DOM fragment with the first document object model DOM fragment to obtain an updated document object model DOM containing the first document object model DOM fragment and the third document object model DOM fragment.

[0202] The first rendering unit is used to render a static page of the target web page based on the updated Document Object Model (DOM).

[0203] The second rendering unit uses the second user-state data to dynamically render the static page, thereby obtaining the target web page that the user can interact with.

[0204] Optionally, the device may further include:

[0205] The first judgment module is used to determine whether the application client has stored the first page data of the static page used to render the target web page locally, and obtain the first judgment result.

[0206] The request module is configured to request the first page data from the server if the first determination result indicates that the application client does not store the first page data locally.

[0207] The second rendering module is used to render the target web page using the first page data to obtain a static page of the target web page.

[0208] The second reading module 906 may specifically include:

[0209] The reading unit is configured to read the first page data of the static page used to render the target web page from the local storage of the application client if the first determination result indicates that the first page data is stored locally in the application client.

[0210] Optionally, the first page data includes multiple batches of subpage data, and the server sends each batch of subpage data to the application client at different times.

[0211] The second rendering module may specifically include:

[0212] A receiving unit is configured to receive the first page data returned by the server, wherein the server feeds back the multiple batches of subpage data to the application client in a batch-by-batch manner.

[0213] The third rendering unit is used to render the multiple batches of subpage data sequentially according to the order of the batch feedback, so as to obtain the complete static page of the target web page.

[0214] Optionally, the device may further include:

[0215] A storage module is used to store the data of the first page in the application client.

[0216] Optionally, the device may further include:

[0217] The first request module is used to request new user-state related data from the server. The new user-state related data includes user interaction data generated after the target web page was rendered into a dynamic page during the previous access.

[0218] The third rendering module is used to dynamically render the target web page that the user can interact with again using the new user-state data, so as to obtain an updated target web page.

[0219] The first extraction module is used to extract third-user-state related data and the corresponding Document Object Model (DOM) fragments from the updated target web page.

[0220] The snapshot storage module is used to perform snapshot storage processing on the data related to the third user state and the document object model (DOM) fragments corresponding to the data related to the third user state, so as to obtain the second page data stored in the application client.

[0221] Optionally, the request module may specifically include:

[0222] The sending unit is used to send a data query request to the server, the data query request being used to request new user-level data from the server.

[0223] The request unit is used to obtain the new user-state data returned by the server if the server has new user-state data.

[0224] Optionally, the second page data is user-state related data extracted from the first page data;

[0225] The device may further include:

[0226] The second acquisition module is used to acquire user interaction data generated by the user and the target web page that the user can perform interactive operations on.

[0227] The update module is used to update the user interaction data to the user-related data in the first page data, so as to obtain the updated first page data.

[0228] Optionally, the first page data includes the HTML skeleton corresponding to the target web page, and the device may further include:

[0229] The sending module is used to send an update query request to the server, the update query request being used to request the server to determine whether the HTML skeleton corresponding to the target web page has been updated.

[0230] The second request module is used to request new first page data corresponding to the updated HTML skeleton from the server if the query result returned by the server reflects that the HTML skeleton has been updated.

[0231] A caching module is used to cache the new first page data.

[0232] Optionally, the first page data includes a first HTML skeleton corresponding to the target web page, and the device may further include:

[0233] The second judgment module is used to determine whether the second HTML skeleton of the second page data is consistent with the first HTML skeleton, and to obtain a second judgment result.

[0234] The rendering module 908 may specifically include:

[0235] The fourth rendering unit is used to render the target web page that the user can interact with, based on the first page data and the second page data, if the second determination result indicates that the second HTML skeleton is consistent with the first HTML skeleton.

[0236] Optionally, the first page data may also include user-state related data and user-state unrelated data.

[0237] Optionally, the device may further include:

[0238] The second extraction module is used to extract the first user-state related data from the first page data if the second judgment result indicates that the second HTML skeleton is inconsistent with the first HTML skeleton.

[0239] The fourth rendering module is used to dynamically render the static page of the target web page generated based on the first page data using the relevant data from the first user state, so as to obtain the dynamic page of the target web page.

[0240] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0241] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0242] The above is an illustrative scheme of a page rendering apparatus for web pages according to this embodiment. It should be noted that the technical solution of this page rendering apparatus for web pages and the technical solution of the page rendering method for web pages described above belong to the same concept. For details not described in detail in the technical solution of the page rendering apparatus for web pages, please refer to the description of the technical solution of the page rendering method for web pages described above.

[0243] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0244] Figure 10 This is a structural block diagram of a computing device provided in one embodiment of this specification.

[0245] The computing device 1000 includes: a memory 1010 and a processor 1020;

[0246] The memory 1010 is used to store computer programs / instructions, and the processor 1020 is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor 1020, they implement the steps of the page rendering method for the web page.

[0247] Specifically, the components of the computing device 1000 include, but are not limited to, a memory 1010 and a processor 1020. The processor 1020 is connected to the memory 1010 via a bus 1030, and the database 1050 is used to store data.

[0248] The computing device 1000 also includes an access device 1040, which enables the computing device 1000 to communicate via one or more networks 1060. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 1040 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0249] In one embodiment of this specification, the above-described components of the computing device 1000 and Figure 10 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 10 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0250] The computing device 1000 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 1000 can also be a mobile or stationary server.

[0251] The processor 1020 executes the computer instructions to implement the steps of the page rendering method for the web page.

[0252] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the page rendering method for web pages described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the page rendering method for web pages described above.

[0253] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the page rendering method for a web page as described above.

[0254] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the page rendering method for web pages described above. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the page rendering method for web pages described above.

[0255] An embodiment of this specification also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the page rendering method for web pages described above.

[0256] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the page rendering method for web pages described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the page rendering method for web pages described above.

[0257] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the embodiments of apparatus, devices, and systems, since they are basically similar to the method embodiments, the descriptions are relatively simple, and relevant parts can be referred to the descriptions of the method embodiments. The apparatus, devices, systems, and methods provided in the embodiments of this specification correspond to each other; therefore, the apparatus, devices, and systems also have similar beneficial technical effects to the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatus, devices, and systems will not be repeated here.

[0258] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0259] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0260] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051 F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0261] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0262] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0263] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0264] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0265] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0266] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0267] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0268] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0269] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0270] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0271] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A page rendering method for web pages, applied to an application client, comprising: Obtain the user's access request, which is used to request access to the target web page displayed in the application client; In response to the access request, the first page data for rendering the target web page is read from the local storage of the application client. The first page data is data stored by the application client after rendering the static page for the target web page based on the user's historical access to the target web page. The application client reads second page data from its local storage to convert the target web page from a static page to a dynamic page. The second page data is data stored by the application client after rendering a dynamic page for the target web page based on the user's historical access to the target web page. Based on the first page data and the second page data, the target web page that the user can interact with is rendered.

2. The method according to claim 1, wherein the first page data includes first user-state related data and user-state unrelated data, the second page data includes second user-state related data and a first document object model (DOM) fragment corresponding to the second user-state related data, and the freshness of the second user-state related data is greater than or equal to the freshness of the first user-state related data. The process of rendering the target web page, which allows the user to perform interactive operations, based on the first page data and the second page data, specifically includes: Parse the first page data to obtain a Document Object Model (DOM) that can be read by the application client. The DOM includes a second DOM fragment corresponding to the data related to the first user state and a third DOM fragment corresponding to the data unrelated to the user state. The second document object model DOM fragment is replaced with the first document object model DOM fragment to obtain an updated document object model DOM that includes the first document object model DOM fragment and the third document object model DOM fragment; Based on the updated Document Object Model (DOM), a static page of the target web page is rendered and generated. Using the data from the second user state, the static page is dynamically rendered to obtain the target web page that the user can interact with.

3. The method according to claim 1, further comprising: Determine whether the application client has stored first page data for rendering the target web page locally, and obtain a first determination result; If the first determination result indicates that the application client does not have the first page data stored locally, then request the first page data from the server. The target web page is rendered using the data from the first page to obtain a static page of the target web page; The step of reading the first page data of the static page used to render the target web page from the local machine of the application client specifically includes: If the first determination result indicates that the application client has the first page data stored locally, then the first page data of the static page used to render the target web page is read from the local storage of the application client.

4. The method according to claim 3, wherein the first page data includes multiple batches of subpage data, and the server sends each batch of subpage data to the application client at different times; The step of rendering the target web page using the first page data to obtain the static page of the target web page specifically includes: The server receives the first page data returned by the server, wherein the server sends the multiple batches of subpage data to the application client in a batch manner. Following the order of the batch feedback, the subpage data of the multiple batches are rendered sequentially to obtain the complete static page of the target web page.

5. The method according to claim 3, further comprising, after rendering the target web page using the first page data to obtain the static page of the target web page, the method includes: The first page data is stored in the application client.

6. The method according to claim 1, further comprising, after rendering the target web page available for interactive operation by the user based on the first page data and the second page data: Request new user-state related data from the server. The new user-state related data includes user interaction data generated after the target web page was rendered into a dynamic page during the previous access. Using the new user-state data, the target web page that the user can interact with is dynamically rendered again to obtain an updated target web page. For the updated target web page, extract the third user-state related data and the corresponding Document Object Model (DOM) fragments from the page; A snapshot storage process is performed on the data related to the third user state and the corresponding Document Object Model (DOM) fragments to obtain the second page data stored in the application client.

7. The method according to claim 6, wherein requesting new user-state data from the server specifically includes: A data query request is sent to the server, the data query request being used to request new user-level data from the server; If the server has new user-state data, then obtain the new user-state data returned by the server.

8. The method according to claim 1, further comprising, after rendering the target web page available for interactive operation by the user based on the first page data and the second page data: Acquire user interaction data generated between the user and the target web page that the user can interact with; The user interaction data is used to update the user-related data in the first page data to obtain the updated first page data.

9. The method according to claim 1, further comprising: An update query request is sent to the server, the update query request being used to request the server to determine whether the HTML skeleton corresponding to the target web page has been updated; If the query results returned by the server reflect that the HTML skeleton has been updated, then request the new first page data corresponding to the updated HTML skeleton from the server. Cache the new first page data.

10. The method according to claim 1, wherein the first page data includes a first HTML skeleton corresponding to the target web page, and after reading the second page data from the client's local storage for converting the target web page from the static page to the dynamic page, the method further includes: Determine whether the second HTML skeleton of the second page data is consistent with the first HTML skeleton, and obtain a second determination result; The process of rendering the target web page, which allows the user to perform interactive operations, based on the first page data and the second page data, specifically includes: If the second determination result indicates that the second HTML skeleton is consistent with the first HTML skeleton, then based on the first page data and the second page data, the target web page that the user can perform interactive operations is rendered.

11. The method according to claim 10, wherein the first page data further includes first user-state related data; After determining whether the second HTML skeleton of the second page data is consistent with the first HTML skeleton and obtaining the second determination result, the method further includes: If the second judgment result indicates that the second HTML skeleton is inconsistent with the first HTML skeleton, then extract the first user state related data from the first page data; Using the data from the first user state, the static page of the target web page generated based on the first page data is dynamically rendered to obtain the dynamic page of the target web page.

12. A page rendering apparatus for a web page, comprising: The acquisition module is used to acquire the user's access request, which is used to request access to the target web page displayed in the application client; The first reading module is used to read, in response to the access request, the first page data of the static page used to render the target web page from the local storage of the application client. The first page data is the data stored by the application client based on the user's historical access to the target web page after rendering the static page for the target web page. The second reading module is used to read second page data from the local machine of the client for converting the target web page from the static page to the dynamic page. The second page data is data stored by the application client based on the user's historical access to the target web page after rendering the dynamic page for the target web page. The rendering module is used to render the target web page that the user can interact with based on the first page data and the second page data.

13. A computing device, comprising: Memory and processor; The memory is used to store computer programs or instructions, and the processor is used to execute the computer programs or instructions, wherein when the computer programs or instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 11.

14. A computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 11.

15. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 11.

Images