JP6397101B2 - Optimized browser rendering process - Google Patents

Description

  The present invention relates to an optimized browser rendering process.

  Many web pages are generated dynamically. This means that the last page viewed by the user of the web browser is at least partially generated by the browser rendering process. Embedded objects such as scripts, images, and style sheets are often embedded within web pages and can affect the content and appearance of rendered web pages, or generate dynamic content May be included for other purposes unrelated to. For example, the Google Analytics JavaScript code can be an embedded object that helps track traffic to the website but does not affect the content. An embedded object may itself contain additional embedded objects. Similarly, some embedded objects may be hidden and not visible to the user. A web page can have hundreds of embedded objects, and much of the time that the browser rendering engine spends rendering the web page for the user waits for the browser to fetch these embedded resources. Is spent.

  Implementations identify optional embedded resources and allow the rendering engine to skip such resources. This improves rendering time. Optional resources represent embedded objects that can be skipped in a meaningful or salient manner without affecting the content of the rendered web page. The browser may skip such optional embedded resources during the rendering process. The result is a faster load time.

  In one aspect, a system includes at least one processor and memory that stores instructions that, when executed by the at least one processor, cause the system to perform an operation. These operations may include identifying a URL pattern common to a plurality of URLs stored in the fetch record and selecting a sample of URLs from the plurality of URLs. These behaviors also render the first rendering result for the URL embedder using the content for the URL and the second rendering result for the embedder without using the content for the URL And determining for each URL in the sample whether the URL is optional by calculating a similarity score for the URL by comparing the first rendering result with the second rendering result. including. The method also determines if the URL is optional if the similarity score is greater than the similarity threshold, and if the predetermined number of URLs in the sample are optional, the option resource pattern Storing the URL pattern in the data store.

  One or more implementations of the subject matter described in this specification may include one or more of the following features. For example, these operations are also required to receive a request for content of the requested embedded resource and to determine whether the requested embedded resource matches a pattern in the data store. Returning an indication that the requested embedded resource is optional if the embedded resource matches the pattern. In some implementations, the indication may be a URL where no error has been found. As another example, the step of identifying a URL pattern common to multiple URLs stored in a fetch record includes removing at least a portion of the query string from the URL, for each URL stored in the fetch record. Generating a group URL for, and clustering the URL by the group URL. As another example, identifying a URL pattern common to multiple URLs stored in a fetch record removes at least a portion of the query string from the URL, clusters the URLs by group URL, and the largest number of members Generating a group URL for each URL stored in the fetch record by selecting the group URL of the cluster having As another example, the step of calculating the similarity score includes determining a similarity score and determining a longest common sequence for the DOM tree of the first rendering result and the DOM tree of the second rendering result. Using the longest common sequence for the purpose.

  In another aspect, a computer-implemented method identifies a URL pattern common to multiple URLs stored in a fetch record and uses at least one processor to sample URLs from multiple URLs. Selecting. This method also uses the content for the URL to generate the first rendering result for the URL embedder and the second rendering result for the embeder without using the content for the URL Determine whether the URL is optional for each URL in the sample by generating a similarity score for the URL by comparing the first rendering result with the second rendering result May include the step of: If the similarity score is greater than the similarity threshold, the URL is optional. The method may also include storing the URL pattern in the optional resource pattern data store if the majority of the URLs in the sample are optional.

  One or more implementations of the subject matter described in this specification may include one or more of the following features. For example, the method also includes determining whether the number represented by the plurality of URLs exceeds a size threshold before determining whether the URL in the sample is optional. obtain. As another example, the method may include storing the URL pattern in an optional resource pattern data store if all URLs in the sample are optional. As another example, the step of identifying a URL pattern common to multiple URLs in a fetch record is to remove at least part of the query string from the URL for each URL in the fetch record, cluster by group URL, If the number of members in satisfies a threshold, it may include generating a group URL for the URL in the fetch record by selecting a group URL for the cluster.

  In another aspect, a method receives a request to render a web page, identifies at least one embedded resource in the web page that requests a fetch, and the embedded resource is an optional resource. Determining and rendering the web page as if the embedded resource is not available without fetching the content for the embedded resource.

  One or more implementations of the subject matter described in this specification may include one or more of the following features. For example, determining that the embedded resource is an optional resource may include determining that the URL for the embedded resource matches a pattern in the data store of the optional resource. As another example, the method may also include receiving a pattern data store for an optional resource from the service, wherein determining that the embedded resource is an optional resource includes a URL for the embedded resource. Includes determining that the pattern matches the pattern in the data store. As another example, the step of determining that the embedded resource is an optional resource includes rewriting the URL for the embedded resource by removing the query string portion from the URL, Matching the pattern in the data store of the optional resource, and if the rewritten URL matches this pattern, the embedded resource is optional. As another example, determining that an embedded resource is an optional resource includes rewriting the URL for the embedded resource by removing at least part of the query string from the URL, and rewritten Matching the URL to a pattern in the optional resource's data store, and the embedded resource is optional if the rewritten URL matches this pattern.

  In another aspect, a non-transitory computer readable medium is executable by at least one processor formed on a substrate that causes a computer system to perform one or more of the methods described above. Instructions can be included.

  One or more of the implementations of the subject matter described in this specification may be implemented to realize one or more of the following advantages. As an example, the step of skipping optional embedded resources allows the rendering engine to render web pages faster without losing content. Not only can the browser skip the step of fetching the optional embedded resource, but the browser also skips the step of fetching the object embedded in the skipped optional embedded resource. Thus, the disclosed implementation saves network bandwidth and battery consumption. Such optimization can be essential because web pages can contain hundreds of embedded objects.

FIG. 6 illustrates an example system in accordance with the disclosed subject matter. FIG. 4 is a block diagram of rendering results for a rendered web page, according to an implementation. 6 is a flowchart illustrating an example process for identifying option resource patterns, according to an implementation. 6 is a flowchart illustrating an exemplary process for determining whether two rendering results are similar, according to an implementation. 6 is a flowchart illustrating an exemplary process for providing information for optimized rendering, according to an implementation. FIG. 11 illustrates an example of a computing device that can be used to implement the described techniques. FIG. 11 illustrates an example of a distributed computing device that can be used to implement the described techniques.

  The disclosed implementation identifies optional embedded objects or embedded objects that do not significantly affect the content of the rendered web page, so that the browser rendering engine can You can render such a web page without fetching. This improves rendering time and load in the fetch system. This is important for computing devices that have limited resources, such as smartphones and tablets. An embedded resource is optimal if the rendering result of an embedded web page rendered with an optional embedded object is similar to the rendered result of an embedded web page rendered without an optional embedded object Can be a candidate for a customized rendering. Similarity may be determined by token similarity, outlink similarity, page layout similarity, etc. on the page. In some implementations, the system may use the longest common sequence measurement to determine if the rendering results are similar. In some implementations, a snapshot may be considered similar if the major components of the snapshot have a similarity score that satisfies a similarity threshold. If the system determines that an embedded resource is optional, the system may store the embedded resource (eg, its uniform resource locator or URL) in a list of optional embedded resources. In some implementations, the system may aggregate optional embedded resource URLs to identify patterns that may be used to identify other optional embedded resources.

  When the browser begins to render a web page, the browser may request a service if any of the embedded resources are optional. In some implementations this may be done as part of a fetch request. The service may match the URL of the requested embedded resource to the optional embedded object data store, either by exact match or pattern match in the data store. If the service finds a match, the service tells the browser which embedded resources are optional, and the browser can render the web page without fetching these embedded resources. Such optimized browser rendering makes the browser rendering process even more resource efficient. In some implementations, the optional embedded resource data store may differentiate browser types, such as mobile browsers and desktop browsers.

  FIG. 1 is a block diagram of a system according to an example implementation. The system 100 can be used to identify optional embedded resources and optional resource patterns and use these patterns to optimize the browser rendering process. System 100 may include computing devices that take the form of many different devices. For example, the system 100 may include a computing device 600 that is an example of a computing device 600 as depicted in FIG. 6 and a computing device 700 as depicted in FIG.

  The system 100 can include a batch rendering system 110. The batch rendering system 110 can be a standard server, a group of such servers, a client-server system, or a rack server system. In addition, the batch rendering system 110 may be implemented on a personal computer. The batch rendering system 110 includes one or more processors configured to execute one or more machine-executable instructions or some software, firmware, or combinations thereof, stored in memory. May be included. For example, the batch rendering system 110 may include a rendering engine 120, a fetch service 122, a web-crawling engine 124, and an optional resource identification engine 126. The batch rendering system 110 may generate rendered web pages in batch mode, for example, as part of an index process, and in this process, a fetch record 132 may be generated. This can be used by the batch rendering system 110 to generate the option resource pattern 130.

  Downstream processing may require the batch rendering system 110 to render the web page in batch mode. In some implementations, the batch rendering system 110 may include downstream processing such as an optional resource identification engine 126 or an index engine (not shown). In some implementations, the downstream processing may be performed on a different computing device than the batch rendering system 110. For example, downstream processing may be an index engine or advertising platform that sends requests to a batch rendering system via a remote procedure call. Downstream processing may require one of the batch rendering engines 120 to generate a rendering result for a particular web page. Each batch rendering engine 120 may be configured to emulate a renderer for a personal web browser, but is optimized for batch rendering. Batch rendering system 110 may include thousands of batch rendering engines 120. Load leveling can then be used to select one of the batch rendering engines 120 that responds to a particular request. The requested web page may include embedded objects such as style sheets, JavaScript, images, etc. Batch rendering engine 120 may request content for embedded objects using fetch service 122.

  The fetch service 122 determines which embedded resources need to be fetched from the host server 190, which embedded resources can be returned from the cache, and which resources do not need to be returned. obtain. Host server 190 may be any type of computing device accessible via the Internet that hosts one or more web pages or resources embedded in one or more web pages. If the embedded resource needs to be fetched, the fetch service 122 may request content for the embedded object via the web-crawling engine 124 using conventional techniques. Downstream processing, such as an index engine, may also request content from the server 190 via the web-crawling engine 124. As a result of a fetch request via the web-crawling engine 124, the batch rendering engine 110 may generate a fetch record 132. The fetch record 132 may include information regarding which web pages and embedded objects were requested and retrieved from the host server 190. The fetch record 132 may also include additional information, such as time of request, embedder web page, etc., if any.

  Web-crawling engine 124, batch rendering engine 120, and fetch service 122 work together to efficiently render a large number of web pages, such as web pages that can be found on the World Wide Web. The rendering of the web page is the rendering result. This includes various data elements that are useful or otherwise unavailable for downstream request processing. Optional resource identification engine 126 may use batch rendering engine 120 to generate optional resource pattern 130. Optional resource identification engine 126 may execute periodically (eg, daily, twice a week, etc.) using fetch record 132 as input. Optional resource identification engine 126 may analyze fetch record 132 and generate a pattern for URLs fetched in the previous cycle. For example, the option resource identification engine 126 removes the URL query string in the fetch record and generates a group URL for each URL. The query string can be any character after the question mark (?) In the URL. In some implementations, only a portion of the query string can be removed to generate a group URL for the URL. The option resource identification engine 126 can then sort or cluster the group URLs and determine from the time period which group URLs had the most fetch requests.

  Optional resource identification engine 126 may select the group URL with the largest number of fetch requests as a potential pattern. Such a pattern represents the embedded resource that has the greatest potential for optimizing the browsing process because it is fetched most frequently. The optional resource identification engine may determine whether a URL that matches the potential pattern or a sample of URLs that match the potential pattern is optional. For example, the optional resource identification engine 126 may identify embedded resources that match a potential pattern from the fetch record 132, and the batch rendering engine 120 may identify the first of the embedder web page for embedded resources. It may be required to render the rendering result. The embedder web page may be identified from a fetch record for an embedded resource, for example. Optional resource identification engine 126 may then request that batch rendering engine 120 render a second rendering result of the embedder web page without fetching embedded resources.

  In order to determine whether the rendered content of the embedder web page is affected by skipping a particular embedded resource, the optional resource identification engine 126 uses the first rendering result as the second rendering result. Can be compared with the rendering result. In some implementations, specific embedded resources can be added to the list of requested resources if the content is significantly affected. If the content is not significantly affected (eg, the content is similar), the optional resource identification engine 126 may identify the embedded resource as an optional resource. In some implementations, the embedded resource (eg, its URL) may be stored in a data store, such as optional resource pattern 130. In some implementations, embedded resources may be stored in a temporary list of optional resources that are used at a later time to determine a pattern for the optional resources. Optional resource identification engine 126 uses this test (compare rendering results) for all embedded resources that match the potential pattern in the fetch record, or for samples of embedded resources that match the potential pattern. ). In some implementations, a potential pattern is not an optional resource pattern if any of the embedded resources that match the potential pattern are appropriate. In some implementations, if only a small percentage (e.g., 1% or less) of embedded resources that match the potential pattern is the requested resource, the potential pattern is an optional resource pattern. It is believed that the option resource identification engine 126 may include the potential pattern as a pattern in the option resource pattern 130. Of course, if all tested embedded resources that match the potential pattern are optional, the option resource identification engine 126 may add the potential pattern to the option resource pattern 130.

  In some implementations, the option resource identification engine 126 may also verify that the pattern in the option resource pattern 130 is still optional. For example, the optional resource identification engine 126 selects a sample of URLs that match the pattern and instructs the rendering engine to render the rendering results with and without embedded resources that match the pattern. Request and compare these two rendering results. If the URL that matches the pattern in the option resource pattern 130 is no longer optional, this pattern can be deleted.

  In some implementations, the option resource identification engine 126 may determine whether the pattern is an option for a mobile browser that is separate from the full browser. For example, some websites load different content for mobile and full versions of web pages, embedded resources may be an option for mobile browsers, but are required for full browsers obtain. Accordingly, optional resource identification engine 126 may render four rendering results for the embedded resource. The first two rendering results can be rendered by a rendering engine that emulates a full browser, while the last two rendering results are rendered by a rendering engine that emulates a mobile browser on a mobile device such as a smartphone or tablet. obtain. Thus, the option resource pattern 130 may include data indicating whether the pattern is optional depending on the browser type, such as for a mobile browser or for a full browser.

  Although not shown in FIG. 1 for brevity, in some implementations the batch rendering system 110 may be distributed across multiple individual computing devices. In addition, one or more of batch rendering engine 120, fetch device 122, web-crawling engine 124, and optional resource identification engine 126 may be distributed across one or more computing devices. In some implementations, one or more of the batch rendering engine 120, the fetch service 122, the web-crawling engine 124, and the optional resource identification engine 126, allocate a resource, such as a memory or hardware processor, to the batch rendering system Can be shared with 110 other components. Similarly, fetch records 132 and optional resource patterns 130 may also be stored in memory distributed across multiple computing devices. In some implementations, the various components of the batch rendering system 110 may share computing device hardware components or may be logical partitions of the same computing device.

  Batch rendering system 110 may communicate with client 180 and server 190 via network 160. The network 160 may be, for example, the Internet, or the network 160 may be implemented using, for example, gateway devices, bridges, switches, etc., wire or wireless local area networks (LAN), wide area networks (WAN), etc. Or the like. Via network 160, batch rendering system 110 may communicate with client 180 and / or host server 190 and send data to / from client 180 and / or host server 190. For example, the batch rendering system 110 may provide the option resource pattern 130 to the client 180 or may receive a request from the client 180 asking if a particular embedded resource is optional, and the option resource pattern 130 A response may be provided.

  Client 180 may be a personal computing device with an installed personal web browser 140, such as computing device 600 depicted in FIG. Examples of personal web browsers include CHROME, SAFARI, INTERNET EXPLORER, FIREFOX, etc., whether for mobile devices such as smartphones or tablets, or for personal computers such as laptops or desktops. Browser 140 may be configured to use a service to determine whether to fetch a particular embedded resource when rendering a web page. In some implementations, the system may push a copy of the option resource pattern 130 to the client 180 for use by the browser 140. In this respect, the service can be a local service. In some implementations, the browser 140 is configured to request a server-based service to determine whether a particular embedded resource matches one of the patterns in the option resource pattern 130. obtain. Browser 140 performs optimized rendering by using this service to skip optional embedded resources when rendering a web page. Accordingly, the browser 140 can be configured to selectively skip embedded resources to improve rendering time and conserve resources when content is not affected.

  FIG. 2 is a block diagram of rendering results 200 rendered by batch rendering engine 120, according to an implementation. Rendering result 200 may include various components, not all of which are illustrated in FIG. For example, the rendering result 200 may include an image 205 of the rendered page. The image 205 may be an image that will be displayed to the user via a web browser via a display device. Image 205, for example, to display to the user a thumbnail of the rendered page and to determine where on the display the elements of the web page will appear (eg, based on their x and y coordinates) Can be used. The rendering result 200 may also include a document object model (DOM) tree 210. The DOM tree 210 represents the HTML structure of a web page. The rendering result 200 may also include a layout 215. The layout 215 generally includes boxes for the elements of the web page, which define the x and y coordinates of the elements in the image 205. Thus, layout 215 provides an indication of where the element appears on the web page, how much space it uses on the web page, and so on. Thus, layout 215 shows how much of the web page is advertising, how the paragraph stands out (for example, above the fold or below the crease), and whether the element is visible Provide information on In other words, the layout 215 provides geometric information about the elements of the rendered web page. This rendering result 200 may also include an error 220. Error 220 includes errors encountered as a result of the execution of a script object, such as JavaScript. The rendering result 200 may also include a list of embedded resources 225 fetched during rendering. It may include other elements (not shown) generated as part of the rendering process. Thus, the rendering result 200 provides information that is not available alone by fetching content from the host server. Downstream request processing, such as the option resource identification engine, can be used for a variety of purposes, such as to determine whether a running script object significantly changes the content of the rendered web page. Rendering result information may be used. For example, the content in the advertising portion of a web page may not be considered important, so the URL may still be optional even if the advertising portion is different. In some implementations, only differences in the main components of the rendering result may be considered significant. The main component may be the largest box in layout 215 (eg, the box with the greatest height and width).

  FIG. 3 is a flowchart illustrating an example process 300 for identifying optional resource patterns, according to an implementation. Process 300 may be performed by a system such as system 110 of FIG. The system may use process 300 to identify a pattern for optional resources from the fetch record. The system may determine a pattern for an optional resource based on a rendering result comparison between an embedded web page rendered with resources and an embedded web page rendered without resources. These patterns are stored in the data store so that browsers can optimize rendering by skipping optional resources (eg, not fetching), whether they are full browsers, mobile browsers, or batch rendering engines. Can be used as part of a service.

  Process 300 may begin with the system clustering the fetched embedded resources according to a potential pattern (305). The system may select all embedded resources fetched in a previous time period, such as, for example, one day, two days, a week, since the last time processing 300 was performed, and so on. The potential pattern can be generated by removing all or part of the query string from the URL found in the fetch record. The fetch record may be generated by a web-crawling engine or a fetch service. In some implementations, fetch records may be generated as part of an index process such as, for example, an index process for documents available via the Internet. An embedded resource can be identified in a fetch record by an identifier such as a URL. Thus, web pages or embedded resources can also be referred to as URLs, and references to embedded resources (or web pages) and URLs are generally understood to be synonymous as used herein. The A potential pattern can be generated for a URL by removing all or part of the query string, where the query string is any character following the question mark (?) In the URL for embedded resources . Potential patterns also remove or ignore subdomain names, ignore path components (for example, the first forward slash (“/”) and query string (“?”)), Or query characters Can be generated for embedded resources by ignoring certain parameters in the column. In some implementations, an embedded resource from a fetch record can be associated with more than one potential pattern generated from that URL. Potential URLs can be clustered by sorting or by other known clustering techniques.

  The system may select a cluster represented by one of the potential patterns (310) and determine whether the number of cluster members is greater than or equal to a threshold (315). The number of cluster members represents the number of times that embedded resources matching the potential pattern were fetched during the previous time period. Thus, a particular embedded resource can be represented multiple times in that number if it is fetched more than once. If the number of clusters is less than the threshold (315, No), the system may proceed to the next cluster (355). If the potential pattern has a sufficient number of members (315, Yes), the system may select a sample of embedded resources that matches the potential pattern (320). In other words, the system may sample a unique member of the cluster. Of course, in some implementations, the system may select all unique embedded resources in the cluster as samples (eg, sample size 100%). The system may then select one of the embedded resources in the sample (325), and a first web page (e.g., an embedder web page) that embeds the resource using the selected embedded resource. A rendering result may be generated (330). The embedder web page can be determined from the fetch record. The system may also generate a second rendering result of the embedder web page without fetching the selected embedded resource (330). The system may generate two rendering results using, for example, a batch rendering engine. The system may then compare the first rendering result and the second rendering result to determine whether the rendering results are similar (335).

  The system may use various tests to determine whether these rendering results are similar, as described in more detail with respect to FIG. If the rendering results are not similar (335, No), the system can move to the next cluster (355). If the rendering results are similar (335, Yes), the system may determine whether there are other embedded resources to examine in the cluster sample (340). If there are other embedded resources (340, No), the system can select the next embedded resource for the sample (345) and repeat steps 330 and 335, producing two rendering results And compare these results. If all embedded resources in the sample have been examined (340, Yes), the system can add a potential pattern for the cluster to the optional resource pattern data store (350). This data store may be used by the service to identify embedded resources that do not need to be fetched, as described in more detail with respect to FIG. The system may then determine whether there are other clusters to examine (355). If there are other remaining clusters to analyze (355, No), the system can select the next cluster and step for embedded resources that match the potential pattern of the next cluster. Repeat 315-355. If there are no more clusters to analyze (355, Yes), process 300 is complete.

  The example process 300 illustrates an implementation where one non-optional embedded resource will be a potential pattern that is omitted from the option resource pattern data store (eg, 335, No). However, in some implementations, the system may include a list of embedded resources for potential patterns that are optional and a list of embedded releases for potential patterns that are required (e.g., these two Rendering results may not be considered similar). In such an implementation, the system may calculate the percentage of embedded resources that match the required potential pattern. If this percentage is very low (eg, 1% or less), the system may still add potential patterns to the optional resource pattern data store (350). Thus, implementation is not limited to the exact process 300 illustrated in FIG.

  In some implementations, the system may repeat some or all of the process 300 with rendering results rendered by different browser types. For example, the browser type can be a full browser or a mobile browser. If the first and second rendering results are being rendered by a full browser, the system may repeat steps 330-350 using the mobile browser. Thus, the list of optional resource patterns may include browser type indications, and the patterns in the data store may also include browser type indications. This allows the system to indicate whether the embedded resource is optional for one browser type (eg, mobile browser) and not optional for another browser type (eg, full browser). .

  FIG. 4 is a flowchart illustrating an example process 400 for determining whether two rendering results are similar, according to an implementation. Process 400 may be performed, for example, as part of step 335 of FIG. Although process 400 illustrates three tests for determining rendering result similarity, implementations may include one, two, or all of the illustrated tests, additional not illustrated It is understood that a similarity test can be included.

  Process 400 may include comparing the tokens in the two rendering results (405). These tokens contain the text of the document, for example words that are visible to the user. The token may be generated by processing a DOM tree such as DOM tree 210 of FIG. In some implementations, stopwords and numbers can be deleted before performing the comparison. If the first rendering result token is different from the second rendering result token (410, Yes), the system optionally includes a unique token added by rendering with the activated scripting. It may be determined whether the number is less than a token threshold (415). In other words, if the rendering with the activated script description only results in a small number of unique tokens, the system can consider the difference as trivial. In some implementations, the token threshold may be 5. If the number of unique tokens added satisfies the token threshold (415, No), the system may consider the rendering results not similar (430). If the rendering results are not similar, the embedded resource used to generate the rendering results is not optional. In some implementations, the system may skip test 415 and consider that any differences in tokens are significant and the rendering results are not similar. If the number does not satisfy the token threshold (415, Yes), the system may consider the difference in tokens as trivial. Therefore, the unique token for the first rendering result is the same as the token in the second rendering result (410, No), or the number of unique tokens does not satisfy the token threshold If (415, Yes), the rendering results are considered similar and the system can continue to perform other tests. In implementations that include only token tests, the system may proceed directly to step 445, where a determination is made that the rendering results are similar.

  In some implementations, if the tokens are the same (410, No) or (415, Yes), the system may compare the outlinks (420). Outlinks represent links from rendered pages to other web pages or other documents. Outlinks can also be extracted from anchor tag nodes (<a> tags) in the rendered DOM tree. If the system finds a difference in the outlink (425, Yes), the system may consider that the difference is significant and the rendering results are not similar (430). Thus, embedded resources are not considered options. If the outlinks in the two rendering results are the same (425, No), the system may consider the rendering results to be similar (e.g., by proceeding to step 450) or other similarity test Proceed to perform. In some implementations, the system may perform steps 420 and 425 independently of steps 405 and 415 prior to steps 405 and 415.

  In another similarity test that may be performed in addition to or in place of other tests, the system may determine similarity between images (eg, snapshots), DOM trees, or layouts. For example, the system may calculate (435) the longest common sequence (LCS) for the rendered DOM tree, layout, image, or another component. The system may use LCS to calculate a similarity score that represents the percentage of components that are the same (440). If the percentage meets the threshold (445, Yes), the system may determine that the rendering results are similar (450). If the percentage does not satisfy the threshold (445, No), the system may determine that the rendering results are not similar (430). If the system determines whether the rendering results are similar (450) or dissimilar (430), the process 400 ends.

  Of course, the system may perform other tests as part of process 400. For example, in another similarity test (not shown in FIG. 4), the system may determine the major components of the layout. The rendering result layout consists of boxes, each defined by a screen coordinate. In general, each box corresponds to a respective element of the web page. For example, a layout may include a box representation of DOM nodes in a DOM tree (although not all DOM elements may have corresponding renderer boxes). Boxes can be organized in a tree structure, also known as a renderer tree. Thus, for example, a table can be represented by a box in the layout and a paragraph can be represented by another box in the layout. The main components of a web page are those elements in the layout that have a maximum box, as defined by the screen coordinates. In some implementations, the system may include a predetermined number of primary components in the set, for example, such that the set includes a maximum of the primary components. In some implementations, the system may include major components that account for the percentage of screens in the set. In such an implementation, the largest major component occupies more than that percentage, and the largest major component may only be a member of the set. In some implementations, any component having a box size that exceeds the threshold size may be included in the primary component set. Components that are not in the main set of components can be considered as non-critical components. In some implementations, the system may use onion peeling techniques to discover key components. For example, the system may perform a horizontal search starting at the root box of the renderer tree and identify the largest child box of the root box. The system can then select the largest child and go deeper to find the largest child box of the current box (eg, the largest child box of the root box). The system may stop going deeper if none of the child boxes is dominant, eg, occupying more than half of the area of the parent box. If the system stops going deeper, the main component is a box with no dominating children.

  The system may calculate a similarity score between the major components in the set. For example, the system may use the overlap score of the main component box. With the overlap score, the system can calculate the overlap area of the major components. This represents the area of the main component in the first rendering result that overlaps with the area of the corresponding main component in the second rendering result. The system can then calculate a similarity score. This represents that the harmonic mean of the overlap is related to the total area of each major component. For example, the system may use the following equation:

Where oa is the overlap area, a1 is the total area of the main component box in the first rendering result, and a2 is the total area of the main component box in the second rendering result . Of course, the system may use other similarity metrics to calculate this score. Examples of such similarity metrics can include, but are not limited to, Katz similarity. If the similarity score satisfies the similarity threshold, the rendering results are considered similar and therefore the embedded resource is optional. In some implementations, the similarity threshold can be high, eg, 80% or higher. If the similarity score does not satisfy the threshold, the system may consider that the rendering results are not similar. In some implementations, if the similarity score satisfies a similarity threshold, the system may perform additional similarity tests based on rendering results not illustrated in FIG. . In some implementations, the system may also calculate similarity scores for differences in non-critical components, but does not respect these differences so much, for example, for this rendering result, the final similarity score Of these, only a part.

  In some implementations, the system may attempt to minimize or eliminate indeterminate effects on process 400. Indeterminacy occurs when rendering results are different, even if the embedded resources are the same. Uncertainty can make an optional embedded resource appear as if it is needed. Thus, consideration for uncertainty can significantly increase the coverage of option resources. To account for the uncertainty, the system may generate a third rendering result. The third rendering result may be a rendering using the resources returned from generating the first rendering result (eg, including a sample URL). Any difference that occurs between the third rendering result and the first rendering result is due to uncertainty. The system may remove the similarity by deleting any differences due to indeterminate (eg, differences in the outlinks, tokens, images, renderer trees, etc. that are differences in the first and third rendering results). For example, the system may include a first number representing a number of pixels that is the difference between a first rendering result image and a third rendering result image, a first rendering result image, and a second rendering result. And a second number representing the number of pixels that is the difference between the rendered result images of. The system may subtract the first number from the second number to generate a difference. The closer this difference is to the second number, the more likely that any difference between the first rendering result and the second rendering result is not due to uncertainty. Thus, the system may adjust the LCS similarity score based on the difference (e.g., no adjustment if the difference is equal to the second number, and if the difference is half of the second number). Adjust to half, etc.). As another example, the system may determine a DOM node that is the difference between the first rendering result and the third rendering result, and compares the first rendering result to the second rendering result (e.g., These nodes can be ignored when calculating LCS).

  FIG. 5 is a flowchart illustrating an example process 500 for providing information for optimized rendering, according to an implementation. Process 500 may be performed as a service for a browser. The browser may be a mobile or full client browser, such as browser 140 of FIG. 1, or may be a batch rendering engine, such as batch rendering engine 120 of FIG. In some implementations, the service can be a cloud-based service. In other words, the browser may send a request to the cloud-based service over the network. A cloud-based service may provide a response to the browser. In some implementations, the service may be executed on a server such as the batch rendering system 110 of FIG. In other implementations, the service may be local to the computing device that the browser executes. For example, a data store of optional resource patterns can be pushed to a computing device running a browser, and this service can be executed at the computing device. In some implementations, the service may be executed on a client, such as client 180 of FIG.

  Process 500 begins with the service receiving a URL from a browser (505). The browser can be a mobile browser, a full browser, and can be executed on the client or as a batch rendering engine. The service may determine whether the URL from this request matches an optional resource pattern (510). In some implementations, the pattern may represent a full URL. This provides a match for the entire requested URL. In some implementations, the pattern may represent a partial URL with, for example, removed query strings or various parts replaced by wildcards. If the requested URL does not match at least one pattern in the options resource data store (510, Yes), the service renders the embedder web page without fetching the content and the URL is optional. Provide a response indicating that it can be done (515). In some implementations, this may be a response similar to the “URL not found” response that the browser may receive if the resource cannot be located. In response to receiving this indication, the browser may render an embedder web age that skips embedded resources, saving processing and bandwidth resources. If the requested URL does not match the pattern in the option resource data store (510, No), the service provides a response indicating that an embedded resource is requested (520). In some implementations, the service may actually perform the fetch and provide content for the embedded resource. In some implementations, the service may provide a response that tells the browser to proceed with a fetch request for embedded resources. Thus, the browser may render the embedder web page with content that seeks embedded resources. Thereafter, process 500 provides information that the browser can use to optimize the rendering process and ends. In some implementations, the browser may provide a browser type to the service, and the service may use this browser type if the pattern in the optional resource data store matches.

  FIG. 6 illustrates an example of a general computing device 600 that can be operated as the batch rendering system 110 and / or client 180 of FIG. 1 that can be used with the techniques described herein. The computing device 600 is a variety of exemplary computing devices such as laptops, desktops, workstations, personal digital assistants, cellular phones, smartphones, tablets, servers, and other computing devices including wearable devices. It is intended to represent a form. The components illustrated herein, their connections and relationships, and their functions are intended to be examples only and are not intended to limit the practice of the invention described and / or claimed herein. It has not been.

  The computing device 600 includes a processor 602, such as a silicon-based hardware processor, a memory 604, a storage device 606, and an expansion port 610, connected via an interface 608. In some implementations, the computing device 600 may include, among other components, a transceiver 646, a communication interface 644, and a GPS (Global Positioning System) receiver module 648 connected via an interface 608. . Device 600 may communicate wirelessly via communication interface 644. This may include digital signal processing circuitry if necessary. Each of the components 602, 604, 606, 608, 610, 640, 644, 646, and 648 may be suitably mounted on a common motherboard or otherwise.

  The processor 602 may process instructions for execution within the computing device 600. The instructions include instructions stored in memory 604 or in storage device 606 to display graphic information for a GUI at an external input / output device such as display 616. Display 616 may be a monitor or a flat touch screen display. In some implementations, multiple processors and / or multiple buses may be suitably used with multiple memories and multiple types of memory. Also, multiple computing devices 600 may be connected that provide some of the operations that each device requires (eg, as a server bank, a group of blade servers, or a multi-processor system).

  Memory 604 stores information within computing device 600. In one implementation, the memory 604 is a volatile memory unit. In another implementation, the memory 604 is a non-volatile memory unit. The memory 604 may also be another form of computer readable media such as a magnetic or optical disk. In some implementations, the memory 604 may include expansion memory provided via an expansion interface.

  Storage device 606 may provide mass storage for computing device 600. In one implementation, the storage device 606 includes a floppy disk device, hard disk device, optical disk device, or tape device, flash memory or other similar solid state memory device, or device in a storage area network or other configuration. Or may be a computer readable medium such as an array of A computer program product may be clearly embodied in such computer readable media. The computer program product may also include instructions that, when executed, perform one or more methods, as described above. The computer-or machine-readable medium is a storage device, such as memory 604, storage device 606, or memory in processor 602.

  Interface 608 may be a high speed controller that manages bandwidth consuming operations for computing device 600, or a low speed controller that manages lower bandwidth consuming operations, or a combination of such controllers. An external interface 640 may be provided to allow near area communication with other devices of the device 600. In some implementations, the controller 612 may be coupled to the storage device 606 and the expansion port 614. Expansion ports that can include various communication ports (eg, USB, Bluetooth®, Ethernet®, wireless Ethernet®) such as keyboards, pointing devices, scanners, or switches or routers It may be coupled to one or more input / output devices, such as a networking device, for example via a network adapter.

  As illustrated in the drawings, computing device 600 may be implemented in many different forms. For example, it can be implemented multiple times as a standard server 630 or within a group of such servers. It can also be implemented as part of a rack server system. In addition, it can be implemented in a laptop computer 632, desktop computer 634, or a persona computing device such as a tablet or smartphone 636. The entire system can be comprised of multiple computing devices 600 that communicate with each other. Other configurations are possible.

  FIG. 7 illustrates an example of a general computing device 700 that can be the system 110 of FIG. 1 that can be used with the techniques described herein. Computing device 700 is intended to represent various exemplary forms of large scale data processing devices such as servers, blade servers, data centers, mainframes, and other large scale computing devices. Computing device 700 may be a distributed system having a number of processors, including storage nodes, possibly coupled to the network, interconnected by one or more communication networks. The components illustrated herein, their connections and relationships, and their functions are intended to be examples only and are not intended to limit the practice of the invention described and / or claimed herein. It has not been.

  Distributed computing device 700 may include any number of computing devices 780. The computing device 780 may include a server or rack server, mainframe, etc. that communicates via a local or wide area network, a dedicated optical link, a modem, a bridge, a router, a switch, a wire or wireless network, or the like.

  In some implementations, each computing device may include multiple racks. For example, computing device 780a includes a number of racks 758a-758n. Each rack may include one or more processors, such as processors 752a-752n and 762a-762n. The processor may include a data processor, a network coupled storage device, or other computer controlled device. In some implementations, one processor may operate as a master processor and may control scheduling and data distribution tasks. The processors can be interconnected via one or more rack switches 758, and the one or more racks can be connected via a switch 778. Switch 778 may handle communication between a number of connected computing devices 700.

  Each rack may include memory such as memory 754 and memory 764 and storage such as 756 and 766. Storage 756 and 766 may provide large scale storage and may be a network coupled disk, floppy disk, hard disk, optical disk, tape, flash memory, or other similar solid state memory device, or storage area network or It may include volatile or non-volatile storage, such as an array of devices, including devices in other configurations. Storage 756 or 766 may include a computer readable medium that stores instructions executable by one or more of the processors that may be shared among multiple processors, multiple racks, or multiple computing devices. . Memory 754 and 764 can be, for example, a volatile memory unit, a non-volatile memory unit, and / or a magnetic or optical disk, flash memory, cache, random access memory (RAM), read only memory (ROM), and combinations thereof Such other forms of computer-readable media may be included. Memory, such as memory 754, may also be shared between processors 752a-752n. A data structure such as an index may be stored across storage 756 and memory 754, for example. Computing device 700 may include other components not shown, such as controllers, buses, input / output devices, communication modules, and the like.

  An entire system, such as system 110, may be comprised of a number of computing devices 700 that communicate with each other. For example, device 780a may communicate with devices 780b, 780c, and 780d, which may be collectively known as system 100. As another example, the system 100 in FIG. 1 may include one or more computing devices 700. Some of the computing devices may be located geographically close to each other and others may be located geographically apart. The layout of the computing device 700 is merely an example, and the system may exhibit other layouts or configurations.

  Various implementations may be special purpose or general purpose formed on a substrate and receive data and instructions from a storage system, at least one input device, and at least one output device, and the storage system, at least one input device And implementation in one or more computer programs executable and / or interpretable in a programmable system including at least one programmable processor coupled to transmit data and instructions to at least one output device obtain.

  These computer programs (also known as programs, software, software applications, or code) contain machine instructions for a programmable processor, in a high level procedural and / or object oriented programming language, and / or assembly / Can be implemented in machine language. As used herein, the terms “machine-readable medium”, “computer-readable medium” are any terms used to provide machine instructions and / or data to a programmable processor. Non-transitory computer program product, apparatus, and / or device (eg, magnetic disk, optical disk, memory (including read access memory), programmable logic device (PLD)).

  The systems and techniques described herein include a back-end component (e.g., a data server), a middleware component (e.g., an application server), or a front-end component (e.g., a user In a computing system, or in such a back-end component, middle-end component, including a graphical user interface or client computer having a web browser that can interact with the implementation of the systems and techniques described herein , Or any combination of front end components. The components of the system can be interconnected by any form or medium of digital data communication (eg, a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

  The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship between a client and a server is caused by a computer program that runs on each computer and has a client-server relationship with each other.

  A number of implementations have been described. However, various modifications can be made without departing from the spirit and scope of the present invention. In addition, the logic flows depicted in the drawings do not necessarily require the particular order shown or sequential order to achieve the desired result. In addition, other steps can be provided, or steps can be deleted from the described flow, and other components can be added to the described system, or from the described system. Can be deleted. Accordingly, other implementations are within the scope of the following claims.

100 system
110 Batch rendering system
120 batch rendering engines
122 fetch service
124 Web-crawling engine
126 Optional resource identification engine
130 Optional resource patterns
132 fetch records
140 Browser
160 network
180 clients
190 Host server
200 rendering results
205 images
210 DOM tree
215 layout
220 error
225 Embedded resources
600 computer devices
602 processor
604 memory
606 storage device
608 interface
610 expansion port
612 controller
614 expansion port
616 display
630 server
632 laptop computer
634 desktop computer
636 smartphone
640 External interface
644 communication interface
646 transceiver
648 GPS (Global Positioning System) receiver module
700 computer devices
752 processor
754 memory
756 storage
758 rack, rack switch
762 processor
764 memory
766 storage
778 switch
780 devices

Claims (20)

A computer system,
At least one processor;
When executed by the at least one processor,
Receive the URL for the embedded resource in the web page from the requester,
Determining whether the embedded resource is an optional resource by determining that the URL for the embedded resource matches a pattern in a data store that identifies the optional resource;
Providing an indication for skipping the embedded resource when the requester renders the web page in response to determining that the embedded resource is an optional resource;
A memory for storing instructions for fetching content for the embedded resource and providing the content to the requester in response to determining that the embedded resource is not an optional resource. ,system.   In response to determining that the rendering result of the web page rendered with the embedded resource is similar to the rendering result of the web page rendered without the embedded resource, the embedded resource is optional The system of claim 1, wherein The memory, when executed by the at least one processor, for the system,
Rewrite the URL by removing the query string from the URL,
Further storing instructions for causing the rewritten URL to match the pattern in the data store identifying optional resources;
The system of claim 1, wherein the embedded resource is optional if the rewritten URL matches the pattern. The memory, when executed by the at least one processor, for the system,
Rewrite the URL for the embedded resource by removing at least part of the query string from the URL;
Further storing instructions for causing the rewritten URL to match the pattern in the data store identifying optional resources;
The system of claim 1, wherein the embedded resource is optional if the rewritten URL matches the pattern. The memory, when executed by the at least one processor, for the system,
Using content fetched from the URL to generate a first rendering result for the embedded resource embedder;
Generating a second rendering result for the embedder of the embedded resource without using the content;
Calculating a similarity score for the URL by comparing the first rendering result with the second rendering result;
If the similarity score is greater than a similarity threshold, determine that the embedded resource is optional;
The system of claim 1, further comprising instructions for causing the data store to store a URL pattern in response to determining that the embedded resource is optional. The memory, when executed by the at least one processor, for the system,
Using the content fetched from the URL to generate a third rendering result for the embedder of the embedded resource;
6. The system of claim 5, further comprising instructions for ignoring any difference between the third rendering result and the first rendering result during the calculation of the similarity score. The memory, when executed by the at least one processor, for the system,
Using the content fetched from the URL to generate a third rendering result for the embedder of the embedded resource;
Determining a DOM node that is the difference between the first rendering result and the third rendering result;
6. The system of claim 5, further comprising instructions for ignoring the different DOM nodes when calculating the similarity score.   The system of claim 1, wherein the URL is received as part of a fetch request for the embedded resource.   The system of claim 1, wherein the request source is an index engine.   The system according to claim 1, wherein the request source is a browser. Receiving a URL for the embedded resource in the web page from the request processing;
Determining whether the embedded resource is an optional resource by determining that the URL for the embedded resource matches a pattern in a data store that identifies the optional resource;
Providing an indication to skip the embedded resource when the request process renders the web page in response to determining that the embedded resource is an optional resource;
Providing a response indicating that a fetch of the embedded resource is requested in response to determining that the embedded resource is not an optional resource.   The method of claim 11, wherein the request processing is a browser, and the method is performed by a service local to a computing device executing the browser.   12. The method of claim 11, wherein the request processing is a browser and the method is performed by a service remote from a computing device executing the browser. Rewriting the URL by deleting a query string from the URL;
Matching the rewritten URL to the pattern in the data store identifying optional resources; and
12. The method of claim 11, wherein the embedded resource is optional if the rewritten URL matches the pattern. Rewriting the URL for the embedded resource by removing at least part of the query string from the URL;
Matching the rewritten URL to the pattern in the data store identifying optional resources; and
12. The method of claim 11, wherein the embedded resource is optional if the rewritten URL matches the pattern. Generating a first rendering result for the embedded resource embedder using content fetched from the URL;
Generating a second rendering result for the embedder of the embedded resource without using the content;
Calculating a similarity score for the URL by comparing the first rendering result with the second rendering result;
Determining that the embedded resource is optional if the similarity score is greater than a similarity threshold;
12. The method of claim 11, further comprising: storing the URL in the data store as the pattern in response to determining that the embedded resource is optional. Generating a third rendering result for the embedder of the embedded resource using the content fetched from the URL;
17. The method of claim 16, further comprising ignoring any difference between the third rendering result and the first rendering result during the calculation of the similarity score. Generating a third rendering result for the embedder of the embedded resource using the content fetched from the URL;
Determining a DOM node that is a difference between the first rendering result and the third rendering result;
17. The method of claim 16, further comprising ignoring the different DOM nodes in calculating the similarity score. Identifying a URL pattern common to a plurality of URLs stored in a fetch record, wherein the URL is one of the plurality of URLs;
Selecting a URL sample from the plurality of URLs, wherein the URL is one of the URL samples;
For each sample of the URL
Using content fetched from the URL to generate a first rendering result for the embedded resource embedder;
Generating a second rendering result for the embedder of the embedded resource without using the content;
Calculating each similarity score for the URL by comparing the first rendering result to the second rendering result;
Determining that the embedded resource is optional if the similarity score is greater than a similarity threshold;
Storing the URL pattern common to the plurality of URLs in the data store in response to each of a predetermined number of the similarity scores being greater than a similarity threshold. 11. The method according to 11.   12. The method of claim 11, wherein the pattern is the entire URL.