Caching

Effective use of caching in the browser and on the server is essential to providing the fastest experience for your users. React Storefront allows you to control both client and server caching from a single place: your router definition.

This guide gives you everything you need to know to cache responses effectively using React Storefront.

You can make any route cacheable by adding a cache handler to the route.

For example:

// src/routes.js

import { Router, fromServer, cache } from 'react-storefront/router'

new Router()
  .get('/', 
    cache({ client: true, server: { maxAgeSeconds: 300 }}) // cache in the service-worker and on the server for up to 5 minutes
    fromServer('./home/home-handler')
  )

The cache handler takes an object with with two properties:

• client: (Boolean) Set to true to cache responses on the client using the service worker. Set to false or omit to prevent caching on the client.
• server: (Object) Configures caching on the server. If omitted, responses will not be cached on the server
  • maxAgeSeconds (Integer) The time to live in seconds

All caching on the client is managed by the service worker that react-storefront automatically generates when your app is built.

In additon to specifying cache({ client: true }) on each route, you can configure client-side caching parameters for all routes using router.configureClientCache(options):

// src/routes.js

import { Router } from 'react-storefront/router'

new Router()
  .configureClientCache({
    maxEntries: 1000,
    maxAgeSeconds: 300
  })

The configureClientCache function takes an object with the following properties:

When you specify a cache handler with, for example, { server: { maxAgeSeconds: 300 }}, React storefront adds a cache-control: no-cache, s-maxage: 300 header to the response. This instructs the hosting platform to cache the response for the configured number of seconds.

In order to prevent responses with set-cookie headers from being cache (and thus possibly leaking user-specific information like a session id to multiple users), React Storefront automatically removes all set-cookie headers when your route is configured to cache on the server.

Your JS bundles are far-future cached and contain a cache-busting hash in the filename. Therefore they are safe to cache in the browser (even when service workers are not supported) and on the downstream CDN.

All other static assets will not have a cache-control header. They will be cached based on the CDN and browsers default behavior. If hosting on the Moovweb XDN, all static assets are far-future cached on the server.

Moovweb's XDN platform is automatically configured to respect this header. If you're hosting on another platform, you'll probably need to configure it to do so.

You can use the x-moov-t response header. If you see vc=hit in the x-moov-t response header. A value of vc=cached indicates a miss but the result has been cached for the next request. All other values indicate a cache miss.

There is also a x-moov-cache-reason that specifies whether or not the result was cached and why. For example:

x-moov-cache-reason: cached: cache-control: s-maxage found in response

If you see a cache-control response header with an s-maxage value, Moov XDN will cache it.

Moov XDN strips this value off before it sends the response. This helps ensure that the downstream CDN won't cache the response. This is important to prevent stale responses that would otherwise occur after you deploy an update to your application.

Moov XDN automatically clears the server cache when you deploy an update to your application.

You can also clear it manually at any time using the Moovweb XDN Console. Navigate to your project, then select Project Settings => Project Admin => Clear Hosts Cache.

You will not receive a cached response.