10 ms·

System loads web pages 34 percent faster by fetching files more effectively

177 points by qwename 10y ago

qwename 10y ago
Relevant paper: "Polaris: Faster Page Loads Using Fine-grained Dependency Tracking", http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf
- naasking 10y ago
  Argh, don't people Google names before using them? Polaris was HP's virus-safe Windows project: http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html
  - Ar-Curunir 10y ago
    So... completely unrelated to this project's aim?
  - manarth 10y ago
    The quintessential hardest problem in IT: naming things. Polaris is also a missile. And a star. And a PowerPC port of Solaris. We're always going to have name duplication. At least it's fairly easy to disambiguate with a Google search.
tyingq 10y ago
Interesting. The paper was released before HTTP/2 was in widespread use. They do show that their approach has significant improvements over SPDY alone...I wonder how the comparison to HTTP/2 alone would fare.
- k_lander 10y ago
  is there significant difference in performance between HTTP/2 and SPDY?
  - tyingq 10y ago
    There seems to be, yes. Surprisingly little information to be had though. http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/ http://blog.httpwatch.com/2015/01/16/a-simple-performance-co... I don't think server push was used in this benchmark, it's arguably a poor mans way to achieve part of what's discussed in the referenced paper (serving early dependencies...early).
- vitus 10y ago
  Personally, I'm more curious to see the comparison with QUIC, which eliminates the RTTs to set up TCP + TLS, and multiplexes connections in a way that doesn't lead to the head-of-line blocking problem that you can see with HTTP/2 over TCP -- QUIC uses UDP, so no requirement for in-order delivery across the entire connection, just within each resource flow (in this context, each request). On that note, I do think it's a bit inaccurate to say that Google's efforts are/were primarily focused on data compression -- yes, they did introduce brotli, which is just a better LZ77 implementation (primary difference with gzip is that window size isn't a fixed 32KB), but they also pioneered SPDY (which turned into HTTP/2 after going through the standards committee) and now QUIC. (obligatory disclaimer that google gives me money, so I am biased)
  - tyingq 10y ago
    Wouldn't it be difficult to do a straight comparison without other variables, given that there isn't a popular webserver that supports the protocols they tested with, as well as QUIC? Edit: Should note that I'm excited about QUIC as well, just thought I may have been missing some new development where it's (already) more usable outside Google's walls.
    - vitus 10y ago
      It is, but that doesn't change the fact that I'm still more curious on that front. The wiki page has a few sample servers [0], but again, those don't meet your criterion of popular. I realize that the initial RTT reduction isn't so relevant in the context of large dependency graphs, but especially in the context of packet loss, the proper multiplexing across flows seems useful. There are also a number of other QUIC-based features that might be relevant, since it does essentially reimplement the relevant parts of the TCP stack, so parameter choices might be better suited to today's internet (as opposed to 1980's). [0] https://en.wikipedia.org/wiki/QUIC#Server_support https://en.wikipedia.org/wiki/QUIC#Server_support
- breischl 10y ago
  Aren't they orthogonal? No matter how fast HTTP/2 is or how much it decreases connection setup times, requesting resources in the "right" order will always be faster than doing it in one of the "wrong" orders. More efficient protocols might reduce the disparity, but there should always be one. Right?
  - bastawhiz 10y ago
    Server push in HTTP/2 can force files to load in the right order.
  - tyingq 10y ago
    Yes, it would always be faster, assuming relatively heavy pages. But the reduced number of requests, hpack compression, and server push features in HTTP/2 might reduce the performance improvement to something less impressive. Given that Polaris has some downsides, it might reduce it to the point that you wouldn't consider it. In it's current state, Polaris requires a lot of pre-work...including dependency analysis via a real browser. It also serves up pages that wouldn't work with javascript disabled, and might not be terribly search engine friendly.
Thiez 10y ago
> What Polaris does is automatically track all of the interactions between objects, which can number in the thousands for a single page. For example, it notes when one object reads the data in another object, or updates a value in another object. It then uses its detailed log of these interactions to create a “dependency graph” for the page. > Mickens offers the analogy of a travelling businessperson. When you visit one city, you sometimes discover more cities you have to visit before going home. If someone gave you the entire list of cities ahead of time, you could plan the fastest possible route. Without the list, though, you have to discover new cities as you go, which results in unnecessary zig-zagging between far-away cities. What a terrible analogy. Finding a topological sorting is O(|V|+|E|), while the traveling salesman problem is NP-complete.
- to3m 10y ago
  That's amusing, and I wonder if this particular analogy was chosen deliberately. But I don't think there's anything wrong with it - it's designed to make intuitive sense to non-programming readers, not to be some rigorous description that can be automatically translated into optimal code.
  - Thiez 10y ago
    Perhaps a different analogy would be better, e.g. ordering materials when building a house. If you can only order one material at a time, you would probably want to order the concrete for laying the foundation before ordering the roof tiles. Loading website resources is a lot like that (at least compared to the travelling salesman).
    - saurik 10y ago
      This still smells NP Hard. I mean, in practice for simple dependencies it is probably quite tractable, but this is a combinatorial optimization problem that seems pretty similar to an online modification to Job Shop Scheduling, where the material requirements map loosely to machine-task pairings that would be unblocked by orders, acting to make the problem more complex, not easier.
tedunangst 10y ago
So, uh, what does it do? I mean, I can't even tell if it's a server or client side change.
- naor2013 10y ago
  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.
- tyingq 10y ago
  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 [1]http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf
  - manmal 10y ago
    That sounds like a fun idea for a precompiler.
uaaa 10y ago
Is there a comparison with Google AMP?
- andrewguenther 10y ago
  Paper was released way before AMP. Also not really related to AMP, so I don't think it's necessary to draw a comparison.
leeoniya 10y ago
but we can already make web pages load 500% faster by not shoveling a ton of shit, not loading scripts from 60 third-party domains (yes stop using CDNs for jQuery/js libs, those https connections aren't free - they're much more expensive than just serving the same script from your existing connection), reducing total requests to < 10, not serving 700kb hero images, 1.22MB embedded youtube players [1], 500kb of other js bloat, 200kb of webfonts, 150kb of boostrap css :/ the internet is faster than ever, browsers/javascript is faster than ever, cross-browser compat is better than ever, computers & servers are faster than ever, yet websites are slower than ever. i literally cannot consume the internet without uMatrix & uBlock Origin. and even with these i have to often give up my privacy by selectively allowing a bunch of required shit from third-party CDNs. no website/SPA should take > 2s on a fast connection, (or > 4s on 3g) to be fully loaded. it's downright embarrassing. we can and must do better. we have everything we need today. [1] https://s.ytimg.com/yts/jsbin/player-en_US-vfljAVcXG/base.js https://s.ytimg.com/yts/jsbin/player-en_US-vfljAVcXG/base.js
- deleted 10y ago
  [deleted]
- kup0 10y ago
  Yeah the problem really isn't the technology, it's our poor use of it.
  - visarga 10y ago
    Some files could be hashed and cached locally, such as jQuery files and fonts. I don't know why we have to load it every time from the web, it's the same library for a large number of sites. Just add a hash tag in the <script> to make sure it's the same file.
    - manarth 10y ago
      When JQuery is served by the official CDN, it's given a cache-header giving it a lifespan of 10 years.
jakeogh 10y ago
The web is way better without JS. Rendering engines could in principal do the same (improved) dependency tracking.
kvz 10y ago
I feel Webpack deserves a mention as it resolves the dependencies at build-time and compiles one (or a few chunked/entrybased) assets, hence also solving the problem of too many roundtrips
mikeytown2 10y ago
From my experience preconnect is a big improvement for connecting to 3rd party domains. Will also mention that once you have JS deferred, CSS on a 3rd party domain (google fonts) can cause some major slowdowns in terms of the start rendering metrics if using HTTP/2 on a slow connection; all the bandwidth is used for the primary domain connection and not used for blocking resources, end result being images get downloaded before external blocking CSS.
GrumpyNl 10y ago
Talk to some people in the porn industry. They will tell you how important fast pages are. You will also be surprised what they have done to achieve this.
- sanxiyn 10y ago
  This sounds potentially interesting. Care to elaborate?
WhiteSource1 10y ago
What are you looking to learn about a CDN? There are many ways to accelerate page speed and, like everything else, it's a question of costs and benefits. For most things, some level of technical debt is OK and CDNs even for jQuery are good. Of course, good design and setting things up right is always the best - and the other question is where your site traffic comes from.

177 points by qwename 10y ago

Relevant paper: "Polaris: Faster Page Loads Using Fine-grained Dependency Tracking", http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf

naasking 10y ago
Argh, don't people Google names before using them? Polaris was HP's virus-safe Windows project: http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html
- Ar-Curunir 10y ago
  So... completely unrelated to this project's aim?
- manarth 10y ago
  The quintessential hardest problem in IT: naming things. Polaris is also a missile. And a star. And a PowerPC port of Solaris. We're always going to have name duplication. At least it's fairly easy to disambiguate with a Google search.

tyingq 10y ago

Interesting. The paper was released before HTTP/2 was in widespread use. They do show that their approach has significant improvements over SPDY alone...I wonder how the comparison to HTTP/2 alone would fare.

k_lander 10y ago
is there significant difference in performance between HTTP/2 and SPDY?
- tyingq 10y ago
  There seems to be, yes. Surprisingly little information to be had though. http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/ http://blog.httpwatch.com/2015/01/16/a-simple-performance-co... I don't think server push was used in this benchmark, it's arguably a poor mans way to achieve part of what's discussed in the referenced paper (serving early dependencies...early).
vitus 10y ago
Personally, I'm more curious to see the comparison with QUIC, which eliminates the RTTs to set up TCP + TLS, and multiplexes connections in a way that doesn't lead to the head-of-line blocking problem that you can see with HTTP/2 over TCP -- QUIC uses UDP, so no requirement for in-order delivery across the entire connection, just within each resource flow (in this context, each request). On that note, I do think it's a bit inaccurate to say that Google's efforts are/were primarily focused on data compression -- yes, they did introduce brotli, which is just a better LZ77 implementation (primary difference with gzip is that window size isn't a fixed 32KB), but they also pioneered SPDY (which turned into HTTP/2 after going through the standards committee) and now QUIC. (obligatory disclaimer that google gives me money, so I am biased)
- tyingq 10y ago
  Wouldn't it be difficult to do a straight comparison without other variables, given that there isn't a popular webserver that supports the protocols they tested with, as well as QUIC? Edit: Should note that I'm excited about QUIC as well, just thought I may have been missing some new development where it's (already) more usable outside Google's walls.
  - vitus 10y ago
    It is, but that doesn't change the fact that I'm still more curious on that front. The wiki page has a few sample servers [0], but again, those don't meet your criterion of popular. I realize that the initial RTT reduction isn't so relevant in the context of large dependency graphs, but especially in the context of packet loss, the proper multiplexing across flows seems useful. There are also a number of other QUIC-based features that might be relevant, since it does essentially reimplement the relevant parts of the TCP stack, so parameter choices might be better suited to today's internet (as opposed to 1980's). [0] https://en.wikipedia.org/wiki/QUIC#Server_support https://en.wikipedia.org/wiki/QUIC#Server_support
breischl 10y ago
Aren't they orthogonal? No matter how fast HTTP/2 is or how much it decreases connection setup times, requesting resources in the "right" order will always be faster than doing it in one of the "wrong" orders. More efficient protocols might reduce the disparity, but there should always be one. Right?
- bastawhiz 10y ago
  Server push in HTTP/2 can force files to load in the right order.
- tyingq 10y ago
  Yes, it would always be faster, assuming relatively heavy pages. But the reduced number of requests, hpack compression, and server push features in HTTP/2 might reduce the performance improvement to something less impressive. Given that Polaris has some downsides, it might reduce it to the point that you wouldn't consider it. In it's current state, Polaris requires a lot of pre-work...including dependency analysis via a real browser. It also serves up pages that wouldn't work with javascript disabled, and might not be terribly search engine friendly.

Thiez 10y ago

> What Polaris does is automatically track all of the interactions between objects, which can number in the thousands for a single page. For example, it notes when one object reads the data in another object, or updates a value in another object. It then uses its detailed log of these interactions to create a “dependency graph” for the page. > Mickens offers the analogy of a travelling businessperson. When you visit one city, you sometimes discover more cities you have to visit before going home. If someone gave you the entire list of cities ahead of time, you could plan the fastest possible route. Without the list, though, you have to discover new cities as you go, which results in unnecessary zig-zagging between far-away cities. What a terrible analogy. Finding a topological sorting is O(|V|+|E|), while the traveling salesman problem is NP-complete.

to3m 10y ago
That's amusing, and I wonder if this particular analogy was chosen deliberately. But I don't think there's anything wrong with it - it's designed to make intuitive sense to non-programming readers, not to be some rigorous description that can be automatically translated into optimal code.
- Thiez 10y ago
  Perhaps a different analogy would be better, e.g. ordering materials when building a house. If you can only order one material at a time, you would probably want to order the concrete for laying the foundation before ordering the roof tiles. Loading website resources is a lot like that (at least compared to the travelling salesman).
  - saurik 10y ago
    This still smells NP Hard. I mean, in practice for simple dependencies it is probably quite tractable, but this is a combinatorial optimization problem that seems pretty similar to an online modification to Job Shop Scheduling, where the material requirements map loosely to machine-task pairings that would be unblocked by orders, acting to make the problem more complex, not easier.

tedunangst 10y ago

So, uh, what does it do? I mean, I can't even tell if it's a server or client side change.

naor2013 10y ago
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.
tyingq 10y ago
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 [1]http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf
- manmal 10y ago
  That sounds like a fun idea for a precompiler.

uaaa 10y ago

Is there a comparison with Google AMP?

andrewguenther 10y ago
Paper was released way before AMP. Also not really related to AMP, so I don't think it's necessary to draw a comparison.

leeoniya 10y ago

but we can already make web pages load 500% faster by not shoveling a ton of shit, not loading scripts from 60 third-party domains (yes stop using CDNs for jQuery/js libs, those https connections aren't free - they're much more expensive than just serving the same script from your existing connection), reducing total requests to < 10, not serving 700kb hero images, 1.22MB embedded youtube players [1], 500kb of other js bloat, 200kb of webfonts, 150kb of boostrap css :/ the internet is faster than ever, browsers/javascript is faster than ever, cross-browser compat is better than ever, computers & servers are faster than ever, yet websites are slower than ever. i literally cannot consume the internet without uMatrix & uBlock Origin. and even with these i have to often give up my privacy by selectively allowing a bunch of required shit from third-party CDNs. no website/SPA should take > 2s on a fast connection, (or > 4s on 3g) to be fully loaded. it's downright embarrassing. we can and must do better. we have everything we need today. [1] https://s.ytimg.com/yts/jsbin/player-en_US-vfljAVcXG/base.js https://s.ytimg.com/yts/jsbin/player-en_US-vfljAVcXG/base.js

deleted 10y ago
[deleted]
kup0 10y ago
Yeah the problem really isn't the technology, it's our poor use of it.
- visarga 10y ago
  Some files could be hashed and cached locally, such as jQuery files and fonts. I don't know why we have to load it every time from the web, it's the same library for a large number of sites. Just add a hash tag in the <script> to make sure it's the same file.
  - manarth 10y ago
    When JQuery is served by the official CDN, it's given a cache-header giving it a lifespan of 10 years.

jakeogh 10y ago

The web is way better without JS. Rendering engines could in principal do the same (improved) dependency tracking.

kvz 10y ago

I feel Webpack deserves a mention as it resolves the dependencies at build-time and compiles one (or a few chunked/entrybased) assets, hence also solving the problem of too many roundtrips

mikeytown2 10y ago

From my experience preconnect is a big improvement for connecting to 3rd party domains. Will also mention that once you have JS deferred, CSS on a 3rd party domain (google fonts) can cause some major slowdowns in terms of the start rendering metrics if using HTTP/2 on a slow connection; all the bandwidth is used for the primary domain connection and not used for blocking resources, end result being images get downloaded before external blocking CSS.

GrumpyNl 10y ago

Talk to some people in the porn industry. They will tell you how important fast pages are. You will also be surprised what they have done to achieve this.

sanxiyn 10y ago
This sounds potentially interesting. Care to elaborate?

WhiteSource1 10y ago

What are you looking to learn about a CDN? There are many ways to accelerate page speed and, like everything else, it's a question of costs and benefits. For most things, some level of technical debt is OK and CDNs even for jQuery are good. Of course, good design and setting things up right is always the best - and the other question is where your site traffic comes from.