jQuery CDN having SSL issues

Post by penagwin » Thu, Apr 19, 2018, 8:58 PM UTC

jakobdabo wrote: post #15

I always self-host my JS/CSS libraries: the connection is already open (thanks to keep-alive) so what's the problem of serving a couple of more KiBs of compressed data instead of making an additional DNS request and a new connection to a CDN? I understand that the CDN version of the library may have already been cached by the browser while visiting other websites, but does it really save that much time/traffic compar…

Post by manigandham » Thu, Apr 19, 2018, 9:02 PM UTC

penagwin wrote: post #22

jakobdabo wrote: post #15

I always self-host my JS/CSS libraries: the connection is already open (thanks to keep-alive) so what's the problem of serving a couple of more KiBs of compressed data instead of making an additional DNS request and a new connection to a CDN? I understand that the CDN version of the library may have already been cached by the browser while visiting other websites, but does it really save that much time/traffic compar…

I'm not taking a side, just trying to add some numbers. Let's ignore the privacy/uptime concerns for the sake of this comment. If every site you visit has 350kb of stuff that would benefit from a CDN JS but also some CSS and fonts (google fonts, bootstrap, etc.) If you visit 50 pages a day in a 30 day month, that's a little over 500mb of data. .35mb x 50sites x 30days = 525mb That would be a ton of easily avoidable d…

Post by 2trill2spill » Thu, Apr 19, 2018, 9:06 PM UTC

jakobdabo wrote: post #15

I always self-host my JS/CSS libraries: the connection is already open (thanks to keep-alive) so what's the problem of serving a couple of more KiBs of compressed data instead of making an additional DNS request and a new connection to a CDN? I understand that the CDN version of the library may have already been cached by the browser while visiting other websites, but does it really save that much time/traffic compar…

Post by 2trill2spill » Thu, Apr 19, 2018, 9:08 PM UTC

guessmyname wrote: post #25

2trill2spill wrote: post #23

Earlier quoted context omitted.

> Nowadays, with all the Node.js stuff that goes around modern front-end, I don't see the point of embedding a JavaScript library from a CDN, unless that library is dependent on a remote service, e.g. Google Analytics, Google Maps, etc… That being said, if you are still maintaining a legacy website that depends on jQuery, you should consider to embed the library like this instead: What does Node.js have to do with de…

> What does Node.js have to do with… There are tools like Grunt and WebPack (which depend on Node.js) that can bundle all your dependencies. I cannot provide details about how they work because I don't do front-end development, but I can tell you about years ago when I had to copy & paste both code and links to jQuery and other libraries like BackBone or Ember.js (relevant at the time) into my projects. Nowadays, web…

Post by robin_reala » Thu, Apr 19, 2018, 9:17 PM UTC

Someone1234 wrote: post #11

It is too bad that the HTML standard has no built in way to fallback. They've added a cryptographic hash/integrity and the async/defer attributes to the script tag, but something as essential as a fallback if a script or stylesheet fails to load (which the browser is best placed to know), has no built in functionality. Instead you're left doing JavaScript tricks which for missing CSS gets a little ugly[0]. But CDN wi…