gatsby build very slow

[brigand]

Description

Trying out gatsby for the first time. Not sure if "blazing fast" applies to the production builds, or just while developing, or maybe I'm using the wrong command. Any help is appreciated.

Running gatsby build. Site created from gatsby-starter-docs which is based on gatsby-advanced-starter. If this is unusual performance, a pointer to a known fast base would be appreciated.

Gatsby version: 1.8.11

info bootstrap finished - 2.292 s

success Generating CSS — 53.505 s
success Compiling production bundle.js — 96.203 s
success Generating static HTML for pages — 44.830 s
Total precache size is about 405 kB for 5 resources.
success Done building in 197.28 seconds

Gatsby version 1.9.149 (upgraded all deps in the project to the 'latest' npm tag).

info bootstrap finished - 2.656 s

success Building CSS — 37.436 s
success Building production JavaScript bundles — 79.457 s
success Building static HTML for pages — 39.995 s
Total precache size is about 737 kB for 8 resources.
info Done building in 159.631 sec

It's fast in development mode, but the development startup time is also quite slow. The server doesn't even listen on the port for around 8 seconds.

Development mode output:

info bootstrap finished - 2.827 s

 DONE  Compiled successfully in 36494ms                                       21:11:13


You can now view high-redux-docs in the browser.

  http://localhost:9911/

View GraphiQL, an in-browser IDE, to explore your site's data and schema

  http://localhost:9911/___graphql

Note that the development build is not optimized.
To create a production build, use gatsby build

 WAIT  Compiling...                                                           21:11:13

 DONE  Compiled successfully in 1615ms

Environment

Gatsby version: 1.8.11, also tried upgrading to ^1.9.149
Node.js version: 8.9.0
Operating System: OSX, Darwin {my host} 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64

File contents (if changed):

Repo here: https://github.com/brigand/high-redux-docs

Running yarn build:pp.

Actual result

It takes a very long time, even if I don't modify any files between runs.

---

Thanks for the otherwise amazing tool!

[benjaminhoffman]

success Building CSS — 16.832 s
success Building production JavaScript bundles — 40.115 s
success Building static HTML for pages — 21.036 s
success Done building in 81.941 seconds
✨  Done in 82.15s.

^^ mine
_blazing fast_ refers to the runtime. Page loads super quick for your users. Check out Kyle's recent talk about page load speed: https://www.youtube.com/watch?v=Gtd-Ht-D0sg&feature=youtu.be

I will admit that your build is a bit long tho. Lots of images or assets?

One thing I that that will speed it up is Gatsby 2.0... it will be shipping with the latest versions of Webpack, React, and Babel, thereby speeding up times across the board.

[brigand]

I created the project with the gatsby cli, wrote three markdown pages with no images, and then tried a build. So my best guess is that gatsby-advanced-starter is pulling in a lot of stuff. It seems to have many features.

Thanks for the clarification and your build times. Quite a difference objectively, but 80 seconds vs 159 seconds both fall in the "slow-ish" category, so optimizing down to that point isn't super valuable.

I'll stick with my current setup for this project, and try out 2.0 when it's released.

[benjaminhoffman]

Super bummed that this is the sticking point for you. Is the build time of three minutes really something causing you to avoid using Gatsby... even knowing that the end user experience will likely improve drastically? How often do you even need to run gatsby build? I'm running gatsby develop about 80% of the time and use build only when I want to see what the prod output would be.

[jquense]

I'd say there is something iffy with the starter I've never had a gatsby project take that long to build, heck even the example instragram clone site is faster than that :/

[brigand]

By my current setup, I mean my gatsby site with the slow build. It's not an issue, I just wasn't sure if I was doing things correctly. I'm sorry I didn't express that clearly. Thanks for the great project!

[gregorskii]

It is actually quite a pain when you are debugging SSR issues.

:/

[brigand]

I ended up switching to a different base project, and now the build times are around 20 seconds (pretty small site).

@gregorskii For debugging server rendering, maybe reduce the number of pages it's rendering to just enough to reproduce the issue and disable uglify.

[benjaminhoffman]

@brigand do you have instructions on how to implement both of those tips? Sounds like very useful hacks I could use.

[arnondora]

My site has more than 200 pages, build time is around 300-350 second. In develop environment, I just pick a bunch of article and sperated to use only in development purpose, this help me a lot in managing my memory and the time of rebuild the project when edit the code.

[ygspasov]

I'm having troubles with the build too. It has been running for half an hour already and is stuck on "createPagesStatefully". I have no idea what is causing this.

[m-allanson]

There was a recent bug that caused the “createPagesStatefully” problem. Update to the latest version to fix it.

On 4 Feb 2018, 09:58 +0000, Yavor Spassov [e-mail], wrote:

I'm having troubles with the build too. It has been running for half an hour already and is stuck on "createPagesStatefully". I have no idea what is causing this.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[ygspasov]

m-allanson, I updated to the latest version but now the build fails with the following errors:

error Building static HTML for pages failed

See our docs page on debugging HTML builds for help https://goo.gl/yL9lND

29 | var useElement = element;
30 | if (typeof useElement === "string") {

31 | var el = document.querySelectorAll(useElement);
| ^
32 | assertNodeList(el, useElement);
33 | useElement = "length" in el ? el[0] : el;
34 | }

WebpackError: document is not defined

What can I do about it?

[m-allanson]

@ygspasov It looks like you're using document, which doesn't exist at build time.

If it's part of a React component, you can put it in a componentDidMount method. Otherwise you can do a check like:

if (typeof document !== `undefined`) {
  ...your code here
}

Have a look at the mentioned docs page: https://www.gatsbyjs.org/docs/debugging-html-builds/

[TimNZ]

I'm using https://github.com/AustinGreen/gatsby-starter-netlify-cms, all content local, 3 pages, and build time is 60 seconds.
Updated all packages to the latest.

Definitely very slow.

Mostly the JS bundle build.

I have been doubly spoiled by the speed of Parcel Bundler.

success delete html and css files from previous builds — 0.034 s
success open and validate gatsby-config.js — 0.006 s
info One or more of your plugins have changed since the last time you ran Gatsby. As
a precaution, we're deleting your site's cache to ensure there's not any stale
data
success copy gatsby files — 0.018 s
success onPreBootstrap — 0.834 s
success source and transform nodes — 0.134 s
success building schema — 0.225 s
success createLayouts — 0.009 s
success createPages — 0.051 s
success createPagesStatefully — 0.019 s
success onPreExtractQueries — 0.001 s
success update schema — 0.136 s
success extract queries from components — 0.111 s
success run graphql queries — 0.115 s
success write out page data — 0.004 s
success write out redirect data — 0.001 s
success onPostBootstrap — 0.001 s

info bootstrap finished - 4.033 s

success Building CSS — 8.980 s
success Building production JavaScript bundles — 43.632 s
success Building static HTML for pages — 3.937 s
info Done building in 60.587 sec

[CanRau]

just a note, maybe it helps someone updating my ram helped a lot, more details in https://github.com/gatsbyjs/gatsby/issues/2190#issuecomment-380681918

[dandv]

I'm on Gatsby 2.18.8, and building a very simple site takes 3 minutes on a VPS with 2GB RAM.

The build process stays stuck at this step for 2 minutes:

The last lines of the output are:

success Build manifest and related icons - 9.118s
success onPostBootstrap - 9.139s
⠀
info bootstrap finished - 69.210 s
⠀
success Building production JavaScript and CSS bundles - 102.993s
success Rewriting compilation hashes - 0.068s
success run queries - 104.050s - 3/3 0.03/s
success Building static HTML for pages - 12.770s - 6/6 0.47/s
info Generated public/sw.js, which will precache 12 files, totaling 404375 bytes.
The following pages will be precached:
/offline-plugin-app-shell-fallback/index.html
/about/index.html
/blog/index.html
info Done building in 186.735163138 sec

[hqman]

success Re-building development bundle - 5.409s

[dandv]

If you want fast builds, turns out you need the newly announced Gatsby builds, part of the commercial Gatsby Cloud offering.

[KyleAMathews]

@dandv hey, could you post your site over in this issue? We've been collecting examples of sites there that have slower than expected build times and we'd love to see what's going on with your site.
https://github.com/gatsbyjs/gatsby/issues/19512

[pvdz]

@dandv hm, no, this kind of thing is not why you move to Gatsby Builds. Can you please open a new issue for your example and assign it to me? If you can offer me a repo with a repro (something that gatsby builds) I can have a look. (Note that "run queries" can be a little misleading. For example, when paginating multiple pages per output page it might still report a single query. So 3 queries and 6 pages may still be processing 300 pages under the hood if each generated page contains 50 pages. Have to see config to triage further.)

[pvdz]

For future reference, if you stumble upon this issue because you are experiencing "slow builds", please open a separate ticket and assign it to me. A repro repo, preferably minimal repro, is your fastest ticket to triage. I'm going to lock this ticket.