Reduce Gatsby framework blocking time

[tlgimenes]

Description

Hello people.

I'm developing an e-commerce using Gatsby and Theme-ui and I'm loving it. In the e-commerce world, performance is a must and Gatsby really shines in this regard. Our pages load instantly and navigation is pretty smooth too. However, since Google will soon use Web Vitals score in their search engine ranking system, our market is more and more paying attention to Web Vitals and Lighthouse.

Since Lighthouse V6, I'm noticing there is one metric that I've never really been able to get on the green spectrum of force, specially on Google's PSI. This metric is the Total Blocking Time (TBT)

After a quick search on Gatsby's issues, I've came across issue #24332 where many people report having similar issues with Lighthouse V6. After spending many hours studying the problem I've decided to make a contribution to the community via this PR.
As a test subject, I've chosen ReactJS.org website (that is built using Gatsby) and the method I'm using is Google Chrome's DevTools performance tab for comparing blocking times.

After cloning both gatsbyjs and reactjs.org website and setting up the dev environment correctly, I've run a profiling test with Chrome's performance tab locally with 6x CPU slowdown on a Fast 3G internet connection. The result can be seem in the image below.

As you can see, the blocking time is considerable. By studying the problem, I've found 3 main sources for this gigantic blocking time. The first one is the one with the arrow pointing to. This is React's hydrate function and there isn't much what Gatsby can do to fix this, however React's new concurrent mode should address this soon.
The second big blocking time is the one on the left of React's hydrate function. This is reactjs.org's own code being evaluated, and here again, there is not much what Gatsby can do to improve this blocking time.
The third source, and the most interesting one, is on the left of the later. A closer inspection reveals the following flame chart

As you can see, this is Gatsby's own code + plugins being evaluated, which, in this case, accounts for 195ms of blocking time.
This happens because production-app.js is the app's main entrypoint and requires synchronously (via the import foo from 'bar' construction) all of the framework's + plugins code.

To address the aforementioned problem I hand crafted a method for splitting all production-app.js dependencies evaluation into small tasks so the Gatsby framework does not generate unnecessary blocking times. This method is different from webpack's dynamic import() statement since we don't split the app.js bundle into different file, but rather split the evaluation of app.js file into multiple tasks. The image below show the evaluation of prodution-app.js after the changes included on this PR

As you can see, production-app.js evaluation is now split into multiple different tasks, greatly reducing the blocking time introduced by Gatsby.

I would love to hear your thoughts on this PR and how we could test this on Google's PSI on various websites (maybe releasing a canary) and even if this PR makes sense or if there is a webpack magic that we could use in here.

Thanks !

Documentation

Related Issues

Addresses #24332

[KyleAMathews]

Very cool idea! There are expensive plugins as well so this would help alleviate that.

I published a canary named runtime-tick so we can test performance in the wild.

[KyleAMathews]

Hmm wow, this looks promising. My blog https://www.bricolage.io/ jumped from 92 to 100 on performance

• https://www.webpagetest.org/result/210221_DiHP_a882b767d3ead35d593e4e6edb4af257/
• https://www.webpagetest.org/result/210221_DiW3_eb036377306a0b00ab83c435ade53e4d/

[KyleAMathews]

My blog is a little too simple/fast & the numbers are too close to be sure but it does seem to be improving LCP as well which makes sense as the long sync calls setting up the app + plugins would block rendering as well since it's all on the same thread.

Gotta test on more sites.

[KyleAMathews]

I generally trust webpagetest.org the most as it uses real phones, etc. but tried Google PageSpeed and it showed the same trend — TBT dropped in 1/2 from 200ms to 100ms

• https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fbuild-4543c91c-6d32-4b4f-a846-96606676d86a.gtsb.io%2F
• https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fbuild-ea72903a-8f54-436b-827f-282ffb599b4a.gtsb.io%2F

[tlgimenes]

Cool @KyleAMathews !

I've just made some previews of my Gatsby websites using this @runtime-tick version and tested on PSI. I've seen some 80-100ms decrease on total blocking time 🎉

The previews:
master: https://btglobal.vtex.app/
runtime-ticks: https://preview-246--btglobal.vtex.app/

master: https://marinbrasil.vtex.app/
runtime-ticks: https://preview-390--marinbrasil.vtex.app/

[KyleAMathews]

Run on webpagetest and lighthouse performance jumped 12 points from 65->77

• https://www.webpagetest.org/result/210221_DiF3_4279d6b85e96ad804a82ccf2beefc5f7/
• https://www.webpagetest.org/result/210221_DiH2_aa7b3827eef8a55dbec1987aab976e27/

The TBT reported by webpagetest (instead of lighthouse) isn't as clear cut as there are runs of runtime-tick w/ longer TBT.

master	runtime-tick
246	376
249	464
410	296
404	270
1616	436
413	265

[KyleAMathews]

Tested it on gatsbyjs.com and TBT is down ~150-300ms & Lighthouse score jumps maybe a few points

[ViktorMeduneckij]

Any updates on this?

[tlgimenes]

Hey guys, after watching this video I decided to rename next-tick to zero-timeout to avoid eventual confusion between tasks and nanotasks. Also, I've just rebased with the master branch.

If you guys need anything else, please let me know asap. I'd really like to push this forward :) Thanks !

[7iomka]

Hey guys, after watching this video I decided to rename next-tick to zero-timeout to avoid eventual confusion between tasks and nanotasks. Also, I've just rebased with the master branch.

If you guys need anything else, please let me know asap. I'd really like to push this forward :) Thanks !

Hi
Tell me please how to install your gatsby version from github?
I'm tried "gatsby": "git://github.com/tlgimenes/gatsby.git#improve/production-app-blocking-time"
but I have error:

npm ERR! Can't install git://github.com/tlgimenes/gatsby.git#a11136d6c5050b464a822d83fc87aea718aea42b: Missing package name

[tlgimenes]

Hi @7iomka.

I usually do local testing by cloning gatsby's monorepo and using gatsby-dev-cli. However, if you want to do a quick test, you can try:

yarn add gatsby@runtime-tick

Just note this is an old version prior to my rebase.

[tlgimenes]

Hi @KyleAMathews, can you re-release a runtime-tick version with my new changes after the rebase so people can test it with gatsby v3?

Also, let me know if there is anything I can do to help.

Thanks :)

[dora1998]

Thank you for your awesome PR.
I'm not a Gatsby commiter, but I have a little questions and suggestions.

I think that message event listener should be removed when all tasks complete.
Next, you can also use setTimeout because HTML Standard says setTimeout(func, 0) is not delayed if nesting level is less than or equal to 5, I wonder what is the advantage of postMessage. I feel that setTimeout is more intuitive.
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers

Also, taking advantage of JS thread-loop, you can also write setTimeout flat.

setTimeout(() => {
  require("react-dom")
}, 0)

setTimeout(() => {
  require(`@reach/router`)
  require(`@mikaelkristiansson/domready`)
  require(`gatsby-react-router-scroll`)
}), 0)

setTimeout(() => {
  require(`gatsby`)
}, 0)

setTimeout(() => {
  const plugins = require(`../api-runner-browser-plugins`)

  // Evaluate each plugin on its own task
  return Promise.all(plugins.map(plugin => nextTickAsync(plugin.plugin)))
}, 0)

setTimeout(() => {
  require("./app")
}, 0)

[wardpeet]

@dora1998 You have different ways to delay something in Javascript.

• Nanotasks
• Microtasks
• Task

setTimeout schedules a task, but you don't really know when it's going to fire. Most of the time, it's going to be the next task, but it could also have a delay. The channel approach gives you a consistent way of scheduling tasks. (more info here: https://youtu.be/8eHInw9_U8k?t=381)

@tlgimenes The idea behind this is awesome! I'm not super fond of the restructuring of production-app.js as I find it harder to reason with. I'll change the code a little bit to keep the old structure but keep the same benefits with some webpack import magic. I'll schedule it somewhere this week to publish a canary and get this merged for our next release.

I want to say super nice work on discovering it and making this a reality! 👏 👏

[tlgimenes]

Thanks @wardpeet !

setTimeout may be misleading and using postMessage seems to be more reliable since we don't need to pay attention if we are 6 levels deep etc. However I agree with @dora1998 that we shouldn't leave a postMessage channel opened.

Anyways, thanks for taking a look into it @wardpeet, hope we can roll this out soon. I'm really excited for the results! Also, feel free to close this PR if you prefer opening a new one :)

Also, I saw another opportunity for reducing blocking time in prefetch logic too. I'll hope to open another PR soon :)

Thanks!

[emersonlaurentino]

Any news about it?

[tlgimenes]

Hey, so for those waiting for some news. I created a plugin gathering this and other performance optimizations. You can take a look at here:
https://github.com/vtex/faststore/tree/master/packages/gatsby-plugin-performance

[wardpeet]

@tlgimenes Thank you so much for opening this PR! I've slowly been looking at the implementation details and trying to figure out a technical way forward.

It's more or less moving things out of the critical path and trying to load pieces more lazily. It's not a small piece to get this right. I do want to give you credits for your hard work and insights on this matte. I'll be marking this as a draft until I got some time to work on it.

[tlgimenes]

Thanks @wardpeet!

I'm really happy to know you are working on this. I agree with your approach of a webpack config. However, I have no ideia how to do it, haha.

I've just created the plugin so I can use/test this optimization in my sites and see any possible drawbacks without having to fork Gatsby all along.

I'm really looking forward to see the improvements on this optimization. Thanks again!

[alextercete]

@wardpeet Sorry to revive this old thread, but is there an update on this? I'm willing to contribute to getting this over the line, if there's anything I can do to help.

[cameronbraid]

Closed ? I am sure other people, just like myself, have been watching this thread. Is there a reason why this is closed ? Have the same improvements been done in another PR ?

[tlgimenes]

Hi @cameronbraid.

I decided to close this PR because it took a long time to review and new majors were released in the meanwhile. I guess this technique should still be usefull on current versions, but a new study should be performed. I'm not working with gatsby anymore so feel free to open a new PR :)

thanks!