Long Module Build Chains

The webpack analyzer identifies most of my .scss requires as long module build chains in the hints sections. But even when I pre-fetch the modules nearest to the scss require, I still see the warning and a difference of about 10s between the start time and end time of the scss partial build. I suspect that this is because I’m using the ExtractTextPlugin like so:

    module: {
        loaders: [
            {
                test: /\.scss$/,
                loader: ExtractTextPlugin.extract('style-loader', 'css!sass')
            }
        ]
    },

    plugins: [
        new ExtractTextPlugin('style.[name].[chunkhash].css', {
            disable: false,
            allChunks: true //extract all css from async chunks as well
        }),

And the process does not begin until the chunks are being emitted near the end of the compilation. How does this jive with your experience and what would speed up the build time? Can the sass-loader be configured to pre-fetch all scss and compile them async with node-sass while the rest of the compilation is working?

[Phoenixmatrix]

First, make sure to upgrade to node-sass 3.4. The 3.X line had a major performance regression that was fixed. The actual time spent in node-sass will pretty much be cut by 80% by using node-sass 3.4, which was released recently.

Second, if you’re using css-loader and not using CSS modules, -downgrade- to css-loader 0.14.5, which is about 4x faster. The introduction of css modules and postcss and whatsnot slowed css-loader like crazy. 0.14.5 works fine and is the version right before the regression. If you do not need url resolution (common in development), pass css-loader the url=false argument. That speeds things up too.

If you do not need url and do not use CSS sourcemaps (you can use node-sass’ sourceComments flag instead during development), you’ll get another huge boost by using the raw-loader instead of css-loader.

Finally, since the ExtractTextPlugin needs to find your CSS in the huge amount of javascript to extract it, you can gain a 5-15% performance boost by making the file smaller: if you’re simply requiring your CSS from your javascript entry point (and no requiring CSS from all over your JS modules), create a second webpack configuration (webpack.config can be an array of configs), with the CSS as entry points, so extracting the CSS will be super quick as there won’t be any JS. I think the css loader gets invoked in a different way with ExtractTextPlugin which makes things worse, too. The latest webpack seems to handle this better, so upgrade that too.

Doing all of the above (especially the node-sass 3.4 upgrade, webpack 1.12.2, and not using css-loader > 0.14.5, brought our CSS compile time from 10-20s to <2s!!!.

Note that for SASS, incremental compile only makes a difference if you have a lot of chunks (unlike JS, where it can incrementally compile a single file inside a chunk), so if you have 1 big sass file with @import, you gain almost nothing with incremental.

[jhnns]

Closing this in favor of #296 I also did some profiling: https://github.com/webpack-contrib/sass-loader/issues/296#issuecomment-288464857