Public: anyone can read this; the crew can change it.

/signin and /signup name their Server-Timing phases and answer under 10 ms #4116

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

`/signin` and `/signup` now name their Server-Timing phases. In the test app each answers well under 10 ms. I did not check what production's 9.5 ms and 8.8 ms are made of.

shipped production is serving it deploy 119f4d2

opened this

/signin and /signup now name their Server-Timing phases. In the test app each answers well under 10 ms. I did not check what production's 9.5 ms and 8.8 ms are made of.

  • Phases: /signin notes session, settings (the signup-mode read), claim (the has-admin check) and render. /signup notes session, signup (is signup closed), users (the first-account check), claim and render. The change is in src/web/pages/site.ts. The pages show exactly what they showed before.
  • Where render stops: it times only the page() call, not building the form body. The form body is built just before it, so its time shows up in app but in no named phase.
  • Test: test/signin-timing.test.ts asserts each page's phase names and an app under 10 ms.
  • Debt list: the Server-Timing sweep test kept a debt list that still named both pages as owing phases. I removed those two entries so the sweep now enforces them.
  • Which phase costs the most: I didn't find one. In the test app none of the reads comes close to the 10 ms budget. Once this deploys, the production Server-Timing header on these two pages will show whether a read or the render is the cost.
  • Checks:

- Tests: the new test, the sweep, and the sign-in, sign-up and first-admin tests pass. - Type check: bun x tsc --noEmit could not run here. It stops on "Cannot find type definition file for 'bun'", so the forge's check is the first real type check of this change.

Closes #4106

commented

/signin and /signup now name their Server-Timing phases. In the test app each answers well under 10 ms. I did not check what production's 9.5 ms and 8.8 ms are made of.

  • Phases: /signin notes session, settings (the signup-mode read), claim (the has-admin check) and render. /signup notes session, signup (is signup closed), users (the first-account check), claim and render. The change is in src/web/pages/site.ts. The pages show exactly what they showed before.
  • Where render stops: it times only the page() call, not building the form body. The form body is built just before it, so its time shows up in app but in no named phase.
  • Test: test/signin-timing.test.ts asserts each page's phase names and an app under 10 ms.
  • Debt list: the Server-Timing sweep test kept a debt list that still named both pages as owing phases. I removed those two entries so the sweep now enforces them.
  • Which phase costs the most: I didn't find one. In the test app none of the reads comes close to the 10 ms budget. Once this deploys, the production Server-Timing header on these two pages will show whether a read or the render is the cost.
  • Checks:

- Tests: the new test, the sweep, and the sign-in, sign-up and first-admin tests pass. - Type check: bun x tsc --noEmit could not run here. It stops on "Cannot find type definition file for 'bun'", so the forge's check is the first real type check of this change.

Approved

Preview works: /signin answers app;dur=5.2 and /signup app;dur=4.0, each naming its phases (session, settings/signup, users, claim, render). Markup is unchanged, no design-system surface touched, JavaScript-off unaffected. The debt-list entries are removed so the sweep enforces them, and the new test fails without the change. Next two: (1) time the authForm body build as its own phase, since today it lands in app but in no named phase; (2) rename the inner const app in test/signin-timing.test.ts, which shadows the module-level app.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs