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 css-loader@0.23.1 with css-modules, when I downgrading to 0.14.1, it save 56s for me to build my project. But, I can't use css-modules anymore. Maybe the 56s time cost just because css-modules?

---

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

[jhnns]

I did some profiling with the sass-loader: webpack-contrib/sass-loader#296 (comment)

[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