System for profiling page browsing interactions

Abstract

Systems and methods can optimize or attempt to optimize portions of scripts that might be overlooked by traditional compilers. These systems and methods can include a code analysis module that develops an aggregate execution profile for a script by aggregating individual execution profiles of a plurality of users. These systems and methods can use the aggregate execution profile to emphasize aspects of the script that can be optimized for a plurality of users, enabling improved script performance for users.

Description

BACKGROUND

Generally described, computing devices and communication networks can be utilized to exchange information. In a common application, a computing device can request content from another computing device via the communication network. For example, a user at a personal computing device can utilize a software browser application, typically referred to as a browser software application, to request a Web page from a server computing device via the Internet. In such embodiments, the user computing device can be referred to as a client computing device and the server computing device can be referred to as a content provider.

With reference to an illustrative example, a requested Web page, or original content, may be associated with a number of additional resources, such as images or videos, that are to be displayed with the Web page. In one specific embodiment, the additional resources of the Web page are identified by a number of embedded resource identifiers, such as uniform resource locators (“URLs”). In turn, software on the client computing devices, such as a browser software application, typically processes embedded resource identifiers to generate requests for the content. Accordingly, in order to satisfy a content request, one or more content providers will generally provide client computing devices data associated with the Web page as well as the data associated with the embedded resources.

Once the client computing device obtains the Web page and associated additional resources, the content may be processed in a number of stages by the software browser application or other client computing device interface. For example, and with reference to the above illustration, the software browser application may parse the Web page to process various HyperText Markup Language (HTML) layout information and references to associated resources, may identify and process Cascading Style Sheets (“CSS”) information, may process and instantiate various Javascript code associated with the Web page, may construct a native object model to represent one or more components of the Web page, and may calculate various layout and display properties of the processed content for presentation to a user.

BRIEF DESCRIPTION OF THE DRAWINGS

Throughout the drawings, reference numbers are re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate embodiments of the features described herein and not to limit the scope thereof.

FIG. 1 depicts an embodiment of a content delivery environment that can facilitate script optimizations based on aggregate profile data.

FIG. 2 depicts an embodiment of a script execution profile aggregation process.

FIG. 3 depicts an embodiment of a state flow diagram in which an aggregate execution profile of a script is provided to a client device.

FIG. 4 depicts an embodiment of a state flow diagram in which a decompiled script is provided to a client device.

FIG. 5 depicts an embodiment of a state flow diagram in which a compiled script is provided to a client device.

FIG. 6 depicts an embodiment of a state flow diagram in which an aggregate execution profile of a script is provided to a client device.

FIGS. 7 and 8 depict embodiments of example browser user interfaces that may implement any of the scripts described herein.

FIG. 9 depicts an embodiment of a state flow diagram in which a content page is modified based on user browsing interactions.

FIG. 10 depicts an example browser user interface that may implement the modified content page of FIG. 9.

DETAILED DESCRIPTION

I. Introduction

From the perspective of a user utilizing a client computing device, a user experience can be defined in terms of the performance and latencies associated with obtaining network content over a communication network, such as obtaining a Web page, processing embedded resource identifiers, generating requests to obtain embedded resources, and rendering content on the client computing device. Latencies and performance limitations of any of the above processes may diminish the user experience. Additionally, latencies and inefficiencies may be especially apparent on computing devices with limited resources, such as processing power, memory or network connectivity such as netbooks, tablets, smartphones, and the like.

One approach to improving performance of loading content pages, such as web pages, is to attempt to optimize compilation of a script included in the content. An example of a script language in common use in many content pages is JavaScript. Scripts coded in JavaScript may be compiled into bytecode and interpreted, or they may be directly compiled. In either case, optimizations may be implemented at the compile stage to improve performance (e.g., faster execution speed) to facilitate faster load and/or execution times. An example of a compiler used to compile JavaScript is the V8 JavaScript Engine included in the Google Chrome™ web browser. The V8 JavaScript Engine includes a performance profiler that profiles a script to create an execution profile having information about execution times and frequency that methods in the script are executed. The V8 JavaScript Engine runs the performance profiler on a client device of a user to obtain the execution profile and may use this profile to identify methods that have a certain “hotness” level, meaning, among other things, that such methods may be executed frequently. The V8 JavaScript engine can optimize or attempt to optimize these methods, for example, by performing function inlining, elision of runtime properties, loop unrolling, inline caching, or other optimization techniques. A programmer can also use the execution profile information manually to improve or otherwise optimize a script.

A drawback to the optimization techniques of compilers such as the V8 JavaScript Engine compiler is that such compilers tend to optimize only those functions or methods that are executed frequently, while overlooking slowly-executing functions that execute infrequently. However, for a network resource site, such as a web site, a script in a content page may include a function that executes infrequently for each user that visits the site but that actually executes frequently when taken in the aggregate over many users. Such a function may be slow and cause degraded performance for many users, particularly users of mobile devices.

This disclosure describes embodiments of systems and methods that can optimize or attempt to optimize portions of scripts that might be overlooked by traditional compilers. These systems and methods can include a code analysis module that develops an aggregate execution profile for a script by aggregating individual execution profiles of a plurality of users. These systems and methods can use the aggregate execution profile to emphasize aspects of the script that can be optimized for a plurality of users, enabling improved script performance for users.

As used herein, the term “optimize” and its derivatives, when referred to compilation or script execution techniques, in addition to having their ordinary meaning, are used herein to refer to improving one or more aspects of compilation or execution of a script (such as execution speed) and may, but need not, mean that a theoretically optimal or best compilation or execution of a script has been achieved. In addition, for convenience, script examples are described herein in the context of JavaScript, although other scripts in different script languages and scripting platforms may also take advantage of the features described herein, including, for example, VBScript, ActionScript/Flash, Silverlight, TypeScript, Dart, and the like. Further, although this disclosure focuses primarily on optimization of scripts, some or all of the features described herein may also be applied to computer program code other than scripts, including program code that is compiled into script code.

II. Example Content Delivery Environment

FIG. 1 illustrates an example content delivery environment 100 for delivering content to users. This content may include content pages, such as web pages or other electronic documents, mobile application content, or the like. The content pages may include any combination of text, images, videos, audio, animations, interactive features, and the like. The content may also include scripts embedded in or provided together with the content pages. The scripts can provide or enhance functionality of the content pages by, for example, enabling dynamic updating of content in the content pages. Advantageously, in certain embodiments, the content delivery environment 100 enables script optimizations to be performed based on aggregate profile data, as will be described in greater detail below.

The content delivery environment 100 can include an intermediary system 120, any number of client devices 104, and any number of content servers 106. The various systems may communicate with each other via a communication network 108. The network 108 may be a publicly accessible network of linked networks, possibly operated by various distinct parties, such as the Internet. In other embodiments, the network 108 may include a private network, personal area network, local area network, wide area network, cable network, satellite network, cellular telephone network, combinations of the same, or the like.

The intermediary system 120 can be any computing system that serves as an intermediary between a client device 104 and content servers 106 that serve the content. For example, the intermediary system 120 can be an intelligent proxy server, a system operated by an internet service provider (ISP), or some other device or group of devices that retrieve content on behalf of the client devices 104. The intermediary system 120 can include a number of components, such as a code analysis module 124, a content rendering engine 122, and a script profile data store 126. In some embodiments, the intermediary system 120 may include additional or fewer components than illustrated in FIG. 1. For example, the intermediary system 120 may include or otherwise be associated with various additional computing resources, such as content delivery network (CDN) systems, domain name system (DSN) servers, and the like.

The intermediary system 120 may include multiple computing devices, such as computer servers, logically or physically grouped together. The components of the intermediary system 120 can each be implemented as hardware, such as one or more server computing devices, or as a combination of hardware and software. In addition, the components of the intermediary system 120 can be combined on one server computing device or separated individually or into groups on several server computing devices. In some embodiments, the intermediary system 120 can include multiple instances of a single component, for example, implemented in virtual machines.

The client devices 104 can include a wide variety of computing devices, including personal computing devices, laptop computing devices, handheld computing devices, terminal computing devices, mobile devices (e.g., mobile phones, tablet computing devices, ebook readers, etc.), wireless devices, video game platforms, media players, and various other electronic devices and appliances. The client devices 104 may be configured with a browser application 112 to communicate via the network 108 with other computing systems, such the intermediary system 120 or content servers 106, and to request, receive, process, and display content. In addition, the client devices 104 can include a script engine 114 that interprets, compiles, or otherwise processes scripts included in the content. Moreover, the client devices 104 optionally include a page profiler 106 that can profile general user interactions with content pages. The page profiler 106 is described in greater detail below with respect to FIGS. 9 and 10.

The content servers 106 can each include one or more computing devices for hosting content and servicing requests for the hosted content over the network 112. For example, the content servers 106 can include a web server component that can obtain and process requests for content (such as content pages) from the client devices 104, the intermediary system 120, or other devices or service providers. In some embodiments, one or more content servers 106 may be associated with a CDN service provider, an application service provider, or the like.

In operation, one or more of the client devices 104 may be associated with the intermediary system 120. For example, the client device 104 may utilize proxy and caching services provided by the intermediary system 120. A user of the client device 104 may initialize the browser 112 and use the browser 112 to transmit a request for a content page, such as a web page. Due to the client device's 104 association with the intermediary system 120, the request may be transmitted to the intermediary system 120 rather than directly to the content server 106 of the content page. The intermediary system 120 can retrieve the content page from a content server 106 or some other source of the content page, such as a CDN system. The intermediary system 120 may process the content page prior to transmitting it to the client device 104. For example, the intermediary system 120 may utilize the content rendering engine 122 to partially or completely render the page, for example, by obtaining objects embedded in the page from various different content servers 106. The intermediary system 120 may then transmit the rendered content to the client device 104. Various examples of a content rendering engine 122 executing on an intermediary system 120 or other network computing component, and the browser 112 configurations and processing that can facilitate usage of the content rendering engine 122, is described in U.S. patent application Ser. No. 13/174,589, filed Jan. 3, 2013, titled “Remote Browsing Session Management,” the disclosure of which is hereby incorporated by reference in its entirety.

The intermediary system 120 may utilize the code analysis module 124 to obtain execution profile data from the client devices 104. These execution profiles may be received from the script engine 114 in the client devices 104. For example, if the client device 104 receives a script from the content rendering engine 122, the script engine 114 at the client device 104 can profile the script and export this profile to the code analysis module 124. The code analysis module 124 can accumulate or otherwise aggregate data obtained from these execution profiles into an aggregate execution profile. In one embodiment, the code analysis module 124 therefore creates an aggregate execution profile for each script, and this aggregate execution profile reflects the accumulated or aggregated execution profiles of multiple users.

The code analysis module 124 can store the received execution profiles and the aggregate execution profile in the script profile data repository 126. This repository 126 may include logical and/or physical computer storage, a database, or the like. In an embodiment, the script profile data repository 126 includes tables or other data structures that map scripts (or representations thereof) to execution profiles. Each script can be represented in the script profile data repository 126 by some unique value, such as a hash of the script, or the like. In one embodiment, the script profile data repository 126 is a key-value data store, such as a non-relational (or NoSQL) data store implemented in a cloud computing platform or infrastructure-as-a-service (IaaS) platform or the like.

Once the code analysis module 124 has received these execution profiles from a sufficient number of client devices 104, or otherwise has aggregated a sufficient amount of data, the code analysis module 124 can begin sending the aggregate execution profile to client devices 104 that subsequently receive the script from the content rendering engine 122 (and/or to devices 104 that have already received the script). The script engine 114 at the client device 104 can import the aggregate execution profile and use this profile to optimize compilation. Advantageously, in certain embodiments, this optimized compilation can have better results than traditional optimization that is based on a single user's interactions with the script. For example, the optimizations may cause more methods, functions, or routines in the script to compile with compiler optimizations.

In another embodiment, the code analysis module 124 compiles the script at the intermediary system 120 using the aggregate execution profile. The code analysis module 124 can either send this compiled version of the script to the client device 104 or can first decompile the compiled version and send the decompiled version to the client device. In either case, the script can execute with increased optimization. Other variations are possible, some examples of which are described in greater detail below.

It should be noted that the script engine 114 can be a modified version of an off-the-shelf or currently-available script engine. For instance, the script engine 114 may be modified to enable importing and/or exporting of execution profiles. The script engine 114 may include a plug-in, dynamic-linked library, or other code module that enhances the script engine's 114 functionality to allow importing and exporting of profiles. In another embodiment, the script engine 114 can be partially rewritten to include this enhanced functionality. In one embodiment, the script engine 114 is a modified version of the V8 JavaScript engine described above. Additional example modifications to off-the-shelf script engines 114 are described below.

In some embodiments, the script profile aggregation and optimization features described herein can also be implemented without the use of the intermediary system 120. For instance, the client devices 104 may communicate directly with the content servers 106 while forwarding script execution profiles to a third party server that aggregates the profiles for subsequent compiler optimizations (see, e.g., FIG. 6). Other embodiments are also described in greater detail below.

III. Example Script Optimization Process

FIG. 2 depicts an embodiment of a script profile aggregation process 200. The script profile aggregation process 200 can be implemented by the intermediary system 120 described above. In particular, certain blocks of the process 200 can be implemented by the content rendering engine 122 or the code analysis module 124 of the intermediary system 120. The process 200 need not be implemented by the intermediary system 120 and instead may more generally be implemented by any computing device. However, for convenience, the process 200 will be described in the context of the intermediary system 120.

At block 202 of the process 200, the content rendering engine 122 retrieve a script for a plurality of client devices (e.g., the client devices 104). The script may be a portion of a content page or mobile application requested by the client devices, as described above. Although not shown, in one embodiment, each time the content rendering engine 122 retrieves the script, the content rendering engine 122 can determine whether the script has changed since a previous time obtaining the script. If so, the content rendering engine 122 may direct the code analysis module 124 to discard execution profile data obtained for the script, as this data may be invalid for the changed script. The content rendering engine 122 can determine whether the script has changed by hashing the script and comparing the resulting hash value with a previously stored hash value obtained by hashing a previous version of the script. If the hash values differ, the scripts likely differ to a high degree of probability (which probability depends on choice of hash function). The content rendering engine 122 may instead (or also) examine any hypertext markup language (HTML) header associated with the script to determine whether data in the header indicates that a new version of the script has been received.

At block 204, the content rendering engine 122 provides the script to a plurality of client devices. The content rendering engine 122 provides the script to each client device for which it is requested. At block 206, the code analysis module 124 collects execution profiles of the script from the client devices 104 (or from a subset thereof, e.g., by obtaining a random sample). As described above, the script engine 114 in some or all of the client devices 104 can profile a user's actual usage of the script based on the user's interactions with the script. The resulting execution profiles generated by these script engines 114 can include information regarding which methods or functions were executed by the script, how often these functions were executed, and the amount of time that the functions took to execute, among other data. Further, the execution profiles may also include information about functions or other parts of the script that rarely or never executed, giving clues as to which functions or parts of the script to avoid optimizing. Similarly, the execution profiles may include information on the code path taken by users, including branch behavior of the script. For example, the execution profiles may include information regarding which branches (such as if-then statements, case statements, and switch statements) that were frequently or always followed. This information can also give clues as to which portions of the script to optimize (e.g., the branch that is most commonly selected). For instance, if 85% of the execution profiles indicate that a certain “if” statement was true, it may be beneficial to focus optimization on the Boolean true path of that “if” statement.

The code analysis module 124, at block 208, aggregates the collected execution profiles into an aggregate execution profile for the script. The code analysis module 124 can do so by accumulating related data in the execution profiles. For instance, the code analysis module 124 can accumulate the number of times various users executed or entered the same function in the script. The code analysis module 124 can repeat this process for each function. This aggregate number may be much higher for some functions that would ordinarily be executed a small number of times by individual users. As a result, this number may be used as a clue or data point that suggests that the related functions might benefit from optimization. Similarly, the total execution time for a given function or portion of the script can be accumulated by the code analysis module 124. Alternatively, the number of times that functions were executed or their execution times can be averaged by the code analysis module 124, or other mathematical operations may be performed on such data.

At decision block 210, the code analysis module 124 determines whether sufficient profile data has been obtained from the client devices 104. Once sufficient data has been obtained, the code analysis module 124 can proceed to send the aggregate execution profile for the script or perform script compiling (and associated optimizations) at block 212. The features of block 212 are described in greater detail with respect to subsequent FIGURES. However, if sufficient data is not obtained at block 210, the process 200 can loop back to block 204 (and/or block 202), where the process 200 continues to obtain script execution profiles from client devices 104 to which the script is provided.

Determining whether sufficient profile data has been obtained may be performed in a number of ways. The code analysis module 124 may, for instance, compare the number of execution profiles received with a predetermined threshold to determine whether a sufficient number of profiles have been received. Alternatively, the code analysis module 124 can determine whether a predetermined time period has elapsed prior to aggregating the profiles. In another embodiment, the code analysis module 124 optimizes or attempts to optimize a script until a certain hotness level is achieved for some or all of the methods of the script, such as the highest level of hotness. Once that level is reached, aggregation of the profile data may be considered sufficient.

In another embodiment, sufficiency is determined by determining whether there is convergence in the common code path detected in the aggregate execution profile. As described above, the code analysis module 124 can detect common code paths in the execution profiles and can store this information in the aggregate execution profile. As execution profiles are initially combined to create the aggregate execution profile, the common code path information may change rapidly because different client devices 104 may have entered different functions, branches, or the like. After several execution profiles have been aggregated into the aggregate execution profile, a common pattern may begin to emerge in function calls and/or branch behavior, such that the common code path information may start to change slowly, indicating convergence on a common code path or paths. In another embodiment, the code analysis module 124 determines whether the distribution of usage of the script's functions or branches has reached a stable or convergence point, at which point the code analysis module considers sufficiency to be reached. Moreover, the code analysis module may use any of the sufficiency measures described herein together or in concert to measure sufficiency.

Although aggregation may be considered sufficient, the code analysis module 124 may still continue to aggregate execution profiles in some embodiments. Further, in other embodiments, no check for sufficiency is made, and the code analysis module 124 sends aggregation profiles to the client devices 104 that request content as the aggregation profiles are made.

Furthermore, although the code analysis module 124 may collect data from every client device 104 with which it interacts, in other embodiments the code analysis module 124 samples profile data from a smaller subset of the client devices 104. Sampling profiles may be a more efficient way to obtain profile data than aggregating profile data from all client devices 104. In one embodiment, the code analysis module 124 samples a small portion of client devices 104 initially to determine whether most or all devices are taking the same (or substantially same) execution path. If most or all devices are taking the same (or substantially same) execution path, there may be little to no benefit in sampling more, as the code analysis module 124 knows which execution path to optimize.

Conversely, if in the small sample of execution profiles from client devices 104, the execution path is not converging, the code analysis module 124 may increase the sampling rate or percentage of client devices 104 being sampled until some convergence or stabilization in execution path is reached. Thus, in one example scenario, the code analysis module 124 may sample about 10% of client devices 104, ramp up to sampling about 50% of client devices 104 after not detecting convergence, and ramp down to sampling 5% (or even 0%, e.g., no longer collecting data) after reaching some measure of convergence or stability in the execution path.

IV. Example Script Optimization State Flows

FIGS. 3 through 5 depict various state flow diagrams in which the client device 104 requests content from the intermediary system 120, which in turn retrieves the content including a script from the content server 106. Each state flow diagram then focuses on how example embodiments of the intermediary system 120 interacting with the client device 104 to provide enhanced compilation of the script. For ease of illustration, further details regarding rendering and transmitting the remainder of the content are not shown. In addition, FIG. 6 depicts another embodiment of a state flow diagram for facilitating enhanced compilation of scripts that does not include an intermediary system 120. Each of the state flow diagrams in FIGS. 3 through 6 takes place after an aggregate execution profile is obtained for a script using the process 200 of FIG. 2.

Turning to FIG. 3, an embodiment of a state flow diagram 300 is depicted in which an aggregate execution profile of a script is provided to a client device 104. At state 1, the client device 104 requests content from the intermediary system 120. The intermediary system 120 in turn requests the content at state 2 from the content server 106. The content server 106 returns the content, including a script, at state 3 to the intermediary system 120.

At state 4, the intermediary system 120 identifies an aggregate execution profile associated with the script, for example, from the script data repository 126. If such a profile exists, the intermediary system 120 sends the aggregate execution profile to the client device 104 along with the script at state 5. At state 6, the client device 104 compiles the script with the aggregate execution profile using, for example, the script engine 114. The client device 104 then executes the compiled script at state 7. The client device 104 can also create another execution profile at state 8, based on the user's execution of the script, and can send this execution profile to the intermediary system at state 9. The intermediary system 120 can then incorporate the execution profile from the client device 104 in the aggregate execution profile.

In some embodiments, the script engine 114 of the client device 104 includes decision tree logic or the like that determines whether an aggregate execution profile has been received. If so, the client device 104 can use the aggregate execution profile to initiate compiler optimization instead of generating its own profile. However, in another embodiment, the client device 104 generates its own profile anyway and uploads this profile to the intermediary system 120 for further aggregation with the existing aggregate execution profile by the code analysis module 124. Thus, the code analysis module 124 can continue to aggregate and improve the aggregate execution profile based on information obtained from the client device 104. In still another embodiment, the client device 104 still performs its own execution profile but appends or otherwise aggregates the aggregate execution profile with its own, user-specific execution profile to create a custom aggregate execution profile. The script engine 114 can compile the script using this custom aggregate execution profile instead of the aggregate execution profile received at state 5.

In an embodiment, the script engine 114 in the client device 104 uses the aggregate execution profile to optimize compilation by identifying methods or functions or other parts of the script code that execute frequently, e.g., that have a certain hotness as described above. The client device 104 can then optimize these parts of the script during compilation. Advantageously, since the optimization of this compilation is performed based on the aggregate execution profile, optimization can be performed on most, more, or all of the script code to provide faster script code than might be obtained from an execution profile generated by a single client device 104.

In another embodiment, the intermediary system 120 can strip portions of the script that the intermediary system 120 has detected will never be executed or will likely not be executed prior to sending the script to the client device 104. The code path information contained in the aggregate execution profile can indicate to a high probability whether certain functions or branches of the script will never be executed based on aggregate behavior of many users. Stripping these portions of the script out of the script can beneficially reduce the network bandwidth consumption of the script's transmission to the client device 104 and can reduce the compile, execution, and/or load time of the script at the client device 104.

FIG. 4 depicts an embodiment of a state flow diagram 400 in which a decompiled script is provided to a client device 104. As above, at state 1, the client device 104 requests content from the intermediary system 120. The intermediary system 120 in turn requests the content at state 2 from the content server 106. The content server 106 returns the content, including a script, at state 3 to the intermediary system 120.

However, instead of sending an aggregated execution profile of the script to the client device 104, the intermediary system 120 instead compiles the script using the aggregate execution profile at state 4. At state 5, the intermediary system 120 decompiles the script. The resulting decompiled script may be more optimized than the script originally received at state 3. This increased optimization may be due in part to compilation of the script using the aggregate execution profile, which may indicate which portions (e.g., functions or subparts thereof) of the script are never logically executed. The compiler, when optimizing the script code, can remove or discard these portions of the code that are never logically executed. Some examples of code that may never be executed include debug code used during development of the script that now cannot logically be reached and branches of conditional statements that can never logically be reached. Further, the compiled code may also be optimized based on the other benefits of the aggregate execution profile described above.

The decompiled script is sent by the intermediary system 120 to the client device 104 at state 6. One advantage of sending this compiled and then decompiled code is that it may also be smaller in size, due to the removed code. Thus, transmission may consume less bandwidth and may be accomplished faster. The client device 104 can compile and execute the script at states 7 and 8, respectively. Further, as above with respect to FIG. 3, the client device 104 can also create another execution profile at state 9, based on the user's execution of the script, and can send this execution profile to the intermediary system at state 10. The intermediary system 120 can then incorporate the execution profile from the client device 104 in the aggregate execution profile.

In an embodiment, when compiling the script, the client device 104 can perform additional optimizations. In another embodiment, however, the client device 104 skips these optimizations since optimizations were initially performed by the intermediary system 120 when compiling the script at state 5. Skipping these optimizations can save compile time in some embodiments.

In an embodiment, the server-side compilation shown in FIG. 4 can compile just a part of the script that the client devices 104 tend to not focus on optimizing to reduce compile time in the intermediary system 120. If the aggregate execution profile indicates that a certain method is executed very frequently on any given individual client device 104, the intermediary system 120 can leave that method unoptimized and uncompiled, as the client device 104 will likely optimize that method. Conversely, the intermediary system 120 can focus on optimizing and compiling methods that tend not to be frequently executed on any given individual client device 104 because otherwise, the client device 104 might not optimize those methods. As an example, a script-based video game may include an initialization portion and a main game loop. The main game loop may execute frequently, such that the intermediary system 120 can have a level of confidence that the client device 104 will likely optimize that portion of the script. Conversely, the initialization portion may be executed much less frequently, and the intermediary system 120 can compile and optimize that portion while leaving the rest of the script uncompiled.

FIG. 5 depicts an embodiment of a state flow diagram 500 in which a compiled script is provided to a client device 104. The state flow diagram 500 proceeds as the state flow diagram 400 until state 5, where instead of decompiling the compiled code and sending the decompiled code to the content device 104, the intermediary system 120 sends the compiled code directly to the client device 104. The client device 104 can then execute the compiled script.

Thus, in FIG. 5, the client device 104 can skip the compilation process and thereby execute the script faster. However, the browser 112 of the client device 104 may be modified to expect to receive the compiled script instead of the script source code.

FIG. 6 depicts an embodiment of a state flow diagram 600 in which an aggregate execution profile of a script is provided to a client device 504 without using an intermediary system 120. The client device 504 can have all the functionality of the client device 104 described above, as well as additional functionality described herein.

At state 1, the client device 504 sends a content request directly to the content server 106. The content server 106 responds at state 2 with the content, which includes a script. At state 3, the client device 504 requests an aggregate execution profile of the script from a script analysis system 524. In one embodiment, the browser in the client device 504 is modified to request the aggregate execution profile at state 3 in response to receiving the script at state 2.

The script analysis system 524 can include all of the functionality of the code analysis module 124 described above but may be implemented as an independent system other than the intermediary system 120. The script analysis system 524 may also implement the process 200 of FIG. 2 to obtain execution profiles from a plurality of client devices 504 and aggregate these profiles into an aggregate execution profile.

At state 4, the script analysis system 524 provides the aggregate execution profile to the client device 504. As in FIG. 3, the client device 504 can use the aggregate execution profile to compile and execute the script at states 6 and 7.

Alternatively, the client device at state 3 can provide the script to the script analysis system 524, which can compile the script using the aggregate execution profile and send either the compiled version or a decompiled version thereof to the client device 504. Thus, in certain embodiments, the state flow diagram 600 of FIG. 6 acts as a pull model, with the client device 504 pulling either aggregate execution profile information or optimized script code from the script analysis system 524. In contrast, the state flow diagrams 300-500 of FIGS. 3 through 5 operate as push models, with the intermediary system 120 providing either aggregate execution profile information or optimized script code to the client device 104.

V. Example Browser User Interfaces

FIG. 7 depicts an embodiment of an example browser user interface 700 that may implement any of the scripts described herein. The browser user interface 700 includes a content page 702 that further includes example user interface controls 710-730, any number of which can trigger a script associated with the user interface 700 to be executed. In the depicted embodiment, the controls 710-730 include a text box control 710, a search button 720, and links 730. User selection of any of these controls 710-730 can cause a script embedded in the content page 702 to execute and perform any of a variety of actions, such as loading a new page, making a dynamic modification to the content page 702, bounds-checking input values (e.g., in the text box 710), and so forth. Advantageously, in certain embodiments, the script or scripts executed can be optimized or improved using any of the techniques described above.

As an example, a select box control 740 is shown with the text “Select Language.” A user can select the select box control 740 using a mouse cursor 742 (or with the user's finger on a mobile device, without a cursor) to cause the select box control 740 to expand. Instead of using the standard HTML select box, in an embodiment, the browser user interface 700 can use a custom select box based on a script such as JavaScript to output a more full-featured select box. Thus, for example, user selection of the select box control 740 can cause a menu 850 such as that shown in a browser user interface 800 of FIG. 8 to be displayed. The menu 850 is wider, being double-columned, than a standard HTML text box, and includes languages that may be selected to cause the content page 702 to be translated into the selected language. In one embodiment, the code analysis module 124 can determine from aggregate execution profiles that users frequently select the select box control 740 and select a specific language in a particular geographic region. The content rendering engine 122 can use this information to optimize the execution of this script.

Further, the content rendering engine 122 can use this information to cause the content page 702 to automatically select the desired language and translate the page, for example, using any of the content page profiling techniques described below.

VI. Content Page Profiling

As described, profiling can be performed for code other than scripts. For example, code profiling can be done to identify execution paths of browser code, such as HTML code, in addition to or instead of script code. It may be useful, for instance, to determine which common browsing actions a plurality of users take so as to enable those actions to be taken beforehand by pre-rendering a content page.

Referring again to FIG. 1, as mentioned above, the client device 104 can also include a page profiler 116. The page profiler 116 may include hardware and/or software for profiling user browsing interactions with respect to one or more content pages. The page profiler 116 may be integral with the browser 112 (e.g., as a plug-in) or may be a separate component that communicates with the browser 112. The page profiler 116 can identify user interactions with a content page provided by the intermediary system 120 or a content server 106, including interactions such as selection of a link, expansion of a menu, scrolling of the content page, playing a video, filling at least a portion of a form, expanding a select box, or interaction with a script to perform any of these actions or others. More generally, the page profiler 116 can identify an execution path of the client device 104 based on the browsing actions of a user. The execution path may include a click path taken by a user. As an example, the execution path might include information about a user clicking a first link, then expanding a menu and selecting a second link from the menu, followed by the user scrolling to the bottom of the page.

The page profiler 116 can provide this browsing profile data to the code analysis module 124 of the intermediary system 120. The code analysis module 124 can aggregate this profile data to produce an aggregate execution profile or aggregate browsing profile for a content page, much like the aggregate script execution profiles described above. In an embodiment, this aggregate browsing profile can include information on common execution paths taken by the client devices 104, the number or frequency of user browse interactions with the content page, and so forth. The code analysis module 124 can perform sampling, similar to any of the sampling techniques described above, to collect profile data from a portion of the client devices 104, rather than all devices 104, in some embodiments.

The content rendering engine 122 can use the aggregate browse profile to modify the content page to reflect a common browse interaction or execution path in response to the content page being requested by one of the client devices 104. Thus, for example, if the aggregate browsing profile includes a common execution path taken by many client devices 104 such as expanding a particular menu, the content rendering engine 122 can modify the code of the content page to expand the menu and send the modified content page to the requesting client device 104. In another example embodiment, pre-selection of a link by the content rendering module 122 causes the content rendering module 122 to fetch the linked-to content page from the content server 106 and supply this linked-to content page as the modified page in place of the originally-requested content page. As a result of modifying the page (or fetching a linked-to page), the content rendering engine 122 can enable users to reach more relevant content in the modified content page faster than if the content rendering engine 122 were to send the unmodified content page to the client device 104.

As another example, users may access a content page and commonly scrolling immediately to a bottom portion of the page. The code analysis module 124 can identify this common scroll point as, for example, a common X (horizontal), Y (vertical) position (or just Y position) taken by users. The content rendering engine 122 can subsequently modify the content page to reflect this common scroll point, such that the browser 112 of the client device 104 receiving the modified content page scrolls immediately to the common scroll point.

In one embodiment, the content rendering engine 122 can be said to pre-render the content page to create any of the modifications described above. Such modifications can speed up the user browsing experience and may be particularly beneficial for mobile devices, although any device or user may benefit from faster loading of relevant content.

The content rendering engine 122 can use thresholding techniques to determine which execution paths to take when modifying a content page. For instance, the content rendering engine 122 can determine whether a threshold percentage of users take a certain execution path. If the threshold is met, the content rendering engine 122 can modify the content page to match the execution path (or at least a portion thereof). The threshold may be a relatively high percentage for some browse actions and relatively lower percentage for other browse actions. Some browse actions, like selecting a link to fetch a new content page, may have a higher threshold than expanding a menu to show a submenu, for instance. In some embodiments, more major modifications to the page may have a higher threshold than more minor modifications to a page. Some examples of major modifications might include, for example, selecting of links, selecting of menu options, and the like, while some examples of minor actions can include playing a video upon loading, filling commonly-filled fields of a form with generic information, and so on. However, any of the above user browse actions can be considered either major or minor modifications in different scenarios, which may depend on the type of content page being modified.

FIG. 9 depicts an embodiment of a state flow diagram 900 in which a content page is modified based on user browsing interactions. At state 1, the client device 104 requests a content page from the intermediary system 120. The intermediary system 120 in turn requests the content page at state 2 from the content server 106. The content server 106 returns the content page at state 3 to the intermediary system 120. The content page may or may not include a script.

At state 4, the intermediary system identifies one or more common browsing interactions based on aggregate browsing data collected from a plurality of client devices 104. The intermediary system 120 can then pre-render the content page based on the browsing interaction to produce a modified content page at state 5. The intermediary system 120 then sends the modified content page to the client device at state 6. The client device 104 can then output the modified content page at state 7, which may include performing other rendering of the page.

FIG. 10 depicts an example browser user interface 1000 that may implement the modified content page described above with respect to FIG. 9. The browser user interface 1000 includes all the features of the browser user interface 700 of FIG. 7. In particular, the browser user interface 1000 is an embodiment of a modified content page, where the original content page is the browsing user interface 700 of FIG. 7.

In an embodiment, the code analysis module 124 of FIG. 1 may identify a common user browse action with respect to the browsing user interface 700 of FIG. 7, in that most users initially select the “Entertainment” link 730 upon loading of the browsing user interface 700. The content rendering engine 122 can therefore modify the code of the browsing user interface 700 to cause the browsing user interface 1000 to already have this link selected upon loading. As a result, in this particular example embodiment, the browsing user interface 1000 includes a listing of sub-links 1010 below the “Entertainment” link 730 upon loading of the browsing user interface 1000, as if the user had pre-selected the “Entertainment” link 730 without actually requiring the user to do so.

VII. Terminology

Many other variations than those described herein will be apparent from this disclosure. For example, depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithms). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines and/or computing systems that can function together.

The various illustrative logical blocks, modules, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor may also include primarily analog components. For example, any of the signal processing algorithms described herein may be implemented in analog circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, and a computational engine within an appliance, to name a few.

The steps of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of non-transitory computer-readable storage medium, media, or physical computer storage known in the art. An example storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal.

Conditional language used herein, such as, among others, “can,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list. Further, the term “each,” as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term “each” is applied.

While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As will be recognized, certain embodiments of the inventions described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others.

Claims

1. A system for pre-rendering a content page, the system comprising: a code analysis module comprising computer hardware, the code analysis module configured to: collect page browsing information related to browsing interactions taken with respect to a content page causing a change to a visual state of the content page; andidentify, from the page browsing information, a common browsing interaction taken with respect to the content page by a plurality of client devices, wherein the common browsing interaction comprises selection of a link to a second content page; anda content rendering engine configured to execute on a server computing system and further configured to: receive a request from a first client device to access the content page; andin response to the request: modify at least a portion of the content page based on the common browsing interaction by pre-selecting the link to fetch the second content page; andprovide the second content page to the first client device in place of the content page.

2. The system of claim 1, wherein the code analysis module is further configured to identify the common browsing interaction by identifying a common browsing interaction having a threshold frequency of occurrence among the plurality of client devices.

3. The system of claim 1, wherein the code analysis module is further configured to collect the page browsing information by collecting information about click paths taken by the plurality of client devices with respect to the content page.

4. The system of claim 1, wherein the code analysis module is further configured to identify a second common browsing interaction comprises comprising one or more of the following: expansion of a menu, scrolling of the content page, playing a video, filling at least a portion of a form, or expanding a select box, andwherein the content rendering engine is further configured to modify, in response to a second request for the content page, at least a portion of the content page to reflect the second common browsing interaction.

5. The system of claim 4, wherein the content rendering engine is further configured to modify at least a portion of the content page by modifying code of the content page to reflect the second browsing interaction.

6. The system of claim 4, wherein the content rendering engine is further configured to modify at least a portion of the content page by causing the modified content page to expand the menu.

7. The system of claim 4, wherein the content rendering engine is further configured to modify at least a portion of the content page by scrolling the content page to a common scroll point.

8. The system of claim 4, wherein the content rendering engine is further configured to modify at least a portion of the content page by causing the modified content page to graphically emphasize the link.

9. Non-transitory physical computer storage comprising instructions stored thereon that, when executed in one or more processors of a server computing device, are configured to implement pre-rendering of a content page, the instructions comprising: a code analysis module configured to: collect page browsing information related to user interactions taken with respect to a content page causing a change to a visual state of the content page; andidentify, from the page browsing information, a common user action taken with respect to the content page by a plurality of client devices, wherein the common user action comprises selection of a link to a second content page; anda content rendering engine configured to: receive a request from a first client device for the content page; andin response to the request: modify at least a portion of the content page based on the common user action by pre-selecting the link to retrieve the second content page; andprovide the second content page to the first client device in place of the content page.

10. The non-transitory physical computer storage of claim 9, wherein the code analysis module is further configured to identify the common user action by identifying a common browsing interaction having a threshold frequency of occurrence among the plurality of client devices.

11. The non-transitory physical computer storage of claim 9, wherein the code analysis module is further configured to collect the page browsing information by collecting information about click paths taken by the plurality of client devices with respect to the content page.

12. The non-transitory physical computer storage of claim 9, wherein the code analysis module is further configured to identify a second common user action comprising one or more of the following: expansion of a menu, scrolling of the content page, playing a video, filling at least a portion of a form, or expanding a select box, andwherein the content rendering engine is further configured to modify, in response to a second request for the content page, at least a portion of the content page to reflect the second common user action.

13. The non-transitory physical computer storage of claim 12, wherein the content rendering engine is further configured to modify at least a portion of the content page by modifying code of the content page to reflect the second common user action.

14. A computer-implemented method comprising: as implemented by a server computing system comprising one or more computing devices configured to execute specific instructions, collecting page browsing information related to user interactions taken with respect to a content page causing a change to a visual state of the content page;identifying, from the page browsing information, a common user action taken with respect to the content page by a plurality of client devices, wherein the common user action comprises selection of a link to a second content page; andin response to receiving a request for the content page from a first client device: modifying at least a portion of the content page based on the common user action by pre-selecting the link to retrieve the second content page; andsending the second content page to the first client device in place of the content page.

15. The computer-implemented method of claim 14, wherein identifying the common user action comprising identifying a common user action having a threshold frequency of occurrence among the plurality of client devices.

16. The computer-implemented method of claim 14, wherein collecting the page browsing information comprises collecting information about click paths taken by the plurality of client devices with respect to the content page.

17. The computer-implemented method of claim 14, further comprising: identifying a second common user action comprising one or more of the following: selection of a link, expansion of a menu, scrolling of the content page, playing a video, filling at least a portion of a form, or expanding a select box; andmodifying, in response to a second request for the content page, at least a portion of the content page to reflect the second common user action.

18. The computer-implemented method of claim 14, wherein modifying at least a portion of the content page comprises modifying code of the content page to reflect the second common user action.