Hacker News Reader

Comment by cm2187 | Hacker News Reader

This is why browsers should have an option "Block third party javascript" similar to "Block third party cookies".

With http2, relevant javascript files will be increasingly hosted on the same domain anyway and that option would become increasingly relevant.

View on HN

You can setup a Content Security Policy in your web server that will only allow the browser to load scripts from some domains/subdomains.

NoScript can do that. Just enable the "Temporarily allow top-level sites by default" setting.

I see the need, but fear that if this became a common thing, you'd end up with websites proxying external scripts through their own domain.

I am not that sure of that. Advertisers need to see the connections going through their servers, otherwise they are exposed to massive fraud from the websites they advertise on. So proxy-ing their script might not suit them at all.

So let's do the opposite! Just point our DNS at the ad networks and have them reverse proxy our content! It's genius!

(You just know it's gonna happen one day under the guise of a free CDN)

Like Cloudflare does, haha :)

    With http2, relevant javascript files will be
    increasingly hosted on the same domain

Why is that?

There's a limit on the number of simultaneous requests per domain with http1, which will not be present in http2 [0]. This limit meant that for best performance, static files should be served from multiple (sub)domains.

[0] https://mattwilcox.net/web-development/http2-for-front-end-w...

The way this is phrased sounds backwards to what you actually mean.

HTTP/2.0 supports _single connection multiplexing_, which means that domain sharding (splitting into different domains) is a _bad practice_.

You're both right. There's two separate (but related issues) here.

Blocking third party JS does not help me offload the libraries to a CDN (ex. cdnjs.com) to save server bandwidth.

Is server bandwidth a problem, though?

It's 2015, though, not 1996. If you seriously can't afford to send your visitor a few-dozen-kilobyte file once in a blue moon (because you do have far-future expire dates, right?), you've got bigger problems than CDN'ing your jQuery is going to solve.

If you're serving megabytes of JS such that that is enough to matter... no, it's still true, if that's not sustainable you've got bigger problems than a CDN is going to solve. Even on very JS-heavy sites, the amount of your bandwidth taken up by JS shouldn't be that large on a properly-configured site. (Yes, I can construct some rare exceptions... you've got a demo site for WebGL and your average viewer hits you once with no cache, grabs megabytes of JS and textures, then moves on never to return. But they are rare, even if you can construct them in your head.)

Reply on news.ycombinator.com