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

Short answer

On a modest, low‑traffic page the synchronous cost of M.AutoInit() is usually a handful of milliseconds—often below the noise floor of typical performance budgets. If the page contains only a few components (modals, dropdowns, sidenavs) that are rarely opened, the extra work is negligible. Manual initialization can shave off those milliseconds, but it introduces maintenance overhead: you must keep an element‑to‑init map, remember to init dynamic inserts, and handle teardown for removed nodes.

Why Auto‑Init runs everything up front

• It performs a DOM walk on load and instantiates every component that matches a selector.
• Instantiation creates the component object, attaches listeners, and sets initial state synchronously.
• Hidden or never‑opened components still incur this work, because visibility is not checked.

When the cost matters

• Pages with many components (e.g., dozens of carousels, tables, or complex side‑navs) can see cumulative costs of 10–30 ms.
• High‑resolution budgets (e.g., 4 ms per component for a 200 ms total) may trigger alarms if Auto‑Init is used.
• Very small pages (<10 KB of JS) or pages that are already performance‑optimized typically absorb the cost without perceptible impact.

Manual init trade‑offs

• Defers work until a component is actually interacted with.
• Requires a mapping of elements to M.Component.init calls.
• Dynamic DOM changes (e.g., innerHTML inserts) must be manually initialised.
• Removed nodes need explicit teardown to avoid memory leaks.

Practical recommendation

1. Measure the page: open DevTools Performance, record a load with M.AutoInit(), and note the time spent in that function.
2. If the measured time is 5 ms or less, keep M.AutoInit() for simplicity.
3. For larger pages or when you want to shave the few milliseconds, replace Auto‑Init with manual calls for components that are actually used.
4. Keep a small init map (e.g., document.querySelectorAll('.modal').forEach(el=>M.Modal.init(el));) and add a comment that new components must be added here.
5. If you add elements via JavaScript after load, call M.Modal.init(newEl) or re‑run M.AutoInit() on that subtree.
6. Optionally, use requestIdleCallback to schedule manual initialisation after the main load, reducing perceived latency.

Missing diagnostic detail

Do you currently have any components that are inserted dynamically after page load? If so, that will influence whether you need to keep manual init or rely on re‑scanning.