Thank you for the re-measurement. Before anything else, please note one critical timeline fact, then two new findings from our side, and one request.

1) YOUR MEASUREMENT WINDOW ENDED BEFORE THE AI-SHIELD WENT LIVE
The AI-shield (v75q) was installed on the live server on September 22 at 05:58:38 server time (UTC) — the exact timestamp is displayed on its installation screen (a copy was shared with us; it matches the owner's local clock at 09:00 Cairo / UTC+3). Your report covers "latest records through September 22, 2026 05:34 UTC" — i.e. it ends 24 minutes BEFORE the shield was installed. Therefore all four timings you listed (377s / 305s / 95s / 69s) are, by construction, pre-shield records. With this site's low traffic, the "latest record" per route can easily be hours old.
Additionally, a 69s /ai/ask is no longer physically possible: since 05:58:38 UTC every Gemini call is capped at 12s total (5s connect), max 3 concurrent calls, beyond that an immediate 503, and answers are cached for 6 hours.

2) OUR OWN EXTERNAL MEASUREMENTS, POST-SHIELD (real client, HTTP/2 via your CDN)
• 06:12 UTC: / → 200 in 0.39-0.52s; /admin/login → 200 in 0.32-0.41s; /admin/branches → 302 in 0.37-0.40s; static asset → 0.36s
• 06:18 UTC: / → 200 in 0.43-0.56s; /admin/login → 200 in 0.40-0.51s; /admin/branches → 302 in 0.33-0.43s
• The CDN response header itself reports x-hcdn-upstream-rt: 0.350 (origin round trip ≈ 350 ms)
All sub-second, consistently. Our request: please re-slice your access logs strictly for requests with timestamps ≥ 05:58:38 UTC, September 22, and share per-route p50/p95 for that window only. We propose the 24-hour stability window be counted from the last configuration change (05:58 UTC), not from records that predate it.

3) NEW FINDING — INTERMITTENT EDGE CHALLENGE FROM hcdn
During testing, roughly one third of plain GET requests from a datacenter client received HTTP 403 (6,192-byte page, title "Checking your browser before accessing. Just a moment...") served by the hcdn edge in ~0.15s with no origin hit. Any automated measurement client that does not execute JavaScript will be challenged or measured at the edge instead of the origin. Please confirm whether your measurement tool executes these challenges — if not, route timings it reports may be polluted by the challenge layer.

4) FULL DISCLOSURE — ONE FUNCTIONAL REGRESSION FOUND AND FIXED TODAY
While measuring /ai/ask today (06:13 UTC) we found the endpoint answering in 0.44s but with HTTP 400 "assistant inactive": GEMINI_API_KEY was absent from the runtime environment (very likely masked for some time by a stale cached config, which our September 21 config:clear step removed). Functionally this returned an instant error, so it did not and does not contribute to slowness — but it disabled the AI assistant for visitors. We deployed a restore tool (v75r) that recovers the key from the server's own .env backups or accepts it via POST only (never in URLs, so it cannot leak into access logs), re-clears config, and verifies. The owner is applying it today. Expected /ai/ask behavior going forward: instant (cache hit), ≤ 15s (12s API cap), or an immediate 503 when the 3 slots are busy — never a long worker hold.

In short: the fix timeline is ahead of the measurement window you reported. Re-slice at ≥ 05:58:38 UTC and we believe you will see what we see — sub-second responses on all four routes. If any request inside the post-05:58 window still exceeds 5 seconds, we will treat the complaint as open and investigate immediately.
