Investigate and propose dashboard performance improvements

[o-fernandez]

As I was trying to use it today, it was pretty slow as I was trying to find some old stories. (e.g., went to list view, did some resorting, etc.) I know our pantheon instance has a ton of stories (400+) which our users won't get to for a little while, but would be good to ensure those pages are snappy/fast.

This ticket is to investigate potential areas and prioritize solutions to implement. A few options @carlos-kelly mentioned:

• New way to render previews
• Virtualized lists

[BrittanyIRL]

Since October, as a team we've had some big wins for perf. I'm going to leave this in the backlog for now and when all of our new designs are in place will revisit. Pascal gave us some massive improvements when he separated the code base into packages. There's always things to improve but I don't see anything urgent here right now.

[o-fernandez]

Do we have monitoring in place to evaluate/report on our Dashboard and Workspace performance? @swissspidy @choumx

[swissspidy]

We have some limited tracking of load time of certain things (e.g. loading templates) but not more. Currently working on improving this quite a bit in #6248 .

but we first would have to define what exactly we want to track and what is possible

[swissspidy]

This would be a good candidate for an overarching performance epic I think.

[dreamofabear]

Some anecdotes from @pbakaus for posterity:

1. dashboard: ~4s duration to get from "Create your first story!" to actually show my stories in the dashboard
2. dashboard: cloning a story takes multiple seconds, no confirmation/loading indicator in the meantime.
3. dashboard: renaming a story sometimes doesn't react instantly, unclear whether it happened or not
4. dashboard: switching tabs (e.g. to 'drafts') is very slow. ~1s to just see the UI update on the tab, ~2-3s to actually get a visible update on the cards.

[dreamofabear]

Took a quick look at (1) and it looks like asset downloading is a primary latency culprit for cold editor load on stories-labs.dev. Warm editor load seems fast enough.

For example:

A couple ideas for low-hanging fruit:

• Upgrade hosting for stories-lab.dev or @pbakaus moves Web Creators to a faster host :)
• Optimize template stock images (~several MBs each)
• Preload editor assets while user is on dashboard
• Stale while revalidate e.g. with service worker
• For (2) and (3), add progress indicators/loading spinners

[swissspidy]

Upgrade hosting for stories-lab.dev

Is it really slow hosting or simply quite a large bundle? I'd rather have us fix our bundle size with code splitting etc. before needlessly moving hosts.

[dreamofabear]

Maybe the screenshot above was a fluke, but 2.8s transfer for a 600KB bundle seems really slow. Code splitting sounds great too of course.

[BrittanyIRL]

We've made some significant improvements since this ticket was created and I think moving forward we can stand to be a little more specific - generally speaking the dashboard now loads in under 1.5seconds. Here's metrics in staging against what Will added from Feb 12 courtesy of Paul. I am assuming here that Paul and Will's initial metrics were with their normal high speed internet because in February the dashboard was near unusable in slow 3g it took way too long to do anything.

Issue	Feb 12	Nov 8 (high speed, 3G slow)
Initial load of dashboard	~ 4s	1.3s, 9s
Duplicating a story	"multiple seconds"	.7s, 2.8s
Renaming a story	"not instant, unclear" (generally slow)	280ms, 2.7s
Swapping filters (ie drafts or published)	~3s	40ms, 2.4s

[pbakaus]

Those are fantastic improvements, kudos team! To confirm, yes, I tested on a regular high speed internet connection, and Macbook Pro.

[BrittanyIRL]

I'll use some time tomorrow to do a little more diving into react profiler to see what all we might be able to decrease some renders of or help with some misc content shift but it's feeling really nice right now. Anything I find I'll make new tickets for and then close this one.

[BrittanyIRL]

So actually, we're doing really great on the dashboard. Looked into lighthouse a little bit. My Stories (aka the "Dashboard") scores 95, Explore Templates scores 92, Detail Template view scores 85.

Stories/Dashboard: 95

Of that, largest Contentful Paint is almost entirely stuff out of our control related to WordPress (Render blocking resources that are also chained (wp js, php, styles, jquery), 1 large paint - the telemetry banner, not really sure that banner would ever not be a large paint - it's the entire width of the viewport.

Otherwise, we could look into 2 things here:

1. The excessive DOM size with the many stories displayed in the grid - this would be where a virtualized list could come into play. We're only loading 24 stories at a time, we don't need to render all of them at once though.
2. Layout shift of initial load from no telemetry banner to having a banner which shifts the whole page down some impacting the headline area as well as the banner. Either find out if the banner should exist before loading the header or have it be positioned absolutely (which we had done before but it got dropped due to other style changes).

Explore Templates: 92

• Same things we can't fix here with WordPress resources
• Even though we're using webP resources for the template previews and I just resized them to be the same height as story posters, lighthouse is calling them out as being able to be smaller. Not sure we want to break with our recommended pixels here (568x853px) - if we did shrink them it'd save an estimated 1.44s, so maybe worth doing cutting it again.
• Lighthouse is flagging some unused dashboard js which is interesting and could merit a generic code clean up to make sure t's are crossed and i's are dotted (so to say) given the updates we made this summer.
• We could cache the template poster images which would help speed things up after initial visits
• Same as Stories, could use virtualized list to avoid excessive DOM size.
• Same as Stories, adjust for telemetry banner to avoid shift.

Template Details: 85

• Same WordPress issues we can't fix
• Same issues with resources as Explore Templates (if we cached in explore this would be way faster).

I'll make tickets for the things we can improve - overall this is really awesome though! This time last year we did not see green on our lighthouse audits. Unless something drastic happens we will probably have scope for these in our longer 1.6 release cycle. @choumx How's some Dashboard Perf for that on the roadmap sound?

[swissspidy]

Any new insights from React Profiler as well?

[BrittanyIRL]

Any new insights from React Profiler as well?

Honestly things are pretty good there. This summer we cleaned up excessive re-renders of things (https://github.com/google/web-stories-wp/pull/8274, https://github.com/google/web-stories-wp/pull/8801), everything that should be is memoized.

We'll see some minor profiler wins from virtualizing the grid, probably.

I view this as peeling back layers, we'll fix this lot and expose another layer of things that we wouldn't have seen otherwise - it's hard (at least in my opinion) to know all without going layer by layer. I feel like we've all made some massive improvements to the whole app this year (you have absolutely led the charge on this, pascal!) and now we're able to dig in a little deeper and attend to some things that would have at first had no real noticeable positive change.