[chrisfosterelli]

> 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 chance to even already have an SSL connection to the CDN.

Obviously 60 separate CDNs is excessive, but I don't know if the practice altogether is a bad idea.

[bartread]

Using a CDN for common libraries may help, but doesn't always, and is something you should measure rather than just assume. The situation where a CDN actually hurts performance is one I've seen periodically at different clients.

When people talk about serving jQuery, or J. Random JavaScript library, from a CDN it means the specific version of jQuery (or whatever) that they're using. There's literally no guarantee that the specific version you need will be in any given user's browser cache, and this is exacerbated if you loading multiple libraries from a CDN, or from different CDNs. If your CDNs serve files with low latency then it may not be a big problem, but not all CDNs do. Slow responding CDNs will slow your page loads down, not the reverse.

Moreover, if you're serving over HTTP2/SPDY there's even less likely to be a benefit to using a CDN. Again, it's something you need to measure.

One area where a CDN (e.g., Cloudflare) can benefit you is by serving all your static content to offer users a low-latency experience regardless of where they are in the world, but that's rather a different matter from serving half a dozen libraries from half a dozen different CDNs.

[richmarr]

> ... something you should measure rather than just assume

How do people do this?

My obstacle with this point is each CDN would have a different impact in each locale due to the locations of their points of presence, and CDN-ing each resource would a different impact based on the sites that particuar individual had visited.

Measuring it in any useful way in advance of a change would be really hard unless I'm missing a trick, and measuring it in hindsight would require the kind of performance logging that PaaS-level apps don't have access to.

[tombrossman]

This would be extremely useful data to have and when I last looked I found little to go on. For example, how great would it be to have an extra column on a page like this with cache hit rates? https://cdnjs.com/libraries

Nice to have these free hosted assets, but I suspect that a lot of these are an additional download and not actually cached by the majority of visitors. Just having a rough estimate would be helpful when choosing whether to directly serve an asset or use a CDN.

[leeoniya]

my recommendation is to first serve everything yourself over TLS (minified, bundled, gzipped). if you can, run HTTP2. then measure.

if this does not deliver the perf you expect (chances are that it will), then look into CDNs.

if you need to serve media that needs a lot of bandwidth (expensive) then look into CDNs.

if you need some form of real-time comm like WebSockets or WebRTC that actually requires low latency, look into distributed systems (amazon, google, azure, cloudflare?, etc..)

[richmarr]

Sure, my question was how people measure.

[leeoniya]

your best bet is https://developer.mozilla.org/en-US/docs/Web/API/Performance

combined with either IP2location or Geolocation apis.

[Eridrus]

You can use JavaScript timers to measure how long things take to load and infer how many of the resources come from cache, etc.

[pluma]

In theory public CDNs are the solution. In practice it only works if a critical mass of websites use them.

As others have pointed out, the version matters. There are a gazillion different versions of jQuery out there and many websites are very slow to update them if ever. So you only benefit by visiting multiple sites that use exactly the same version.

Additionally there is a ton of different public CDNs. Now, jQuery itself has solved this by providing an official jQuery CDN and pushing it to developers. In fact, the first result for "jQuery CDN" is their own website.

I'd say jQuery is probably the least bad example of this. If you visit enough websites there's a non-zero chance you'll have a CDN cache hit for jQuery on a few of them.

The problem is that jQuery rarely comes alone. Even jQuery UI is less widely deployed than jQuery and thus less likely to be cached from a CDN. But once you get into plugin territory or third-party libraries all bets are off.

I'm fairly certain that jQuery is the only library that has some realistic chance of benefiting from a public CDN. Everything else is probably asking for trouble (if only because you're adding unnecessary single points of failure).

[inian]

Also, the cache size on mobile devices especially on iOS is ridiculously low. I don't see my cache storage exceed more than 10 MB even though I use my browser a lot. High chance that you are _not_ going to find your common CDN libraries there.

[lukaszkups]

I'm a webdev. I had to speed up web e-mail client, written in angular.js. Besides splitting huge request into couple smaller, async ones (huuge speed improvement) I've also switched downloading files from CDN to app server itself - that gives additional 4sec (sic!) shorter load time.

[pedalpete]

Can you explain how you achieved the 4 second difference using the webserver over the CDN? That seems orders of magnitude faster than I would have expected. I thought you would have been looking at 100ms one way or the other.

[radicalbyte]

At my current client I'm pretty sure that they've got a Raspberry Pi 1 as a proxy server. So all request to outside their network are horribly slow.

[leeoniya]

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.

[supergreg]

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

[leeoniya]

> having cloudflare in front of you or everything being in AWS

sure, sometimes it's unavoidable when there is real value added in using these platforms. at the end of the day most of us have to entrust our infrastructure to some hosting provider. I trust a provider I pay (with a known privacy policy) more than a public CDN (with a privacy policy that allows them to make money in unspecified ways)

but yes, centralized ssl termination for distributed systems is an issue that's difficult to mitigate WRT privacy. maybe via https://en.wikipedia.org/wiki/Multipath_TCP ? i don't know enough here.

> using a browser by an ad company

this is up to the user

[andrewguenther]

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.

[dchest]

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

from which of the following providers:

- https://developers.google.com/speed/libraries/

- https://code.jquery.com/

- https://cdnjs.com/

- https://www.asp.net/ajax/cdn

- ...

[tyingq]

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