Nope, because the order a Browser Engine loads assets is different in Chrome vs. Firefox vs. Edgium, too. Combine that with Firefox's messed up Accept header and you'll have them TOR Browser users, for sure. "@supports" in CSS is additionally a very unblockable way to track users, as it varies uniquely per-Browser-version as features of CSS get implemented and/or get fixed.
Usually traffic analysis for a client (with a specific ETag header) is enough to uniquely find out whether it's the exact same machine, hence that's what the header is made for.
The approach behind my browser tries to actively modify the contents of said malicious HTTP headers and to rewrite the HTML, CSS and other assets in order to force-cache everything and by laying off as much traffic as possible to surrounding peers. [1] But it's far from production-ready.
There's also a frightening amount of CSS features that can be used to track users very easily. @supports, @media, and a combination of <link media=""> and "srcset" attributes in a quick prototype was enough to track every client with around 98.3% accuracy, and I decided to not release the fingerprint.css project due to concerns how it might be abused in the wild.
Especially with unicode behaviour inside the CSS files themselves. CSS ident-tokens [2] are specified as "non-ASCII" so they can be emojis, too. And those have varying support across all Browser versions due to the ICU library being embedded in them (and being absolutely unique in every single subminor release I've tested so far).
