注意，今天我们要讨论的是公共 CDN，而不是自建 CDN 或云厂商的 CDN。
公共 CDN 已经没有缓存优势，对用户来说该加载数据量一点不会减少。
早年公共 CDN 能提速的核心逻辑非常简单：用户访问过任意使用同款 CDN 资源的网站，本地就会缓存该库，再次访问你的网站可以直接命中缓存、零下载。
但这套逻辑，在现代浏览器机制和前端生态下，早已荡然无存。
第一，Chrome 86 正式启用浏览器缓存分区机制，Firefox、Safari 等主流浏览器也同步跟进。不同站点的缓存是被隔离的，用户仍然需要重新下载脚本，所以公共CDN的那点缓存优势早已过时。
第二，即便退一步来说，用户使用 Chrome86 以下的老旧版本，现在已经不是千篇一律的jQuery时代了，现在是前端构建时代，要碰巧遇到之前访问过的网站刚好用了同供应商、同库、同版本、同格式的概率也比较低。
对用户来说，要加载数据量有可能更大
公共 CDN 提供的资源，都是固定全量打包产物。而现代前端工程最大的优势，就是可以基于业务场景做极致按需构建。进一步说，一切构建优化公共 CDN 都无法享用。
tree-shaking 项目中未使用的冗余代码、废弃逻辑，大幅精简资源体积。公共 CDN 的全量包包含库的全部功能代码，哪怕项目只用到 10% 能力，也需要加载 100% 的代码，冗余度极高。
打包 工程构建可将多个小型同类依赖合并为单个 chunk，减少请求数量；也可根据路由、功能拆分资源粒度，实现按需加载。公共 CDN 是固定打包产物，无法适配项目专属的合并、拆分策略。
依赖自身的构建开关 大量主流库提供了环境裁剪、功能开关的构建配置，可按需关闭无用模块、兼容代码。比如 Vue 的 __VUE_OPTIONS_API__。公共 CDN 为了适配全网所有场景，只能保留全部功能、开启全量兼容，无法做定制化裁剪。
按条件加载 现代前端工程可同时输出多份产物不同浏览器运行不同产物。比如业界常用 module/nomodule 实现条件加载。公共 CDN 大多只提供统一大包，要么产物臃肿，要么兼容性差。
自动 polfill 引入 一个优雅的构建过程，是会自动扫描依赖，然后注入特定polyfill的。但是外部依赖就无法扫描到了，要么就全局引入polyfill，要么只能人肉判断polyfill。
深层依赖预加载 在动态import时，现代前端工程能够同时请求深层依赖。使用公共 CDN，只有当前依赖请求完，才知道有哪些深层依赖。
公共 CDN 的网络真就比主站好吗？我看未必
公共 CDN 节点质量不可控、运营商链路不确定。弱网、跨国、小众地区可能比业务自研 CDN / 源站更慢。使用公共CDN还会带来额外的DNS解析、TLS握手、TCP连接建立、CORS校验等开销。
如果主站已经用了HTTP/2、3的多路复用，同域更能提升连接复用效率，进一步拉开差距。
就我个人平时的上网体验来看，打开慢的网站几乎都在用jsDelivr。
增加供应链风险
你的小网站可能黑客不感兴趣，但公共 CDN 可是黑客眼中的香饽饽。历史上，开源供应链攻击层出不穷，公共 CDN 极易面临劫持、篡改、停服、投毒风险。
为了防御，我们被迫使用 SRI (Subresource Integrity) 。
但 SRI 是把双刃剑。一旦 CDN 资源被篡改或者哈希不匹配，浏览器会直接拒绝加载。这就像是为了防止食物中毒，直接把所有外卖都倒进垃圾桶。用户结果是什么？页面白屏。
于是乎，为了用户体验，我们又要写“降级逻辑”：检测 CDN 挂了 -> 加载本地备用资源。
绕了一大圈，不仅代码变复杂了，用户还多走了一条无效的失败路径，速度反而更慢了。 这真是“捡了芝麻丢了西瓜”。
公共 CDN 和主站的 https 加密协议版本可能不同。
HTTPS 的加密协议在不断更新，但有一个核心矛盾：协议越安全，支持面越窄；支持面越广，越不安全。
当你的主站和公共 CDN 的 https 加密协议版本不同时，有可能你的主站支持的用户更广，公共 CDN 支持的用户更窄，导致主站正常，CDN 挂了，又要降级了哎。
更常见的是，公共 CDN 的域名不在用户的 HSTS 列表中。这等于是用户相信我们，但不相信别人，也会导致CDN 挂了。
首屏大小
绝大多数人使用公共 CDN 的方式，都是在首页直接通过 script 全局引入。这种模式本质上就是最原始的手动维护依赖方式，完全违背现代按需加载的工程理念。
如果是 jQuery 这类大概率首屏刚需的依赖，全局引入尚且可以接受。但如果是 lodash、工具类库、非核心组件库，大概率是页面二级、三级路由才会用到，或动态按需引入。
将非首屏依赖强行挂载到首页，会直接增大首屏资源体积、增加首屏请求数、阻塞页面渲染，白白拖慢首屏加载速度，完全得不偿失。
工程复杂度
如果在首屏，你可能通常这样写：
<script src="https://code.jquery.com/jquery-3.7.1.min.js"
integrity="sha384-这是一个示例哈希，故意不匹配"
crossorigin="anonymous"
></script>
<script>
if(!self.$) {
document.write('<script src="/res/jquery.min.js"></script>');
}
// 上面代码虽然勉强实现降级，但是由于是同步加载，是牺牲性能的。
</script>
如果不在首屏的话，还要考虑失败降级、SRI、兼容性整个复杂度提升不是一点半点。这里我就不展开说了，展开文章就跑题了。我简单地列一个表格就能窥见其复杂度。
| 场景 | 处理方案 |
|---|---|
支持 type="importmap": integrity |
使用importmap integrity |
| 支持 top-level-await 和 script integrity | 别名到一个虚拟模块，虚拟模块用 top-level-await 动态创建 |
| 不想使用构建技巧，就想使用原生import | 基于原生import写模块化运行时，fetch拿数据，运行时校验integrity，运行时解析转化源代码，生成blob url，创建script module，里面使用import * |
| 不支持top-level-await或原生import | 使用传统模块化运行时 |
如果非要我做的话，我会选择使用top-level-await，不支持的用传统模块化运行时降级。
总结
公共 CDN 只适合在首屏依赖，工程化不足的情况。比如传统 jQuery 项目：全局引入、人肉babel，这就很适合公共 CDN。但凡工程化能力比较强，即便用jQuery也能按需构建玩出花。
题外话
如果是面试场景，主考官问到“如何优化前端性能”，我建议你还是用公共 CDN。这不妥妥的八股题吗？你要是说公共 CDN不好，岂不是打面试官的脸吗？
