Scout first rewrites a page's HTML and JavaScript objects such that, upon execution, they will output a list of reads and writes to the page's state. These log entries include details such as the filename and line number that trigger the read or write, as well as variable names and object id information. Scout then processes this log to extract dependencies between objects on a page. Using these dependencies, Scout outputs the fine-grained dependency graph for the given page.

Today's browsers are constrained by uncertainty regarding how objects on a page interact. As a result, they are forced to use conservative assumptions when loading pages, to ensure correctness. For example, because browsers today don't know whether two objects on a page share state (and thus have a dependency between one another), they are forced to load these objects serially, in the order that the corresponding HTML tags are in. While this ensure correctness, it often fails to fully utilize network and CPU resources during page loads, and thus prevents browsers from loading pages as quickly as possible.

Polaris tackles this problem by exposing fine-grained dependency graphs (generated by Scout) to browsers, along with a JavaScript scheduling library (the scheduler stub). Executing the scheduler library enables browsers to completely load pages from JavaScript, in a way that most efficient utilizes the available resources, and thereby reduces the number of round trips between clients and servers, and thus, the page load time. To load a page, the scheduler uses XMLHttpRequests to fetch objects, and functions like window.eval() to evaluate responses. Importantly, the scheduler dynamically prioritizes requests that are blocking the largest number of subsequent requests, based on the fine-grained dependency graph.

This high level diagram shows how Scout and Polaris cooperate to reduce page load times. Web servers can run Scout offline to generate fine-grained dependency graphs for each page that they may serve to clients. Then, upon a client request for a page, Web servers will respond with the Polaris stub, instead of just responding with the top-level HTML for the page. The stub has three components: the fine-grained dependency graph for the page, the original HTML for the page, and the Polaris JavaScript scheduling library which uses the dependency graph and HTML to completely load the page in an efficient way. Note that client browsers are completely unmodified.

The Polaris research paper, which provides more details about the design and evaluation of Scout and Polaris, was presented at the 2016 USENIX Symposium on Networked Systems Design and Implementation (NSDI '16).