Patent Description:
Webpages that are requested and presented in web browsers can identify and incorporate a variety of different files and information to render the webpage. For example, a webpage can include an HTML, which can reference various scripts, style sheets (e.g., cascading style sheets ("CSS")), images, videos, and/or other content that are retrieved and rendered as part of the website. Some content in a webpage can be static - meaning it does not change on the website-while other content on a webpage can be dynamic, which means that the content can be modified on the webpage. Some dynamic content modifications may be based on user input, such as a user selecting an option to change the layout of the website, while other dynamic content modifications may be performed automatically, such as based on a script loading and automatically modifying elements of the website.

Web browsers can use a variety of data structures to represent, manage, and present a webpage in a display. One of these data structures is a document object model ("DOM"), which stores the elements of the webpage, their attributes, and relationship to each other. The DOM can be organized in a tree structure, with nodes representing elements, such as HTML tags, and vertices representing relationships between the elements, such as one HTML tab being nested within another tag. The DOM can be dynamically modified by scripts that are loaded as part of the page, such as JavaScript files that are included and loaded with the webpage by the browser. Another data structure used by a web browser is a CSS object model ("CSSOM"), which can represent styles that have been loaded/created as part of the webpage, and that are used to style elements in the DOM. There can be mappings between the DOM and the CSSOM that are used by the browser to render the webpage.

Many web browsers additionally support the "shadow DOM," which permits for attaching a hidden separated DOM to an element. The shadow DOM permits for the nodes in the shadow DOM effectively act in a sandbox separate from the other portions of the DOM, permitting the nodes on the shadow DOM to keep their markup structure, style, and behavior hidden and separate from other code on the page. The shadow DOM can avoid conflicts between parts of the webpage. The shadow DOM allows hidden DOM trees to be attached to elements in the regular DOM tree. A shadow DOM tree starts with a shadow root, underneath which can be attached to any elements in the same way as the normal DOM. The root node of a shadow DOM can be called the "shadow root," and the node of the regular DOM tree to which the shadow root is attached can be called the "shadow host. " The place where the shadow DOM ends and the regular DOM begins can be called the "shadow boundary," and the DOM tree within the shadow DOM can be called the "shadow tree. "
<CIT> discloses a method comprising accessing, by one or more computing systems associated with a social-networking system, a structured document of a network application, the structured document comprising structural information and content comprising one or more embedded scripts, resources or identifiers for the resources. <CIT> discloses a method for implementing web applications including projecting, using a processor of a computing device, one element of a web page of a web application into a view of the web page, the view being a visual representation of a model of the web page, the model including application data and rules. <CIT> discloses a webpage feedback method implemented on a client device, comprising the steps of creating a serialized webpage document of the webpage as implemented in the browser on the client device and of the inputted feedback by the feedback script and transmitting the serialized webpage document to the remote server of the serialized annotated webpage document by the implemented feedback script. <NPL>] discloses using a custom event listener in Google Tag Manager to track interactions in Shadow DOMS. <CIT> discloses an example method of rendering a webpage including generating a first serialized eventual document object module (DOM) based on processing a first Web document referenced by a location. The first serialized eventual DOM includes first in lined dynamic content.

According to an aspect of the invention, there is provided a method for generating a static object model of a dynamic webpage, as set out in claim <NUM>.

The document generally describes technology for generating an accurate and lossless static object model of a dynamic webpage as it is rendered by a browser, including webpages that include a shadow DOM. For example, accurate representations of a webpage can be challenging, particularly when taking into account different styles that are applied to different portions of the webpage. Simply performing static analysis of a webpage, including its HTML, scripts, CSS, and other files, may fail to fully present the elements of a webpage as they will be represented in the DOM and CSSOM, and rendered in the browser. Dynamically rendering a webpage in the browser can provide a more accurate representation of the webpage, but it can be challenging to accurately export a static representation of the rendered webpage from the browser because the elements of the webpage are spread across the DOM, CSSOM, and other data structures, which may further be subject to modification based on dynamic scripts that are further modifying those data structures as part of the page. The disclosed technology provides for accurate generation of a lossless static object model of the dynamic webpage as rendered by a browser in a manner that incorporates all of the different browser data sources into a cohesive and combined object model, including portions of the webpage that are intentionally separated from other portions of the webpage, such as portions represented in the shadow DOM.

The disclosed technology additionally provides for lossless representation of rendered webpages - meaning that the static object model of the webpage can be used to reproduce the complete webpage as rendered in a browser without loss of any content, styles, or information. The models that are generated for websites can be used in a variety of ways, such as permitting for a variety of different webpage analysis (e.g., accessibility assessment, search engine optimization ("SEO"), online advertising assessment) to be performed on the webpage without having to separately render the webpage for each analysis. Additionally, the models that are generated for webpages can be used to succinctly store the content of rendered webpages, which can permit for ready tracking changes and modifications to the webpage over time.

The disclosed technology can also permit for multiple different dynamic states of a webpage to be represented within a single static object model of the webpage. For example, it can be challenging to accurately represent all of the dynamic states that a webpage may encompass, such as changes in styles, layouts, hidden and/or displayed elements, and/or other dynamic changes that can occur on a dynamic webpage as it is interacted with by a user. As a result, analysis of webpages can often be limited to analyzing the webpage as it is initially rendered when the page loads, or to attempting to infer changes that will occur from analysis of the static code (instead of the dynamically rendered content). Such limitations may render analysis performed on webpages, such as accessibility analysis which is looking to identify features that pose usability problems to users with impairments, incomplete and/or inaccurate. The disclosed technology provides a way for the dynamic states of a webpage to be accurately identified and modeled, which can permit for a more complete model of the full range of content in a webpage to be generated and for analysis of the complete dynamic webpage to be performed.

Although the disclosed inventive concepts include those defined in the attached claims, it should be understood that the inventive concepts can also be defined in accordance with the following embodiments.

Embodiment <NUM> is a method for generating a static object model of a dynamic webpage. The method comprising receiving, at a computer system, a webpage from a web server; instantiating, by the computer system, a headless web browser application to render the webpage, wherein the headless web browser includes browser memory and is configured to render the webpage by creating a document object model ("DOM") and a cascading style sheet object model ("CSSOM") in the browser memory, the DOM and the CSSOM representing dynamic rendered content of the webpage; injecting, by the computer system, a probe script into the headless browser, wherein the probe script is configured to retrieve the dynamic rendered content of the webpage; traversing, by the probe script, the DOM, including traversing regular nodes of the DOM and shadow nodes of a shadow DOM that is attached to regular nodes of the DOM; retrieving, by the probe script, dynamic information for the regular nodes and the shadow nodes from, at least, the DOM and CSSOM, wherein the information includes style information for the DOM and shadow style information for the shadow DOM; building, by the computer system, a static object model of the webpage based on the dynamic information, wherein the static object model including (i) the regular nodes, (ii) the shadow nodes, (iii) the style information for the DOM, (iv) the shadow style information, and (v) structural features delineating separate styles applying to the regular nodes and the shadow nodes; and outputting, by the computer system, the static object model for the webpage.

Embodiment <NUM> is the method of embodiment <NUM>, wherein traversing the nodes of the DOM comprises recursively traversing the DOM using a recursive function that instantiates separate recursive instances for child nodes and shadow host nodes to which a shadow root node is attached.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the static object model includes one instance of the style information for the DOM that is positioned within an hierarchical structure of the static object model to indicate an association with only the regular nodes, and the static object model includes one instance of the shadow style information for the shadow DOM that is positioned within the hierarchical structure of the static object model to indicate an association with only the shadow nodes.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the traversing is performed in response to detecting a load event generated by the headless browser for the webpage.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, further comprising simulating, by the probe script, an additional state of the webpage in the headless browser; traversing, by the probe script, the DOM in the additional state, including traversing the regular nodes and the shadow nodes in the additional state; retrieving, by the probe script, dynamic state information for the regular nodes and the shadow nodes in the additional state; and adding, by the computer system, the dynamic state information to the static object model for the regular nodes and the shadow nodes.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, further comprising: determining, by the computer system, whether the dynamic state information is different from the dynamic information for the nodes and the shadow nodes; wherein only portions of the dynamic state information that are determined to be different from corresponding portions of the dynamic information are added to the static object model.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the dynamic information added to the static object model comprises difference information identifying only differences between the dynamic state information and the dynamic information.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the dynamic state information is added to the static object model as data fields within data structures for the regular nodes and the shadow nodes already added to the static object model based on the dynamic information.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, further comprising identifying a plurality of dynamic elements that are part of the webpage; wherein the simulating, the traversing, the retrieving, and the adding with regard to the additional state are performed for each of the plurality of dynamic elements.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, further comprising: identifying a plurality of input options for each of the dynamic elements; wherein the simulating, the traversing, the retrieving, and the adding with regard to the additional state are performed for each of the input options for each of the plurality of dynamic elements.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the static object model is configured to be used by multiple different webpage analysis pipelines to analyze the dynamic content of the webpage without rendering the webpage.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the static object model is built with a hierarchy of nodes having relationships that are represented by nested relationships among the regular nodes and the shadow nodes.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the shadow nodes are represented together and nested within the relationships with the regular nodes.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the static object model is built with a nodes list that stores the regular nodes and the shadow nodes in an array that is addressable via a nodes list index.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein child nodes are identified within the regular nodes and the shadow nodes using references to node list index values for the child nodes.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the static object model is further built with a strings list that stores unique string values from the regular nodes and the shadow nodes in an array that is addressable via a string list index.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the regular nodes and the shadow nodes include references to common string list index values.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, further including identifying one or more annotations for at least a portion of the regular nodes and at least a portion of the shadow nodes; adding the one or more annotations to the at least a portion of the regular nodes and the at least a portion of the shadow nodes in the object model.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the one or more annotations correspond to identifications of page segments in the webpage using a segmentation engine.

Embodiment <NUM> is the method of any one of embodiments <NUM> through <NUM>, wherein the identifications of the page segments are determined for a website that includes the webpage and other webpages.

The devices, system, and techniques described herein may provide one or more of the following advantages. For example, the disclosed technology can permit for accurate and lossless static object models of webpages to be generated, which can improve the accuracy of webpage analysis features (e.g., accessibility analysis systems, SEO analysis systems, ads performance systems, webpage quality assessment systems).

Additionally, the static object models that are generated with the disclosed technology can provide the computational efficiencies of static webpage analysis, which can be performed without the computation resources required to render and analyze a rendered webpage, while providing significant improvements in the accuracy of the analysis that is performed. For example, with static analysis there can be significant gaps and/or omissions in the analysis since the dynamically rendered content of the webpage may deviate and differ significantly from the static content as represented in the static webpage files (e.g., HTML files, scripts, CSS). The disclosed technology can permit for the webpage as rendered to be accurately represented and analyzed without having to render the webpage. Such a structure can permit for a webpage to be rendered a single time, the object model to be generated, and then for the object model to simply be shared across multiple different webpage analysis pipelines without having to be re-rendered for each pipeline - creating increased efficiency and decreasing the computation resources required across the pipelines.

In another example, the disclosed technology can permit for complete spectrum of states that may occur for a webpage to be accurately captured in a static object model, which can further increase the efficiency and accuracy with which website analysis pipelines can perform their analysis on a webpage.

The document generally describes technology for generating an accurate and lossless static object model of a dynamic webpage as it is rendered by a browser, including webpages that include a shadow DOM.

<FIG> is a conceptual diagram of example system <NUM> for generating an object model of a webpage. The example system <NUM> includes a web content analysis system <NUM> that can request and receive a webpage <NUM>, which can include multiple different components, such as HTML <NUM>, scripts <NUM> (e.g., JavaScript), CSS files <NUM>, and/or other files <NUM> (e.g., images, content files, videos). The webs content analysis system <NUM> can be any of a variety of computer system, such as a server system, a cloud-based system, an end user device (e.g., laptop, mobile device), and/or combinations thereof.

The webpage <NUM> can additionally be requested by client devices <NUM>, such as laptops, mobile devices, and/or other client computing devices, which can use a browser application <NUM> to render the webpage <NUM> using the files <NUM>-<NUM> (<NUM>). In the example browser <NUM> that is depicted, the rendered webpage <NUM> includes static content <NUM> and dynamic content <NUM>. The static content <NUM> can be content that does not change as part of the webpage <NUM>, such as an HTML tag in the HTML <NUM> that is not modified by a script <NUM>. The dynamic content <NUM> can be content that is modified in some way (e.g., added, removed, changed) during loading, presentation, and/or use of the webpage <NUM> in the browser, such as elements that are modified based on user input. The dynamic content <NUM> includes various states A-N 124a-n that are entered into by the browser <NUM> while the webpage <NUM> is being presented.

The web content analysis system <NUM> includes an object model builder <NUM> that is configured to build a static object model of the webpage <NUM> as it is rendered in the browser <NUM>. The object model builder <NUM> accomplishes this through the use of a headless browser <NUM> (e.g., headless Chromium browser), which can be run and used to render a webpage as it would be presented in the browser <NUM> on the client device <NUM> without requiring user input and/or a display. The object model builder <NUM> can run the headless browser <NUM> and direct it to render the webpage <NUM>, as indicated by step B (<NUM>). As part of this, the headless browser can receive the webpage files <NUM> from the object model builder <NUM>, and the browser code <NUM> can build the dynamic webpage in the browser's memory <NUM>, as indicated by step C (<NUM>). Rendering the webpage <NUM> can include building a DOM <NUM>, a CSSOM <NUM>, and a mapping <NUM> there between for the webpage <NUM>. As shown in the example that is depicted, the DOM <NUM> can include a regular portion <NUM> of the DOM as well as a shadow DOM <NUM>, which is attached to an element of the regular portion <NUM> of the DOM <NUM>, but which has a different style B <NUM> in the CSSOM <NUM> from the style A <NUM> that is mapped to the regular portion <NUM> of the DOM <NUM>.

The object model builder <NUM> can inject a probe script <NUM> (e.g., JavaScript) into the headless browser <NUM> to query and retrieve data from memory <NUM> in order to build the object model for the webpage <NUM>. The probe script <NUM> can interact with the browser code <NUM> (e.g., submit queries, instructions, and/or other requests for access to data in the memory <NUM>) to obtain data from the DOM <NUM>, the CSSOM <NUM>, as well as the mappings <NUM>, as indicated by step D (<NUM>). For example, the probe script <NUM> can traverse all of the nodes in the DOM <NUM>, including the shadow DOM <NUM> and its nodes, while retrieving corresponding attributes and information about each of the nodes, which can be returned to the object model builder <NUM>, as indicated by step E (<NUM>). The object model builder <NUM> can build a static object model <NUM> of the dynamic webpage as rendered by the headless browser <NUM>, as indicated by step F (<NUM>). The object model <NUM> can be output, as indicated by step G (<NUM>), which can permit for accurate and lossless analysis of the dynamically rendered webpage <NUM> by other systems without having to separately render the webpage <NUM>.

The probe script <NUM> may obtain the data from the memory <NUM> after one or more events occur for the webpage, such as a loading event having occurred indicating that the webpage has loaded in memory <NUM>. In some instances, the data retrieved by the probe script <NUM> may be limited to only data from memory <NUM> that is retrieved on loading of the page, meaning that the resulting object model <NUM> represents the webpage <NUM> as initially loaded/rendered. In some other instances, the probe script <NUM> can provide simulated input, commands, and/or other instructions to the browser code <NUM> to cause the different states 124a-n of the dynamic content <NUM> to be rendered in memory <NUM>, and data for each of those states 124a-n can be retrieved by the probe script <NUM> and incorporated into the resulting object model <NUM> for the webpage <NUM>.

Although the above process flow and system <NUM> is described with regard to generating the object model <NUM> using the headless browser <NUM> (i.e., instantiating an instance of the headless browser <NUM> for the webpage <NUM>), the same process flow (steps A-G) can be performed by other browsers, such as by browsers with user interfaces (e.g., Chrome browser, Firefox browser) configured to run on user computing devices (e.g., laptop, desktop computer, smartphone, tablet). For example, the process flow (steps A-G) can additionally and/or alternatively be performed on the web browser <NUM> (non-headless browser) running on the client computing device <NUM>, which renders and presents the webpage. The object model builder <NUM> can be run on the client computing device <NUM> (e.g., Javascript code run by the browser <NUM> when rendering the webpage) and the probe script <NUM> can be injected into and used to traverse the rendered webpage data structures, including the DOM <NUM> and the CSSOM <NUM> as stored in memory (not depicted) on the client computing device <NUM>, as described with regard to the process flow (steps A-G). Discussions of these or other features throughout this this document, even if illustrated with regard to a specific type of browser (e.g., a headless browser), can be performed by any of a variety of browsers, such as headless browsers, browsers rendering and presenting web page content, and/or other browsers.

Additionally, the process flow (steps A-G) as well as other processes, techniques, and methods described throughout this document can be performed prior to publication of web content one or more web servers. For example, the process flow (step A-G) can be performed on pre-published content, such as content that is being edited and/or previewed prior to being made available for public access on a web server. Such pre-published content may have an associated URL (i.e., internal URL that is not published or linked to from other public-facing sites) and/or may simply include content that is under development/edit without a specified URL.

Furthermore, the process flow (steps A-G) can be performed on demand - meaning that the process flow may be prompted and/or triggered in response to user selection of an option to capture and transmit the object model. For example, a user browser may be configured to include a selectable option (e.g., button, menu entry), such as through a browser plugin or through a iframe or wrapper within which another webpage is presented, that a user can select to capture the object model for a webpage, such as when a user has transitioned the webpage into a particular state.

<FIG> is an example <NUM> of an object model generated for an example webpage. The depicted example <NUM> can be generated using any of a variety of systems, such as the web content analysis system <NUM>.

The depicted example <NUM>, which is simplified for illustrative purposes, includes HTML code <NUM> that includes a "styleA" that designates the text in DIV tags to be rendered bold, along with a DIV tag with the text "List Title" and another DIV tag with the id "host. " The script <NUM> for the webpage includes JavaScript code to instantiate a shadow root that, when the script is run, will cause the shadow root to be attached to the "host" DIV element. The script further includes code to add two DIV elements (with the text "List item <NUM>" and "List item <NUM>") to the shadow root, and to further designate a "styleB" for the shadow root that uses normal font weight (not bold).

A browser <NUM> can receive and render the code <NUM>-<NUM> for the webpage, which results in generation of the example DOM <NUM> and the example CSSOM <NUM>, which are both simplified for presentation. Each of the tags that are presented in the DOM <NUM> correspond to a node, and vertices between the nodes represent hierarchical nested relationships between the tags. Note that the DIV tag with the "host" ide includes a shadow-root that includes it's the shadow DOM with the DIV elements mentioned above.

The object model builder <NUM>, which can be similar to the object model builder <NUM>, can access the DOM <NUM> and the CSSOM <NUM> to generate the example object model <NUM>, which is presented in a simplified format. The example object model <NUM> incorporates and combines the static and dynamic features in the DOM <NUM> and the CSSOM <NUM>. In the depicted example, nodes are represented with enumerated types <NUM>, the name of the element <NUM>, and attributes <NUM> related to the element. The attributes <NUM> can include any of a variety of elements, such as the namespace_uir, the prefix, the local_name, and the value. Other attributes are also possible. The node <NUM> can further include an extensible field for child nodes <NUM>, which can include all of the same data elements for each child node. The shadow host node <NUM> to which the shadow root is attached is depicted. Each element can include a "shadowRoot" field, which can designate the presence (or absence) of a shadow DOM attached to the element. In this example, the shadowRoot field <NUM> for the shadow host node <NUM> includes the shadow root node <NUM> which designates a document fragment separate from the remainder of the elements on the webpage. The shadow root node <NUM> includes the example node <NUM> for the DIV tag "List item <NUM>" that is presented in the displayed page <NUM>. The shadow root <NUM> further includes a stylesheet field <NUM> that designates the styles for the document fragment provided by the shadow DOM, which are different from the style <NUM> that applies to the document outside of the shadow DOM. The object model <NUM> can accurately model the entire dynamic content of the webpage, including the shadow DOM, in a manner that is lossless and avoids the loss of elements, styles, and/or other content.

<FIG> is a flowchart of an example process <NUM> for generating a lossless static object model for a webpage. The example process <NUM> can be performed by any of a variety of systems, such as the web content analysis system <NUM>, the object model builder <NUM>, and/or the object model builder <NUM>.

For a webpage rendered by a browser, such as a headless browser, the root node of the DOM for the webpage can be selected (<NUM>). The probe script <NUM> is injected into a headless browser and is used to traverse the DOM for the rendered page, such as in response to a load event having been received for the webpage. Styles for the document are retrieved from the CSSOM and added to the object model (<NUM>), such as styles that apply to the regular DOM. The object model is iteratively built based on data that is retrieved and/or received from the probe script, which in some instances may build some or all of the portions of the object model.

A recursive node traversal and evaluation function can be called for the selected node (<NUM>). This function can include determining and adding an enumerated type for the selected node to the object model (<NUM>). Any of a variety of types for nodes can be designated and used, such as an element type, an attribute type, a text type, a comment type, a document type, and a document fragment type, such as a node designating a separated shadow DOM. Additional and/or alternative types are also possible. Information for the selected node can be accessed and added to the object model (<NUM>), such as the namespace URI, prefix, local name, value, text, attributes (e.g., elements designating values of another element, such as an id value for an element), and/or other information. If there are any unevaluated children of the selected node (<NUM>), then a child node can be added to the object model (e.g., element for the child node added to model) and the next child node can be selected (<NUM>). The selected child node is then processed through another instance of the recursive function <NUM>. The recursion can continue through all nodes of the DOM until the full DOM has been traversed and added to the object model for the webpage.

If there is not an unevaluated child node of the selected node (<NUM>), then a determination can be made as to whether the selected node has an attached shadow root with a shadow DOM (<NUM>). If there is a shadow root at the selected node (<NUM>), then the styles for the shadow DOM document fragment is retrieved and added to the object model, along with a node in the object model for the shadow root (<NUM>). For example, the shadow root node <NUM> can be added for the shadowroot field <NUM>, and the styles <NUM> applying to the shadow root can be added to the shadow root <NUM>, as well. Once the shadow root has been added to the object model, the shadow DOM for the shadow root is traversed in the same way as other nodes that are part of the regular DOM. A determination can be made as to whether there are any unevaluated nodes of the shadow DOM (<NUM>). If there are, then the next node from the shadow DOM can be selected for evaluation by the recursive function <NUM> (<NUM>). By traversing into the shadow DOM, the entirety of the DOM is replicated into the object model, permitting for the complete DOM to be captures. Additionally, by designating that the elements of the shadow DOM are part of a document fragment associated with a separate group of styles, the object model can be lossless. If there are no more nodes of the shadow DOM remaining (<NUM>) or if the selected node does not have a shadow root (<NUM>), then the recursive function instance for the selected node can return (<NUM>), which simply returns processing back to the parent recursive instance that called the present recursive instance. Once all recursive instances have been returned, then the object model can be output for the webpage (<NUM>).

<FIG> is a diagram of an example system <NUM> for generating lossless static object models for webpages. The example system <NUM> includes a web content analysis system <NUM>, which can be similar to the web content analysis system <NUM> and other systems/processes described throughout this document.

The web content analysis system <NUM> includes an object model builder <NUM>, which can be similar to the object model builder <NUM> and/or the object model builder <NUM>, described above. The object model builder <NUM> can request and receive webpages over one or more networks <NUM> (e.g., internet, local area networks, wide area networks, virtual private networks) from web server systems <NUM>. The webpages can include multiple different types of files and data that are hosted and served by the web server systems <NUM>, such as HTML files <NUM>, scripts <NUM>, CSS sheets <NUM>, and/or other files <NUM> (e.g., image files). The object model builder <NUM> can provide webpage files to a headless browser <NUM>, which can render the dynamic webpage as described above. The object model builder <NUM> injects one or more probe scripts <NUM> into the headless browser <NUM> to obtain information on the dynamic webpage as rendered by the headless browser <NUM>. The object model builder <NUM> uses that information to generate an object model for the webpage, which can be stored in an object model database <NUM>. The object model database <NUM> can be any of a variety of data storage systems, such as a cloud based data storage system, and may be configured to store instances of the object model for a particular website over time (e.g., generate and store an object model for the webpage every time it is crawled by a web crawler, such as hourly, daily, weekly, monthly).

The web content analysis system <NUM> further includes a web content analyzer <NUM>, which can be used to assess an overall quality of the webpage. The web content analyzer <NUM> can include separate analysis pipelines, such as an SEO analyzer <NUM>, a QA analyzer <NUM>, an accessibility analyzer <NUM>, and/or a page segmentation engine <NUM>. The page segmentation engine <NUM> can use various techniques, systems, and/or processes, such as machine learning techniques, to automatically identify segments of a webpage, such as menus, headers, footers, and/or other structural and/or contentbased segments or sections within a webpage. An example of a page segmentation engine <NUM> is described in <CIT> and <CIT>. Additional and/or alternative analysis pipelines are also possible. The web content analyzer <NUM>, which may combine the results of each pipeline, as well as each of its separate pipelines <NUM>-<NUM>
may access and use the object model for a webpage from the object model database <NUM>, which can permit for the dynamic content of the webpage to be analyzed without each analyzer <NUM>-<NUM> having to separately render the dynamic webpage.

The web content analysis system <NUM> also includes a webpage rebuilder <NUM> and a reconstruction script <NUM>. The webpage rebuilder <NUM> can reconstruct webpages, including their structure, content, and styles, including both static and dynamic content, using object models generated by the object model builder <NUM> and stored in the object model database <NUM>. The webpage rebuilder <NUM> can use a reconstruction script <NUM>, which can interface with the headless browser <NUM> to reconstruct the webpage within memory (i.e., reconstruct the DOM and CSSOM) using the object models in the object model database <NUM>. The webpage rebuilder <NUM> and reconstruction script <NUM> may be used by one or more portions of the web content analyzer <NUM> to perform their web content analysis. Additionally and/or alternatively, the web content analyzer <NUM> and its components <NUM>-<NUM> can access the object models stored in the object model database <NUM> to perform their analysis. The webpage rebuilder <NUM> and reconstruction script <NUM> may be separate from and called by the web content analyzer <NUM> (i.e., as an API), and/or they may be implemented as part of the web content analyzer <NUM> and/or one or more of its components <NUM>-<NUM>.

The system also includes client devices <NUM> that can also interact with the web server systems <NUM> to present webpages in a browser application <NUM>.

<FIG> is a conceptual diagram of an example system <NUM> for generating a static object model incorporating multiple states of dynamic elements in a webpage. The system <NUM> can be similar to the systems <NUM>, <NUM>, and <NUM> described above.

In the depicted example system <NUM>, the webpage <NUM> includes dynamic content, such as dynamic scripts that are part of the webpage, that can cause nodes AN (504a-n) to enter various states. The webpage <NUM> can also include static nodes <NUM> that, based on the configuration of the webpage, do not change. In the depicted example, the object model builder <NUM> probes and obtains state information for the dynamic nodes 504a-n, as indicated by step A (<NUM>). For example, the probe script <NUM> is configured to inject various commands, simulated inputs, and/or other instructions to the headless browser to get the browser to cause the webpage to assume the states for the dynamic nodes 504a-n. When each of these states are achieved, the probe script captures information about the dynamic nodes 504a-n, which the object model builder <NUM> can used to build a static model of the dynamic webpage states, as indicated by step B (<NUM>). An example process for doing this is described below with regard to <FIG>. The object model builder <NUM> outputs the model once generate, as indicated by step C (<NUM>).

An example depiction of a static model <NUM> that includes dynamic state information for webpage elements is presented. In the example, which is shown for illustrative purposes, the dynamic node A includes an additional state field <NUM> that can include information about the dynamic node 504a in each of the states that are represented. For example, an element for "State <NUM>" can be added along with information <NUM> about the node 504a (e.g., text, attributes) when it was in "State <NUM>. " Information for each of the states for node 504a can be presented, such as with the element <NUM> for "State <NUM>. " In order to reduce the size of the object model, particularly when a webpage has a large number of elements that are capable of assuming multiple different states, the node information for subsequent states can optionally include difference information <NUM>, which is a difference in the information from the information for one or more of the other states for the node 504a (e.g., difference as compared against the first state). Such a configuration can minimize the size of the resulting object model without losing any of the details.

<FIG> are flowcharts of example processes <NUM> and <NUM> for generating a static object model incorporating multiple states of dynamic elements in a webpage. The processes <NUM> and <NUM> can be performed by any of a variety of systems, such as the web content analysis system <NUM> and its component parts, the object model builder <NUM>, the web content analysis system <NUM>, and/or the object model builder <NUM>. The processes <NUM> and <NUM> can be used, for example, to generate the static model capturing dynamic states of a website, such as the model <NUM> described above with regard to <FIG>.

Referring to <FIG>, a comprehensive object model for the initial load state of a webpage can be generated and initialized (<NUM>). For example, an object model of a webpage when loaded can be generated, for example, using the process <NUM> described above with regard to <FIG>. This initial object model can serve as a starting point from which various states of the webpage can be achieved, and into which states information for elements can be added.

A dynamic element can be selected (<NUM>). A dynamic element can include, for example, elements that have event listeners attached to them (e.g., JavaScript event listeners), elements that are capable of receiving user input, elements that have script attached to them, and/or others dynamic elements. Input options for the selected dynamic element can be identified (<NUM>). For example, the various types of events that can be generated for a corresponding event listener can be determined. In another example, if a user input field includes an enumerated set of selectable options for a user, such as a drop down menu or selectable radio buttons, each of the options can be identified as an input option. The identified input options may be limited to only options that are determined to result in one or more permitted actions (i.e., permitlist actions) being performed on the webpage and/or that are determined to not perform one or more denied actions (i.e., denylist actions) from being performed. Permitlist and denylist actions may be used, for example, to avoid the probe script from performing harmful actions, such actions that may result in an account being deleted, content being posted to a third party site, and/or other actions that may be bad if performed. An example algorithm to identify input options to be performed is described below with regard to <FIG> and process <NUM>.

A first input option can be selected (<NUM>) and input to the dynamic element to cause the webpage to, potentially, achieve a different state for one or more nodes (<NUM>). To determine whether a different state is achieved, a state object model for the current state of the webpage can be generated, for example, using the process <NUM> (<NUM>), and can be compared against the initial state of the webpage as represented in the comprehensive model of the webpage (<NUM>). New states may be achieved for nodes associated with the dynamic element, and/or for other nodes that are not associated with the dynamic element. The new states can be identified, for example, by identifying differences in node values between the state object model and the initial state reflected in the comprehensive model. If differences are identified for nodes, then they can be added to the comprehensive model in an additional state, including the entire state information for the nodes and/or only difference information as compared against the initial state information for the nodes.

If more input options are available for the selected dynamic element (<NUM>), then the steps <NUM>-<NUM> can be repeated until all input options have been tested and state information has been added to the comprehensive model. Once all of the input options have been exhausted, a determination can be made as to whether there are more dynamic elements on the webpage (<NUM>). If there are more dynamic elements, then the steps <NUM>-<NUM> can be repeated for each dynamic element. Once all of the dynamic elements and their input options have been tested and evaluated, then the comprehensive object model can be output (<NUM>).

Referring to <FIG>, the process <NUM> includes receiving identification of an input option for a selected dynamic element (<NUM>). The process <NUM> may be performed for each input option identified for a selected dynamic element. A determination can be made as to whether the input option should be simulated for the dynamic element (<NUM>), which can include determining whether the action to be performed by the input option would be permitted (i.e., on a permitlist of permitted actions) and/or not permitted (i.e., on a denylist of unpermitted actions).

Parameters and context for the input option can be identified (<NUM>). For example, the destination URL for an input option, parameters to be passed with and/or appended to the destination URL, metadata associated with the input option, a position of the input option within a DOM tree for the website, a segment of the website within which the input option appears, text that is part of and/or positioned nearby the input option, and/or other information can be identified.

A projected action associated with the input option can be determined (<NUM>). For example, the parameter and the context information for the input option can be used to project an expected action that will caused to be performed via the input option without performing the action. Such a determination can be made, for example, using one or more machine learning models that are trained on the webpage and/or website from which the website is retrieved. For example, input options, their resulting actions, and associated parameters and/or context for various webpages on a website can be used to train a machine learning model for the website that can then be used to estimate an expected action associated with the input option. Models for similar or related websites may be used for other websites, such as websites that are designed by similar web design services and/or software systems may be sufficiently similar to permit for models trained on one website to be used on other, similar websites.

A determination can be made as to whether the projected action is of a permitted type and/or of an unpermitted type (<NUM>). For example, as discussed above, the determination of whether the projected action is permitted can be based on permitlists and/or denylist of actions - defining actions that are permitted as an identified input option (i.e., action on a permitlist) or actions that are not permitted as an identified input option (i.e., action on a denylist). If the action is of a permitted type, then it can be kept on a list of input options for the selected dynamic element (<NUM>), and subsequently processed through steps <NUM>-<NUM> of process <NUM>. If the action is not of a permitted type (<NUM>), such as via the action either not being on a permitlist (if permitlists are being used) and/or is present on a denylist (if denylists are being used), then the input option can be removed as an input option for the selected dynamic element (<NUM>). Removing the input option can result in the input option not being included in the identified input options in step <NUM>, and also the input option not being processed through steps <NUM>-<NUM>.

<FIG> are conceptual diagrams of example systems <NUM> and <NUM> for adding annotations to an object model of a webpage. The example systems <NUM> and <NUM> can be similar to and used in combination with the systems described above with regard to <FIG>. The systems <NUM> and <NUM> can be used to add annotations to the object models for webpages, where the annotations are additional details and/or information generated by systems, such as a page segmentation engine. The annotations can include additional details that can enhance and/or annotate portions of the object model, which can aid in enhanced analysis of the webpage and its content by other systems, such as the web content analyzer <NUM>.

Referring to <FIG>, the example system <NUM> is similar to the system <NUM>, but with the addition of page analysis/annotation engines <NUM> that are configured to analyze the webpage (i.e., HTML <NUM>, script <NUM>, DOM <NUM>, CSSOM <NUM>) and/or the object model <NUM> of the webpage to determine annotations based on the analysis. An example analysis/annotation engine depicted as part of the example system <NUM> is a page segmentation engine <NUM> (similar to the page segmentation engine <NUM> described above with regard to <FIG>). Other analysis/annotation engines are also possible. The page segmentation engine <NUM> can, for example, identify segments that are associated with the nodes for the webpage that are represented in the object model <NUM> and can add them inline within the object model <NUM>. An example depiction of this is presented with example segment annotations <NUM>-<NUM> being added in-line with the webpage object model data structure and its data elements <NUM>-<NUM>. For example, the first node <NUM> can be identified as part of segment X by the annotation <NUM>.

Such annotation information (e.g., segment information) can provide a variety of efficiencies and improvements to object models, such as by storing information within the object model that may be accessed and used by multiple other, downstream systems (e.g., web content analyzers <NUM>-<NUM>). By storing information inline instead of in a database that would have to be accessed at runtime by each of the content analyzers <NUM>-<NUM>, it can make processes using the object models more efficient by reducing the database calls and network traffic to query and respond with the annotation information. Additionally, by storing the annotation information inline instead of determining it at runtime, it can also make the process of using the objects more efficient by permitting the content analyzers <NUM>-<NUM> to process the information without having to wait for a response from an annotation engine <NUM>.

Referring to <FIG>, the example system <NUM> presents an example annotating object models for two webpages 750a (page1) and 750b (page2) from a website with segment information using the page segmentation engine <NUM>, which can identify common page segments across the webpages 705a-b. For example, the page segmentation engine <NUM> can access page data <NUM> and/or object models <NUM> for the pages 750a-b and identify headers, menus, titles, content, and footers <NUM>-<NUM> (example segments). Each of these segments can be designated with a unique identifier by the page segmentation engine <NUM>, which in the depicted example range from Segment1 - Segment9. These segment identifiers can be stored in a page segment database <NUM>, a simplified example of which is depicted in <NUM>. As depicted in the example, some segments can appear across multiple pages P1 and P2 (i.e., Segment1, Segment3), whereas others may only appear in one of the pages (i.e., Segment2).

The object model builder <NUM> can access the page data <NUM> to generate object models <NUM> for the pages P1-P2 (750a-b), which can be stored in the object model database <NUM>. The object model builder <NUM> can access the page segment data <NUM> that is generated by the page segmentation engine <NUM> and use the segment information to further annotate the object models. For example, as depicted in the example and simplified object models <NUM>-<NUM>, the nodes can be annotated with the corresponding segment identifiers (i.e., Segment1-Segment9) in the object models. As depicted, these identifiers can reference unique identifiers that are resolved via a separate system from the object model builder <NUM>, which in this case is the page segmentation engine <NUM> and the page segment database <NUM>. Alternatively, the page segment information may be encoded within the object model itself (i.e., encoded with enumerated value identifying type of segment (e.g., menu, header, footer) instead of specific segment (e.g., specific header that is Segment1)). The segment information, as well as other annotation information, may draw on inferences and analysis from other webpages beyond just the webpage to which the object model pertains. For instance, the object model <NUM> for page P1 750a include annotations that are derived by the page segmentation engine <NUM> through analysis of the pages P1 and P2 (750a-b) together to determine the segments.

<FIG> is a flowchart of an example process <NUM> for adding annotations to an object model of a webpage. The example process <NUM> can be performed by any of a variety of systems and/or devices, such as the web content analysis system <NUM> and its component parts, the object model builder <NUM>, the web content analysis system <NUM>, the object model builder <NUM>, and/or the systems <NUM> and <NUM>, such as by the page analysis annotation engines <NUM> and/or the page segmentation engine <NUM>. The example process <NUM> may additionally be performed in combination with and/or as part of any of a variety of other processes, such as the processes <NUM>, <NUM>, and/or <NUM>. For example, the process <NUM> can be performed as part of step <NUM> of process <NUM> and/or step <NUM> of process <NUM>.

A node for a page can be selected (<NUM>) and object model annotations can be generated for the selected node (<NUM>). A segment for the selected node can be determined (<NUM>) and a segment identifier for the selected node can be retrieved (<NUM>). For example, the page segmentation engine <NUM> can process the node, determine a segment for the node, and provide a segment identifier and/or other information for the segment. In some instance, other information for the selected node can also be determined (<NUM>), such as through the use of other annotation/analysis engines that are part of the analysis/annotation engine <NUM>. The segment identifier/information for the selected node can be added to the object model for the page (<NUM>) and other information determined in step <NUM> for the selected node can be added to the object model for the page (<NUM>).

<FIG> is a conceptual diagram of an example system <NUM> for reconstructing a webpage using an object model of the webpage. The example system <NUM> can be similar to and used in combination with the systems described above with regard to <FIG>. The system <NUM> can be used to reconstruct webpages from object models so that they can be used by other systems, such as the web content analyzer <NUM> and its components <NUM>-<NUM>. The system <NUM> includes a webpage rebuilder <NUM> and a reconstruction script <NUM>, similar to the webpage rebuilder <NUM> and the reconstruction script <NUM> described above with regard to <FIG>.

Databases storing object models <NUM> and accessory files <NUM> (i.e., images, videos, other non-webpage files referenced in the webpage code) for webpages can provide the object model and/or accessory files for a webpage, as shown in step A.

The accessory files for a webpage can be stored as accessory files <NUM> and global references to those files within the webpage can be redirected to unique identifiers for those files within the accessory file database <NUM>. Alternatively, the accessory files may continue to have global identifiers that are contained in the object model and that can be used to retrieve the accessory files anew and as needed when using the object model. Some analysis by the web content analyzer <NUM> and its components <NUM>-<NUM> may be performed using the static object model and/or the accessory files from the databases <NUM> and <NUM>. Some analysis may additionally and/or alternatively be performed via the webpage rebuilder <NUM> and reconstruction script <NUM>.

The webpage rebuilder <NUM> can inject the reconstruction script <NUM> into a browser <NUM> with the accessory files <NUM> and/or the object model <NUM> (step B, <NUM>), which can interface with the browser code <NUM> to instantiate a DOM <NUM> and CSSOM <NUM> in memory <NUM> (step C, <NUM>) and then to reconstruct the webpage by injecting DOM and CSSOM elements form the object model <NUM> into a DOM <NUM> and CSSOM <NUM> (step D, <NUM>). The browser <NUM> can be any of a variety for browsers, such as a headless browser (e.g., the headless browser <NUM>), a browser with a corresponding user interface, and/or other types of browsers. Reconstructing the webpage can include recreating a normal portion <NUM> of the DOM <NUM> as well as the shadow DOM <NUM>, instantiating styles <NUM> and <NUM> (including styles for different document fragments in the page), and mappings <NUM> between the DOM <NUM> and CSSOM <NUM>. Reconstructing the webpage can additionally and/or alternatively include rendering the webpage as represented in the object model <NUM> and presenting it in a user interface based on the reconstructed DOM <NUM>, CSSOM <NUM>, and mappings <NUM> there between.

The webpage rebuilder <NUM> can provide web content analyzer <NUM>, its components <NUM>-<NUM>, and/or other systems/services with access to the webpage as reconstructed in the browser <NUM> (step E, <NUM>). Using the reconstructed dynamic webpage in the browser <NUM> and/or the static object models <NUM> and/or accessory files <NUM>, the web content analyzer <NUM>, its components <NUM>-<NUM>, and/or other systems/services can perform webpage analysis (step F, <NUM>).

<FIG> are flowcharts of example processes <NUM> and <NUM> for generating an object model of a webpage. The example processes <NUM> and <NUM> can be performed by any of a variety of systems and/or devices, such as the web content analysis system <NUM> and its component parts, the object model builder <NUM>, the web content analysis system <NUM>, the object model builder <NUM>, the systems <NUM> and <NUM>, and/or the system <NUM>. The example processes <NUM> and <NUM> may additionally be performed in combination with and/or as part of any of a variety of other processes, such as the processes <NUM>, <NUM>, <NUM>, and/or <NUM>. For example, the processes <NUM> and <NUM> can be performed as part of steps <NUM>, <NUM>, and/or <NUM> of process <NUM> and/or step <NUM> of process <NUM>.

Referring to <FIG>, the process <NUM> creates an object model in which the nodes and their relationships to each other are provided by a nested relationship, such as the a child node being defined within the parent node, as well as all of the children nodes of the child node. Such nesting can be provided, for example, by using data structures that define data elements being contained within or as part of a data element, such as through opening and closing braces defining the data element for a parent node and the child node being contained within the opening and closing braces. Other opening and closing designators can be used, though, such as other characters (i.e., brackets) and/or spacing (e.g., line returns, indentation). A root node for the DOM can be selected (<NUM>) and recursive traversal of the DOM and shadow DOM can be performed (<NUM>), similar to the description above with regard to <FIG>. An opening designator for the selected node can be appended to the object model (<NUM>), such as an opening brace character ('{'), Content for the node can be appended to the object model (<NUM>) within the open designator and, in some instances, annotations for the node can be appended to the object model (<NUM>) within the open designator. The recursive function can be called for each child node and shadow DOM node (<NUM>) - meaning that the opening designator for each of these child nodes and shadow DOM nodes will be appended within the open designator for the selected node. After the recursive functions return for all child and shadow DOM nodes, then the closing designator for the selected node will be appended to the object model (<NUM>). Once all nodes have been traversed, the object model is finalized and returned (<NUM>). The resulting object model from process <NUM> is similar to the object model <NUM> depicted in <FIG>.

Referring to <FIG>, the example process <NUM> generates an object model that uses a node list where child nodes and shadow nodes are referenced by their index value within the node list, which avoids the nested structure of process <NUM>. The process <NUM> also uses a string list where unique string values are referenced within the nodes via their string index, which permits for common strings to be contained a single time within the object model and referenced from multiple different nodes via the string index value. Depending on the structure and content of the webpage for which the object model is being generated, the process <NUM> may result in a smaller, more compact object model than the process <NUM> due to the flattened/non-nested structure, as well as through the use of an index of unique string values. Additionally, object models generated by the process <NUM> may be more efficient for other systems to analyze and process, and may use fewer computing resources to process (i.e., less memory to regenerate the node structure). An example resulting data structure from the process <NUM> is depicted in <FIG>.

The root node can be selected from the DOM (<NUM>) and data structures used for the object model can be initialized, including the node list, the node list index value, and the string list (<NUM>). The DOM tree and shadow DOM can be recursively traversed to build the object model (<NUM>). An entry in the node list can be generated at the node list index value for the selected node and then then node list index value can be incremented (<NUM>). For each content item or element of the node (e.g., content, attributes, node type), the items/elements can be added to the created entry in the node list (<NUM>), which can include creating entries in the string list for string values that are not yet present in the string list (<NUM>) and adding items/elements to the created entry using corresponding string list index values (<NUM>). The string list can include any string, such as HTML tags, scripts, textual values, and/or other strings. A process similar to <NUM>-<NUM> can be performed for annotations being added to the object model.

For each child node and shadow DOM node of the selected node (<NUM>), a reference to the node list index value for the child/shadow DOM node can be added to the created entry for the node (<NUM>) and the recursive function can be called for each child/shadow DOM node, passing-in the node index value designated for that node (<NUM>). The node list and string list can continue to be constructed for each child and shadow DOM node via steps <NUM>-<NUM>, and once completed the node list and the string list can be added to the object model (<NUM>). The object model can then be finalized and returned for the page (<NUM>).

<FIG> depicts an example object model <NUM> generated using node and string references. The example object model <NUM> can be generated by any of a variety of processes, such as the process <NUM> described above with regard to <FIG>.

The example object model <NUM> includes a node list <NUM> with example node list entries <NUM>-<NUM> and a string list <NUM> with example string list entries <NUM>-<NUM>. The example node list entries <NUM>-<NUM> are identified with their node list index values (e.g., "index: <NUM>"), and the example string list entries <NUM>-<NUM> are designated in-line with their corresponding string list index values (e.g., "<NUM>: font-weight: bold'"). The index values are presented for illustrative purposes, and are not required to be part of the resulting object model <NUM>.

For the first node entry <NUM> (at node list index "<NUM>"), there are two child nodes <NUM>-<NUM> designated as part of the "childNodeList" element <NUM>. These child nodes <NUM>-<NUM> are identified by their corresponding index value in the nodesList <NUM>. The first node entry <NUM>, which could be considered to be the root node, also identifies the "document" element <NUM> includes a stylesheet element <NUM> with a selectorTextRef element <NUM> and a cssTextRef element <NUM>. In the depicted example, elements ending in the suffix "-Ref" refer to an index value for the string list <NUM>. Accessing the string list <NUM>, the value for the selectorTextRef element <NUM> is "div" (string list element <NUM> at string list index "<NUM>"), and the value for the cssTextRef element <NUM> is "font-weight: bold" (string list element <NUM> at string list index "<NUM>").

The node entry <NUM> (node list index "<NUM>") includes child nodes <NUM> that directly and indirectly correspond to regular portions of the DOM, such as nodes <NUM>-<NUM>, and also nodes that identify and correspond to the shadow DOM, such as the shadowRoot node <NUM> (node list index "<NUM>"), which is identified in node <NUM> by the shadowRoot element <NUM>, and the child nodes <NUM>-<NUM> of the shadowRoot node <NUM>. The shadowRoot node <NUM> includes a document fragment element <NUM>, which identifies the shadowRoot <NUM> along with the corresponding styles <NUM> that apply to the document fragment. Nodes for the regular DOM and the shadow DOM can be interspersed within the node list <NUM>, and can also share string list values for common string values based on their corresponding string identifier.

Any of a variety of different elements can use the same string list and values, such as for "element" <NUM> and its localNameRef element <NUM>, the localNameRef <NUM> and valueRef <NUM> that are part of an attributesList, and a dataRef <NUM>. As discussed above, the string list can include any string, such as strings identifying styles (e.g., string <NUM>), tags (e.g., string <NUM>), and scripts (e.g., string <NUM>).

The example object model <NUM> that is depicted in the example corresponds to the simplified example webpage that is described above with regard to <FIG>. When cross-referencing the various node and string indices, the following elements are provided by the object model <NUM>:.

<FIG> shows an example of a computing device <NUM> and an example of a mobile computing device that can be used to implement the techniques described here. The mobile computing device is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart-phones, and other similar computing devices.

The computing device <NUM> includes a processor <NUM>, a memory <NUM>, a storage device <NUM>, a high-speed interface <NUM> connecting to the memory <NUM> and multiple high-speed expansion ports <NUM>, and a low-speed interface <NUM> connecting to a low-speed expansion port <NUM> and the storage device <NUM>. Each of the processor <NUM>, the memory <NUM>, the storage device <NUM>, the high-speed interface <NUM>, the high-speed expansion ports <NUM>, and the low-speed interface <NUM>, are interconnected using various busses, and can be mounted on a common motherboard or in other manners as appropriate. The processor <NUM> can process instructions for execution within the computing device <NUM>, including instructions stored in the memory <NUM> or on the storage device <NUM> to display graphical information for a GUI on an external input/output device, such as a display <NUM> coupled to the high-speed interface <NUM>. In other implementations, multiple processors and/or multiple buses can be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices can be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multiprocessor system).

The memory <NUM> can also be another form of computer-readable medium, such as a magnetic or optical disk.

In some implementations, the storage device <NUM> can be or contain a computer-readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. The computer program product can also contain instructions that, when executed, perform one or more methods, such as those described above. The computer program product can also be tangibly embodied in a computer- or machine-readable medium, such as the memory <NUM>, the storage device <NUM>, or memory on the processor <NUM>.

The high-speed interface <NUM> manages bandwidth-intensive operations for the computing device <NUM>, while the low-speed interface <NUM> manages lower bandwidth-intensive operations. In some implementations, the high-speed interface <NUM> is coupled to the memory <NUM>, the display <NUM> (e.g., through a graphics processor or accelerator), and to the high-speed expansion ports <NUM>, which can accept various expansion cards (not shown). In the implementation, the low-speed interface <NUM> is coupled to the storage device <NUM> and the low-speed expansion port <NUM>. The low-speed expansion port <NUM>, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) can be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

The computing device <NUM> can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as a standard server <NUM>, or multiple times in a group of such servers. In addition, it can be implemented in a personal computer such as a laptop computer <NUM>. It can also be implemented as part of a rack server system <NUM>. Alternatively, components from the computing device <NUM> can be combined with other components in a mobile device (not shown), such as a mobile computing device <NUM>. Each of such devices can contain one or more of the computing device <NUM> and the mobile computing device <NUM>, and an entire system can be made up of multiple computing devices communicating with each other.

The mobile computing device <NUM> can also be provided with a storage device, such as a micro-drive or other device, to provide additional storage. Each of the processor <NUM>, the memory <NUM>, the display <NUM>, the communication interface <NUM>, and the transceiver <NUM>, are interconnected using various buses, and several of the components can be mounted on a common motherboard or in other manners as appropriate.

The processor <NUM> can be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor <NUM> can provide, for example, for coordination of the other components of the mobile computing device <NUM>, such as control of user interfaces, applications run by the mobile computing device <NUM>, and wireless communication by the mobile computing device <NUM>.

The processor <NUM> can communicate with a user through a control interface <NUM> and a display interface <NUM> coupled to the display <NUM>. The display <NUM> can be, for example, a TFT (Thin-Film-Transistor Liquid Crystal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display interface <NUM> can comprise appropriate circuitry for driving the display <NUM> to present graphical and other information to a user. The control interface <NUM> can receive commands from a user and convert them for submission to the processor <NUM>. In addition, an external interface <NUM> can provide communication with the processor <NUM>, so as to enable near area communication of the mobile computing device <NUM> with other devices. The external interface <NUM> can provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces can also be used.

The memory <NUM> stores information within the mobile computing device <NUM>. An expansion memory <NUM> can also be provided and connected to the mobile computing device <NUM> through an expansion interface <NUM>, which can include, for example, a SIMM (Single In Line Memory Module) card interface. The expansion memory <NUM> can provide extra storage space for the mobile computing device <NUM>, or can also store applications or other information for the mobile computing device <NUM>. Specifically, the expansion memory <NUM> can include instructions to carry out or supplement the processes described above, and can include secure information also. Thus, for example, the expansion memory <NUM> can be provide as a security module for the mobile computing device <NUM>, and can be programmed with instructions that permit secure use of the mobile computing device <NUM>. In addition, secure applications can be provided via the SIMM cards, along with additional information, such as placing identifying information on the SIMM card in a non-hackable manner.

The memory can include, for example, flash memory and/or NVRAM memory (non-volatile random access memory), as discussed below. In some implementations, a computer program product is tangibly embodied in an information carrier. The computer program product can be a computer- or machine-readable medium, such as the memory <NUM>, the expansion memory <NUM>, or memory on the processor <NUM>. In some implementations, the computer program product can be received in a propagated signal, for example, over the transceiver <NUM> or the external interface <NUM>.

The mobile computing device <NUM> can communicate wirelessly through the communication interface <NUM>, which can include digital signal processing circuitry where necessary. The communication interface <NUM> can provide for communications under various modes or protocols, such as GSM voice calls (Global System for Mobile communications), SMS (Short Message Service), EMS (Enhanced Messaging Service), or MMS messaging (Multimedia Messaging Service), CDMA (code division multiple access), TDMA (time division multiple access), PDC (Personal Digital Cellular), WCDMA (Wideband Code Division Multiple Access), CDMA2000, or GPRS (General Packet Radio Service), among others. Such communication can occur, for example, through the transceiver <NUM> using a radio-frequency. In addition, short-range communication can occur, such as using a Bluetooth, WiFi, or other such transceiver (not shown). In addition, a GPS (Global Positioning System) receiver module <NUM> can provide additional navigation- and location-related wireless data to the mobile computing device <NUM>, which can be used as appropriate by applications running on the mobile computing device <NUM>.

The mobile computing device <NUM> can also communicate audibly using an audio codec <NUM>, which can receive spoken information from a user and convert it to usable digital information. The audio codec <NUM> can likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of the mobile computing device <NUM>. Such sound can include sound from voice telephone calls, can include recorded sound (e.g., voice messages, music files, etc.) and can also include sound generated by applications operating on the mobile computing device <NUM>.

The mobile computing device <NUM> can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as a cellular telephone <NUM>. It can also be implemented as part of a smart-phone <NUM>, personal digital assistant, or other similar mobile device.

These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

Claim 1:
A method for generating a static object model (<NUM>) of a dynamic webpage (<NUM>), the method comprising:
receiving (<NUM>), at a computer system (<NUM>), a webpage from a web server;
instantiating, by the computer system and using an object model builder (<NUM>), a headless web browser application (<NUM>) to render (<NUM>) the webpage, wherein the headless web browser includes browser memory (<NUM>) and is configured to render the webpage by creating a document object model (<NUM>), DOM, and a cascading style sheet object model (<NUM>), CSSOM, in the browser memory, the DOM and the CSSOM representing dynamic rendered content of the webpage;
injecting (<NUM>), by the computer system and using the object model builder, a probe script (<NUM>) into the headless browser, wherein the probe script is configured to retrieve the dynamic rendered content of the webpage;
traversing, by the probe script, the DOM and the CSSOM, including traversing regular nodes of the DOM and shadow nodes of a shadow DOM (<NUM>) that is attached to regular nodes of the DOM;
retrieving, by the probe script and based on the probe script injecting instructions to the headless browser to cause the webpage to assume one or more states (124A-N) for the regular nodes and the shadow nodes, dynamic information for the regular nodes and the shadow nodes from, at least, the DOM and the CSSOM, wherein the dynamic information includes style information for the DOM and shadow style information for the shadow DOM, wherein the dynamic information further includes different states of the regular nodes and the shadow nodes;
building (<NUM>), by the computer system, a static object model of the webpage using the dynamic information for the regular nodes and the shadow nodes, wherein the static object model includes (i) the regular nodes, (ii) the shadow nodes, (iii) the style information for the DOM, (iv) the shadow style information, (v) structural features delineating separate styles applying to the regular nodes and the shadow nodes, and (vi) the different states of the regular nodes and the shadow nodes; and
outputting (<NUM>), by the computer system, the static object model for the webpage.