VueJS/browser caching production builds

Question

I have a VueJS app. Whenever I run npm run build it creates a new set of dist/* files, however, when I load them on the server (after deleting the old build), and open the page in browser, it loads the old build (from cache i assume). When I refresh the page, it loads the new code no problem.

This is my index.html:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta http-equiv="Content-Type" content="text/html;charset=UTF-8"/>
        <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"/>
        <meta http-equiv="cache-control" content="max-age=0" />
        <meta http-equiv="cache-control" content="no-cache" />
        <meta http-equiv="expires" content="-1" />
        <meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
        <meta http-equiv="pragma" content="no-cache" />
        <link rel="stylesheet" href="/static/css/bootstrap.min.css"/>
    </head>
    <body>
        <div id="app"></div>
    </body>
</html>

Is there a way to force it to load new code every time or (ideally) to check if the old files are gone from the server, then refresh the browser?

For the Name · Accepted Answer

We struggled with this same issue and found that some people's browsers would not even pull the latest version unless they manually refreshed. We had problems with caching at various layers, including the CDN where we hosted files.

We also struggled with maintaining versions and being able to rapidly redeploy a previous version if something goes wrong.

Our solution (using project based on vue-cli Webpack):

1) We build the distribution to have a version specific folder instead of 'static'. This also helps us track builds and 'undo' a deployment if needed. To change the 'static' directory, change 'assetsSubDirectory' under 'build' in index.js and change 'assetsPublicPath' to your CDN path.

2) We use Webpack Assets Manifest to build a manifest.json file pointing to all the assets. Our manifest includes a hash of all files, as its a high security application.

3) We upload the versioned folder (containing the js and css) to our CDN.

4) (Optional) We host a dynamic index.html file on the backend server. The links to the stylesheet and scripts are filled in by the backend server using a template system pulled from the data on the manifest.json (see #5). This is optional as you could use the force-reload option as in the comment below, which isn't a great experience but does work.

5) To publish a new version, we post the manifest.json to the backend server. We do this via a GraphQL endpoint but you could manually put the json file somewhere. We store this in the database and use it to populate the index.html and also use it to verify files using the file hash (to validate our CDN was not hacked).

Result: immediate updates and an easy ability to track and change your versions. We found that it will immediately pull the new version in almost all user's browsers.

Another bonus: We are building an application that requires high security and hosting the index.html on our (already secured) backend enabled us to more easily pass our security audits.

Edit 2/17/19

We found that corporate networks were doing proxy caching, despite no-cache headers. IE 11 also seems to ignore cache headers. Thus, some users were not getting the most up to date versions.

We have a version.json that is incremented/defined at build time. Version number is included in manifest.json. The build bundle is automatically uploaded to S3. We then pass the manifest.json to the backend (we do this on an entry page in Admin area). We then set the "active" version on that UI. This allows us to easily change/revert versions.

The backend puts the "currentVersion" as a Response Header on all requests. If currentVersion !== version (as defined in version.json), then we ask the user to click to refresh their browser (rather than force it on them).

Sean Ray · Answer

Based on this comprehensive answer on cache headers, your best bet is going to be solving this on the server side if you have control of it, as anything in the <meta> tags will get overridden by headers set by the server.

The comments on the question indicate that you are serving this app with nginx. Using the linked answer above, I was able to set the Cache-Control, Expires and Pragma headers for any requests for files ending in .html this way in my nginx config:

server {

  ...other config

  location ~* \.html?$ {
    expires -1;
    add_header Pragma "no-cache";
    add_header Cache-Control "no-store, must-revalidate";
  }
}

This successfully forces the browser to request the latest index.html on every page reload, but still uses the cached assets (js/css/fonts/images) unless there are new references in the latest html response.

bragboy · Answer

This problem is annoying, no doubt. Had to solve it using a custom Front end version endpoint sent in the header. I am using a rails backend and Vue + Axios as front-end. Note I don't need a service worker and hence not using one.

Essentially I am just reloading whenever there is a get request and that the version of the application has changed (the server can inform the same)

axiosConfig.js

axios.interceptors.response.use(
  (resp) => {
    const fe_version = resp.headers['fe-version'] || 'default'
    if(fe_version !== localStorage.getItem('fe-version') && resp.config.method == 'get'){
      localStorage.setItem('fe-version', fe_version)
      window.location.reload() // For new version, simply reload on any get
    }
    return Promise.resolve(resp)
  },
)

Rails Backend

application_controller.rb

after_action :set_version_header

def set_version_header
  response.set_header('fe-version', Setting.key_values['fe-version'] || 'default')
end

application.rb (CORS config assuming Vue running on port 8080)

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins ['localhost:8080', '127.0.0.1:8080']
    resource '*', expose: ['fe-version'], headers: :any, methods: [:get, :post, :delete, :patch], credentials: true
  end
end if Rails.env.development?

Wrote a detailed article here: https://blog.francium.tech/vue-js-cache-not-getting-cleared-in-production-on-deploy-656fcc5a85fe

Connor Leech · Answer

To delete the cache you can run rm -rf node_modules/.cache

This deletes your cache. You can run a new build before deploying.

I was having the same issue where I ran a production build, but then even when running locally my code would point to the production build instead of my latest changes.

I believe this is a related issue: https://github.com/vuejs/vue-cli/issues/2450

ADM-IT · Answer

If you use asp.net core you can try the following trick among with the webpack which generates js files with the hash at the end of the name eg. my-home-page-vue.30f62910.js. So your index.html contains: <link href=/js/my-home-page-vue.30f62910.js rel=prefetch> which means whenever you change the my-home-page.vue it will generate a new hash in the filename.

The only thing you need is to add a cache restriction against the index.html

In your Startup.cs:

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    // ....
    app.UseStaticFiles(new StaticFileOptions
    {
      // Make sure your dist folder is correct
      FileProvider = new PhysicalFileProvider(Path.Combine(_env.ContentRootPath, "ClientApp/dist")),
      RequestPath = "",
      OnPrepareResponse = context =>
      {
        if (context.Context.Request.Path.StartsWithSegments("/index.html", StringComparison.OrdinalIgnoreCase))
        {
          context.Context.Response.Headers.Add("Cache-Control", "no-cache, no-store");
          context.Context.Response.Headers.Add("Expires", "-1");
        }
      },
    });
    // ....
}

Devin · Answer

I serve a Nuxt app alongside a very lightweight Express app that handles server-side authentication and other things. My solution is to let Express store the current git hash in a cookie when a user logs in. This value is then placed in a Vuex store along with the current time (and other info about the current user).

On a route change, a router middleware checks how long it's been since we last compared the store' hash with the actual one. If it's been more than a minute, we request the current Hash from Express and force a server-side render for the current route if the value has changed.

Here's the relevant code:

server/index.js

const getRevision = function() {
  return require('child_process')
    .execSync('git rev-parse --short HEAD')
    .toString()
    .trim()
}

app.get(
  '/login',

  async function(req, res, next) {
    // (log in the user)

    const revision = getRevision()
    res.cookie('x-revision', revision)

    return res.redirect('/')
  }
)

app.get(
  '/revision',

  function(req, res) {
    const revision = getRevision()
    return res.send(revision)
  }
)

store/index.js

export const actions = {
  nuxtServerInit({ dispatch }) {
    const revisionHash = this.$cookies.get('x-revision')
    dispatch('auth/storeRevision', revisionHash)
  }
}

store/auth.js

export const state = () => ({
  revision: { hash: null, checkedAt: null }
})

export const mutations = {
  setRevision(store, hash) {
    store.revision = { hash: hash, checkedAt: Date.now() }
  }
}

export const actions = {
  storeRevision({ commit }, revisionHash) {
    commit('setRevision', revisionHash)
  },

  touchRevision({ commit, state }) {
    commit('setRevision', state.revision.hash)
  }
}

middleware/checkRevision.js

export default async function({ store, route, app, redirect }) {
  const currentRevision = store.state.auth.revision
  const revisionAge = Date.now() - currentRevision.checkedAt

  if (revisionAge > 1000 * 60) {
    // more than a minute old
    const revisionHash = await app.$axios.$get(
      `${process.env.baseUrl}/revision`
    )

    if (revisionHash === currentRevision.hash) {
      // no update available, so bump checkedAt to now
      store.dispatch('auth/touchRevision')
    } else {
      // need to render server-side to get update
      return redirect(`${process.env.baseUrl}/${route.fullPath}`)
    }
  }

  return undefined
}

VueJS/browser caching production builds

Tags:

html

browser-cache

vue.js

ierdna

6 Answers

For the Name

Sean Ray

bragboy

Connor Leech

ADM-IT

Devin

Recent Activity

Donate For Us

VueJS/browser caching production builds

Tags:

html

browser-cache

vue.js

ierdna

6 Answers

For the Name

Sean Ray

bragboy

Connor Leech

ADM-IT

Devin

Related questions

Recent Activity

Donate For Us