4 Caching Strategies to Make Your Application Fly |

Hey readers,

I once worked on a social media site where the homepage loaded the top 10 most popular posts from the last 24 hours. It was the heart of the app, but it was painfully slow. We dug into the code and found that for every single person who visited the site, our server was running a massive, complex database query to recalculate this list.

We were doing the same expensive work over and over again, millions of times a day. The solution? We calculated the list once and then stored the result for a few minutes. The homepage load time went from five seconds to fifty milliseconds.

This is the power of caching. It’s the single most effective way to improve your application’s performance. The core idea is simple: if a piece of data is expensive to create but doesn’t change often, you should save a copy of it somewhere fast.

Let’s explore the four common layers of caching you can use to make your application dramatically faster.

1. Client-Side (Browser) Caching

The fastest data is the data that never has to leave the user’s own computer. When a user visits your website, their browser can save local copies of your assets (like images, CSS, and JavaScript files).

The best way to picture this is a customer at a coffee shop. The first time they visit, they have to read the entire menu on the wall. But if they take a picture of the menu with their phone, the next time they visit, they can just look at the photo instead of reading the whole menu again.

How it works: Your server sends Cache-Control headers with your files. A header like Cache-Control: max-age=3600 tells the browser, “You can reuse this file for the next hour without asking me for it again.”
Why it matters: This dramatically reduces the number of requests to your server and makes your site feel instantaneous on subsequent visits.

2. Content Delivery Network (CDN)

What if your user is in Tokyo but your server is in Virginia? The physical distance alone will make your site slow. A CDN solves this by distributing your static assets to servers all over the world.

Imagine you have a famous pizza recipe. Instead of making everyone in the world fly to your single restaurant in New York, you open franchises in London, Tokyo, and Sydney. Now customers can get the exact same pizza from a location much closer to them.

How it works: A CDN like Cloudflare or Amazon CloudFront copies your images, videos, and CSS files to dozens of “edge locations” globally. When a user in Tokyo requests an image, it’s served from the Tokyo edge location, not your main server in Virginia.
Why it matters: A CDN drastically reduces latency for a global audience. It also takes a huge load off your main server, freeing it up to handle important application logic.

3. Application-Level Caching (In-Memory)

This is the type of caching we implemented to fix our slow homepage. It involves storing the results of expensive operations—like complex database queries or calls to third-party APIs—in a high-speed, in-memory data store like Redis or Memcached.

This is like a chef preparing for the dinner rush. Instead of chopping an onion every time an order comes in, the chef pre-chops a whole bucket of onions in the morning. When an order arrives, the onions are ready to go instantly.

How it works: Before running an expensive query, your application first checks the cache.
- If the data is in the cache (a “cache hit”), it returns the data immediately.
- If the data is not in the cache (a “cache miss”), it runs the query, saves the result to the cache for next time, and then returns the data.
Why it matters: This is the most powerful way to reduce the load on your database. It can turn a query that takes seconds into one that takes milliseconds, directly improving your application’s response time.

4. Database Caching

Your database itself is also smart about performance. Most modern databases have a built-in, in-memory cache where they keep frequently accessed data.

Think of a librarian at their desk. They’ll keep the most popular, frequently requested books on a small shelf right behind them. When someone asks for one, they can just turn around and grab it. For less common books, they have to walk back into the main stacks (the disk) to find them, which takes much longer.

How it works: The database engine automatically identifies data that is being read often and keeps it in RAM. When a query comes in for that data, it can be returned directly from memory instead of being read from the much slower disk.
Why it matters: While this happens mostly automatically, understanding it is key. It explains why the first time you run a query it might be slow, but subsequent runs are much faster. It also highlights the importance of having enough RAM for your database server.

What’s the next move?

Challenge: Go to a media-heavy website you visit often (like a news site or YouTube). Open the Network tab in your browser’s developer tools.

Make sure “Disable cache” is unchecked.
Load the page. Note the size and time for some of the larger assets, like images.
Now, refresh the page.

Look for requests that now have a status of 304 Not Modified or say (from memory cache) in the size column. You’ve just seen browser caching in action!

Thanks for reading!

Bou~codes and Naima from 10xdev blog.