Everything you think you know about speed? It’s mostly perception.
Your favorite apps don’t actually “feel fast” because they magically process data in the blink of an eye — they feel fast because they trick you into thinking they are.
Sure, solid infrastructure, smart data modeling, and good indexing get you closer to real performance. But to deliver product‑grade perceived speed, teams lean heavily on clever caching and rendering strategies. And when it’s done right? It’s beautiful engineering, even if it’s technically a bit of a cheat.
Users don’t care how elegant or clean your code is. They only care whether something loads in 150ms or 750ms. Those hundreds of milliseconds matter, and once you cross into seconds, attention evaporates.
Here are the strategies worth stealing:
We lean on this pattern heavily at Joyful.
Every time we insert or update, we also pre‑compute joins and store them as jsonb fields. Yes — it adds a little write overhead. But because our platform is extremely read‑heavy, we’re optimizing for the common case: reading.
Reads become instant, and users never feel latency they shouldn’t.
Think of this as pre‑joining on steroids.
Instead of just caching joined data in your database, you persist read‑optimized documents into Elasticsearch. The result:
Is Elasticsearch overkill early on? Maybe. But once you have a few hundred customers and search matters? It becomes essential.
Rather than waiting for the user to ask for data, you fetch ahead of time — based on what they’re most likely to need next.
For example:
The result? The user never experiences the fetch at all — it already happened.
Perceived speed isn’t just about writing faster code — it’s about engineering the illusion of speed.
The best teams:
Because at the end of the day, users don’t care how fast your backend is.
They care how fast your product feels.
And great products always feel fast.