Apple Store web site: Poor performance culprit is JavaScript
Posted by Pierre Igot in: MacintoshJuly 21st, 2008 • 4:28 pm
Following my post last week about the poor performance of the Apple Store web site in Safari on my machine with limited bandwidth, I received an e-mail from a reader who suggested that I turn off JavaScript in Safari:
Safari has poor Javascript performance compared to other browsers and having a high latency connection like Satellite probably makes things worse.
Today, I did just that, and the difference is indeed striking. While, in a limited bandwidth situation, the Apple Store web site still takes a long time to load, due to the many elements that each page contains, at least when JavaScript is turned off, the Safari application itself no longer becomes unresponsive (with the Spinning Beach Ball of Death) for extended periods while (slowly) loading the Apple Store web pages.
Since I have limited experience with the Apple Store web site on a Mac with ample amounts of bandwidth, I do not know how much the JavaScript performance is tied to the bandwidth and is negatively impacted by a slow connection.
But there is no doubt that turning off JavaScript, at least on my machine, makes a very noticeable difference. For a multitasker like me, there is a big difference between “slow” and “slow and unresponsive.” I can deal with “slow” (I am used to it), but “slow and unresponsive” means that I no longer have the option to multitask within Safari.
And it definitely looks like Safari’s JavaScript performance is the main culprit here.
Of course, it is not really practical to disable JavaScript in Safari, because a number of web sites depend on it, and it also adds some functionality to the Apple Store web pages themselves. (I am not sure to what extent JavaScript is actually required in order to be able to use the store.)
But the fact that the poor performance is so clearly linked to Safari’s JavaScript implementation means that there is hope that it could be improved soon. Because, as reported here and here, Apple’s WebKit team is precisely in the process of implementing a new JavaScript interpreter in WebKit, on which Safari is based.
So presumably the poor JavaScript performance is something that Apple is actually fully aware of, and something that they are actively working to address. Whether they can really deliver remains to be seen, but the signs are encouraging.
July 22nd, 2008 at Jul 22, 08 | 9:51 am
Well I hope you are right, but I may discourage your hope. Indeed, I observed similar sluggishness with Safari (2.x at that time — 2006), especially when using discussions.apple.com (which is at least as weird as your Apple Store example, this site being apparently quite light in terms of dynamic features), and after much testing of various possible causes, I found out that the culprit was JavaScript too. I temporarily soved the problem by disabling JavaScript (for the discussions.apple.com site only: you can use SafariStand for per-site settings), and shortly after I completely switched to Camino, which does not exhibit such issues.
Although I am still using Safari from time to time, I am preferring Camino for extensive day-to-day browsing, therefore I do not know whether things have changed for discussions.apple.com with recent builds of Safari.
I agree that it is quite strange that sites hosted by Apple work so poorly with their home-made browser, hence I suspect that this is a combination of configuration settings (system-wide) that may yield such an issue (in my particular case and in yours), otherwise it should have been fixed for a long time…
July 22nd, 2008 at Jul 22, 08 | 10:20 am
I don’t know what the quality of your connection is, but apparently it can have a lot to do with it (i.e. JavaScript causes Safari to lock up while it’s waiting for data to come in).
I am cautiously optimistic that things will be better soon. Optimistic, because Apple is actually working on JS performance. Cautious, because Apple tends to ignore the needs of people with slow connections, and I don’t expect things to be any different this time. So my hope is that the improvements they make will, somehow, also benefit people with slower connections, even if it’s not their intention.
I do occasionally use Camino, but there are things about Safari that I prefer (tab management, for one thing). Plus Apple’s site is the one that causes me most problems. Most other sites I visit regularly don’t have any such problems with JavaScript. (The other thing that tends to cause Safari to temporarily lock up is embedded media.)
July 22nd, 2008 at Jul 22, 08 | 12:26 pm
I’m intrigued by this, because JavaScript performance has always been a selling point for Safari. It consistently benchmarks among the fastest browsers at JavaScript.
See e.g. Coding Horror, Dromaeo, Ars Technica (this last also includes a result with a build of the new, faster interpreter for Safari (SquirrelFish)).
It may be that Safari’s JavaScript implementation is peculiarly hobbled by a high latency connection — that it’s faster with a high-speed, low-latency connection, but makes poor assumptions for a connection like yours.
You might want to try downloading a WebKit nightly build, which now include SquirrelFish, and see how it goes. It won’t interfere with your existing copy of Safari, and in my experience they tend to be quite stable, as long as you don’t have InputManager hacks on your Safari.
I don’t *know* if this will help; I don’t have performance issues on the Apple Store. Page loads in Safari are 2-3 seconds for the home page and 1-2 seconds on subsequent pages on my system, an iMac with a cable modem. Heck, the Apple Store is faster than Betalogue for me :-P
July 22nd, 2008 at Jul 22, 08 | 1:52 pm
Thanks for the various pointers. The poor performance on my machine probably has more than a little to do with the latency and poor overall bandwidth performance. (Things can vary. Depending on network traffic conditions, the providers “reserves the right” to throttle you back down to dial-up speeds for a while if you’ve been downloading more than your fair share of stuff… Needless to say, no hard numbers are provided, which gives them the right to do pretty much as they please.)
It could very well be that JavaScript is particularly sensitive to latency, that it often needs an immediate response in order to proceed to the next step, and locks up until it gets that response.
But it’s precisely the locking-up part that I have a big problem with, because it locks up the entire Safari environment, not just that particular window. To me, an engine that cannot handle network fluctuations and unpredictability gracefully is a badly designed engine.
People with ample bandwidth (i.e. most Apple engineers, apparently) do not seem to care about this and will blame our poor connection, but there are numerous aspects of Mac OS X and its applications that are properly designed to handle network fluctuations gracefully, whether it is intentional on the part of the developer or it just stems for the intrinsic quality of the underlying tools.
I can live with “slow.” I can live with “slow and unresponsive,” as long as the lack of responsiveness is strictly limited to the part of the program that absolutely requires data from the Internet before being able to proceed.
But a lack of responsiveness that extends to the entire application, including the multiple other windows and tabs that have nothing to do with the site in question, is clearly unacceptable.
Yet this is what exactly happens in Safari when visiting the Apple Store with JavaScript on, on my machine.
I don’t have any InputManager hacks in Safari anymore, since Safari 3.0 meets most of my needs in that department. So I will give the WebKit build a try.
(Betalogue.com is hosted by a French provider, so there is inevitably a slightly longer response time than for a site hosted in North America. Of course, with my own connection, I don’t notice the difference at all, but I am sure it can be noticeable. One day, when I have some free time, I might do a site redesign and move to a different provider. But right now I have other priorities. And apart from possible performance issues, this particular provider has been relatively trouble-free for me in the past couple of years.)
July 22nd, 2008 at Jul 22, 08 | 3:23 pm
Yeah, it seems to me like Safari is locking more than it should while waiting for JavaScript; my main purpose was to point out that ‘poor JavaScript performance’ is an incomplete diagnosis — when it comes to actually *executing* JavaScript, Safari does pretty well.
Besides my recommendation to try the WebKit nightly, have you experimented with Firefox 3? In benchmark environments its JavaScript performs similarly, but it may or may not have the same problems with high latency and locking up the app while it waits. Again, I can’t really speak to this because it doesn’t come up on my connections.
(Betalogue’s not terribly slow or anything, 4-5 seconds to the Apple Store’s 2-3. It was just a handy comparison. On my machine & connection, the Apple Store is faster than most other blogs I frequent, too.)
July 22nd, 2008 at Jul 22, 08 | 4:00 pm
I not a JavaScript expert but having used Safari a lot and knowing that you have a more than powerful machine, I am sure it’s not actual performance that’s playing a role there but more the way in which things interact.
From what I have seen it can be a real problem if a web page calls a JavaScript just when the page loads. Of course people frequently want to do exactly that because the script is supposed to set something up on the page to make it look right when it appears. Now add a slow connection (or broken server) to that which prevents all relevant script parts to be loaded when the page should be displayed. I imagine that the browser easily locks up in that situation because it’ll have to decide whether to display the imperfect page or to wait until everything necessary arrived.
I guess the real implementation problem there is that you see the whole browser locking up rather than just the tab in question. And that certainly deserves more careful implementation. I’v certainly seen similar problems myself even for tiny scripts simply because the server wasn’t available.
July 22nd, 2008 at Jul 22, 08 | 5:20 pm
Just to make it clear: my “JavaScript problems” occurred with a perfectly good connection (> 10 Mbit/s)…
July 22nd, 2008 at Jul 22, 08 | 5:28 pm
Indeed, as Dan Ridley suggests Firefox may not suffer from the same sort of problems. Having used Opera for a long time in a few different sorts of set-ups (but not a satellite link, I confess), I am quite confident you would not experience similar problems with it.
July 23rd, 2008 at Jul 23, 08 | 10:09 am
I am afraid I have to report that neither WebKit nor Firefox provides any improvement over Safari in this department. With both browsers, i still get significant application responsiveness issues while the Apple Store pages are loading.
So I guess the only “option” is to turn off JS, which is not an option, really. And the next version of Safari probably won’t make any difference either.
July 23rd, 2008 at Jul 23, 08 | 12:05 pm
That’s unfortunate. I guess next time you hit the Apple Store, you can fire it up in a different browser than the rest of your tabs? :-P
Not the sort of workaround you should have to do on a modern desktop, and it doesn’t help if you don’t know ahead of time that a particular site is going to be a problem.
July 23rd, 2008 at Jul 23, 08 | 2:40 pm
Yes, I am going to have to create a stand-alone browser with Fluid just for the Apple Store!
The Apple Store web site is really the only one I use regularly which exhibits this kind of problem. The only other times I get temporary unresponsiveness in Safari is with pages with embedded media (mostly stuff played by the QuickTime plug-in). Which is why I strongly suspect a problem with the JavaScript code used by the Apple Store. But of course if the problem only affects people with a satellite-based connection, Apple is unlikely to even notice it.