Big deal.
I think a better sentiment is that you probably don't need jQuery. jQuery is a great library, but with the modern state of JS, you can probably get by without it and spend that 32kb on something else more useful.
You can get Preact, RxJS-lite and Immutable in total for about 40kb - is that going to be a better use of your performance budget?
1. Your visitor must have visited other sites using jQuery from a CDN.
2. One of those sites must have used the same CDN you're using.
3. The site must have used the exact same version you're using.
4. Depending on the CDN, the version must have been served from the same URL (e.g. a problem when CDNs allow specifying partial version numbers and sites differ between referencing the full version number or just a part of it, 1.8 vs 1.8.2).
And you're already doing things right, using HTTP/2 and everything, but your client hasn't visited a site before that uses your CDN and your version via your URL, now what? Your visitor's browser has to make another DNS lookup, open another connection to a different server, possible block your own scripts from executing because they depend on jQuery, and so forth.
But if you're doing it right and using HTTP/2 and everything and hosting jQuery yourself (or possibly even use a vendor bundle) there won't be any visitors who have already got your jQuery version cached but the browser can avoid the overhead of another DNS lookup and another connection and just tell the server to send jQuery along with everything else over the same socket.
Public CDNs have been of questionable value from the start[0] but with HTTP/2 this "if you're doing it right, you're loading your dependencies from a public CDN" meme needs to finally die.
[0]: AFAIK the argument that public CDNs are a performance gain for third-party dependencies (vs bundling and/or hosting them yourself) was never substantiated with any real-world data. I guess for jQuery things have improved a bit with jQuery providing an official CDN as the default option but this doesn't help with jQuery plugins or anything other than jQuery itself.
But on the other hand jQuery unlike MVC/virtualdom frameworks loads asynchronously and adds behaviour to static html ie it's non blocking.
- Each file downloaded adds latency. This especially hurts if you're on a satellite or similar, highly latent connection. The more files you have to download the worse start-up and various loading timing can get.
- Okay, so let's say you minified and combined everything to help avoid the first issue, now you have a new issue: all JavaScript needs to get executed when included. So adding 20kb worth of JavaScript, while not all of it is executed immediately, a chunk of it is. This adds to start-up time.
- Don't forget JavaScript execution, when compared to a desktop, is absolutely abysmal. For mobile web browsers you need to shave as much time off of start-up and ready states as possible.
Satellite in a bit of a red herring in terms of the point I wanted to convey.
I also spent about 3 years working on systems that had to work across satellite connections so I have a little bias as well :)
jQuery is also not doing a whole lot on startup, its functions get called when needed. Lodash is the same.
[1] http://httparchive.org/compare.php?&r1=Nov%2015%202010&s1=Al...
2.5MB is absolutely ridiculous. Regardless, you just created a straw-man. jQuery is, what, 26kb minified + gzipped? So you could also say that if website is 100kb then jQuery is 25% the size of your website.
Now 26kb is not much at all but small things add up very quickly. If you're not using it, don't include it. If you can write a tiny bit of extra code to avoid a dependency that isn't highly specialized (e.g. moment.js) it's usually a good idea on the web.
> If that means that some random satellite user has to wait 101s instead of 100
FYI satellite connection issues are more about latency than bandwidth. Adding an extra connection (if it's not concatenated) to fetch jQuery can easily add more than 1 second even though it's only 26kb. Also, I sure hope your app doesn't take 100 seconds to start-up :)