我之前一直在思考，在项目中引入第三方库会给我们带来什么，在你为什么用或不用框架？这篇文章中 wo 说了使用框架（库）带给我们的好处和不使用给我们的好处是什么，但是并未详细说明使用第三方库，它本身又会带来什么问题。
通过查找资料，我在 Hard Costs of Third-Party Scripts 这篇文章中找到了答案。第三方库带来的影响就是它降低了用户体验效果，增加了 用户成本。这篇文章从 7 个方面说明了使用第三方库可能带来的问题，文中说的问题你大多数也都遇到过。
译文如下：
我对第三方库与用户体验成本之间的关系感兴趣。我做的每个客户端，平均大约使用 30 个第三方库。但开发者却因为 如果我们将 *async* 它们全部加载呢？减少了对它们的争论。虽然这是一个很好的反驳，但是仍然存在将它传递给用户的成本。这就是我要讲的主题。
用户成本 是什么？最常见答案可能是隐私。但就隐私被侵犯这事儿来说，从来没有明确界限。人们对个人数据暴露也有不同的容忍度。在讨论第三库的时，隐私就变得有点儿笨拙党的感觉。虽然讨论它们很有必要，但我希望将隐私与第三份库分开，并专注于应用程序带来的成本。
为了更好地了解 用户成本，我在 Twitter 上发了一个话题：假设我们有一个包含约 300 个第三方库的站点，所有库都负责加载为异步，用户体验将面临什么？
1. aync 代码在你自己编写的代码之前到达
如果异步代码在你自己编写的代码完成下载之前到达，将阻止 HTML，CSS 和 JS 解析。
2. DNS 查询成本
今年早些时候，我看到 webhint 的 AntónMolleda 做的 一些数字统计，它表明即使 3 次 DNS 查询，也会在 3G 渲染预算上降低~5s/170kb，额外需要 10kb。有一些 HTTP 存档数据表明更多的第三方库会增加加载时间，这似乎证实了这个数字。
3. CPU 占用
第三方库可能会阻止你自己编写的代码的性能。它占用了大量的可用的 CPU 周期，你自己编写的代码处于明显的 下风。
4. 网络占用
Paul Irish 提到了类似于 CPU 占用的网络占用，他说：“你的更重要的自己编写的代码的网络请求会占用较少的带宽。”虽然你的浏览器有~5 个连接线程可用于网络请求，但你自己编写的代码的任何部分或单个页面需要另一个文件或者懒加载的图像，它可能需要排队等一段时间。
5. 用户数据和电池成本
手机的数据需要成本，HTTP 请求也会消耗手机电池的电量。我认为无论是用户有意识地，还是由市场的无形大手的引导，最终将追求非数据消费和电池电量消耗的替代方案（例如，使用 FB Messenger 的微信）
6. 重载事件
它和 CPU 占用类似，但大多使用 scroll，resize，或 click 的库可能会降低页面在浏览器中的自适应性，在极端情况下可能会导致布局的崩溃。
7. 调试覆盖范围增加
虽然这会增加组织代码的成本，但它可能会变成影响用户体验的成本。更多库会增加调试的覆盖范围。如果出现问题，你是喜欢检查 5 个地方的问题还是 300 个？我最近遇到了由第三方库的问题而导致的错误，找出导致问题的库，花费了我一整天的时间，但我仍然不知道该如何将该库引入构建，而不产生错误。
虽然 300 个第三方库，这听起来有点夸张，但是有约 50 或者约 150 个第三方请求呢？我现在有几个应用就是这个样子。Alexa Top 50 的统计结果是平均约为 18 个第三方库。我坚信即使有了第三方提供的解决方案，你也可能会遇到部分或全部上述的问题。
总结
我想这里我们可以得到这样一个结论，那就是单页应用程序和它每个路由的 JS 构建包可能最有可能被网络和 CPU 争用所扼杀。你的初始有效负载可能会获得 100%的 CPU，但后续页面可能会争夺其中的一小部分。但这取决于你的构建策略，如果构建策略是完美的，那么构建包会很好的加载并及时执行。不仅是 SPA 可能会遇到这样的问题，其它任何资源都可能延迟加载，并缓慢的执行。特别是网络不靠谱的情况下，所以这不应该让你感到非常惊讶的。
如果你想到我遗漏的任何东西，请告诉我。我想我们都在这艘沉没的第三方船上，我们彼此都需要摆脱它。
我在 gihub[article 中开辟了一个想法模块]，我会陆续添加一些相似的文章，希望得到大家的支持。