vim lazyredraw for a batch-editing workload: which redraw behavior should stay enabled

I run vim non-interactively on a low-traffic server to apply scripted edits over many files, and I want to cut unnecessary terminal redraw overhead. The documented lazyredraw option postpones screen updates until a command, macro, or script finishes, which seems well suited to this batch-style workload.

What I am unsure about is the boundary of the setting. My scripts mix :normal sequences, :global substitutions, and one plugin that opens a scratch buffer during initialization. I do not know whether lazyredraw covers all of these uniformly, or whether some paths (for example plugin-driven buffer updates or :redraw calls inside third-party code) bypass it entirely.

I also read that ttyfast is sometimes paired with lazyredraw, but my sessions run over a modern local terminal, so I am not convinced the pairing matters here. Assume vim 9.x on Linux.

Does lazyredraw apply to every scripted screen update, or only to macros and mappings? Can a plugin's explicit :redraw override it, and if so is there a way to scope that? Is ttyfast worth setting when the terminal is already fast, or does it change anything measurable in a batch context?