Precompress the immutable dashboard runtime to preserve request responsiveness #431

Closed
opened 2026-08-09 22:09:45 +00:00 by timmy · 0 comments
Owner

Problem

The 442 KB fingerprinted browser runtime is gzip-compressed at level 9 on the ASGI event loop for every cold request. Local audit measurements show about 39 ms CPU per request and serialized latency under concurrent cold launches, even though the runtime is immutable and assembled once at startup.

Vertical slice

  • deterministically precompress the content-addressed runtime once during frontend build
  • negotiate gzip directly at the runtime route, with identity and gzip;q=0 preserved
  • bypass runtime middleware recompression while preserving immutable caching, CSP, Vary, and exact content length
  • use a balanced default level for remaining dynamic compression

Acceptance tests

  • identical sources produce byte-identical gzip bytes (mtime=0)
  • gzip clients receive the precomputed representation and exact compressed content length
  • identity and gzip;q=0 clients receive original bytes
  • repeated runtime requests never invoke dynamic gzip compression
  • concurrent runtime cold requests do not serialize compression work and /healthz remains responsive
  • full suite passes

No historical issue or recent commit covers precompression/event-loop responsiveness. Related #417 only introduced HTTP gzip negotiation and transfer-size coverage.

## Problem The 442 KB fingerprinted browser runtime is gzip-compressed at level 9 on the ASGI event loop for every cold request. Local audit measurements show about 39 ms CPU per request and serialized latency under concurrent cold launches, even though the runtime is immutable and assembled once at startup. ## Vertical slice - deterministically precompress the content-addressed runtime once during frontend build - negotiate gzip directly at the runtime route, with identity and `gzip;q=0` preserved - bypass runtime middleware recompression while preserving immutable caching, CSP, `Vary`, and exact content length - use a balanced default level for remaining dynamic compression ## Acceptance tests - identical sources produce byte-identical gzip bytes (`mtime=0`) - gzip clients receive the precomputed representation and exact compressed content length - identity and `gzip;q=0` clients receive original bytes - repeated runtime requests never invoke dynamic gzip compression - concurrent runtime cold requests do not serialize compression work and `/healthz` remains responsive - full suite passes No historical issue or recent commit covers precompression/event-loop responsiveness. Related #417 only introduced HTTP gzip negotiation and transfer-size coverage.
timmy self-assigned this 2026-08-09 22:09:45 +00:00
timmy closed this issue 2026-08-09 22:22:04 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#431
No description provided.