[ocdtrekkie]

Is there a good reason to use these things hosted by a third party source? Libraries are tiny, the fonts can be downloaded from Google Fonts and embedded locally, etc. Even the Google Analytics JS script I presume can be stored and run local.

Shouldn't a goal be to mitigate the number of possible failures which can bring down your site by reducing the number of single points of failure?

[bcherny]

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.

[dchest]

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

[castis]

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.

[adventured]

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.

[kerkeslager]

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.

[nix0n]

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

[s_kilk]

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

[lamlam]

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

[s_kilk]

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.

[takeda]

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.

[hungerstrike]

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

[bcherny]

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

[klodolph]

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.

[wil421]

One reason is that by linking to external libraries your browser most likely has them cached. At least it was the case a few years ago when I was doing web dev.

[eric_b]

I see this argument a lot but I don't think it's necessarily a good one. If a third party CDN goes down, your site is down.

A few extra ms in initial download isn't so bad compared to having your site be completely inaccessible for reasons outside your control.

[matthberg]

When a CDN goes down, that is the time to use local backups. The best policy I've seen is using 3rd party CDNs for scripts like jQuery, ie. common, unchanging resources, yet with subresource integrity checks [0] to make sure it's actually what you are asking for (in case the site somehow gets compromised or returns an error). On top of that to cover for failure, you have a fallback locally hosted copy which is loaded only if the CDN version fails.

[0] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

[wil421]

Would those resource checks been done at the client or sever? For example the sever pings the CDN at a set interval and if it's down the sites code is modified to included links to local copies.

Or would you do something in the browser to fetch the local one in case of failure?

[omni]

Why doesn't having the resources cached provide a buffer against short-term outages of the CDN?

[hobofan]

Because normal Cache-Control is only aimed at reducing the amount of data transferred. With newer immutable Cache-Control[0], a CDN going down wouldn't have an effect if you have the resources cached.

[0]: https://hacks.mozilla.org/2017/01/using-immutable-caching-to...

[nleach]

The browser still has to make a request to the CDN to get back an HTTP 304. The goal is to avoid downloading a potentially large payload, not be resilient against connectivity issues.

[wil421]

Self hosting will probably cause more downtime than if you are using a decent CDN. CDN is just one of many points of failure, I would expect there's a fine balancing act where you could achieve benefits of both.

[dom0]

By definition, if your site is down, you don't need your assets.

[jlgaddis]

Then why are these sites down?

[Asmod4n]

This is most likely never the case, because there are way too many versions of each library.

[tregoning]

Yes, Google can change the logic for auth, analytics, etc at any time and your local outdated copy will be useless, further I believe it's possible that Google returns different JS depending on the browser that's requesting it in order to keep payloads down and performance high.

[jjlane]

Our GA is setup through GTM now, that is why it's not hardcoded into our head. Really the most important gain we get from hosted libraries is caching. Since any user that has hit a google hosted lib, which is pretty widely used and distributed it allows them to access their cached version instead of sending our another request.

[sbov]

IIRC Google Fonts aren't easy to download because they vary by user agent.

[vetinari]

You can download zip archive of ttfs using the customize tab on the fonts site. Or go directly to the source, and get the git repo.