The signed-out front page names its Server-Timing phases: session, shelf, render #4117

Signed-out / now reports session, shelf and render in Server-Timing, but the named phases cover only about half of app, not the 80% the issue asks for. The new test passes, bun x tsc --noEmit is clean, and the home tests pass. I did not run the full suite.

What changed

• studioDoor in src/web/studio/home.ts now notes session (takeSessionTime), shelf (already there) and render (notePhaseRest, the rest of the handler once the shelf read is out), the way studioHome does. It touches no markup, so it should rebase cleanly past #3870/#3942.
• test/front-timing.test.ts reads / signed out 15 times after a warm-up. It asserts the phases are exactly session, shelf, render, in that order, on every request.

The 80% coverage is not met

• I timed the handler locally: it takes about 0.75 ms, and the three phases account for essentially all of that.
• The rest of app (about 0.6 ms of roughly 1.4 ms) is spent before and after the handler, in src/http/server.ts. That covers host resolution for hosted children and apps, the security floor and header wrapping, and rate-header wrapping. home.ts can't see that time.
• The test therefore asserts the named phases are at least 40% of app (median over the runs), and a comment in the test says why. The issue's 80% would need a phase for that pre-handler work in server.ts, which is outside the files this issue names.
• Production's unnamed 7.7 ms is most likely in that same code. Locally the shelf is 0.1–0.3 ms and render about 0.7 ms, and neither is slow. I didn't measure production beyond the issue's figures, and I didn't change any speed.

Try it: curl -sI https://<preview>/ | grep -i server-timing shows app, session, shelf, render.

Closes #4105

Signed-out / now reports session, shelf and render in Server-Timing, but the named phases cover only about half of app, not the 80% the issue asks for. The new test passes, bun x tsc --noEmit is clean, and the home tests pass. I did not run the full suite.

What changed

• studioDoor in src/web/studio/home.ts now notes session (takeSessionTime), shelf (already there) and render (notePhaseRest, the rest of the handler once the shelf read is out), the way studioHome does. It touches no markup, so it should rebase cleanly past #3870/#3942.
• test/front-timing.test.ts reads / signed out 15 times after a warm-up. It asserts the phases are exactly session, shelf, render, in that order, on every request.

The 80% coverage is not met

• I timed the handler locally: it takes about 0.75 ms, and the three phases account for essentially all of that.
• The rest of app (about 0.6 ms of roughly 1.4 ms) is spent before and after the handler, in src/http/server.ts. That covers host resolution for hosted children and apps, the security floor and header wrapping, and rate-header wrapping. home.ts can't see that time.
• The test therefore asserts the named phases are at least 40% of app (median over the runs), and a comment in the test says why. The issue's 80% would need a phase for that pre-handler work in server.ts, which is outside the files this issue names.
• Production's unnamed 7.7 ms is most likely in that same code. Locally the shelf is 0.1–0.3 ms and render about 0.7 ms, and neither is slow. I didn't measure production beyond the issue's figures, and I didn't change any speed.

Try it: curl -sI https://<preview>/ | grep -i server-timing shows app, session, shelf, render.

Signed-out / and /front now report session, shelf and render in Server-Timing, but the named phases cover only about half of app, not the 80% the issue asks for.

The check failed because /front shares studioDoor, so it now names its phases. test/server-timing-sweep.test.ts still listed it as unnamed debt and fails any page that is both named and listed. I removed /front from that list and pushed. The sweep and test/front-timing.test.ts pass locally. I did not rerun the full suite.

What changed

• studioDoor in src/web/studio/home.ts notes session, shelf and render in that order, the way studioHome does.
• test/front-timing.test.ts reads / signed out 15 times after a warm-up and asserts exactly those three phases, in that order, on every request.
• The sweep's debt list drops /front (#3311).

Why the coverage test asserts 40%, not 80%:

• Locally the handler takes about 0.75 ms and the three phases account for essentially all of it.
• The rest of app is spent outside the handler, in src/http/server.ts: host resolution, the security floor and header wrapping. That is roughly 0.6 ms of about 1.4 ms, and home.ts can't see it.
• So the test asserts the named phases are at least 40% of app (median over the runs), and a comment in the test says why.
• Reaching 80% would need a phase for that pre- and post-handler work in server.ts, which this issue doesn't name.
• Production's unnamed 7.7 ms is probably in that same code. No phase is plainly slow locally: shelf is 0.1–0.3 ms and render about 0.7 ms. I didn't measure production beyond the issue's figures, and I changed no speed.

Try it: curl -sI <preview>/ | grep -i server-timing shows app, session, shelf, render.