Performance issues

[BowlingX]

Hi,
thank you for this great plugin. I'm running to some performance issues with a big project.
Due the multiple bundles generated (one with and one without css), the build time increases significant (at least double in production with minification) in comparision with just extract-css-webpack-plugin . It also seems to me, that the no_css get's generated when there is no css imported at all.

In my case it goes from 6 minutes to 16 Minutes.

[faceyspacey]

Wow that's a big build.

A pr just came in yesterday to turn off the no_css chunks all together. Would that work for you or are you saying that some of your chunks have css and some not?

I don't suppose u could put some timers in node_modules/extract-css-chunks-webpack-plugin/index.js (and maybe loader.js) and figure out precisely what the problem is. It's either at the bottom of index or the bottom of loader.

Also checkout the pr. I don't wanna merge it until I'm 100% sure about the option name. But try turning off no_css chunks like in the PR and see if we still have the problem. That way we can know whether we can fully blame it on those extra chunks. There's a chance it's not. It's not the only thing I changed.

[BowlingX]

I created a pull-request to skip duplicating chunks that have no css. In my case it goes down to around 13 minutes now (always depending on the project I guess). Fully Skipping the duplicated chunks reduces it to 8 minutes, so I think this is the main issue.

[BowlingX]

What if the css stuff get's removed after optimizing instead of before ?

[BowlingX]

What also drains more performance is that all chunks / css files get extracted and therefore the style-loader (that is not fast in general) adds additional load on top. I would suggest to restore the configuration initialChunks only or allChunks.

[BowlingX]

And I think we should skip the generation of no_css files for non initial chunks (or make it configurable).

[BowlingX]

I actually would expect to behave like this:

app.js
   - basicStyles.css
   - routes: 
          - homepage.js (async)
             - homepageStyle.css
          - contact.js (async)
             - contactStyles.css

yields: (if we would create one entry per route)

homepage.bundle.js (app.js + homepage.js) no css
homepage.bundle.css (app.css + homepage.css only)

contact.bundle.js (app.js + contact.js) no css
contact.bundle.css (app.css + contact.css only)

Async part:
0.js (only homepage js + css)
1.js (only contact js + css)

[faceyspacey]

What if the css stuff get's removed after optimizing instead of before ?

Maybe, but I think at a certain point it becomes hard to parse the minified version of what needs to be removed.

style-loader (that is not fast in general) adds additional load on top

...Here's how I use style-loader:

https://github.com/faceyspacey/extract-css-chunks-webpack-plugin/blob/master/loader.js#L139
So i dont think it's style-loader that's slow. I just use it to inject it on the client. What's slow is that i "paste" the css into all your javascript modules (like I assume style-loader would otherwise do). I'm just saying--maybe there's a faster way to do what I did right there. But I'm not doing much besides string interpolation.

I would suggest to restore the configuration initialChunks only or allChunks.

but then why not just use the original EWTP? ...i usually don't have setups with multiple named chunks, and just rely on dynamic chunks, but I think I know what you want (based on your PR):

• automatic detection of whether bundles even have CSS, and if not, dont create a no_css.js file.
• make additional css files configurable as per this PR.

Does combining those 2 PRs solve the problem? Do we need deeper specification options for toggling no_css.js creation. Like, do we let u specify whether it's on or off at both the named chunk level and dynamic chunk level?

And if so, story over?

[faceyspacey]

also, let me know if u have any input on the noCssChunks option name, etc. as per @igogrek 's PR.

[faceyspacey]

...unfortunately, we also have this issue:

faceyspacey/universal-demo#1

I asked a Webpack team member about how to solve it here (with no response yet):
#3 (comment)

if you have any ideas about that one, it would really help this out. I plan to more publicly release/promote just this plugin once that's solved. And urs and @igogrek 's also make a whole lotta sense to have before launching.

[faceyspacey]

here's a short private/unpublished launch article im releasing in a few days:

https://medium.com/@faceyspacey/extract-css-chunks-webpack-plugin-chunkify-your-css-a-few-things-you-need-45cb474cc332

feedback is much appreciated. trying to make this as obvious to people as possible. anything i should strip away or add? or say better?

...guys help me get this (as in the package in general) ready for prime time. we all know its very needed.

[BowlingX]

style-loader (that is not fast in general) adds additional load on top

Sorry, I meant the css-loader, see this issue here: webpack-contrib/css-loader#124. So in general, I would prefer to have as less as possible duplicated work.

but then why not just use the original EWTP? ...i usually don't have setups with multiple named
chunks, and just rely on dynamic chunks, but I think I know what you want (based on your PR):

good question :). the EWTP plugin does not load the additional styles async, that's how I found your repository (trough this issue: webpack-contrib/extract-text-webpack-plugin#120)

I think however, that this is a bug and I'm constructing a test case right now.

[BowlingX]

I created a pull request here, that addresses the issue and shows a test case webpack-contrib/extract-text-webpack-plugin#546

[faceyspacey]

...ok, but didnt u solve your problem here with your PR? If the other PR is combined, doesn't that solve all the problems you're interested in?