How best to detect the need for CSS hardware-acceleration "hinting"

How best to detect the need for CSS hardware-acceleration "hinting"

It's pretty well-known that Safari (both desktop and mobile) has some issues with transitions that can be helped by using a CSS trick ("null 3D transform") to "hint" the browser that hardware acceleration is wanted on certain elements. This can be useful to improve page transitions and scrolling.

The symptom, for example, with scrolling is that scrolling will be choppy until the user has scrolled all the way to the bottom. Once they have, then scrolling is smooth. The browser has cached the content as the user scrolled. This can be remedied by judiciously applying a null 3D-transform, and then the elements will be cached in advance. You get smooth scrolling (but at the expense of greater up-front setup time.)

Other browsers don't require this (because they handle pre-caching automatically) and, in fact, it can actually degrade performance.

The problem is coming up with a suitable browser test, so that this CSS can be applied only when needed.

Does anyone know of a reliable way to test this "feature" in code? That would be ideal. But it also might be rather complex. Try to measure the "stuttering"? Ugh!

Absent a feature test, then we have to use a user-agent test. But thanks to browser makers, this is a mess! Everybody is spoofing everybody else.

"Safari" is certainly not a reliable test. In fact, in some cases, it isn't even a part of the user-agent string on legitimate Safari browsers. (It's omitted for UIWebView and full-screen.)

I thought AppleWebKit might be good, but, no, Chrome spoofs AppleWebKit if running on OSX!

You can then exclude "Chrome", but then who ELSE is spoofing AppleWebKit? (But it it really IS something built on AppleWebKit, then I want a positive test.)

Is there some specific feature that can distinguish real Apple Webkit from some other WebKit pretending to be Apple WebKit?

My concern here is specifically the need for hardware acceleration hinting. For now, I am just excluding Chrome, since the biggest issue seems to be that this unnecessarily slows-down Android browsers.