Does M.AutoInit() add avoidable startup cost on a low-traffic Materialize page?

The goal is to choose between Materialize CSS's one-line M.AutoInit() and explicit calls such as M.Modal.init(el, options) for a low-traffic page — assuming the 1.x M.* API, not the 0.x jQuery plugins — with per-page-view scripting cost as the priority.

M.AutoInit() scans the DOM at load and instantiates every matching component. On a page whose modal, dropdown, and sidenav sit behind clicks most visitors never make, that construction happens regardless. Explicit initialization can defer it until interaction, but shifts the burden into per-page init maps: nodes inserted after load are not covered by an earlier auto-init pass, and removed components need teardown.

The open trade-off is simplicity versus startup work. A single global call survives page edits without maintenance; manual init concentrates execution only where UI is actually triggered. Because client-side cost is per view and per device, low monthly traffic alone does not reduce it.

Does M.AutoInit() instantiate hidden, never-opened components before any interaction, and is that overhead meaningful on a modest page? At what point do per-page init maps justify their upkeep? What cleanup do dynamically inserted components require under manual init?