7 ms·

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

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

leeoniya 10y ago
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-ssl/ 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 10y ago
  >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 10y ago
    > 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 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 10y ago
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 10y ago
  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://developers.google.com/speed/libraries/ - https://code.jquery.com/ https://code.jquery.com/ - https://cdnjs.com/ https://cdnjs.com/ - https://www.asp.net/ajax/cdn https://www.asp.net/ajax/cdn - ...
  - tyingq 10y ago
    And over which protocol (http/https cached separately)....
bartread 10y ago
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 10y ago
  > ... 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.
  - leeoniya 10y ago
    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..)
lukaszkups 10y ago
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 10y ago
  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 10y ago
    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.
inian 10y ago
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.
pluma 10y ago
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).

leeoniya 10y ago

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-ssl/ 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 10y ago
>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 10y ago
  > 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 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 10y ago

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 10y ago
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://developers.google.com/speed/libraries/ - https://code.jquery.com/ https://code.jquery.com/ - https://cdnjs.com/ https://cdnjs.com/ - https://www.asp.net/ajax/cdn https://www.asp.net/ajax/cdn - ...
- tyingq 10y ago
  And over which protocol (http/https cached separately)....

bartread 10y ago

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 10y ago
> ... 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.
- leeoniya 10y ago
  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..)

lukaszkups 10y ago

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 10y ago
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 10y ago
  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.

inian 10y ago

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.

pluma 10y ago

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