我正在开发相当大的SPA(最终~30MB)，不幸的是，其中一个要求是应用程序必须作为一个大的html文件发布。我使用webpack将所有部分连接在一起。
目前我面临着性能问题(有些库是相当大的库)。它们"吃掉"了很多 ram，并且由于浏览器中的代码评估而影响加载时间。我想推迟它并仅评估应用程序主屏幕上必需的这些模块。
我的想法是使用与 webpack 相同的机制来处理源映射：
https://webpack.js.org/configuration/devtool/(评估源地图)
Webpack 只是将代码放在eval("模块代码")中，从而阻止了 Javascript 引擎的自动评估。当然，这段代码不能缩小，最后还附加了 base64 的源映射。我想在没有源映射和包括丑陋化的情况下做同样的事情。此外，我有一个想法，通过压缩源代码来减小应用程序的大小，因此最终它将是eval(gz.decompress("模块代码"))。
这将是应用的巨大变化，所以在我重新发明轮子之前，我想问你：
- 从问题的角度来看有意义吗？
- 您知道任何现有的解决方案吗？
- 您是否建议使用 webpack 中的任何现有组件，例如：
https://webpack.github.io/docs/code-splitting.html
或者从头开始编写自己的解决方案(加载器/插件)。
不要随心所欲！
如果您确实想找到一个奇怪的技巧来获得您想要的东西，请尝试动态包含您的大 JS 文件。请参阅此处或谷歌jquery getscript。无需额外的 Webpack 操作。
如果没有，请继续阅读。
你从错误的角度处理问题。
首先，确保你正在做所有明显的HTML/HTTP内容：
- 您正在下载该文件的
gzip-ed版本(如果没有，则谷歌http script gzip) - 您将在
body末尾包含<script>标记。只有在 HTML 呈现后，才会开始下载和解析 JS。
然后，最重要的是，尝试找出30MB来自哪里。这不太可能是你所有大胖依赖的公平总和。通常，它是一个特定的臃肿库(或两个)。确保使用得到而不是请求，因为最少是臃肿的。查找超大依赖项的替代方法。
世界上没有一个 SPA 应该有一个 30MB 的 JS 捆绑包。我假设你的项目不是很大，否则它将是业务关键，你会投资提供一个体面的后端策略(例如代码拆分、死代码消除等)。
1)类似的问题可以通过Webpack代码拆分功能来解决。
这个想法是，在用户访问特定页面之前，您不会加载特定于路由的代码和库。
2)看看这个：script-ext-html-webpack-plugin，看起来很有前途做这些事情。例如，延迟选项适用于要延迟执行的模块或脚本。异步适用于要在执行 HTML 时执行的脚本。不过要小心比赛条件。
3)你提到你使用的库太大了，确保你使用带有摇树的Webpack。如果您使用没有树摇动的旧 Webpack(版本 1.*)，则应尝试手动优化导入。例如，而不是import _ from 'lodash'它会是import map from 'lodash/map'.
4)您还提到内存是问题所在，那么压缩如何帮助RAM？压缩可以帮助浏览器更快地检索它。
5)另一个想法是：
- 加载主页所需的脚本
- 此时，用户将看到功能页面
- 然后在后台缓慢加载其他脚本，而用户不会注意到它。
- 评估加载的代码，因为它将成为用户需要的。