
Polaris: Faster Page Loads Using Fine-grained Dependency Tracking [pdf] - Libertatea
http://mickens.seas.harvard.edu/files/mickens/files/polaris.pdf
======
outsidetheparty
This press release is rather light on details. The actual paper can be found
here:

[http://mickens.seas.harvard.edu/files/mickens/files/polaris....](http://mickens.seas.harvard.edu/files/mickens/files/polaris.pdf)

I haven't completely digested it, but it looks like it works by a combination
of pre-calculating a dependency graph for each page, which it then tweaks
during the real page load depending on current network conditions.

~~~
dang
Ok, we changed the URL to that from [http://news.mit.edu/2016/system-loads-
web%20pages-34-percent...](http://news.mit.edu/2016/system-loads-
web%20pages-34-percent-faster-0309).

------
tyingq
Based on the related paper[1], this appears to be more of a proof of concept
than something you might introduce into production.

For example:

 _" To evaluate a JavaScript file, the scheduler uses the built-in eval()
function that is provided by the JavaScript engine. To evaluate HTML, CSS, and
images, Polaris leverages DOM interfaces like document.innerHTML to
dynamically update the page’s state"_

So, it relies on eval(), which will slow down javascript significantly, and
document.innerHTML, which will slow down rendering. It's trading asset
download improvements for rendering slowdown.

The high level advice of streamlining the dependency chain of page assets is
laudable, but this doesn't sound like the right approach.

[1][http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf](http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf)

~~~
outsidetheparty
I'm not 100% certain, but it looks like that parsing is meant to be done ahead
of time, rather than on the fly?

> _" To use Polaris with a specific page, a web developer runs Scout on that
> page to generate a dependency graph and a Polaris scheduler stub. The
> developer then configures her web server to respond to requests for that
> page with the scheduler stub’s HTML instead of the page's regular HTML._"

(But even if I've misunderstood that and it is realtime, the network is still
a tighter bottleneck than the page renderer in most cases, so it seems like a
generally reasonable tradeoff to me.)

I'm curious how well this compares to e.g. a plain old webpack solution though
-- ideally you'd have organized your assets well enough in the first place
that something like Polaris would be unnecessary. "Ideal" is often a long way
from reality, of course.

~~~
tyingq
The calls to eval() and manipulation of innerHTML are runtime...they describe
it as what the "scheduler stub" does, which is the runtime code that parses
the "processed page" and recreates it.

eval() is a significant concern for performance.

------
riskable
This seems very similar to the system I came up with to reduce load times for
JavaScript and CSS assets in Gate One a few years ago:

[https://github.com/liftoff/GateOne/blob/master/gateone/core/...](https://github.com/liftoff/GateOne/blob/master/gateone/core/server.py#L2743)

Instead of letting the browser figure out which assets to load--using multiple
GET requests--it delivers assets over the existing WebSocket connection and
_also_ caches those assets at the client in IndexedDB. So the client only ever
has to download JavaScript/CSS assets _once_ unless they change on the server
(in which case they'll get re-synchronized automatically).

The mechanism loads _much_ faster than allowing the client browser to perform
all those (latency-unfriendly) GET requests. It is also superior to file
concatenation since you can change any individual asset without having to
worry about the impact of all clients having to re-download that one huge
concatenated file.

------
phatbyte
Doesn't HTTP2 solves this by using Stream dependencies? It seems to be a lot
clean than using JS eval()

~~~
riskable
Yes, it does. By keeping the connection persistent while assets are loaded you
completely do away with the latency introduced by using multiple separate GET
requests.

HTTP2 is basically like loading all your assets over an existing WebSocket.

------
nateberkopec
I'm curious to know how much this improves page loads when resource hints are
used properly. I may be failing to understand the paper, but it seems to me
that strong usage of resource hints plus HTTP/2 dependency-based
prioritization makes a lot of this technique obsolete.

~~~
youngtaff
There's quite a gap and a lot of head scratching between the theory of H2
dependence based prioritization and the reality of implementation - for
example Chrome haven't even implemented it yet.

Even with resource hints, H2 etc. the browser is still discovering the
dependencies at run time and relying to the developer to hint them correctly
for some performance speed up.

~~~
spankalee
Except with resources where it's trivial for the server to determine the
dependency graph, like ES2015 modules and HTML imports. In these cases the
server can send push dependencies before the client even receives the initial
document.

------
deadowl
I've seen significant script delays from loading files on the server, before
ever getting to the web browser. I.e. apparently the file server was on the
network, but not the same machine as the web server. I was using Smarty as a
templating engine, and I had a template for a table row that loaded many times
during the rendering of a particularly long table. It literally was loading
the file once for every time a table row had to be generated, and it came with
a lot more overhead than I would ever expect.

I switched the include directive to inline for the table row, but I was using
template directives that were not supported inline by the template compiler.
In the end I had to add some code to the compiler in order to get a reasonable
performance time (thank you open source).

------
imaginenore
How does it compare with HTTP/2 or even SPDY?

------
SimeVidas
Or websites could just optimize themselves for fast “first render”. It’s not
rocket science. Start by making sure your non-critical assets don’t block
rendering. (E.g. many large news sites still have FOIT-inducing web fonts,
which should be considered an amateur’s mistake at this point.)

~~~
blowski
It's not an either/or. If this helps people who want content from slow
websites without requiring the slow website to do very much, and it has no
impact on existing websites, then what's the problem?

------
mchahn
Couldn't you get close to optimization by just observing the load order in a
real page load? Why go to the trouble to construct the dependency graph?

------
gravypod
What I've found helps, if you really need to squeeze that performance out of a
server, is setting up a ram disk for your /var/ directory, or one small
ramdisk for every small web page you are running.

That running with lighttpd will probably be the fastest you can easily pull
from a web-server.

Also I try to never directly edit the ramdisk. I write changes to a git repo
and write a small script to pull from the repo and directly write to the disk
immediately.

------
samfisher83
Is the software available to download?

~~~
gravypod
I don't see any place to get it. That's what I've always found funny about
academic CS work.

------
zv
tl;dr anyone? For me - what is seems it tries to automagically optimize poorly
written webpages.

~~~
tyingq
It changes the page fairly dramatically. Before rolling out a page, you run it
through their parser, which creates skeletal html and a javascript stub which
you serve in place of the original html.

Then, when this substituted page is loaded, their javascript rebuilds the
original web page with calls to eval() and whatever.innerHTML, in a way that
the dependencies are supposedly streamlined.

~~~
joveian
Ug, just what we need - more pages that don't work without javascript :(. You
know what really speeds up the web? Turning off javascript...

------
Chlorus
Wait, is that _the_ James Mickens?

[https://www.usenix.org/system/files/1309_14-17_mickens.pdf](https://www.usenix.org/system/files/1309_14-17_mickens.pdf)

~~~
outsidetheparty
The Mickens of fame and fortune.

I aspire to someday be the kind of guy who gets the definite article prepended
to his name

~~~
JadeNB
> I aspire to someday be the kind of guy who gets the definite article
> prepended to his name

Some comedian (Demetri Martin, maybe?) called this "the American version of
royalty."

~~~
eyko
At least it's not hereditary.

