Question

我一直在优化我的应用的加载时间，经过优化我的代码的一些快速获胜后，我注意到似乎有一个500毫秒长的初始化阶段，其中所有需要的语句似乎都得到了解决，什么的。

这可以优化吗？

我正在使用webpack，做出反应并结合几十个npm包。结果文件解压缩为2.8M，压缩约900k。应用程序本身没有大量的代码，主要是npm包。

我想知道我是否可以以不同的方式编译，以避免所有需求和实时不适用。

更新：我目前正在使用带重复数据删除插件的生产版本。

Answer 1

正如一些评论已经指出的那样，我们必须区分构建时和运行时。 webpack文档中的referenced guide与构建性能有关。

虽然不使用像源映射这样的devtools和缩小代码会影响执行速度，但我认为最重要的是分块/延迟加载（正如estus已经指出的那样）

您应该确定初始渲染不需要应用程序的哪些部分。应将这些部分移动到另一个块中并通过require.ensure()懒惰地加载。

通常，您的路由器是异步加载内容的典型位置：

<Router>
    <Route
        path="/dashboard"
        getComponent={loadPage("Dashboard")}
    />
</Router>

function loadPage(page) {
    return (location, cb) => pages[page](cb);
}

const pages = {
    Dashboard(cb) {
        require.ensure(
            ["./Dashboard.js"],
            require => cb(null, require("./Dashboard.js").default)
            // .default is required in case you are using ES2015 modules
        );
    }
};

现在，Dashboard上仅需要的所有模块都将被移动到一个单独的块中。

详细require.ensure部分甚至可以通过将所有顶级组件（我将其称为pages）移动到pages等专用文件夹中进行优化。然后，您可以将webpack配置为始终使用bundle-loader：

异步加载这些内容

// webpack.config.js
...
{
    test: /\.jsx$/,
    include: [
        path.resolve("path", "to", "pages"),
    ],
    loaders: [
        "bundle-loader?" + JSON.stringify({
            lazy: true
        })
    ]
},

然后你的路由器看起来像：

// This does not actually import the Dashboard,
// but a function which loads the dashboard.
import Dashboard from "path/to/pages/Dashboard";

function loadPage(page) {
    return (location, cb) => pages[page](module => {
        cb(null, module.default);
    });
}

const pages = {
    Dashboard
};

如果你是超级懒惰而且你只想在不手动创建pages - 对象的情况下引用相同的文件名，你也可以使用require contexts：

function loadPage(page) {
    return (location, cb) =>
        require("./path/to/pages/" + page + ".jsx")(
            module => cb(null, module.default)
        );
}

Answer 2

您可以做的一件事是使用devTool config来改变生成源图的方式。这应该会加快速度，但代价是易于调试。

Webpack实际上有一个很好的指导如何优化性能http://webpack.github.io/docs/build-performance.html。

基本上，它归结为您认为需要多少调试信息。

通过设置

{
  devtool: "#source-map"
}

您保留原始代码，这显然是最容易调试的，但这是以文件大小/构建时间为代价的。

<强>更新根据克里斯在下面的评论，这里是another guide

Answer 3

我不相信您的时间表来自缩小代码（比较maped文件中的__webpack_require__和缩小代码中的f。

我将展示minify和一些插件可以减少这个脚本的两倍运行时间。在webpack配置中，我将仅显示配置之间的主要区别。

开发模式

webpack.config.js

devtool: 'cheap-module-eval-source-map',
cache: true,
debug: true,

时间轴 - 473毫秒

生产模式

webpack.config.js

plugins: [
    'transform-react-remove-prop-types',
    'transform-react-constant-elements',
    'transform-react-inline-elements'
],
cache: false,
debug: false,
plugins: [
    // Search for equal or similar files and deduplicate them in the output
    // https://webpack.github.io/docs/list-of-plugins.html#dedupeplugin
    new webpack.optimize.DedupePlugin(),

    // Minimize all JavaScript output of chunks
    // https://github.com/mishoo/UglifyJS2#compressor-options
    new webpack.optimize.UglifyJsPlugin({
        compress: {
            screw_ie8: true, 
            warnings: false,
        },
    }),

    // A plugin for a more aggressive chunk merging strategy
    // https://webpack.github.io/docs/list-of-   plugins.html#aggressivemergingplugin
    new webpack.optimize.AggressiveMergingPlugin(),
]

时间轴 - 228毫秒

如果您希望从此解释中深入分析webpack.config.js，可以查看react-starter-kit的源代码。

如何优化webpack / es6开销？

3 个答案:

开发模式

生产模式