Optimizing Page Loading: How Browsers Use Cache to Speed Up the Web

So far, we've seen how the browser loads a page by requesting resources like stylesheets, scripts, images, and more. But what happens if you revisit the same page later?

The answer is key to web performance: the browser tries not to download the same thing twice. Instead, it uses cache to temporarily store files and speed up subsequent visits.

Cache is like a pantry at home

Imagine the browser as a person who cooks every day. When they need to prepare a meal, the first thing they do is check the pantry (the cache). If they already have the ingredients (previously downloaded files), they can cook faster without leaving the house. But if something is missing, they have to go to the store (the server) to buy it, which takes more time.

Sometimes, an ingredient in the pantry is expired (the cache has expired), so it needs to be replaced with a new one. And if it's the first time cooking that dish, they'll need to get everything from scratch.

So, if the browser detects that it has valid information available, it uses it directly from local storage without making a new request to the server. This makes page loading much faster and reduces bandwidth usage.

What gets stored and for how long?

When the browser visits a page, it can save some files (like images, stylesheets, or scripts) to avoid downloading them again next time. But how does it know if it can save them and for how long?

The server provides special instructions called cache headers, which act as notes for the browser:

• Cache-Control: max-age=3600 → “Save it for 1 hour”
• Expires: [date] → “Save it until this specific date”
• ETag: [identifier] → “If in doubt, ask me if it has changed”

This way, the browser can decide when to use what it already has and when to request a new version from the server.

When can it cause problems?

Although caching is very useful for speeding up site loading, it can also cause confusion, especially when you're making changes during the development of a page.

For example:

• If you modify a file (like a CSS file), but the browser keeps using the old copy stored in the cache, you won't see your changes reflected.
• This can make it seem like the site is broken or unresponsive, even though your code is up to date.

What can you do as a developer?

• Force a reload without cache (e.g., with Ctrl + F5) so the browser downloads everything again.
• Disable cache temporarily from the browser's developer tools.

As a developer or user, understanding how caching works helps you diagnose errors, avoid confusion, and optimize the performance of any site.

flowchart TD
        A[Browser requests a resource] --> B[Is it cached?]
        B -- Yes --> C[Is it valid?]
        C -- Yes --> D[Use cached version]
        C -- No --> E[Request a new version from the server]
        B -- No --> E
        E --> F[Save new version in cache]
        D --> G[Render the page]
        F --> G

How to detect if a resource was served from cache

When using the browser's developer tools (DevTools), you can inspect requests in the Network tab. Some indicators that a resource was served from cache are:

• Status code 304 Not Modified: This means the browser asked the server if the resource had changed, and the server responded that it hadn't, so the browser used its local copy.

• Indicators like "from disk cache" or "from memory cache" in the Size column or request details: This shows that the browser didn't even consult the server because it already had a valid copy in memory or on disk.

Note: In Chrome DevTools, you can add columns like "Transferred" and "Size" to see if a resource was actually downloaded or came from cache.

The trick of clearing a resource using query strings

Sometimes we want to force the browser to treat a resource as new, even if the file path hasn't changed. A common strategy is to add an extra parameter to the URL that doesn't affect the content. For example:

1<link rel="stylesheet" href="styles.css?v=2">
2<script src="app.js?version=20240427"></script>

Here, even though the server is serving the same styles.css or app.js file, the browser sees a different URL (styles.css?v=2) and makes a new request as if it were another resource.

This is useful for:

• Ensuring users download the latest version of an updated file.
• Avoiding issues with aggressive caching in browsers or intermediate proxies.

Important: These parameters should be controlled strategically: you can automate them in the deployment (build) process to add a version number or hash when a file changes.

Real-world examples of cache issues and how to solve them

Here are some typical cases developers face:

• CSS or JS file changes but users see the old version: Solution: use a version query string (?v=2) or change the file name (styles_v2.css).

• Bug reported where "it looks broken for me but not for others": One user might be seeing the old cached version.
  Solution: force reload without cache (Ctrl + F5) or manually clear the cache.

• Analytics or third-party scripts don't update even after integration changes:
  Solution: add version control to the URLs of those scripts.

• You changed an image, but users still see the old one:
  Solution: rename the image (logo_v2.png) or add a query string (logo.png?updated=1).

• Minor HTML changes don't reflect on sites with service workers (PWA):
  Solution: invalidate caches in the service worker and ensure proper update management.