DOM access is the slowest part of JS in the same way that Window API access is the slowest part of a C++ app on Windows.
"DOM access" covers everything from "WebGL calls" to "stroke a path in canvas" to "hey, redo the layout of the whole page" to "hey, store this string in a database" to "add an attribute to this element", depending on who you're talking to. Some of these are slow (redoing the layout of the whole page). Some are not too bad (e.g. in a current Firefox on Mac typical WebGl calls are about 2x slower than a corresponding GL call from a C program last I measured).
Now obviously storing data in a DOM attribute is slower than storing it in a JS property, because there is more overhead: DOM attributes can dispatch mutation notifications, can affect styling, etc. If you don't need any of those things, you might be paying some cost that you don't need to pay. This typically starts to matter once you're doing a _lot_ of attribute sets, though. A typical attribute set in a modern browser is in the <100ns range on modern laptop hardware.
"DOM access" covers everything from "WebGL calls" to "stroke a path in canvas" to "hey, redo the layout of the whole page" to "hey, store this string in a database" to "add an attribute to this element", depending on who you're talking to. Some of these are slow (redoing the layout of the whole page). Some are not too bad (e.g. in a current Firefox on Mac typical WebGl calls are about 2x slower than a corresponding GL call from a C program last I measured).
Now obviously storing data in a DOM attribute is slower than storing it in a JS property, because there is more overhead: DOM attributes can dispatch mutation notifications, can affect styling, etc. If you don't need any of those things, you might be paying some cost that you don't need to pay. This typically starts to matter once you're doing a _lot_ of attribute sets, though. A typical attribute set in a modern browser is in the <100ns range on modern laptop hardware.