Hello Addy, so nice to have you here!
Would you say that DOM nodes are heavy in terms of memory occupation? Even if they're not rendered? Taking about 6k-14k nodes here, including text and comment nodes.
Are element nodes heavier in terms of memory and CPU hogging?
How about HTML parsing? Is a big HTML document (like, 400k unzipped) a problem for mobile devices?
Asking for, huh, a friend that has to struggle with a client that doesn't think reducing the HTML to the bare minimum is meaningful for performance.
Everything has a cost and too many DOM nodes = unhappiness.
Back in 2016, the Chrome team observed that most sites we were profiling had 5000+ DOM nodes. Ideally, your page should stick closer to 1500 for mobile. At that time Chrome was optimized for a rough maximum of 32 element deep documents. We definitely handle things a lot better than this, but you're in the sweet spot if you're able to stay within these constraints.
With respect to HTML parsing costs, I always lean on shipping the greatest value to users in the fewest bytes possible. That said, I would probably do some auditing on the costs of sending down 400K of unzipped HTML (see if there's a real issue with CPU and memory usage on your target devices) and visualize to your client the difference of shipping less if that's the case.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.