Today we're rolling out a performance improvement that makes browsing recipes noticeably faster. Behind the scenes, we introduced smart caching for recipe listings so you spend less time waiting and more time cooking.
What you'll notice
- Recipe lists load faster — especially when you browse, filter, or search repeatedly.
- Smoother navigation: switching between pages feels more responsive.
- Less waiting: common views are served almost instantly from the cache.
These changes are most visible when you refresh the recipe list or revisit filters you've used recently. Instead of fetching everything from the database each time, the app serves your personalized results from a fast in-memory cache.
How caching helps you
Every time you view the recipe list — whether you're searching by tag, browsing your own recipes, or exploring public ones — the backend would typically query the database and assemble the result from scratch. That takes time.
With caching, successful queries are saved for a short period (5 minutes). When you return to the same view the app skips the database query and delivers your results immediately. That means:
- Faster page loads and less time waiting for content.
- More responsive interactions when navigating between filters, tags, and searches.
- Lower backend load so the app stays fast even during busy times.
Your privacy stays protected
Caching is user-specific and respects authentication:
- Each user gets their own cache space — you never see another user's cached data.
- Only successful GET requests for recipe listings are cached — write operations (creating, editing or deleting recipes) are never cached.
- When you create, edit or delete a recipe your cache is automatically cleared so you always see fresh, up-to-date content.
- Cached entries expire after 5 minutes to keep data fresh and avoid showing stale results.
This design ensures caching accelerates the app without compromising security or data accuracy.
Behind the scenes
For the technically curious: we built a lightweight in-memory cache inside the Node.js backend. Each cache entry is keyed by user ID, route and query parameters so every user gets their own isolated cache.
When a recipe is created, updated or deleted the relevant user's cache is invalidated immediately. A background cleanup process sweeps expired entries every minute to keep memory usage lean.
The approach is simple, effective and keeps response times fast without adding external dependencies like Redis.
What's next
We're exploring additional caching strategies:
- Caching individual recipe views for repeat visits to popular recipes.
- Client-side caching in the frontend to reduce network requests even further.
- Smarter invalidation rules so related content updates trigger targeted cache refreshes.
If you notice faster load times or have ideas about what else we could optimize, please let us know through the in-app feedback form.
— Andreas