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

91–100 of 105 posts

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

#91

Post by roryisok »

nattmat wrote: post #78
roryisok wrote: post #60

Earlier quoted context omitted.

> 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

A Raspberry Pi running Pi-Hole is what you want. https://pi-hole.net/

Ok, that's even better. I can get a pi for less than a new router, build my own case. If only my router had a usb port, I could even power it off that

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

#92

Post by manarth »

leeoniya wrote: post #68
manarth wrote: post #67

Earlier quoted context omitted.

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.

In general, browsers shouldn't even revalidate the file as long as it's younger than the max-age lifespan.

They may choose to "evict" it from the cache, but that's generally based on a policy of recent usage and needing to free up/prioritise disk space for more recent assets.

I'm now interested to see how different browsers handle refresh/force-refresh - whether they revalidate a file that's still considered fresh, and whether they set request-headers to bypass upstream caches too. Maybe an experiment for the xmas holidays :-)

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

#93

Post by bastawhiz »

breischl wrote: post #89
tyingq wrote: post #3

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.

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?

Server push in HTTP/2 can force files to load in the right order.

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

#94

Post by renke1 »

leeoniya wrote: post #68
manarth wrote: post #67

Earlier quoted context omitted.

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.

There is also Cache-Control: immutable [1] which prevents browsers requesting the given file even when the site is refreshed. It's experimental though.

[1]: http://bitsup.blogspot.de/2016/05/cache-control-immutable.ht...

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

#95

Post by manarth »

renke1 wrote: post #94
leeoniya wrote: post #68

Earlier quoted context omitted.

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.

There is also Cache-Control: immutable [1] which prevents browsers requesting the given file even when the site is refreshed. It's experimental though. [1]: http://bitsup.blogspot.de/2016/05/cache-control-immutable.ht...

Currently only supported by Firefox (as of 49.0), according to Mozilla [1].

Interestingly, it's being used by the BBC [2], who have reported a 10.8% reduction in 304 responses as a result [3]. Google have also stated their intention to use it (comment 11 in the same Chromium ticket).

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...

[2] https://mybbc.files.bbci.co.uk/notification-ui/2.6.8-mvt//sv...

[3] https://bugs.chromium.org/p/chromium/issues/detail?id=611416

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

#96

Post by renke1 »

manarth wrote: post #95
renke1 wrote: post #94

Earlier quoted context omitted.

There is also Cache-Control: immutable [1] which prevents browsers requesting the given file even when the site is refreshed. It's experimental though. [1]: http://bitsup.blogspot.de/2016/05/cache-control-immutable.ht...

Currently only supported by Firefox (as of 49.0), according to Mozilla [1]. Interestingly, it's being used by the BBC [2], who have reported a 10.8% reduction in 304 responses as a result [3]. Google have also stated their intention to use it (comment 11 in the same Chromium ticket). [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca... [2] https://mybbc.files.bbci.co.uk/notification-ui/2.6.8-mvt//sv...…

Another alternative would be service workers, which are (partially) supported by Chrome and Firefox according to [1]

[1]: http://caniuse.com/#feat=serviceworkers

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

#97

Post by jasonkostempski »

leeoniya wrote: post #75
jasonkostempski wrote: post #73

Earlier quoted context omitted.

I sort of agree, i just think JS and content from other domains should have required user prompts.

and https by default should have never allowed off-domain or insecure/mixed content.

We can dream but, even if it had been that way, I suspect it would have taken just one bad browser (probably IE) to ruin it for everyone. They'd advertise it as "no annoying prompts", everyone would flock to it and other browsers would have to follow.

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

#98

Post by tyingq »

breischl wrote: post #89
tyingq wrote: post #3

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.

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?

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.

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

#99

Post by tyingq »

dchest wrote: post #58
andrewguenther wrote: post #33

Earlier quoted context omitted.

jQuery was a poor example in the original comment. You almost 100% have jQuery cached if you're getting it from CDN. But this only works for extremely widely used libraries (jQuery, Bootstrap, etc.). It drives me nuts when I see tiny little libraries in Github bragging about being on a CDN. They just don't have the usage for it to be efficient.

Which of the following versions are cached? 3.1.1, 3.1.0, 3.0.0, 2.2.4, 2.2.3, 2.2.2, 2.2.1, 2.2.0, 2.1.4, 2.1.3, 2.1.1, 2.1.0, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 1.12.4, 1.12.3, 1.12.2, 1.12.1, 1.12.0, 1.11.3, 1.11.2, 1.11.1, 1.11.0, 1.10.2, 1.10.1, 1.10.0, 1.9.1, 1.9.0, 1.8.3, 1.8.2, 1.8.1, 1.8.0, 1.7.2, 1.7.1, 1.7.0, 1.6.4, 1.6.3, 1.6.2, 1.6.1, 1.6.0, 1.5.2, 1.5.1, 1.5.0, 1.4.4, 1.4.3, 1.4.2, 1.4.1, 1.4.0, 1.3.2, 1.3.1,…

And over which protocol (http/https cached separately)....

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

#100

Post by endless1234 »

pjmlp wrote: post #87
endless1234 wrote: post #84

Earlier quoted context omitted.

>but then someone had this idea to try to compete with native applications You say as if that's a bad thing. Just wondering, for instance, do you use some standalone maps software instead of Google/Bing/Openstreet/... maps?

Ever heard of GPS devices, mobile phones or tablets? I always use native software on my own computers, unless I don't have another option and have to go the web app instead. Same applies to projects I work on, if I am allowed to choose.

No, I have not heard of GPS devices, mobile phones or tablets. Thank you for introducing me!
Post reply on HN