Lazy Development JS bundling

[KyleAMathews]

Update

After extensive testing, we've decided to not go ahead with with this experimental feature. See #28137 (comment) for more details.

Huge thanks to everyone who helped test & discuss.

---

This is an umbrella issue for discussing the new feature for lazy JS bundling in development. The initial PR dropped times for bundling by up to 80% on some sites (with possible future improvements that can be made as well). Sites with less JS won't see as dramatic of improvement but all sites will benefit.

How to test & help out

Try out the feature on your site by running gatsby develop with the feature enabled GATSBY_EXPERIMENTAL_LAZY_DEVJS=true gatsby develop

Report any errors or other problems you might see. Also how does it feel clicking around the site? This change will make it slower the first time you visit a page as it compiles each page's code on demand.

We'd love also for you to report on how much this improves times for your site.

To make the comparison, run develop on your site with and without this feature running gatsby clean before each run.

# run 1
gatsby clean
gatsby develop // Make note of the "Building development bundle" time

# run 2
gatsby clean
GATSBY_EXPERIMENTAL_LAZY_DEVJS=true gatsby develop // Again note the time.

[svirins-zz]

Hi! in my case, running with Lazy Development flags provides no visible benefits. My codebase is ~6000 lines. TypeScript.

[KyleAMathews]

hi, what was the times for the runs? Is your site open source (or otherwise available for me to look at?)

[KyleAMathews]

thanks for testing & reporting!

[svirins-zz]

sure, it's my pet project. will get everything polished in a few days and share a link

[svirins-zz]

Wow! now, it works!

-run 1
info bootstrap finished - 109.068s
success Building development bundle - 33.433s

-run 2
info bootstrap finished - 122.037s
success Building development bundle - 7.961s

[KyleAMathews]

nice!

[Pearce-Ropion]

This is great! Our site is pretty big (~117k lines of js) and our development build averages 260s - 300s

Without GATSBY_EXPERIMENTAL_LAZY_DEVJS
success Building development bundle - 296.947s

With GATSBY_EXPERIMENTAL_LAZY_DEVJS
success Building development bundle - 131.494s

[KyleAMathews]

very nice! What is the experience like clicking around the site? How long do you wait now to visit the next page? That's the main tradeoff with this approach — by not compiling all pages upfront, it's slower to click around. This is the main thing we want to validate before enabling this for everyone — that the tradeoff isn't too painful.

Also if you'd like to test out some other related changes on your site, you can test those with GATSBY_EXPERIMENTAL_FAST_DEV=true gatsby develop

[Pearce-Ropion]

Hmm, definitely slower on page load. When does it make the decision to build the next page?
Is it when you click on page link? Or when you hover over a page link?

The reason I ask is after it built the homepage, I noticed it started a re-build that took 57s which seemed to bundle the rest of pages that are linked to from our navbar. After that, any page that I clicked on from the navbar did not trigger a build. Other pages that were linked to from within the page's body/footer took between 2.5 - 5s to build.

I noticed that it hadn't even built the homepage. Would it be possible to specify some pages that will always generate during the initial bundle generation?

I also had this error spamming my console. This was when I first loaded the homepage (which has a link to the FAQ in the navbar) and when I manually visited the /faq page. It disappeared after I had visited a few more pages then went back the the /faq page.

home/propion/Projects/Bifrost/bifrost/frontend/.cache/ensure-page-component-in-bundle.js:35 Uncaught (in promise) Loading the page component component---src-pages-faq-js timed out after 5 seconds

Also regarding this error, the message says 5 seconds but the code actually times out after 10 seconds.

Could you also explain what GATSBY_EXPERIMENTAL_FAST_DEV does?

[KyleAMathews]

When does it make the decision to build the next page?

On hover

I noticed it started a re-build that took 57s which seemed to bundle the rest of pages that are linked to from our navbar

hmm that's unexpected — maybe we should only build on clicking as 57s is a long time to wait

Would it be possible to specify some pages that will always generate during the initial bundle generation?

Yeah, we're thinking about always building the home page + tracking which other pages you typically go to & then lazily building those in the background.

I also had this error spamming my console

gah, lemme remove that. It's not very useful in retrospect.

Could you also explain what GATSBY_EXPERIMENTAL_FAST_DEV does?

We're working on a few changes to speed up local dev. This flag enables lazy bundling + query on demand (so don't run queries until they're needed) + SSR in development (make it easier to detect & fix SSR related problems). You can enable them one-by-one but we wanted an easier way for us and others to test them together.

[Pearce-Ropion]

When does it make the decision to build the next page?

On hover

I noticed it started a re-build that took 57s which seemed to bundle the rest of pages that are linked to from our navbar

hmm that's unexpected — maybe we should only build on clicking as 57s is a long time to wait

Yea, maybe this is specific to my site, but I can easily mouseover over 10 links in a second on either my navbar or footer. I feel like using onClick would be better when using the LAZY_DEV flag as you are probably only interested in working on a couple of pages at a time.

[KyleAMathews]

👍 yeah — for cheap operations onHover speeds things up by a few 100ms so that's great but if it's more expensive like this — onClick is better as otherwise it's easy to block yourself by triggering a bunch of unnecessary operations.

[zslabs]

👋 Thanks for creating this - really excited to see where this lands! Sharing my experience before/after.

Both bootup time and clicking between pages showed regressions, but happy to help provide any more context.

TLDR (boot time)

Before: 96.657s
After: 100.425s

Navigation

Before: Near instantaneous
After: 6.533s

Before

Cold-start

  System:
    OS: macOS 10.15.7
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Shell: 3.0.0 - /usr/local/bin/fish
  Binaries:
    Node: 12.19.0 - /usr/local/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 6.14.8 - ~/.npm-packages/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 87.0.4280.67
    Edge: 87.0.664.41
    Firefox: 82.0.3
    Safari: 14.0.1
  npmPackages:
    gatsby: 2.26.1 => 2.26.1
    gatsby-plugin-compile-es6-packages: 2.1.0 => 2.1.0
    gatsby-plugin-feed: 2.7.0 => 2.7.0
    gatsby-plugin-google-tagmanager: 2.5.0 => 2.5.0
    gatsby-plugin-launchdarkly: 0.3.2 => 0.3.2
    gatsby-plugin-manifest: 2.6.1 => 2.6.1
    gatsby-plugin-mdx: 1.4.0 => 1.4.0
    gatsby-plugin-mdx-embed: 0.0.14 => 0.0.14
    gatsby-plugin-mdx-frontmatter: 0.0.2 => 0.0.2
    gatsby-plugin-netlify: 2.5.0 => 2.5.0
    gatsby-plugin-netlify-cms: 4.4.0 => 4.4.0
    gatsby-plugin-react-helmet: 3.4.0 => 3.4.0
    gatsby-plugin-react-helmet-canonical-urls: 1.4.0 => 1.4.0
    gatsby-plugin-segment-js: 3.6.0 => 3.6.0
    gatsby-plugin-sitemap: 2.6.0 => 2.6.0
    gatsby-plugin-svgr: 2.0.2 => 2.0.2
    gatsby-plugin-webpack-bundle-analyser-v2: 1.1.16 => 1.1.16
    gatsby-source-filesystem: 2.5.0 => 2.5.0
  npmGlobalPackages:
    gatsby-cli: 2.12.117

success open and validate gatsby-configs - 0.185s
success load plugins - 2.222s
success onPreInit - 0.054s
success initialize cache - 0.006s
success copy gatsby files - 0.036s
success onPreBootstrap - 0.021s
success createSchemaCustomization - 0.008s
success Checking for changed pages - 0.001s
success source and transform nodes - 17.946s
success building schema - 0.726s
info Total nodes: 2108, SitePage nodes: 408 (use --verbose for breakdown)
success createPages - 57.768s
success Checking for changed pages - 0.000s
success createPagesStatefully - 0.318s
success update schema - 0.206s
success write out redirect data - 0.001s
success Build manifest and related icons - 0.081s
success onPostBootstrap - 0.083s
info bootstrap finished - 81.799s
success onPreExtractQueries - 0.001s
success extract queries from components - 1.201s
success write out requires - 0.011s
success run static queries - 0.323s - 19/19 58.80/s
success run page queries - 15.199s - 455/455 29.94/s
info [HPM] Proxy created: /  -> http://localhost:9000
info [HPM] Proxy rewrite rule created: "/.netlify/functions/" ~> ""
success Building development bundle - 96.657s

After

Cold-start. Removed yarn.lock and node_modules/

  System:
    OS: macOS 10.15.7
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Shell: 3.0.0 - /usr/local/bin/fish
  Binaries:
    Node: 12.19.0 - /usr/local/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 6.14.8 - ~/.npm-packages/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 87.0.4280.67
    Edge: 87.0.664.41
    Firefox: 82.0.3
    Safari: 14.0.1
  npmPackages:
    gatsby: 2.27.0 => 2.27.0
    gatsby-plugin-compile-es6-packages: 2.1.0 => 2.1.0
    gatsby-plugin-feed: 2.8.0 => 2.8.0
    gatsby-plugin-google-tagmanager: 2.6.0 => 2.6.0
    gatsby-plugin-launchdarkly: 0.3.2 => 0.3.2
    gatsby-plugin-manifest: 2.7.0 => 2.7.0
    gatsby-plugin-mdx: 1.5.0 => 1.5.0
    gatsby-plugin-mdx-embed: 0.0.14 => 0.0.14
    gatsby-plugin-mdx-frontmatter: 0.0.2 => 0.0.2
    gatsby-plugin-netlify: 2.6.0 => 2.6.0
    gatsby-plugin-netlify-cms: 4.5.0 => 4.5.0
    gatsby-plugin-react-helmet: 3.5.0 => 3.5.0
    gatsby-plugin-react-helmet-canonical-urls: 1.4.0 => 1.4.0
    gatsby-plugin-segment-js: 3.6.0 => 3.6.0
    gatsby-plugin-sitemap: 2.7.0 => 2.7.0
    gatsby-plugin-svgr: 2.0.2 => 2.0.2
    gatsby-plugin-webpack-bundle-analyser-v2: 1.1.17 => 1.1.17
    gatsby-source-filesystem: 2.6.1 => 2.6.1
  npmGlobalPackages:
    gatsby-cli: 2.12.117

[1] Three fast dev experiments are enabled, Lazy Bundling, Query on Demand, and Development SSR.
[1]
[1] Please give feedback on their respective umbrella issues!
[1]
[1] - https://gatsby.dev/lazy-devjs-umbrella
[1] - https://gatsby.dev/query-on-demand-feedback
[1] - https://gatsby.dev/dev-ssr-feedback
[1]
success open and validate gatsby-configs - 0.213s
success load plugins - 1.911s
success onPreInit - 0.079s
success initialize cache - 0.007s
success copy gatsby files - 0.040s
success onPreBootstrap - 0.020s
success createSchemaCustomization - 0.006s
success Checking for changed pages - 0.000s
success source and transform nodes - 19.651s
success building schema - 0.816s
info Total nodes: 2108, SitePage nodes: 408 (use --verbose for breakdown)
success createPages - 61.784s
success Checking for changed pages - 0.000s
success createPagesStatefully - 0.330s
success update schema - 0.202s
success write out redirect data - 0.001s
success Build manifest and related icons - 0.077s
success onPostBootstrap - 0.079s
info bootstrap finished - 87.191s
success onPreExtractQueries - 0.001s
success extract queries from components - 1.281s
success write out requires - 0.012s
success run static queries - 0.315s - 19/19 60.24/s
success run page queries - 0.038s - 2/2 52.96/s
info [HPM] Proxy created: /  -> http://localhost:9000
info [HPM] Proxy rewrite rule created: "/.netlify/functions/" ~> ""
success Building development bundle - 100.425s
success onPreExtractQueries - 0.002s
success extract queries from components - 0.312s
success write out requires - 0.003s
success run page queries - 0.280s - 1/1 3.58/s

Clicking a link took about 6 seconds to generate/change:

success onPreExtractQueries - 0.018s
success extract queries from components - 3.009s
success write out requires - 0.002s
success Re-building development bundle - 6.533s

[KyleAMathews]

huh interesting. Would it be possible to get direct access to your site's code so I could play with some options?

Could you try running it with just GATSBY_EXPERIMENTAL_LAZY_DEVJS=true? FAST_DEV currently makes generating your dev bundle a bit slower (until this PR is published (in an hour or so) #28149).

[KyleAMathews]

We're looking into some ways of speeding up the lazy compiling of pages e.g. predicting which pages you'll visit and using quiet time while you're working on a page to bundle other pages.

Also extract queries from components can be made a lot less expensive.

[KyleAMathews]

Also when you are testing w/ FAST_DEV — running gatsby develop --verbose gives you a running time since start that lets you compare the total time taken more directly. E.g. your second run looks like it saved ~15 seconds from not running all queries upfront.

[zslabs]

👋 @KyleAMathews Sorry for the delay, an invite was sent your way to the repo. Thanks again!

[zslabs]

@KyleAMathews Thanks for the response! I've included what I saw with the flag changes below. I've also reached out to our security team about providing you access to the repo and will follow-up with that shortly.

One item to note is that this line:

verbose 97.306271503 Warning: lock file older than 10s, ignoring it... There is a possibility this leads to caching problems later.

showed up several dozen times while booting.

success open and validate gatsby-configs - 0.320s
success load plugins - 3.484s
success onPreInit - 0.064s
success initialize cache - 0.006s
success copy gatsby files - 0.057s
success onPreBootstrap - 0.029s
verbose 7.321865105 Transition to "initializingData"
success createSchemaCustomization - 0.009s
verbose 7.331774271 Transition to "initializingData" > "sourcingNodes"
verbose 30.460855027 Checking for deleted pages
verbose 30.461347962 Deleted 0 pages
verbose 30.461474663 Found 0 changed pages
success Checking for changed pages - 0.000s
success source and transform nodes - 23.132s
verbose 30.512764196 Transition to "initializingData" > "buildingSchema"
success building schema - 1.011s
verbose 31.54011864 Transition to "initializingData" > "creatingPages"

verbose 97.306271503 Warning: lock file older than 10s, ignoring it... There is a possibility this leads to caching problems later.
info Total nodes: 2108, SitePage nodes: 408 (use --verbose for breakdown)
verbose 102.575487008 Number of node types: 7. Nodes per type: SitePage: 408, SitePlugin: 67, Site: 1, SiteBuildMetadata: 1, Directory: 19, File: 806, Mdx: 806
success createPages - 71.098s
verbose 102.576888733 Checking for deleted pages
verbose 102.577084632 Deleted 0 pages
verbose 102.578425231 Found 407 changed pages
success Checking for changed pages - 0.001s
verbose 102.584881707 Transition to "initializingData" > "creatingPagesStatefully"
success createPagesStatefully - 0.405s
verbose 103.021081095 Transition to "initializingData" > "rebuildingSchemaWithSitePage"
success update schema - 0.252s
verbose 103.244019294 Transition to "initializingData" > "writingOutRedirects"
success write out redirect data - 0.001s
verbose 103.2454901 Transition to "initializingData" > "done"
verbose 103.247671694 Transition to "runningPostBootstrap"
success Build manifest and related icons - 0.109s
success onPostBootstrap - 0.112s
info bootstrap finished - 103.360s
verbose 103.377670274 Transition to "runningQueries"
success onPreExtractQueries - 0.001s
success extract queries from components - 1.618s
verbose 105.015699347 Transition to "runningQueries" > "waitingPendingQueries"
verbose 105.073869115 Transition to "runningQueries" > "writingRequires"
success write out requires - 0.015s
verbose 105.082372091 Transition to "runningQueries" > "calculatingDirtyQueries"
verbose 105.084886654 Transition to "runningQueries" > "runningStaticQueries"
success run static queries - 0.350s - 19/19 54.25/s
verbose 105.517394089 Transition to "runningQueries" > "runningPageQueries"
success run page queries - 22.353s - 455/455 20.36/s
verbose 127.789649677 Transition to "runningQueries" > "waitingForJobs"
verbose 127.78992466 Transition to "runningQueries" > "done"
verbose 127.793857406 Transition to "startingDevServers"
info [HPM] Proxy created: /  -> http://localhost:9000
info [HPM] Proxy rewrite rule created: "/.netlify/functions/" ~> ""
success Building development bundle - 59.932s
verbose 187.894603855 Transition to "waiting"
error Error loading a result for the page query in "index" / "/". Query was not run and no cached result was found. ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gatsby/public/page-data/index/page-data.json'

[1]
[1]   Error: ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gats  by/public/page-data/index/page-data.json'
[1]
error Error loading a result for the page query in "dev-404-page" / "dev-404-page". Query was not run and no cached result was found. ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gatsby/public/page-data/dev-404-page/page-data.json'

[1]
[1]   Error: ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gats  by/public/page-data/dev-404-page/page-data.json'
[1]
error Error loading a result for the page query in "404.html" / "404.html". Query was not run and no cached result was found. ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gatsby/public/page-data/404.html/page-data.json'

[1]
[1]   Error: ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gats  by/public/page-data/404.html/page-data.json'
[1]
error Error loading a result for the page query in "dev-404-page" / "dev-404-page". Query was not run and no cached result was found. ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gatsby/public/page-data/dev-404-page/page-data.json'

[1]
[1]   Error: ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gats  by/public/page-data/dev-404-page/page-data.json'
[1]
error Error loading a result for the page query in "404.html" / "404.html". Query was not run and no cached result was found. ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gatsby/public/page-data/404.html/page-data.json'

[1]
[1]   Error: ENOENT: no such file or directory, open '/Users/zach/Sites/gremlin-gats  by/public/page-data/404.html/page-data.json'
[1]

verbose 225.721320981 Webpack file changed: /Users/zach/Sites/gremlin-gatsby/.cache/_this_is_virtual_fs_path_/$virtual/lazy-client-sync-requires
verbose 225.726595002 Transition to "waiting" > "aggregatingFileChanges"
verbose 226.12628623 Transition to "runningQueries"
success onPreExtractQueries - 0.027s
success extract queries from components - 0.305s
verbose 226.460629295 Transition to "runningQueries" > "waitingPendingQueries"
verbose 226.806126413 Transition to "runningQueries" > "writingRequires"
success write out requires - 0.002s
verbose 226.808417434 Transition to "runningQueries" > "calculatingDirtyQueries"
verbose 226.808920072 Transition to "runningQueries" > "runningStaticQueries"
verbose 226.809231396 Transition to "runningQueries" > "runningPageQueries"
verbose 226.809906327 Transition to "runningQueries" > "waitingForJobs"
verbose 226.810181434 Transition to "runningQueries" > "done"
verbose 226.813975508 Transition to "recompiling"

[KyleAMathews]

createPages - 71.098s 😬 — MDX is pretty slow here it seems

[zslabs]

Indeed :( Running the latest gatsby 2.27.3 here's a breakdown of how HMR is working:

success building schema - 1.979s
success createPages - 5.264s
success Checking for changed pages - 0.026s
success update schema - 0.165s
success onPreExtractQueries - 0.000s
success extract queries from components - 0.194s
success write out requires - 0.001s
success run static queries - 0.072s - 3/3 41.68/s
success run page queries - 11.712s - 227/227 19.38/s
success Re-building development bundle - 0.234s

That seems like an awful long time for a single-file. I looked into the lessBabel option within gatsby-plugin-mdx; which did decrease the boot time of source and transform nodes to 4.979s, but saves were still pretty slow.

I was hoping there was a cache-issue like what was found during https://www.youtube.com/watch?v=Nz0UXVvqP2Q but I do see the same basic principles.

[KyleAMathews]

some improvements based on today's discussions #28249

[pvdz]

One item to note is that this line: showed up several dozen times while booting.

I'll push something to prevent this from printing more than once.

[rzubrycki]

@KyleAMathews
gatsby develop = Building development bundle - 30.291s

GATSBY_EXPERIMENTAL_LAZY_DEVJS=true gatsby develop = Building development bundle - 11.783s

Open localhost = Re-building development bundle - 2.553s
Every click on link = Re-building development bundle 1s to 3 s +/-

Experience is a little bit odd to be honest, app is frozen for rebuild time.

[KyleAMathews]

Thanks for testing and reporting!

Could you describe more what you mean by the "app is frozen"? What did you try doing during those times that didn't work? Or is just the waiting to navigate that's strange?

[rzubrycki]

Yes, it is like click on the link and wait for few seconds to navigate. That's the tradeoff I assume.

[KyleAMathews]

So news — we decided this experiment isn't working out as well as we hoped. Huge thanks to everyone who's tested and given us access to your sites — that's what let us quickly make the decision.

The root problem is that for many sites, the wait to navigate between pages when you have to wait for that page to be compiled is really long — like 10s+ — which felt like an unacceptable regression from the current experience. You often want to be able to quickly click around a site and this change breaks it.

We looked into a number of workarounds but there just wasn't anything practical that we could figure out.

We also saw a few sites where compiling a page component had side effects e.g. they required CSS which they then expected to be part of the global CSS. So introducing this feature would mean some subset of people would see their dev environment work in strange ways depending on which pages they visit.

Also we have another change coming soon which seems like a better all-around solution. We're going to be revamping how caching works with Gatsby. Currently when you edit your gatsby-config/gatsby-node files or install a plugin, it deletes all your caches. Including the webpack cache. Which is way too aggressive. So we'll be shipping behind a flag soon a change to this behavior where we'll be much more selective about when we clear the webpack cache which will mean that most times you start the develop server, it'll rely on the webpack cache vs. now where it often has to recreate the same cache. That + the move to webpack 5 in Gatsby v3 (which has a much better cache) will mean that webpack's contributions to dev server starts should be tolerable.

[KyleAMathews]

We now (as of 2.28) have a new flag for preserving the webpack cache — everyone testing here will also appreciate this change — would love help testing it out!

https://github.com/gatsbyjs/gatsby/blob/master/docs/reference/release-notes/v2.28/index.md#experimental-new-cache-clearing-behaviors

[KyleAMathews]

For people looking to test additional ways to speedup starting the dev server — please try out Query on Demand! We've seen some pretty dramatic speedups for sites with it enabled — #27620 We'd love to have some more testers so we can get this polished up for a full-release.

[joshjg]

Reposting from another discussion.

Regarding lazy bundling, is it expected to work with the MDX plugin yet? Seems like the MDX plugin still eagerly builds everything when GATSBY_EXPERIMENTAL_DEVJS_LAZY is turned on.

it doesn't seem like Query on Demand helps in my case, most of my MDX files have imports using a fairly expensive webpack loader.

I was hoping for a way to defer the expensive loader until you actually visit the page.

[joshjg]

More details about my situation:
Starting the dev server takes ~5-6 minutes.

The expensive webpack loaders don't seem to be getting cached. I'm not sure yet if this is an issue with the loader, gatsby, webpack, or something else.

To make matters worse, I'm also observing that all of the MDX files are built TWICE in a row, once here:
https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/commands/build-html.ts#L182
and once on the next line.

[KyleAMathews]

is your site open source? Could you file a new issue?

[kevee]

Build time notes for covidtracking.com, website code repo is open source. Heres' the timing of Building development bundle:

Before: 64.198s
With lazy devjs: 25.526s

Clicking around the site is extremely slow, around 10-15 seconds.

[KyleAMathews]

hey @kevee — as you probably saw, we're removing this experiment due to precisely what you saw — very slow rebuild times on page components :-(

I think you'll have a better experience w/ Query On Demand & Lazy Image processing as I had a go running your site & the bits that could be most sped-up look like avoiding running queries & processing images up front #27620

[bee-san]

Hey! Sorry to butt in, I'm very new to Gatsby (literally 3 days ago I started) and very new to JS in general (I didn't even know what a component was until I had to add something to my site. I still don't know to be honest!)

And this is so big for me! Thank you for doing this

I normally make a small change, gatsby develop my site and see if it broke anything (due to my lack of knowledge, I do this so much more often than you think as I'm basically brute forcing a solution with stack overflow open).

This cuts down my build time from 78s to 30.2 seconds!! I can now, quite literally, bruteforce editing my website in half the time. Thank you, thank you, thank you!!!

One thing I'll say (that may not be obvious to others) but to run this you can use:

GATSBY_EXPERIMENTAL_LAZY_DEVJS=true gatsby develop

In the Terminal. Not sure if it's supposed to be in a settings file somewhere, but this worked great!

[zslabs]

Awesome! For the flags, in 2.28.0 you can specify them in your gatsby-config.js file which may be easier for re-use https://github.com/gatsbyjs/gatsby/blob/master/docs/reference/release-notes/v2.28/index.md#feature-flags-in-gatsby-config

[KyleAMathews]

hey sorry to be the bearer of bad news but we decided not to go ahead with this feature — see #28137 (comment)

What you can try instead (also released in 2.28) is https://github.com/gatsbyjs/gatsby/blob/master/docs/reference/release-notes/v2.28/index.md#experimental-new-cache-clearing-behaviors which should have the same effect of keeping build times down. Let us know it goes!

[alexfornuto]

@KyleAMathews the second link is currently a 404, can we get a fresh link?

[KyleAMathews]

https://github.com/gatsbyjs/gatsby/blob/master/docs/docs/reference/release-notes/v2.28/index.md#removed-experimental-lazy-page-bundling