General rule of thumb with databases is to reduce the number of queries. Fetch large batches of information. This can be difficult to arrange with how such systems are commonly built and/or coded; some sort of intermediary between the consumer and the database can be warranted, which you can tell, “oh btw, these are the items that I’m going to want, d’you mind just fetching them all now so you can hand them directly to the consumers when they ask for them rather than issuing a new query for each?” In a well-done system like this, the database will be a minor component in the performance—templating and other JS-side transformations are much more expensive than fetching easily-identified rows from a database that’s been designed to handle zillions of requests per surprisingly-small-unit-of-time.
I’m curious what fraction of the 1m22s it now takes is waiting for the database.
Building performance tracking into the product? Good job! That shows me that you’re genuine in caring about it, which is still more encouraging. I’m going to investigate Elder.js.
In that example most of it was waiting on the remote database. (I’m ans SQL newb).
That said, Elder.js makes it easy to see what is causing performance hits with full perf tracking.
These days that same site is 1 min 22sec.