Keystone: Performance Audit

[jossmac]

Our lighthouse score is pretty bad...

[mitchellhamilton]

While I completely agree we need to improve load performance, I don’t think doing SSR is worth it for the Admin UI. There are a bunch of things that rely on layout and local storage and things and while we could solve all the problems, I’m not sure the time and complexity cost would be worth the likely minimal to no performance benefit or potentially worse performance.

[jesstelford]

I'm working on _parts of this_ this now 👍

[jossmac]

@mitchellhamilton fair enough. Title updated.

[VinayaSathyanarayana]

Need to look at "Enormous Network Payload" of 13MB first

[jesstelford]

There is some useful lazy-loading code in https://github.com/keystonejs/keystone-5/pull/745 which we can cherry-pick onto master for some perf wins (experiments show it removes ~3MB from first load).

[mitchellhamilton]

FYI, I'm working on this, gonna take a slightly different approach to #745 with suspense. I'll probably want to cherry-pick the accessing field types from adminMeta stuff from #745 though.

[jesstelford]

I'm also working on building the AdminUI with next.js to get all the perf benefits it can convey with static building, etc.

[jesstelford]

I've been playing around with switching to next.js, and results so far are promising!

Current master

With Next 8

[jesstelford]

I don’t think doing SSR is worth it for the Admin UI.

Next.js has SSR built in - it takes zero extra effort to get started.

There are a bunch of things that rely on layout and local storage and things and while we could solve all the problems, I’m not sure the time and complexity cost would be worth [it].

I spent some time this weekend ironing this out - there were very few changes needed 👍

likely minimal to no performance benefit or potentially worse performance.

See the above screenshot of the perf benefits 👆

[JedWatson]

I'm doing some repo cleanup and closing issues that aren't specifically actionable.

Since this is more of a broad concern, I'm going to close it. Let's continue to focus on performance and open actionable issues we (and contributors) can work on.

In the meantime I'm expecting #749 will make a pretty big difference when it lands.