Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache busting/invalidation? #658

Closed
davidrossjones opened this issue Jan 4, 2017 · 7 comments
Closed

Cache busting/invalidation? #658

davidrossjones opened this issue Jan 4, 2017 · 7 comments

Comments

@davidrossjones
Copy link
Contributor

davidrossjones commented Jan 4, 2017

With something like file-loader it's possible to generate file names to help with cache invalidation upon change e.g. forcing user to download new assets (css, images, etc).

In light of #638 what are some of the approaches to solving this problem in Next.js?

@nkzawa
Copy link
Contributor

nkzawa commented Jan 5, 2017

I don't fully understand your question. Can you elaborate ?

@davidrossjones
Copy link
Contributor Author

So I need a strategy for managing invalidation of cached assets and I want to avoid doing this manually by, for example, adding a query param onto the end of any referenced image in my components:

/static/image.jpg?v=1

Instead I have previously been using Webpack file-loader so I can load the image into my component and have file-loader generate a new hash filename every time its changed via the client side js bundle:

/static/0dcbbaa701328a3c262cfd45869e351f.jpg

Perhaps I need to implement something like this with a customer server? https://www.npmjs.com/package/webpack-assets-manifest

@Huxpro
Copy link
Contributor

Huxpro commented Jan 6, 2017

I also regraded assets hashing as an essential step of nowadays build process.

Instead of just taking advantages of conditional request (304) with ETag and Last-Modified, Cache-Control: max-age make browser response from cache directly which is a huge perf boost. However we need to hash our static assets so we can invalidate cache when we update out assets.

Take a look at your rivals https://nuxtjs.org/guide/assets, which has had this kinda functionality built-in.

IMO whether or not use webpack is just a implementation details. Developers can use gulp-rev to do it themselves but It's way better to have this feature built-in.

@Huxpro
Copy link
Contributor

Huxpro commented Jan 6, 2017

Got to say next.js have handled JS/CSS hashing well and It solve 99% cases, while assets such as images/fonts could cause some UI problems

@timneutkens
Copy link
Member

Might be related: #672

@timneutkens
Copy link
Member

See #745. Feel free to re-open if this doesn't solve your issue.

@rbalicki2
Copy link

rbalicki2 commented Mar 14, 2018

@Huxpro @davidrossjones I too consider hashing and never serving the wrong version of a file to a user of the website to be of paramount importance. I do the following with nextjs:

in my .babelrc

    [
      "babel-plugin-file-loader",
      {
        "extensions": ["otf", "png", "jpg", "svg"],
        "publicPath": "/static",
        "outputPath": "/static",
        "name": "[path][name].[ext]/[hash].[ext]",
        "context": ""
      }
    ],

now, all of my static assets go into the static folder and have a hash. It's not exactly pretty, but it works.

Then, I upload the static folder to S3 and set the cache-control headers to immutable. There are no conflicts, obviously, because of the hash, and users of previous versions of the site can continue to get the proper assets. Then, I have a cloudfront distro that compresses the files and terminates ssl connections, and a route53 DNS record in front of that.

Similarly, I upload the html files (from out/builds) to S3 with cache-control max-age=0,no-cache. To deploy a version of the site, I run

aws s3 sync \
  s3://$S3_BUCKET/$S3_BUCKET_FOLDER/builds/$GITHASH \
  s3://$S3_BUCKET/$S3_BUCKET_FOLDER/current \
  --delete \
  --cache-control max-age=0,no-cache \
  --acl public-read

and use a separate behavior in cloudfront to serve /current from root.

That's super abbreviated, but feel free to ping me for more details, and I'll put up a boilerplate or something. :)

@lock lock bot locked as resolved and limited conversation to collaborators May 16, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants