Css-loader: 0.15.0+ makes Webpack load slowly

[ljconde]

Ever since the 0.15.0 update, I've had to revert back to 0.14.5, because Webpack loads very slowly (12 secs vs almost 60 secs). Is there a breaking change I should be aware of? Maybe something regarding PostCSS?

[ljconde]

Here's the webpack update output using css-loader 0.16.0 (same happens with 0.15.0+):

Hash: 8d3652a9b4988c8ad221
Version: webpack 1.11.0
Time: 51612ms

Here's the output with css-loader 0.14.5:

Hash: bd471e6f4aa10b195feb
Version: webpack 1.11.0
Time: 6121ms

[BowlingX]

Same here, but I have more then 40 css (sass) modules, that take about 15 seconds with the old version and around 4 Minutes with the latest.

[BowlingX]

still exists in 0.18, but its faster then the 0.16 build:

0.18.0:

Container#eachAtRule is deprecated. Use Container#walkAtRules instead.
Container#eachRule is deprecated. Use Container#walkRules instead.
Container#eachDecl is deprecated. Use Container#walkDecls instead.
Hash: 0a92ccc4450f1a9a5193
Version: webpack 1.12.0
Time: 60275ms

0.14.5

Hash: 53d6260b86ff835b0eb1
Version: webpack 1.12.0
Time: 16196ms

[Phoenixmatrix]

Probably PostCSS, since that's the first thing that changed after 0.14.5, and that thing does a lot.

IMO at this point CSS loader does too much. There's no real alternatives if you want url/import mapping and sourcemaps (raw-loader won't help with those), but to get those you have to pay the cost of all the bells and whistles. Is it time for a minimal css-loader that does just enough to pass stuff from the post-processors (like less-loader, sass-loader, etc) to style-loader as quickly as possible, with optional import/url support?

[jhnns]

I agree @Phoenixmatrix. There are still a lot of people who only want imports and urls to be resolved which doesn't even require an actual parser imho.

What do you think @sokra? Is it time to separate the css-loader from css-modules? Did I miss something?

[sars]

same problem...

[unindented]

Same problem here. With 0.14.5 build time is 60s, with 0.23.1 it is 90s.

[MoOx]

poke @ai

[ai]

New PostCSS is not slow then previous. But when you use depreacted PostCSS API it is of course slower, because it should print warning and call extra code.

So, you should update webpack custom plugins for PostCSS 5.0 API (it is very simple) to remove all warnings. It will give a good speed boost.

[ai]

Here is benchmarks: PostCSS 4.x vs. 5.0.

[ElegantScripting]

I'm having these issues too.

[goldensunliu]

@ai do you know which calls in https://github.com/webpack/css-loader/blob/master/lib/processCss.js are deprecated? I would take a stab at it, but am having trouble finding any information on deprecated methods from 4.0

[goldensunliu]

I am not seeing anything in the source code that is deprecated based on this change log on deprecation
https://github.com/postcss/postcss/blob/0873667be6d65dafb1d2a3650ce87cd1f3fec204/CHANGELOG.md#50-president-valac

[ai]

@goldensunliu here is 5.0 changes post https://github.com/postcss/postcss/releases/tag/5.0.0

Maybe CSS Modules uses 4.0 API?

[unindented]

@ai css-loader didn't use to use PostCSS, just regular expressions. It was version 0.15 the one that introduced PostCSS, and that's when performance degraded. I don't think it's a matter of 4.0 API vs 5.0 API. It's just that css-loader wasn't using PostCSS, and was obviously faster, because it did less.

[Phoenixmatrix]

I still feel there's more to it than just "css-loader is using PostCSS so now its slow"

PostCSS is reasonably fast. Using a couple of postcss things with raw loader is significantly faster than using css-loader stand alone. so I don't think it's just PostCSS usage.

[ai]

We have a postcss-devtools to find slowest plugin in PostCSS pipeline https://github.com/postcss/postcss-devtools

I think it is a ideal case for it.

[billyjanitsch]

@ai I tried adding postcss-devtools to the css-loader pipeline but webpack throws a rather unhelpful error:

Module build failed: TypeError: Cannot read property 'length' of undefined

Any ideas?

[ai]

@billyjanitsch we need a full stacktrace to fix this issue

[billyjanitsch]

@ai I figured out that it's because postcss-modules-values (also included in the css-loader pipeline) doesn't register itself using the postcss.plugin API.

Is this valid (i.e. a bug in postcss-devtools for not handling this case) or invalid (i.e. a bug in postcss-modules-values for not registering itself like others do)?

[ai]

It is bad thing for public plugins https://github.com/postcss/postcss/blob/master/docs/guidelines/plugin.md#14-create-plugin-by-postcssplugin

But we should fix it in postcss-devtools, because some debug/custom plugins could be without name.

[billyjanitsch]

Anyway, I was able to hackily fix this for the purpose of debugging css-loader speed, and found that in our build, postcss-modules-scope is by far the slowest plugin in the pipeline. postcss-modules-local-by-default can also be sluggish.

If anyone has more time to work on this, looking for perf improvements there might be a good place to start.

[FrendEr]

@billyjanitsch I am using [email protected] with css-modules, when I downgrading to 0.14.1, it save 5~6s for me to build my project. But, I can't use css-modules anymore. Maybe the 5~6s time cost just because css-modules?

---

Update: just set the query params from 'modules' to 'module', it works fine for me

[ai]

Guys, just run postcss-devtools — it is a special profiling tool, to find slowest PostCSS plugins. Maybe it is a CSS minifier. Maybe it is some mistake in CSS Modules (honestly, this plugins have a lot of PostCSS APU violations, I create a issues for biggest mistakes).

Performance should always starts from profiling.

[MoOx]

@ai postcss instance is not public, so it's not possible to add postcss-devtools without editing the package directly :/

[ai]

Yeap, we need extra hacks. In this case we can just edit files inside node_modules :D

[psimyn]

Findings and hacks so far. Chain-hacking stuff in node_modules of actual project to try to get an idea of what is slow. @billyjanitsch let me know if you've found anything else - I'm at about the same point as your earlier post

Here's what I've done if anyone wants some setup/or if I forget. Paths all relative to main repo (which has webpack with css modules)

1. cd css-loader
npm install postcss-devtools
2. Hack devtools to handle modules-values
   edit css-loader/postcss-devtools/node_modules/text-table/index.js:59, change c.length to c && c.length || 0; (or try/catch or something...).
3. Add devtools
   node_modules/css-loader/lib/processCss.js
   line 5: + var devtools = require('postcss-devtools');
   line 152: + devtools({precise: true}),

Some typical numbers:

postcss-modules-local-by-default  61.735718 ms
postcss-modules-scope             21.195637 ms
css-loader-parser                 13.432423 ms
modules-extract-imports           1.107515 ms
undefined                         659.907 μs

css-loader/node_modules/postcss-modules-local-by-default/index.js
console.log timediffs throughout this file
line ~238 call to localizeDecl (inside forEach loop) is where it seems to spend most of it's time. This makes sense since this is every declaration for every rule.

Haven't yet dug much into that but will try to see if there is anything obvious

[ai]

Looks fine. Do we have slow performance in production or development mode (because production mode has also a CSS minifier)

[psimyn]

both - but in dev mode it's ~80% of the build time. Dev mode is the more frustrating one, since they run hundreds of times more frequently than production deploys.

Main contributor is a js entry point used as dumping ground for all CSS files (extract text plugin then generates single CSS file). If changing a file included in a lot of places (e.g. variable in settings) it's often 30-40s to rebuild (while running watch!).

[psimyn]

i noticed that even though 'postcss-modules' stuff was taking the longest, it was still in the order of milliseconds whereas the actual wait time was seconds. ran a trace with node --prof ./node_modules/.bin/webpack, then loaded it in chrome's about://tracing view

It showed a huge amount of time (~75%) was being spent in url-resolver's Rework calls, so probably not css-loader-related.

removing sourceMap from sass-loader options has given ~400% speedup (from sometimes minutes down to ~30 seconds). Subsequent profiles have been more balanced (mix of all loaders).

Can people try disabling sourcemaps and see if that improves. I will try to look into why it's having such an effect, or if there are some other optimisations for for loader

[MoOx]

The weird thing is that you are mentioning Rework. css-loader is supposed to use postcss, not rework.

[psimyn]

yeah rework was used by url-loader (I think), but some kind of knock-on effect due to sourcemaps

[jhnns]

@psimyn disabling source maps will _always_ speed up the build time. But I have to admit that a 400% increase is a lot and there is probably room for optimization.

Btw: the url-loader has never used rework. Remember, the url-loader is _not_ responsible for detecting url() references in CSS-files. The url-loader does not know about CSS, HTML or JavaScript. It just takes a file, checks its file size and either emits it to the output folder and returns the final url or just returns a data url.

[psimyn]

my bad, resolve-url-loader had snuck himself in there - that is what was responsible for the rework process

I'll try to get a better profile of the postcss plugins since removing it

[jhnns]

No worries :grin:

[BerndWessels]

Hi

Any updates on the performance issues?

I use latest webpack with latest version of all loaders and plugins

sassLoader: {
    loader: ExtractTextPlugin.extract('css?sourceMap&modules&importLoaders=2!postcss!resolve-url!sass')
    }

for the production build and it is terribly slow. Even though I have only about 6 small sass files imported it takes more than a minute on a decent core i7 win 10 with ssd.

One thing I noticed is that the development version is still fast (~10sec)

/**
 * Webpack config for development
 */

// Force development mode for all build components.
process.env['BABEL_ENV'] = 'development';
process.env['NODE_ENV'] = 'development';

module.exports = require('./webpack.make')({
    BUILD: false,
    TEST: false,
    TRANSLATE: false
});

But the build is slow (~90sec)

/**
 * Webpack config for builds
 */

// Force production mode for all build components.
process.env['BABEL_ENV'] = 'production';
process.env['NODE_ENV'] = 'production';

module.exports = require('./webpack.make')({
    BUILD: true,
    TEST: false
});

webpack.make.js

/**
 * Webpack config
 */

// Modules
var fs = require('fs');
var path = require('path');

var webpack = require('webpack');
var autoprefixer = require('autoprefixer');
var HtmlWebpackPlugin = require('html-webpack-plugin');
var ExtractTextPlugin = require('extract-text-webpack-plugin');
var BrowserSyncPlugin = require('browser-sync-webpack-plugin');
var CleanWebpackPlugin = require('clean-webpack-plugin');
var CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = function makeWebpackConfig(options) {
    /**
     * Environment type
     * BUILD is for generating minified builds
     * TEST is for generating test builds
     */
    var BUILD = !!options.BUILD;
    var TEST = !!options.TEST;
    var TRANSLATE = !!options.TRANSLATE;

    /**
     * Config
     * Reference: http://webpack.github.io/docs/configuration.html
     * This is the object where all configuration gets set
     */
    var config = {};

    /**
     * Entry
     * Reference: http://webpack.github.io/docs/configuration.html#entry
     * Should be an empty object if it's generating a test build
     * Karma will set this when it's a test build
     */
    if (TEST) {
        config.entry = {}
    } else {
        config.entry = {
            app: './src/index.js'
        }
    }

    /**
     * Externals
     * Reference: http://webpack.github.io/docs/configuration.html#externals
     */
    config.externals = {
        "react": "React",
        "react-dom": "ReactDOM"
    };

    /**
     * Output
     * Reference: http://webpack.github.io/docs/configuration.html#output
     * Should be an empty object if it's generating a test build
     * Karma will handle setting it up for you when it's a test build
     */
    if (TEST) {
        config.output = {};
    } else if (TRANSLATE) {
        config.output = {
            // Absolute output directory
            path: __dirname + '/build/public',

            // Output path from the view of the page
            // Uses webpack-dev-server in development
            publicPath: '',

            // Filename for entry points
            // Only adds hash in build mode
            filename: '[name].bundle.js',

            // Filename for non-entry points
            // Only adds hash in build mode
            chunkFilename: '[name].bundle.js'
        };
    } else {
        config.output = {
            // Absolute output directory
            path: BUILD ? __dirname + '/dist' : __dirname + '/public',

            // Output path from the view of the page
            // Uses webpack-dev-server in development
            // Reference: http://stackoverflow.com/questions/34133808/webpack-ots-parsing-error-loading-fonts/34133809#34133809
            publicPath: BUILD ? '' : 'http://localhost:3000/',

            // Filename for entry points
            // Only adds hash in build mode
            filename: BUILD ? '[name].[hash].js' : '[name].bundle.js',

            // Filename for non-entry points
            // Only adds hash in build mode
            chunkFilename: BUILD ? '[name].[hash].js' : '[name].bundle.js'
        };
    }

    /**
     * Devtool
     * Reference: http://webpack.github.io/docs/configuration.html#devtool
     * Type of sourcemap to use per build type
     */
    if (TEST) {
        config.devtool = 'inline-source-map';
    } else if (BUILD) {
        config.devtool = 'source-map';
    } else {
        config.devtool = 'eval';
    }

    config.resolve = {
        extensions: ['', '.jsx', '.scss', '.js', '.json'],
        modulesDirectories: [
            'node_modules',
            path.resolve(__dirname, './node_modules')
        ]
    };

    /**
     * Loaders
     * Reference: http://webpack.github.io/docs/configuration.html#module-loaders
     * List: http://webpack.github.io/docs/list-of-loaders.html
     * This handles most of the magic responsible for converting modules
     */

    // Initialize module
    config.module = {
        preLoaders: [],
        loaders: [{
            // JS LOADER
            // Reference: https://github.com/babel/babel-loader
            // Transpile .js files using babel-loader
            // Compiles ES6 and ES7 into ES5 code
            test: /\.js$/,
            loader: 'babel',
            exclude: /(node_modules|bower_components)/
        }, {
            // ASSET FONT LOADER
            // Reference: https://github.com/webpack/file-loader
            // Copy png, jpg, jpeg, gif, svg, woff, woff2, ttf, eot files to output
            // Rename the file using the asset hash
            // Pass along the updated reference to your code
            // You can add here any file extension you want to get copied to your output
            test: /\.(svg|woff|woff2|ttf|eot)$/,
            loader: 'file?name=assets/fonts/[name].[hash].[ext]'
        }, {
            // ASSET IMAGE LOADER
            // Reference: https://github.com/webpack/file-loader
            // Copy png, jpg, jpeg, gif, svg, woff, woff2, ttf, eot files to output
            // Rename the file using the asset hash
            // Pass along the updated reference to your code
            // You can add here any file extension you want to get copied to your output
            test: /\.(png|jpg|jpeg|gif)$/,
            loader: 'file?name=assets/images/[name].[hash].[ext]'
        }, {
            // HTML LOADER
            // Reference: https://github.com/webpack/raw-loader
            // Allow loading html through js
            test: /\.html$/,
            loader: 'html'
        }, {
            // JSON LOADER
            // Reference: https://github.com/webpack/json-loader
            // Allow loading JSNO
            test: /\.json$/,
            loader: 'json'
        }
        ]
    };

    // ISPARTA LOADER
    // Reference: https://github.com/ColCh/isparta-instrumenter-loader
    // Instrument JS files with Isparta for subsequent code coverage reporting
    // Skips node_modules and files that end with .test.js
    if (TEST) {
        config.module.preLoaders.push({
            test: /\.js$/,
            exclude: [
                /(node_modules|bower_components)/,
                /\.test\.js$/
            ],
            loader: 'isparta-instrumenter'
        })
    }

    // LESS LOADER
    // Reference: https://github.com/webpack/less-loader
    // Allow loading less/css through js
    // Reference: https://github.com/postcss/postcss-loader
    // Postprocess your less/css with PostCSS plugins
    var lessLoader = {
        test: /\.less$/,
        // Reference: https://github.com/webpack/style-loader
        // Use style-loader in development for hot-loading
        loader: (!BUILD || TEST) ? 'style!css?sourceMap&modules&importLoaders=2!postcss!resolve-url!less' :
            // Reference: https://github.com/webpack/extract-text-webpack-plugin
            // Extract less/css files in production builds
            ExtractTextPlugin.extract(
                // activate source maps via loader query
                'css?sourceMap&modules&importLoaders=2!postcss!resolve-url!less'
            )
    };

    // SASS LOADER
    // Reference: https://github.com/jtangelder/sass-loader
    // Allow loading sass/css through js
    // Reference: https://github.com/react-toolbox/react-toolbox/issues/246
    // Configure React-Toolbox properly. TODO replace with own theming plugin
    var sassLoader = {
        test: /(\.scss|\.css)$/,
        // Reference: https://github.com/webpack/style-loader
        // Use style-loader in development for hot-loading
        // Reference: https://github.com/webpack/css-loader
        // Use css-loader with css-modules support for react-toolbox
        // Reference: https://github.com/postcss/postcss-loader
        // Reference: https://github.com/jtangelder/sass-loader
        loader: (!BUILD || TEST) ? 'style!css?sourceMap&modules&importLoaders=2!postcss!resolve-url!sass?sourceMap' : //!toolbox' :
            // Reference: https://github.com/webpack/extract-text-webpack-plugin
            // Extract sass/css files in production builds
            ExtractTextPlugin.extract('css?sourceMap&modules&importLoaders=1!postcss!resolve-url!sass') //!toolbox')
    };

    // Skip loading css in test mode
    if (TEST || TRANSLATE) {
        // Reference: https://github.com/webpack/null-loader
        // Return an empty module
        lessLoader.loader = 'null';
        sassLoader.loader = 'null';
    }

    // Add cssLoader to the loader list
    // config.module.loaders.push(lessLoader); // We are not using less!
    config.module.loaders.push(sassLoader);

    /**
     * PostCSS
     * Reference: https://github.com/postcss/autoprefixer-core
     * Add vendor prefixes to your css
     */
    config.postcss = [
        autoprefixer({
            browsers: ['last 2 version']
        })
    ];

    /**
     * Plugins
     * Reference: http://webpack.github.io/docs/configuration.html#plugins
     * List: http://webpack.github.io/docs/list-of-plugins.html
     */
    config.plugins = [
        // Reference: https://github.com/webpack/extract-text-webpack-plugin
        // Extract css files
        // Disabled when in test mode or not in build mode
        new ExtractTextPlugin('[name].[hash].css', {
            disable: !BUILD || TEST || TRANSLATE
        }),
        // Reference: http://mts.io/2015/04/08/webpack-shims-polyfills/
        // Inject a polyfill for the given key words
        new webpack.ProvidePlugin({
            'fetch': 'imports?this=>global!exports?global.fetch!whatwg-fetch'
        })
    ];

    // Skip rendering index.html in test mode
    if (!TEST && !TRANSLATE) {
        // Reference: https://github.com/ampedandwired/html-webpack-plugin
        // Render index.html
        config.plugins.push(
            new HtmlWebpackPlugin({
                template: './src/index.ejs',
                inject: false
            })
        );
    }

    // Add build specific plugins
    if (BUILD) {
        // Reference: https://github.com/jeffling/ng-annotate-webpack-plugin
        // Make Angular Injections minification safe
        config.plugins.push(
            // Reference: https://github.com/johnagan/clean-webpack-plugin
            // Clean the output folders before building
            new CleanWebpackPlugin(['dist', 'build'], __dirname),
            // Reference: https://github.com/kevlened/copy-webpack-plugin
            // Copy the public folder to the dist folder
            new CopyWebpackPlugin([
                {from: 'public'}
            ]),
            // Reference: http://webpack.github.io/docs/list-of-plugins.html#noerrorsplugin
            // Only emit files when there are no errors
            new webpack.NoErrorsPlugin(),

            // Reference: http://webpack.github.io/docs/list-of-plugins.html#dedupeplugin
            // Dedupe modules in the output
            new webpack.optimize.DedupePlugin(),

            // Reference: http://webpack.github.io/docs/list-of-plugins.html#uglifyjsplugin
            // Minify all javascript, switch loaders to minimizing mode
            new webpack.optimize.UglifyJsPlugin()
        )
    }

    // Add dev specific plugins
    if (!TEST && !TRANSLATE && !BUILD) {
        config.plugins.push(
            // https://webpack.github.io/docs/list-of-plugins.html#occurenceorderplugin
            new webpack.optimize.OccurenceOrderPlugin(),
            // Reference: https://github.com/gaearon/react-hot-loader/issues/127
            // https://webpack.github.io/docs/list-of-plugins.html#hotmodulereplacementplugin
            // new webpack.HotModuleReplacementPlugin(),
            // https://github.com/webpack/webpack/issues/701
            new webpack.OldWatchingPlugin(),
            // https://webpack.github.io/docs/list-of-plugins.html#dedupeplugin
            new webpack.optimize.DedupePlugin(),
            // https://webpack.github.io/docs/list-of-plugins.html#noerrorsplugin
            new webpack.NoErrorsPlugin(),
            // Reference: http://webpack.github.io/docs/list-of-plugins.html#noerrorsplugin
            // Only emit files when there are no errors
            new BrowserSyncPlugin(
                {
                    host: 'localhost',
                    port: 3000,
                    proxy: 'http://localhost:8087/'
                },
                {
                    // determines if browserSync should take care
                    // of reload (defaults to true). switching it off
                    // might be useful if you combine this plugin
                    // with webpack-dev-server to reach
                    // Hot Loader/Hot Module Replacement tricks
                    reload: false
                })
        )
    }

    /**
     * Dev server configuration
     * Reference: http://webpack.github.io/docs/configuration.html#devserver
     * Reference: http://webpack.github.io/docs/webpack-dev-server.html
     */
    config.devServer = {
        contentBase: './public',
        port: 8087,
        stats: {
            modules: false,
            cached: false,
            colors: true,
            chunk: false
        }
        /**
         * Add your own certificates for https here.
         * cert: fs.readFileSync('certificates/my-domain.crt'),
         * key: fs.readFileSync('certificates/my-domain.decrypted.key')
         */
    };

    config.toolbox = {
        theme: path.join(__dirname, 'src/theme.scss')
    };

    return config;
};

[psimyn]

@BerndWessels my main suspect is UglifyJS plugin - can you try removing that from your BUILD block and see if any faster?

Do you have a sample repo set up for this? I have been meaning to look back into it but needed a good example (i.e. very slow build) to test on

Thanks!

[BerndWessels]

@psimyn You are right - removing the UglifyJsPlugin speeds up the production build extremely (90sec down to 30sec). But I am pretty sure that it was faster before even with the ulgify plugin.

I will do some more experiments and maybe share a test repo if I get stuck.

Thanks for now.

[datakurre]

014.5

Hash: 62722a60bab2439b5095
Version: webpack 1.13.1
Time: 6154ms

0.23.1

Hash: 17911a52a6e0f640d6ed
Version: webpack 1.13.1
Time: 390122ms

[psimyn]

@datakurre do you have an example project to try with?

[datakurre]

@psimyn Nothing public currently. I was just struggling with these slowing build times without any visible reason and then found this issue.

[psimyn]

no worries, I will try to get some more info with node inspect later this week. If you find any good open source examples of super long builds let me know :)

[datakurre]

@psimyn Thanks. My example will eventually be published, but it may still take a few weeks and is not a trivial setup (I'm working on a webpack build setup for theming an open source CMS called Plone, and I don't even know how many original less/css files my build currently has :). So, probably there are simpler examples out there.

[jhnns]

A complex example would actually be good. I think the performance issues are not noticeable in too simple setups. I've seen some real slow builds in the wild and I don't know why that is...

[psimyn]

I just tried some profiling with a single entry point that just requires js. Most time-consuming thing I found was babel-loader.

Original build:
babel-loader for js
css-loader and extract-text-plugin for css
~4500 line css file (repeated class)

Same, but without babel-loader:

Setting up a similar test here; I'll try making it similar, or at least take longer for testing

[jhnns]

Yes, it makes sense that the babel-loader is a heavy loader, that's why you should skip node_modules.

[sublimeye]

Guys, this problem still exists and babel-loader is not related anyhow. It is css-loader's issue.
I was struggling trying to optimize webpack build times and couldn't understand why the hack it happens with nano-500kb CSS file.

I created a separate repository where only required webpack plugins are used:
https://github.com/sublimeye/css-loader-slow-load-example

Whenever I switch back to css-loader 0.14.5 I have ~2seconds, when I switch to version 0.23 I get 80seconds. It's ridiculous how long this bug exists. I'll probably try to look myself what might trigger that enormous work.

0.14.5: 2'356ms
0.15.0: 79'855ms

[psimyn]

thanks @sublimeye! checked your example, 90% of the time is spent in postcss-discard-duplicates. Can you try with this in webpack config?

  loader: 'style!css?-discardDuplicates'

For me build went from 40s to ~5s

Related issue: https://github.com/ben-eb/postcss-discard-duplicates/issues/9

[jhnns]

I'll probably try to look myself what might trigger that enormous work.

That is an excellent idea 👍. No one of us gets paid to do this kind of work. Our time is limited just as yours.

[ai]

Also maybe postcss-csso is better idea for CSS minify. It uses PostCSS AST too, but faster.

But cssnano anyway compress better, than csso.

[asztal]

I've attempted to fix the postcss-discard-duplicates performance issues with https://github.com/ben-eb/postcss-discard-duplicates/pull/32. Perhaps someone could try replacing their postcss-discard-duplicates with my version to see if it improves their CSS compile times?

[ben-eb]

I can confirm @asztal's patch dramatically improves performance and so I've cut a new release of postcss-discard-duplicates. New installs should see a drop in build times especially for large CSS files.

[csvan]

Confirming that 2.0.2 is a drastic improvement (builds down from 5-6 seconds to 2-3).

[flynfish]

same issue for me. Downgrading to 0.14.5 brought the build from about 40s down to under 2s.

Update with details:
On css-loader 0.25.0, with the 2.0.2 version of postcss-discard-duplicates, my build is about 34s, and a hot rebuild is at 18s.

Using version 0.14.5 of css-loader and 2.0.2 of postcss-discard-duplicates, my build is about 18s and hot rebuild is under 2s.

[jonnolen]

dumb question, what is npm preferred way of pegging the version of postcss-discard-duplicates at 2.0.2? I'm seeing it pulled in as via of cssnano dependencies.

[aight8]

How much this issue is solved? I just want that css loader work and do ONLY what it is related to. Postcss etc. I configure myself - how the most here except. Otherwise I have no clue what css-loader already doing and what not. This is extremly confusing then.

[bebraw]

@jonnolen Can you try to fix its version as a dev dep or lock it through yarn?

@aight8 Not solved at all, the regression still remains. It would take a bigger redesign to solve this I think and you still might see some slowness (the old solution was bit of a hack, but it was fast, yup).

[kennethaasan]

Downgraded css-loader from 0.26.1 to 0.14.5 and our total build time (including npm install, npm build, rsync and mco) went from 16 minutes to 8 and 23 seconds in Jenkins.

[jhnns]

I did some profiling with the sass-loader: https://github.com/webpack-contrib/sass-loader/issues/296#issuecomment-288464857

[knaos]

Is this issue fixed yet?

[outreal]

Does this issue also affect webpack 2 or 3?

[jhnns]

Nope, afaik it's not fixed. It's not directly related to webpack itself, but the way how the css loader works.

[alexander-akait]

Feel free to PR, what speedup css loader

[yibn2008]

If you don't need sourceMap and css module, you can try fast-css-loader, it use RegExp to parse @import and url(...), which will be faster than postcss.

[ai]

@yibn2008 note, that regexp is not a safe way for CSS since CSS could contain a string (inlined SVG?) or comments with directives inside.

But it is a good idea to improve css-loader. Maybe we could try to create a css-loader fork with PostCSS (it’s parser is very fast), but without all features. Maybe CSS Modules is used every time and slow down the process?

[yibn2008]

@ai I have handled comments in css, but inline SVG haven't been tested. I'll try to use postcss alone later to see is the performance improved.

[alexander-akait]

@ai it is in our plans in future, if somebody started this i can help

[alexander-akait]

In next major release (will be release in next future):

• We implement reusing ast from postcss-loader (increase perf)
• We implement logic for disable css modules plugins (modules: false, by default css modules disabled, you can avoid modules: false), it is allow increase perf, if you don't use css modules.

Feel free to open issue if you have ideas how we can increase perf more

[ZuBB]

@evilebottnawi will be any limitation for minimal required version of webpack for this new release of css-loader?

[alexander-akait]

@ZuBB webpack@4, but you can ignore peerDependencies warning and use in webpack@3

[ZuBB]

hi @evilebottnawi!

Sorry to persist but I see in "BREAKING CHANGES" section of v1.0.0 next statement

minimum require webpack version is 4

considering this do you think your statement on webpack@3 & next css-loader is still valid?

[alexander-akait]

@ZuBB we avoid using old webpack version due a lot of bugs, but no new api used in css-loader@1, also no used new api in webpack@2 (next release) so it should be work, but i recommended upgrade your webpack

[ZuBB]

thanks for reply @evilebottnawi! I got your point