Question

When adapting a web page for mobile devices I always rely on css media queries.

Recently I no longer worry only about the screen size, but also the javascript engine of many mobile devices. Some common javascript effects that rely on window scrolls or a quick sequence of DOM transformations work really bad on slow devices.

Is there any way to guess the device performance so I can enable/disable elements that look bad on slow devices?

So far I can only think of bad solutions:

1. screen size. narrow screen “might” mean slow device
2. user agent information. I could look at the device, browser or cpu, but that does not seem a stable long term solution because of the amount of devices to consider

UPDATE:
Fixed my question to focus on one problem. In the comments there is a good solution for the touch interface problem.

Answer 1

It certainly seems as though there is no particularly good solution for this issue (which would make sense since this type of stuff is normally supposed to be the type of stuff that’s hidden away). I think either way your best starting with UA detection to take care of those platforms that are known to fall into one category or another. Then you’d have 2 options to flexibly adapt to unknown/uncertain platforms:

1. Progressive Enhancement: Start with a stripped down test and load a small performance test or tests to gauge the device performance and then load the files for the appropriate enhancements. Test such as already provided or at: Skip some code if the computer is slow

2. Graceful Degradation: Wrap those features that are candidates for causing unfavorable UX on slower devices in a higher order function that replaces them if they take too long on first execution. In this case I’d probably add it to Function.prototype and then allow an acceptable delay argument to be chained on to the function definition. After the first invocation store the time lapsed, and then on the second invocation if the time lapsed is over the delay swap out the function with a fallback. If the time elapsed is acceptable then remove the profiling code by swapping in the standard function. I’d need to sit down and work out sample code (maybe this weekend). This could also be adjusted by additional arguments such as to profile multiple times before swapping.

The first option would likely be the friendlier option, but the 2nd may be less intrusive to existing code. Cookies or collecting further UA data would also help from continuing to profile after information is retrieved.