Improve readme regarding "stale-while-revalidate" used in this project

Can someone explain a bit more about stale-while-revalidate is used in this project? I found i very hard to understand how it works in this example.

the now.json file:

"routes": [
    {
      "src": "/api/(.*)",
      "dest": "backend/api/$1"
    },
    {
      "src": "/auth/(.*)",
      "dest": "backend/auth/$1"
    },
    {
      "src": "/backend/(.*)",
      "dest": "backend/$1"
    },
    {
      "src": "/_next/static/(?:[^/]+/pages|chunks|runtime)/.+",
      "continue": true,
      "headers": {
        "cache-control": "immutable,max-age=31536000"
      }
    },
    {
      "src": "/static/models/(.*)",
      "dest": "frontend/static/models/$1",
      "headers": {
        "cache-control": "immutable, max-age=31536000"
      }
    },
    {
      "src": "/(.*)",
      "dest": "frontend/$1",
      "headers": {
        "cache-control": "s-maxage=31536000, maxage=0, stale-while-revalidate"
      }
    }
  ],

[zeusdeux]

@TommySorensen We know that Zeit purges the cache when a new alias is created or an existing one is updated and when s-maxage is reached. Let’s keep this in mind as it helps reason around the behaviour you are seeing.

When you reload using F5, the browser tries to do everything it can to obtain a cached copy from some cache (browser cache, shared cache [CDN], …, origin). In your case, the shared cache sees caching related headers (such as If-Modified-Since, etc) and responds with the content it has which is outdated as you mentioned. Why is it outdated even though your lambda has new data? Well, my guess is that while your lambda does indeed have new content every month, you don’t redeploy the lambda every month and the cache doesn’t get purged of old data. Furthermore, since there’s a big mismatch between how long content is fresh from the lambda’s perspective (1month) and how long the content is fresh from the shared cache’s perspective (~12months), you end up with the behaviour you’re seeing when you hit F5.

When you reload using Shift + F5 or Ctrl + F5 or Cmd + Shift + R, etc, the browser tries to bypass all the caches (by setting or unsetting certain headers such as cache-control: no-cache, no If-Modified-Since, Pragma: no-cache, etc) which results in the shared cache being bypassed and your lambda being hit. Which in turn leads to fresh content being delivered with a 200 OK directly from the origin ie your lambda.

[TommySorensen]

Thanks @zeusdeux That really helped. One thing i cant seem to get working is that if i cache everything in the frontend folder /(.*) for 365 days, and I browse to the website within the 365 days, is that if I reload the URL (only f5), it will always give me back the “old” data with an 304, even thought i changed the data in that lambda that is fetching something that changes on a monthly basic. But if i ctrl+f5, i will get a 200 response with the new data. So the lambda is working, but is always returning the cached state.