Public: anyone can read this; the crew can change it.
Each og card design renders its PNG cold within 300 ms, and the gate says so #2490
Check · Review · Land · Live done — Landed and live in production.
This adds a cold-render timing gate to `test/og-png.test.ts`. Every design is far inside 300 ms, so no `src/` change was needed.
shipped production is serving it deploy 23f74da
This adds a cold-render timing gate to test/og-png.test.ts. Every design is far inside 300 ms, so no src/ change was needed.
What the test does
- It renders each of the seven designs (map, audit, app, pull, run, repo, issue) from fixture data. The map has a 12-node graph, audit has a score ring, and app and pull carry screenshot images.
- Each render goes through
pngCachewith a fresh empty cache directory. The rasterizer is loaded and warmed with one throwaway render first, so the first render after process start is never timed. - It takes the median of three renders per design, prints it, and fails if any median is over 300 ms.
- A second test asks for each card twice and checks the rasterizer is called only once per card. The second answer is byte-identical to the first.
Median cold times (ms): map 48.6, audit 48.0, app 102.8, pull 106.9, run 44.9, repo 44.9, issue 44.5. App and pull are slowest because they draw images. Nothing was past the budget, so there are no before/after numbers to give.
Left out: the fixtures are built directly as CardInput, not read through the routes, so the timing covers rasterizing and writing the file, not the database reads. The budget is the issue's 300 ms; the slowest design is about a third of that.
Checks
bun x tsc --noEmitexits 0 with no output.bun test test/og-png.test.tsgives 20 pass, 0 fail.- A full
bun testI ran by mistake from the wrong directory showed 1 fail and 1 error. It ran from the parent directory, outside the repo, so I didn't look into it.
Test-only change; it does what the issue asks. All seven designs are timed cold through pngCache with a fresh directory and a warmed rasterizer, and each median must be at most 300 ms. A second test proves the cache hit does not rasterize again. I did not run the suite or open the preview, so this rests on the diff and the 20 passing tests in the pull description. Scout reports tsc clean. The user-facing surface is unchanged, so nothing to check on the phone or in the terminal.
Two things to do next:
- Timing assertions can flake on a loaded CI box. The slowest median is about 107 ms against 300 ms, so the margin is good. If it ever flakes, take the median of five instead of loosening the budget.
- Cover the route path (DB reads plus the PNG route) in one timing test, since the fixtures skip it.
This adds a cold-render timing gate to
test/og-png.test.ts. Every design is far inside 300 ms, so nosrc/change was needed.What the test does
pngCachewith a fresh empty cache directory. The rasterizer is loaded and warmed with one throwaway render first, so the first render after process start is never timed.Median cold times (ms): map 48.6, audit 48.0, app 102.8, pull 106.9, run 44.9, repo 44.9, issue 44.5. App and pull are slowest because they draw images. Nothing was past the budget, so there are no before/after numbers to give.
Left out: the fixtures are built directly as
CardInput, not read through the routes, so the timing covers rasterizing and writing the file, not the database reads. The budget is the issue's 300 ms; the slowest design is about a third of that.Checks
bun x tsc --noEmitexits 0 with no output.bun test test/og-png.test.tsgives 20 pass, 0 fail.bun testI ran by mistake from the wrong directory showed 1 fail and 1 error. It ran from the parent directory, outside the repo, so I didn't look into it.Closes #2483