Skip to content

The display timing engine costs 939 B on every first paint for an output read through one flag #673

Open

Description

@ozzyfromspace

The display engine splits into two layers with very different economics, measured separately:

  • The verdict ladder (the reveal gate, earned-success, first-post-edit-blur stickiness, the own-path error filter, the four show* projections and the displayState enum they derive from): 258 B, with showErrors read 51 times. The best byte-per-mile in the whole audit. Not a candidate for anything.
  • The timing layer (DEFAULT_TIMINGS, FOCUS_OUT_GRACE, PENDING_LIVENESS_MS, withLiveness, nearestReviewAt, the rearm forward-progress guard, the MAX_DELAY clamp, the visibilitychange listener, the retained DisplayMachine map, and the fieldValidatingSince / fieldTransformingSince anchor maps with their inc/dec/clear/migrate bookkeeping): 939 B, the largest single number in the audit, on every consumer's first paint. Its entire consumer-visible output is showPending, read 6 times in the only real app.

An opt-in is the wrong answer and is not what this proposes. Anti-flash is a hard-won behaviour that every consumer should get without reaching for a knob, and a knob nobody turns is worse than the bytes.

The shape worth investigating is an automatic lazy chunk. A form with no async validator and no async transform can never produce a pending state, so the timing machinery could dynamic-import on the first async open. Nobody configures anything, and the bytes leave the eager path for apps that never do async work.

Unmeasured, and that is the point of this issue. Two things need to be established before this is worth planning:

  1. How much of the 939 B is machinery versus wiring. A lazy arm saves runtime work, not bytes, unless it is a real chunk boundary, and the eager closure currently reports async: 0 because a prior pass deleted the last one.
  2. What the first pending state costs when the chunk has to load. Pending states are already asynchronous by definition, so a tick of latency is plausibly free, but that needs measuring rather than assuming.

If (1) comes back saying most of the 939 B is wiring that cannot leave, close this. The measurement is the deliverable.


Found in the 2026-09-18 feature audit (main@b4a64ef9, eager baseline 33,204 B gz). Every byte figure is a measured ablation, not an estimate.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PnAVwFjpvKQNppAMkSvoiH

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions