- Shipped
- August 19, 2026 at 3:58 PM UTC
- Author
- Kamo
- Commit
- c38923b
Five rounds of fixes have each removed a real defect and none has fixed what is actually being felt, because every diagnosis so far has been inference from outside the browser. The ?perf=1 probe that would settle it has produced no samples, since it needs someone to drive a flagged session by hand. So it measures every navigation now. The on-screen readout stays behind ?perf=1 — nobody else sees a thing — but the timings are reported either way, which means ordinary browsing produces the evidence. Also measures cold page loads, which is the case actually being described: "opening any page other than the homepage". A click and a fresh load are different paths and only the first was instrumented. Navigation Timing already holds the answer for the second, so [navload] now records ttfb, html, first-contentful-paint, domInteractive, domComplete and load per page — that separates "the server was slow" from "the HTML arrived quickly and then the browser spent a second on 880 KB of JavaScript". Timings only: a path, some durations, a truncated UA. No identifiers, no query strings, nothing persisted beyond a log line. TEMPORARY — NavPerfGate, NavPerfProbe and /api/perf-probe come out together once the numbers point somewhere. Also fixes the post-deploy revalidate step, which silently did nothing. It called https://www.kamocrm.com from a runner with no egress to it, and continue-on-error hid the failure. It goes through kubectl exec into the pod now, which needs no egress and no secret in CI at all — the pod already holds REVALIDATE_SECRET. The port is a literal: interpolating $APP_PORT into the inner single-quoted sh -c string is what produced `wget: bad port ''`. Verified against the live pod, and verified the tag mechanism end to end — the banner went from the build-time 0 to the real 12.