Speed of Open Collective

[shannondwray]

Who is your user?

Everyone

What are they trying to achieve?

I've noticed lately that it is taking a while for the webpage to load and I'm frequently getting non responsive pages which I have to reload

How are they currently doing this?

Not to sure how this is currently monitored by the engineering team

How well understood is this problem?

• Surfacing: if you feel this is a seed of an idea that needs to be researched.
• Understanding: if you've done some research and feel it is already well understood and ready for shaping.
• Shaping: if you feel a solution is clearly defined and can be made into a pitch (read more about shaping)
• Pitching: if you feel that it is ready to be presented for prioritisation (read more about pitching)

[Betree]

I share the feeling that, lately, multiple pages were really slow and sometimes unresponsive; usually on large hosts or OC Inc profiles. To come up with effective solutions, we need to better identify and document the pages that are slow/unresponsive.

In opencollective/opencollective-api#8051 we've plugged Sentry's performance tool; it should help us both to detect slow queries and to diagnose why they're slow.

We can use this issue to summarize our actions on this topic.

[Betree]

Search is extremely slow lately, would be great to investigate that area (related: #5809)

[gustavlrsn]

One avenue to explore could be to statically render a lot of content, and fetch the logged in user data on the client.

Currently our approach is server side rendering everything, I think. But since most of the content on our platform is public, it seems like a good candidate to use static rendering.

We could use Next.js getStaticProps an on-demand revaidation to instantly revalidate a page when something gets outdated.

[kewitz]

Project Updates Week 4:

• Frontend performance metrics update merged and deployed;
• Performance day at Berlin retreat:
  • Collective Page logic refactor specifications written and started;
  • Queries and resolvers reviewed;

Next steps:

• Work on Collective Page refactor
• Dig more into creating a follower DB outside Heroku

[znarf]

Last week.

Collective Page

• Tweaked the GraphQL cache to be more generic and created a new cache invalidation mechanism performance: update approach at graphql cache opencollective-api#8722
• Tweaked the preloader to work with the latest budget section performance: preload for new budget section opencollective-frontend#8749

Host Dashboard

• Identified a huge bottleneck preventing host reports to load performance: getHostedCollectives "raw" optimization opencollective-api#8713
• Use fast balance to compute getTotalMoneyManaged performance: use getCurrentCollectiveBalances to compute getTotalMoneyManaged opencollective-api#8714
• Make the current day statistics works nicely with loader and cache performance: host report optimization opencollective-frontend#8739

CSV

• Implemented zero limit strategy for counting transactions Performance: support for zero limit (count only) on transactions resolver opencollective-api#8716

[BenJam]

closing as we've comitted a cycle (6 weeks) to addressing a number of concerns and increasing performance. We'll continue to look at performance and speed on a cycle by cycle basis but there's little value in keeping this open ad infinitum. Thank you and good night!

[shannondwray]

https://pagespeed.web.dev/analysis/https-opencollective-com/kksrxpcocj?form_factor=mobile - She's not looking too good...