High 'Total Blocking Time' In Lighthouse

[3200creative]

When using theme-ui I've noticed that the 'Total Blocking Time' is significantly increased. Primarily on mobile. This causes a lower Lighthouse score. I haven't experienced this using other styling methods (CSS, SASS)

Example: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Ftheme-ui.com%2Fhome

I searched pretty extensively and haven't been able to locate any sites using theme-ui that don't experience this degradation in pagespeed.

[jxnblk]

I suspect this is due to the blocking script in the Gatsby plugin to set color mode before the page renders, but that shouldn't cause a significant issue. You can use Theme UI without the Gatsby plugin if you'd prefer to keep the FOUC behavior when using color modes in your site

[kenny-loveholidays]

We've noticed similar issues too. Especially since lighthouse v6 puts more emphasis on total blocking time.
See this preactjs/preact#2531 (comment) for some experiments done on comparing theme-ui vs emotion only vs no theme-ui and no emotion

[3200creative]

Thanks for the link! That further confirms what I'm experiencing.

@jxnblk What are your thoughts on this additional information?

[3200creative]

@jxnblk, this may help with the issue:

I'm building my site over the next few weeks and currently it has a very simple homepage. I was happy to see that with Theme-UI it gets 100/100 in lighthouse.

Lighthouse:

The same content in PageSpeed does significantly worse. Hopefully this helps narrow down a solution. I'm guessing the PageSpeed simulation of a throttled network connection is causing the drop in score.

PageSpeed:

[tlgimenes]

I was having the same problem @3200creative.

I've managed to reduce TBT by removing all theme merges and pre-optmizing the theme. I explain the problem in greater detail in here

Me and my team are currently developing a gatsby plugin for theme ui focussed in performance. This plugin automatically deepmerges themes in gatsby's build process and include pre-otimized assets to the browser. Also, we are removing all non performatic features, like color modes. It's still in very early stages of development, but if you guys have interest we can try porting it to here and making a PR

[MarkosKon]

I also have high TBT on a Gatsby site with theme-ui.

After measuring the production build, I noticed that a good portion of React's hydrate (25%) was spent on calls to get, css, and responsive methods from @theme-ui/css. With x4 cpu slowdown that 25% is about 200-250 ms.

Something similar happens on a side project site. To measure, I use the Performance tab of Chrome DevTools and the bottom-up view.

I wasn't able to observe something similar on gatsbyjs.com or the theme-ui docs site, so maybe I'm doing something wrong or overusing the sx prop.

[lachlanjc]

Related: #1234 will improve frontend performance

[tlgimenes]

Hi guys, it's been a while. I've managed to greatly reduced the blocking time by rewriting the theme-ui plugin and removing some features like dark mode. Also I had to hack emotion and I made a PR in emotion core in here.

The plugin is in here. To try it just:
yarn add @vtex/gatsby-plugin-theme-ui

It's not well documented, however it should follow the same interface of the official plugin. If you guys happen to give it a try, please post you results so we can try merging these changes into the official gatsby plugin.

Thanks !

[lachlanjc]

Very cool! What did you discover? What would you suggest we change?

[AbdallahAbis]

@lachlanjc Any updates on this?

[lachlanjc]

@AbdallahAbis Nope! Would love contributions improving performance if you'd like to investigate.

[hasparus]

One problem is that the color modes detection has to be blocking — it's reading from localStorage, and we need it to happen ASAP to avoid color flash.

However, I know a few companies using Theme UI without color modes... I've advised people to manually use @theme-ui/core and add more packages as needed in such case. If this is more common than we expected we could reorganize the docs to deprioritize the umbrella package.

Regarding the Preact issue, I'm not sure if we can significantly limit the number of contexts we create without cutting some features.

cc @lachlanjc