This assumes that both your and the the subsequent site's use either pulls an evergreen version (bad practice) or the exact same version (not altogether likely). Doing enough front-end performance auditing for potential clients, it's clear the latter case is as varied as can be.

We pulled everything in-house onto our own Cloudfront CDN and saved a bunch of time on DNS/TLS negotiation, as each unique third-party request is extremely expensive over middling 3G, on the order of nearly 1 second apiece according to WebPageTest. Leveraging 'preconnect' with that CDN saved just a bit more time on top of that.

That's fine for jQuery, Bootstrap etc, however most modern frameworks are bundled into a single package with all of the templates and logic, making a shared CDN useless.

It would be interesting to see some benchmarks of a cached CDN Angular file and non-cached template/logic file, however lots of other sites would have to jump on board to get the cached file into users' browsers reliably.

Historically that was a major security issue. It’s less of an issue now that SRI exists (you’re using SRI, right?), but it’s still a problem when you have a broken pathway to the CDN but your site loads OK. Well, assuming you’re not building with progressive enhancement. You’re building with progressive enhancement right?

sorry what is SRI ?

Subresource Integrity. It’s designed specifically for this scenario: a resource included into your page from a seperate server that could potentially be compromised. Your hash the known good resource and include that hash in your script or link tags as an integrity attribute. When the user’s browser downloads the resource it’ll hash it again and check for a match. Only if the two match will it parse and execute the contents.

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Don't ignore the time required to parse and execute JS. You don't get as much benefit from cached scripts as you do from other cached resources.