-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
[email protected] slower webpack than @19.x #23221
Comments
Thank you! Seems like build-javascript is the problem here if I look closely. I can have a look at why that's happening. We changed bundling in a 2.20.7 I'll checkout your github repo: |
Just for debugging purposes, I run a Gatsby Cloud build that took 37min just in the queries stage 😂 |
Locked dependencies to {
"gatsby": "2.19",
"gatsby-cli": "2.10"
}
|
Like I thought it's webpack being way slower. I'll be investigating |
(To clarify; the reason is that we're looking into webpack is because that step ("Building production JavaScript and CSS bundles") is blocking but the reporter already starts counting for "run queries" so the time spent in "run queries" includes the webpack time entirely.)
So this is why "run queries" is not the source of the problem here. |
I confirm this is fixed; build time is back to be reasonable. Total build time took 119.87s. Thanks for that! |
This does not appear to be solved for my team. Our webpack builds are still about 4x slower than they used to be, and we are on gatsby 2.21.13. |
@rgraber if you see significant regression in the current version of Gatsby please open a new issue and let us know the repo to test it with as well as the last version known to you to be fast. Tag me in that issue. But please first check to confirm that it's still a problem on the current version. That includes other dependencies besides |
Description
gatsby@20
take too much time undergatsby build
command.gatsby@19
gatsby@20
This happening from the first
20.x
build. I was waiting a bit before opening the issue just to be sure it isn't a temporal regression that would be patched on successive versions, but it's still happeningSteps to reproduce
Expected result
Although my website project has a medium size, I expected that using latest gatsby version possible keeps the build time in similar numbers (around ~5m) or less.
At gatsby@20, most of the build time the process is spending the time at
run queries
stage:Actual result
This same stage at gatsby@19 is consuming so much less time:
185s at gatsby@19 vs 297 at gatsby@20!
Probably something internal in the way gatsby perform has changed and I did to rework my queries; but still feeling it's a bit strange, all my queries are static and I'm using useStaticQuery on all of them (see an example).
Just want to figure out what I need to do to back my project on gatsby road 🙂
Environment
The text was updated successfully, but these errors were encountered: