Steadier Sites Under Heavy Automated Traffic
A regional cache layer, cache headers on every public API response, and strict limits on page and list parameters keep sites fast when bot traffic surges.
Automated traffic does not arrive politely. A single sustained burst can spread thousands of requests across dozens of edge locations, each holding its own cache, so a page that is comfortably cached in one part of the world is still being rendered from scratch in another. Basker now places a regional cache in front of the origin for public sites and custom domains, so simultaneous requests for the same page collapse into as few as one render and traffic spikes stop translating into slow pages for real visitors.
Cached where it counts
Every public API response now carries an explicit cache instruction, rather than a handful of endpoints doing so and the rest relying on a default. Two ways of bypassing the cache without signing in have also been closed: previously, a stray preview cookie or an unrecognised parameter could force a live render on every request. Genuine preview and editor sessions are unaffected, because they are recognised by a validated token rather than the presence of a cookie.
Sensible limits on list requests
Page and limit values on lists and API endpoints are now strictly read and capped before any lookup happens. A nonsense value falls back to the first page rather than returning an error, and a very deep page number clamps to the maximum, so legitimate deep links still work while an automated crawl cannot manufacture endless unique, expensive requests. Nothing changes for normal browsing, pagination controls, or ordinary API use.