Save early, before the Editor actually presses save. Only commit the change if the Editor actually presses save.
This will improve the Editor experience by making save faster at the expense of CPU time. Predict well enough, or do enough processing client side, then you won't need extra server side CPU used.
What is more precious to you? The human Editors or some dumb pieces of silicon?
However, the method I mentioned can be done with zero extra server load if done correctly. I've done this before with other editors, and it definitely did not take a team 12 months to complete.
It is a full stack optimisation however, from UI all the way through the DB and the rest of the stack. Now that they're using only 10% load, there's plenty of room to breath.
Saving a draft of what someone may have spend hours typing into a crash prone browser is good UI practice regardless.
Saving a draft is indeed good UI practice, but best practice is never "regardless" in the real world, particularly in cash/manpower strapped non-profits.
I think the effort of my optimisation would cost less time and effort, and give better results.
It would also waste less Editor time.
Mediawiki already allows drafts to be saved.