BanTool Documentation

Appearance

Chapter 6: Don't Re-download: Leveraging the Browser Cache ​

Of course. Now that we've made our files as small as possible, the next step is to ensure the user's browser doesn't have to download them again unnecessarily. This is where Browser Caching comes in.

The Scenario 📝 ​

  • System: A user visits your website for the first time. Their browser downloads all the necessary assets: HTML, CSS, JavaScript, the company logo, etc.
  • Problem: Five minutes later, the same user returns to your site. The browser proceeds to re-download all the CSS, JavaScript, and logo files from scratch, even though they haven't changed at all. This makes the second visit just as slow as the first and wastes bandwidth.

Analyzing the Bottleneck 🧐 ​

The bottleneck here is unnecessary network requests. The browser is perfectly capable of storing these files on the user's machine, but it doesn't because the server never told it to.

The Solution: The Cache-Control HTTP Header ✅ ​

  • The Logic: A web server can attach a header named Cache-Control to every response it sends. This header is an instruction, telling the browser what to do with the file it just received.

  • The Most Important Directive:Cache-Control: public, max-age=31536000, immutable

    • public: Any cache along the way (like a proxy or CDN) can store this file.
    • max-age=31536000: "Store this file for one year (in seconds). For the next year, if you need this file, use the saved copy and don't bother asking the server again."
    • immutable: An extra hint that the file's content will never, ever change.

How This Works in Nuxt (and Other Modern Frameworks) ✨ ​

How can we confidently tell the browser to cache a file for a whole year? What if we update our code? Modern frameworks solve this with a clever technique called File Hashing.

  1. File Hashing:

    • When you run npm run build, Nuxt automatically adds a unique hash to the filenames of your CSS and JavaScript assets.
    • For example, main.css becomes main.a4b6cf.css.
    • If you change even a single character in your code and rebuild, the hash changes: main.b8e1a0.css.

  2. The Perfect Caching Strategy:

    • For hashed files (.js, .css, images, etc.): The server is configured to send Cache-Control: max-age=31536000 (cache for one year).
    • For the index.html file: The server sends Cache-Control: no-cache. (Note: no-cache doesn't mean "don't cache"; it means "you must check with the server for a new version before using the cached one").

The Workflow:

  • First Visit:
    1. The browser downloads index.html.
    2. The index.html file requests main.a4b6cf.css.
    3. The browser downloads main.a4b6cf.css and caches it for one year.
  • Second Visit:
    1. The browser asks the server for a fresh index.html.
    2. The index.html file still requests main.a4b6cf.css.
    3. The browser says, "Hey, I have that file in my cache, and it's still valid!" and loads it instantly from the disk. No network request is made for the CSS file.
  • After You Deploy an Update:
    1. You deploy the new version of your site.
    2. The browser downloads the new index.html.
    3. This new index.html now requests a completely different file: main.b8e1a0.css.
    4. Since this is a new filename, the browser downloads the new version and caches it for another year.

Conclusion:

  • Properly configuring browser caching is the key to making your website feel nearly instantaneous for returning visitors.
  • The combination of File Hashing (done by your framework/bundler) and the Cache-Control header (configured on your server) is the most effective and standard pattern for handling static assets.