A lot of this like the browser waiting for a server response for each endpoint, and I think you could maybe speed this up globally with both a client-side and server-side cache for ETags, but I could be very wrong.

(This is all unsolicited conjecture based on a light reading of the client-side code so it may be totally wrong and useless. If so: Sorry! I'm just really enjoying the product, think y'all are grand, and would like to help if I can.)

It looks like axios isn't adding any caching headers like , so I would assume you're stuck doing something more expensive on the server side rather than the ideal "fast lookup in an in memory kv store". I'm actually not quite sure how the server is generating 304s given that the client doesn't appear to send anything that hints at what its cache looks like.

(It's possible you're already doing something like this but with a server-side lookup based on the account ID and some other unique key like the request URI and parameters, but if so it's odd that the TTFB would be so high. That solution would work but may prove inflexible in some circumstances; possibly none of them actually circumstances the product has though.)

https://axios-cache-interceptor.js.org seems to be the thing you might want—judging from the feature list—for the client, but it looks like you may also have to sprinkle in a bunch of caching hints as well when the client requests mutations and TTLs. Or disable the interceptor's total preemption of a request to use just the local cache, and instead make a conditional every time, which may make more sense given the product.

Server side you'd get some validated account ID from the corresponding cooke and—now—the client's current ETag for the request. You could use both in valkey/redis/memcache/whatever as your key to check if that tag is still valid. It'd be extremely fast O(1) operations to add those keys, check for their existence, and delete them.

You're already generating ETags on your responses so I think the server-side bit ends up easier, since you can stick this work globally at the start of of your req/resp cycle to look up the account ID and ETag in your in-memory DB and preempt any more work if it exists, and globally at the end to add the new ETag to the cache so that you both defer the work to generate one and reduce the size of the in-memory DB.

Security-wise you'd want to prevent an attacker from doing blind lookups by, e.g., making a request that somehow has a shorter/missing account ID and a larger ETag that contains account ID to fake a full cache key. I'm not sure that attack is even possible, but it can be easily thwarted by validating the account ID and ETag are the right shape and then concatenating them with a reserved delimiter that is not allowed to be present in either.

( set but it looks like that response is effectively uncacheable cause the timestamps and invoice URLs change frequently. You could pull those specifically out into a separate endpoint, though that may be a pain. I bet that info could also be a deferrable request rather than one that blocks the product from starting up.)

I have 134 categories and app speed seems ok to me.