iOSアプリケーション開発会社の経営者であるDrew Crawford氏は、現在のモバイルWebアプリケーションが遅く、また、近い将来にその遅さが大幅に改善されると思えない理由を、ブログ記事（内容が充実しており、良く調査して書かれている）の中で明らかにした。 このブログ記事は、これより前に書かれた記事への追加記事である。前の記事で氏は、モバイルにおけるJavaScriptのパフォーマンスがデスクトップの10倍遅いことを指摘した。その記事は激しい批判を浴びたため、Drew氏はそれに答える形で、さらに詳細な内容の記事を記した。モバイルの貧弱なパフォーマンスと、それについての改善が見られない理由は、次の3つに分類される。
- モバイルのARMプロセッサのスピードと、デスクトップのx86プロセッサのスピードとの違い
- JavaScriptエンジンのパフォーマンスの傾向
- ガベージコレクションに関連する特定のメモリ消費量
Drew氏が述べる2つのボトルネックは、CPUとメモリである。CPUの制約には2つの側面がある。すなわち、CPUのパワーと、実行効率である。Drew氏は、今のx86プロセッサがARMプロセッサ（iPhoneやハイエンドのAndroid端末で使用されている）の10倍速いことを指摘している。
私はハードウェアのエンジニアではありませんが、大手の半導体メーカーに勤めていたことがあります。当時の同僚は、パフォーマンスの大部分はプロセスルール（例えば、それは『ナノメートル』という単位で計測します）によるものであると、私に教えてくれました。iPhone 5の素晴らしいパフォーマンスは、プロセスルールを45nmから32nm―約3分の1―に縮小したことによる影響が少なくありません。しかし、もう一度同じ事をするためには、Appleはプロセスルールを22nmに縮小しなければならないでしょう。
トランジスタのサイズ縮小に関する知識や投資のほとんどがIntelの手中にある。Drew氏は、ARMが近い将来にx86に追いつくことはありそうにないと主張している。実際、ARMがパフォーマンスの差を縮めることよりも、IntelがARMに匹敵する消費電力のx86プロセッサを生産することの方がはるかにあり得る話だ。
パフォーマンスの2つ目の側面は効率である。どの程度効率的にCPUサイクルが使用されるのか、すなわち、JavaScriptのコードをCPUはどれぐらい効率的に実行できるのか？
多くの優秀なソフトウェアエンジニアがつまずくのはここです。思考のプロセスはこのようになります―JavaScriptはより速くなった！これからも速くなり続けるだろう！
前半部分は正しいでしょう。JavaScriptはかなり速くなっています。しかし、今がJavaScriptのピークでしょう。これ以上速くはなりません。
このベンチマークは私のMacで動かしたChromeのバージョン8によるものです（2010年12月にリリースされた、実行可能な一番古いバージョン）。現在はバージョン26です。
違いに気付きませんか？それは違いが存在しないからです。 CPUに最適化された最近のJavaScriptに、重要なことは何ひとつ起きていないのです。
2010年当時よりもWebが速くなったような印象を感じるのであれば、それはおそらく速いマシンを使っているからであり、Chromeの改善とは何の関係もありません。
Drew氏によると、JavaScriptのパフォーマンスが大幅に改善されない理由は明快であるという。
JavaScriptのJITコンパイルは60年前のアイデアを60年かけて研究してきた成果であり、考えうる限りのプログラミング言語すべてにおいて、文字通り何千もの実装で証明されている素晴らしいアイデアでした。しかしそれを実装した今、60年物のアイデアを使い果たしてしまったのです。皆さん、これでお終いです。ショーは終了しました。今後60年で、何か別の素晴らしいアイデアを育てることが出来るかもしれません。
モバイルWebの2つ目の制約はメモリである。くり返すと、メモリ使用には2つの側面がある。利用できる総量と、利用効率である。
現代のモバイル端末はかなりの量のメモリ（通常は512GBか1GB）を積んでいるが、オペレーティングシステムはアプリケーションにそのような大量のメモリを使わせない。メモリの大部分はオペレーティングシステムによって、オペレーティングシステム自身とその他の実行中のアプリケーションのために使われる（マルチタスク）。
（前略）iPhone 4Sでは基本的に約40MBのメモリ使用で警告が出始め、約213MBでkillされます。iPad 3では約400MBで警告が出て、約550MBでkillされます。
Drew氏は、iPhone 4Sの解像度の場合、カメラで写真を撮ると1枚あたり30MBのビットマップデータを消費すると指摘している。それはつまり、オペレーティングシステムがメモリ不足でアプリケーションをkillする前に、RAMに7枚の写真が使用可能なスペースがあるということを意味している。そのため、特にアプリケーションで写真やビデオといったメディアを扱う場合、メモリが極めて限られたものであるとして、何がどの程度メモリを必要とするのかについてかなり注意する必要がある。
メモリの2つ目の側面は効率である。JavaScriptはガベージコレクションを備えた言語である。開発者を楽にするために設計されたその機能のおかげで、開発者は手動でメモリを管理する必要がない。しかしながら、ガベージコレクションにはコストがかかる。そのコストは、メモリに制限のある環境において、劇的に増加することとなる。
このグラフは次のことを示しています。『必要なメモリの6倍のメモリがある限りは、安泰です。しかし、必要なメモリの4倍に満たなくなってくると、悲惨なことになるでしょう。』
この調査結果は、メモリに制限のある環境において、ガベージコレクションのパフォーマンスが急激に低下することを示しています。もしあなたがPythonやRuby、もしくはJSのプログラムを書き、デスクトップPC上で動かす場合、グラフの右側が示すような感覚を覚えるでしょう。そして、ガベージコレクタの遅さを1度も経験することはないでしょう。
この挙動は、AppleがiOS上でのObjective-Cのガベージコレクタを決してサポートせずに、その代わりにガベージコレクタではなくARC（iOSとMac両方に）を採用した理由だったと思われる。
Drew氏は自身の記事で興味深い主張をしているが、Brendan Eich氏のツイートにあるように、すべてのアプリケーションがCPUやメモリの制約を受けるわけではない。例えば、ゲームやマルチメディアを扱うアプリケーションなどといった、いくつかのカテゴリに属するアプリケーションだけがこれらの問題に直面することとなる。とはいえ、Drew氏の記事（10,000単語もの長い記事）はモバイルWebにおけるパフォーマンスに興味がある読者にとっては、読む価値があるものとなっている。