結論から言おう。パフォーマンスの点で、Firefox 3.5 RC1はFirefox 3.5 Previewとほとんど差がない。『Firefox 3.5はFirefox 3からどの程度速くなったのか』で扱ったテストセットを実施した結果、そう判明した。
テストに使用したのは、Firefox 3.5 RC1とコードベースが共通の、Shiretoko Nightly（3.5pre, ID:20090612044217）だ。これをFirefox 3.5 Preview（3.5b99, ID:20090605162636）と比較したわけだが、コンテンツが変動するものを除き、数値は上記『〜どの程度速くなったのか』から引用している。
また、予告していたとおり、Safari 4正式版（AppleWebKit/530.17）も比較対象とした。こちらはBeta版のテストを『過去最速のFirefox、しかしアピールすべきは総合力』で行っており、どこまで進化したかが見ものだ。
では、順次パフォーマンスを検証していこう。なお、各WebブラウザはWindows Vista SP2（32bit版）上で動作させている。
ロード時間
各Webブラウザの読み込み速度を、WebWaitで計測してみた。以下の表で「初回」とあるのは、ディスクキャッシュをクリアした状態で、ブラウザの起動直後に1回だけ指定ページを読み込ませた場合を指す。「平均」は、2〜4回目の読み込み時間（ロードの間隔は10秒）を平均したもの。両者の違いは、キャッシュを利用するかどうかだ。
このテストだけは、表示するコンテンツが日々変わっていくので、Firefox 3.5 Previewについても再計測している。
まず、はてなのフロントページを指定したケースの結果を示す。
| Shiretoko | 3.5 Preview | Safari 4 | |
|---|---|---|---|
| 初回 | 4.81秒 | 4.77秒 | 5.50秒 |
| 平均 | 1.31秒 | 1.43秒 | 1.95秒 |
ShiretokoとFirefox 3.5 Previewを比較すると、初回読み込みの時間にほとんど差はなく、平均読み込み時間だとわずかにShiretokoが上という結果になった。ただ、測定誤差のレベルであり、速くなったとまではいえない。
対するSafari 4は、Firefox 3.5にやや劣るものの、Beta版の頃と比べると、平均読み込み時間が短縮されているのが見て取れる。
次に、Yahoo!ニュースで同様の計測を行ってみた。
| Shiretoko | 3.5 Preview | Safari 4 | |
|---|---|---|---|
| 初回 | 4.58秒 | 4.87秒 | 4.31秒 |
| 平均 | 2.61秒 | 2.57秒 | 1.74秒 |
Shiretokoは、初回読み込みで3.5 Previewに多小差を付けている。スクリプトの処理がわずかに向上したとも考えられるが、平均では差がないので、これも測定誤差の可能性が高い。
他方、Safari 4の速さには目を見張るものがある。興味深いことに、このパフォーマンス傾向は、Firefox 3.5を上回る点も含め、Google Chrome 2.0（以下Chrome）と共通だ。WebKitが得意とするレンダリング対象に、ページがうまく当てはまっているのだろう。
レンダリング時間
『Test rendering time』で巨大なテーブルを処理させ、各Webブラウザのレンダリング能力を調べてみた。以下の表の「初回」および「平均」の意味は、ロード時間のケースと同じである。ただし、平均を出す際、ロードの間隔はとくに設定していない。
| Shiretoko | 3.5 Preview | Safari 4 | |
|---|---|---|---|
| 初回 | 7.0569秒 | 6.5260秒 | 2.3250秒 |
| 平均 | 6.1106秒 | 6.0642秒 | 1.3896秒 |
初回読み込みは通信状況の影響を受けるので、多少の誤差はやむを得ない。ただ、平均時間でもShiretokoが3.5 Previewより少し遅いのは気になるところだ。
その一方、Safari 4は非常に成績が良く、平均タイムでいうと、Chromeよりも短時間でテストを終えているほどだ。レンダリング能力の高さが窺える。
ダイナミックコンテンツ
『HTML - DHTML Test』は、リアルタイムでコンテンツを変化させ、その描画性能を計測してくれる。ブラウザエンジンの各パートがうまく連携しないと、高いフレームレート（fps）が出ない。
| Shiretoko | 3.5 Preview | Safari 4 | |
|---|---|---|---|
| フレームレート | 8.63 - 9.65fps | 8.86 - 9.84fps | 9.76 - 10.11fps |
Shiretokoは3.5 Previewよりも少しパフォーマンスが落ちているようだ。3.5 Beta 4が「8.91 - 10.18fps」だったので、これと同じ水準を維持できなかったのは残念である。
Safari 4はFirefox 3.5と大差ないレベルだが、下限の数値が高く、安定している。Chromeがこのテストを苦手としていたことを踏まえると、なかなかの好成績というべきだろう。
スクロール
スタイルシートで背景画像を固定したWebページにおけるスクロール性能と、CPU負荷をテストケースを使って計測した。なお、「CPU負荷」は、タスクマネージャに示されたCPU使用率の最高値であり、条件を均等にするためウィンドウはすべて最大化してある。
| Shiretoko | 3.5 Preview | Safari 4 | |
|---|---|---|---|
| 1回目 | 4647ms | 4629ms | 8769ms |
| 2回目 | 4671ms | 4611ms | 8752ms |
| 3回目 | 4604ms | 4611ms | 8713ms |
| CPU負荷 | 52％ | 55％ | 60％ |
Shiretokoと3.5 Previewの所要時間は同じなので、パフォーマンスは同一。ただ、ShiretokoのCPU負荷は少しだけ下がったようだ。
Safari 4の成績は芳しくない。Chromeが最高のパフォーマンスを叩き出すこのテストで、Firefox 3よりも遅い結果になっている。実は、Beta版でも同じ現象が発生していた。正式版で問題が修正されなかったのは、何かエンジンの深い部分と関わっているからなのか。
JavaScriptベンチマーク
ここからは、JavaScriptエンジンの性能をチェックしていく。利用したベンチマークは、SunSpider、V8、Dromaeoの三つである。なお、ShiretokoおよびFirefox 3.5の設定は、断らないかぎりjit.contentがtrue、jit.chromeがfalse（デフォルト）となっている。
SunSpider
最初に、SunSpiderベンチマークの成績を比較してみよう。
| Shiretoko | 3.5 Preview | Safari 4 | |
|---|---|---|---|
| Total | 2049.4ms +/- 0.8% | 2052.0ms +/- 0.7% | 1281.6ms +/- 1.2% |
| 3d | 284.8ms +/- 1.3% | 291.6ms +/- 1.7% | 298.2ms +/- 3.2% |
| access | 293.0ms +/- 2.7% | 293.0ms +/- 1.1% | 122.4ms +/- 3.3% |
| bitops | 63.8ms +/- 2.5% | 63.4ms +/- 2.2% | 59.2ms +/- 1.8% |
| controlflow | 96.2ms +/- 0.6% | 97.6ms +/- 1.5% | 5.6ms +/- 12.2% |
| crypto | 104.2ms +/- 1.0% | 105.0ms +/- 2.2% | 90.0ms +/- 1.4% |
| date | 305.0ms +/- 1.8% | 300.4ms +/- 1.1% | 126.8ms +/- 0.4% |
| math | 98.0ms +/- 1.6% | 97.0ms +/- 0.9% | 182.8ms +/- 1.2% |
| regexp | 131.6ms +/- 3.9% | 142.8ms +/- 11.6% | 39.0ms +/- 2.3% |
| string | 672.8ms +/- 0.2% | 661.2ms +/- 1.1% | 357.6ms +/- 0.7% |
Shiretokoと3.5 Previewの数値は見事なまでに近い。対するSafari 4は圧倒的なスピードだ。Chromeが「1223.4ms +/- 2.1%」だったので、ほぼそれに匹敵する。また、Beta版の成績である「1651.0ms +/- 0.2%」からの伸びも著しい。Nitroエンジンは大きく改良されたことがわかる。
もう一つ、Firefox 3.5でTraceMonkeyを使わないケース（jit.contentもfalse）も見ておこう。信頼区間に差があるので一概には言えないが、Shiretokoは3.5 Previewよりも成績が落ち込んでいる。Beta 4が「5821.2ms +/- 0.7%」だったので、これと比べると明らかな悪化だ。また、過去最高のケース（3.1b3pre, ID:20090227033431）を持ってくると、低下ぶりが目立つ。
| Shiretoko | 3.5 Preview | 3.1b3pre | |
|---|---|---|---|
| Total | 6047.8ms +/- 0.9% | 5999.2ms +/- 0.2% | 5655.4ms +/- 0.7% |
V8
次に、V8 Benchmarkで比較してみよう。
| Shiretoko | 3.5 Preview | Safari 4 | |
|---|---|---|---|
| Score | 199 | 196 | 1091 |
| Richards | 751 | 737 | 1479 |
| DeltaBlue | 53.1 | 52.6 | 1172 |
| Crypto | 281 | 313 | 1568 |
| RayTrace | 152 | 152 | 1193 |
| EarleyBoyer | 181 | 179 | 1569 |
| RegExp | 110 | 110 | 481 |
| Splay | 367 | 273 | 751 |
Shiretokoと3.5 Previewに差は見られない。Safari 4はここでも強かった。Chromeが1451なのでそれには及ばないものの、Firefox 3.5とは桁違いの数字が並んでいる。なお、同じWebKit系とはいえ、搭載しているJavaScriptエンジンは別々だから、SunSpiderのように僅差でなくても不思議はない。
Dromaeo
Dromaeoは、三つのベンチマークの中で最もヘビーで、それだけにエンジンの性能が問われるテストである。
| Shiretoko | 3.5 Preview | Safari 4 | |
|---|---|---|---|
| Total | 35.73runs/s ±3.55% | 35.43runs/s ±3.65% | 61.35runs/s ±2.27% |
Shiretokoと3.5 Previewはここでも誤差程度の差しかない。ちなみに、Beta 4の「34.79runs/s ±3.66%」と比べると、約3％弱の向上である。
Safari 4とは大差がついた。Chromeの「71.76runs/s ±4.70%」には及ばないが、Beta版が「51.21runs/s ±2.31%」だったことからすれば、充分に高速化されている。
なお、CNET Japanの『「Safari 4」の正式版--ベータ版からの変更点とパフォーマンス:スペシャルレポート』を見ると、DromaeoでSafari 4が175.06runs/s、Chromeが67.92runs/sで、Firefox 3.5 Previewは48.48runs/sだったとしているが、あり得ない。SafariとFirefoxの成績に照らしてみると、Chromeはテスト中に何かトラブルがあったと考えるべきだろう。
総評など
Firefox 3.5 RC1と同じコードベースのShiretoko Nightlyは、Firefox 3.5 Previewとかなり似たようなベンチマークの成績を出した。一部のテストでは若干の低下もみられたが、これがPreviewリリース後の修正による影響か、測定誤差なのかは判断が難しい。
ただ、不具合があったから修正したわけで、その分安定性が増していると考えられる。かつてTraceMonkeyはバグの宝庫で、潰しても潰しても次から次へとバグが発見され、モグラ叩きのような様相を呈していた。それをあらかた潰し終えたのが今の状況だ。アドオンの互換性という難題を抱える中、JavaScriptチームは良い仕事をしたと思う。
他方、Safari 4はBeta版からパフォーマンスを大きくアップさせ、動作も安定したようだ。とくにJavaScriptの処理に関してはかなりのレベルに達しており、TraceMonkeyがNitroエンジンに追いつくのは容易ではないだろう。
とはいえ、スピードだけを比べたときは、なおChromeが上回っているから、世界最速を名乗るのは不適当というほかない。加えて、かなり改善されたとはいえ、Flashとの相性の悪さは残っている。Flashを使ったコンテンツがページ内にあると、CPU負荷が目立って高まり、読み込みも遅くなる。したがって、たとえばYouTubeを見るのには、Safari 4よりもFirefox 3.5やChromeのほうが向いている。
Firefox.nextに目を向けると、JavaScriptチームは既に増員を図って、パフォーマンスの向上に向けた下地慣らしを始めた。また、グラフィックスのハードウェアアクセラレーションや起動プロセスの改善など、サポートするOSを絞ってでもスピードを引き上げようと計画を練っている。その成果は実に楽しみだが、残念ながら製品として結実するのは、早くても10か月後になりそうだ。それまでChromeやSafariに大きく水をあけられた状態で耐えしのぐ必要がある。ここからはマーケティングの出番かもしれない。
