如何使用prefetchPlugin&优化Webpack的构建时间分析工具? [英] How to optimize webpack's build time using prefetchPlugin & analyse tool?
问题描述
如webpack的Wiki所述，可以使用分析工具来优化构建性能:
As webpack's wiki says, it is possible to use the analyse tool to optimize build performance:
来自: https://github.com /webpack/docs/wiki/build-performance#hints-from-build-stats
有一个分析工具，它可以可视化您的构建并提供 一些提示，如何优化构建大小和构建性能.
There is an analyse tool which visualise your build and also provides some hint how build size and build performance can be optimized.
您可以通过运行webpack --profile生成所需的JSON文件 --json> stats.json
You can generate the required JSON file by running webpack --profile --json > stats.json
我生成统计文件(在此处可用)
将其上传到webpack的分析工具
并在提示标签下
我告诉我使用prefetchPlugin:
I generate the stats file (available here)
uploaded it to webpack's analize tool
and under Hints tab
I told to use the prefetchPlugin:
使用预取可提高构建性能. 从链的中间预取模块.
Use prefetching to increase build performance. Prefetch a module from the middle of the chain.
我从里到外挖掘网络，发现prefechPlugin上唯一可用的文档是这样的:
I digged the web inside out to find the only documentation available on prefechPlugin is this:
new webpack.PrefetchPlugin([context], request)
对普通模块的请求，该请求甚至在之前就已解决和构建
要求发生.这样可以提高性能. 尝试对
首先构建，以确定聪明的预取点.
A request for a normal module, which is resolved and built even before
a require to it occurs. This can boost performance. Try to profile the
build first to determine clever prefetching points.
- 如何正确使用prefetchPlugin?
- 什么是将其与分析"工具一起使用的正确工作流程?
- 我如何知道prefetchPlugin是否有效?我该如何测量?
- 从链的中间预取模块是什么意思?
- How to properly use prefetchPlugin?
- What is the right workflow to use it with the Analyse tool?
- How do I know if the prefetchPlugin works? how can I measure it?
- What it means to Prefetch a module from the middle of the chain?
我会很感激一些例子
对于下一个想要使用prefechPlugin和Analyze工具的开发人员，请帮助我使这个问题成为宝贵的资源. 谢谢.
Please help me make this question a valuable resource for the next developer who wants to use the prefechPlugin and the Analyse tools. Thank you.
推荐答案
是的，预取插件文档几乎不存在.在自己弄清楚它之后，它非常易于使用，并且没有太多的灵活性.基本上，它需要两个参数，上下文(可选)和模块路径(相对于上下文).在您的情况下，上下文为/absolute/path/to/your/project/node_modules/react-transform-har/，假设您的屏幕快照中的波浪号按照webpack的
Yeah, The pre-fetch plugin documentation is pretty much non-existent. After figuring it out for myself, its pretty simple to use, and there's not much flexibility to it. Basically, it takes two arguments, the context (optional) and the module path (relative to context). The context in your case would be /absolute/path/to/your/project/node_modules/react-transform-har/ assuming that the tilde in your screenshot is referring to node_modules as per webpack's node_module resolution.
理想情况下，实际的预取模块深度应不超过三个模块依赖项.因此，在您的情况下，isFunction.js是构建链较长的模块，理想情况下应在getNative.js
The actual prefetch module should be ideally no more than three module dependencies deep. So in your case isFunction.js is the module with the long build chain and ideally it should be pre-fetched at getNative.js
但是，我怀疑您的配置中有些时髦，因为您的构建链依赖关系是指模块依赖关系，应该由webpack自动对其进行优化.我不确定您是怎么得到的，但是在我们的案例中，我们看不到有关node_modules中较长的构建链的任何警告.我们大部分的长构建链都是由于需要scss的深度嵌套的react组件所致.即:
However, I suspect there's something funky in your config, because your build chain dependencies are referring to module dependencies, which should be automatically optimized by webpack. I'm not sure how you got that, but in our case, we don't see any warnings about long build chains in node_modules. Most of our long build chains are due to deeply nested react components which require scss. ie:
无论如何，您都希望为每个警告添加一个新插件，如下所示:
Regardless, you'll want to add a new plugin for each of the warnings, like so:
plugins: [
new webpack.PrefetchPlugin('/web/', 'app/modules/HeaderNav.jsx'),
new webpack.PrefetchPlugin('/web/', 'app/pages/FrontPage.jsx')
];
第二个参数必须是模块相对位置的字符串.希望这是有道理的.
The second argument must be a string to the relative location of the module. Hope this makes sense.
这篇关于如何使用prefetchPlugin&优化Webpack的构建时间分析工具?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
