数あるアドオンの中でも、FasterFox（派生版を含む）ほど賛否が極端に分かれるものもないだろう。「高速化の切り札」といった文句で褒め称えるマスコミのWeb記事やレビュー、一般のブログ記事が出ると、古参のユーザーが「ダメ。ゼッタイ。」と利用を戒めるのが定番になっている。
しかし、トンデモ扱いして切って捨てるだけでは、もはや説得力に乏しいだろう。なぜなら、FasterFoxが非難される最大のポイントは、接続先のサーバーに過大な負荷をかけるおそれがあるという点にあるが、サーバーの性能、帯域幅ともに年々引き上げられているからだ。
とくに、先読み機能とサーバー当たりの最大持続接続数の話は、分ける必要がある。まず、先読み機能こそが酷いという意見だが、その根拠はもうしばらくは通用しそうだ。あるサーバーのページを読み込んだら、そのリンク先のページも片っ端から読み込んでいくのがこの先読み機能である。もともとFirefoxがサポートしている先読み機能は、ページが明示的に先読みを指定しているリンクにだけ働くのだが、FasterFoxは指定のないリンクでも先読みを行う。この荒っぽさゆえに、作者がFAQの中でサーバー側の遮断方法を説明するという奇妙なことになっている。また、派生版のFasterFox Liteは、「先読み機能を含まないFasterFox」として作られた。本家の弊害が意識されていればこそだ。
これに対し、FasterFoxがサーバー当たりの最大持続接続数を増やす点は、下手に非難すると墓穴を掘ることになる。「Firefoxまとめサイト」の該当記事によれば、「Fasterfoxの『ターボチャージャー』では、ひとつのサーバーに対する最大持続的接続数がRFC 2616の4倍となる8に設定されている
」ことが問題だという。インターネットの規約であるRFCを守っていないのが悪いというわけだ。ただ、FasterFoxの設定画面には、「ターボチャージャー」を選ぶとRFC仕様を超える設定になると明記されている。ユーザーに誤ったインセンティブを与えているとは言えても、何の問題もないかのように騙しているわけではない。
真に重要なのは、Firefox 3がこのサーバー当たりの最大持続接続数をデフォルトで6に設定していることである。これは、about:configの画面で"network.http.max-persistent-connections-per-server"の値を確かめてみればすぐにわかる。Firefox 2のときは2だったものを、6に増やした。RFC仕様をオーバーする設定に最初からなっているのだ。
この変更がインターネットに与えたインパクトはかなりのものだったと推測される。Firefoxのユーザー数については正確な統計が発表されていないようだが、Mozillaが把握しているところでは、2008年10月の時点で6770万人（日常的に利用しているユーザー数）。NetApplicationsのデータを参照すると、2008年10月に19.97％だったシェアが2009年1月に21.53％に増加しているから、単純計算で2009年1月には約7300万人のアクティブユーザーがいたことになる。また、Firefox 2のユーザー数は、2009年1月下旬の時点で1360万人だという。これを差し引いた約6000万人がFirefox 3のアクティブユーザーとみられるが、これだけ大勢の人がサーバー当たりの最大持続接続数を6にした状態でアクセスを続けている。ちなみに、Internet Explore 6/7もこの数はデフォルトで2に設定されているため、Firefox 3にバージョンアップしたケースだけでなく、乗り換えたケースでも、同程度にサーバーに負荷をかけるようになったと考えられる。
約6000万人のユーザーが上記の数を2ではなく6でサーバーにアクセスしていることのインパクトと、約7300万人のユーザーの一部がFasterFoxを入れてこの数を8にしてアクセスしていることのインパクト。どちらが大きいかは言うまでもない。RFC仕様をオーバーしている点を捉えてFasterFoxをトンデモ扱いすると、Firefox自体がトンデモになりかねない。しかも、IE8がこの最大持続接続数を6に増やす予定だ。Firefoxが先行していなかったら、はたしてMicrosoftはこうした措置をとっただろうか。ここでは、RFC破りの先例を作ったFirefoxは罪深いという批判も成り立つ。
（09/02/04追記）
コメントでのご指摘を受けて、誤った記述を訂正する（ただし原文は残す）。Bug 423377における一連のやりとりから察するに、Firefox 3は、IE8 Beta 1に追随して最大持続接続数を6にした。先例を作ったのはIEのほうだ。
これとは別に、興味深いのは、RFC 2616のSection 8.1.4に"A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy."とあり、"MUST NOT"とされていないことを理由に、接続数を増やす余地があると判断されていたところ。"SHOULD NOT"なので、たんなる推奨ではなく一定の拘束力をもつはずで、「3倍しても許容範囲」というのは無理がある。"Alea iacta est."（賽は投げられた）といって見切り発車したのが、そのまま定着してしまったようだ。となると、やはりFasterFoxだけを責めるのは難しい。
＜追記終わり＞
Firefoxの評判を守るためにFasterFoxを批判すると、その矢が自分に向かってくる。墓穴を掘るとは、そういう意味だ。余談になるが、FasterFoxと同時に「DNS Prefetch」を批判する場合も同じことが言える。『Firefox 3.1で採用される高速化技術』で説明したとおり、DNSプリフェッチはFirefox 3.1で標準機能になる。DNS Prefetchという拡張機能をトンデモ呼ばわりするなら、Firefox 3.1もトンデモなのか。
今後は、「ダメ。ゼッタイ。」ではなく、現在のインターネット環境に照らして、どこが問題なのかを具体的に示さなくてはいけない。この場合、もし先読み機能こそが問題だと判明したのなら、FasterFox Liteの使用を戒める理由は消える。
ほかにFasterFoxを使うとまずそうな点を考えてみよう。たとえばパイプライン接続はどうだろう。Firefoxまとめサイトでは、そのデメリットとして、「一部のサイトで画像の読み込み速度が極端に低下する
」ことを挙げる。実際には、うまく画像を読み込めずに表示が崩れることもある。が、これは嫌ならユーザーが設定をオフにすればいいという話でしかなく、「使ってはいけない」理由にはならない。また、FasterFoxは最大パイプライン要求数をFirefox 3のデフォルトである4から8に引き上げるが、その変更はサーバーに大きな負荷をかけるのだろうか。あるいは、サーバー当たりの最大接続数に目を向けると、これをデフォルトの15から24に引き上げるのは、強く非難されるほど悪質なことなのか？
一見実証データがないと水掛け論に終わりそうだが、別の角度から光を当ててみると、意外な事実に気づく。Mozilla Add-ons（AMO）で「Video DownloadHelper」と比較してみよう。累計ダウンロード数こそVideo DownloadHelperの約2900万に対し、FasterFoxは約1100万とそれなりに多く見えるが、週間ダウンロード数では103万対2200とまるで桁が違う。FasterFox Liteの4700を足しても勝負にならないことは明らかだ。もちろん、FasterFoxは実験的なアドオンとして登録されているので、AMOではなく公式サイトからダウンロードしている人は多いだろうが、この圧倒的な差は変わらないはずだ。要するに、FasterFoxやその派生物のユーザー数は、Video DownloadHelperのユーザー数に及ばず、伸び率を見るとはるかに小さい。
そして、動画のダウンロードはサーバーに大きな負荷をかけ、帯域幅も占有する。このとき、負荷がかかるサーバーは動画共有サイトだけ、というわけにはいかない。プロバイダを通じてインターネットにアクセスしている以上、そのサーバーへの影響も考慮する必要がある。加えて、帯域幅の占有はインターネット利用者の全体に関わる事柄だ。とすれば、Video DownloadHelperがネット全体に与えるインパクトは、FasterFoxの比ではないとの見方も十分可能だろう。
では、Video DownloadHelperはトンデモ拡張機能なのか。「使ってはいけない」のか。このアドオンは、Mozilla Japanで「スタッフのおすすめ」に指定されているが、これも謝罪して撤回すべきなのか。違うというなら、FasterFoxだけがダメな理由をどう説明すればいいのだろう。
以上の検討で、単純にFasterFoxを切って捨てるのは無理だということが明らかになった。それでも使うべきでないと主張するなら、その弊害を具体的に、しかも説得力のある形で示すべきだ。当ブログの見解に対する反論は歓迎する。議論を深めていければ幸いである。
