A performance change is a shipped change like any other: it needs a token, a rollout, and a rollback. The token is what makes the new asset reachable to new visitors and the old one intact for cached ones. The rollback is what makes a bad change reversible in one step.
About 1 min of reading
Ship one performance change with a rollback
Token the new asset
Before you run it, say out loud what it will print. Then open the answer.
Confirm the old variant still serves
Before you run it, say out loud what it will print. Then open the answer.
Run the gate after the ship
Before you run it, say out loud what it will print. Then open the answer.
Practice the rollback
Before you run it, say out loud what it will print. Then open the answer.
Land the change, token the asset, keep the previous variant, run the gate, record the number. Five steps, and each one is checkable.
The previous tokened file is still served and the HTML edit is one line. Reversibility is a property of the files, not of the person.
The new CSS or JS gets a new token in the URL. Nothing in the HTML points at the old token, so a fresh visitor never asks for a stale file.
The previous tokened file stays served for the window. Removing it turns a cached visitor into a 400-range response.
Rolling back is editing the HTML back to the old token, not deleting the new one. The new file can stay unused on disk while you confirm the old one works.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.