New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.15.0+ makes Webpack load slowly #124

Open
ljconde opened this Issue Aug 13, 2015 · 67 comments

Comments

Projects
None yet
@ljconde

ljconde commented Aug 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ljconde

ljconde Aug 13, 2015

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

ljconde commented Aug 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@BowlingX

BowlingX Aug 31, 2015

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 commented Aug 31, 2015

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 added a commit to BowlingX/flexcss that referenced this issue Aug 31, 2015

@BowlingX

This comment has been minimized.

Show comment
Hide comment
@BowlingX

BowlingX Sep 17, 2015

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

BowlingX commented Sep 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Phoenixmatrix

Phoenixmatrix Sep 18, 2015

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?

Phoenixmatrix commented Sep 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Oct 31, 2015

Member

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?

Member

jhnns commented Oct 31, 2015

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?

bebraw added a commit to antwarjs/antwar that referenced this issue Nov 6, 2015

Bump css-loader to 0.14 series
css-loader gets slow after that.

Related:
* webpack-contrib/css-loader#124
@sars

This comment has been minimized.

Show comment
Hide comment
@sars

sars Dec 12, 2015

same problem...

sars commented Dec 12, 2015

same problem...

@unindented

This comment has been minimized.

Show comment
Hide comment
@unindented

unindented Jan 20, 2016

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

unindented commented Jan 20, 2016

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

@MoOx

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Jan 27, 2016

Member

poke @ai

Member

MoOx commented Jan 27, 2016

poke @ai

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 27, 2016

Contributor

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.

Contributor

ai commented Jan 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 27, 2016

Contributor

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

Contributor

ai commented Jan 27, 2016

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

@ElegantScripting

This comment has been minimized.

Show comment
Hide comment
@ElegantScripting

ElegantScripting Mar 24, 2016

I'm having these issues too.

ElegantScripting commented Mar 24, 2016

I'm having these issues too.

@goldensunliu

This comment has been minimized.

Show comment
Hide comment
@goldensunliu

goldensunliu Mar 27, 2016

@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 commented Mar 27, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@goldensunliu

goldensunliu Mar 27, 2016

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

goldensunliu commented Mar 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 27, 2016

Contributor

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

Maybe CSS Modules uses 4.0 API?

Contributor

ai commented Mar 27, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@unindented

unindented Mar 28, 2016

@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.

unindented commented Mar 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Phoenixmatrix

Phoenixmatrix Mar 28, 2016

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.

Phoenixmatrix commented Mar 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 28, 2016

Contributor

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.

Contributor

ai commented Mar 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@billyjanitsch

billyjanitsch Apr 1, 2016

@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?

billyjanitsch commented Apr 1, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 1, 2016

Contributor

@billyjanitsch we need a full stacktrace to fix this issue

Contributor

ai commented Apr 1, 2016

@billyjanitsch we need a full stacktrace to fix this issue

@billyjanitsch

This comment has been minimized.

Show comment
Hide comment
@billyjanitsch

billyjanitsch Apr 1, 2016

@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)?

billyjanitsch commented Apr 1, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 1, 2016

Contributor

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.

Contributor

ai commented Apr 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@billyjanitsch

billyjanitsch Apr 1, 2016

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.

billyjanitsch commented Apr 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@FrendEr

FrendEr Apr 18, 2016

@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

FrendEr commented Apr 18, 2016

@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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 18, 2016

Contributor

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.

Contributor

ai commented Apr 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Apr 18, 2016

Member

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

Member

MoOx commented Apr 18, 2016

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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 18, 2016

Contributor

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

Contributor

ai commented Apr 18, 2016

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

@psimyn

This comment has been minimized.

Show comment
Hide comment
@psimyn

psimyn Apr 18, 2016

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

psimyn commented Apr 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Apr 18, 2016

Contributor

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

Contributor

ai commented Apr 18, 2016

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

@psimyn

This comment has been minimized.

Show comment
Hide comment
@psimyn

psimyn Apr 18, 2016

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 commented Apr 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@psimyn

psimyn Apr 22, 2016

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

psimyn commented Apr 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Apr 22, 2016

Member

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

Member

MoOx commented Apr 22, 2016

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

@psimyn

This comment has been minimized.

Show comment
Hide comment
@psimyn

psimyn Apr 22, 2016

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

psimyn commented Apr 22, 2016

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

@jhnns

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Apr 22, 2016

Member

@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.

Member

jhnns commented Apr 22, 2016

@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.

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 2, 2016

Contributor

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

But cssnano anyway compress better, than csso.

Contributor

ai commented Aug 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@asztal

asztal Nov 12, 2016

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

asztal commented Nov 12, 2016

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

@ben-eb

This comment has been minimized.

Show comment
Hide comment
@ben-eb

ben-eb Nov 13, 2016

Contributor

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.

Contributor

ben-eb commented Nov 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@csvan

csvan Nov 14, 2016

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

csvan commented Nov 14, 2016

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

@flynfish

This comment has been minimized.

Show comment
Hide comment
@flynfish

flynfish Nov 14, 2016

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.

flynfish commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jonnolen

jonnolen Feb 1, 2017

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.

jonnolen commented Feb 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@aight8

aight8 Feb 2, 2017

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.

aight8 commented Feb 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bebraw

bebraw Feb 2, 2017

Contributor

@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).

Contributor

bebraw commented Feb 2, 2017

@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).

JeffreyWay added a commit to JeffreyWay/laravel-mix that referenced this issue Feb 15, 2017

Downgrade css-loader requirement
Seems like a huge performance regression was introduced a long time ago
with v0.15.0.

webpack-contrib/css-loader#124

I just confirmed it. With the latest release of css-loader, a test file
of mine took 30 seconds to compile. After I downgraded to 0.14.5, that
time was reduce to 12 seconds.
@kennethaasan

This comment has been minimized.

Show comment
Hide comment
@kennethaasan

kennethaasan Mar 1, 2017

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.

kennethaasan commented Mar 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Mar 22, 2017

Member

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

Member

jhnns commented Mar 22, 2017

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

@knaos

This comment has been minimized.

Show comment
Hide comment
@knaos

knaos Oct 10, 2017

Is this issue fixed yet?

knaos commented Oct 10, 2017

Is this issue fixed yet?

@outreal

This comment has been minimized.

Show comment
Hide comment
@outreal

outreal Oct 11, 2017

Does this issue also affect webpack 2 or 3?

outreal commented Oct 11, 2017

Does this issue also affect webpack 2 or 3?

@jhnns

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Oct 12, 2017

Member

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

Member

jhnns commented Oct 12, 2017

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

@evilebottnawi

This comment has been minimized.

Show comment
Hide comment
@evilebottnawi

evilebottnawi Feb 15, 2018

Member

Feel free to PR, what speedup css loader

Member

evilebottnawi commented Feb 15, 2018

Feel free to PR, what speedup css loader

@yibn2008

This comment has been minimized.

Show comment
Hide comment
@yibn2008

yibn2008 May 8, 2018

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.

yibn2008 commented May 8, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai May 8, 2018

Contributor

@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?

Contributor

ai commented May 8, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@yibn2008

yibn2008 May 8, 2018

@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.

yibn2008 commented May 8, 2018

@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.

@evilebottnawi

This comment has been minimized.

Show comment
Hide comment
@evilebottnawi

evilebottnawi May 8, 2018

Member

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

Member

evilebottnawi commented May 8, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment