Google is pervasive about associating Chrome with being fast. It’s was their primary pitch when they first announced it. Back when Firefox went 1.0, it wasn’t so much about speed but “not sucking” as all the geeks liked to say. Given IE 6 was the competition, that was likely the best marketing on earth. Sure it was faster, but sucking fast wasn’t nearly as good as not sucking. Not sucking encompassed the missing features, broken rendering, crashing, constant parade of security problems. It summarized the product surprisingly well for not being an official slogan by any means.

Google now launched Chrome for iOS. On the desktop Chrome and Safari both use WebKit, Chrome applies it’s own touches to make things faster. Notably they have their own JS engine. Safari also has it’s own JS engine. This is the secret sauce of performance. In the iOS world however Apple being the totalitarian dictator decided that iOS will provide WebKit and JS. If your app has any web browser functionality it will utilize these API’s and not implement it’s own engine. Verbatim:

2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript

Google Chrome for iOS however is Google integration into a reskinned experience of Safari. It’s the same browser. Just a new UI bolted on with some Google features integrated in. It’s not a separate browser. It’s a UI.

That however doesn’t stop Google’s marketing machine (I’d argue Apple marketing’s top rival) from putting “fast” as the second word:

Browse fast with Chrome, now available on your iPhone, iPod touch and iPad. Sign in to sync your personalized Chrome experience from your computer, and bring it with you anywhere you go.

It goes on to clarify:

Search and navigate fast, directly from the same box. Choose from results that appear as you type.

So Google isn’t truly misleading. It’s just very strategic wording.

The truth of the matter however is that Google Chrome on iOS is substantially slower than Safari. Safari uses Nitro to accelerate JavaScript, which powers most of the complicated websites that will slow down a browser on any modern device. Apple however restricts Nitro to Safari, and doesn’t let third party apps like Google Chrome use it. This is still the case as of iOS 5, and I believe is the case in iOS 6, though I haven’t personally verified that.

How much slower is Google Chrome on iOS in comparison to Safari? Well Here’s a SunSpider test I did on my iPad 3:

Safari

============================================ RESULTS (means and 95% confidence intervals) -------------------------------------------- Total: 1817.9ms +/- 0.2% -------------------------------------------- 3d: 214.7ms +/- 1.1% cube: 72.3ms +/- 0.7% morph: 57.9ms +/- 0.9% raytrace: 84.5ms +/- 2.2% access: 224.9ms +/- 0.6% binary-trees: 44.4ms +/- 1.7% fannkuch: 96.2ms +/- 0.6% nbody: 56.0ms +/- 0.0% nsieve: 28.3ms +/- 2.7% bitops: 141.0ms +/- 0.4% 3bit-bits-in-byte: 23.4ms +/- 1.6% bits-in-byte: 29.5ms +/- 1.3% bitwise-and: 37.8ms +/- 1.5% nsieve-bits: 50.3ms +/- 0.7% controlflow: 15.7ms +/- 2.2% recursive: 15.7ms +/- 2.2% crypto: 123.3ms +/- 0.6% aes: 70.5ms +/- 0.5% md5: 29.4ms +/- 1.3% sha1: 23.4ms +/- 1.6% date: 274.4ms +/- 0.7% format-tofte: 139.8ms +/- 1.1% format-xparb: 134.6ms +/- 0.7% math: 175.1ms +/- 0.3% cordic: 61.5ms +/- 0.8% partial-sums: 74.4ms +/- 0.7% spectral-norm: 39.2ms +/- 0.8% regexp: 70.8ms +/- 0.6% dna: 70.8ms +/- 0.6% string: 578.0ms +/- 0.5% base64: 78.3ms +/- 1.9% fasta: 68.1ms +/- 0.9% tagcloud: 109.5ms +/- 1.2% unpack-code: 207.5ms +/- 1.2% validate-input: 114.6ms +/- 0.7%

Google Chrome

============================================ RESULTS (means and 95% confidence intervals) -------------------------------------------- Total: 7221.0ms +/- 0.1% -------------------------------------------- 3d: 802.7ms +/- 0.2% cube: 230.9ms +/- 0.6% morph: 297.3ms +/- 0.5% raytrace: 274.5ms +/- 0.1% access: 1112.0ms +/- 0.2% binary-trees: 98.4ms +/- 1.1% fannkuch: 609.6ms +/- 0.2% nbody: 247.9ms +/- 0.2% nsieve: 156.1ms +/- 0.4% bitops: 957.2ms +/- 0.2% 3bit-bits-in-byte: 210.4ms +/- 0.6% bits-in-byte: 232.9ms +/- 0.2% bitwise-and: 188.5ms +/- 0.4% nsieve-bits: 325.4ms +/- 0.2% controlflow: 129.5ms +/- 0.3% recursive: 129.5ms +/- 0.3% crypto: 493.3ms +/- 0.2% aes: 214.3ms +/- 0.4% md5: 140.2ms +/- 0.3% sha1: 138.8ms +/- 0.5% date: 381.1ms +/- 0.3% format-tofte: 214.2ms +/- 0.2% format-xparb: 166.9ms +/- 0.5% math: 770.7ms +/- 0.2% cordic: 316.6ms +/- 0.2% partial-sums: 243.2ms +/- 0.3% spectral-norm: 210.9ms +/- 0.4% regexp: 1340.2ms +/- 0.2% dna: 1340.2ms +/- 0.2% string: 1234.3ms +/- 0.6% base64: 175.7ms +/- 0.5% fasta: 205.6ms +/- 0.2% tagcloud: 284.0ms +/- 2.3% unpack-code: 370.1ms +/- 0.9% validate-input: 198.9ms +/- 0.6%

Quite a bit slower.

So really, if you’re using Chrome on iOS, it’s because you absolutely love the design and integration with Google’s services, and are willing to trade off considerable JavaScript performance for those perks.

That however doesn’t stop many people from thinking it’s fast. Just in the past few minutes I’m able to find these Tweets among the thousands streaming across the web. I won’t mention or link to them directly (you could find them however if you wanted):

“Chrome for iOS is FAST, takes the mobile browsing experience to a new level.” “I like it! It’s fast and can sync with Chrome desktop, which I use all of the time.” “Liking #chrome on #iOS very slick, fast and clean looking” “using chrome on my iphone right now.. cant believe how fast it is” “That chrome for iOS is freaking fast but so basic. No tweet button, no add-on. Man I kinda disappointed. I give ’em 1 ‘fore the update” “Chrome for iOS? Hell yes!! So fast! #chrome” “Google Chrome for iOS is fast.” “Holy hell Chrome is fast on the iPad.”





The most touted feature isn’t actually a feature. It’s technically not even there. The numbers and the technology insist that it’s not (they prove it’s actually slower). But that’s what everyone is ranting and raving about. You could argue Google’s UI is faster, but I’d be highly skeptical that Google’s found Cocoa tricks Apple engineers haven’t. Perhaps a UI transition or two makes you think it’s faster or more responsive, however even that I can’t find any evidence of.

All the hard work the Google engineers did squeezing their services into a compact simple to use UI are ignored in favor of this non-existent feature. And as a developer who can’t ignore such a thing, I will say they did a great job with their UI.

I present to you, the power of marketing!