jQuery Forum

There have been persistent reports of poor performance when scrolling lists on touchscreen devices. These reports go back more than a year. See here:


The issue has been acknowledged:


... and much work has been done recently on improving performance in general. And, yet, the problem persists.

I think I have identified just what the problem is, have a simple work-around, and want to foster a discussion about a more complete/permanent solution.

In my experience, the problem occurs only with lists whose items are links. That is, the items are clickable/tappable with the content wrapped in an <a> tag. On most mobile touchscreen devices, performance of these types of lists is abysmal.  Frankly, it's just unacceptable. I would be embarrassed to release an app or web site with this kind of list performance.

There is no problem with lists whose items are NOT links. They scroll quite nicely, at least on the devices on which I have tested. (Admittedly limited - iPhone 4 and 4S, iPad 1.)

Proposed solutions have often revolved around specific enhancements - typically shadows, box-shadows, and gradients - and have involved removing these from list items.

Todd's comments (in the second link above) got me thinking about what is really going on here, and I think I've figured it out. It's really quite simple.

JQM essentially turns each list item in this situation into a button. And that button has up/down/hover states. JQM adds and removes styles to the items when they are touched, or clicked/hovered with a mouse. And that, in a nutshell, is the problem.

People have different styles of scrolling with a finger-swipe. There are slow, careful swipers. And there are fast, sloppy swipers. And there are those who "flick" and treat the screen like a trackball. The slow, careful swipers have less trouble. The flickers have the most. (Thanks, Todd, for your observations, which made this clear to me. No, as you reluctantly admit - it's unreasonable to ask users to change their scrolling style.)

The other clue was that I was seeing the problem using either a standard full-page scroll, or when using iScroll to create a scrolling region. If JQM has a problem with scrolling, iScroll should surely fix it right? I mean, if I can demonstrate that iScroll has great performance on my device, I should be able to use it with JQM and it should still have good performance. But it doesn't. iScroll doesn't fix it, because JQM is still doing all that button-state changing!

So, what is happening as you scroll is that you are changing the up/down/hover states of "buttons" (list items) that you touch. Because of different swipe styles, as well as the effect of kinetic/elastic scrolling on many devices, you may activate several "buttons" while you are swiping. (With kinetic scrolling, your finger will "slip" relative to the items.) You can see this clearly in the distracting visual effects as you scroll. You will see a "piano key" effect - on a fast device - and a horrible mess on a slower one.

Depending on how complex the styling, this will slow things down either a little or a lot, as the poor little CPU in the mobile device tries to keep-up with all those events. JQM is busy flipping styles around, and the browser is trying it's best to keep up with it. Unfortunately, most/all of this is going on in the CPU, and so any hardware acceleration goes largely out the window.

Not only does this slow things down, but it's a horrible visual distraction. What useful purpose does all that piano-key nonsense serve? I say "none".

So, here, really is the fundamental issue. It's inappropriate to use up/down/hover states on list items. At least not whilst scrolling. It serves no useful purpose, it's slow and it's visually distracting.

Fortunately, (at least for mobile touchscreen app developers, like myself) there is a quick and simple workaround. Just a bit of CSS to make it go away:

*.ui-listview *.ui-btn-up-c,
*.ui-listview *.ui-btn-down-c,
*.ui-listview *.ui-btn-hover-c
  {
  /* Copy your .ui-btn-up styles here */
  }

/* Repeat for each of your themes */

If you make ALL of the styles the same for up/down/hover you will see near-native performance. Even so much as a different border will impact performance drastically. Make all the styles the same for all of these states, and the visual distraction goes away. The CPU time needed to do all that redrawing goes away. The user is much happier. The developer isn't embarrassed to release the app.

(On most platforms at least) the issue is NOT shadows or gradients. Feel free to use them. The browser is just pushing around a bunch of pixels when you scroll, and in many cases now with hardware acceleration. The complexity of the styling affects only the initial drawing time, not scrolling performance.

Now, my workaround is only good for a pure touchscreen application. That's fine with me, but others are developing websites that target multiple devices. The effects are appropriate when using a mouse. They might even be desirable on a touchsceen - just not while scrolling!

Perhaps my CSS workaround can be combined with media queries, so that it will only apply if a touchscreen is in use?

However, I am concerned that there are still CPU cycles being wasted because JQM is still flipping the styles, though at least now the browser is saved from doing all that updating of the screen. I don't know if that's a lot of CPU cycles or just a few. But perhaps further improvement can be made.

The best solution, it seems to me, would be to somehow disable these events once scrolling starts. I don't know if that would require modification of JQM, or if it's something that can be easily implemented by a developer using unmodified JQM. It wouldn't be good if you have to add a ton of code to work-around this issue. There should be some clean, permanent solution.

I'll leave it to others to work-out what that solution is. I have mine. But I thought I'd share my findings and try to start a discussion about how to fix this in a broader sense.

--------

Now, there's  still something bothering me about this: the performance is not as bad on the JQM demo/doc site as in my own app. That is, on the same device, I can point Mobile Safari at the demo site, and while the performance is not great, it is also not horrible. In my app it is horrible. I looked for differences, I tested using only the distribution CSS (no additional CSS). And, still, the difference. It gets REALLY bad if you used data-inset="true".

The only difference I could find is the use of <nav></nav> around the <ul>. So, I added that, and no difference.

I can only speculate there is some difference between using the Safari app on iOS and embedding the platform WebKit control in an app. I understand there may be a difference in Javascript speed between the two. Perhaps there are other issues as well. (Hardware acceleration.) Curiously, though, the problem occurs on both an iPhone4 with iOS 4.3.5 and  iPhone 4S with ioS 5.01. And I *think* read that the Javascript issues was fixed in 5.0.

See below link. Apparently, the "Nitro" Javascript acceleration is unavailable to apps and only used by the Mobile Safari app. At least in 4.3, which is when it was introduced:

http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/