Access-Control-Max-Age: caching the preflight result

Without preflight caching, a cross-origin application makes two round trips for every write: an OPTIONS request and then the real one. On a high latency connection that doubling is the single largest cost of using CORS at all, and it is entirely avoidable for endpoints whose policy does not change from minute to minute.

Browsers cap the value regardless of what you send. Chrome clamps to roughly two hours and Firefox to roughly a day, and a much larger number is silently reduced rather than refused, so an enormous value neither helps nor causes an error. Something in the range of a few hours captures nearly all of the benefit.

The cached entry is keyed by origin, URL and the specific method and headers that were requested. Changing your policy therefore leaves clients with a stale permission for as long as their entry lives, which is the reason to keep the value moderate on any endpoint whose CORS rules you might tighten.

The value minus one turns caching off explicitly. That is occasionally useful while debugging, because otherwise a corrected preflight response is not consulted until the old entry expires, and it is easy to conclude a fix did not work when the browser simply has not asked again. A private window achieves the same thing without a deploy, since its preflight cache starts empty.