JavaScript 膨胀的三大支柱：为什么现代网站越来越慢？

你有没有发现，现在打开一个普通博客首页都要等好几秒？明明只是展示几行文字和图片，加载进度条却要转半天。打开开发者工具一看，吓一跳：十几MB的资源，JavaScript占了一大半。

十年前，网页平均大小不到1MB。现在呢？随随便便就突破10MB，翻了十倍都不止。JavaScript越来越胖，是网站变慢的罪魁祸首。

我们是怎么走到这一步的？我总结了三个核心原因，每一个都戳中现代前端开发的痛点。

第一根支柱：依赖地狱

我之前帮朋友改一个小项目，就加了一个日期格式化功能，打包体积直接涨了1MB。为什么？因为他用了一个很流行的日期库，这个库又依赖了好几个其它包，一层接一层，最后带进来几百个文件。

这就是npm的"依赖地狱"。你只想要一个简单功能，结果把别人全家都请来了。更夸张的是，不同依赖还会引入同一个包的多个版本，最后打包出来重复代码一大堆，反正用户流量买单，开发者不在乎。

我见过更绝的项目，为了用一个数组去重，导入了整个lodash。其实原生一句话就能写好：[...new Set(arr)]。

这种情况下，网站能不慢吗？

现在的前端框架越做越大，为了通用性，什么功能都给你内置好。不管你项目需不需要，反正都打包进去。

我见过很多企业官网，总共也就五六个页面，内容基本不怎么变，上来就是React + Vue三大框架走起，服务端渲染搞一套，打包出来几MB的JS。其实就是个展示型网站，用纯HTML+CSS写不好吗？加载速度能快十倍。

不是说框架不好，框架解决了复杂应用的很多问题。但问题是，很多开发者不管项目大小，上来就用最"主流"的技术栈，为了抽象而抽象。“零成本抽象"听起来美好，实际成本都藏在打包体积里，最终由用户的浏览器和流量买单。

我刚开始做开发的时候，也犯这个毛病。项目一开始，就想着"未来扩展”，把分层、架构、插件机制全都设计好，各种设计模式往上堆。结果项目上线一年了，当初预留的扩展点一次都没用过，代码倒是变复杂了，打包体积也上去了。

这就是过度设计。我们总喜欢为了可能永远不会来的"未来"，付出现在的性能代价。其实软件开发最宝贵的就是简洁，能解决当前问题的最简单方案，就是最好的方案。

YAGNI原则你肯定听过：“You Ain’t Gonna Need It” — 你其实不需要它。但真到写代码的时候，很多人还是控制不住自己。

我自己踩过这些坑之后，总结了几个简单实用的优化习惯，分享给你：

首先，导入依赖的时候只导入你需要的。别为了一个方法导入整个库，现在很多打包工具都支持按需导入，善用它。如果一个功能原生就能写，那就别加新依赖。

其次，定期给你的依赖做个体检。用webpack-bundle-analyzer之类的工具看看，谁占的体积最大，有没有可以替换的轻量化选项。比如用day.js代替moment，能省好几MB。

然后，别为了技术而技术。你的项目是展示型官网，就别强行上三大框架。工具是用来解决问题的，不是用来装X的。

最后，记住YAGNI。别提前设计一堆你现在不需要的功能，先把当前问题解决，未来真需要了再重构也不迟。

我之前给一个博客做过优化，把不必要的框架和依赖删掉，打包体积从3.2MB降到了不到300KB，加载速度直接提升了七八倍。用户打开网站几乎秒开，体验提升不是一点半点。

JavaScript膨胀不是哪个人的错，是整个生态发展到今天的结果。框架越来越大，依赖越来越多，大家都默认了这就是"现代开发"。但我觉得，我们应该偶尔停下来想一想：这些体积和复杂度，真的都是必须的吗？

回到Web最初的样子好不好？更快、更轻量、更省用户流量。毕竟，用户来你的网站是看内容的，不是来加载你的JS堆的。

你的项目最大的打包体积有多大？有没有遇到过哭笑不得的依赖地狱故事？评论区聊聊。