One change, to the PR preview template that fxcss init ships: the base-branch render is cached between pushes to a pull request.
Every preview run rendered both the base branch and the pull request. On a real theme repo that was 87% of all runner minutes, and a fifth of everything went to runs a newer push cancelled — usually after the base half had already finished. Base captures are deterministic (it is the contract fxcss's own CI asserts on every change), so re-rendering them on each push reproduced a result already proven identical.
The cache key names everything that can change a pixel — base commit, runner image, Firefox version, fxcss version, and the workflow file — with no near-match fallback: a base captured on one Firefox diffed against a head on another would blame the pull request for the upgrade. The base is saved the moment it renders, not at job end, so a run that a later push cancels still leaves its base behind for that push.
What it does and does not save. GitHub scopes caches to the branch that created them, so this helps a pull request's second push onward, not its first. A PR that takes six pushes to land renders the base once instead of six times.
Regenerate with fxcss init --force to pick it up. actions/cache@v5 joins the Node 24 floor test.