Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.mit.edu

Post reply on HN
Print view View original

61–70 of 105 posts

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

#61

Post by zeveb »

leeoniya wrote: post #19

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 1.22MB embedded youtube players [1], 500kb of other js bloat, 200kb of webfonts, 150kb of…

This, this, a thousand times this.

There's a site I read, really like and financially support, but which has some pretty terrible slowness & UI issues. It's so bad that they've started a campaign recently to fix those issues. But when I check Privacy Badger, NoScript and uBlock, there's a reason that it's so terrible slow: they're loading huge amounts of JavaScript and what can only be called cruft.

Honestly, I think that they'd come out ahead of the game if they'd just serve static pages and have a fundraising drive semi-annually.

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

#62

Post by manarth »

icebraining wrote: post #55
yellowbeard wrote: post #34

Earlier quoted context omitted.

The server is taking a long time to render the response. In the first link, 650ms or so. Open the network tab in your browser developer tools to see the details.

Slashdot's solution to this was to render the HTML on write, instead of on read. Whenever someone posted a new commend, a static HTML file would get generated, so that it could be rapidly served to readers. Movable Type works (can work?) much in the same way, though for blogs. I know that caching achieves a similar result and is an accepted component of a modern architecture, but I wonder if we wouldn't be better ser…

  Whenever someone posted a new commend, a static HTML file would get generated
It's essentially still a cache, with the same concerns/issues - mainly cache invalidation - as a HTTP cache.

An on-disk cache of that sort has other issues though. For example, what if a request is received whilst the file is being written? Does the system deliver a half-written HTML page? You can introduce locking or atomic file operations (write to a temporary directory, then mv the file into the correct location: mv is an atomic operation), but this adds more complexity to the cache logic.

One of the benefits of a HTTP cache is that they generally have a default graceful failure mode: if the cached data doesn't exist, request it from the backend application server.

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

#63

Post by leeoniya »

roryisok wrote: post #60
leeoniya wrote: post #19

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 1.22MB embedded youtube players [1], 500kb of other js bloat, 200kb of webfonts, 150kb of…

> literally cannot consume the internet without uMatrix & uBlock Origin hear hear. and on mobile, its painful because I can't have those (windows phone at least). planning on buying a DD-WRT compatible router soon so I can do some kind of router level ad-blocking and let me browse on the phone again PS: opera mobile for android has a built in adblocker

yep, i use opera mobile and also am rooted so use a hostfile blocker (AdAway).

uBlock Origin exists for Firefox Mobile btw, but i prefer opera's speed/ui.

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

#64

Post by amelius »

leeoniya wrote: post #19

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 1.22MB embedded youtube players [1], 500kb of other js bloat, 200kb of webfonts, 150kb of…

Actually I don't even read the articles anymore when on mobile. I just use HN, and hope somebody posts a TL;DR, or some relevant comment that gives some more information about the article. Only if this is not the case will I consider clicking on the article link. It's pretty sad actually.

I secretly wish there was some way that allows us (as a community) to collaboratively "pirate" articles, perhaps as a torrent (IPFS perhaps), so we only have to download the ascii text.

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

#65

Post by manarth »

naasking wrote: post #22
qwename wrote: post #2

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

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

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.

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

#66

Post by Thiez »

saurik wrote: post #11
Thiez wrote: post #9

Earlier quoted context omitted.

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).

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.

Your sense of smell is off. Assuming a directed acyclic graph (the usual shape of a dependency tree), assume we write the result order to a list L. Walk over all vertices once, create a mapping M of each vertex to its number of incoming edges, and add all vertices without incoming edges to a list R. This is O(|V| + |E|). Now, pick the first item of R and append it to L. For each outgoing edge in the item we chose, decrement the associated count of its receiving vertex in M by 1. For each item where the count becomes 0, append it to R. Keep running until R is empty, and you're done. This second part of the process is again O(|V| + |E|).

We're done and found a topological order in O(|V| + |E|).

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

#67

Post by manarth »

visarga wrote: post #24
kup0 wrote: post #21

Earlier quoted context omitted.

Yeah the problem really isn't the technology, it's our poor use of it.

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 to make sure it's the same file.

When JQuery is served by the official CDN, it's given a cache-header giving it a lifespan of 10 years.

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

#68

Post by leeoniya »

manarth wrote: post #67
visarga wrote: post #24

Earlier quoted context omitted.

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 to make sure it's the same file.

When JQuery is served by the official CDN, it's given a cache-header giving it a lifespan of 10 years.

the bandwidth isnt the problem.

your browser still has to make the https connection to the cdn and request the file with a Last-Modified or Etag header so the server can return a 304 Not Modified response. This is the real cost, not the download size itself.

I'm not sure how often browsers choose to do this, but if you refresh a page, they all will.

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

#69

Post by pjmlp »

leeoniya wrote: post #19

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 1.22MB embedded youtube players [1], 500kb of other js bloat, 200kb of webfonts, 150kb of…

The browsers should have stayed HTML/CSS but then someone had this idea to try to compete with native applications....

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

#70

Post by leeoniya »

pjmlp wrote: post #69
leeoniya wrote: post #19

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 1.22MB embedded youtube players [1], 500kb of other js bloat, 200kb of webfonts, 150kb of…

The browsers should have stayed HTML/CSS but then someone had this idea to try to compete with native applications....

but they can compete when written properly, at least for business/productivity apps.

though not for anything requiring direct hardware access, AAA games included.

Post reply on HN