The research paper[1] describes Polaris. Basically, you have to make large, sweeping changes to your html, server side. Instead of your original page + js references, you serve a bunch of javascript that then dynamically recreates your page on the client side in the most performant way that it can:
• The scheduler itself is just inline JavaScript code.
• The Scout dependency graph for the page is represented
as a JavaScript variable inside the scheduler.
• DNS prefetch hints indicate to the browser that the
scheduler will be contacting certain hostnames in
the near future.
• Finally, the stub contains the page’s original
HTML, which is broken into chunks as determined
by Scout’s fine-grained dependency resolution
It's in between. It's a way for website developers to explain the dependencies for the files (in html or JavaScript or whatever) and a change needed for browsers to know how to use this new data to make better requests to the server.
• The scheduler itself is just inline JavaScript code.
• The Scout dependency graph for the page is represented as a JavaScript variable inside the scheduler.
• DNS prefetch hints indicate to the browser that the scheduler will be contacting certain hostnames in the near future.
• Finally, the stub contains the page’s original HTML, which is broken into chunks as determined by Scout’s fine-grained dependency resolution
[1]http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf