Why does NotebookAutoSave -> True cause a UI lag on cell evaluation, even for small files, and can it be made asynchronous?

Questions
1

I have a package that defines custom InputAliases and applies them via:

CurrentValue[$FrontEndSession, InputAliases] = Append[CurrentValue[$FrontEndSession, InputAliases], $MyAliases];

With NotebookAutoSave -> True, I get a visible lag between a cell finishing evaluation and its output appearing on screen. This happens even in a brand-new notebook under 100 KB, so it isn’t about file size or accumulated output. Turning NotebookAutoSave off removes the lag completely.

My current workaround is to disable native autosave and trigger the save myself after the front end is idle:

DelayedSave[] := With[{nb = EvaluationNotebook[]},
RunScheduledTask[NotebookSave[nb], {10^-11}]];
SetOptions[EvaluationNotebook[],
NotebookAutoSave → False, CellEpilog :> DelayedSave[]];

This hides the lag, since the save happens after the output is already displayed.
Questions:

  1. Is NotebookAutoSave -> True fundamentally synchronous — does it block the UI thread until the write completes — or could something else (e.g., session-level InputAliases, front-end metadata) be responsible for a lag that appears only when this option is on?
  2. Is there a supported way to get autosave-like behavior without blocking, short of reimplementing it with RunScheduledTask/SessionSubmit?
  3. Is CurrentValue[$FrontEndSession, InputAliases] known to have performance costs distinct from a notebook-level InputAliases option or a stylesheet-based one?

Any insight or a better solution into how NotebookAutoSave is implemented internally, or known interactions with InputAliases, would help.

2

A computationally light automatic saving is provided by ResourceFunction[“SetNotebookAutoSaveTime”].

https://resources.wolframcloud.com/FunctionRepository/resources/SetNotebookAutoSaveTime/

3

Thanks @dangregori for the helpful suggestion. However, is there a way around the aliases to not lead to the lag in the first place?