Lazy Development JS bundling #28137
Replies: 12 comments 26 replies
-
|
Hi! in my case, running with Lazy Development flags provides no visible benefits. My codebase is ~6000 lines. TypeScript. |
Beta Was this translation helpful? Give feedback.
-
|
hi, what was the times for the runs? Is your site open source (or otherwise available for me to look at?) |
Beta Was this translation helpful? Give feedback.
-
|
thanks for testing & reporting! |
Beta Was this translation helpful? Give feedback.
-
|
sure, it's my pet project. will get everything polished in a few days and share a link |
Beta Was this translation helpful? Give feedback.
-
|
Wow! now, it works! -run 1 -run 2 |
Beta Was this translation helpful? Give feedback.
-
|
nice! |
Beta Was this translation helpful? Give feedback.
-
|
This is great! Our site is pretty big (~117k lines of js) and our development build averages 260s - 300s |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, definitely slower on page load. When does it make the decision to build the next page? 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. Also regarding this error, the message says Could you also explain what |
Beta Was this translation helpful? Give feedback.
-
On hover
hmm that's unexpected — maybe we should only build on clicking as 57s is a long time to wait
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.
gah, lemme remove that. It's not very useful in retrospect.
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
👍 yeah — for cheap operations |
Beta Was this translation helpful? Give feedback.
-
|
👋 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.657sAfter: 100.425s NavigationBefore: Near instantaneousAfter: 6.533s BeforeCold-start AfterCold-start. Removed Clicking a link took about 6 seconds to generate/change: |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Also when you are testing w/ |
Beta Was this translation helpful? Give feedback.
-
|
👋 @KyleAMathews Sorry for the delay, an invite was sent your way to the repo. Thanks again! |
Beta Was this translation helpful? Give feedback.
-
|
@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: showed up several dozen times while booting. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Indeed :( Running the latest That seems like an awful long time for a single-file. I looked into the 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. |
Beta Was this translation helpful? Give feedback.
-
|
some improvements based on today's discussions #28249 |
Beta Was this translation helpful? Give feedback.
-
I'll push something to prevent this from printing more than once. |
Beta Was this translation helpful? Give feedback.
-
|
@KyleAMathews GATSBY_EXPERIMENTAL_LAZY_DEVJS=true gatsby develop = Building development bundle - 11.783s Open localhost = Re-building development bundle - 2.553s Experience is a little bit odd to be honest, app is frozen for rebuild time. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it is like click on the link and wait for few seconds to navigate. That's the tradeoff I assume. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Reposting from another discussion.
I was hoping for a way to defer the expensive loader until you actually visit the page. |
Beta Was this translation helpful? Give feedback.
-
|
More details about my situation: 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: |
Beta Was this translation helpful? Give feedback.
-
|
is your site open source? Could you file a new issue? |
Beta Was this translation helpful? Give feedback.
-
|
Build time notes for covidtracking.com, website code repo is open source. Heres' the timing of Before: 64.198s Clicking around the site is extremely slow, around 10-15 seconds. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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, 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: In the Terminal. Not sure if it's supposed to be in a settings file somewhere, but this worked great! |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! For the flags, in |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
@KyleAMathews the second link is currently a 404, can we get a fresh link? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
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 developwith the feature enabledGATSBY_EXPERIMENTAL_LAZY_DEVJS=true gatsby developReport 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 cleanbefore each run.Beta Was this translation helpful? Give feedback.
All reactions