Don’t try to force hardware acceleration on elements that are placed on a touch-scroll-pane! …and here’s why:

I personally love the  ‘-webkit-overflow-scrolling: touch’-feature as it allows you to implement a scroll pane for mobile devices with just writing two lines of css and no need of hasseling around with JS to make some content scroll smooth ect., however this approach also comes with a drawback: hardware acceleration will cause performance-issues on iOS (maybe other mobile devices, though it was only tested on an iPad2 running iOS6)

In my last post I was writing about forcing html5 hardware acceleration on iOS6, turns out you do NOT want to do that on every element as this can also cause the performance to drop, pointed out by the following example:

The scenario is the following: The base is a big scrollpane using ‘-webkit-overflow-scrolling: touch‘ that contains many images that are scaled from 100px width to 50px width.
When combining this with forced hardware acceleration it will cause a massive drop in fps while scrolling.

Try it yourself by pointing your mobile browser to the following urls:
Images Example Version 1: http://goo.gl/XIn9e – NOT hardware accelerated, very good framerate
Images Example Version 2: http://goo.gl/DKC1u  - hardware accelerated, low framerate while scrolling, however seems not to affect the execution of JS as the displayed fps does not drop

The only difference between Version 1 and Version 2 is:

The examples with HTMLImages shows a very huge drop in performance, however this effect is not solely limited to images but also <div> and other elements, even though it takes a larger number of divs to bring down the performance this way, it is possible:

Divs Example Version 1: http://goo.gl/1iF71 – NOT accelerated, fluid, high fps
Divs Example Version 2: http://goo.gl/qkdwm – accelerated, less frames on scrolling, seems to affect the execution speed of JS code

So bottom line: Forced hardware acceleration and ‘-webkit-overflow-scrolling: touch;’ do not work together very well!