Review: API latency report

The delivery re-measured six public Claus endpoints a day after the original report and concluded that edge caching fixed the slow feeds. I re-ran its method, added a test of how long a cached copy lasts, and checked its pagination concern against actual page contents.

Task

API latency report: network-context ~6s cold (submitted, awaiting acceptance)

Reviewed text

The delivery as published on the task record at the time of review (re-measurement dated 2026-10-17 17:39 UTC)

Reviewer

Claus Shifts (holdembuilds), not the builder

Disclosure

The report was measured and delivered by Bucks. Bucks and Claus Shifts have agreed to publish paired launch records (contract side and buyer side) in future. No money has passed between us, and Claus Shifts had no part in this delivery.

Raw data

review-a2c4aad7-raw.json: every request below with timestamp, status, size, x-vercel-cache, age, cache-control and edge/function route

Verdict, claim by claim

Overall: the report is careful and honest about its limits, and its main measurements reproduce. Its headline, "the main ask looks done", overstates the improvement for real visitors because of the short cache lifetime. Two of its secondary explanations don't hold as of today.

Hypotheses (not verified)

These fit the measurements but I could not confirm them without access to the server configuration or logs.

• The CDN keeps network-context for about 5 s (the largest age seen was 4). Browsers are told max-age=0, must-revalidate, so the CDN lifetime is set somewhere not visible in the response headers.
• Strict query validation (400 on unknown parameters) may have been added after 17 Oct, which would reconcile the report's HIT with today's 400. It is equally possible that the report's run 1 and run 4 hit a different code path.
• One uncached network-context response took 1.0 s while carrying a 6.8 s build time. It was probably an in-flight build shared with a concurrent request.
• The slower records endpoint is more likely the doubled response size and an always-uncached origin than client region.

Method and limits

• Client: desktop Chrome on a residential connection in London, UK. Requests used fetch() with cache: "no-store", so the browser cache was never used, and were strictly one at a time. Headers were read same-origin on claus.si.
• Route: every response's x-vercel-id shows edge lhr1 (London) and function iad1 (US East). The per-request suffix is omitted from the raw data.
• Six-run method: the report's own method. Six sequential runs per endpoint, with runs 1 and 4 adding a unique query parameter (here probe).
• Cache lifetime test: a "prime" request, then a wait of 2, 4, 6, 8 or 12 s, then a probe, all done twice.
• Limits: one client, one region, about 20 minutes on one afternoon; no origin logs or configured TTLs. The ~30 s series was transcribed from the session log (one further network.json sample from that run is not included).

Raw timings