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

81–90 of 105 posts

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

#81

Post by icebraining »

manarth wrote: post #62
icebraining wrote: post #55

Earlier quoted context omitted.

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…

The issue doesn't seem any different - assuming you have concurrent requests, you also have to make sure the cache doesn't return a result until the whole document is written to it.

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

#82

Post by supergreg »

leeoniya wrote: post #30
chrisfosterelli wrote: post #29

Earlier quoted context omitted.

> 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 Do you have a source for this? My understanding is that, in real usage, it is cheaper to load common libraries from a CDN because in a public CDN (for something like jQuery), the library is likely to already be cached from another website and has a cha…

this has been true in my own testing (with plain SSL/TLS, not even SPDY/HTTP2/QUIC), but you can read another analysis that reaches the same conclusion here: https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-... another important reason i personally don't use CDNs is the privacy of my users.

>another important reason i personally don't use CDNs is the privacy of my users.

How high up the privacy concern is using a CDN vs having cloudflare in front of you or everything being in AWS or using a browser by an ad company?

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

#83

Post by jaclaz »

keypress wrote: post #53
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…

Back in the day we'd try and get page sizes down to less than 100k. The Internet isn't fast for everyone. I (in the UK) have no 3G signal, let alone 4G and my broadband speed is pitiful - but it will do. There is nothing I can do to ramp the pipe speed up. I do end up turning off JS and images a lot of the time, because otherwise it ills me. As a web dev, I don't care for bloat. So I find it particularly irksome, and…

An IMHO interesting unit of measure is the DOOM(s), JFYI:

https://twitter.com/xbs/status/626781529054834688

As in "my site homepage is less than 1 Doom" or "that crappy site is more than 3 Dooms" ...

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

#84

Post by endless1234 »

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 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?

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

#85

Post by jimlawruk »

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 use of CDNs is not primarily for speeding up page load times, but rather to offload bandwidth from the web server. Low budget Web sites don't always have money for server farms and are severely limited by how much bandwidth they can serve. One post to HN can take them down. Free CDNs are the poor man's approach to this problem.

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

#86

Post by acdha »

amelius wrote: post #64
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 (IPF…

I use Brave as my primary mobile browser because it allows me to have JavaScript disabled but trivially enable it when I need it. The experience is massively better – on LTE the average page load is under a second except maybe for a video or lots of images, and you avoid all of the user-hostile pop-ups, app nags, etc.

(I subscribe to most of the sites which I read regularly so I don't feel guilty about blocking ads but I really hope someone successfully makes a Google Contributor-style network where a trusted browser serves only static image/text ads, as much resistance as that will trigger)

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

#87

Post by pjmlp »

endless1234 wrote: post #84
pjmlp wrote: post #69

Earlier quoted context omitted.

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

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

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

#88

Post by manarth »

icebraining wrote: post #81
manarth wrote: post #62

Earlier quoted context omitted.

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…

The issue doesn't seem any different - assuming you have concurrent requests, you also have to make sure the cache doesn't return a result until the whole document is written to it.

That's a fair point - I didn't consider that issue, because using a standard HTTP cache, that's taken care of.

It's just become somebody else's problem (the developers of the HTTP cache), but it's fair to say it's still an issue to solve.

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

#89

Post by breischl »

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?

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

#90

Post by neurostimulant »

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

Or just configure your router to use an ad blocking DNS (host your own or use one of those public DNS servers). Works with any router as long as it allows you to edit the default DNS config. This helps a lot when browsing on home wifi connection. Too bad you can't edit DNS config on mobile device without rooting/jailbreaking.
Post reply on HN