3 ms·

On the other hand, the URL for a common library hosted on cdnjs (or one of the other big JavaScript CDNs) and included on many different websites is much more

by thorum 6y ago

On the other hand, the URL for a common library hosted on cdnjs (or one of the other big JavaScript CDNs) and included on many different websites is much more likely to already be cached on edge servers close to your users than if you host the file yourself.

arghwhat 6y ago
The time to connect to the CDN hostname will negate any benefit, especially if push can be used.
Matthias247 6y ago
You can mitigate this by getting your website itself on a CDN. If this is cached, then it's assets (incl javascript), would be too. And by going that route you make sure that all pieces of your website have the same availability guarantees, the same performance profile, and the same security guarantees that the content was not manipulated by a 3rd party.
- GeneralTspoon 6y ago
  > And by going that route you make sure that all pieces of your website have the same availability guarantees, the same performance profile, and the same security guarantees that the content was not manipulated by a 3rd party. You can already guarantee the security of the file by using the integrity attribute on the <script> tag. And the performance of your CDN is probably worse than the Google CDN (not to mention that you lose out on the shared cache).
  - Matthias247 6y ago
    I agree on the security side if you use that attribute. However: > And the performance of your CDN is probably worse than the Google CDN What means probably? Other CDNs (Akamai, CloudFront, Cloudflare, etc) are also fast. And by pushing one piece of your website on a different CDN you force your users browser to create an additional HTTPS connection which takes additional round-trips, instead of being able to leverage one connection for all assets. This alone might as well outweigh the performance differences between CDNs. Also the "shared cache" benefit might go away, if I read the other answers in this topic correctly.

by thorum 6y ago

arghwhat 6y ago

The time to connect to the CDN hostname will negate any benefit, especially if push can be used.

Matthias247 6y ago

You can mitigate this by getting your website itself on a CDN. If this is cached, then it's assets (incl javascript), would be too. And by going that route you make sure that all pieces of your website have the same availability guarantees, the same performance profile, and the same security guarantees that the content was not manipulated by a 3rd party.

GeneralTspoon 6y ago
> And by going that route you make sure that all pieces of your website have the same availability guarantees, the same performance profile, and the same security guarantees that the content was not manipulated by a 3rd party. You can already guarantee the security of the file by using the integrity attribute on the <script> tag. And the performance of your CDN is probably worse than the Google CDN (not to mention that you lose out on the shared cache).
- Matthias247 6y ago
  I agree on the security side if you use that attribute. However: > And the performance of your CDN is probably worse than the Google CDN What means probably? Other CDNs (Akamai, CloudFront, Cloudflare, etc) are also fast. And by pushing one piece of your website on a different CDN you force your users browser to create an additional HTTPS connection which takes additional round-trips, instead of being able to leverage one connection for all assets. This alone might as well outweigh the performance differences between CDNs. Also the "shared cache" benefit might go away, if I read the other answers in this topic correctly.