Hacker News new | ask | show | jobs
by bcherny 3198 days ago
2 reasons:

1. If you're still using HTTP 1.x, sharding assets across origins lets the browser load them in parallel (if set up correctly). You can generally load just 6 assets in parallel per origin, and sharding is a way to get around that limit.

2. A library like jQuery is so popular, and is so often served from googles CDN, that chances are a user already has it in their local cache from when they downloaded it on some other site.

That said, yes - the downside is more surface area that might go down.

4 comments

2. A library like jQuery is so popular, and is so often served from googles CDN, that chances are a user already has it in their local cache from when they downloaded it on some other site.

Which of these versions do you have cached?

3.2.1, 3.2.0, 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, 1.3.0, 1.2.6, 1.2.3

Asking an annoyed rhetorical question doesn't seem productive to the point you're trying to make here.

As an actual answer, it would be variable proportional to the size of the window between releases mentioned here: https://en.wikipedia.org/wiki/JQuery#Release_history

I'm sure a fair amount of people serve jQuery from a local storage. The usefulness that the user might already have it cached is a non-zero point, no matter how insignificant you may think it is.

Just two versions of jQuery, 1.12 and 1.11, represent approximately half of all jQuery versions in use. The top four most common versions (1.12, 1.11, 1.7, 1.8) represent close to 3/4 of all versions of jQuery in use. Version 3.x and 2.x are hardly being used by comparison to those.

That narrows your suggested problem down dramatically.

How many do you need to make this worthwhile?

The ratio of cost of storing a library versus the cost of GETing a library is very low, so the chances of already having a library cached can be very low for the EV to be worthwhile.

Weighing that against the chance of downtime is a bit more complicated, admittedly.

Looking at just minified versions from googleapis.com, I have 1.12.4, 2.2.4, 1.8.2, 1.10.2, 1.8.1, 1.9.1, and 2.1.1
> You can generally load just 6 assets in parallel per origin

This seems to only apply to Chrome, whereas Firefox will happily download everything as fast as possible.

I know this because I fixed a bug recently where chrome was taking so long to download images that other resources on the page were timing out. No problem in Firefox.

Last I checked all the browsers had limits [1] when it came to HTTP 1.X.

[1] http://blog.olamisan.com/max-parallel-http-connections-in-a-...

The limits in Firefox must be really high then, it was almost funny looking at the difference in behaviour between the two browsers in the situation I was testing.
3. Now 1/3 of pages I'm visiting I need to make request to google because someone wanted to use a 5 lines of JS from jQuery.
> If you're still using HTTP 1.x

Not sure why it was phrased that way but...isn't everybody?

I know that HTTP/2 is released and browsers support it, but I'm fairly certain that next to nobody is actually doing anything with it.

Google, FB, Youtube, Wikipedia, and HN :) use HTTP2.

I also use HTTP2 at work, and on every personal project. It's supported by every browser [1], and comes with a slew of benefits. It's usually trivial to set up, if you want to give it a shot.

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

It's getting rolled out in a lot of places. I think adoption is somewhere around 17% depending on how it's measured. I started using it for my personal website and it was really easy, the only part I missed was setting a cron job to reconfigure the web server whenever cert renewal went through.