Thursday, May 6th, 2010

iPad JavaScript Shockingly Slow?

Category: JavaScript, Mobile, Performance

>Douglas “My Guns Are Bigger Than Yours” Crockford sent us a pointer to Moonwatcher’s post on entitled “My MacBook Pro runs JavaScript 26.7x as fast as my iPad“.

After Moonwatcher ran SunSpider on the iPad, he concluded:

It’s one thing not to be able to run Flash apps. But JavaScript performance like this effectively means the iPad can’t run complex JavaScript apps either. Interesting.

Many folks in the comments are quick to retort that:

And have you noticed this to be an actual problem, in practice, or are you just obsessing over benchmarks?

and:

Heavy ajax sites like gmail run quite well on the iPad. Yes, I have an iPad and use it for such sites everyday (including for writing this post).

But it got me curious: what have you noticed about the iPad’s performance and your web apps? Does it inhibit the types of experiences you’re trying to create?

In my own experience, mobile devices have shown us that JavaScript-driven animations are generally a bad idea when you want multiple sprites or extreme performance, but CSS animations are there to fill the gap. Otherwise, JS perf. on mobile is generally fine for what I’ve tried to do.

I also find it interesting that while the iPad is slower than my MacBook Pro, I rarely notice it–and I certainly haven’t noticed anything as dramatic as an alleged 27x gap. Have you?

Related Content:

Posted by Ben Galbraith at 6:00 am
27 Comments

++---
2.3 rating from 3 votes

27 Comments »

Comments feed TrackBack URI

Yes, I already have verrry slow web sites running on iPad. I non’t know why:
- First time it was the autocomplete field of yellow page (french) now it seems to works
- Second time it was a Facebook wiget or ads displayed on a third party site.

Comment by nextone — May 6, 2010

We did some proof of concept ( read:fast and completely unoptimized ) work recently for sales and definitely saw some sluggishness using JS animations. Stuff that looked great in the emulator skipped around a little bit on the actual device. Clearly, turning something around in a day didn’t help matters, but it was noticeable. The CSS animations we did were better, performance-wise.

Comment by roblarsen — May 6, 2010

@roblarsen

I recently experimented with using CSS3 animations (because that would eventually have to replace flash graphically) on Apple’s own iPad page.

My version uses CSS3 animations instead of scripaculous effects and only works in Chrome / Safari.

http://www.visualmedia.nl/html5/ipad/

CPU usage is around 40% with both solutions.

Comment by Tinus — May 6, 2010

Just got my IPad yesterday and tried browsing me.com and I only got information how to set up the me.com service on my IPad, no way to log in through the web interface. not nice if you wan’t to check out your mac account on your wife’s IPad. if me.com is not working well on an IPad and Jobs recommending developers to rewrite their flash apps in HTML dose not make sens. Still I think the IPad is an awesome device :)

Comment by sigurthor — May 6, 2010

Yes, we noticed that the interactive Ajax-interface of our pricewatch section (example) is notably slow on the iPad. I haven’t had time yet to pinpoint the exact culprit but it is on my list to be investigated further.

Comment by crisp — May 6, 2010

I’ve definitely noticed extremely sluggish performance in a complex web app that runs fine in even IE7 on a Motion tablet PC.

Comment by ifwdev — May 6, 2010

While JS performance absolutely can be improved (always, without a doubt) the comparison hinks – I would much rather see a benchmark comparing the iPads performance with for instance Palm, Blackberry OS5 or any other mobile device. After having worked with most other mobile platforms (iPhone, Palm, Android, Blackberry, S60, Windows Mobile, VF360) the iPad does an amazing job (Palm as well btw.). On top of that webkit offers very good HTML5 and CSS3 support (yes, not complete and with issues).. Once we start making use of stuff like the flex-box model we should start delivering much leaner/faster apps – if we don’t make use of those, then we’re doing something wrong and a benchmark like this will only tell me about the speed of JS which is only half the bill. On top of that I am not even sure I want to use an app written for the desktop paradigm on an iPad – there’s a shift happening in app development here and I fear that most “desktop” apps tested on the iPad have not been written with that shift in mind (Multitouch?). Back to the JS benchmark, we are seeing much faster development on the mobile front than we are used to in the desktop world so even though the iPad is not as fast as a MBP (hell, the top line of Apples laptop series) it does already do a great job and you can write amazing apps. Did you give http://static.uxebu.com/~david/touchscroll/ a try on the iPad? It performs very well, and uses exactly what is supported best by the device.

Comment by nonken — May 6, 2010

I may be wrong, but scientifically, what does sunspider really bench ? Javascript execution ? not only. When I look at the source code of sunspider, I can see that the starting date for the test is not just before the test run. There is a lot of javascript to PARSE before EXECUTING the test.
So my questions are : am I wrong ? if not, do you think parsing javascript may be significant in the time calculation wrt execution ?

Comment by gaalan — May 6, 2010

I have an ipad and have never noticed any websites being slow on it. This may be benchmark fetishizing. That aside, is the ipad *supposed* to be any faster than an iphone? When folks call it a giant iphone, i think that is supposed to be an accurate description. It’s not a small laptop, after all, so it’s performance should not be closer to a laptop than an iphone. What sort of processor is in it, compared to an iphone? I know apple fabbed the processor, but that aside, isn’t it just the same thing that’s in an iphone?

Comment by JohnDeHope3 — May 6, 2010

Yes! I’ve noticed.

I work on a web app that does a ton of charting. We’ve been using Flex for several years, but now Flash is persona non grata so we’ve been considering alternatives. HTML5/Canvas is the only choice left so we’ve built some prototypes.

These prototypes work great on the desktop/laptop, and are basically worthless on the iPad. Just to preemptively hit the “why javascript question”: Charts need interaction (tap/rollover for point details, drag on chart to zoom in). To do this, you need to write (increasingly complex) javascript. And on the iPad, it’s a comparitively lousy experience.

To the argument “well the iPad isn’t supposed to be a PC”: Fine, but it is supposed to be the “best web experience”. Yet here I am trying to support a device that can’t do what it needs to be able to do.

I’m not a big flash fan, but it does handle interaction well – the iPad browser does not (the apps of course, do). The notion that HTML5/CSS/Javascript can replace flash doesn’t hold water if the Javascript engine isn’t up to the task.

My overarching concern is that if I can’t do complex interactions on the web, then creativity has been stifled – and that’s too bad. So the javascript engine matters!

Comment by CR4 — May 6, 2010

I haven’t noticed most JavaScript-heavy sites running particularly slow on my iPad.

I have noticed that animating images through JS isn’t great though. A 250ms jQuery fadeOut/In on a 680×400 image results in only 1-2 transition states before the animation finishes, which looks pretty clunky.

Comment by Encosia — May 6, 2010

I tend to agree

- JQtouch on the ipad flickers and feels slow
- RaphaelJS works but slow
- ProcessingJS feels also slow
- scripty2.com promising library, horrible performance on the ipad. OK with a pentium 4 running FF or Chrome + xubuntu

All these nice libraries could have helped with the ipad, but nope. too slow..

Comment by emailandthings — May 6, 2010

I noticed the performance issue – and was disappointed. A simple test case of dragging a DIV around with a few styled images inside was not good. Lots of lag. Minimal processing going on there – just watching the touch events and reacting. I am going to pursue the CSS to see if I can find the friction. Opacity and gradients seem the likely suspects. If the compositing engine is gagging, I’m guessing those two properties would point right to it. Would like to hear other experiences!

Comment by RelativeEdge — May 6, 2010

I’ve run up against some pretty major slowdowns using the YUI libraries. Although I expect the various script libraries will optimize over time to accommodate an ever-larger mobile market, developers will probably have to lean more heavily on CSS transitions and native html5 solutions for some time to come.

Comment by portilaj — May 6, 2010

Have you checked out the Steve Jobs HTML5 web experience on the iPad YouTube video, that has some sad results on speed and experience on JavaScript aided HTML5 pages.

Comment by Poetro — May 6, 2010

Here is a simple test you should all try out. Install Safari 3.0.4 alongside your latest Safari 4 using Multi-Safari (http://michelf.com/projects/multi-safari/). Now run SunSpider on both browsers on the exact same machine. Guess what ? Safari 4 typically scores 10x faster than Safari 3.

So, question is, were all your webapps completely unusable in Safari 3 ? Do you really think Safari 4 is that much faster ? I’m confused by the results too, and think that it points to some fundamental flaws with SunSpider.

Comment by rudro — May 6, 2010

It’s all well saying what apps today stress it? its about the apps of tomorrow, the performance is shockingly bad. But hey, no apple product is a higher performer, they look pretty and get insanely well marketed.. thats the apple way

Comment by meandmycode — May 6, 2010

Interesting results from Encosia… I though jQuery was supposed to be using css3 animations when it was present and using JS otherwise. So I was expecting better performance from it. I could have been making an ignorant assumption I guess.

Comment by tack — May 6, 2010

I guess “magical” != fast. I had no expectations this thing would be any faster than the iPhone in browser performance. I doubt it will be anytime soon either. Once again, Apple gives us form over function.

Comment by leptons — May 6, 2010

I wonder if this is the mobile safari caching limit issue from the iphone rearing its ugly head again due to the ipad using essentially mobile safari 3.x + exposing true inline html5 audio/video tag support. This would explain the similar performance between iphone and ipad even accounting for obvious hardware advantages on ipad.
Mootouch “solved” the performance issue by chopping up mootools leaving only the critical little pieces; jqtouch can’t due to the (relatively) monolithic jquery core structure.
My (purely pie in the sky) hope is that iphoneOS4 will solve this for both iphone and ipad.

Comment by rdza — May 6, 2010

For clarity we were using basic jquery effects and some stuff out of jqtouch. We were also working with the device in the hands of the sales team on another continent, so we weren’t able to tinker and try to improve the performance. I’d love to revisit to see what we could do stripping away some of the library stuff.

Comment by roblarsen — May 6, 2010

I would have expected that our site would run awfully slow after these tales. But that is definitely not the case. We run a client side comet styled hotel price comparison engine, all parsing is done client side. And the iPad can handle parsing 400 hotels in one response, where Opera chokes and crashes.

So I guess, you need to analyze exactly where and on what part the iPad is slow. And build around those limitations.

Comment by V1 — May 7, 2010

Has anyone played Pinball HD or similar 3D game on the iPad? Now those are mostly relying on the GPU and are highly optimized by a compiler, but I don’t see any reason why javascript animation can’t eventually get to that level of smoothness, at least for animation using canvas. If not by tweaking Safari to get better performance, then by optimizing the A4 (in the next iPad) for intensive javascript operations.

Webkit already uses hardware acceleration for 3D canvas, and iPad Safari uses acceleration for video decoding. Does anyone know if the GPU is used or can assist in rendering basic HTML?

Comment by webxl — May 7, 2010

We did some heavy testing of the iPad to support or cross Flash and HTML5 graphing library http://www.zingchart.com/flash-and-html5-canvas/
and found that an iPad in general is only about 1.5 – 3x faster than an iphone 3GS for some typical web page stuff. Sunspider tests and other synthetics show it just doesn’t have great horsepower JS wise. I have pinball HD and it rocks but that isn’t what you are seeing on an iPad for web app rendering. I know because we are collecting a log of it, so if you want submit your data in benchmarking with PC, Mac, ipad, etc. We have over 1000 different runs from all sorts of environments http://www.zingchart.com/flash-and-html5-canvas/#speedtest It is curious to see but the meme of canvas beats flash or flash beats canvas is a bit too simplistic for what data shows. It depends quite a bit on app, number of cores you have, OS, browser, and very likely what else you have going on locally. A good read on this subject can be found here http://www.craftymind.com/guimark2/

Comment by ThomasAPowell — May 7, 2010

If you run your js apps in webkit (via AIR) you’ll get the same results.

Comment by jaysmith — May 8, 2010

Why do people jump all over Microsoft for their slow JS performance, but when it comes to Apple they say “But does it really affect the performance of real world sites?” That was the same thing Microsoft said, and the answer is a resounding YES!!!!!

Comment by fredclown — May 9, 2010

I have been developing a magazine engine, in jquery, for over a year and it’s pokey on the first gen iPad. The majority of the speed loss is the addition and removal of classes to show or hide pages. (all pages visible makes the system even slower) using one of the third party browsers does improve js animations. (I don’t use CSS animations because it needs to work on all devices)

Comment by nosarious — August 20, 2011

Leave a comment

You must be logged in to post a comment.