Performance ~lol~

[demiters]

Disclaimer: I'm unlikely to be able to contribute with more than advice and discussion at this point in time and I'm aware these probably aren't priorities but could be something to consider if major refactors are underway anyway.

Ran some web performance tests out of curiosity. Not quite stellar:

• tested from USA
• tested from Sweden

Basically there are issues with security, compression, caching and global reach is limited because of no CDN, which also would have improved the time-to-first-byte. Now, dealing with some of these properly (assuming anyone would want to do it) would require pretty significant work. As a fan of web perf/edge computing and Jamstack/Serverless architectures (which I initially dismissed as only useful for simple static sites but found to be beneficial even for dynamic data-heavy apps) I thought I'd fantasize about what would reasonably perf-optimized architecture look like for this, where these issues are mitigated by design and good defaults, which also improves developer experience so friction is reduced and more effort can be focused on building features.

Next.js and Gatsby both are mature, production-ready React frameworks focused on performance. My pick is Next.js due to the amount of dynamic content on the site which should be handled on the client.

Next.js (which has great defaults for performance and wraps React so migrating would not be too much pain) hosted on Netlify or Vercel would improve global performance in many user-perceivable metrics as both include a CDN. Things like caching and performance are built-in, not afterthoughts. PWA would be trivial to add which can be useful for mobile usage.

In both cases for best performance the API would need to be converted into serverless functions/workers (not too difficult) deployed to the edge (CDN) for performance on Netlify or Vercel. Both Netlify and Vercel would cost around $20/mo if we want to use functions/workers. To use the free tiers, API would have to remain hosted where it is so a bit of latency would remain for loading data but overall it would still be an improvement.

With everything on the CDN, requests to the centralized database become the performance bottleneck but both EOL server and MySQL would likely stay the same as it is probably way too much effort to be worth with implementing a distributed database and replicating MySQL to the edge could become pretty expensive. But if going that route, frontend data fetching times could be reduced for people proportionally to their distance to the current MySQL server if the database gets replicated to the edge (which I'm not quite sure how) or simply mirrored to a distributed one like Fauna (looks like current usage would fit in $25/mo tier) which integrates seamlessly with Netlify and Vercel and is then also distributed to the edge with the CDN for very low latency anywhere. And API performance could be boosted a fair bit with a rewrite to Rust framework actix-web but that would alienate some contributors I guess.

Anyway, just some things to consider.

[sunehs]

As discussed in discord, there's a few low hanging fruits at least, such as adding the headers, zipping static content. The other stuff is potentially a lot of work and would also increase running costs based on those numbers. But always good with some ideas.

Another consideration for performance is db queries, there's some multiple seconds ones there, can consider some redis cache.

[j-masci]

Could start with some middleware like this: https://github.com/idanto/express-node-metrics. I think finding lowest hanging fruit is best start. Server logs queries taking over a second but shorter than 1s is still long if it's done often.

ORMs/sequalize probably quite slow for some queries. Might be worth re-writing the worst offenders in good old SQL as much as this option isn't exactly ideal.

[sunehs]

did some things, a lot better now at least https://www.webpagetest.org/result/210316_AiGR_a4095981841d19f62a8c14b7740b2246/